This schematic shows the design of the 1972 game Atari Pong.
Schematics were usually drawn in black and white, but, someone took the time to colourize this schematic.
I count something like 14-20 different sections on this schematic.
Observing the schematic, we see several things
There are no CPUs on this schematic. There is no code in this design.
Schematics contain lots of detail and are overly-complicated. Design overview and implementation details are smushed together.
There are something like 60 ICs in this design. ICs are asynchronous devices, which means that this game has over 60 async threads. Actually many ICs contain several async devices, so, by a rough count, there are something like 100 threads in this design.
The whole game fits on one piece of paper. “C” size (large) paper, but still a single piece of paper. [Rhetorical question: how many pieces of paper / windows does it take to hold the code for a version of Pong written in any modern programming language?]
The sections of the game contain multiple inputs and multiple outputs, all asynchronous. This kind of thinking is hard to express using 1960s Gutenberg type-set programming languages. Language does affect thought. Since we can’t easily say something like this in type-set text, we tend not to say it at all and try to find different ways to design the game.
Some smart person managed to design the game this way and put it into (profitable) production. I.E. this style of thinking and designing is certainly possible and does not need to be linearized nor sequentialized.
Modern programming languages encourage programmers to design in a way that is different from this design. The modern idea is to design the game to be one enormous lump of code consisting of many tightly coupled, clockwork functions. The idea of designing a simple game like this, using 100 threads is essentially unthinkable using modern sequential, synchronous programming languages. It is do-able using modern programming languages, but, most programmers tend not to think this way due to a function-based upbringing.
The original intent for inventing CPUs was to replace chunks of random hardware logic. Thinking about the design of the game and looking at the colourized schematic, we might conclude that the simple game of Pong should contain something like 20 CPUs.
The main failures of this design are
It is too complicated, it contains too much nuance and detail, the DI (Design Intent) is not obvious. Someone tried to improve the DI by colourizing the schematic, but, it still looks to be too complicated.
The Parts of the design are not well scoped. Inputs and outputs of sections are essentially random and willy-nilly. Each Part on the schematic should be defined in terms of well-defined inputs and well-defined outputs.
Parts are synchronized, but, that fact is not obvious on the schematic. Parts free-run. Parts don't need to all dance to the same, global clock for synchronization, yet, how inter-part synchronization actually happens is not made obvious in the drawing. For example, this circuit is meant to drive cathode ray tubes - the form of T.V. that was prevalent before digital LED T.V.s became ubiquitous. Cathode ray tubes contain a single electron gun that shoots a focussed ray of electrons at a glass screen painted with phosphorus. When the electrons hit the phosphorus, the phosphorus emits light for a moment. It is possible to draw dots on the screen by turning the ray on and off at discrete moments. The single electron ray is swept left-to-right several 100’s of times and top-to-bottom, in two full round-trips 30 times a second. After displaying one line on the screen, the ray sweeps back from right to left. It is turned off during this back-sweep. When the ray hits the bottom of the screen, it sweeps back to the top of the screen. It is turned off during this upward backtracking. These two backtracking events are marked by the H-Sync (Horizontal Synchronization) and V-Sync (Vertical Synchronization) pulses. The H-Sync and V-Sync process is described in more detail in this ESP32 Composite Video YouTube. The Pong circuit does its calculations and manipulations during the backtracking sweeps, when the display is off, to avoid displaying smeared, torn and partial results on the screen. The blanking signals are fed into the circuit but not directly to every section. Sections free-run in a massively parallel manner, but their results are scoped (“gated”) in such a way as to avoid sending screen updates while the display is live. Sections are not micro-managed by a global synchronization clock, the main sync signals are fed into the top-level sections and are implicitly percolated down by chains of free-running sections that create more events. Sections are parallel and reactive and don’t do anything until poked by incoming events from other sections.
The sweet spot of functional programming is single-threadedness and clockwork-like synchrony. Does functional programming tend towards solving the bigger picture - parallelism and asynchrony? Will spending more and more time on incremental improvements to functional programming and type-checking and low-level caching, etc., solve the bigger picture?
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