Archive
Patience Grasshoppa, Patience
It won’t arrive for awhile, but it’s on its way: the C++11 rendition of Bjarne Stroustrup‘s “The C++ Programming Language“.
In case you didn’t already know, the C++11 editions of these tomes are already available for your consumption:
But of course, you did already did know this. There are gifted copies of each of these references on your and your colleague’s desks because your company cares about you, your productivity growth, and continuously enhancing the quality of its revenue-generating product portfolio. That’s why it obsesses over little, but simultaneously huge, things like this for you, its products, and its future well being. It’s a quiet, low-key, low-cost, win-win-win situation that makes you feel warm and fuzzy each day you walk in the door to joyfully add your contribution to the whole.
And puh-leeze, no comments from the hip and cool Ruby, Python, Java, Go, Scala, C#, etc, peanut galleries. On this bogus blawg, only pope BD00 is approved to promote or trash other programming languages, ideas, groups, concepts, institutions, traditions. Well, you get the idea.
Note: I created the above image at says-it.com. It’s a wonderful site, so hop on over there and give it a whirl.
Best Actor Award
I recently watched (Trifork CTO and Erjang developer) Kresten Krab Thorup give this terrific talk: “Erlang, The Road Movie“. In his presentation, Kresten suggested that the 20+ year reign of the “objects” programming paradigm is sloooowly yielding to the next big problem-solving paradigm: autonomous “actors“. Using Thomas Kuhn‘s well known paradigm-change framework, he presented this slide (which was slightly augmented by BD00):
Kresten opined that the internet catapulted Java to the top of the server-side programming world in the 90s. However, the new problems posed by multi-core, cloud computing, and the increasing need for scalability and fault-tolerance will displace OOP/Java with actor-based languages like Erlang. Erlang has the upper-hand because it’s been evolved and battle-tested for over 20 years. It’s patiently waiting in the wings.
The slide below implies that the methods of OOP-based languages designed to handle post-2000 concurrency and scalability problems are rickety graft-ons; whereas the features and behaviors required to wrestle them into submission are seamlessly baked-in to Erlang’s core and/or its OTP library.
So, what do you think? Is Mr. Thorup’s vision for the future direction of programming correct? Is the paradigm shift underway? If not, what will displace the “object” mindset in the future. Surely, something will, no?
Too much of my Java programs are boilerplate code. – Kresten Krab Thorup
Too much of my C++ code is boilerplate code. – Bulldozer00
Java either steps up, or something else will. – Cameron Purdy
Misapplication Of Partially Mastered Ideas
Because the time investment required to become proficient with a new, complex, and powerful technology tool can be quite large, the decision to design C++ as a superset of C was not only a boon to the language’s uptake, but a boon to commercial companies too – most of whom developed their product software in C at the time of C++’s introduction. Bjarne Stroustrup‘s decision killed those two birds with one stone because C++ allowed a gradual transition from the well known C procedural style of programming to three new, up-and-coming mainstream styles at the time: object-oriented, generic, and abstract data types. As Mr. Stroustrup says in D&E:
Companies simply can’t afford to have significant numbers of programmers unproductive while they are learning a new language. Nor can they afford projects that fail because programmers over enthusiastically misapply partially mastered new ideas.
That last sentence in Bjarne’s quote doesn’t just apply to programming languages, but to big and powerful libraries of functionality available for a language too. It’s one challenge to understand and master a language’s technical details and idioms, but another to learn network programming APIs (CORBA, DDS, JMS, etc), XML APIs, SQL APIs, GUI APIs, concurrency APIs, security APIs, etc. Thus, the investment dilemma continues:
I can’t afford to continuously train my programming workforce, but if I don’t, they’ll unwittingly implement features as mini booby traps in half-learned technologies that will cause my maintenance costs to skyrocket.
BD00 maintains that most companies aren’t even aware of this ongoing dilemma – which gets worse as the complexity and diversity of their product portfolio rises. Because of this innocent, but real, ignorance:
- they don’t design and implement continuous training plans for targeted technologies,
- they don’t actively control which technologies get introduced “through the back door” and get baked into their products’ infrastructure; receiving in return a cacophony of duplicated ways of implementing the same feature in different code bases.
- their software maintenance costs keep rising and they have no idea why; or they attribute the rise to insignificant causes and “fix” the wrong problems.
I hate when that happens. Don’t you?
Find The Bug
The part of the conclusion in the green box below for 32 bit linux/GCC (g++) is wrong. A “long long” type is 64 bits wide for that platform combo. If you can read the small and blurry text in the dang thing, can you find the simple logical bug in the five line program that caused the erroneous declaration? And yes, it was the infallible BD00 who made this mess.
Performance Per Watt
Recently, I concocted a blog post on Herb Sutter‘s assertion that native languages are making a comeback due to power costs usurping programming labor costs as the dominant financial drain in software development. It seems that the writer of this InforWorld post seems to agree:
But now that Intel has decided to focus on performance per watt, as opposed to pure computational performance, it’s a very different ball game. – Bill Snyder
Since hardware developers like Intel have shifted their development focus towards performance per watt, do you think software development orgs will follow by shifting from managed languages (where the minimization of labor costs is king) to native languages (where the minimization of CPU and memory usage is king)?
Hell, I heard Facebook chief research scientist Andrei Alexandrescu (admittedly a native language advocate (C++ and D)) mention the never-used-before “users per watt” metric in a recent interview. So, maybe some companies are already onboard with this “paradigm shift“?
Hacrobatics
It’s funny how attitudes, preferences, and likes-dislikes change over time via personal experience and the acquisition of new knowledge. Having transitioned from a C background over to C++ quite awhile ago, I used to think pre-processor macros were a kool feature that came along for the ride. However, after having been burned multiple times by scope-ignoring macros, I learned to hate the damn little buggers. The scorchings made me fully appreciate the addition of “const“, templates, and inline functions to C++ in order to wean people off of “hacros“.
Maintaining a “hacro” laced program can drive anyone up a wall because:
I’m bummed, but not surprised, at how many people still think that “hacros” are a kool and useful feature of C++.
New Native Languages
The editor of Dr. Dobb’s Journal, Andrew Binstock, has put together a nice little slideshow summary of four “modern” native (native = no virtual machine running underneath the code) programming languages here: New Native Languages. As the figure below shows, these relatively new languages are D, Go, Vala, and Rust.
According to Andy, “older” native languages like C11 and C++11 “can have the feel of a past era onto which contemporary elements have been grafted“. I don’t agree with his “grafted” assertion, but I have to begrudgingly agree with him when he says:
The upshot is that to be truly expert in C++ requires far more education and far more effort than comparable mainstream OO languages (notably, Java and C#). – Andrew Binstock
Since I have much admiration for “D” creator Walter Bright and co-evolver Andrei Alexandrescu, I’ve been following the evolution of their language from afar. These two guys really know C++ inside and out; warts and all. Thus, unlike the 1995 Sun marketing proclamation that “Java is what C++ should have been“, Walter and Andrei are truly evolving D into “what C++ should be” – which is not just an OO language. Plus, they are being very gracious about it.
Relentless Assault
Microsoft’s Herb Sutter is a whirling dervish. Since the ISO approval of the C++11 standard last fall, he’s been on a crusade to promote C++ via several comparative assaults on Java and Microsoft’s own C#.
Herb’s latest blitzkrieg occurred at the lang.next 2012 conference (video link, slides link). In this slide, Herb summarizes some of the C++11 features that close the productivity and safety gap relative to C# and Java.
In this next slide, Herb contrasts C++11’s adherence to its more open “trust the programmer” philosophy against the more closed “we know what’s good for you” C#/Java philosophy.
Unless the large movement of business applications to the cloud is the latest fad du jour, the following two slides show that the largest software development and maintenance costs will shift from labor to compute efficiency. Thus, it doesn’t matter how programmer friendly your language is and how low the salaries you pay are, you might find that your costs are going up because of power drain in massive data centers and time spent frantically optimizing VM-based code that’s relatively slower and bigger.
In closing, Herb, the nice guy that he is, backs off a bit with this “the right tool for the right job” slide:
Is Herb stretching the truth and exaggerating the improvements offered up by C++11? The fact that I wrote this post obviously means that I don’t. What about you, dear reader? What say you?
Metadata Code Bloat
In many of his (terrific) talks and lectures, Herb Sutter often says that “always on garbage collection“, “default virtual dispatch“, and “metadata” are valid reasons as to why managed language programs written in C# and Java are typically slower and bigger than native languages like C++ and C. I understand the first two issues, but not the “metadata” argument. Thus, I asked Herb to “splain dis to me Lucy“.
Here’s my question and Herb’s gracious answer:
The “Void Star” Crowd
During the “Ask Us Anything” panel discussion at the “Going Native 2012” conference, one of the questions asked was: how do you get the “void *” guys to move forward toward a more type-safe and abstract C++ style of programming?“.
By “void *“, the questioner meant programmers who still cling to writing code like this:
instead of this:
The panelists admitted that it was a big challenge, and they gave the following suggestions:
- Ask them what problems they’re having and then show them the solution by doing it for them in C++ style. (Stroustrup)
- Set a personal example of increased productivity. (Alexandrescu)
- Show them compiler generated assembly output comparing the “void *” C-style code with a more expressive, less error-prone, more readable C++ equivalent. Odds are that the compiler-optimized C++ code will be much shorter than the hand-crafted C code. (STL)
Bjarne Stroustrup seemed especially frustrated at the pervasiveness of “void *” mindset. As a professor at Texas A&M, he said that as people come out of high school, most of them want to write games and they’ve convinced themselves and each other that, beyond a shadow of a doubt, “void *” is as fast as one can get. That’s exacerbated by the fact that many professors and “greybeards” still code in the type unsafe, barely readable, and error prone “void *” way.
I can sympathize with Bjarne and the panel. When I made the transition from C to C++, it took me what-seemed-like forever to “graduate” from arrays and naked pointers to containers and smart pointers and algorithms. Luckily, I did it in spite of myself. I can’t even remember the last time I used “void *” in any of the code I wrote.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 