Every person has at least one hero whose work they admire. If you’ve glanced at my “about” page, you may have correctly assumed that one of my heroes is writer/speaker Scott Berkun. I’ve followed Scott and read all of his books since he made the scary leap long ago from a safe job at Microsoft into the unforgiving jungle of self-sufficiency.
I like Scott’s work so much because I think he’s genuine, transparent, sincere, and down-to-earth. In short, his ideas and insights are helpful to his readers. That’s why I got a kick out of this twitter exchange:
Scott’s brand new, kickstarter-funded, book is titled “The Ghost Of My Father“. It’s a radical departure from his other books in that it’s a deeply personal treatise on growing up with an absentee father. Go out and buy it, pronto!
If I ever get my lazy ass out of “blog only” mode and hunker down to write some kind of unsellable book for my own personal satisfaction, Scott will have been a huge influence on the transition.
“A Conversation with Bjarne Stroustrup, Carl Hewitt, and Dave Ungar” is the most fascinating technical video I’ve seen in years. The primary focus of the discussion was how to write applications that efficiently leverage multicore processors. Because of the diversity of views, the video is so engrossing that I watched it three times. I also downloaded the MP3 podcast of the discussion and saved it to a USB stick for the drive to/from work.
When pure physics started limiting the enormous CPU clock speed gains being achieved in the 90s, vertical scaling came to an abrupt halt and horizontal scaling kicked into gear. The number of cores per processor started going up, and it still is today.
There was much discussion over the difference between a “lock” and “synchronization“. As the figure below illustrates, main memory is physically shared between the cores in a multicore processor. Thus, even if your programming language shields this fact from you by supporting high level, task-based, message passing instead of low-level cooperative threading with locks, some physical form of under-the-hood memory synchronization must be performed in order for the cores to communicate with each other through shared memory without data races.
Here is my layman’s take on each participant’s view of the solution to the multicore efficiency issue:
- Hewitt: We need new, revolutionary, actor-based programming languages that abandon the traditional, sequential Von Neumann model. The current crop of languages just don’t cut it as the number of cores per processor keeps steadily increasing.
- Ungar: We need incoherent, unsynchronized hardware memory architectures with background cache error correction. Build a reliable system out of unreliable parts.
- Stroustrup: Revolutions happen much less than people seem to think. We need to build up and experiment with efficient concurrency abstractions in layered libraries that increasingly hide locks and core-to-memory synchronization details from programmers (the C++ threads-to-tasks-to-“next?” approach).
Some of the parody accounts on Twitter are hilariously creative. Take “InfoSec Taylor Swift” for example:
The key word in Ms. Swift’s aphorism is “irreducible“. Being one of those things that isn’t objectively measurable (it’s funny how many things in real life are unmeasurable), one man’s “irreducible” is another man’s “reducible“.
I’ve discovered that many people, especially penny-obsessed managers, are so quick to assume and accept irreducibility in a complex system that they don’t even attempt to reduce its complexity:
- It takes time (which directly maps into expense) and hard mental labor to unravel complexity.
- In macho org cultures, irreducible complexity is often seen as intelligent sophistication, a badge of honor, a step toward lofty guru status.
Conversely, it is easier and less time consuming (which again directly maps into expense) to concoct an irreducible complex monolith than it is to thoughtfully build a reducible complex system of smoothly interacting parts.
I’ve been developing software in the aerospace and defense industry for 30+ years. Because of the sizes of, and innate System-of-Systems nature of, the solutions in this domain, the processes used to develop them are by necessity, heavyweight. Oh sure, agile/lean techniques can be used effectively in the teeny-tiny-small deep down in the bowels of some of these programs, but to assume “scaling agile” will work in a domain with hundreds of programmers from multiple contractors working on the same distributed system is naive at best, and downright disingenuous at worst.
The most ridiculous examples of inapplicable development practices to the aerospace and defense industry are #noestimates” and “#noprojects“. The “#noprojects” cult is so far off base that they don’t even acknowledge the existence of “programs” – which are a way of organizing a large set of inter-dependent “#noprojects” into, well, a larger grained mission-critical entity worth tens of millions of dollars. It’s like before there were classes and namespaces(packages) added to a programming language to accommodate increasing software system size, there were only “functions” for organizing the structure of a program – and having functions as your only organizing mechanism doesn’t scale well to large software systems.
Hell, the #noprojects people are akin to #noclasses and #nonamespaces people, of which there are thankfully, #nomembers. Really hardcore #noprojects people are perhaps even more loony. They are equivalent to a hypothetical #nofunctionsallowed crowd that demands monolithic, straight-line code only. Line number 1 straight to line number 5,000,000 – and you can’t use loops or “ifs” because they don’t add value and #nofunctionsallowed is all about “maximizing the amount of work not done“.
But hey, if you don’t need any “projects” to build a successful product from the gecko, then by extrapolation you don’t need any “programs” for organizing your projects. Hence, the inimitable BD00 proposes to “scale up” the “#noprojects” movement. We’ll start a revolutionary #noprograms movement, or equivalently, #justcode . We’ll leapfrog both the #noestimates and #noprojects movements at once. W00t!
Since I enjoyed reading Tom DeMarco’s “Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency” years ago, this diagram in Jamshid Gharajedaghi’s “Systems Thinking: Managing Chaos and Complexity” brought back some fond memories of that book:
The diagram shows the slow, insidious erosion in flexibility that occurs in a complex system when efficiency and optimization initiatives are relentlessly applied to the system by its uninformed stewards. As the “slack” is stretched out of the system due to increasing internal pressure, it: 1) loses its robustness to external stressors, 2) the tension between connected nodes increases, and 3) the inter-node couplings harden. At the system breaking point, one or more of the connections crack open, the nodes fly apart, and the conglomeration ceases to function as a whole – a system. I hate when that happens!
Check out this snippet from one of Bjarne Stroustrup’s CppCon keynote slides:
Now take a glance at one of Herb Sutter’s CppCon talk slides:
Bjarne’s talk was titled “Make Simple Tasks Simple” and Herb’s talk was tiled “Back To The Basics!: Modern C++ Style“. Since I abhor unessential complexity, I absolutely love the fact that these two dedicated gentlemen are spearheading the effort to evolve C++ in two directions simultaneously: increasing both expert-friendliness AND novice-friendliness.
By counterbalancing the introduction of advanced features like variadic templates and forwarding references with simpler features like range-for loops, nullptr, and brace-initialization, I think Bjarne and Herb (and perhaps other community members I don’t know about) are marvelously succeeding at the monumental task of herding cats. To understand what I mean, take a look at another one of Herb’s slides:
Do you see that teeny tiny dot at the end of the big arrow down on the lower right edge of the circle? Well, I don’t come anywhere close to qualifying for membership with the cats inside that dot… and I’d speculate that most advanced feature proposals and idiom ideas, whether they are understandable/teachable to mere mortals or not, originate from the really smart cats within that dot.
By gently but doggedly communicating the need for lowering the barriers to entry for potentially new C++ users while still navigating the language forward into unchartered waters, I’m grateful to Herb and Bjarne. Because of these men, the ISO C++ committee actually works – and it is indeed amazing for any committee to “work“.
Thanks to an angel on the blog staff at the ISO C++ web site, my last C++ post garnered quite a few hits that were sourced from that site. Thus, I’m following it up with another post based on the content of Bjarne Stroustrup’s brilliant and intimate book, “The Design And Evolution Of C++“.
The drawing below was generated from a larger, historical languages chart provided by Bjarne in D&E. It reminds me of a couple of insightful quotes:
“Complex systems will evolve from simple systems much more rapidly if there are stable intermediate forms than if there are not.” — Simon, H. 1982. The Sciences of the Artificial.
“A complex system that works is invariably found to have evolved from a simple system that worked… A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.” — Gall, J. 1986. Systemantics: How Systems Really Work and How They Fail.
A we can see from the figure, “Simula67” and “C” were the ultimate ancestral parents of the C++ programming language. Actually, as detailed in my last post, “frustration” and “unwavering conviction” were the true parents of creation, but they’re not languages so they don’t show up on the chart. :)
To complement the language-lineage figure, I compiled this table of early C++ features and their origins from D&E:
Finally, if you were wondering what Mr. Stroustrup’s personal feature-filtering criteria were (and still are 30+ years later!), here is the list:
If you consider yourself a dedicated C++ programmer who has never read D&E and my latest 2 posts haven’t convinced you to buy the book, then, well, you might not be a dedicated C++ programmer.