
Ask HN: Need for openly available source-to-source compilation projects - zxienin
Is there need for openly available, batteries included, source-to-source compilation projects?<p>I talk being able to transpile from one programming language source to another (java to rust, cobol to java and so on).<p>There is of course, option like ANTLR, though it leaves ground wide open after parsing.<p>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&#x27;t such tools built out in the open. Why? Do I mis-judge the demand space as being strong?
======
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?

