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

121–130 of 180 posts

Re: Use boring languages with LLMs

#121

Post by mamidon »

iLemming wrote: post #116
christophilus wrote: post #111

Earlier quoted context omitted.

I ran a little test with Go, TypeScript, Clojure, F#, Haskell, and Rust. Token count was roughly in the same ballpark, but it used the fewest for TypeScript, then Go. The rest required a bit more. Clojure always won in terms of lines of code though, generally coming in at 1/2 the size of the Go or Typescript solutions.

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,…

That's ... an interesting observation. I've found that LLMs work great when they can check their work and have a clear notion of what correct looks like. e.g. a good test suite they can rely on.

I'm sure a REPL helps out with this sort of thing quite a bit!

Re: Use boring languages with LLMs

#122

Post by thenobsta »

iLemming wrote: post #116
christophilus wrote: post #111

Earlier quoted context omitted.

I ran a little test with Go, TypeScript, Clojure, F#, Haskell, and Rust. Token count was roughly in the same ballpark, but it used the fewest for TypeScript, then Go. The rest required a bit more. Clojure always won in terms of lines of code though, generally coming in at 1/2 the size of the Go or Typescript solutions.

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.

Re: Use boring languages with LLMs

#123

Post by jaggederest »

iLemming wrote: post #116
christophilus wrote: post #111

Earlier quoted context omitted.

I ran a little test with Go, TypeScript, Clojure, F#, Haskell, and Rust. Token count was roughly in the same ballpark, but it used the fewest for TypeScript, then Go. The rest required a bit more. Clojure always won in terms of lines of code though, generally coming in at 1/2 the size of the Go or Typescript solutions.

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.

Re: Use boring languages with LLMs

#124

Post by cpursley »

tern wrote: post #118
cpursley wrote: post #41

Earlier quoted context omitted.

Here’s some of the reasons it’s so good with Elixir: https://dashbit.co/blog/why-elixir-best-language-for-ai

My intuitions for using Elixir: - Durable, 'enterprise grade' software patterns are baked into the runtime and into common, stable libraries that everyone uses - You can use Ash, which pretty much entirely solves architectural considerations for many types of backends - The tooling for inspecting and enforcing style (tidewave, credo, dialyzer, Dan's "vibe" ecosystem tools) is far beyond what I see in other ecosystems…

Is ex_slop one of Dans? That one is great. Been looking for an equivalent in Swift.

Re: Use boring languages with LLMs

#125

Post by christophilus »

iLemming wrote: post #116
christophilus wrote: post #111

Earlier quoted context omitted.

I ran a little test with Go, TypeScript, Clojure, F#, Haskell, and Rust. Token count was roughly in the same ballpark, but it used the fewest for TypeScript, then Go. The rest required a bit more. Clojure always won in terms of lines of code though, generally coming in at 1/2 the size of the Go or Typescript solutions.

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,…

No, I didn’t. It occurred to me that I should, but I ran out of time. It’s been a hot minute since I last wrote Clojure, but it was by far my favorite codebase to read out of this experiment. It’s a great language.

Re: Use boring languages with LLMs

#126

Post by e12e »

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/

Re: Use boring languages with LLMs

#127

Post by iLemming »

mamidon wrote: post #121
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,…

That's ... an interesting observation. I've found that LLMs work great when they can check their work and have a clear notion of what correct looks like. e.g. a good test suite they can rely on. I'm sure a REPL helps out with this sort of thing quite a bit!

Yeah, most kids have no idea what it is like. Here's my longer comment further down in the thread. https://news.ycombinator.com/item?id=48287062

Re: Use boring languages with LLMs

#128

Post by e12e »

iLemming wrote: post #116
christophilus wrote: post #111

Earlier quoted context omitted.

I ran a little test with Go, TypeScript, Clojure, F#, Haskell, and Rust. Token count was roughly in the same ballpark, but it used the fewest for TypeScript, then Go. The rest required a bit more. Clojure always won in terms of lines of code though, generally coming in at 1/2 the size of the Go or Typescript solutions.

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?

Re: Use boring languages with LLMs

#129

Post by iLemming »

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?

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.
Post reply on HN