Programming Simplicity

Separating Architecture From Implementation

Paul Tarvydas — Fri, 26 Jun 2026 12:52:26 GMT

With our current programming languages it is difficult to separate architecture from implementation.

The reason for this is just a minor detail: functions are implemented on hardware using the CALL/RETURN instruction.

The implementation is that the CALLer suspends (blocks) until the callee returns something. This minor detail winds deep dependencies throughout code and makes it difficult to reason about what is going on.

The best way to break the dependency is to separate - control-flow wise - the caller from the callee, i.e. by using pure message sending (instead of impure message passing, as is implemented by CALL/RETURN and calling conventions). I built this into Parts Based Programming (PBP) through instinct.

Hardware ICs work this way, too. If actions need to be synchronized, the are explicitly, externally synchronized by the architect, not vagaries of the hardware such as CALL/RETURN (and cache coherency).

Concurrency (Part 2 of 2)

Paul Tarvydas — Wed, 24 Jun 2026 13:56:58 GMT

“Concurrency” is a concept tuned for allowing multiple functions to operate independently in the synchronous, sequential paradigm. It essentially uses a “trick” to allow this to happen - it assumes that the multiple functions are internally synchronized and it makes them run in a sequential manner.

This “trick” is useful for allowing us to think in terms of computation, but it doesn’t address asynchronous systems. Hence, it only addresses about 5% of reality (this number is pulled out of thin air and is not measured, yet, I base it on the fact that cosmology is based on the functional paradigm which pushes aside 95% of the problem that can’t be addressed in functional form, and calls it “dark matter”)

only simulates parallelism, is not full parallelism
teaching this has obscured the fact that concurrency is not true parallelism - people think that they are getting parallelism when using “thread libraries”, but they are only getting time-slicing, i.e. multiple functions running on a single computer in a synchronous - not asynchronous - manner.
micro-managed sharing of memory at the cell level instead of message-passing between isolated components
upper-level, explicit message-passing vs. lower-level, implicit memory sharing
the simplest, most efficient system would be a computer that is running exactly one program and not time-sharing the same computer with other programs
- this would remove the need for a lot of internal complexity, i.e. “thread safety”, since the single program does not share memory with any other program, hence, the compiler and the programming language could be massively simplified
If we imagine multiple such devices running single programs, but not sharing memory, then the best way for them to communicate and synchronize would be to pass message packets to one another
- This is what PBP does - it creates “parts” that are self-contained and do not share memory with other parts, it uses send(...) to explicitly send message packets (“mevents”) between parts.
- You are forced to write code that contains explicit message passing, instead of writing code that relies on implicit memory sharing. This maps to asynchronous reality better. # See Also

Email: ptcomputingsimplicity@gmail.com
Substack: paultarvydas.s. bstack.com
Videos: https://www. youtube.com/@programmingsimplicity2980
Discord: https://discord.gg/65YZUh6J. q
Leanpub: https:. /leanpub.com/u/paul-tarvydas
Twitter: @paul_tarvydas
Bluesky: @paultarvydas.bsky.social
Mastodon: @paultarvydas
(earlier) Blog: guitarvydas.github.io
References: https://guitarvydas.github.io/2024/01/06/References.html

Paid subscriptions are a voluntary way to support this work.

Leave a comment

Subscribe now

Concurrency (Part 1 of 2)

Paul Tarvydas — Wed, 24 Jun 2026 13:55:57 GMT

Simplified sketches that show the difference between concurrency and pure message passing.

Computer With Concurrency

A simplified sketch. Note that functions (A-I) might be one function or a tightly coupled thread of functions calling functions (which is really just one big function).

Not shown: all sorts of complicated extra code that belongs to the dispatcher and operating system.

Threads run more slowly than they could due to time-slicing and due to operating system overhead.

This only simulates parallelism using a mechanism that is unrealistic for geographically distributed systems, i.e. memory sharing. In addition, the simulation assumes that the processes are automagically synchronized (via memory sharing and cache coherency and extra hardware).

Each program (functions A-I) is actually a state machine. Programmers do not get to easily control and architect this behaviour. Context switching is performed by algorithms buried in the operating systems.

System With Pure Message Passing

Not shown: code that polls (or reacts to) incoming messages on input ports.

This can be simulated on a single development system by ensuring that programs cannot share memory.

Each program gets almost 100% of each separate CPU, hence, runs more quickly than on time-shared machines. # See Also

Paid subscriptions are a voluntary way to support this work.

Leave a comment

Subscribe now

Repeating Architectural Patterns

Paul Tarvydas — Wed, 24 Jun 2026 13:53:55 GMT

As we build a PBP version that mimics the original Atari Pong schematic, I doubt that we will actually see strictly repeating high-level patterns emerge. I think that the strictly repeating patterns are embodied in the ICs used in the original circuit. Combinations of ICs on the schematic are used to create architectural chunks that don’t repeat verbatim.

The design of ICs is about as far as we can take the idea of strict, repeatable patterns. The design of the Pong schematic uses low-level repeatable patterns to build up higher-level chunks of architecture.

PBP is an attempt to allow expressing such chunks in a readable manner. We should be able to reuse low-level parts to build up customizable medium-level parts that are used to build up specific parts for a specific project.

Seasoned “architects” may recognize such high-level patterns and reuse them as customizable ideas that can be used (in a modified way) in other architectures.

We already see this kind of thing happening in electronics and other fields of engineering, e.g. civil engineering and bridge design - not all bridges are designed the same way, but sometimes general architectural features are reused.

When I showed the Pong schematic to someone versed in electronics design, they “immediately” saw architectural patterns in the design, but with tweaks. For example, a comment was that BCD score was being rasterized for display on a then-standard cathode ray tube (CRT). The person saw that some low-level ICs were used in an idiomatic manner.

I guess one might say that PBP is a way to build up custom Designs using very low level patterns, while leaving the high-level Design readable. Currently, electronics schematics are filled with implementation details that obfuscate the design to anyone but seasoned architected.

Likewise with the way we write code. The code consists of a bunch of details that don’t tend to reveal the over-lying Design, unless the programmer(s) was careful to use common idioms and unless the reader is a seasoned programmer who rapidly recognizes the use of such idioms.

The colourized version of the Pong schematic was probably done by a seasoned electronics person. The person recognized areas within the circuit that were aimed at solving specific sub-problems, then grouped such areas together by colouring them. People who aren’t versed in reading schematics can understand the colourized groups without needing to understand the actual details of the electronics inside each group.

Resources

Articles

Videos

Examples

PBP Kernel Portability
Larson scanner written in PBP
Pong in PBP (very WIP)
Reasoning About Ordering
Exploring Techniques and Notations for Augmenting DX (Demo for FoP)
ASON sample tokenizer
early code repo for ė (eh) ancestor of PBP (contains basics for PBP/0D reasoning)
thinking Prolog: small sample of reasoning in Prolog
Nils Holm’s Prolog in Scheme code ported to Common Lisp
sample of creating “verbatims” in little language
- verbatims enable staged computation
- if a pass converts code to final code, it wraps the generated code in a “verbatim” and subsequent passes just ignore it and don’t try to parse it
example of using “applySyntactic<…>” in Ohm
using OhmJS to convert markdown to structured (bracketed) form
example of converting textual behaviour trees to JSON then to C++
Ohm In Small Steps (diary of converting some Scheme code to Javascript)
PT Pascal and S/SL
Call Return Spaghetti (essay)

AI Is No Code

Paul Tarvydas — Wed, 24 Jun 2026 12:37:46 GMT

AI is No Code for one specific architectural pattern. The one I call “function-based”, which is synchronous and sequential.

You can build other architectural patterns on top of that one architectural pattern, but the substrate function-based pattern restricts your architectural thinking (“Design”). For example, you cannot build Forth on top of that substrate. Forth doesn’t use the function-based “calling convention”. The best you can do is to build a fake Forth that adheres to a prematurely-supplied calling convention. Nor, can you build something that is asynchronous and fully parallel on top of that substrate, since the substrate has already eliminated asynchrony from any design you put on top of it. The best you can do is to define synchronous “reactors” and then plumb them together by hand in a manner analogous to writing assembler.

I’ve built many Designs using a different substrate architectural pattern - asynchronous, electronic IC based. From that experience, I conclude that the function-based pattern is too restrictive and bloatful and that we need to break free of it. AI won’t help with that.

Anti Assimilation

Paul Tarvydas — Fri, 19 Jun 2026 11:39:44 GMT

Anti Assimilation

2026-06-19

The way we build software - time-shared and centralized - is no longer appropriate for the problem domains of the 21st century, regardless of how convenient the synchronous, sequential, centralized paradigm seems.

Any code sitting atop Linux (or other even more bloated operating systems) has a base tax of about 30,000,000 lines of code on top of CPU ICs that use many more transistors than what was needed to build Sketchpad, Visicalc, Turbo Pascal, Unix V1 (UNIX was originally written in assembler, not K&R C), etc. We can do a lot better.

Continuing to build software the same way over and over again, expecting different results is a death march based on unwillingness to accurately assess the cost of doing so and based on the belief that there is only one purpose for “computers” (a better name might be RM - Reprogrammable Machines).

Pure functional programming - modern Sector Lisp - costs about 354 lines of assembler. Most other programming languages pay a huge tax for stretching and generalizing the functional programming model.

We need to think outside of the box of the synchronous, sequential, centralized model. Machine code and ICs can support many more kinds of models than just functional programming (K&R C may have been a convenient abstraction, but, subsequently, C has been distorted into a functional programming language (albeit flawed) replete with function-based calling conventions).

Progress should result in less code. I don’t believe that this is happening.

Our current programming model makes us believe that issues - e.g. assignment, synchronous concurrency, asynchronous parallelism, thread safety, control flow - falling outside of the functional, synchronous, sequential model can be ignored or simply assimilated. Yet, Harel came up with a better notation for one of those issues some 40 years ago (Statecharts for reactive control flow). I think that we should be using models for programming that allow us to compose solutions using many paradigms, each with laser-focused languages to support them - specialization instead of generalization and the kitchen sink approach. Decentralization instead of centralization and assimilation. Eliminating problems instead of laboriously assimilating solutions to them.

Switching to a decentralized model could eliminate the issue of thread safety. Simply eliminating thread safety concerns would noticeably reduce the size and complexity of programming languages. Since the main role of operating systems is to act as scaffolding to support the functional model, can something be done about that issue?

Everything we’ve accomplished in the past 50 years fits inside just one of the bubbles on my diagram labelled “app” in a previous article. We haven’t really addressed the rest of the stuff, other than by applying notation worship to assimilate each new gotcha, in a whack-a-mole manner, into the ball of stuff that we already have. Grace Hopper warned against this approach.

Functions and math-like notation (mangled by 500 year-old Gutenberg technology) aren’t the only way to program the things we call “computers”.

It is entirely reasonable to specialize and drill down onto a thin slice of programming. But, it must be remembered that this is not programming, it is just a thin slice of programming. Looking at all problems through a single lens has a cost.

The Hardware Changed. The Software Didn’t.

Paul Tarvydas — Sun, 14 Jun 2026 19:32:57 GMT

TL;DR

The centralized CPU model is a historical accident driven by 1950s economics. CPUs and memory were expensive, so we time-shared a single machine and faked parallelism. Hardware has since gotten cheap. We should stop architecting software as if it hasn’t.

L;R

The centralized model is an artifact of scarcity

Early computers were extraordinarily expensive. CPUs and memory cost fortunes. This economic reality drove a specific architectural choice: one central processor, shared by many processes, switching between them fast enough to create the illusion of simultaneous execution. That illusion is what we call multitasking.

The illusion has a cost. Processes sharing memory introduce race conditions. Race conditions require thread safety. Thread safety requires locks. Locks introduce deadlocks. Deadlocks require careful engineering. That careful engineering leaks into every layer of the stack — operating systems, runtimes, frameworks, application code.

This is not a law of nature. It is a tax on a design decision made when hardware was scarce.

The mismatch that nobody names

The shared-memory model does not extend to distributed systems. The internet is not a shared-memory machine. Nodes are physically distant. Network latency is measured in milliseconds, not nanoseconds. Packets are dropped. Clocks drift. Nothing is synchronized by default.

We have spent decades building increasingly complicated machinery to paper over this mismatch — cache coherency protocols, multi-core synchronization hardware, distributed consensus algorithms, eventual consistency models. Each layer of complexity is a response to the fundamental mismatch between a shared-memory mental model and a physically asynchronous reality.

The hardware knows the truth. CPUs run in parallel. Network nodes run in parallel. The hardware is asynchronous by default. The software pretends otherwise.

Thread safety has poisoned language design

Thread safety is not a property of programs. It is a property of the shared-memory model. Remove shared memory and thread safety ceases to exist as a concept. It does not need to be solved. It needs to be made irrelevant.

This distinction has been lost. A generation of language designers treated thread safety as a fundamental problem of computation and built it into the core of their languages. Mutexes, semaphores, atomic operations, memory barriers, volatile qualifiers, synchronized blocks — these are not features. They are patches on an architecture that should not have required them.

The damage runs deeper than syntax. Languages now ship with concurrency primitives as first-class citizens. Programmers learn these primitives early and internalize them as part of what programming is. The question is no longer “why does this need a lock?” The question is “which kind of lock should I use here?” The accidental complexity has been promoted to essential complexity. It appears in textbooks. It appears in job interviews. It appears in the checklist of skills a senior engineer is expected to possess.

Most working programmers today have never written production software that does not grapple with thread safety in some form. To them it is simply part of the job — as natural and unavoidable as parsing or memory allocation. The idea that the entire concern could be eliminated by a different architecture is not on the table. It is not even a thought that occurs to ask.

This is how accidental complexity becomes permanent. Not by conspiracy, but by familiarity. Each generation of programmers learns the workarounds, masters them, teaches them to the next generation, and the underlying architectural mistake recedes further from view.

The decentralized model follows the hardware

CPUs and memory are now cheap. The economic constraint that justified the centralized model has evaporated.

The decentralized model takes the hardware at face value. Each node has its own CPU and private memory. Nodes do not share memory. Nodes communicate by passing messages. This is not a simulation of parallelism — it is actual parallelism.

Smart Apps

Smart Devices

Decentralized Model

Consequences

The consequences are significant. Thread safety disappears as a concern. There is nothing to share. The operating system’s job of mediating access to shared resources shrinks, or vanishes entirely. Applications own their CPU. They are not slowed by context-switching or contention.

This Has Been Done Before

Apple demonstrated this in hardware decades ago. The LaserWriter was a smart printer. It ran PostScript on its own CPU with its own memory. The Macintosh sent it a document; the printer handled the rest. The HP model of the same era exposed raw printer hardware to the host CPU — the host had to manage the device. Apple’s model was right. The device is smart. The wire carries messages.

Structured messaging is the discipline that makes it scale

Early message-passing systems failed. The reason is not that message passing is wrong. The reason is that unstructured message passing does not scale.

The solution is hierarchy. Messages flow as requests down the tree and summaries flow back up. No node communicates directly with its peers. A node sends requests to its direct subordinates and receives results from them. Peer-to-peer communication is handled entirely by a common parent node — there is no going over the boss’s head, and no reaching two levels down to micromanage a subordinate’s subordinates.

This is not a novel idea. It is how every functional organization has operated for centuries. Large businesses stay coherent by enforcing exactly this discipline. The org chart is not bureaucratic overhead. It is a scaling solution. The same discipline that keeps a ten-thousand-person company from collapsing into chaos is what keeps a distributed software system from collapsing into an undebuggable message storm.

A node knows only its direct children. It does not know what those children do internally. It does not reach past them to micromanage their subordinates. This is topology-blindness applied to network architecture.

Request Flow

Summary Flow

The development environment needs to change too

One honest complication: software development happens on single machines. A developer writing a decentralized application is still sitting in front of one CPU with shared memory.

Right now, we handle this backwards. We build systems that fake asynchronous processing as if it were synchronous — we write code that calls remote services as if they were simple function calls that pause, wait for a result, and always return — as if the network were just a slow piece of memory — then we hide the asynchrony and spend enormous effort managing the consequences when the illusion breaks. Then we ship the entire development environment to users. Users must buy computers running operating systems that support faked multi-processing. The bloat, the context-switching overhead, the complicated scheduling algorithms — all of it lands on the user’s machine because we never separated the development model from the deployment target.

We need to invert this. Development systems should fake asynchronous message-passing on a single machine, not fake synchrony on top of an asynchronous reality. Each component should be treated as if it owns a private CPU and private memory. Components communicate only by passing messages. No shared memory. No thread safety. The fact that the underlying machine is actually running these components by time-sharing a single CPU is an implementation detail of the development environment — not an architectural assumption that bleeds into the design.

One might expect that faking message-passing on a single development machine would make apps noticeably slower. This is not obviously true. Avoiding shared memory by default does impose a cost on apps that genuinely benefit from bulk data transfers — but it does not tax the vast majority of apps that never needed that optimization in the first place. The current version of PBP builds this fake asynchronous processing from scratch, in a green-thread manner. This implies — though it has not yet been fully tested — that PBP does not actually require an operating system as we know it. If that holds, the target hardware does not need to be burdened with a bloated OS, nor with the costs of time-sharing, context-switching, and the overhead of complicated scheduling algorithms. We should be able to ship simpler, leaner systems to users. Not copies of our development environments.

Our current workflow makes this worse in a specific way. We write single synchronous nodes first, then retrofit reactivity onto them so they can be plumbed together — callbacks, event emitters, promise chains, async/await. This is programming asynchrony in assembler. We are manually encoding, at the application level, coordination that should be handled in a higher level, asynchronous architectural manner. The result is code that is hard to read, hard to reason about, and hard to compose.

That said, the existing body of synchronous software is not worthless. Code written for a single synchronous node can be wrapped and treated as a leaf component in a larger asynchronous scheme. The wrapper handles the message boundary. The interior of the component stays exactly as it was. This gives us a migration path. We do not need to discard what works. We need to stop using it as the architectural model for the whole system.

The model is not hypothetical

Electrical engineers have run this architecture for as long as there have been chips. VHDL synthesis describes hardware components with private state communicating through ports. Schematics are topology diagrams, not shared-memory diagrams. EEs do not worry about thread safety. Their components run in parallel because the hardware runs in parallel.

Software inherited the centralized model from economic necessity. The necessity is gone. The model should follow.

Software Development Has a Brainstorming Problem

Paul Tarvydas — Sun, 07 Jun 2026 02:44:14 GMT

Every serious creative field has developed a rich pedagogy around brainstorming — the generative phase of work where raw material is produced before the evaluating mind gets involved. Songwriting has Pat Pattison. Fiction writing has Natalie Goldberg and Julia Cameron. Software development has… sprint planning?

This gap is real, and it matters. Here’s a tour of what the other fields figured out, why software missed it, and why Failure Driven Development might be the framework that finally closes the gap.

TL;DR

The songwriting and writing teachers all share one core move: make it safe to produce bad output. Software culture has never institutionalized this. FDD reframes failure as the mechanism of discovery — which is exactly the philosophical infrastructure the generative phase of programming has been missing.

L;R

What Songwriting Teachers Figured Out

Pat Pattison, the Berklee College of Music professor whose students include John Mayer and Gillian Welch, built his brainstorming pedagogy around a technique he calls object writing. The exercise is simple: pick an object — any person, place, or thing — set a timer for ten minutes, and write about it using all seven senses. The five familiar ones plus organic sense (how your body feels internally — butterflies in your stomach) and kinesthetic sense (how your body moves in relation to space — the room was spinning). The rule is no self-editing, no crossing out, and stopping when the timer goes off regardless of where you are.

The deeper principle is what Pattison calls “the art of diving.” In daily life we skim the surface of experience. Object writing forces a descent into concrete sensory detail — the kind of specific, embodied language that listeners can actually share. Abstract emotion becomes communicable only when grounded in sensory particulars.

He also teaches the title as a brainstorming scaffold: a strong title carries implicit “DNA” — a set of concepts and promises — that organizes what the verses can explore. And during the generative phase, the rule is an explicit “no free zone”: the inner critic is told to stand down entirely.

Other songwriting teachers work adjacent territory. Jason Blume mines everyday conversation and overheard phrases for title ideas. Ralph Murphy (ASCAP) starts with the title and asks what promise it makes to the listener, then brainstorms only what fulfills that promise. Jimmy Webb (Tunesmith) is more romantic about it — walks, drives, solitude, boredom — creating conditions for the unconscious to work rather than following a system. Sheila Davis (The Songwriter’s Idea Book) is the most toolkit-heavy: forty distinct strategies including clustering, mind-mapping, “what if” scenarios, and working from photographs.

The consensus across all of them: write before you edit, collect more than you need, and anchor abstract emotion in concrete specific detail.

What Writing Teachers Figured Out

The fiction and nonfiction world arrived at essentially the same pedagogy independently.

Natalie Goldberg (Writing Down the Bones) is the closest to Pattison in spirit: timed “writing practice,” keep your hand moving, don’t cross out, go for the jugular. Very Zen-influenced — she treats writing practice as a form of meditation.

Julia Cameron (The Artist’s Way) prescribes Morning Pages: three longhand pages every morning, stream of consciousness, no re-reading. The explicit goal is not good writing but drainage — clearing the “brain sludge” so the real creative work can flow later.

Peter Elbow (Writing Without Teachers) coined “freewriting” as a formal technique and articulated perhaps the clearest theoretical framing: the generating self and the evaluating self cannot operate simultaneously. They must be sequenced, not interleaved.

Anne Lamott (Bird by Bird) gives permission with her concept of the “shitty first draft” — the psychological license to write badly is the whole game. Also teaches radical scope narrowing: don’t write a book, write what you can see through a one-inch picture frame.

Dorothea Brande (Becoming a Writer, 1934) is arguably the original: write immediately upon waking before the rational mind engages. She predates Cameron by fifty years with essentially the same insight.

Why Software Missed This

The dominant culture treats programming as engineering or mathematics — fields where rigor and correctness are the virtues, not generative looseness. The inner critic is baked into the tools: the compiler rejects your shitty first draft immediately. It’s structurally difficult to maintain “keep your hand moving, don’t cross out” when the environment is constantly evaluating you.

The field also conflates design brainstorming with implementation. Whiteboard sessions, user stories, sprint planning — these exist, but they’re about requirements and architecture, not about the kind of raw generative thinking Pattison or Goldberg are after.

What does exist in software: sketching and paper prototyping in UX (borrowed from design thinking), “spike” solutions as throwaway exploratory code, rubber duck debugging as dialogic thinking-aloud, Ward Cunningham’s CRC cards for object brainstorming. These are useful but ad hoc — nobody has assembled them into a coherent pedagogy.

What’s entirely missing: a daily timed practice for generating design ideas, uncoupled from correctness. Nobody teaches programmers to separate the generating self from the evaluating self the way Elbow does explicitly. Nobody has articulated the software equivalent of object writing.

Where FDD Comes In

Failure Driven Development reframes failure as information rather than catastrophe. That is exactly the philosophical move the other fields make to enable generative work — they just make it at the psychological level rather than the architectural one.

Lamott’s shitty first drafts, Pattison’s no-self-editing rule, Cameron’s prohibition on re-reading morning pages — all of these are systems for making failure safe enough to be productive. FDD says the same thing at a deeper level: failure is not a deviation from the process, it’s the mechanism of the process.

The songwriting and writing teachers have practice without theory — they know the techniques work but haven’t fully articulated why. FDD is positioned to supply the theoretical grounding: the connection between psychological safety-to-fail and actual generative productivity is implicit in Goldberg and Pattison but never made explicit.

FDD could be the first framework in software that:

Names the generating/evaluating split explicitly in a programming context
Provides a concrete practice (analogous to object writing or morning pages) for the generative phase
Grounds it in a coherent epistemology rather than just craft wisdom
Distinguishes tactical failure-tolerance (agile’s “iterate fast”) from epistemic failure-embrace (“failure is how you find out what you need to know”)

That last distinction is the one that makes FDD genuinely new rather than just a restatement of agile. Agile tolerates failure as an unfortunate cost of moving quickly. FDD treats failure as the primary signal — the thing that tells you where the real problem lives.

Paul Tarvydas is the originator of Parts-Based Programming (PBP) and Zero Dependency (0D) component architecture. His book Failure Driven Development is available in progress on Leanpub at leanpub.com/failuredrivendevelopment. He writes at Programming Simplicity on Substack.

Appendix: Full Conversation

The following is the unedited conversation with Claude that generated the ideas in this article.

Paul: how does pat pattison teach brainstorming for songwriters

Claude: Pattison’s core brainstorming method is called object writing, and it’s the centerpiece of his book Writing Better Lyrics (1995). Here’s how it works:

The basic exercise

Pick a tangible object — a person, place, or thing — and do a timed free-write about it, keeping the writing anchored to all seven senses. Set a timer for 10 minutes, write whatever sensory impressions come to mind in a stream-of-consciousness style, and stop when the timer goes off. Don’t write in complete sentences, and above all don’t self-edit. If your mind veers off in different directions, go with it — as long as it stays sense-bound.

The seven senses

The five familiar senses (sight, sound, smell, taste, touch) plus two less obvious ones: organic sense (how your body feels internally — “butterflies in your stomach”) and kinesthetic sense (how your body moves in or relates to space — “the room was spinning”).

Why sense-bound writing specifically

In daily life we mostly stay at surface level. In object writing, your job is “to master the art of diving” — getting to the bottom of the sea, finding the shell, opening it, and finding the pearl inside. The idea is that abstract emotions become communicable only when grounded in concrete sensory experience that listeners can share.

The daily practice angle

Pattison advises setting your alarm 10 minutes earlier and doing object writing first thing in the morning. He warns against going over 10 minutes — if you use a longer session one day, you’ll use it as an excuse to skip the next day.

The title as brainstorming tool

Separate from object writing, Pattison also teaches using a title or hook as a brainstorming scaffold — it immediately suggests implicit concepts (the “DNA” of the title), and helps organize ideas into effective sections, making the process efficient while giving structure to what the verses can explore.

The “no free zone” for generating raw material

In his co-writing and classroom work, Pattison emphasizes a “NO-free zone” during the generative phase — no criticism, no shooting down ideas. The inner critic is explicitly told to stand down while material is being produced.

In short, his brainstorming philosophy is: bypass the conscious, judgmental mind by flooding the page with sense-specific concrete detail on a tight timer, then mine that raw material for lyric ideas.

Paul: how does jai joseph teach this

Claude: I’m not finding good results specifically on Jai Joseph/Josefs teaching brainstorming as a distinct topic — his book Writing Music for Hit Songs is focused primarily on melody, harmony, and musical craft rather than the lyric-brainstorming angle that Pattison emphasizes.

It’s possible you’re thinking of a different teacher, or perhaps a specific course or video where Josefs addresses idea generation. Could you give me a bit more context — is this from a book, a course, a YouTube video, or something else? That would help me find the right person and material.

Paul: any songwriting guru

Claude: Here are some of the major songwriting teachers and how they approach brainstorming/idea generation:

Pat Pattison (Berklee) — object writing, as covered above. Sense-bound timed free-writing to bypass the conscious mind.

Jason Blume — teaches a “title first” approach. Mine everyday conversation, overheard phrases, and clichés with a twist for title ideas. Keep a running list at all times; ideas are everywhere.

John Braheny (The Craft and Business of Songwriting) — emphasizes keeping an “idea file” — scraps of paper, recordings, journal entries — and revisiting them regularly. Raw material accumulates; you mine it later.

Ralph Murphy (ASCAP) — very Nashville-practical: start with the title, ask “what does this title promise the listener?” and brainstorm only what fulfills that promise. Ruthlessly cuts anything that doesn’t serve the title’s implied contract.

Jimmy Webb (Tunesmith) — more organic and romantic about it: walks, drives, daydreaming, letting the unconscious work. Less systematic than Pattison, more about creating conditions for inspiration — solitude, boredom, sensory experience.

Sheila Davis (The Songwriter’s Idea Book) — the most explicitly brainstorm-focused of the lot. Forty distinct strategies including free association, clustering/mind-mapping around a central word, “what if” scenarios, and working from images or photographs.

Berkeley’s Andrea Stolpe — teaches brainstorming from personal story: interview yourself about a specific emotional memory, extract concrete details, then find the universal in the specific.

The broad consensus across all of them: write before you edit, collect more than you need, and anchor abstract emotion in concrete specific detail. Pattison is the most systematic about the sensory-grounding piece; Davis is the most varied in her toolkit.

Is there a particular angle you’re developing this for — lyrics, melody, or the general creative process?

Paul: how about bookwriting?

Claude: Same basic territory — bypass the inner critic, generate raw material, organize later. Here are the main teachers:

Natalie Goldberg (Writing Down the Bones) — closest to Pattison in spirit. Timed “writing practice”: pick a prompt, keep your hand moving, don’t cross out, go for the jugular. The hand bypasses the censoring mind. Very Zen-influenced; she studied with a Zen teacher and treats writing practice like meditation.

Julia Cameron (The Artist’s Way) — Morning Pages: three longhand pages every morning, stream of consciousness, no re-reading. Not meant to be good writing — meant to drain the “brain sludge” so the real creative work can flow. Hugely influential across all creative fields.

Peter Elbow (Writing Without Teachers) — coined “freewriting” as a formal technique. Timed, uncensored, no stopping. Also teaches “cooking” — letting ideas sit and ferment before shaping them. Distinguishes the generating self from the editing self and insists they can’t operate simultaneously.

Anne Lamott (Bird by Bird) — “shitty first drafts.” Permission to write badly is the whole game. Also teaches extreme narrowing of focus: don’t write a book, write what you can see through a one-inch picture frame.

Stephen King (On Writing) — situational rather than plot-driven brainstorming. Put characters in a situation and watch what happens; don’t outline, just discover. Keeps a notebook but trusts his subconscious more than any system.

Dorothea Brande (Becoming a Writer, 1934) — arguably the original. Write immediately upon waking before the rational mind engages. Predates Cameron by fifty years with essentially the same insight.

The through-line across all of them is identical to the songwriting teachers: separate generation from evaluation, use time pressure or physical momentum to outrun the critic, and treat the first draft as raw material not finished product. Goldberg and Pattison are almost the same pedagogy applied to different crafts.

Paul: my sense is that brainstorming in software development is far less developed than in other fields

Claude: That’s a sharp observation, and I think you’re right. A few thoughts on why:

Why software brainstorming is underdeveloped

The dominant culture treats programming as engineering or mathematics — fields where rigor and correctness are the virtues, not generative looseness. The inner critic is baked into the tools: the compiler rejects your shitty first draft immediately. It’s hard to maintain “keep the hand moving, don’t cross out” when the environment is constantly evaluating you.

Also, the field conflates design brainstorming with implementation. Whiteboard sessions, user stories, sprint planning — these exist, but they’re mostly about requirements and architecture, not about the kind of raw generative thinking Pattison or Goldberg are after.

What does exist

Sketching / paper prototyping in UX/design (borrowed from design thinking)
“Spike” solutions — throwaway code to explore a problem space
Rubber duck debugging as a kind of dialogic thinking-aloud
Ward Cunningham’s CRC cards for object brainstorming
Some of the agile literature touches on it obliquely

What’s missing

Nobody in software has articulated the equivalent of “object writing” — a daily timed practice for generating design ideas, uncoupled from correctness. Nobody teaches programmers to separate the generative self from the evaluating self the way Pattison or Elbow do explicitly.

Your own work on 0D and PBP is arguably closer to this territory than most — treating diagrams and notations as a way to think before committing to implementation. DaS as a brainstorming medium, essentially.

Do you think the missing piece is a practice (like morning pages for coders) or a notationthat’s loose enough to support generative thinking without triggering the evaluating mind?

Paul: how about failure driven development (my leanpub book, unfinished)

Claude: Your FDD concept is directly relevant here, and potentially a significant contribution to this gap.

How FDD fits the brainstorming problem

The songwriting and writing teachers all share a core move: make it safe to produce bad output. Lamott’s “shitty first drafts,” Pattison’s timed writing with no self-editing, Cameron’s morning pages you’re not allowed to re-read. The psychological infrastructure is “failure is not just acceptable, it’s the mechanism.”

FDD says essentially the same thing at the architectural level — failure is information, not catastrophe. That’s the generative insight the software field is missing. Most programmers treat a failing test or a wrong design as something to be minimized and hidden; FDD reframes it as the driver.

What FDD could add that the others don’t have

The songwriting teachers have practice but no theory of why failure-tolerance works cognitively. You’re positioned to supply that — the connection between psychological safety-to-fail and actual generative productivity is implicit in Goldberg and Pattison but never made explicit.

FDD could be the first framework that:

Names the generative/evaluating split explicitly in a software context
Provides a practice (analogous to object writing or morning pages) for the generative phase
Grounds it in a coherent theory rather than just craft wisdom

The gap it fills

Agile tolerates failure tactically (iterate fast). FDD embraces failure epistemically — as the way you find out what you actually need to know. That’s a different and deeper claim.

Have you framed FDD explicitly in terms of separating the generative phase from the evaluating phase, or is that angle still implicit in the current draft?

One Language To Rule Them All

Paul Tarvydas — Thu, 04 Jun 2026 07:07:29 GMT

TL;DR The functional paradigm is not general-purpose. It is specialized notation aimed at classical physics and mathematics. We mistook it for a universal foundation and spent decades bolting onto it everything it was not designed to handle. The result is bloat — measured in orders of magnitude — and a habit of removing things that worked, replacing them with things that didn’t, and quietly re-introducing the originals under new names. We never measured whether any of this was worth it.

L;R

SICP — Structure and Interpretation of Computer Programs — is scaffolding for SICM, Structure and Interpretation of Classical Mechanics. SICM uses a programming notation to express classical mechanics. SICP builds that notation. Operating systems are scaffolding for SICP — they provide the environment in which functional programs run. Each layer solves a narrow problem well. None of it is general-purpose. It is a stack of specialized tools aimed at one target: mathematical, functional, deterministic computation.

This would be fine if we had recognized it for what it is. We did not. We declared the functional paradigm the foundation of all programming. When C made functional calling conventions standard practice for every subroutine, we stopped noticing that other conventions existed. The paradigm suited to one class of problems became the only paradigm considered for any problem.

The functional domain has a precise set of properties.

Equations are timeless. Functions are pure. State does not exist. Time does not pass. Order is irrelevant.

Classical physics is built on exactly these properties. SICP provides a notation for reasoning within these constraints. SICM uses that notation to express classical mechanics directly. The fit is exact because the domain and the notation share the same assumptions.

This is not how computers work. This is not how the internet works. This is how a single CPU works. This is how a single node in a network works. The moment you connect two CPUs, or two nodes, time reappears. State reappears. Order matters again. The functional paradigm describes one part of the machine accurately and says nothing useful about what happens between parts.

The problems began when we stretched the notation beyond its target. Re-assignment was the first major addition. In a pure functional system a variable holds one value. In the real world things change. Rather than reaching for a different notation suited to expressing change — state machines, for instance — we bolted re-assignment onto the functional paradigm. The guarantees the notation had offered began to erode. We did not get a more general tool. We got a worse functional tool with state stapled to the side.

Dynamic binding followed the same pattern. Early Lisp resolved variables at runtime, based on the call environment at the moment of execution. This was judged unpredictable and replaced with static scoping — variables resolved at compile time, based on position in the source. Static scoping made compile-time analysis possible. Type checkers and optimizers depend on it. The trade seemed like progress. Then we introduced JIT compilation. JIT makes decisions at runtime, based on what the program is actually doing. That is runtime dynamism. That is what dynamic binding did. We removed runtime flexibility in the 1960s, spent decades building tooling that assumed its absence, then spent more decades building tooling to recover it. Lisp 1.5 had this in 1962. We took a very long detour back to the same place.

Lisp 1.5, in 1962, did the core job in approximately 27 kilobytes. It had garbage collection, recursion, and a runtime evaluator. It was powerful enough to run a proof assistant. VisiCalc, in 1979, invented the spreadsheet paradigm in 20 kilobytes. Unix V1, in 1971, ran the entire operating system — kernel, shell, tools — in 24 kilobytes of total memory. Turbo Pascal 1.0, in 1983, delivered a complete IDE — editor, compiler, linker, all libraries — in a single 38-kilobyte file. These were not toys. They changed the world.

Today we speak in gigabytes. The Linux kernel exceeds 30 million lines of source code. A modern language runtime requires hundreds of megabytes before a user program loads. The footprint grew by four to five orders of magnitude. We did not ask whether we were getting four to five orders of magnitude of additional value. We assumed we were.

Sector Lisp answers the question. Sector Lisp is a modern Lisp implementation with garbage collection, written in 223 lines of assembly. Its footprint is 436 bytes. It runs the proof assistant that shipped with Lisp 1.5. The difference between gigabytes and 436 bytes is not just hardware improvement. It is the removal of everything added to function-based programming languages in the attempt to make the functional paradigm general-purpose. Sector Lisp does not allow re-assignment. It does exactly what the pure functional paradigm does, nothing more. The bloat was the generalization. The core was always small.

Type checking is the most visible symptom. We have spent decades elaborating type systems, adding annotations, and refining inference engines. The argument is that type checking catches errors before they reach production. Robert Smallshire has cited research suggesting type checking catches approximately 3 percent of real-world errors. Whether that number is exact or not, it raises a question we have not asked seriously: what did the other 97 percent cost us, and what were we doing before type checking existed?

Sketchpad, in 1963, pioneered the graphical user interface and object-oriented programming. VisiCalc transformed the personal computer into a business tool. Unix built the foundation the internet runs on. None of these were built with automated type checking. Their creators were working in notations suited to their domains — small enough to hold in one head, expressive enough to say what they meant directly. Type systems grew because languages grew because the problem domain kept expanding beyond what the original notation was designed for. With multiple small domain-specific notations, much of what the type system guards against would not exist in the first place.

This is not an argument against type checking. It is an argument that type checking is a symptom, not a solution. The solution is to stop forcing every problem into a notation designed for a different class of problems. Build or borrow a notation that fits. Small notations can be held in one head. Small notations do not require elaborate annotation to stay consistent. Small notations, as Turbo Pascal and VisiCalc and Unix V1 showed, can change the world in under 40 kilobytes.

We did not get here by making bad decisions. We made locally reasonable decisions without measuring their cumulative cost. Each addition to the functional paradigm made sense in isolation. But we kept adding and never subtracted, never benchmarked against the baseline, never asked what we were comparing against. The baseline was 20 kilobytes and a spreadsheet that changed the world. We owe it to ourselves to compare honestly.

We Painted Ourselves Into a Corner

Paul Tarvydas — Wed, 03 Jun 2026 13:00:24 GMT

TL;DR Synchronous, sequential notation has colonized all of modern programming. Every mainstream language — Python, JavaScript, Haskell, Rust, Clojure — is the same at the core: sync. Once you commit to sync, asynchrony is not just inconvenient to recover; it is structurally unrecoverable. We have compounded this by treating analysis-oriented notation as if it were expression-oriented notation. The result is that we are solving 21st-century problems with 20th-century tools, pasting bandaids on bandaids, and calling it progress.

L;R

Python, JavaScript, Haskell, Rust, Clojure. These languages look different. They feel different. Their communities are different. But they are the same at the core: every one of them is built on the synchronous, sequential paradigm. This paradigm is not a feature of these languages — it is the water they swim in. It permeates every language decision, every library design, every idiom. The differences between these languages are lipstick on the same pig.

The mechanism is simple. As soon as you write a function that calls another function, you have committed to synchronous control flow. The callee runs. The caller waits. Time is implicit. Order is enforced. On paper — where the laws of physics do not apply to notation — this works fine as a simplification. But when you map this onto real, physical hardware, the implicit assumptions start leaking. The hardware does not wait. The network does not wait. The user does not wait. And no amount of async/await sugar, thread libraries, or reactive frameworks recovers what was lost when you wrote that first function call. You cannot put asynchrony back into a notation that has already committed it away.

This is not a theoretical complaint. It shows up as “callback hell.” It shows up as cache coherence problems and thread-safety rituals. It shows up as the entire edifice of concurrency primitives — semaphores, mutexes, futures, promises — which exist not because concurrency is complicated, but because we chose a notation that cannot express it directly, and then spent decades building scaffolding to work around that choice. We painted ourselves into a corner and responded by building more elaborate furniture to stand on.

A five-year-old taking piano lessons understands something that a senior software engineer, working in a modern language, cannot directly express. The child learns to get the left hand and the right hand to play different notes at the same time — not sequentially, not taking turns, but concurrently, each following its own rhythm. The child learns hard realtime: notes must land at exactly the right moment. The child learns a notation — standard musical notation — that captures all of this succinctly. Duration, timing, concurrency, relative ordering: one page of sheet music expresses what no mainstream programming language can express without significant ceremony. The five-year-old’s intuition is a tell. The problem is not complicated. Our notation made it complicated.

We have not only chosen a paradigm poorly suited to concurrency. We have allowed the demands of analysis to colonize the demands of expression. These are different things. A notation suited to analyzing a concept is not necessarily suited to expressing that concept in a running system, and vice versa. David Harel’s Statecharts are the clearest demonstration I know of how analysis can destroy the very thing it sets out to formalize. Harel’s original statechart paper gave us a notation that expressed asynchronous parallelism directly. States, transitions, hierarchy, concurrency — all visible, all expressible in a diagram. His follow-up micro-semantics paper formalized the concept analytically. In doing so, it forced sequentiality onto the model. The asynchronous parallelism of Statecharts was converted into synchronous concurrency. The formalization was correct analytically and useless practically. I discovered this early on, trying to use the formalized version in a real, live, asynchronous system. The analysis had eaten the property I needed.

The same pattern appears in pBFT — Castro and Liskov’s 1999 solution to the Byzantine Generals Problem, which influenced several blockchain implementations.. The concept at the heart of pBFT is actually two concepts: cryptographic constructs for encryption, and state-machine constructs for the ebb and flow of node participation, drop-in, and drop-out. The cryptographic part is naturally expressed in mathematical, functional notation. The state-machine part is naturally expressed as a state machine — or better, a Statechart. But the paper was written in one notation. The state-machine behavior was forced into the same synchronous sequential framework as the encryption. The extra work required to do this was not free. The brain power spent on the impedance mismatch was brain power not spent on other problems.

A simpler example: I built a three-state state machine and expressed it as a diagram. The same machine, transcribed into Python, runs to approximately sixty lines of code. A seasoned Python programmer could trim that number. But no amount of trimming recovers what the diagram gives for free: the visual structure of the states, the transitions, the conditions, all immediately apparent to anyone who looks. The Python version is not wrong. It is a different notation, and it obfuscates the information that the diagram expresses directly. We use the wrong notation and then spend effort reconstructing what a better notation would have given us at no cost.

The same principle, this time with a textual notation: Forth Haiku. Two lines of Forth Haiku control a GPU as well as a hundred lines of GLSL and JavaScript. This is not a party trick. It is a demonstration that a notation suited to its domain can be radically more expressive than a general-purpose notation applied to the same domain. Critically, generalizing Forth Haiku — trying to make it do everything — would produce a mess. Exponential growth of code. The mess is a tell. The right lesson is not to generalize Forth Haiku. The right lesson is that domain-specific notation, applied with discipline, beats general-purpose notation applied with force.

Casey Muratori and the Handmade Network have been making a version of this argument from the direction of games programming: our current programming languages are not well suited to building games. The gaming industry’s response has been to work around the languages, not with them. This is the same pattern everywhere. The workarounds are not solutions. They are evidence that the foundation is wrong.

We tell ourselves we are standing on the shoulders of giants. In many cases we are. But the giants were solving single-CPU, synchronous, sequential problems. Their shoulders point in one direction. The problems of the 21st century — distributed systems, asynchronous networks, multi-core concurrency, real-time interaction — are in a different direction entirely. Continuing to build on those shoulders, in those notations, is not progress. It is the definition of doing the same thing over and over and expecting different results.

The prescription is not a new general-purpose language. The prescription is to stop insisting on one. Use synchronous notation where synchronous notation fits: mathematical expression, encryption, pure function. Use state-based notation where state-based notation fits: control flow, lifecycle, protocol. Use diagram-based notation where diagrams carry information that text cannot. Use whatever notation is suited to the part of the problem you are solving. Match the notation to the domain, not the domain to the notation. Build a small, cheap, custom notation when none of the existing ones fit. OhmJS and PEG parsers make this as accessible as writing a regular expression.

We have the tools. We have the intuition — five-year-olds have it. What we are missing is the permission to stop treating one notation as the answer to every question.

References

Statecharts PWL video
microsemantics of Statecharts
Muratori “The Big OOPs - Anatomy of a Thirty-Five Year Mistake”
Forth Haiku video playlist
3 state state machine video (convert state machine diagram to Python)

Words

Paul Tarvydas — Mon, 01 Jun 2026 12:03:33 GMT

One must be careful to understand that words carry much more baggage than just their literal dictionary meaning.

In songwriting, I was taught to lean heavily on the thesaurus for several reasons, such as
- syllable count, and syllable emphasis to match underlying melody flow
- plosives, fricatives, etc., to evoke “feeling” that matches with the rest of the intent of the song
- brainstorming - just looking at synonyms can trigger thoughts and new ideas on a custom / personal basis
- rhymes and B-rhymes
- imagery

There are lots of examples of this kind of thing, but I most reminded of Robert Frost’s “The Span of Life” - a two-line poem that evokes lots of imagery:

The old dog barks backwards without getting up.
I can remember when he was a pup.

For example, note that “barks” ends in a fricative “s” which allows a smooth flow into “backwards”. Both words begin with a plosive “b” which makes the phrase pop out and evoke the image of barking. There’s lots more going on here…

Lispers tend to use long names in code, whereas non-lispers see this as being verbose. “Ret” instead of “return” can be a readability issue as well as a writability issue (akin to the use of Greek letters in math).

Inference: each consumer of words can get a completely different meaning from a phrase, hence, one cannot always achieve perfect transmission of intent. Great songwriters make their songs touch many people, great software architects arrange designs in ways that are more readable. Great code is not always great architecture. Code is for machines. Arrangement of code to express design intent is for people.

Computation vs. The Arrow of Time

Paul Tarvydas — Mon, 01 Jun 2026 02:09:40 GMT

In the book “Order Out of Chaos” authors Ilya Prigogene (Nobel laureate) and Isabelle Stengers state that functional thinking - function-based notation - has set physics back by 100 years.

I feel that the same is happening in Computer Science.

I used to think that Computer Science was a study of the way to express what reprogrammable machines (RMs) could do.

I no longer think so. I see Computer Science as the study of how to formalize computational thinking and of how to use reprogrammable machines as building materials to build machines for computation, i.e. “compute-ers” instead of a study of what reprogrammable machines are capable of.

Lisp 1.5 was an exposition of how to use assembler-based CPUs to build machines for computing within the functional paradigm, where only the result matters and the zig-zag, irreversible path of how that result was achieved is elided and ignored. In my view, Computer Science is just an extension and further refinement and modernization of this notion.

I see this as a form of notation worship. The intent seems to be to thread every problem through the eye of the needle of the synchronous, sequential paradigm, regardless of how much accidental complexity this causes.

This is but a one-way mapping. You can use CPUs to create machines for computation, but you can’t use synchronous, sequential computation to express the composition of the asynchronous parts that make up a laptop or an internet. You can use current synchronous, sequential programming languages to create parts of a laptop - e.g. the CPU-based part - or parts of the internet (i.e. one node) - but you can’t actually express the composition of the whole, since that involves components that run asynchronously - which is - by definition - swept off the table by the underlying model of synchronous, sequential paradigm.

To express async composition, we use electronic schematics. Schematics allow for the combination of asynchronous units, like disks, CPUs, keyboards, displays, etc. Schematics ain’t perfect as a notation, but at least they don’t prematurely discard asynchronous non-sequential operation.

Inventing constructs like “async/await” in programming languages allows us to describe reactive elements that work synchronously internally but can only be coupled together in a laborious, assembler-like fashion, into compositions of asynchronously-operating units. This will never achieve the expression of the composition of async elements - something “above” and outside of the capabilities of what we currently call programming languages. Programming deals only with the synchronous, sequential action of a single node in an asynchronous system, it does not deal with the whole async system.

Multi-threading as we know it cannot be parallelism, it is only a collection of interleaved functional threads that work so quickly as to fool us into perceiving that they are working in parallel.

Example: Prolog is a non-functional language. Prolog uses synchronous, sequential programming languages, of the ilk of assembler, C, Haskell, Clojure, Rust, etc., as building materials to construct an engine for relational expression and thinking. Prolog builds relational engines using synchronous, sequential programming languages, but can never express whole parallel relational machines since asynchronousity has already been removed due to the underlying synchronous, sequential substrate.

I assert that continuing to use current synchronous, sequential programming languages to deal with asynchronous systems is a death march. It only looks like we are dealing with asynchronous, non-sequential issues, but, by using synchronous, sequential programming languages we remove asynchronousity and cherry pick problems and solutions that are already amenable to that kind of approach - a thin slice of what’s actually possible. This kind of cherry picking is causing us to miss the forest for the trees.

Arrow of time: the synchronous, sequential paradigm is a spherical cow that excludes the arrow of time for computational convenience. Once you throw out the arrow of time, you can’t put it back. You can put fake constructs like timestamps into the synchronous, sequential expression of systems, but in reality, the arrow of time is gone.

Concurrency Is Not Parallelism

Paul Tarvydas — Tue, 26 May 2026 08:46:23 GMT

TL;DR

In casual English, “concurrency” and “parallelism” are used interchangeably. In computer science, the distinction is precise and consequential. Synchronous functions cannot — as in impossible — express asynchronous activities. Multi-threading fakes parallelism; PBP (0D) designs software that is ready for true parallelism from the start.

L;R

Analogy

Consider what a data record looks like in memory: A struct (class, record) written in code looks benign. Mapped onto 64-bit hardware and emitted as aligned data, gaps appear in the memory layout between fields.

Some languages and compilers allow programmers to “pack” the data to eliminate those gaps. This saves memory but costs compute cycles, because the CPU works harder to access data not aligned on 64-bit boundaries.

The same phenomenon appears in multi-threading — except the gaps are in the dimension of time, not space. The principle is identical: optimization choices in one dimension create costs in another.

Multi-Threading Fakes Parallelism

Each “thread” is an isolated function. Such functions call other functions within the same thread in a synchronous, sequential manner.

Extra software — the operating system — divvies up CPU time and hands slices of it to all threads running on the same machine.

This happens fast enough that humans perceive the threads as running in parallel. They are not. They run sequentially, and slower than they could, due to the overhead of the operating system.

We have been extracting performance from this model by adding complex caches, multiple cores, and cache coherency logic. Code running in the L1 caches of separate cores can run in parallel, but becomes sequential and synchronous the moment it accesses data outside those caches. One machine does not run multiple threads in a truly parallel manner.

True Parallelism Requires Dedicated CPUs

True parallelism means one CPU per thread. In that case, no operating system overhead is needed on each machine.

This was the goal of hardware architects in the early days of computing. CPUs and whole computers were too expensive to justify it then.

Today, CPUs are cheap. Arduinos, ESP32s, and Raspberry Pis are cheap. The economic justification for complicated software that squeezes cycles out of shared hardware is gone.

The internet already works this way. Internet nodes are separate, totally isolated computers that run at their own speed and exchange blobs of data as messages.

We continue using old-fashioned shared-memory ideas because, as Grace Hopper put it, “we’ve always done it this way”.

PBP — Parts-Based Programming

PBP (0D) simulates software meant to run in parallel, on a single machine, in a way that is ready to split off onto separate machines.

The key fact: synchronous functions cannot express asynchronous activities. Fake parallelism expressed as concurrency in the functional paradigm works the way Disney cartoons work — by fooling human perception into seeing motion that is not there.

In the early days of stand-alone computers, we chose small-grained memory sharing over message passing. The earliest symptom of that choice was “thread safety”. Symptoms have been popping up in whack-a-mole fashion ever since — callback hell, the Mars Pathfinder fiasco — and each time, we applied a band-aid instead of fixing the basic problem. The problems of thread safety evaporate when isolated computers are used. Programming complexity drops when thread safety no longer inflicts itself on thought patterns, language design, and operating system architecture.

Early cartridge-based gaming systems had no operating systems and were fundamentally simpler to program. The invention of the operating system was a soft substitute for a machine with multiple slots, each with its own isolated CPU, with mechanical switches to route shared hardware resources — displays, keyboards, joysticks — between programs. We built the switch in software and called it an OS. PBP goes back to the hardware intuition: isolated components, explicit wiring, message passing. No shared memory. No thread safety. No operating system required.

FDD - Failure Driven Development

Paul Tarvydas — Sun, 24 May 2026 21:57:26 GMT

We can now stop worrying about “code” and worry a lot more about “design”. That’s the main point of Failure Driven Development.

PBP is one of the tools for FDD - snap parts together like LEGO blocks and see if you like the result. If not, knock it all down and start all over again. Repeat numerous times.

I’ve been using Claude to argue with me. To be a foil that espouses the “functional approach” to writing code.

The biggest fall-out of these brain-storming sessions is the observation that PBP goes a step further than Erlang by providing “topology blindness”. It is a core term in the PBP/0D vocabulary, describing the property that components do not know their own neighbors and that wiring is controlled by the parent container rather than by the components themselves.

To implement topology blindness, it is more convenient to roll your own multi-tasking kernel, instead of relying on existing thread libraries, and, you need to create a system of two-tier “parts” that I call Container parts and Leaf parts.

Ideas for Porting PBP to Go

Paul Tarvydas — Sun, 24 May 2026 21:48:09 GMT

I’ve written the PBP kernel in a pseudo-language and generate Python, JS and CL. I think that if you were to point your LLM at

and gave it the Python versions

it might be able to infer the Go version.

Maybe you also need to give it the Ohm grammar file

https://github.com/guitarvydas/pbp-dev/blob/main/kernel/emit.ohm

and the Python rewrite rules

https://github.com/guitarvydas/pbp-dev/blob/main/kernel/emitPython.rwr

I suspect that using words like “concurrent” and “process” and “thread” might get an LLM to generate convoluted / wrong code. 0D.rt implements its own form of multi-processing from scratch - don’t let an LLM use preconceived ideas about what threads are. Threading needs only 10’s of lines of code - all existing thread libraries that I know of (including Go) have turned this into a behemoth, steaming pile of complexity.

If you do need to use words like these, tell the LLM to use a mutual multi-tasking model (aka “green threads”) with NO shared memory. A lot of the cancerous complexity growth has befallen us because of the use of implicit memory sharing (starting with the concept of “thread safety”). When you strip the underlying memory sharing assumption out, the code becomes orders of magnitude simpler. The first kernel I studied was 1/2 page of assembler code.

Forth Haiku Compendium

Paul Tarvydas — Sun, 17 May 2026 08:35:49 GMT

Forth Haiku Compendium

These have been already published in substack and on YouTube.

This is but a summary for convenience.

Forth Haiku Analysis Part 1
Forth Haiku Analysis Part 2
Forth Haiku Optimizer
Forth Haiku CPU and GPU Pipelines
What I’ve Learned From Forth Haiku Thus Far

youtube playlist (duplicates of above videos, without the rest of the text supplied in the substack articles)
Forth Haiku youtube playlist

You Already Know PBP

Wed, 13 May 2026 21:49:31 GMT

TL;DR

A Unix pipeline is a PBP Container. You just never generalized it.

L;R

When you write ls | grep foo | wc -l, you are doing something remarkable without thinking about it. Three programs run concurrently. None of them knows what it is connected to. grep does not call wc. It writes to stdout and forgets. The wiring — who feeds whom — is declared outside the programs, on the command line, by you.

That is PBP. Parts Based Programming.

Each command in the pipeline is a Part. It has an input port (stdin) and an output port (stdout) and no knowledge of the pipeline it inhabits. The pipeline itself is a Container — it knows the topology; its Parts do not. A Part can itself be a shell script that contains another pipeline, making it a Container in turn. The hierarchy composes.

A sequential pipeline is one kind of Container. PBP Containers are more general — the wiring inside can fan out, loop back, or converge, not just chain. But the Unix pipeline is enough to show you the idea: topology declared externally, components oblivious to their neighbors, communication by message rather than by call.

Where Pipes Stop

Unix pipes prove the concept but the syntax freezes your thinking. Shell scripts can call other shell scripts. File descriptors can serve as ports. The composition is there if you work at it. But the text syntax nudges you toward chains — one program feeding the next, left to right — because that is what the | character expresses naturally. Fan-out, fan-in, and feedback are possible but awkward to write and hard to see.

PBP uses diagrammatic syntax. Fan-out, feedback, and arbitrary topologies are drawn, not written. The diagram makes the structure visible and natural to think about, not a clever trick you have to construct from text primitives.

The second difference is what gets passed. Pipes carry bytes. PBP passes mevents — two-part messages consisting of a tag and an unstructured byte payload. Tag is port name; payload is data. This is a key/value pair, and the key is what makes multiple named input and output ports thinkable. You stop reasoning about a stream and start reasoning about discrete, labelled messages arriving on specific ports. That shift is what lets you break out of the chain-of-processes paradigm entirely.

The one-input-queue-per-Part rule follows from this. Each Part receives mevents in arrival order on a single queue. Mevent ordering becomes something you can reason about explicitly, rather than something you manage through ad hoc state variables scattered across your code.

The third difference is weight. Unix pipes are OS-level — you pay for process creation, scheduling, and kernel context switches. PBP’s process model is defined simply enough that the entire kernel can be implemented in a small amount of Python. No operating system required.

Why Not Just Use CALL/RETURN

The reason software does not work this way by default is CALL/RETURN. Functions call functions, wait for results, and return. That model made sense on a single CPU in 1970. It makes less sense when your components are threads, processes, or machines on a network. CALL/RETURN forces synchrony onto a world that is not synchronous.

Unix got this right in 1973 and then software forgot the lesson.

References

PBP Cookbook beginning with simple Hello World demo and installation of tools and kernel
PBP tools and kernel development , see kernel/kernel.drawio and kernel/*.rtfor kernel sources (use drawio to read/edit kernel.drawio) ; collaborators welcome

The Limits of Mathematical Computation Applied to Physical Hardware

Paul Tarvydas — Sun, 03 May 2026 13:17:06 GMT

TL;DR

Every executable program can be described as a formal language. The converse does not hold. Not every capability of physical hardware can be expressed in a mathematical model of computation. This is a one-way street, and the traffic has been going the wrong way for fifty years.

L;R

The Statement That Feels Obviously True

Everything executable by a computer is a formal language. This is true, and it feels complete — as if it closes the question. If every program is formal, and formal languages are the subject of computer science, then computer science covers everything a computer can do. The logic seems airtight.

It isn’t. The statement is a one-way relationship. It says nothing about the converse. The converse — that every capability of physical hardware can be expressed in a formal, mathematical language — does not follow, and is false. The word “formal” is doing double duty without anyone noticing: assembler is formal in the sense of being precisely specified, but modern programming languages are formal in the sense of being mathematical abstractions independent of physical hardware. Conflating the two meanings makes the one-way street look two-way.

Interrupts: The Counterexample That Cannot Be Argued Away

An interrupt is a hardware event that stops the CPU at an arbitrary moment — determined by the outside world, not by the program — saves machine state, executes a handler, restores state, and resumes. The program did not call anything. There is no caller, no return value, no scheduled moment. The outside world reached into the machine between two instructions and redirected it.

The immediate objection is: you can write a callback that responds to an interrupt. Yes, you can. But the callback is not the interrupt. A callback is a function, and a function in the mathematical sense is synchronous and side-effect-free by definition. An interrupt handler is neither. It has side effects by definition — it modifies machine state — and it fires asynchronously, at a moment the program did not choose and cannot predict. You can bolt a callback onto the interrupt mechanism, but the asynchronous, uninvited, side-effecting hardware event underneath it remains outside the mathematical model.

Mathematical computation is a closed system. It maps inputs to outputs on its own schedule. An interrupt is the outside world breaking into that schedule uninvited. A closed system has no vocabulary for this. You can simulate it — polling, cooperative yielding, continuation-passing — but simulation changes what is being modeled. Polling is not an interrupt. It is the program asking, at moments of its own choosing, whether something happened. An interrupt does not ask permission.

Where the Trade Was Made

The assembler-to-C transition is where the physical model was quietly replaced by the mathematical one. Assembler is the machine’s own notation: every instruction directly specifies a physical state change, including interrupt vectors, privileged operations, and cycle-exact timing. C replaced this with a mathematical abstraction: functions, typed values, a memory model, a calling convention. The abstraction is useful — it raised the floor enormously. But it lowered the ceiling. Capabilities that were native and direct in assembler became impossible or required operating system mediation in C.

Every language since — C++, Java, Python, Haskell, Rust — has refined the mathematical model. None has gone back to recover what was traded away at the assembler-to-C boundary. The industry has spent fifty years polishing an abstraction that is categorically mismatched with the physical hardware it runs on, and has celebrated the polish as progress.

The mismatch does not matter for batch computation: sort this list, compute this hash, prove this theorem. The machine waits. But for real-time systems, distributed networks, interrupt-driven hardware, and any system embedded in a world that keeps happening on its own schedule — the mathematical model is not an approximation of the physical reality. It is a different thing entirely, and no amount of additional mathematical machinery brings it closer. The machinery is inside the closed system. The interrupt comes from outside.

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Discord: https://discord.gg/65YZUh6Jpq

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

Paid subscriptions are a voluntary way to support this work.

Leave a comment

Subscribe now

From State Machine Diagram to Python

Paul Tarvydas — Sun, 03 May 2026 12:08:05 GMT

I walk through a simple three-state state machine with an idle state and two “wait for recrossing” states, showing how transitions fire based on guards like x ＞ max or x ＜ min (with e encapsulating environment values such as x, max, min).

I demonstrate converting the diagram into a textual intermediate representation called SM and then generating equivalent Python code with enter, step, and exit sections per state.

I explain how each event triggers transition tests, runs transition code (e.g., e.reverse), exits the current state, and enters the next state, or otherwise falls through to remain in the current state.

I note that the idle state has two mutually exclusive transitions. I want to enforce that only one fires by adding returns after a transition. To accomplish this, I update the T2T rewrite rules in sm-metapy.rwr to insert returns in generated code.

I note that the Python is not optimized but aims to stay true to the diagram, and mention experimental, not-yet-debugged work applying these drawings to a collision detector for the PBP Pong project.

00:00 Three State Overview
00:58 Dot SM Text Format
01:35 States Enter Step Exit
02:39 Guards And Transitions
03:18 Generated Python Code
04:22 Ensuring Single Transition
05:11 Updating The Code Emitter
06:02 Results And Next Steps

code repository: https://github.com/guitarvydas/sm-pbp

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Discord: https://discord.gg/65YZUh6Jpq

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

Paid subscriptions are a voluntary way to support this work.

Subscribe now

Leave a comment

Source Code Control Doesn’t Need to Store Source Code

Paul Tarvydas — Sun, 26 Apr 2026 13:37:06 GMT

TL;DR — Source code control only needs to store enough syntactic and semantic information to reconstruct human-readable form on checkout. We assumed otherwise because 20th-century CPUs were too slow to make transformation practical. That assumption is now obsolete.

L;R

The Assumption We Never Questioned

Source code control systems store text files. That’s the unexamined assumption baked into every tool from SCCS to Git. The text file is treated as the ground truth. What you check in is what gets stored. What gets stored is what you check out.

This assumption was born of necessity. In the 20th century, CPU cycles were expensive. Spending them on tooling was a luxury most shops couldn’t afford. So we stored source “as is” — static, human-readable, character-for-character identical on the way in and out.

That constraint no longer exists. We haven’t updated our tools to reflect that.

What Source Code Control Actually Needs to Do

Source code control has one job: preserve enough syntactic and semantic information to reconstruct the source faithfully.

It does not need to preserve the exact text representation. It needs to preserve the meaning and structure. The human-readable form is a rendering of that structure — not the structure itself.

This is the insight behind projectional editing. A projectional editor stores an AST or semantic graph, then renders it into whatever human-readable form is appropriate for the current task. The stored form and the displayed form are decoupled.

Source code control can work the same way. Check-in applies a transformation: source text → normalized machine-readable form. Checkout applies the inverse: machine-readable form → source text (or any other rendering).

Lisp Pointed at This Decades Ago

Lisp is worth examining here. A Lisp program is already close to its own AST. Everything normalizes down to either a function application or an atomic object. The s-expression syntax is a nearly direct serialization of the semantic tree.

This is why Lisp macros are powerful: the code is the data structure. Transformations over code are just transformations over lists.

Lisp didn’t go far enough — it still stores and transmits s-expressions as text — but it identified the right level of abstraction. The canonical form should be the semantic structure, not a particular textual rendering of it.

Factbases: Flatter Than Lisp

Lisp normalizes to a recursive structure. There is a deeper normalization.

The triple:

relation(subject, object).

This fragments meaning into atomic elements that carry no embedded structure. The elements can appear in any order. No element points to another in the low-level sense. A subject is an identifier — a name. An object is an identifier. Neither is a hard-coded address. Neither encodes position. A reference in a factbase is an indirection, not a pointer.

Prolog works with this representation. Prolog expends CPU cycles to infer structure from it.

Consider encoding the fact that variable x is an integer with value 42:

type(x, int).
value(x, 42).

This is identical in meaning to:

value(x, 42).
type(x, int).

Order doesn’t matter. There are no pointers. There is no tree to traverse. There is only a set of atomic facts and an inference engine that can assemble them into whatever structure a query demands.

From those two facts, inference can reconstruct:

var x: int = 42

The concise, human-readable form is derived, not stored. The stored form is the flat factbase. The readable form is a rendering.

This is exactly the pattern a source code control system could exploit. Store the factbase. Render on checkout. The rendering is a query over the facts — a transformation, not a retrieval.

What Factbases Buy Over Lisp

Lisp’s s-expressions preserve tree structure. The parent-child relationship is encoded in nesting. To change the structure, you change the nesting.

A factbase has no nesting. Structure is inferred, not stored. This means:

Adding a new relation to an existing subject requires no restructuring. You append a fact.
Querying across subjects requires no pointer traversal. You pattern-match.
Diffing two factbases is a set operation — which facts were added, which removed — not a tree diff.

There is a further practical consequence. Because facts are order-independent, a factbase can be stored in sorted form. Sorting does not scramble the semantic information — any ordering retains the full semantics. But a canonically sorted factbase is far more amenable to existing diff and git tooling than raw source text. Two versions of a program that differ in one relation will produce a clean, minimal diff over their sorted factbases. The same change in source text might produce a noisy diff spanning multiple lines, or no diff at all if the change was a refactor that preserved textual structure while altering meaning. Sorting is free. The improvement to diff quality is not.

This means the proposal does not require replacing git. Git can remain exactly as it is. What changes is what git is given to store. Feed git a canonically sorted factbase instead of raw source text, and git’s existing diff, merge, and history machinery works better than it ever did on source. The transformation happens at the boundary — on check-in and checkout — and git operates on the normalized form without needing to know anything changed.

A semantic diff of two versions of a program becomes: what facts changed? Not: what characters changed. Not even: what AST nodes changed. What relations changed.

That is a diff at the level of meaning.

The CPU Trade

Prolog infers. Inference costs CPU cycles.

In 1980, this cost was prohibitive for routine tooling. Today it is not. A factbase representing a large codebase is still a small dataset by modern standards. The inference required to reconstruct human-readable form from a factbase is well within what current hardware makes trivial.

We are not proposing anything computationally exotic. We are proposing that tools run a Prolog query on checkout instead of copying bytes.

Inferencing Is Not Prolog-Specific

Prolog is a convenient syntax for expressing inferencing. It is not the only way to do it.

Nils Holm wrote a complete Prolog inferencer in Scheme and explained it in approximately six slides worth of code — “Prolog Control in Six Slides” (https://www.t3x.org/prolog6/). The point is not the language. The point is the size: a working inferencer consists of a small amount of code.

I ported Holm’s inferencer manually to Common Lisp (https://github.com/guitarvydas/cl-holm-prolog) and again to Javascript using OhmJS (https://github.com/guitarvydas/js-prolog). The Javascript port includes a diary of the porting process. These ports exist not to produce production inference engines but to demonstrate that the mechanism is simple enough to carry across languages by hand.

An inferencer can be written in any language. Prolog syntax is convenient — relations expressed as relation(subject, object) read naturally and the unification semantics are clean — but the syntax is separable from the mechanism. If Prolog syntax is an obstacle, replace it. The inferencing still works.

MiniKanren: A Different Trade

MiniKanren (minikanren.org) is a family of inference systems that make a different computational trade than Prolog.

Prolog expends CPU cycles for backtracking — it searches a space of possible solutions by trying, failing, and retrying. MiniKanren avoids backtracking by expending space instead. It represents the search space explicitly and explores it without the overhead of backtrack-and-retry.

Both achieve inferencing. They make different trade-offs between CPU and memory. In the context of source code control — where the factbases are relatively small and queries run at checkout time, not in inner loops — the trade-off is largely academic. Either approach works.

The practical point is: inferencing is a solved problem, it is small enough to port by hand, and the implementation language does not matter. A source code control system that stores factbases and runs inference on checkout is not proposing exotic machinery. It is proposing ordinary programming with a different data model.

Transformations on the Way In and Out

There is no rule that says a version control system must store source verbatim.

A VCS can apply a transformation pipeline on check-in: parse the source, extract the semantic structure, store a normalized form. On checkout, the inverse pipeline runs: take the normalized form, render it into whatever human-readable shape the developer needs.

Those two shapes need not be identical. A junior developer might get a more verbose, annotated rendering. A senior developer might get a compact, dense form. A code reviewer might get a diff at the semantic level rather than the text level — showing what changed structurally, not just what characters differ.

None of this requires storing anything extra. It just requires running a transformation on checkout.

Why We Didn’t Think This Way

CPU cycles were the constraint. In 1975, spending processor time on pretty-printing or semantic reconstruction at checkout was unacceptable overhead. Tools had to be fast. Fast meant: don’t transform, just copy bytes.

That decision calcified into assumption. The assumption calcified into convention. The convention calcified into “the way source control works.”

We designed around a bottleneck that no longer exists.

What Becomes Possible

Once check-in and checkout are transformation boundaries, several things open up:

Semantic diffing. Compare ASTs or factbases, not character streams. Detect that a function was renamed even if it moved to a different file. Know which relations changed, not which lines changed.

Multiple renderings of the same codebase. One stored form, many views. Render for documentation, for review, for onboarding, for debugging — each optimized for its purpose.

Notation independence. Store the semantic graph or factbase. Render into Python syntax, or Lisp syntax, or a diagram, or a table. The notation becomes a view over the model, not the model itself.

Programmatic normalization. Formatting debates disappear. The canonical form is the semantic structure. Human-readable renderings are generated, not hand-maintained.

The Deeper Point

We built 20th-century tools under 20th-century constraints. We then treated those tools as definitions of what source code control is, rather than as solutions to problems that no longer exist in the same form.

Source code control is not “store text files and track diffs.” That’s an implementation that made sense under specific historical conditions.

Source code control is “preserve enough information to reconstruct the program.” How we store that information, and what form we present it in, are engineering choices — not axioms.

The computers are fast enough now. The question is whether we’re willing to rethink the tools.

Appendix: Working SWI-Prolog Code

Three files. The inference code is render.pl. The factbases are separate.

render.pl

render(Var, Result) :-
    type(Var, Type),
    value(Var, Val),
    format(atom(Result), 'var ~w : ~w = ~w', [Var, Type, Val]).

render_all :-
    forall(type(Var, _), (render(Var, R), writeln(R))).

facts1.pl — sorted

:- discontiguous type/2, value/2.
type(x, int).
type(y, float).
value(x, 42).
value(y, 99).

facts2.pl — reverse-sorted

:- discontiguous type/2, value/2.
value(y, 99).
value(x, 42).
type(y, float).
type(x, int).

Run either factbase against the same inference code:

swipl -q -g "render_all, halt" facts1.pl render.pl
swipl -q -g "render_all, halt" facts2.pl render.pl

Output from facts1.pl:

var x : int = 42
var y : float = 99

Output from facts2.pl:

var y : float = 99
var x : int = 42

The rendered declaration for each variable is identical in both cases. The output order follows the order facts appear in the file — itself an illustration of the point: a canonically sorted factbase produces a canonically ordered rendering, and a VCS storing that sorted form gets clean, minimal diffs as a direct consequence.

The :- discontiguous declarations tell SWI-Prolog that facts of the same relation may appear non-contiguously — exactly the condition that holds in a sorted factbase, where facts are ordered globally rather than grouped by relation.

The key thing visible here: render.pl is six lines. The factbase is data. The inference is code. They are completely decoupled.

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Discord: https://discord.gg/65YZUh6Jpq

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

Paid subscriptions are a voluntary way to support this work.

Leave a comment

Subscribe now

Programming Simplicity

Separating Architecture From Implementation

Further Reading / Viewing

See Also

Concurrency (Part 2 of 2)

Concurrency (Part 1 of 2)

Computer With Concurrency

System With Pure Message Passing

Repeating Architectural Patterns

Resources

Articles

Videos

Examples

See Also

AI Is No Code

See Also

Anti Assimilation

Anti Assimilation

See Also

The Hardware Changed. The Software Didn’t.

TL;DR

L;R

The centralized model is an artifact of scarcity

The mismatch that nobody names

Thread safety has poisoned language design

The decentralized model follows the hardware

Smart Apps

Smart Devices

Decentralized Model

Consequences

This Has Been Done Before

Structured messaging is the discipline that makes it scale

Request Flow

Summary Flow

The development environment needs to change too

The model is not hypothetical

See Also

Software Development Has a Brainstorming Problem

TL;DR

L;R

What Songwriting Teachers Figured Out

What Writing Teachers Figured Out

Why Software Missed This

Where FDD Comes In

Appendix: Full Conversation

See Also

One Language To Rule Them All

See Also

We Painted Ourselves Into a Corner

References

See Also

Words

See Also

Computation vs. The Arrow of Time

See Also

Concurrency Is Not Parallelism

TL;DR

L;R

Analogy

Multi-Threading Fakes Parallelism

True Parallelism Requires Dedicated CPUs

PBP — Parts-Based Programming

See Also

FDD - Failure Driven Development

See Also

Ideas for Porting PBP to Go

See Also

Forth Haiku Compendium

Forth Haiku Compendium

See Also

You Already Know PBP

TL;DR

L;R

Where Pipes Stop

Why Not Just Use CALL/RETURN

References

See Also

The Limits of Mathematical Computation Applied to Physical Hardware

TL;DR

L;R