HN Explorer

Ask HN: Need for openly available source-to-source compilation projects

2 points by zxienin ↗ HN
Is there need for openly available, batteries included, source-to-source compilation projects?

I talk being able to transpile from one programming language source to another (java to rust, cobol to java and so on).

There is of course, option like ANTLR, though it leaves ground wide open after parsing.

IMHO having such tool can help renovate legacy codebases easier, minimize over focus on programming language decisioning in greenfield projects. Yet, despite noticing organizations always burdened with managing old codebases, surprisingly there aren't such tools built out in the open. Why? Do I mis-judge the demand space as being strong?

4 comments

[ 3.5 ms ] story [ 19.1 ms ] thread
detaro
I don't think demand is particularly large: do you have examples of projects that used source-to-source compilation on a large scale (outside the web ecosystem, which is very much a special case). And I especially don't think they are good candidates for being open tools, especially if porting "forwards" to more modern languages, but much more likely to be inhouse tools of companies specializing in ports.
zxienin
> do you have examples of projects that used source-to-source compilation on a large scale

That's the root of opening this question. In the companies, that I've been in, I have numerous cases where business was impaired by speed at which codebase could be renovated. Basically, a. business looks at engineering b. engineering shrugs (we got capacity, time constraints)

This is where, I believe, an openly available tool like above would make the difference.

I'd like to hear more on what you say at the tail end.

> And I especially don't think they are good candidates for being open tools Why?

> especially if porting "forwards" to more modern languages Am curious. What, in modern languages, makes it so?

> but much more likely to be inhouse tools of companies specializing in ports. Why do you think it fits inhouse cases?

I can imagine an openly available option, commonly used by each inhouse team, to be more effective. You get community scale of development, This space doesn't really look very IP differentiating vis-à-vis business anyways.

detaro
Porting forwards is in my view typically done to move a project from A to B once. That can be a longer process due to complexity, but it's a phase that starts and ends and ideally is short. In contrast, compiling "backwards" is often done for a longer time for platform support -> compiling languages to run in the browser with JS, to run on platforms that only have a C compiler, to bootstrap a compiler toolchain off a C/C++ compiler.

<EDIT> Doing it fully automatically often has problems with the usability of the source code for further development. Automatically converted code will work, but typically not look like properly human-written code in the target language. Fixing that is additional difficulty or human work, so often semi-automated is actually better. </EDIT>

At the same time, building such tools requires different skillsets than typical application development or manual porting. If you are massive, or the type of company that has uses for this skillset elsewhere, it might still be viable to hire for those skills. But for many companies, they don't want to have this problem around long-term. They do not want to long-term maintain migration tooling, they're the happiest if the migration happens and they never need to think about anything related to it again. That's a poor motivation to maintain an open project. (they'd of course love if other people had done that and open-sourced their work)

On the other hand, specialized knowledge required on a per-project basis is pretty much the perfect scenario for consulting work. And a company that repeatedly does ports for customers has an interest in a) having deep knowledge about it b) automating the work where possible, even if automation is expensive up-front c) being paid for said investment in knowledge and not giving it away for free.

zxienin
> But for many companies, they don't want to have this problem around long-term. They do not want to long-term maintain migration tooling, they're the happiest if the migration happens and they never need to think about anything related to it again.

Treating $(subject) tool to be equivalent of day 2 ops, does the trick.

What makes it viable to do it with a team of (say) 6 folks? Community driven core, adopted internally by this team.

So is it mostly about mindset change, or it just really doesn’t have a place in org internal engineering team setups?