3 ms·

> Switching is possible, but the cost to replace it is half a decade or more. I would imagine if you're going to switch millions of lines from one language to

> Switching is possible, but the cost to replace it is half a decade or more. I would imagine if you're going to switch millions of lines from one language to another - you wouldn't do it by hand - you'd write something transpile it? Has any company actually done something like this before - especially somewhat recently? I can't imagine anyone doing it by hand...

cguess 4y ago
That doesn't really work in practice at scale. There's "Ruby" ways of doing things that don't just transpile over. It's also the entire Rails framework that would have to be ported then, which is beyond a monumental undertaking. That's not to even mention the massive amounts of new bugs that would be put into the code that have been ironed out over years of debugging and testing in the Ruby base. There's a reason so many legacy operators still run COBOL despite even C being a better candidate, it was just created twenty years too late and the costs of moving it over is well outside of the savings of not doing that. "If it ain't broke, don't fix it" is very much the key here.
bastawhiz 4y ago
You need to produce code that not just runs, but is idiomatic in the target language. I'm not aware of ANY transpilers that do this for target and source languages that run in different runtimes (i.e., not coffeeacript to JS). You need every language feature to translate cleanly, and that means that a translation failure makes it impossible to convert a logical unit (module, package, etc) at once. Simply having a translated version of the code without making it idiomatic means it's impossible to read or modify.
mprovost 4y ago
How is hiring a few people to write a transpiler any different than hiring a few engineers to write a JIT compiler? Isn't a JIT just transpiling code at a different level (bytecode instead of source code)?
r-s 4y ago
Many many years ago I was hired to convert a Fortran app to C. The first person to try it ran it through a software called "f2c". It worked fine - but the code was totally non human readable so it couldn't be extended later, so it provided almost no value in this case.

cguess 4y ago

That doesn't really work in practice at scale. There's "Ruby" ways of doing things that don't just transpile over. It's also the entire Rails framework that would have to be ported then, which is beyond a monumental undertaking. That's not to even mention the massive amounts of new bugs that would be put into the code that have been ironed out over years of debugging and testing in the Ruby base. There's a reason so many legacy operators still run COBOL despite even C being a better candidate, it was just created twenty years too late and the costs of moving it over is well outside of the savings of not doing that. "If it ain't broke, don't fix it" is very much the key here.

bastawhiz 4y ago

You need to produce code that not just runs, but is idiomatic in the target language. I'm not aware of ANY transpilers that do this for target and source languages that run in different runtimes (i.e., not coffeeacript to JS). You need every language feature to translate cleanly, and that means that a translation failure makes it impossible to convert a logical unit (module, package, etc) at once. Simply having a translated version of the code without making it idiomatic means it's impossible to read or modify.

mprovost 4y ago

How is hiring a few people to write a transpiler any different than hiring a few engineers to write a JIT compiler? Isn't a JIT just transpiling code at a different level (bytecode instead of source code)?

r-s 4y ago

Many many years ago I was hired to convert a Fortran app to C. The first person to try it ran it through a software called "f2c". It worked fine - but the code was totally non human readable so it couldn't be extended later, so it provided almost no value in this case.