The following collection of conversations and articles have all been thought-provoking to me and I want to respond to them.
Towards a text editor construction kit – @raphlinus
Troubles with the CRDT model and the
ALGOL, Burroughs, Donald Knuth
That people produce HTML with string templates is telling us something – Chris Siebenmann
A discussion of context-aware auto-escaping templating and other structural templating systems. We often think about how difficult it is to parse HTML, but it can be similarly challenging to provide a safe and reliable system to print it, merging data values with placeholders.
Statistics and evidence
Functional architecture is Ports and Adapters – Mark Seemann
Dependency injection, pushing state to the edges, and more.
Remembering Joe, a Quarter of a Century of Inspiration and Friendship – Francesco Cesarini
Inside the mind of Joe Armstrong and how his brain ticked.
Designing protocols vs. APIs and hooking up software pipes the way we hook up electrical circuits.
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”
How far do we push the paradigm? Is the paradigm practical? What does it mean, essentially?
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?
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.
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.