[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.