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.
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.
I encounter that regularly, as I often use aviation analogies to guide me in programming. D's design has been significantly influenced by my aerospace experiences.
That being said, I myself do prefer types over tests. I just don't know of a better analogy...
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.
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.
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.
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.
> C++
I'm a bit confused here.
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.
Indeed, everybody knows they have just one type (:
https://www.google.com/search?q=%22dynamic%22+programming+la...
https://cs.stackexchange.com/questions/63533/untyped-vs-unit...
https://semantic-domain.blogspot.com/2022/01/static-typing-v...
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.
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/