>Pretty disappointing article. All the arguments are pretty weak. For example, the article argues that FP is necessary going forward because immutable data helps avoid race conditions. However, immutable data does not make a programming language functional. I could just use Rust, which (although it incorporates functional constructs) is still clearly imperative, and avoid race conditions through its particular implementation of immutable data structures.

Which is neither here, not there.

Rust is like the 1/10000th of what's going on in the programming world.

Just because this new language, not even widely adopted yet, offers some way to tame certain race conditions doesn't mean the general argument in favor of FP is moot.

For one, the implementation of "immutable data structures" in Rust, as well as other parts of Rust, was inspired by FP concepts itself. So whether one goes for pure FP or uses some of its concepts in a language like Rust, the central point that FP is important holds.

>The most upsetting part is when the author brags about how Clojure programs can manipulate itself at run-time, on a website that's literally called "Clean Coder Blog". Self-modifying code is a clear opposite of clean code.

If you do it in 70s goto/spaghetti style then yes.

Else, citation needed.

Not to mention that Robert C. Martin literally wrote the book on Clean Code.

>> Maybe we don’t have to worry about chips with 32,768 cores on them. Author apparently has never written a GPGPU program.

Author apparently knows about this trivial counter-example, and speaks about general purpose CPUs, not GPU programming in his post...

> doesn't mean the general argument in favor of FP is moot

I didn't say that. I'm not opposed to FP, quite to the contrary. My point is that there are better arguments for FP than those in the submission.

> The most upsetting part is when the author brags about how Clojure programs can manipulate itself at run-time, on a website that's literally called "Clean Coder Blog". Self-modifying code is a clear opposite of clean code.

This is a Lisp macro. Macros are a powerful form of abstraction. Abstractions are what us programmers create to reduce complexity and clean code.

One just needs to be mindful of how this powerful tool is wielded, just like any other tool; you can make a mess with anything.

> Author apparently has never written a GPGPU program.

99% of the programmers out there never did and never will do.

I have another gripe with these kinds of immutability / FP praising articles: The assumption that this must be faster, because multicore. As an example, many if not most of scientific applications (for which Haskell wants to position itself) are memory bandwidth bounded, not CPU bounded. These applications also deal with Gigabytes of data for each timestep, applied over dozens if not hundreds of kernels. So we're talking about thousands to tens of thousands of functional updates over data objects, each on the order of Gygabytes. The way this is dealth with efficiently in many cases is by doing pointer swapping - after each timestep, or even for intermediate kernels, the old output becomes the new input and the old input is overwritten by the new output. Swapping allows this to be an O(1) operation. Allocating new memory at each kernel launch for the output would absolutely kill the performance - we're talking one to two orders of magnitude here. Even if an FP compiler comes along that is able to optimize this, if this ever breaks I have zero trust that it will be a simple thing to figure out why the compiler doesn't do what I wanted, and at that point I'd rather just program it procedurally. To my knowledge, game programming is pretty much the same thing, so these usecases are rather wide spread.

I think there must be a (probably not yet invented) language somewhere that would allow me to write computations in immutable FP style, either as pointwise operations (i.e. stencils), or as matrix operations, but allows me to pass in some information that directly instructs the backend what it should do with the memory. I.e. I want to be able to program my own memory pools and link pointers to memory slots needed for the computations. Maybe that part could even be done using visual programming, akin to linking up GUI elements to properties in XCode: Let the compiler figure out where a memory slot is needed, do a dependency analysis for the memory slots and show graphically what slots are linked to what input and output. Then, let me add constraints to that linking and recompute a new solution whenever I move something around. The next step would be to do a performance model for each processor and figure out the best solution using machine learning, but let me actually see what the solution is without me having to go look at assembly (which, frankly, for FP frontends seems near impossible since it has even less to do with the frontend code than if you compile down something like C or Fortran).

Exactly. I've actually been giving this a fair amount of thought, as it also relates to "GC for everything", another obstacle for real time programming (soft or hard). I like many things about the FP approach, especially in terms of reasoning about the code. I just think the computer science community needs to focus on basically what you're advocating, immutable recycling alongside of garbage collection.

It seems to me that this is a fairly easy problem really, and things should move to more of a mixed memory handling model, where one could use one or more of manual memory management, recycling, or GC as needed. FP language scala-native is providing both manual management and GC already, for instance...

Thank you. Yes, well, from the CS people I usually just get blank stares. "What did you say, you prefer Fortran"? I feel like there's a big divide between engineering and CS. The latter would rather never care about anything to do with hardware. IMO the real innovation usually comes at the intersection of hardware and software - like the recent boom of neural nets. Those things are known since the 80ies and then promptly dropped because the hardware wasn't ready, until someone 30 years later took the time to make a good CUDA library and make it work fast enough to be useable. Meanwhile the CS community focuses on adding more abstractions until no-one can figure out the hardware implementation anymore. Sorry for the grumpyness, guess my mood isn't the best today...

> Haskell wants to position itself

Haskell isn't really a thing that could "want" to "position itself".