The following collection of conversations and articles have all been thought-provoking to me and I want to respond to them.
Functional architecture is Ports and Adapters – Mark Seemann
Dependency injection, pushing state to the edges, and more.
Towards a text editor construction kit – @raphlinus
Troubles with the CRDT model and the xi editor.
Everything is correlated – gwern.net
Troubles with frequentist statistics and null hypotheses.
Strong typing – M-J. Dominus
Introduction to type systems and why PERL’s core design fights types.
What To Know Before Debating Type Systems – Chris Smith
Broad discussion of what type systems are, what they can do, what they can’t do, and what “type” means.
Remembering Joe, a Quarter of a Century of Inspiration and Friendship – Francesco Cesarini
Inside the mind of Joe Armstrong and how his brain ticked.
Should we adopt Dave’s way of building applications as a series of components? – Joe Armstrong
Designing protocols vs. APIs and hooking up software pipes the way we hook up electrical circuits.
Discussion of ALGOL in contrast to modern C – reddit
ALGOL, Burroughs, Donald Knuth
The Emperor’s Old Clothes – Tony Hoare (1980)
“experiences in the implementation, design, and standardization of computer programming languages, and issues a warning for the future”
Alan Kay on the meaning of “Object-Oriented Programming” – reddit
How far do we push the paradigm? Is the paradigm practical? What does it mean, essentially?
Alan Kay on “Erlang might be the only object-oriented language” – Quora
Erlang is much closer to the original ideas I had about “objects” and how to use them…much more is needed beyond what we are programming in today
Programming Sucks – Peter Welch
A terse discussion of what’s wrong in the software industry and why we can’t get ahead.
The care and feeding of software engineers (or, why engineers are grumpy) – Nicholas C. Zakas
As in the name – why does it seem like software developers are cynical naysayers.
What if “data” is a really bad idea? – Alan Kay, Rich Hickey on reddit
What comprises “data?” What comprises “code?” Why does it matter?
The Failures of “Intro to TDD” – Justin Searls (2014)
Invert our normal conception of test-driven develop or of building independent units as we work up the application; start with the “finished” application as a fake/mock and refine the tests and the units as you fill out more and more of the product.
Ironies of Automation – Lisanne Bainbridge, Automatica Vol.19, No.6 pp. 775-779 (1983)
Adding automation in order to minimize the demand for skilled manual labor has an odd tendency to increase the demand for more-skilled manual labor. Quis custodiet ipsos custodes?
The Early History of Smalltalk – Alan Kay, HOPL II pp. 511-598
What does object-oriented mean and how did it develop? What is the significance of Smalltalk and how does its history mix with the pursuit of personal computing?
Can’t Buy Integration – Brandon Byars, 2021
Building integration as the understanding of clean interfaces between capabilities instead of as wiring between implementations or services.
While we have historically drawn up our project plans and costs around the boxes — the digital products we are introducing — the lines are the hidden and often primary driver of organizational tech debt. They are the reason that things just take longer now than they used to.
Buying a graphical integration tool allows for a simpler, more approachable form of custom software. Yes, it’s true that each line between boxes on your architectural diagram will likely become simpler to create. However, because of the complexity ceiling of such tools, the number of lines will explode, which is like pouring slow-hardening concrete on your architecture that increases your architectural tech debt over time.
reframing the integration conversation away from wiring systems together and towards exposing self-service interfaces between business capabilities can lead to significant business value.
Programming as Theory Building – Peter Naur, 1985
The product of programming isn’t primarily a body of code, but a theory for how a complex system works. Decisions based on the idea of code-as-the-result will make repeated mistakes because of failing to acknowledge the role that this institutional knowledge plays.
programming in this sense primarily must be the programmers’ building up knowledge of a certain kind, knowledge taken to be basically the programmers’ immediate possession, any docu- mentation being an auxiliary, secondary product.
Allegory
Computing Machines – Lawrence Kesteloot
A fictional tale of how deeply computer security bugs can go; an imagination of “reflections on trusting trust” where the actor is sentient in itself rather than malicious.