Simplicity

2025-01-22

Jan 22, 2025

Sometimes, simplicity is so simple that it looks to be too simple to be useful.

How can you tell if you're looking at something simple, but, useful?

How about?...

1. Just use a couple of FIFO queues and some closures and just change your mindset to one of "layering" instead of "infinite canvas". That's pretty simple. You can do this in just about any modern language. Right now. You don't need any new high-falutin' syntax nor cosmic new language features to do this.

2. Just inhale a (big) string, modify it, then exhale the modified string. Why bother writing yet another compiler? Just transpile a string into a string that looks like {Python/Rust/etc.} code and let the existing {Python/Rust/etc.} compilers do the rest of the heavy lifting.

3. Change your mindset of 1-in, 1-out to many-in, many-out. Allow subroutines to have many inputs that dribble in over time. We already do this and call it "client-server".

4. Stop using the word "function" when you mean "subroutine". Keep remembering that CPUs fundamentally violate pure-functional basics. CPUs are based on mutation. CPUs create side-

effects. CPUs embody control flow. Functional Programming is a useful paradigm, but, it ain’t the be-all and end-all of programming. There are other fruitful ways to create programs. Like, for starters, node-and-arrow with ports, or, Harel Statecharts[1], or, Drakon[2], and so on.

5. Stop thinking that you must call functions. Send messages (not what Smalltalk calls message-sending, which is just function-calling in disguise). We already do this. It's called "internet".

Different compounds of rust were used to create transistors and transistors were used to create ICs. That stuff seemed like an unmanageable bag of complexity until we layered on top of it a way to simplify thinking about it. Now, we can build electronics by "writing code". We didn’t just hack new features into the already-complex stuff, we built a new layer on top of the stuff. We thought of the existing stuff like it was an “assembler” for bigger and better ideas.

We're there again - we are holding a bag of unmanageable complexity. We need to think again how to layer simplicity over top of this bag. We need to think of existing stuff - existing programming languages and the like - as “assembler” for bigger and better ideas[3].

By the way, I have a name for (1) above - "0D"[4].

I call (2) "t2t"[5].

(3) is called "node-and-arrow diagrams", where the nodes have multiple ports. This looks "too simple", but, was powerful enough to develop t2t.

(4) and (5) are mindset things. You don't actually need code to change your mindset. 0D grew out of this simple change of mind-set. I strung two parsers together in a multi-branching pipeline. Easy to do in code, but, 1-in/1-out code doesn’t encourage that line of thought. I needed to start out thinking about what I wanted, instead of how to code it up.

Bibliography

[1] Statecharts from https://guitarvydas.github.io/2023/11/27/Statecharts-Papers-We-Love-Video.html

[2] Drakon from https://drakon-editor.sourceforge.net

[3] In a 'real' Computer Science, the best languages of an era should serve as 'assembly code' for the next generation of expression (Alan Kay, 31:50) from

[4] 0D from https://github.com/guitarvydas/0D

[5] t2t from https://github.com/guitarvydas/t2t

Paul’s Substack

Discussion about this post

Paul’s Substack

Simplicity

2025-01-22

Bibliography

See Also

Discussion about this post