Simplicity vs. Functional Programming

2025-02-07

Feb 07, 2025

The job of researchers and scientists is to understand a complicated issue and to explain it in less-complicated terms.

That's what happened in the 1950s. They took a complicated piece of parallel electronics and wrapped a single-threaded, synchronous notation around it to get a simpler single-threaded way to reason about the complicated parallel electronics. To perform this trick, they used time-sharing and shared memory and, implicitly, relied on advances in hardware to shrink memory-access pathways and to speed up the use of shared memory.

Now, in 2025, we are still using the same pet trick of functional programming, but for a completely different problem domain - a complicated collection of computing entities, distributed in a way that miniaturization won't help with. We're making the explanation, notation, and, reasoning-about more complicated. For example, concepts like "priority inheritance" inherited from the Mars Pathfinder fiasco, callback hell, 'await', '.then', etc. are more complicated, not less complicated. We strive to use these baubles based solely on our desire to stick to Gutenberg-inspired sequential notation.

Certainly, `a = b + c` is a more succinct way to write that kind of relationship than any other notation that I've seen. I learned that particular notation in grade school (ugh, let's say grade 3, but, I don't remember). I learned another notation in Kindergarten, though - how to draw a closed figure and how to colour it in without crossing the lines. The best Gutenberg-inspired notation for that simple relation that I've seen involves brace bracket characters `{...}`. This seemingly simple notation led us (the royal "us") down a garden path of worrying about free and bound variables for years, where any kindergarten kid knows how to express that relationship more simply with a crayon.

In 1950, due to hardware costs, we (the royal "we") had no choice but to use small, fixed-sized bitmaps on strict, non-overlapping grids. Today, we have better hardware and a completely different problem domain, i.e. whole-program concurrency, instead of opcode concurrency. We can do better. Yet, we continue to use small, fixed-sized bitmaps on strict, non-overlapping grids as IDEs for programming.

I disagree with the notion that our functional programming languages are 'simple' and I disagree with the idea that 'more interesting combinations' are somehow 'more complicated'. They're only artificially more-complicated, because we insist on using functions inspired by the Gutenberg printing press and notations designed for writing on papyrus using quills. Yes, expressing non-calculator concepts, like asynchrony, is more complicated when using functional notation, but, that is mostly due to self-flagellation. To me, this is a tell that we need to switch to another notation for that portion of programming. We should continue to use functional notation, but, only where it applies and not where it needs to en-baubled.

My interest in UNIX pipelines stems from the fact that these pipelines give us a clue on how we should be thinking. UNIX pipelines fail to satisfy, though, because of the attempt to use Gutenberg-inspired notation in shells. But, that's a fix-able problem. Smart people can come up various ways to fix this deficiency.

Functional notation, whether "pure" or just the stuff found in “C”, puts too many restrictions on programming. We got away with these restrictions for several decades, but, it is clear (to me, at least) that we've hit the wall.

Do we have to throw everything away and start all over again? No. Can we use what we've got at this point? Yes. In fact, simply rearranging a few inexpensive things in our current programming languages will let us leap over the new hurdles. E.G. create Queue classes, use queue-per-part instead of queue-per-port, use first-class functions and closures, learn from UNIX shells and Lisp that you can recursively combine entities to make bigger entities. But,,, learn that you need 2 kinds of entities. Just a single one (functions) ain't enough. Using a programming language that emphasizes only functions and makes you suffer to express queues and messages ain’t enough.

Programming Simplicity

Discussion about this post

Ready for more?

Programming Simplicity

Simplicity vs. Functional Programming

2025-02-07

See Also

Discussion about this post

Ready for more?