Manifesto

The main themes of these essays are:

Notations - dividing work up into small chunks and giving each chunk its own mini-language.
Software Architecture - It is my feeling that most existing programming languages are geared towards implementation of details instead of description of Software Architecture. For example, any language that requires the programmer to describe types or to use an operator, such as +, is a language of implementation details. I favour the use of dataless languages for describing Software Architectures. I use the name DI - Design Intent - when discussing pure Software Architecture devoid of implementation details.
DaS - Diagrams as Syntax. There is no good reason why programming languages should not be built using hybrids of diagrams and text. In fact, most Software Architectures start out life as diagrams on whiteboards. Parsing and compiling diagrams is at least as easy as parsing and compiling text. I strive to show the basics of doing so. (FYI - DaS is not “Visual Programming”).
Asynchronous Software Components - Snapping software together like LEGO® blocks¹.
Concurrency - Computers are concurrent. Most people understand concurrency. Children learn hard realtime notations at an early age, e.g. music lessons. Programmers have tried to force computing into cubby-holes using only synchronous methods, which has caused a great deal of accidental complexity.
Removing Dependencies - Programmers cannot “plug” components together if the components contain dependencies on other components. We see problems manifest themselves with the use of code libraries and APIs. Tools (like npm and make) that help manage dependencies only help in overlooking the elephant in the room.
Simplicity - Formal methods and mathematical notation were supposed to make it “easier” to “reason about programs”. I think that we’ve hit an asymptote where formal methods are actually making it harder - than necessary - to reason about programs. Most programmers think that multitasking is a difficult problem, while I feel that it is easy². I argue that the main reason for this problem of anti-simplicity is the (failed) idea that we need to use only a single programming language and that we must force-fit every problem into that single language. I favour the use of multiple notations for a given problem. I think that technologies like PEG³, make it possible to invent notations rapidly and to change the way we think about programming. I argue that we need to discard the notion of GPLs - General Purpose Languages - and focus on paradigms and on the problems-at-hand.
Isolation - Isolation between components is more important than formal proofs, statelessness and all of the other buzzwords. Isolation is not obvious to achieve - for example, calling a function by using its name is anti-isolationist.
Programs that write programs - I think that we need to invent languages and syntaxes that cater to machine-readability, and, we need to extend compiler-ism into more general problem solving and computing. Compilers are programs that write programs - their input is HLL syntax and their output is in the form of triples. Compiler technology can be extended to transpiler technology, e.g. notations (little languages) that transpile to Python/JS/etc.
Computers are machines. Machines do the boring, repetitive work, humans do the thinking.
Computers Are More Than Just Calculators. Computers are machines that can perform sequences of operations (functions of time) and control other machines, as well as calculating things.

Highlights

If I were to highlight certain articles, I would choose:

but, then, I already know what I mean.

YMMV.

Highlights

See Also