AI coding agents are removing programming language barriers

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.

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 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.

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.

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.

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.

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.

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.

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).

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.

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)

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

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

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

The robot responds, "Can you?"

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

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.