[Frieren]

> There is a recurring need in the software world for teams to convert a codebase from one language to another.

Sounds more like a sales pitch than a reality. I have seen many times developers excited to port code from one language to another, but just because it is an opportunity to learn something new, do something different for a change and even rewrite old code.

What is the value if is done automatically, nobody learns anything and the code is just a transcript of the old one?

[temporarely]

Back in late 80s we were building automated Fortran to C converters. Client was in the aerospace field.

> What is the value if is done automatically, nobody learns anything and the code is just a transcript of the old one?

You may be shocked to learn that businesses using software have a different metric for the value of "code" than educating their (transient) code wranglers. The actual value of software is computational work. If a new language affords better tooling and availability of human resources, that is a win.

[Closi]

Yes, I was at a company that moved an application from Cobol to Java for exactly that purpose - having a mission critical application written in cobol is way harder to maintain than having that exact same application in Java.

[codr7]

Extremely short term, yes.

In the longer perspective, you'll lose most good developers if you don't allow them to evolve and have some fun along the way. And without the developers, the source code is pretty much useless.

Humans are not machines.

[refulgentis]

I think this is an interesting line of argument but its sort of reached its shallow depth on its 3rd exposition: it's not very complicated if I'm reading it correctly:

"Theoretically, developers could eschew jobs that don't allow them to creatively reinterpret code as they translate it."

It's a weak argument, because if you're translating even manually, it's not exactly the peak of creative self-expression.

There's plenty of rote code that we'd all be happy to automate translation of --- I used this technique with GPT 3.0 to get math code translated across languages for Google's color library.

[codr7]

You'd have to take a step back to see it, I think.

It's more like: in general, people will chose fun over not fun, given they have a choice.

And good developers have PLENTY of choices.

[StableAlkyne]

> you'll lose most good developers if you don't allow them to evolve and have some fun along the way

That's actually something I really like about tools like GH Copilot! It gives me an excuse to try out something using a new language, but with less of the productivity dip that comes from chasing syntax or stdlib calls. It doesn't produce code that is as good as an expert in that language, but it's a really convenient set of training wheels

So it becomes easier justify, at least with my current organization

[imvetri]

Businesses see human and machine as resources.

[codr7]

Only the losers, mark my words.

[simonw]

That was my initial instinct on reading that sentence too - I don't think converting from one language to another is actually very common.

But in this particular case I think they justified doing so: "Our team had a prototype written in the language, R, and wanted to convert this to our standard production tech stack, Golang and ReactJS."

As a Python programmer I tend not to worry about this, because Python is a good language for both prototyping and production - but I can absolutely see the need for this if you're prototyping with tools that you wouldn't want to run in production.

[tbrownaw]

One benefit I've heard for using different languages for prototyping and production is that it helps you remember to rewrite things properly rather than just dumping prototype-quality code into prod.

Working around this by using tools that aren't exactly known for code quality in the first place seems like a bit of an odd choice.

[disgruntledphd2]

> "Our team had a prototype written in the language, R, and wanted to convert this to our standard production tech stack, Golang and ReactJS."

It's very hard for me to understand how this would work, unless the R code was very very simple.

Like, R is mostly used for stats, and Go doesn't have all of the stats libraries, so what did the LLM generate?

Maybe it was a pretty simple LoB app written in R (which would be pretty weird, even I as an R-head gave up on writing general purpose software in R some time ago) in which case it makes sense, or else the LLM generated lots and lots of boilerplate for matrix multiplication (I imagine any implementation of `model.matrix` would have been fun).

Very very strange to me, at least.

[simonw]

I would expect most good LLMs to be able to implement statistical functions from scratch in languages like Go.

I often ask ChatGPT Code Interpreter to implement algorithm from scratch in Python where the library needed for that function isn't present in the Code Interpreter environment - things like haversine distances for example.

[skissane]

> I would expect most good LLMs to be able to implement statistical functions from scratch in languages like Go.

Implementing statistical functions from scratch can be rather dangerous – can you trust the implementation is correct? You can have an implementation which works well for a few obvious tests, but then performs poorly for edge cases (e.g. due to excessive accumulation of rounding error). Whereas, good chance the existing R implementation of whatever has been reviewed by expert statisticians.

LLMs can be great for saving time/energy when you have the domain expertise to validate their answers. But if you don't...

[simonw]

Yeah that's fair, I don't have a strong enough background in statistics to be able to catch edge cases in these kinds of things.

[disgruntledphd2]

> Implementing statistical functions from scratch can be rather dangerous – can you trust the implementation is correct? You can have an implementation which works well for a few obvious tests, but then performs poorly for edge cases (e.g. due to excessive accumulation of rounding error). Whereas, good chance the existing R implementation of whatever has been reviewed by expert statisticians.

What the GP said. This would scare the hell out of me, and I probably do have the expertise to check this.

More generally though, the LLM won't see the code for the implementations, just the function calls so I'd be really impressed if it could do a good job here.

[goatlover]

The statistical functions in R and Python libraries are well tested. I don't know what sort of confidence you'd have in an LLM generating new stats libraries in other languages.

[cpeterso]

Was the R prototype outputting HTML code? What React front end code of any value is the LLM extracting from the R prototype?

Other options to converting the code: call into the R code from the Go code. Or don’t let your prototype grow to 12 KLOC in a language you don’t intend to use in production.

[thiht]

> the code is just a transcript of the old one

That’s a very important point. Every rewrite I’ve been part of needed major architectural changes because of deep issues with the system. Switching the language was just a nice bonus.

[john_the_writer]

This was what I was thinking.. Moving something from rails to elixir as a copy-pasta wouldn't give you the things elixir is great at. You'd just get MVC.. No use of OTP or Services.

When I was at Uni I wrote an app for a Java course. The prof laughed and said. "You're a c++ programmer aren't you." My code smelled of it.

"A language that doesn't affect the way you think about programming, is not worth knowing." - Alan Perlis

[singingfish]

Not that long ago I moved a 250kline codebase from oracle to postgres. Yes, SQL embedded in strings and so on.

Towards the end of that process, chat GPT helped me with that, and it was pretty valuable for some kinds of problem. Still had to watch it like a hawk and specify things really clearly to make sure it didn't go off the rails.

[yarg]

There's a huge value in being able to automate conversion, especially on an active project with several teams working on features for several different clients (where downtime simply is not an option).

Having dealt with a similar problem however, stay away from AI and instead perform the conversion by manipulating source code ASTs.

[imvetri]

I don't anyone have solved to do this automatically, in this community.

Value it provides is for the business. If a tool can do it, there is no need to hire or keep an engineering team.

Engineering team has a running cost. Where as, using a tool or if someone makes the tool, sells it at a price slightly lower than what's spent for engineering team, doesn't it add a value?

First. It's a tool that does, so reliable more than a human.

If it is a sales pitch, someone will get it done, as there is an opportunity

[TechDebtDevin]

It's not reliable and LLMs cannot create anything novel.

Your hypothetical company is going to end up pulling a Crowdstrike with this method and then they definately won't need an engineering budget!

[nerdjon]

> Value it provides is for the business. If a tool can do it, there is no need to hire or keep an engineering team.

What exactly is the "value?". It worked before so what is the purpose of the change.

> First. It's a tool that does, so reliable more than a human.

Sorry but, are you new to LLM's? Have you seen the recent news? "Reliable" it is not.

If your pitch is that an LLM will just write all of your code in the first place, there really isn't any need to migrate the code to another language when by your logic the LLM could just manage its existing language. The logic here quickly breaks down and doesn't make any sense.

[imvetri]

What news? I'm not talking about LLM. I'm talking about the challenge of cross language and code generation

[nerdjon]

> What news?

https://news.ycombinator.com/item?id=40475578

One such news entry, LLM's being unreliable is not a controversial opinion. It is well known and easy to find many instances of similar issues.

> code generation

What exactly do you think is generating the code? The article here is about generating code with an LLM.

[rossant]

It's not rare in academia to translate Matlab scientific libraries into Python.

[nerdjon]

Right, I have never been in a situation that a re-write was considered in another language that it was not due to some other reason.

Most of the time it is first, we need to change some major functionality, we have an architectural issue, or something along those lines that will require a major re-write in the first place. So the idea of, maybe we should use a different language comes up.

The idea of re-writing something in another language and it is identical functionality just for the sake of using another language just isn't a normal exercise unless you have a CTO pushing for something unnecessarily.

Maybe, maybe I could buy saying we don't want to manage Java servers anymore or something along those lines. But even then, why break something that works.

This seems like such a bad idea, is going to introduce so many bugs, require a ton of testing, for a minimal at best gain?

And then yeah, who is going to maintain it given that no one actually wrote the code in the first place. Goodby historical knowledge and productivity. Hope you don't find a critical bug as soon as you release it that needs to be fixed asap.

Don't do this, a seriously bad idea. That assumes that it is somehow a 1:1 functionality which by now we should be well aware that an LLM is going to make mistakes.

[john_the_writer]

My friend wrote in Cobol until the day he retired. Every couple years management would spin up a project to replace the Cobol part. He and his team would consult. In the end he would just use the project to set his watch.