Programming Beyond Practices
14 points by pushcx
14 points by pushcx
Could you clarify if this PDF has been shared with the author’s permission? Looks like it’s hosted on the author’s website, but given that the book is otherwise a paid book on various websites, it felt a bit odd that the full PDF link was posted here directly…
Author posted the link on Mastodon: https://mastodon.social/@skillstopractice/114597222084354354 (account linked from the website)
Published 2017. Chapter 8 is a pipe dream about… vibecoding!
I wrote this book because I believe the shift away from “programmer as coding specialist” is inevitable. If that’s true, then our entire field will need to prepare itself for the not-so-distant future when “programmer as technically skilled solver of ordinary human problems” becomes the norm.
I’ve been writing code for a couple decades now, so this idea feels radical—and also quite liberating. The interesting parts of programming to me have always been the problem-solving, communication, and human-centric aspects of things; code was just the most effective tool I could find to serve those purposes.
Just…. smh. At this point in the week, I can’t quite muster the scathing critique that that vision deserves. I’ll just point back to that NYT article somebody linked a few days ago, as the other half of a “how it started / how it’s going” meme.
A few days ago, a friend asked and I responded:
What do you make of the need for programming languages going away with more LLM usage? Is it going to be a bit like cursive?
This is the essence of my worldview, which I struggle to convey: APL is a better math (notation). (There are some even better like BQN, probably!) Knowing it improves your vision, perception, understanding of the world. Formal languages (or jargon to a lesser extent) empower you with precision, giving you more perfect command over a domain. Taming and summarizing fields into distilled representations is divine. Programming is theory building.
In another but more direct form: COBOL is instructive. It attempted to solve programing, putting it in an intuitive English skin. (The siren’s song. Using English grammar and concepts seduces you into confusion, because a formal language has different grammar, semantics, limits, so your speech must be retrained.) Low-code approaches are even more instructive, letting you avoid the scary code / formal notation and grammar. But in both cases, they led to an explosion in more difficult roles than before like domain modelers https://www.mendix.com/blog/low-code-principle-1-model-driven-development/ working in obtuse formal schematics https://fswb-documentation.knowis.net/2.5/SolutionDevelopment/content/managing_low_code_solutions.html which repeat the creation of notation, but slave themselves to common language, with vague overlong terms etc. etc. ossifying their fields with human boiler plate and ceremony.
If every user of an application needs to write the same code, your API is wrong. If you abstract away the boilerplate and reuse that abstraction, you’ve made the world better. If you create a tool that generates the boilerplate, you’ve made the world more fragile. @david_chisnall
Instead of regarding the obligation to use formal symbols as a burden, we should regard the convenience of using them as a privilege: thanks to them, school children can learn to do what in earlier days only genius could achieve. - Dijkstra
A short look at the history of mathematics shows how justified this challenge is. Greek mathematics got stuck because it remained a verbal, pictorial activity, Moslem “algebra”, after a timid attempt at symbolism, died when it returned to the rhetoric style, and the modern civilized world could only emerge —for better or for worse— when Western Europe could free itself from the fetters of medieval scholasticism —a vain attempt at verbal precision!— thanks to the carefully, or at least consciously designed formal symbolisms that we owe to people like Vieta, Descartes, Leibniz, and (later) Boole. - Dijkstra
Just consider the European music tradition without notation, gradually adding forms of it and gaining in complexity and expressive power as the notation enabled more complex thought.
Alexis King touched on similar ground recently, feeling stuck in the Platonic spheres. I believe she’s throwing out the baby with the bathwater, that applying those PLT chops to make a lisp for music (instead of lists or maps) or for gardening or recipe design is the greatest thing we can do and tacitly helps people.
Very happy to be reading this. Our value as programmers is to create tools for thought that when used will change the user’s perspective, simplifying and empowering them. Language is the medium for that, and as such can either support or hinder the creation and use of these tools. LLMs are indeed very good at boilerplate, but very poor at designing these abstractions. It’s a good thing, IMO, as it puts the emphasis on the design, less on the execution.
I think there’s some truth to this, but I think there’s also truth to the idea that there is value in expressiveness over precision. Arguably the most popular APL-variant today is NumPy, a library for a programming language famously described as executable pseudo-code. It doesn’t “tame and summarise fields into distilled representations”, but it does mean that scientists and data analysts can get work done effectively and quickly. Or look at Excel as another example of array programming (at least in the more recent versions) which powers a lot of businesses still, and aims so hard to be expressive that files will be parsed in different ways depending on which language you open them in.
I agree that for complex software, precision is important (I wouldn’t want to build Excel or NumPy by vibe coding them!) but there’s a lot of software where precision isn’t so important, at least not to the people creating and using that software, and I can imagine in those situations, LLMs could be very useful.