I would never use an LLM for trying to generate a full solution to a complex problem. That's not what they're good at. What LLMs are good at and their main value I'd argue, is nudging you along and removing the need to implement things that "just take time". Like some days back I needed to construct a string with some information for a log entry, and the LLM that we have suggested a solution that was both elegant and…
I was still learning Java at uni (while being a Python/Lisp fanboy) when I realised this:
- Complex and wordy languages need tooling (like autocomplete, autoformatting) to handle the tedious parts.
- Simple and expressive languages can get away with coding in notepad.exe.
- Lisp, as simple and powerful as it is, needs brace highlighting. You. Simply. Just. Can't.
Now 10, 20 years later you can look back at the evolution of many of these languages; some trends I've observed:
- Java, C#, C++, have all borrowed a lot from functional languages.
- JVM has Clojure.
- Go stubbornly insists on "if err != nil" - which isn't even the worst part; the following fmt.Errorf is.
- Rust (post-1.0) cautiously moved towards "?"; Zig (still pre-1.0) also has specific syntax for errors.
- Python is slowly getting more verbose, mostly because of type annotations.
- Autoformatters are actually great, you don't even have to care about indenting code as you spit it out, but... Python, being whitespace-sensitive, makes them a bit less useful.
Good tooling helps you with wordy languages. Expressive languages help you write concise code. Code is read much more often than it's written. Deterministic tooling can work with the structure of the code, but LMs (being probabilistic) can help you work with its intent. Language models are an evolution of automated tooling - they will get better, just like autocomplete got better; but they will never "solve" coding.
In my opinion, there's no truth here, only opinions.