I don't really agree with this. Having strong types and guardrails like in Haskell, Rust or OCaml helps _massively_ with LLMs because they get very clear messages back, and can express their logic using semantic types they can easily follow. Conversely, I've noticed that AIs (just like humans) tend to kind of lose the thread with very dynamic code

▲

nylonstrung 2 hours ago | parent | next [-]

I've found the same: strong types are disproportionately valuable in LLM coding vs human coding because they essentially function as context and the typechecker actively enforces correctness

▲

WalterBright an hour ago | parent | next [-]

In aviation, there is the notion of "dual path", which means two ways to do anything. Each functions as a backup to the other.

The best dual path systems are when they use different technology. Hence, an error in one is highly unlikely to infect the other.

This is what static typing provides.

	▲	ozim an hour ago \| parent \| next [-]
		I guess people who are against static typing are not working on aviation type projects - more like worst thing that can happen on what they work is a div slightly off.
	▲	jessekv 44 minutes ago \| parent \| prev [-]
		I like this analogy. Another one I have used is double-entry bookkeeping.

▲

groestl 2 hours ago | parent | prev | next [-]

It's basically a myriad of unit tests without writing them down (in full).

▲

georgemcbay an hour ago | parent | prev | next [-]

> strong types are disproportionately valuable in LLM coding vs human coding because they essentially function as context and the typechecker actively enforces correctness

One could argue that this was a large benefit for human coding long before LLMs became useful.

It is why I always preferred strongly-typed languages.

And once we had practical strongly-typed languages with implicit type inference I really couldn't wrap my head around why anyone would prefer dynamic typing other than just inertia due to that being what they were used to.

▲

IshKebab an hour ago | parent | prev [-]

I wouldn't say it's disproportionate. Strong static typing is massively valuable for humans too. Maybe it's just more obvious to some people because you actually can write the same large program twice using the same "person" and a different language.

Previously studies into the benefits of static typing for humans were always a bit flawed because you can't do that with people. And tbh I don't know why but there are a surprising number of people that don't appreciate static typing. My guess is a combination of ego and laziness, which doesn't apply to LLMs.

▲

sroerick an hour ago | parent | prev | next [-]

OCaml core + interpreted Lisp on top really feels like total enlightment, I have to say.

The dynamic features you get with a full blown REPL are, in some specific cases, worth the trade off you get by losing the guardrails (which I call Rubber Baby Buggy Bumpers).

You're right though - strong typing feels like a cheat code.

▲

pseudony an hour ago | parent | prev | next [-]

And I think this point is a poor as any made in the article.

Last I attempted to write some smaller ocaml project I used LLMs for support (but wrote myself). They generally weren’t excellent.

Honestly, types don’t help as much as people want them to. The LLM does best on popular languages, especially those whose use and feel is also mainstream.

That is to say, pick a niche language like Odin, and it may incorrectly start to over-apply Go’isms - knowledge from one language bleeds into how it approaches others.

▲

unprovable an hour ago | parent | prev | next [-]

Absolutely this. Plus, LLMs are surprisingly adept (in my experience) at handling gnarly syntactic corners of most widespread strongly typed languages, esp. C++ and Rust.

	▲	copperx 40 minutes ago \| parent [-]
		> strongly typed languages > C++ I'm a bit confused here.

▲

xlii an hour ago | parent | prev | next [-]

And there is a super power to it.

It's possible to write the whole system only by defining the types.

The "glue" can be sloppy but as long as it keeps on the edges the output is most often fine.

Recently I'm on the fence about Rust vs OCaml (but plan to write about it soon) because I have ~700k LoC in Rust but my workflow starts to get seriously dragged down by compilation/tests in isolated worktrees.

I recently also dab with Gluon (as embeddable type safe scripting) and rule-based-development for maximum code control/agents output leverage.

	▲	sroerick an hour ago \| parent [-]
		OCaml is really good.

▲

sheepscreek an hour ago | parent | prev | next [-]

Yes! Maybe the current limitation is due to their limited context and frequent compaction. Where they can lose track of (abc-xyz A B) and what A and B need to be.

I’m not sure if the Common Lisp compiler can be very helpful either, since it’s a dynamic language and A and B could be many different types (duck typing).

Strong types are the way to go, at least for now.

	▲	Jach an hour ago \| parent [-]
		CL is strongly typed. It is quite refreshing to not have to worry about implicit type conversion (or worse) all over the place, unlike some other languages... Type declarations are also optional and compilers can create compile-time warnings about them. Thus for many trivial cases, when using SBCL some obviously wrong types, or typos, or miscounted arguments, can be caught ahead of time without having to execute code. CL is also not duck typed. If abc-xyz is a generic function, selecting which method to call relies on the actual class hierarchies of the given A and B objects, there's no "duck shape" shenanigans. For static types, well, CL is flexible enough to bolt such a system on top as a library, where you'll have a full ML/Haskell style type system. https://coalton-lang.github.io/ But it seems the relevance for LLMs is rather mixed, much like studies from the last few decades on static/dynamic typing in general: https://danluu.com/pl-tokens/

▲

brabel an hour ago | parent | prev [-]

What the heck this thread is about, Common Lisp has types and you can use them in ways most strongly typed languages wouldn’t let you! They are basically expressions, which gives a lot of flexibility. It may not be always checked statically, but in practice SBCL does a great job at doing it or at least emitting warnings when it can’t prove the code will fail at runtime.

Also if you really want Haskell types you can use Coalton, which is essentially Common Lisp with Haskell types, but lets you interop with Common Lisp seamlessly as Kotlin with Java.