To expand on your main point: A loose, but appropriate analogy is that FP appeals to programmers in the way analytic solutions appeal to mathematicians and scientists: Neat, ideal, beautiful... but a poor fit for many practical problems.

That's the main issue which FP-for-parallel-execution proponents don't seem to get: Identifying independent (and therefore parallelisable) computations isn't the hard part, but planning the data layout and partitioning so that all your parallelism isn't eaten up by synchronization and data movement between cores.

The NC complexity class assumes a PRAM machine, in which all processors can access all locations of a central memory in constant time. That's not how a multi-core CPU works in practice: If your parallel algorithm doesn't make proper use of cache-locality, you've already lost.

[1] (the best kind of correct)

Not to fully justify the OP (though it rings both true and not quite true to me), but I think topology is a good positive example. It's impressive how much of continuity can be captured purely algebraically. For example, topologies are a kind of lattice, which cross both algebra and order theory. And then you get literal algebraic topology, which captures useful and interesting properties of individual topological spaces effectively.

> A more substantive objection is that the sole purpose of parallelism is performance.

I disagree a lot more strongly here, though I will twist your words a little bit. Yes, parallelizing a program is about making it run faster; but parallelism is also a base fact of many problem domains, where you have multiple agents (up to and including humans) collaborating and interacting simultaneously.

Abstracting over the speed-up aspects of parallelism gets you to concurrency -- the independence of knowledge held by distinct agents that is not directly knowable by others -- which is far more fundamental than simply making programs run faster. In my experience, most properties of modular systems can be stated in terms of concurrency. Parallelism is an exploitation of that concurrency structure to schedule things efficiently, but it is by no means the only application.

The fact that "one can achieve a 7x speedup on 8 cores by adding a handful of lines to a program" tells me that Haskell is extremely good at letting you expose the concurrent structures of your problem domain.

I don't think parallelism is the word for that. More like concurrency

Parallel computing is closely related to concurrent computing—they are frequently used together, and often conflated, though the two are distinct: it is possible to have parallelism without concurrency (such as bit-level parallelism), and concurrency without parallelism (such as multitasking by time-sharing on a single-core CPU).[5][6] In parallel computing, a computational task is typically broken down into several, often many, very similar sub-tasks that can be processed independently and whose results are combined afterwards, upon completion. In contrast, in concurrent computing, the various processes often do not address related tasks; when they do, as is typical in distributed computing, the separate tasks may have a varied nature and often require some inter-process communication during execution.

https://en.wikipedia.org/wiki/Parallel_computing

What you're describing sounds like it would be solved by primitives such as the actor model, not by Haskell-style FP.

> Yes, parallelizing a program is about making it run faster; but parallelism is also a base fact of many problem domains, where you have multiple agents (up to and including humans) collaborating and interacting simultaneously.

Maybe I should say what I meant more clearly. The claim "one can achieve a 7x speedup on 8 cores by adding a handful of lines to a program" implicitly has a "and this is good because being fast is good" at the end. Why care about a speedup if you don't care about speed in the first place?

It follows that when evaluating a language's ability to gain speed through parallelization, we should also evaluate how fast that language is in the first place. If you can get a 7x speedup on 8 cores from a few lines of code, but the original algorithm is, say, 10x slower than a similar implementation in C/Rust/Go on one core, then who cares? The ultimate criterion is always absolute speed, not relative improvement.

I agree that being able to deal with concurrency is important, but as the Go people always remind me, concurrency and parallelism are distinct concepts.

Also, you seem to be overstating the maturity of PDE (people are pretty much still trying to turn it into algebra, but it may not be possible) and number theory (that's an active research area).

I have never seen that saying either, but it seems quite correct, with the exception of the areas where an algebra is impossible, so the field matures without becoming one.

Obviously, I'm forgetting some, but none of these are primarily algebraic. Some algebraic methods are used (orthogonal polynomials in random matrix theory, and determinants and a whole host of other things to study integrable models in the KPZ universality class, etc.), but clearly groups/rings/fields are not playing a major role.

For a more systematic approach you could look at recent issues of Annals of Probability, Annals of Applied Probability, and similar journals. There's not going to be a lot of "modern algebra" (of the flavor you see in algebraic geometry) there.

The same comments apply to PDE and analytic number theory. Both are obviously mature fields (worked on for a long time by many people, with a lot of great discoveries), but again algebra does not play a central role in either. In particular I am not aware of any PDE specialists whose research agenda consists of "trying to turn it into algebra."

[1]: https://www.unige.ch/math/folks/velenik/smbook/

There's this rare unclosed survey-like mathoverflow question that highlights some of these points: https://mathoverflow.net/questions/66046/which-nonlinear-pde...

Julia is a multi-paradigm language, but it is heavily Erlang inspired (another multi-paradigm language, but primarily functional.)