[bos]

This is a bizarre essay by someone who understands neither functional programming nor the history of computers.

> To be kind, we’ve spent several decades twisting hardware to make the FP spherical cow work “faster”, at the expense of exponential growth in memory usage, and, some would argue, at the expense of increased fragility of software.

There is not one iota of support for functional programming in any modern CPU.

[seanhunter]

Totally agree. In addition, one of his examples (Mars Pathfinder) has absolutely nothing to do with functional programming or simplifying assumptions of any kind. The mars pathfinder problem was caused by a priority inversion on a mutex - exactly the sort of thing that all programmers rightly consider hard and that things like software transactional memory in FP would prevent. Here’s the famous email “What Really Happened on Mars?” which was written by the a pathfinder software engineer and explains the issue

https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hd...

Even by the standards of substack TFA is an extraordinarily poor blogpost.

[imtringued]

The definition of spherical cow is also butchered beyond recognition.

Spherical cows are about simplifying assumptions that lead to absurd conclusions, not simplified models or simplified notation in general.

Calling functional programming a spherical cow when you mean that automatic memory management is a simplifying assumption, is such a gross sign of incompetence that nobody should keep reading the rest of the blog.

[JumpCrisscross]

> Spherical cows are about simplifying assumptions that lead to absurd conclusions

There aren’t any commonly-accepted conclusions from spherical cows because the bit is the punch line. It’s a joke a physics 101 student makes when toughing through problems that assume away any real-world complexity and thus applicability.

Spherical cows, in the real world, are pedagogical tools first, approximations second, and mis-applied models by inexperienced practitioners third.

“Hello World” is a spherical cow. Simplifying assumptions about data are spherical cows. (And real dairy farmers implicitly assume flat cows when using square feet to determine how much room and grazing area they need per head.)

[dragontamer]

Spherical cows?

The joke as I recall it, was a physics student who brags that he can predict the winner of any horserace, so long as all of the horses were perfectly spherical perfectly elastic horses.

I'm actually not sure where cows came in, but maybe there's a different version of the joke out there.

[jibal]

Spherical cows are very much about simplified models--that's what modeling a cow as a sphere is all about.

[Scubabear68]

Trying to be as kind as possible in my interpretation of the article, my take was that the author got stock on the "spherical cow" analogy early on and couldn't let it go. I think there are nuggets of good ideas here which generally tries to talk to leaky abstractions and impedance mis-matches in general between hardware and software, but the author was stuck in spherical cow mode and the words all warped toward that flawed analogy.

This is a great example of why rewrites are often important, in both English essays and blogs as well as in software development. Don't get wedded to an idea too early, and if evidence starts piling up that you're going down a bad path, be fearless and don't be afraid of a partial or even total rewrite from the ground up.

[froh]

yes. and the two nuggets I took were looking a Unix pipe as a concurrent processing notation and pointing out that the Unix R&D for great notations (or the communication thereof?) stopped right before splitting, cloning and merging concurrent streams. I've rarely seen scripts nicely setting up a DAG of named pipes. I'm not aware of a Unix standard tool that would organize a larger such DAG and make it maintainable and easily to debug.

assuming pointing at a problem counts as nugget.

[Yoric]

Agreed, it's really weird.

To the best of my understanding, the author describes the structured imperative programming style used since the 70s as "functional" because most languages used since the 70s offer functions. If so, it makes sense to describe hardware is optimized for what the author calls "functional programming", since hardware has long been optimized for C compilers. It also makes sense to describe callbacks, async, then, thread-safety as extensions of this definition if "functional programming", because yes, they're extensions of structured imperative programming.

There are a few other models of programming, including what people actually call functional programming, or logical programming, or synchronous programming, or odder beasts such as term rewriting, digraphs, etc. And of course, each of them has its own tradeoffs.

But all in all, I don't feel that this article has anything to offer to readers.

[foobarian]

This would probably apply better in the ~80s after all the hard work building Lisp/Forth machines

[karmakaze]

The most credit I could give is that the post itself is a spherical approximation of the subject and the point being made is that they discovered async dataflow programming and think it's underrepresented. I've only seen it compared it to command-line pipes for explanation of the concept, not understanding implementation characteristics.

I agree that code tends to be overrepresented--we don't 'data golf'. Even non-async dataflow oriented programs are much easier to follow, which happens to play exceptionally well with FP.

[mananaysiempre]

If you squint so hard that SSA is functional programming[1] and register renaming is SSA, modern CPUs are kind of functional, but that of course has nothing to do with functional programming done by the user, it’s just the best way we know to exploit the state of the art in semiconductors to build CPUs that execute (ostensibly) serial programs.

[1] https://www.cs.princeton.edu/~appel/papers/ssafun.pdf

[hinkley]

You’d have to cross your eyes pretty hard but SIMD and GPUs.

But for the classic ALU, I can’t think of anything. Anything that helps FP was probably meant to help with text processing and loops in general.

[muststopmyths]

TFA actually refers to "other spherical cows", not just FP.

Doesn't makes any point very coherently, but it's not exclusively about FP though that gets mentioned a lot.

[kgwgk]

> TFA actually refers to "other spherical cows"

What does that mean in the context of the comment you reply to - which includes the literal quote about "twisting hardware to make the FP spherical cow work faster”? The article may not be exclusively about FP but nobody said it was.

[KerrAvon]

“spherical cow” seems to be a bizarre, pointless substitution for “encapsulation” or “object oriented programming” depending on the context.

[JumpCrisscross]

> TFA actually refers to "other spherical cows", not just FP

I’m genuinely curious if anyone can derive a consistent definition of what the author thinks a spherical cow is.

[andersmurphy]

Yeah the whole article is absurd. Functional programming is not even remotely mainstream. So not sure who is twisting?

[quamserena]

> There is not one iota of support for functional programming in any modern CPU.

But there is a ton of support for speeding up imperative, serial programs (aka C code) with speculative execution, out-of-order execution, etc.