Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use boring languages with LLMs

jry.io

Post reply on HN
Print view View original

131–140 of 180 posts

Re: Use boring languages with LLMs

#131

Post by iLemming »

thenobsta wrote: post #122
iLemming wrote: post #116

Earlier quoted context omitted.

I bet you have not tested it with live Clojure REPL. When you give the LLM living, breathing REPL, it stops guessing and starts empirically analyzing current state of things and produces working solution faster, costing far less tokens. This article doesn't seem to mention it either https://martinalderson.com/posts/which-programming-languages... even though states Clojure to be the most token efficient. I personally,…

I would looove to see an analysis of this.

I can only share my empirical anecdata - I deal with code in different languages daily. Lisps have little difference when using with LLM just like any other compile&run language. But when you hook them up to a live Lisp REPL (which I admit requires some work) - it all gets very interesting.

Re: Use boring languages with LLMs

#132

Post by cpard »

* Large language models amplify inconsistent technology and quietly reinforce consistent ones. *

This is another way of saying that the tools you equip the LLM affect their effectiveness, in other words, the harness you build around them matters and matters a lot.

At the end of the day, the language you pick, enriches the harness with the toolchain, libraries etc. it offers. This is most evident with the toolchain as the author mentioned but if you think about it, picking a specific framework that constraints the choices the model can make (e.g. the Ruby on Rails example) is also affecting the behavior it has.

Re: Use boring languages with LLMs

#133

Post by iLemming »

jaggederest wrote: post #123
iLemming wrote: post #116

Earlier quoted context omitted.

I bet you have not tested it with live Clojure REPL. When you give the LLM living, breathing REPL, it stops guessing and starts empirically analyzing current state of things and produces working solution faster, costing far less tokens. This article doesn't seem to mention it either https://martinalderson.com/posts/which-programming-languages... even though states Clojure to be the most token efficient. I personally,…

This is really cool, it's one of my goals. I think LLM programming is essentially simulated annealing and the more you can do to constrain the problem space, the better. I wonder how LLMs would do with something like an image based system - it seems like you could pin the image and get a perfectly reproduced environment to get the LLM to make changes to, each time.

We have a few backend services written in Clojure. We expose nrepl ports in our testing SDE k8s clusters. Our UI is all in Typescript, but I use nbb with Playwright - that gives me another REPL. LLM can poke through things in the UI REPL, while simultaneously running subagents that monitor situation in the cluster and then can dynamically change backend behavior. This all happens dynamically, without recompiling anything, without restarting, re-deploying, even saving the code (until it works), without losing the state.

Re: Use boring languages with LLMs

#134

Post by dasil003 »

e12e wrote: post #126
jryio wrote: 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/

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 compared to python which had greater diversity of adoption and use cases both before and after the Web 2.0 era. I do feel pythons explicit imports and cultural aversion to meta programming win it some points. Overall though it kind of feels like a wash and I still choose the language based on the some criteria I would have used before agentic coding--claude does fine with either.

Re: Use boring languages with LLMs

#135

Post by e12e »

iLemming wrote: post #129
e12e wrote: post #128

Earlier quoted context omitted.

Curious what that would look like - and if javascript, ruby would benefit equally? How do you work with LLM and repl?

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, I was more curious about how you mix repl, clojure and LLMs in practice?

Re: Use boring languages with LLMs

#136

Post by e12e »

e12e wrote: post #128
iLemming wrote: post #116

Earlier quoted context omitted.

I bet you have not tested it with live Clojure REPL. When you give the LLM living, breathing REPL, it stops guessing and starts empirically analyzing current state of things and produces working solution faster, costing far less tokens. This article doesn't seem to mention it either https://martinalderson.com/posts/which-programming-languages... even though states Clojure to be the most token efficient. I personally,…

Curious what that would look like - and if javascript, ruby would benefit equally? How do you work with LLM and repl?

On a side note, for other helix users, I found two approaches to improve repl interaction from helix:

https://github.com/a3lem/replink

https://github.com/waddie/nrepl.hx

Re: Use boring languages with LLMs

#137

Post by MattRogish »

dasil003 wrote: post #134
e12e wrote: 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…

Yes! It reminds me of the tabs vs spaces argument. Yeah, you have your preference, but as long as everyone on your team uses the same convention it doesn’t matter

The Rails apps I’ve programmed with LLMs seem to work a LOT better than arbitrary python or ruby or JavaScript apps. I chalk that up to “there are a gazillion examples of omiauth in Rails that the LLM can’t really stray off the path. It just works.”

That means I let the agent do things the way it wants to, not because I have a preference. So we’re using turbo and Hotwire and whatever it is it’s doing. And I’m using React for some other problems. Not because I know React, but because the LLM does.

In golf it is said to “let the club do the work”. Over control leads to disaster. Same with LLMs. Not saying let it do whatever but if there are widely baked in conventions you’ll be far better off letting those do the work.

Re: Use boring languages with LLMs

#138

Post by dr_kretyn »

I'm developing a terminal agent (https://GitHub.com/laszukdawid/trrminal-agent) in golang and can't say that it's easier or less error prone to write it in golang vs Python or JS. There's still plenty of bad ideas and bad code being suggested by Claude Code / Codex so it's still hands on work. However, testing is much easier and it makes me think more about the arch more than with Python.

Re: Use boring languages with LLMs

#140

Post by thijsvandien »

fmxexpress wrote: post #119
trees101 wrote: post #117

Anyone use this stuff with Delphi? I've been looking for tips for getting the best out agents for Delphi

I use it with Delphi. Claude Code with Opus 4.7 works fine. It can use FPC in Delphi mode so that it can test itself. I'm doing greenfield and not an old project though.

Care to share your specific setup/workflow? I'd be interested.
Post reply on HN