Live data from Hacker News

Use boring languages with LLMs

jry.io

151–160 of 180 posts

Re: Use boring languages with LLMs

#151
post #126
post #80

Author here, wasn't expecting this piece of writing to show up on HN. The specifics of Python were chosen only due to the language ecosystem being fragmented and inconsistent while Python remains an essential learning, research, and now ML programming language (it was my first language and I still love it). My thoughts on LLM generated code have changed immensely in the last 9 months as I've taken on teams and projec…

> Languages with a single way to do things benefit the most: Ruby I love ruby - but surely it's closer to Perl and "There's more than one way to do it" - than python which generally strives for "There should be one-- and preferably only one --obvious way to do it."? https://legacy.python.org/dev/peps/pep-0020/

I can assure you that it's not worth your time to have LLMs write non-trivial code in Ruby.

I doubt Python is significantly better.

The problem isn't that there's more than one way to write working code.

It's that there's infinite ways to write working code, and nearly all of them are bad, and any dynamically typed language allows for a lot of type slop that you don't want.

There's a lot more opportunity for LLMs to write terrible working code in Ruby or Python than there is in Rust, for example.

Re: Use boring languages with LLMs

#152
I have tested almost every language and Go is pretty good but for some reason LLMs get paranoid over races and just start spamming locks next thing you know every fucking struct has mutexes and every function has locks lol.

The best language I have seen an LLM use was Kotlin. It actually surprised me how well it wrote the language. I wrote a project in it and I think I didn't have to correct it once. Like I was seriously impressed. I just wish Kotlin had better tooling so I didn't have to use gradle or maven lol.

Re: Use boring languages with LLMs

#153

When you're working on something difficult that requires a model to reason intelligently, lower level and strongly typed languages often outperform on the same problems [0]. We have a few hypotheses about why, with a moderately high correlation between performance and token density of the output program -- i.e. more token dense languages are more difficult for programs to reason about. Most models come up with the le…

Your theory about token density seems reasonable, but your data doesn't seem to really match it.

Very little difference between TypeScript and JavaScript, which are essentially the same language, just one has more tokens.

Functional languages like Clojure and OCaml are pretty dense, I would have expected them to feature lower.

Kotlin is in some ways a more token dense version of Java, yet Kotlin leads, and Java is almost last.

Re: Use boring languages with LLMs

#155
post #126
post #80

Author here, wasn't expecting this piece of writing to show up on HN. The specifics of Python were chosen only due to the language ecosystem being fragmented and inconsistent while Python remains an essential learning, research, and now ML programming language (it was my first language and I still love it). My thoughts on LLM generated code have changed immensely in the last 9 months as I've taken on teams and projec…

> Languages with a single way to do things benefit the most: Ruby I love ruby - but surely it's closer to Perl and "There's more than one way to do it" - than python which generally strives for "There should be one-- and preferably only one --obvious way to do it."? https://legacy.python.org/dev/peps/pep-0020/

My experience has been the exact opposite. Python seems to churn its packaging and tooling at an astonishing rate, whereas Rails forced a centralisation of its ecosystem.

Re: Use boring languages with LLMs

#156
post #126

Earlier quoted context omitted.

> Languages with a single way to do things benefit the most: Ruby I love ruby - but surely it's closer to Perl and "There's more than one way to do it" - than python which generally strives for "There should be one-- and preferably only one --obvious way to do it."? https://legacy.python.org/dev/peps/pep-0020/

In practice, Ruby is much more opinionated than Perl, mostly because of Rails being the catalyst to drive mass adoption of Ruby. So you basically have Rails, and then the RubyGems/Bundler package management was pretty linear. There's no equivalent of python2->python3 schism and the package management churn, and more stylistic continuity since ruby adoption is lower and more concentrated in the 2005-2015 time frame co…

> There's no equivalent of python2->python3 schism and the package management churn

I tried to run a Ruby script recently and got an error about Fixnum. Apparently they made some breaking change to how integer types are referenced in version 3. I had to modify the script to get it to work on a modern parser. How is this not equivalent to the Python 2-3 jump? I don't know the first thing about Ruby but this already told me that it's a language with breaking changes between versions.

(It was the ruby scripts here if anyone is curious: https://github.com/haberman/vtparse/ )

Re: Use boring languages with LLMs

#157

Earlier quoted context omitted.

Memory management annotations are actually quite rare in Rust. It mostly uses plain RAII as seen in C++. You do need to annotate whenever an object may have multiple "owners" extending its lifecycle (which requires refcounting) but that's often directly visible in the problem domain.

& and &mut is all over the code in Rust. &T by far the most common arg type. In the OP article, they mention 'don't need to worry about thread cause the concept does not exist' - well, & does not exist in Python. Those things are related to low-level computational issues (memory management) not problems space issues (moving money, transcoding the file, checking the spreadsheet), so a lot of &/&mut etc. and all that e…

There is a huge semantic difference between sharing an object by providing a reference to it, passing the ownership of the object and passing a copy. It’s not a technical low level detail because the results can differ. Many developers use those distinctions in Rust to encode business rules, not to optimize memory use.

Similarly there is an important semantic difference between something you can change and something you shouldn’t change. Again - this can be used to express business logic constraints, similarly to how you can use static types to enforce other properties like e.g. „age must be a number”.

While you may say you can get away with just sharing references everywhere like Java or JS do, and not care about immutability, that’s like saying the only type you need is string and hashmap and you can code everything. And you just document in comments when strings contain numbers. I saw code like that in PHP once. Fun.

Re: Use boring languages with LLMs

#160
post #80

Author here, wasn't expecting this piece of writing to show up on HN. The specifics of Python were chosen only due to the language ecosystem being fragmented and inconsistent while Python remains an essential learning, research, and now ML programming language (it was my first language and I still love it). My thoughts on LLM generated code have changed immensely in the last 9 months as I've taken on teams and projec…

> Languages with a single way to do things benefit the most: Rust I posit that Rust is the optimal language to emit from LLMs unless you have to target web, a specific platform, or a legacy project: - The required error handling for Option , Result , and required destructuring of sum types naturally reduces errors by an order of magnitude - If it compiles, chances are higher the code is correct. Especially if you're…

>I posit that Rust is the optimal language to emit from LLMs unless you have to target web, a specific platform, or a legacy project:

What would you suggest is optimal for targeting web?

Post reply on HN