I'm new here, though I'm a long-time geezer at /. First post! My style there was somewhere between civil and uncivil. This never harmed my karma. I was blun

I'm new here, though I'm a long-time geezer at /. First post! My style there was somewhere between civil and uncivil. This never harmed my karma. I was blunt and/or pointed in my mockery of reasonably smart people tossing off their pet clichés with their brain on dial-tone. I tried to toe the line on sharp yet not vindictive. Usually my posts digressed with a vengeance from an initial sharp retort to something original or constructive. Writing has always been a thing for me that releases frustration when technologies are _unnecessarily_ bloody-minded. I wasn't using /. to establish rapport. But recently the story summaries are achieving new heights of vagueness. I'm like the old dog who finally caught his tail, and noticed the smell. I clearly recall when Paul Graham became a bit of a meme at /. circa 2004. I still remember the desk I was sitting at when I first read Paul Graham's comments on LISP. So here we go, wading into the C++ bash-fest for old times' sake. (Is it permissible to compose in full paragraphs around here? I guess I'll soon find out. The Y/Z/omega generation's allergy toward paragraphs made reddit a total non-starter.) I've definitely let my C++ skills languish for the past few years. It's an awfully demanding language if it's not your bread and butter. One way to characterize C++ is that it's an elegance inversion. Most languages are founded on the assumption that beauty is transitive. If you start with beauty at the bottom and stay true to your aesthetic all the way up, the beauty will bloom as a mature rose. The C++ design aesthetic is that the language designer should not be refactoring his language user's problem domain in order to shoehorn simplicity (and elegance and glory) into his solution domain. There were no end of frameworks back in the 1970s and early 1980s that promised vast productivity increases, and delivered these for the most part, until the dread day came "oh oh, we have a new requirement and this tool we've chosen just won't go there, and backing out now is too painful to even contemplate". (Think Rails, back when every country was laying down a different rail gauge.) I find it amusing to read the experience of people deploying MongoDB. The thing is, regret has a different price than it used to. A few startups report rapid development on MongoDB for an initial year, then jumping to a different approach when some of Mongo's design eccentricities became problematic. Jumping is a lot less hard than it used to be. This might even have been a good overall development path. Few said that about a major misdirection in the 1980s. The comment over at the TFA that caused me to sign up and post was a guy saying that every piece should occupy a limited depth of the abstraction stack. He took offense that the language should have high level abstractions and still be able to specify execution details at almost the machine level. This was actually an almost explicit language design goal. This sentiment is reminiscent of the old "Worse is Better" debate. (Do I have HTML here? No info from the UI. Activate telepathy module: throw ("does not compute"). catch ("induction from sparse"): I guess I'll just post the author's name of the piece I'm referencing: Richard Gabriel.) C++ doesn't believe that great programs are written on the principle of "no ugly". Ugly happens. This is a property of reality, is it not? Or am I way too old for my own good? The premise in C++ is that low level library implementers have the gory power (pages of closely debated language specification) to conceal some (or even most) of the ugliness they face. Library implementers working at the next level up similarly have the gory power to conceal some of the ugliness they inherit, and also some of the ugliness their own layer introduces. This continues until the final consumer ends up working at a fairly high (and reasonably clean) level of abstraction. The ugliness propagates, but doesn't explode. Incompetence explodes, however, so there is that. Of course most casual users of C++ don't appreciate the substrata. They get buried in the arcane and baroque syntax required to make this magic work. (C++11 tries to redress this.) This is a whole different tranche of ugliness that stems from the original decision to keep the C language as a proper subset (plus a few design missteps along the way that are deeply regretted, but hard to reverse). Usually on the short list of toxic inheritance from C is the clever declaration syntax. This didn't generalize to OO without introducing some ugly ambiguities. Much baroqueness of the language still stems from this. It's an old language with history, much like Perl. Every new language arrives with a fresh face. A few get used enough to accumulate wrinkles. And we've even learned a few things over the years at how to avoid the worst wrinkles of all. It's nasty, but not ultimately toxic in its own right. Not so often admitted by these fresh-faced languages is the relief and freedom that accrues to not having to profess to solve every possible problem. Why? Because either C or C++ can be hauled out with a fair certainty that there's no ugliness so great it can't be captured and expressed well enough. My own opinion is that C++ has faded into its sunset years by finally buckling under its own weight. The baroqueness of the syntax is a finite burden, much like decoding the x86 instruction set as compared to RISC (the amount of circuitry needed to accomplish fit quite easily into a 386, yet we still complain about this overwhelming burden 15 die shrinks later). Nevertheless, it all adds up. I don't think the ROI of learning C++ in a deep way makes sense for younger developers. It's a complex world. There's too many other demands for that cognitive space. That said, I know that if I run into a problem where turning my back on ugly is not a viable option, C++ is still there for me, with a proven ecology of ugliness containment. In C++, one can always push ugliness from the problem domain back into the solution space, at the expense of some source code eye bleed--supposing your developers are well enough versed to distinguish incompetent solutions elegantly expressed from competent solutions with an ugly expression. This is why I described C++ as an elegance inversion. There are many languages more beautiful where that isn't true. Think of yourself as a plumber. There's a dirtiness to your world that's simply inescapable. This doesn't stop plumbers from implementing vacuum reflux hoses for optimal sewage containment. Then along comes Fritz Haber who declares sewage obsolete. Be thankful another language built those reflux hoses so your language doesn't have to. [Shit, no preview! Edit boxes are pathetic for tweaking paragraph flow. Who ever looks at their prose any more as others will see it? WTF. Fire and forget. My first lesson here in the new culture.]