Read on Twitter
This morning's PL insight: another reason why "everything is an X" with X in {Object, function, list, relation, ...} is pointless reductionism. Software is something we want to assemble from pieces. This, I think, is completely uncontroversial. The error seems to stem from an 1/
odd desire to have all the pieces be homogeneous and have the concept of 'assembly' and 'plugging in' also be homogeneous. That is where things go wrong. [Yes, I'm aware of Turing completeness and how plenty of homogeneous languages have it.] 2/
Settling for 'mathematically complete' is setting the bar much, much too low. The only (to me!) interesting metric is "being able to express core application concepts both clearly and succinctly". So it's a multi-objective optimization problem. 3/
Succinctness leads to Kolmogorov Complexity, and I'll unravel some of the conclusions from that some other day. "clarity" is the other half: it means optimizing for code _readers_ (and not code execution). I don't mean beginners, I mean "sufficiently knowledgeable" readers. 4/
The point remains that, at different scales, you really do want different kinds of 'plugging in'. Why can't I have wire diagrams for signal flow (a la Simulink) in the same language where I have Datalog queries and (pure!) function calls? 5/
Some languages have stumbled onto at mix somewhat by accident. It is still very funny to me that Template Haskell is an untyped, impure kind-of functional language on top of Haskell. Worse, LTac is an untyped, imperative language no top of Coq's CiC! 6/
To be fair, Agda's Emacs interaction mode is also weird: it's an untyped language of control codes that result in in-place editing of partial pieces of code. Treating it as extra-linguistic is a nice fiction, but developers integrate it fully in their methods of interaction. 7/
We should be more honest with ourselves, and design "software development environments" (as opposed to just programming languages) that encompass the human programmer and time as essential aspects. [Yes, I know, some people have been working on that for decades.] 8/
But the work I know is in languages where there is a single concept of "plugging in" & "wiring up". The physical world offers us an incredible array of different mechanisms for making wholes out of pieces, why are our software languages so poor in that respect? 9/9
