# Summary 2022 For me 2022 was: 1. 0D 2. transpiler pipelines Explanations below. There is nothing “new” here. I believe that our crop of programming languages subtly discourages certain kinds of thoughts. You can do these things with our programming languages, but, you don’t bother. [I wrote this on Jan 1/2023. Then I promptly got sick and found new ways to procrastinate. I will gladly remove this if it is inappropriate or too long...] # TL;DR ## 0D • 0D is part of traditional parallelism (zero-dependency, total decoupling) • breaking 0D away from parallelism enables other uses • 0D uses FIFOs, whereas functions use LIFOs (LIFOs are used by most modern programming languages, Python, Rust, etc. and stifle possible solutions) ## Transpiler Pipelines • “skip over” uninteresting bits of syntax, whereas CFG requires full language specification • leads to a different class of tools -> parser used for “quickie” matches instead of for building compilers ; different way of using parser DSLs ; like mathematical manipulation of notation • “skipping over” bits of syntax allows syntactic composition ; syntactic composition enables pipelines ; # 0D 0D is a short-hand for the phrase zero dependency. Total decoupling. Programmers already know how to write 0D code, but, they tangle this simple concept up with other concepts and call the result “parallelism”. At a very, very basic level, you can achieve 0D by using FIFOs instead of LIFOs (queues vs stacks). LIFOs - callstacks - are good for expressing synchronous code. LIFOs are less-good for expressing asynchronous code. Programmers often conflate nested, recursive functions with the notion of pipelines. If a component sends itself a message, the message is queued up in FIFO order and there is a “delay” before the message is processed, whereas if a component recursively calls itself, the function parameters are pushed onto a stack and the processing happens immediately, in LIFO order. This subtle difference in processing sequence manifests itself in design differences. For example, in electronics - where all components are asynchronous by default - you often see the use of “negative feedback”, say in Op-Amp designs. You rarely see this technique used in software design. In electronics, negative feedback is used by components to self-regulate, whereas in software, recursion is used as a form of divide and conquer. Feedback loops make it possible to be explicit about software design, whereas recursion hides the key element - the callstack - of the design. EEs had this issue sussed out, before the advent of the “everything must be synchronized” mentality. All components in an electronic circuit are asynchronous by default. Synchrony is judiciously, explicitly designed-in through the use of protocols. Synchrony is not designed-in everywhere by default and is explicitly designed in on an as needed basis. There is a reason - a subtle reason - why it is easy to draw diagrams of computer networks and not-so-easy to draw diagrams of synchronous code. In EE designs, concurrency is so cheap that you can’t help but use it. In software, concurrency implies difficulty and designers end up avoiding concurrency in their designs. This subtle difference has a trickle-down effect to end-user code. When it is difficult to draw diagrams of programs and to snap components together, programmers tend not to provide such features to end-users. Or, when they provide such features, they implement such features under duress. If DaS and snappable components were abundantly available, such features would naturally leak through to end-user apps. 0D can be implemented a lot more efficiently than by using operating system processes and IPCs. Most modern programming languages support closures (anonymous functions) and make it easy to build queue data structures. Stick one queue at the front of a closure - the “input queue” - and one queue at the tail of a closure - the “output queue” - and, you get 0D. Then, you need to write a wrapper component that routes “messages” from the output queue of one closure to the input queue of another closure. Can this concept be generalized? This ain’t rocket science. When you build 0D software components, does the order-of-operation of components matter? Nope. Can a 0D component create more than one result during its operation? Yep. Can a 0D component directly refer to another 0D component? Nope. The best you can do is to compose networks of 0D components inside of routing wrappers. # Transpiler Pipelines It would be nice to build up solutions using pipelines of many little solutions and syntaxes made expressly for those solutions. What do you need to be able to do this? 1) You need to be able to write grammars that are very, very small and that allow you to”ignore” bits of syntax that don’t pertain to a problem, e.g. kind-of like REGEX, but, better. 2) Total isolation of building blocks. ## Very Small Grammars That Ignore Uninteresting Items Ohm-JS - a derivative of PEG (Parsing Expression Grammars) - makes it possible to write grammars that skip over uninteresting bits of text. For example, if you want to write a quickie parser for C code, you might want to say:

... function-name (...) {...}

In Ohm-JS, you can say this, whereas in a CFG-based parser generator you need to over-specify all of the niggly bits of C syntax. In Ohm-JS, this results in a few minutes of work and only a few lines of code. The Ohm-Editor assists in developing the micro-grammar. In YACC and CFG-based approaches, though, you’re looking at a gargantuan job (days, weeks, months, ...) and you simply don’t bother to write such a quickie parser. You either don’t bother with the whole idea, or you use something like REGEX which fails on a number of edge-cases for this kind of thing. REGEX can’t search recursively for matching brackets, Ohm-JS can. Using REGEX, you might get away with a partial solution, or, the project might grow larger as you hit unexpected speed bumps. You either persevere or you just give up. For the record, the grammar plus the accompanying code fabricator specification for the above simple example are shown in the appendix. ### DaS Comes For Free When you can build totally isolated building blocks, you can draw sensible diagrams of how the building blocks should be snapped together to solve a problem. Later, you can steal (cut/copy/paste) chunks of previous solutions and use them as building blocks for new problems. DaS: Diagrams as Syntax. DaS is not diagrams as an Art Form. DaS is diagrams as programming languages. For example, instead of writing

{...}

, you draw a rectangle. Programming languages were created by culling the English language and by choosing only the words and phrases that could be compiled to executable code. Can we cull diagrams in the same way to invent new programming languages? EE’s have done this and they call the resulting diagrams “schematics”. Building construction engineers have done this and call the resulting diagrams “blueprints”. ## Don’t We Already Use Building Blocks? “Code Libraries” look like building blocks, but, contain subtle bits of coupling that discourage building-block-iness. For example, the very common idiom of a function call

f(x)

introduces at least 3 kinds of coupling: 1. The name

f

is hard-wired into the caller’s code. The calling code cannot be cut/copy/pasted into some other solution without also dragging in the called code, or, by futzing with the source code. 2. The function call

f(x)

waits for the callee to return a value. This is also known as blocking. Function call notation works fine on paper, where functions can be evaluated instantaneously. It’s different when you map function call syntax onto hardware that has propagation delays wherein functions take finite amounts of time to “run”. This subtle difference in behaviour leads to hidden gotchas. A glaring example of the impact of such a difference can be seen in the Mars Pathfinder disaster[^pathfinder]. 3. The function return

v = f(x)

hard-wires a routing decision into the callee’s code. The callee must direct its response back to the caller. This is called “returning a value”. Again, this doesn’t look like a problem when you just want to build fancier calculators, but, this hard-wired routing decision discourages simple solutions to non-calculator problems, like machine control. [^pathfinder]: https://www.rapitasystems.com/blog/what-really-happened-software-mars-pathfinder-spacecraft When you don’t have complete isolation, you don’t have building blocks. Imagine a LEGO® set where all the pieces are joined together with a single, long sewing thread glued to each LEGO® block. Or, you have two real-world objects, e.g. one apple and one orange. You cut the apple in half. What happens to the orange? As humans, we are used to the idea that objects are completely isolated. Programs don’t work that way. We have to stop and think hard when writing programs.

Nice ideas. Re 0D, my next question is: how to decide at what granularity to stop using function calls? Or are you suggesting eliminating them entirely? Re transpiler pipelines: I tried this for a while a few years ago. The conclusion I reached was that they were great for adding capabilities but they can't add restrictions. In first class languages often a lot of value comes from guarantees that certain events won't occur. An int won't be assigned to a string. There you need a single coherent grammar. Does this seem right?

this talk is quite relevant —

... re: 0D ... ideal: use both, without letting language influence your thinking ideal: use both, but, remain aware of what each choice accomplishes ideal: 0D to be so cheap that it could be used on every line of code reality: 0D is entangled with Multiprocessing and the current grain size is “Process” alternate reality: 0D can be couched in terms of closures and FIFOs, hence, grain size is “function” (where closure is roughly equivalent to function) reality: CALL/RETURN and the callstack are hard-wired into CPUs (there used to be a time when CPUs didn’t have hard-wired callstacks) reality: 1950s IDEs for Programming were Programming Languages, but, in 2022++ IDEs include other stuff, like powerful programming editors CALL is used for 2 reasons: (1) compacting code size, (2) DRY (Don’t Repeat Yourself). There is no good reason to allow CALL/RETURN to leak into end-user code except for case (1) compacting code size [corollary: case (2) should be entirely optimized away at “compile time” and “edit time”] x.f(x) is syntax with the meaning “mutate the global callstack and mutate the IP to point at the method function x.f” (and “return” means “put the return value in a special place, then mutate the global callstack, then mutate the IP to point at the caller’s continuation code”) but, there is no popular builtin syntax for Send()ing to an output queue and passing the finalized output queue back up to the parent Container ... re: transpiler pipelines question ... thinking ...

While I don’t believe 0D is possible, it certainly is true that our current dominant architectural style, call/return, couples way more than it should, and is largely mismatched with the majority of systems we build today. I talk about this in some detail in Can Programmers Escape the Gentle Tyranny of Call/Return.

Curious to learn more, I listened to @Marcel Weiher over here . The Q&A has a few familiar faces. The idea, as I understand it, is that we often want to connect bits of data

y = f(x)

but call/return unnecessarily couples how you enforce the relation, namely, by fixing

y

based on

f

of an precomputed

x

. You may do it eagerly, you may do it lazily, but you're still committed. With Prolog you can leave variables unbound. With bidirectional transformations / lenses you can update

x

from changing

y

. And there are more possibilities. I've long been curious about decoupling relations over state from evaluation/update mechanisms. By the way Common Lisp's resumable exception handling mechanism is called the "Condition System."

I apologize if I’ve made this sound too complicated... 0D has been around for a long time. I didn’t invent it, I just drew a sloppy red circle around it and gave it a name that I like. Every “concurrent” program needs, first, to be 0D. UNIX pipes were invented in 1973 https://en.wikipedia.org/wiki/Pipeline_(Unix). Morrison invented Flow-Based Programming even earlier. Processes and IPCs have been around for a long time. All are 0D at the core. Anonymous functions (the precursors to closures) were invented around 1956 (Lisp 1.5). If there hadn’t been such a deep allergy to Lisp, it might have become obvious that “operating system processes” were just closures. One of the first CPUs that I programmed, didn’t have a callstack. You had to choose to implement CALL manually, or, choose to implement co-routines manually. (BALR instruction, IIRC). Or, to do something more ad-hoc and less-structured. Basic 0D consists of putting a queue at the front of a closure and another queue at the back of the same closure. Then, writing a wrapper that shepherds messages between queues. Stating the obvious - lists and callstacks are not queues. Recursion is not 0D. I will try to whip up an example in some example language ...

I think you did a great job describing it, and yes, Unix P/F, Morrison’s FBP etc. are all under-appreciated. Not sure the name “0 Dependencies” does the trick, though I understand where you are coming from with it. Part of the problem with dataflow systems being under-appreciated, I think, has to do with them usually suffering from packaging mismatch. So while in principle they are structurally simpler, their implementations tend to be difficult to integrate with. So-called “FRP” (or Rx) has done a somewhat better job of integrating with existing procedural/functional languages, and has thus seen fairly wide adoption, but at the cost of hiding the goodness of the dataflow underpinnings under some FP goobledygook that makes it much more difficult to (re-)use and compose. Polymorphic Write Streams do a slightly better job, IMHO of course, but still suffer, because in the end it is tricky to provide non-procedural abstractions when the abstraction mechanism itself is the procedure call. You simply can’t talk about what you’re doing with the linguistic means available, which is a bit of a bummer. One of the reasons I decided to create a new language…

message has been deleted

Re: ALGOL. My quip (which I get a lot of flak for, so good…) is that today’s “general purpose” languages are nothing of the sort. They are domain specific languages for the domain of algorithms. See ALGOL, the ALGOrithimic Language, which all of today’s mainstream languages are descendants of and largely indistinguishable from. That said, “algorithms” is a pretty good domain, and if I had to choose one and only on architectural style, call/return is the one I’d choose. And I think the idea that we have to get rid of the dominant style in order to overcome its limitations is one of they key obstacles to actually doing so. We need to generalize from it, not ditch it.

a) I consider IF-THEN-ELSE to be the root of many evils. It is “too general” and allows one to construct ad-hoc control flows. (McCarthy specified COND, which maps functions to values, but, was not meant to be a control flow concept). b) There used to be a time when CPUs gave equal weight to function calling and to co-routining. Function calling is an attempt to graft mathematics notations onto CPUs. One difference is that mathematics notation requires instantaneous textual replacement of functions (“referential transparency”). CPUs have propagation delays which make it “impossible” to graft 0-time concepts onto electronics. A lot of epicycles have been invented to get around this issue by completely ignoring it (e.g “operating systems”). [aside: “instantaneous textual replacement” without side-effects? Isn’t that what Microsoft Word “find-and-replace” does?] c) I am enjoying your comments / this perspective. Mathematical “algorithms” are not the same as “electronic machine algorithms”. Electronic machines have “mutation”. Period. “Mutation” is also known as “RAM” (and heaps, and caches, and registers, and ...). Models of mathematical-only algorithms using electronic machines are not the same thing as models of electronic machines in general. Using only functional notation to express electronic-machine-algorithms snips off a bunch of possible avenues of thought. d) Abstraction. “Lambda” is a way to lasso and abstract code. But, a rectangle drawn on a whiteboard is also a way to lasso and abstract code.

“A computer does not primarily compute in the sense of doing arithmetic. Strange. Although they call them computers, that’s not what they primarily do. They primarily are filing systems. People in the computer business say they’re not really computers, they are “data handlers”. All right. That’s nice. Data handlers would have been a better name because it gives a better idea of the idea of a filing system.” — Richard Feynman

message has been deleted

“For the first time I thought of the whole as the entire computer and wondered why anyone would want to divide it up into weaker things called data structures and procedures. Why not divide it up into little computers, as time sharing was starting to? But not in dozens. Why not thousands of them, each simulating a useful structure?” — Alan Kay, The Early History of Smalltalk

Ironically, all of the Smalltalks that I know about implement so-called “message sending” using synchronous CALL/RETURN. What is needed is a Smalltalk that implements Objects as concurrent entities with input and output queues. McCarthy provided the basics for faking this kind of thing out in 1956 (anonymous functions, and, cons cells) Aside: I have a passing interest in Dave Ackley’s MFM. What I see there is “relativity”. Machines cannot address one another in absolute terms, but only in relative terms. Kinda like The Game of Life on steroids and hardware. The only valid use of CALL is to save space in a delivered executable. Using CALL - in end-user apps - for any other purpose is inefficient and abusive. Mapping “functional notation” onto CALLs in end-user code is expensive. If you wish to fake out “functions” during development, let your IDE do it for you, but, make sure that none of that fakery reaches the end-user. (Corollary - back-pedaling by inventing epicycles such as “inline code” is the opposite of how scripts for generalized electronic machines (aka “computers”) should be created. Operating systems fake out closures. Closures fake out a notation that is - sometimes - useful for developing scripts of Assembler.).

Ironically, all of the Smalltalks that I know about implement so-called “message sending” using synchronous CALL/RETURN.

Yes. And in fact, Alan’s famous quip “I made up the term ‘object-oriented’, and I can tell you I did not have C++ in mind” was followed immediately with the far less quoted “The important thing here is I have many of the same feelings about Smalltalk”.