Hacker News new | ask | show | jobs
by jaxrtech 1341 days ago
A lot of the time, I ask myself, "why don't we seem to have a tool with robust source-to-source transformation?" You could call it "cross-language refactoring". I wouldn't be surprised if someone with the code-base the size of Google has some internal tool. Maybe this is just wishful thinking. The closest thing I've seen is in academic research, e.g. [1].

[1]: Koppel, Solar-Lezama - Incremental parametric syntax for multi-language transformation (2017) - https://dl.acm.org/doi/10.1145/3135932.3135940

4 comments

The cost of this challenge is likely bigger than the market. How many large code bases need to be translated from X to Y? Probably not very many. There are only so many legacy COBOL systems.

Big issues off the top of my head.

Legacy support. Legacy code is already difficult to understand. If it was originally written in another language that would only make it harder to grok.

Transpiled output is often ugly. Developers in general seem to dislike modifying generated code for a number of reasons. I imagine transpiled code would end up implicitly frozen, and new code would only be added to new files.

Language idioms are hard to translate. Some structures are unique to languages and their equivalents may be considered bad in other languages.

You would either need equivalent libraries in new languages or also translate dependencies. You could probably find equivalent libraries, but their scope may vary.

Large scale code organization varies between languages. Things like Dependency Injection may not translate at all. Some languages may use config and some use code for the same thing.

I mean Google did essentially do this: https://opensource.googleblog.com/2017/01/grumpy-go-running-...

Except without actually solving the problem of making the translation nice and readable. But this kind of thing at least gives you options for changing language.

Idioms and features often don't match up between any two languages. For example, what do you do with monkeypatched code when porting from Ruby to Go?
There are some tools specific to some transformations at least:

https://c2rust.com/