Live data from Hacker News

Use boring languages with LLMs

jry.io

141–150 of 180 posts

Re: Use boring languages with LLMs

#141
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…

Swift is something that works very well if you enforce Swift 6 + good architecture and doesn’t work very well and ends up with slop if you don’t.

Usually once the project is already established and has good patterns, both Claude and GPT will continue the good patterns, but you may still want to add a review pass step to remove bad practices (usually hacks around concurrency instead of doing it properly).

Re: Use boring languages with LLMs

#143
Though I dont know GO, but reading your post - really have me thinking that okayy this is a cool and easy language too

But as someone who is working in python since ages - I guess it is pretty much easy too, and as not as hard as you described. LOL, but whatever, your this post was really amazing

Re: Use boring languages with LLMs

#144
post #135

Earlier quoted context omitted.

When I say REPL, I specifically mean "Lisp REPL". Every step in Read.Eval.Print.Loop slightly differs in homoiconic languages like Clojure, CL, Fennel, Elisp, etc. Javascript and Ruby in that sense can only "benefit" if they have a homoiconic language on top - e.g. Clojurescript.

How so? I don't think anyone would consider Smalltalk to be homoiconic? But would consider it to support a repl-like development process? Smalltalk has system images - which AFAIK clojure lacks (as does python, ruby). I wonder if it would be possible to pair python ZODB with storing python code alongside the pickled objects... And effectively create an unholy image-like workflow with IPython and ZODB? But at any rate…

[dead]

Re: Use boring languages with LLMs

#145
post #93

Earlier quoted context omitted.

I love REPL-driven development, and exploratory "programming" via small snippets is likely part of the endgame (the more the agent strays outside its comfort zone, the more it's needed). It also looks like it paradoxically saves context, since piling up many small snippets is still better than trying to fix a one-shot gone horribly wrong. And yeah, if Clojure had a better static safety story, it would actually rank h…

It sounds almost squarely written by someone without practical experience of REPL-driven development. Specifically with Lisp REPLs. Sure, other languages also have REPLs, but if you dig just a bit deeper, you'd learn that every single step there in R[ead] E[val] P[rint] L[oop] has differences. That makes the entire holistic experience of using the language drastically different. Not universally better for every domai…

> Static types are, in a real sense, a compensation for the gap I just described - the gap between the description and the running thing. When you can't easily inspect or reshape the live system, you want the compiler to tell you as much as possible before you cross that gap.

I think this underrates static typing. For me the biggest value add of a static type system is that while doing a big, breaking-change refactor, I can near-instantly see all the places I need to update callers. Getting the code to work in the place I was actually working on is easy, I was already focused there. Static types pay off by helping me know when my change broke other parts of the system I wasn't even thinking about.

Re: Use boring languages with LLMs

#146
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 using strong typing.

- The training data for Rust is likely of a higher quality than, say, Javascript

- The resulting code is fast and portable

- You get really nice threading and async, and you don't have to think about the silly "color problem" because the LLM handles it for you.

- Using an LLM takes away any trouble you'd have with the borrow checker or refactoring, or otherwise working in a slightly more difficult language.

- Applications are single binary executables.

Since LLMs let you generate and manipulate Rust code as fast as you would Python, why not just emit Rust instead? It's the least brittle language, and it's incredibly performant.

Re: Use boring languages with LLMs

#147

Earlier quoted context omitted.

It sounds almost squarely written by someone without practical experience of REPL-driven development. Specifically with Lisp REPLs. Sure, other languages also have REPLs, but if you dig just a bit deeper, you'd learn that every single step there in R[ead] E[val] P[rint] L[oop] has differences. That makes the entire holistic experience of using the language drastically different. Not universally better for every domai…

> Static types are, in a real sense, a compensation for the gap I just described - the gap between the description and the running thing. When you can't easily inspect or reshape the live system, you want the compiler to tell you as much as possible before you cross that gap. I think this underrates static typing. For me the biggest value add of a static type system is that while doing a big, breaking-change refactor…

I'm not underrating static typing and I'm not saying static types have no value for refactoring - they absolutely do. But the "I can't refactor safely without types" argument tends to assume a codebase structured the way typed codebases are structured. Idiomatic Clojure has a different shape, and the refactor pain you're describing almost never materializes.

What the static typing camp can't acknowledge is that not all dynamically typed languages are equal. I agree with your sentiment e.g., on Python codebases - it's legit pain, but PLs like Clojure and Elixir are a different story.

Data-orientation flattens the call graph. Most Clojure functions take and return plain maps/vectors/seqs. A "breaking change" to a data shape doesn't ripple through type signatures across the codebase the way it does when every layer has its own nominal type. You change the shape at the edges (parsing, validation via Spec/Malli) and most intermediate code keeps working.

Fewer, more general functions. map, filter, reduce, get-in, update, etc. replace dozens of bespoke typed methods. There's just less surface area to break. But then again, I would say `(map)`, and someone familiar with Javascript's `map()` would have some wrong assumptions.

You really just can't evaluate ANY language by picking a single aspect of it without wholly understanding the holistic picture in practical, battleground scenarios. Yes, Clojure is dynamic, but it doesn't mean it's harder to maintain or to more difficult to build with, or you just can't write robust software in it. It genuinely has qualities that shine in some domains.

My claim wasn't "static types are useless for refactoring" - it was that they're a compensation for the gap between description and running system. Your refactor scenario fits that exactly: you need the compiler to tell you about distant breakage because you can't cheaply ask the live system "who calls this, and does it still make sense?"

In a live image, that question is answerable directly. find-usages, instrument the function, exercise the path, watch what flows through. The "places I wasn't thinking about" announce themselves the moment they're touched, with real data in hand - not as a list of locations I now have to go read and reason about cold.

Re: Use boring languages with LLMs

#148
Just want to throw the other Google language into the ring. While I would say Dart has a few more fancy language features than Go, it has an extremely strong and modern cli tool, which is a one stop shop for all your formatting, linking, and project building needs. It even grades how well your project is constructed before you publish it to pub.dev

Re: Use boring languages with LLMs

#149
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…

Correct, even though Ruby the language exists and predates Rails. What -- 80%+ of all Ruby code is Rails? Effectively the largest consumer and producer of the language which I think is a net benefit to your point.

Correct in that Ruby never had a schism and is still massively productive and wideley deployed (e.g. Shopify + Stripe alone represent billions/trillions of dollars through Ruby hotpaths).

Python's general lack of success in this domain is telling and embodies whats I was trying to communicate in the article -- languages with low entropy in syntax, features, ecosystem, and toolchain compound slowly.

Re: Use boring languages with LLMs

#150
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…

It's displayed in my practice that LLMs master Rust even as weaker models like deepseek.
Post reply on HN