Depends on the effect, no? Eg imagine that you're implementing an infrastructure-as-code tool like Terraform. And it has to execute a 'plan' to delete a cloud database and then some networking infrastructure for the database. But it has to do them in a single transaction. So if the second delete fails it has to roll back the database deletion. Is that doable? I don't think so...

That's a good example of a feature hard to retrofit elsewhere.

Do you know of any non-trivial production codebases relying on STM in a load-bearing way?

However, I think it's not controversial to say that in the presence of unmanaged effects, the complexity of understanding any given function is O(n)

What do you mean by this? Are you saying that when someone tries to understand a function in an imperative language codebase, they have to go look at the full call graph but that's not the case for purely functional languages?

I think it's quite uncontroversial to say that if the type system is powerful enough you only need to read the function definition to understand what a function does? Ergo, in order for an LLM to update a function it only needs to load the definition into its context.

There's a big difference between this statement and the one you're quoting "Unsubstantiated claim that AI tools benefit more from local reasoning."

In particular:

1. LLMs do not necessarily do the minimal thing they theoretically need to do.
2. In practice, there are multiple orders of magnitude more code for more mainstream languages.

Your comparison is essentially stating "everything else being equal, local reasoning is better" and sure, that may be the case, but in practice, "everything else being equal" does not hold.

So the claim as to whether LLM performance is better on purely functional languages needs to be tested against reality. As one data point, I've worked at one company building AI dev tools, and we've seen much better performance on mainstream and simpler languages like TypeScript, Go and Python compared to more niche languages.

We don't need such guarantees when writing code for ourselves, but it's important when dealing with user-supplied code.

In my own experience, knowing what code cannot do without having to read the implementation is a very nice property to have, especially when dealing with third party code.

I think nixpkgs/nix expressions are a very good answer to this question. Nixpkgs wouldn't be impossible in a non functional language, but it would be magnitudes harder and make little sense. This is why the "impossible" bar isn't relevant.

If something would be significantly easier and more maintainable in a certain paradigm, you should probably use that paradigm.

pure functional language is much easier to audit for supply-chain attacks since the attack area is vastly reduced.

Are you basing this based on practical experience of auditing codebases or based on theory? Because Haskell code can definitely do this via unsafePerformIO or FFI. Cabal can also run code at build time.

Also since functions are never redefined or removed, you can do more optimizations to reduce the asset size of the dependencies you pull in. This is quite a big win for web development

In practice, if you look at bundle sizes, there are several JS/TS frameworks with sizes competitive to that of Elm. Additionally, in Wasm usage, the size of the language runtime that needs to be shipped adds substantially to the bundle size, so much so that uptake of Wasm outside of systems languages like C++ and Rust seems to be relatively low.

Uh, can I have an example? Since from what I understand your comment is essentially saying "imperative programs are more complex because their execution becomes nonlinear the moment you have one of if, for, return, and friends."

If that's true, I don't think I can agree with you because:

First of all, there are equivalents to these constructs in FP land, such as the venerable case. Ah, but you might say, many times we want to avoid using case by using a combinator or typeclass, which indeed is often idiomatic. But it's like even less clear to trace execution then.

Which makes the execution path more explicit?

if my_map.contains(x) {
    my_map.get(x)
} else {
    my_map.insert(x, value);
    value
}

vs

my_map
    .entry(x)
    .or_insert(value)

(You can still argue the latter is easier to understand, but that would be because it is less about describing how to get there and more about describing what the final state will look like)

Early returns and the like can be achieved using e.g. the exception monad (or Rust's equivalent ?), and loops can be replaced by folds or maps. Outside of goto I have a hard time thinking of something without a direct analogue.

But perhaps more importantly, a major point of a functional language is describing what and not how, and in this regard execution is often (deliberately?) obscured. Enter laziness, everyone's favorite footgun in Haskell.

I mean seriously, even the small and cute example of

fibs = 0 : scanl (+) 1 fibs

is extremely confusing to the uninitiated (ask me how I know).

Or how about https://chrisdone.com/posts/twitter-problem-loeb/#time-travelling-solution ?

I think both of these programs are awesome by the way. But if I had to tell you the order of execution for the latter it would just be a guess.

Rather than a third item, I think “user-programmable control flow” is a better name for my first item. First-class functions are the tamest form of user-programmable control flow, which I is why I called them “least harmful”.

I can't agree that user-programmable control flow makes the execution path “linear”, though. Any nontrivial algorithm has to have jumps somewhere; the only real question is how crazy such jumps can be. And, with user-programmble control flow, the answer is “very crazy”.

Moving past superficial aesthetic preferences (e.g., if/switch vs patern matching, for/while vs. tail recursion, etc.), the only meaningful algorithmic difference is between static jumps (i.e., into a constant address/label) and dynamic jumps (i.e., into an address passed around as a runtime datum):

• The usual selection and repetition constructs only involve static jumps.
• Calling an ordinary function is a static jump, but calling a virtual method or a function pointer is a dynamic jump. In either case, returning to the caller is a dynamic jump.
• Forcing a lazy suspension is a dynamic jump.
• Handling effects is a dynamic jump.
• And so on.

The mathematical techniques for analyzing programs with only static jumps (Hoare logic, Dijkstra's predicate transformer semantics, etc.) have been more or less well understood since the 60's. But analyzing dynamic jumps is a more delicate issue, because you need to track the possible addresses to which the control may jump. In general, you need to look at the whole program at once, which obviously doesn't scale.

Almost every language feature that enables user-programmable control flow relies on dynamic jumps. The only exception I can think of are macros. But macros have other complications, e.g., it's hard to check, at the definition site, that a macro will always generate well-typed code. (Essentially the same issue as C++ templates.)