Hacker News Reader

Comment by depletedgherkin | Hacker News Reader

Bit of an aside, but I wonder if the rise of LLMs will lead to new programming languages being much slower to be adopted.

Like you said, you might have given up on F# without ChatGPT assistance, and the main way ChatGPT is able to help with F# is because of all of the example code it's been trained on. If developers rely more and more on LLM aid, then a new language without strong LLM support might be a dealbreaker to widespread adoption. They'll only have enough data once enough hobbyists have published a lot of open-source code using the language.

On the other hand, this could also leading to slowing adoption of new frontend frameworks, which could be a plus, since a lot of people don't like how fast-moving that field can be.

View on HN

I heard somewhere that ChatGPT is surprisingly good for human language translations even though it's not specifically trained for it. There seems to be just enough examples of e.g. Japanese that Japanese researchers use it to translate papers. I suspect that's largely true for programming languages too. I've had great success working with it in Clojure, even though there's relatively little published code compared to more popular languages.

ChatGPT is pretty good for translations of Japanese into English. It’s English to Japanese translation tend to sound somewhat stiff/formal/machine-generated, although it’s less prone to hallucinations than DeepL for larger texts. I expect this is because it was trained on a much larger corpus of English language texts than Japanese ones, which means the problem is not intractable.

Wouldn't you just need to publish a Rosetta stone type translation for it to be able to digest the new language fully? e.g. here is how you do this in python and here is how you do it in this new language

The crazy thing that a lot of people don’t realize is that all of that data generalizes to anything new you can throw at it. As long as there’s enough space in the prompt to provide documentation it can do it on the fly but you could also fine tune the model on the new info.

Which is what Phind tries (and mostly succeeds) in doing. LLM + Search Engine is way smarter than just LLM.

It could go the other way. LLMs might make porting code from one language to another easier which would speed the adoption of newer and more niche languages. And the future of documentation and tutorials might be fine-tuning an LLM.

I've also wondered this - including if we might see a breed of 'higher level' languages (i.e. much higher level than Python) which can then be 'AI compiled' into highly efficient low level code.

i.e. the advantages of an even-higher-level python that's almost like pseudo-code with assembly-level speed and rust-level safety, where some complexity can be abstracted out to the LLM.

I disagree. Chatgpt is helpful here because f# is a paradigm shift for this otherwise experienced programmer. The programmer probably knows juuussstt enough f# to guide the llm.

I mean why is f# the goal, and could we write a better f# with the use of AI.

As an example, why not write in f# and let an 'AI-compiler' optimise the code...

The AI-compiler could then make sure all the code is type safe, add in manual memory management to avoid the pitfalls of garbage collection, add memory safety etc - all the hard bits.

And then if we gave the AI-compiler those sort of responsibilities, then we can think about how this would impact language design in the longer term.

None of this is with current generation LLM's, but might be where we end up.

This doesn’t require AI, it requires higher-level languages than we have that can express intent more directly.

In current generation language there is definitely a trade-off between language productivity (i.e. speed of writing) and features such as speed and memory-safety.

So far we haven't been able to close this gap fully with current compilers and interpreters (i.e. python still runs slower than C).

It seems like that gap could be closed through, for example, automated refactoring into a rust-like language during compilation, or directly into more-efficient byte-code/ASM that behaves identically.

And surely if that is a possibility, that would affect language design (e.g. if you can abstract away some complexity around things like memory management).

Reply on news.ycombinator.com