I have heard of some compilers that convert code in one high level language to another
e.g Shedskin that converts python code to optimized C++.
I was wondering why would one ever try to do that. Why not directly write in the desired language itself?
The only reason I could think of was may be compiled languages like C/C++ are better than interpreted ones performance-wise.
Any more insights are welcome.
It is often handy to convert one part of a codebase into a different language if you want to reuse that code in another project.
For example, say you had a python application which used some handy utility functions. Later, you're writing a C++ application, and need that same functionality.
You have two options - either use some form of bridge to call the python code from C++ (which can be clunky at times, although it is possible), or rewrite the routine in C++. Translation tools can simplify the second option.
Well if you think about it, any compiler converts to another language: machine code.
If you go with that argument, anything other than assembly is pointless. (Actually assembly would be too. Real men type hex opcodes by hand.)
You would use one language to convert to another if you want to write from a higher level perspective or if you are more comfortable in one language than another.
For example, would you rather write and debug a few hundred lines of network code in one language or use 5-10 lines in another language?
It is often handy to convert one part of a codebase into a different language if you want to reuse that code in another project.
For example, say you had a python application which used some handy utility functions. Later, you're writing a C++ application, and need that same functionality.
You have two options - either use some form of bridge to call the python code from C++ (which can be clunky at times, although it is possible), or rewrite the routine in C++. Translation tools can simplify the second option.
Not only for performance issues, but also for skillsets - sometimes it is faster to go through slightly mangled code in a team's primary language than it would be for them to learn the source language and edit it due to time constraints.
One benefit is it allows you to prototype your applications in a dynamic language, and then optimize them in a statically compiled language. This allows you to focus on the algorithm in a very permissive language like Python, and then compile into a statically typed language like C++ when you're interested in speed and type-safety.
The other advantage of tools like this is that it allows translation of legacy code into more modern languages. I've used f2c in the past to convert some old Fortran projects into C, and while it wasn't perfect it solved a lot of simple, repetitive problems that I didn't want to solve myself.
One other valid reason for converting code is for updating it. For example, we have a 10 year old application written in Delphi, and a large portion of it will be needed in C# in an update we're about to start. Rather than re-write the code in C#, we just convert the entire application, make the updates, and we have a brand new app in about 6 months compared to the two years it would take to re-write.
high level languages are supposed to be easier to write. Even a C++ compiler is a tool to convert one language (C++) to another (object code)
This is because the "interpreted" language is higher level. Typically this means that much of the difficult or boilerplate code you'd have to write is taken care of, allowing you to focus more on the problem and less on the actual workings of the language or compiler.
Other situations like Java or .NET compile to their various byte code formats which are then either interpreted by a virtual machine, or JIT (Just In Time) compiled to machine code. This makes the compiled bytecode more portable, so that it can be run anywhere the virtual machine or JIT compiler exist, regardless of platform.
Some languages were written for a specific purpose in mind. Erlang for example was written specifically to be multi-threaded and crash resistant. The developer of CouchDB said he started his project in C++, but then switched to Erlang, as it fitted his programming model better.
VM languages like .NET/C# are more general purpose languages, and well suited for programmers that just want to get the job done. Built-in safety-nets help protect from common problems. No need to worry about things like buffer overflow attacks, as such security issues are generally taken care of by the VM.
C++ is fast, but requires more work.
One reason to go from one language to another (Python -> C++) is an optimization issue. By compiling to native code you get rid of any interprittation or JIT'ing step. That might normally occur with Python; you would also remove any reliance on having Python installed locally on a machine.
Additionally, the program can now make use of any optimization capabilities of the destination compiler. I've heard this is fairly common when writing a simple compiler; to go from the 'nice' language to an intermediate language with an optimizing compiler.
And finally, as others have said, the reason for using Python over C++ is because it should easier to work in; from Epigrams in Programming, "A programming language is low level when its programs require attention to the irrelevant."
The only good reason to convert working code to another language is that your target platform doesn't support any compiler for the native language. If that isn't your situation, then it is a stupid thing to do.
The thing you have to realise is that language's features don't overlap perfectly. So there is going to have to be some recoding. That's work.
You are going to have to invest a lot of effort, perhaps equivalent to %50-%75 of the effort of rewriting from scratch. At the end of all this you will have something that only works as well as the thing you already had working just fine for free. Plus any new bugs you introduced.
© 2022 - 2024 — McMap. All rights reserved.
