It’s good at matching patterns. If you can frame your problem so that it fits an existing pattern, good for you. It can show you good idiomatic code in small snippets. The more unusual and involved your problem is, the less useful it is. It cannot reason about the abstract moving parts in a way the human brain can.

From what I can tell, LLMs tend to hallucinate more with minor languages than with popular ones. I'm saying this as a Scala dev. I suspect most discussions about the LLM usefulness depend on the language they use. Maybe it's useful for JS devs.

Cursor and Claude Code were the asskicking I needed to finally get on the typescript bandwagon.

Strong typing drastically reduces hallucinations and wtf bugs that slip through code review.

So it’ll probably be the strongly typed languages that receive the proportionally greatest boost in popularity from LLM-assisted coding.

Most people who work in non-mainstream languages are, to some extent, making a statement. They care more about X than mere "popularity". (Sometimes X is money, hence why I still have Anki flashcards in rotation on OCaml, Intersystems Cache and Powershell.)

If they do want "popularity" then the counter-counter-point is that it should be easier to get than ever. Just have one proficient person write a lot of idiomatic, relatively isolatable code, and then have an AI generate terabytes upon terabytes of public domain licensed variations and combinations on that code. If you make programming in the small a breeze, people will flock to your language, and then they can discover how to program in the large with it on their own time.

I’m having a good time with claude and Elm. The correctness seems to help a lot. I mean it still goes wonky some times, but I assume that’s the case with everyone.

I'm not sure, I have a custom config format that combines a CSV schema with processing instructions that I use for bank CSVs and Claude was able to generate a perfect one for a new bank only based on one config plus CSV and the new bank's CSV.

I'm optimistic that most new programming languages will only need a few "real" programmers to write a small amount of example code for the AI training to get started.

More people who are not traditionally programmers are now writing code with AI assistance (great!) but this crowd seems unlikely to pick up Clojure, Haskell, OCaml etc... so I agree this is a development in favor of mainstream languages.

Yes, I worry that we're in for an age of stagnation, where people are hesitant to adopt radically new languages or libraries or frameworks because the models will all be bad at them, and that disadvantage will swamp any benefit you might get from adopting an improved language/library/framework.

Alternatively every new release will have to come with an MCP for its documentation and any other aspects that might make it easier for an LLM to talk about it and use it accurately.

Can confirm, you can do some good vibe coding with JavaScript (or TypeScript) and Claude Code. I once vibe coded a test suite for a complex OAuth token expiry issue while working on someone else's TypeScript code.

Also, I had created a custom Node.js/JavaScript BaaS platform with custom Web Components and wanted to build apps with it, I gave it the documentation as attachment and surprisingly, it was able to modify an existing app to add entire new features. This app had multiple pages and Claude just knew where to make the changes. I was building a kind of marketplace app. One time it implemented the review/rating feature in the wrong place and I told it "This rating feature is meant for buyers to review sellers, not for sellers to review buyers" and it fixed it exactly right.

I think my second experience (plain JavaScript) was much more impressive and was essentially frictionless. I can't remember it making a single major mistake. I think only once it forgot to add the listener to handle the click event to highlight when a star icon was clicked but it fixed it perfectly when I mentioned this. With TypeScript, it sometimes got confused; I had to help it a lot more because I was trying to mock some functions; the fact that the TypeScript source code is separate from the build code created some confusion and it was struggling to grep the codebase at times. Though I guess the code was also more complicated and spread out over more files. My JavaScript web components are intended to be low-code so it's much more succinct.

Recently I wrote a significant amount of zig first time in my life thanks to Claude Code. Is zig a mainstream language yet?

AI seems pretty good at Rust, so I don't know. What sort of obscure languages are we talking about here?

Ehhhh, a year ago I'd have agreed with you — LLMs were noticeably worse with Elixir than with bigger langs.

But I'm not noticing that anymore, at least with Elixir. The gap has closed; Claude 4 and Gemini 2.5 both write it excellently.

Otoh, if you wanted to create an entirely new programming language in 2025, you might be shit outta luck.

Same here. Reading the article, I could not really relate to the experience of being a single-language developer for 10 years.

In my early days, I identified strongly with my chosen programming language, but people way more experienced than me taught me that a programming language is a tool, and that this approach is akin to saying "well, I don't know about those pliers, I am a hammerer."

My personal feeling from working across a wide range of programming languages is that it expands your horizons in a massive way (and hard to qualitatively describe), and I'm happy that I did this.

<< It would have taken "less than a year" with or without AI. They just spent 10 years not trying.

I suppose we can mark this statement as technically true. I can only attest to my experience using o4 for python mini projects ( popular, so lots of functional code to train on ).

The thing I found is that without it, all the interesting little curve balls I encountered likely would have thrown a serious wrench into the process ( yesterday, it was unraid specific way of handling xml vm ). All of sudden, I am not learning how to program, but learning how qemu actually works, but it is a lot more seamless than having to explore it 'on my own'. And that little detour took half a day when all was said and done. There was another little detour at dockers ( again unraid specific isseus ), but all was overcome, because now I had 4o guide me.

It is scary, because it can work and work well ( even when correcting for randomness). FWIW, my first language was basic way back when.

> They just spent 10 years not trying.

Being in the zone of proximal development will do that: https://en.wikipedia.org/wiki/Zone_of_proximal_development

We shouldn't dismiss high friction problems.

I wish but the opposite seems to be coming - Haskell will have less support from coding AIs than mainstream languages.

I think people, who care about FP, should think about what is appealing about coding in natural language and is missing from programming in strongly typed FP languages such as Haskell and Lean. (After all, what attracted me to Haskell compared to Python was that the typechecking is relatively cheap thanks to type inference.)

I believe that natural language in coding has allure because it can express the outcome in fuzzy manner. I can "handwave" certain parts and the machine fills them out. I further believe, to make this work well with formal languages, we will need to use some kind of fuzzy logic, in which we specify the programs. (I particularly favor certain strong logics based on MTL but that aside.) Unfortunately, this line of research seems to have been pretty much abandoned in AI in favor of NNs.

I used a LSP MCP tool for a LLM and was so far a bit underwhelmed. The problem is that LSP is designed for human consumption and LLMs have different constraints.

LLMs don't use the LSP exploratory to learn the API, you just give it to it as a context or MCP tool. LLMs are really good at pattern matching and wont make type errors as long as the type structure and constructs are simple.

If they are not simple it is not said that the LLM can solve and the user understand it.

IMO, Haskell is less helpful for an LLM because of its advanced language features. The LLM is reasoning about the language textually. Since Haskell is very tense, the LLM would need a very strong model of how the language works.

I think languages with more minimal features and really good compile time errors would work well with LLMs. In particular, I've heard multiple people say how good LLMs are at generating Go.

Personally, I like languages with type inference so this wouldn't be my preference.

We might see wider adoption of dependently typed languages like Agda. But limited corpus might become the limiting factor, I’m not sure how knowledge transfers as the languages get more different.

> can be formally verified using well known algos

Is there any large formally verified project written in Haskell? The most well known ones are C (seL4 microkernel) and Coq+OCaml (CompCert verified C compiler).

My experience is that each question I ask or point I make produces an answer that validates my thinking. After two or three iterations in a row in this style I end up distrusting everything.

I'm addition, I frequently tell it to ask clarifying questions. Those often reveal gaps in understanding or just plain misunderstanding that you can then bip in the bud before it has generated a million tokens.

Yeah, I don’t understand how people feel confident with that at all.

Whenever I dive into a programming language I don’t know, I realize the amount of stuff I need to get used to before I feel confident reviewing code in it.

Also supposedly language barriers are smaller than ever, yet WhatsApp is killing its desktop app on Windows in favor of using the Web-based version.

That’s a bash problem, not LLM.

I’ve done similar tools with Go and haven’t had any issues.

One goes through a tree of dirs, finds zip files with images, unzips, benchmarks which image format is the most compact and creates a new zip with that.

Got it right the first go (hehe pun)

I think this is more of a criticism of bash than of Gemini.

Also, I out-of-hand reject any criticism of an AI that specifies only the brand ("ChatGPT") and not the specific model version, settings, etc...

So, for example, Gemini 2.5 Pro (Jan 2025) with temperature 0.15 prompted with: "Write a short, idiomatic bash script that takes a file containing a list of directory names, changes to each one, runs a command, and then returns to the original working directory."

Spits out this:

    #!/bin/bash

    # A script to run a command in a list of directories.

    # Exit if the wrong number of arguments are provided.
    if [[ $# -lt 2 ]]; then
      echo "Usage: $0 <file_with_dirs> <command> [args...]" >&2
      exit 1
    fi

    DIR_FILE="$1"
    shift # The rest of the arguments ("$@") are now the command.

    # Ensure the directory list file exists and is readable.
    if [[ ! -r "$DIR_FILE" ]]; then
      echo "Error: Cannot read file '$DIR_FILE'" >&2
      exit 1
    fi

    # Read the file line by line.
    while IFS= read -r dir; do
      # Skip empty lines or non-existent directories.
      if [[ -n "$dir" && -d "$dir" ]]; then
        echo "==> Entering '$dir'..."
        # Run command in a subshell to keep the 'cd' local.
        # '&&' ensures the command only runs if 'cd' succeeds.
        (cd "$dir" && "$@")
        echo "<== Finished with '$dir'."
      else
        echo "--> Skipping invalid directory: '$dir'" >&2
      fi
    done < "$DIR_FILE"

    echo "All done."

Something that I found amusing, and again, is a criticism of bash instead of the AI, is that this fails to process the last line if it isn't terminated with a \n character.

PS: This is almost a one-liner in PowerShell, and works with or without the final terminator character:

    Push-Location
    Get-Content dirs.txt | cd -PassThru | Foreach-Object { echo "Hello from: $pwd" }
    Pop-Location

    pushd;gc dirs.txt|%{cd $_;"Hello from: $pwd"};popd

Wish I could go back to a time when I believed stuff like this

I've seen plenty struggle.

They don't struggle to write code, but they struggle to write idiomatic code.

An experienced programmer from a different language introduced to another will write lots of code that works, but in a style idiomatic to their favoured language, be that C, C++, rust, python, etc.

Every language has its quirks, and mastery is less about being able to write a for loop or any given algorithm in any given language, but more about knowing which things you should write, and which things you should be using the standard libraries for.

I've literally seen C# consultants waste time writing their favourite .NET LINQ methods into a javascript library, so they can .Select(), .Where(), etc, rather than using .filter, .map, etc.

Likewise I've seen people coming from C struggle to be as productive as they ought to be in C#, because they'd rather write a bunch of static methods with loops than get to grips with LINQ.

Fully understanding a runtime (or compiler behaviour for AOT languages) and what is or isn't in standard libraries isn't something that can be mastered in a few hours.

Bash might not be difficult, but it is very annoying, so I'm happy that the AI edits my scripts for me.

LLMs learn and apply pattern. You can always give some source code examples and language docs as context and it will apply those adapted patterns to the new language.

Context windows are pretty large (Gemini 2.5 pro with 1 mill tokens (~ 750k words the largest) so it does not really matter.

It just needs to be better than the human would be and less effort. It does not need to be great.

Let me just say this way.

AI is a much better, so in some case worse, language lawyer than humans could ever be.

Will Smith asks, "Can a robot write a Vulkan app?"

The robot responds, "Can you?"

See if you have same thoughts after 1 years

I would expect anyone to get proficient in Swift after 10 months of using it, with or without AI...

If AI had really a multiplying factor here, I'd expect you to BE an expert.

how'd you get your code review automated?

> Can you though?

Take a look at this Haskell program that LLM wrote. I do not write Haskell, but I can review the code just fine to say that this is doing what I want.

  -- Simple multiplication function
  multiply :: Num a => a -> a -> a
  multiply x y = x * y

  -- Main function for running the program
  main :: IO ()
  main = do
      putStrLn "Enter the first number:"
      input1 <- getLine
      putStrLn "Enter the second number:"
      input2 <- getLine
      
      let num1 = read input1 :: Double
      let num2 = read input2 :: Double
      let result = multiply num1 num2
      
      putStrLn $ "Result: " ++ show num1 ++ " * " ++ show num2 ++ " = " ++ show result

It really is an NP problem, come to think of it.

Yet WhatsApp is killing its Windows desktop app in favor of the web-based version.