So, I have heard about code porting, basically where you take existing code from one language, and translate it to another language. What I want to know is how does this process work? Are there automated tools for preforming this type of thing, or is it always a manual process? The languages really don't matter to me, I just want to understand the process. For instance, is source code analyzed, or are automated tools used to translate between bytecodes etc.

I would have selected all languages, but there was a limit on the number I could select.

Dani AI

Generated

Quick primer and practical path.

"Porting" (moving an app to a different OS, libc, or CPU) and "transpiling" or source-to-source translation (turning code in language A into language B) are related but different problems. Porting is dominated by system APIs, binary interfaces and performance tradeoffs; transpiling is dominated by language semantics and runtime model. already flagged that distinction, and it's the right place to start.

Concrete checklist to reduce risk.

  • Create a thorough test suite first: unit, integration, and a few behavioral end-to-end tests. Tests are your contract during the rewrite.
  • Inventory dependencies and platform gaps: third‑party libs, system calls, file formats, threading model, and expected performance.
  • Pick a strategy for each subsystem: run-as-is under a VM/container or compatibility layer; transpile an isolated module; write language bindings/FFI; or rewrite with a compatibility shim.
  • Port incrementally by module, not all at once. After each module, run tests, profile, and review the produced code for idiomatic mismatches.
  • Plan roll-back and staging; use CI to catch regressions early.

Practical notes and pitfalls.

  • Automated translators work well for small, well-defined subsets or boilerplate, but they often produce non-idiomatic code and miss semantic edge cases — as warned. Regex-based conversions fail quickly; AST-driven tools are far safer.
  • Expect to emulate or polyfill missing runtime features (garbage collection differences, exception semantics, integer sizes, concurrency primitives).
  • Performance and security characteristics can change. There are often many "valid" translations; choose one that preserves the runtime contract, not just a line-by-line mapping (echoing ).
  • You will frequently need to infer intent where tests or docs are missing, as noted — keep those areas small and well-covered by tests.

Small iterative workflow (illustrative):

git checkout -b port-target
./run_tests.sh        # baseline
# port one module, add/adjust tests
./run_tests.sh
git commit -am "port module X"
# repeat

Summary: use tests, inventory dependencies, choose an incremental strategy, and expect manual work. Automated tools can help, but heavy review and validation are the reliable safeguards.

Recommended Answers

All 5 Replies

Sure there are tools out there to "translate" from (for instance) Java to Javascript (basically, the GWT framework generates javascript to run on the client's machine based on the Java code written by the developer) or from Java to a C variant.
Does this mean it's always good to use them? In my opinion, no.

If it's just for small snippets it'll be easy-peasy to test, but if you're going for larger applications, it'll be very hard to discover subtle "translation errors" which may create bugs. Computer languages also evolve, so the conversion tools might not convert to the latest version of the language.

commented: Thanks for the reply, didn't know that they were that bad at translating... Perhaps there should be improvement in transcompilers? +2

You try to emulate the original with what system resource you have. Also need to reverse engineer/intelligent guesses to what the intent of certain parts of the code does.

commented: So getting the sense that there is still a lot of manual work involved. +2

porting usually means getting something to work on a different operating system and/or hardware.
This is largely a manual process (though I'm sure there are tools that can help identify common areas of interest).

Transpiling is the move of one language to another. While there are tools that can help (again) it's mostly a manual process again.

Now, what stultuske mentions, code generation using code in one language written to a highly specific and limited API to generate code in another language that's defined by the original code is no different from any other compiler.
A Java compiler generates executable bytecode from Java code. A GWT compiler generates Javascript from Java code. A C++ compiler generates object code from C++ code, a C# compiler generates C# runtime units from C# source code.
You can definitely write a tool that generates say Java source code from C++ source code, but it'd be one hell of a job.

commented: I did some googling, apparently sourceforge has some of these tools, and they are very extensive programs, had to cancel the svn download. +2

So I have done some googling on this, sometimes they are called transcompilers, other times they are called source to source compilers. They have actually been used a lot more than I thought they had. Python had one for updating python 2 to python 3, there was one for migrating off of typescript (I had to work with some old versions of Typescript, was buggy as hell), etc. There was a wiki article that discussed them. Also apparently there are quite a few tools on sourceforge, I may try to browse some code if the download doesn't take all day (seriously why is turtle svn not multithreaded?). I will keep this thread open for a while in case somebody else has other information/links etc to add. Thanks for the discussion guys.

If there was some computer program which could transcompile between languages, it would make life a hell of a lot easier for certain legacy situations. My last job had some really really old code there that they were still actively developing. :(

The problems I guess would be navigating from a language with a certain feature to a language without a certain feature, example C to C++, one is object oriented, one is not. The tools would also break whenever the API changed. One might need some sort of configuration for each language, as well as a way to automatedly perhaps download API calls/configurations as they were added (web bot?). It seems like a very involved process. I have some free time, perhaps I will look into this a little bit.

Actually if there are any tools you have used, and they are available for free download/source code browsing, please include some links.

The problems I guess would be navigating from a language with a certain feature to a language without a certain feature

That's one problem, yes. Another would be choosing a consistently compatible translation route when the target language has multiple ways of doing the "same" thing that in practice may not be the same as the source language. Another might be performance concerns of compatible translations where you don't want the obvious translation because it's hideously slow. Security concerns also vary between languages.

All in all, translating a program between languages tends to be far more complex than it initially seems. It requires intimate knowledge of both, and often there are parts you simply cannot convert automatically without some manual intervention to resolve conflicts.

commented: Good observations. +2
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.