I knew that Stephenson had a reputation for eclecticism, but I had no idea how wacky this novel would be, and I've barely even gotten into the Sumerian mythology. The genre is cyberpunk, and the setting is mostly near-future (or at this point, retro-futuristic), but the tone is predominantly absurd, comedic, and satirical.
Overall, this book has been a lot of fun, and is a fun glimpse into expectations of technology in the early 90s.
So far I've found this book a bit disappointing. What I expected was techniques for developers to make growing and changing a system safer and easier. Instead, the perspective is very detached and top-down. The target audience of this book is people-managers at big companies who bear the title of "architect" and who hardly ever write any code. Nothing wrong with that, but I certainly don't fit into that category.
I think this books depends on an artificial divide between design and implementation (something Evans brings up in Domain-Driven Design), and I'm skeptical that that divide is helpful.
This is a new Stack Exchange, still in a trial period, and so far I've been pleasantly suprised to see a lot of engagement!
Programming language design has always been an area of interest to me. In the workplace, language choice is often a foregone conclusion (perhaps especially in web dev, where JS is unavoidable), so it's refreshing to see some very knowledgeable people discussing the various design choices that go into languages both familiar and obscure.
Link to the forum here
I recently took a trip to Juneau, Alaska, and encountered this book at the Sealaska Heritage Institute's gift shop.
Tlingit is an endangered language spoken in the Alaskan panhandle by only around 50 speakers. It's a distant relative of Navajo, spoken in the American southwest, and languages of that family are famous for the complexity of their verbal morphology. While the book is designed mostly as a textbook for heritage speakers (perhaps high-schoolers and college students), it does occasionally delve into the verbal morphology, and the phonology has been interesting to learn about as well.
Scott is a popular author in the world of anthropology, so I was already primed to be interested when I kept hearing this title mentioned in podcasts. It has lived up to its reputation.
In a nutshell, the main argument is that when we flatten the complexity of the real world into simplified models in order to better control it, we sometimes end up enforcing that model upon the world, often to our detriment. While the prototypical culprit of this pattern is government, Scott emphasizes that the same could be said about companies or other actors.
I think there are parallels in software developement, since that also relies on modeling real-world systems.
Reading Domain-Driven Design, I noticed that it bore certain assumptions that were true in 2003 but not today. Namely, that any serious software development is object-oriented, and that you are almost certainly doing it in Java or maybe C++.
I sought this book out to hear the core concepts of domain-driven design reformulated in functional terms, and the first 30% of the book was exactly that. I've encountered videos and articles by this author before, however, and sooner or later he always turns the topic into an advertisement for F#. It seems like a lovely language but I would prefer if he would keep the principles more general.
Recently I've been interested in how the architecture of a project affects its long-term growth. With my own projects (especially my Language Workshop project), but to a lesser extent even professional projects I've worked on, I notice that the natural trajectory for any project is to become more complex and less comprehensible, and the gradual drift of the implementation away from the domain that it models adds more and more cognitive load in translating requirements from one to the other.
It seems that domain-driven design offers a potential solution. By consciously keeping the system tightly coupled to the domain, you can mitigate the difficulty of working on mature projects.
A quote from the book that I particularly liked:
Manufacturing is a popular metaphor for software development. One inference from this metaphor: highly skilled engineeers design; less skilled laborers assemble the products. This metaphor has messed up a lot of projects for one simple reason—software development is all design.
I sometimes use Docker Compose when developing multiple interacting services, just because it keeps things simple. All the ports are in one YAML file, and Docker hooks them all up for me, recompiling when necessary, and in the order that I specify.
My interest in Terraform was similar, though more theoretical than practical. Books about Dev Ops, strangely, tend to be aimed at a non-technical audience, and as a result the practical lessons have to be sifted out of a lot of fluff. But reading about Terraform, you can get all the relevant aspects of managing complicated infrastructure distilled into a concise interface.
Since I was mostly using it as a window into the world of Dev Ops, I didn't really absorb much practical information about Terraform, but I have a much better sense of what it does, along with similar tools like Ansible.
This was a really fun book. It explores a lot of unusual programming languages, which Kneusel groups into atypical languages like SNOBOL, which are practical languages that work according to very different ideas of what a programming language even is, and esoteric languages like BF, which aren't meant to be useful, but instead are some sort of experiment or parody.
The vast majority of programming in real-world projects is firmly in the ALGOL- or C-family of languages, so seeing the languages described in this book really makes you wonder how things could be different. What common but difficult tasks in C-family languages might be trivial in another language? Does our usual languages give us blind spots in our thought processes and problem solving?