The Case for Composable Notations

We don't need to start over. We need to start composing.

1 of 5 The Spherical Cow We Forgot We Were Riding 2 of 5 The Restrictions That Came With the Cow 3 of 5 State Isn't The Enemy 4 of 5 Ease of Expression Is the Whole Point 5 of 5 UNIX Already Showed Us the Way 6 of 5 WIP - Notations in Progress

"The Spherical Cow We Forgot We Were Riding" — that is a great title. If you're in the mood @guitarvydas, may or may not be your style, I would love to push on the assertion, "Functional programming cannot express this [data flow] without leaving the paradigm. The workarounds (callbacks, futures, reactive streams) are all ways of bolting asynchrony onto a fundamentally synchronous notation."

I would be most interested in your (or anyone else’s) pushback. Thanks!

@guitarvydas I really enjoyed this set of articles. Here are some of the quotes that resonate strongly for me: From article 1:

CPUs and memory are now effectively free. The original justification evaporated. What remained was the notation, now mistaken for ground truth.

From article 2:

Every notation has a sweet spot — a class of problems it expresses clearly and cheaply. Outside that sweet spot, the notation fights you.

From article 3:

Every one of these domains is stateful by nature. The state does not go away because the notation ignores it.

-

Hidden state is not safe state. It is state that is harder to reason about, harder to test, and harder to modify.

From article 4:

The question is not “can this notation express the problem?” The question is “does this notation make the problem easy to express, easy to reason about, easy to modify, and easy to communicate?”

From article 5:

A GPL must be expressive enough to handle every problem domain, which means it cannot be optimally expressive for any particular one.

Little languages — small, purpose-built notations for specific problem domains — make the opposite trade.

The mismatch between the dominant notation(s) and the things we really care about when designing software screams at me everyday.

IMO, programming consists of broadly 2 categories: Design Engineering and Production Engineering. The former requires iteration and rapid turnaround and lots of little languages instead of behemoth milquetoast GPLs, while the latter requires dotting all the i’s and crossing all the T’s, serious type-checking, etc, etc. IMO, our current spate of programming languages serves the latter only and ignores the former. When I crawl down the Design Engineering rabbit hole, I get to wanting a workflow that I call Failure Driven Design. @Benji Rappoport