Two Key Concepts in Programming
2025-05-12
Programming consists of several key concepts along several dimensions. In this article, I ponder one of the dimensions:
dealing with data
dealing with interpretation of data.
Interpretation involves concepts like control flow, tree walking, backtracking, blocking, state transitions, etc.
The Functional Programming paradigm, currently in vogue, constrains control flow to being of only one possible slice in this dimension - synchronous, single-threaded and blocking.
Other kinds of data interpretation are possible, but the Functional Programming paradigm doesn’t easily accommodate other kinds of interpretations and causes programmers to develop workarounds. The workarounds tend to produce exponential increases in complexity, unintended consequences and tend to be ultimately insufficient to solve problems that are outside of the sweet spot of the original, function-based paradigm. For example, programmers were subjected to callback hell and expensive software failures like the Mars Pathfinder mission and complicated notations like monads and sync/async and .then.
Smalltalk purports to use message passing, but, instead, uses synchronous function calling with multiple entry points into closures. Calling a method in Smalltalk is essentially an invocation of a closure containing private data that does a dictionary lookup (“switch”) on the incoming method name for synchronously calling the appropriate function.
UNIX, unlike most other programming languages, uses asynchronous message sending without blocking as its transport mechanism (“wire”) between processes.
This is very different from what Smalltalk does. When a UNIX process sends a message, the data is put on the process’s output queue and something else moves the message to the receiver. The receiver does not wake up immediately, the something else decides when the receiver will run. In UNIX, and most operating systems, this something else is just another subroutine called the dispatcher. Sending a message does not necessarily block the sender and does not necessarily wake up the receiver. The receiver does not necessarily return a value to the sender - the receiver might do something else. In FP parlance, this is derisively called a “side effect”, yet is extremely common in today’s asynchronous internet world, for example in “servers” and “daemons”.
In the article the-unix-binary-wants-to-be-a-smalltalk-method-not-an-object/ the author argues that UNIX and Smalltalk are similar. I agree, but only as far as the “dealing with data” angle. The author does not address the “dealing with interpretation” angle. IMO, this is where UNIX differs from Smalltalk and from just about every popular programming language in use today, like Python, Javascript, C++, Rust, etc.
See Also
Email: ptcomputingsimplicity@gmail.com
References: https://guitarvydas.github.io/2024/01/06/References.html
Blog: guitarvydas.github.io
Videos: https://www.youtube.com/@programmingsimplicity2980
Discord: https://discord.gg/65YZUh6Jpq
Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas
Gumroad: tarvydas.gumroad.com
Twitter: @paul_tarvydas
Substack: paultarvydas.substack.com