Repeating Architectural Patterns

2026-06-24

Jun 24, 2026

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)

Programming Simplicity

Discussion about this post

Ready for more?