All Panaceas Become Poison

AllPanaceasBecomePoison was the title of a CoEvolutionQuarterly? I read maybe 20 years ago. I think of it today with regard to C++.

I loved C. A neat, flexible, concise, expressive little language. But with warts. You could do big things in it, but the maintainability was not good. When C++ 1.0 came out, the old cfront/glockenspiel stuff, I looked at it, liked the flavour and the symmetry, but dismissed it - immature, a toy, not something to do real work in.

But I kept watching, and as I watched the language grew, and it grew strong. I liked C++ 2.x - an expressive, detailed, efficient, brutal language. Still heavy to maintain, but far better than C, and really easy to get to from C. I loved the C++ of the ARM, a language a C programmer could learn in a week, and master in six months. It was ugly under the covers, but it was manageable and did what it was told. I used it and boosted it and built big useful things with it and made money with it.

But Bjarne and Andy and co. were still monkeying with it. Monkeying with it was their business. They stooped to conquer. So we had RTTI, and namespaces, and bags of kludgy keywords like "explicit", "export", and "typename". And STL and the "improved" Standard Library. The ARM doubled in size to become "The C++ Programming Language, Third Edition" - the kitchen sink of kitchen sinks. And you really can't use C++ without an OODBMS, or COM, or CORBA, and now, swelp me, a bunch of UmlCaseVultures with the demonstrated and chronic inability to design an efficient drawing tool.

And the language went to a committee.

So now we've got this bloated mutant bastard that looks almost but not quite entirely unlike C. Each little bit of it, especially STL, is cute in its own way. But the parts don't fit together without a lot of non-C experience, and even then there's plenty of warts. C++ warts tower over the old C warts. Over ten years since I first played with C++, I consult in it, teach in it, make my money with it, build in it ... and loathe it. The panacea that cured the old C diseases has become a poison that kills projects at the root.

At least it didn't turn into something almost but not quite entirely unlike tea.

Well, I just woke up to this. What's woken me up is Perl. I'd tinkered with perl like I used to tinker with awk and sed and shell, but never took it seriously. A scripting language - something for neat cgi scripts, sure, but no more. Nothing large. Immature. A toy. Then a few months ago I stumbled across Ward's WikiBase, and that made me go and buy a couple of books just to get up to speed. I never intended to use perl for real, just wanted to get competent with it for competency's sake and to play with.

But I read the PerlBooks and now I can see that large things can be done easily in Perl. Sure, I've still got a learning curve. It took me a week to learn and six months before full fluency. There was all that CPAN stuff to grok, and the builtin syntax is intricate and often perverse.

But it's clean - woman and man, this language is so damned pure compared with C++. And expressive. And concise. And flexible. And extensible. And easy to teach. And fun! Every time you want to use a feature in some way - damned if it doesn't work that way! Or if it doesn't, you can make it work that way!

In short, Perl reminds me of nothing so much as C. It has none of C's warts, but it has its elegance. Perl has everything that ought to have been in C++, and none of the hypercomplex claptrap that ended up in there.

But there's still an efficiency issue. Until Perl can be properly compiled I think what's best is to combine the two - write most of your stuff in perl, and then rewrite the tight loops in C++. Just write little things in C++ - it's no longer fit for the big stuff. AlternateHardAndSoftLayers.

I still expect one day Perl will go the same way. AllPanaceasBecomePoison. -- PeterMerel.

Well, that was six months ago. Now Python's my fave and Perl seems big and kludgy. I remember feeling the same way about other languages; that this, at last, suits me best of all. Perhaps a more rational way to think about it is HorsesForCourses?

Um, ObjectiveCee that is ...

Um, XformsTechnology ...

Um, RubyLanguage ...

Maybe I'm just slow of mind ... but you know, the problem I'm really trying to describe is caused by everything generative eventually becoming ExtremelyInterstrangled. It'll happen to ruby too, just you watch. And at every step there'll be a bunch of hoary grey-beards singing out "ya shoulda programmed in [Forth|Lisp|Smalltalk] all along like we toldja!". Which prompts a good question: HowComeLispAndSmalltalkAintPoisonYet?

C++ is my milk language. I used to sleep with the ARM under my pillow. I see C++ as a solid feat of engineering, where engineering is understood to be the science of intelligent tradeoffs. There is an inner elegance to C and C++ in that they present a consistent model: an underlying machine that everything can be understood in terms of. STL takes advantage of it.

That said, I feel cheated. At OOPSLA97, I walked into a room and saw WardAndKent speaking. I felt out of place because I was probably the only one there who had never programmed in Smalltalk. Nonetheless, it dawns on me more and more (especially with exposure to Java) that C++ has so many options that it forces undue hesitation in work. Man, the simple things... I downloaded JUnit a few weeks ago and thought it would be cool to port it to C++. I looked at it and saw the stack trace, the garbage collection, the reflection and the dynamic loading that you get for free, and I felt like I've wasted too much time.

I never wanted to believe the people who maligned C and C++. After all, I had work to do, right? I needed speed, and C++ is the lingua franca. Man.

-- MichaelFeathers

I think Java is turning toxic fast. Problem is not the syntax with java, it's the libraries - ugh.

Pretty much agree on Java. About what Michael says, you can beat the hesitation problem by sticking to a dialect, there are good tracing facilities in the OSE library, STL Allocators can be made to auto-ref-count just fine, an OODBMS will reflect and CORBA/COM will manage the dynamic loading okay. So as long as you can figure out a way to graft all those bits together and convince someone to pay you to do it, your only worry will be how to stick to a dialect. Heh.'' -- PeterMerel.

Yeah. I don't mind having lots of stuff (libraries). I just don't like the lag between intention and realization which is consumed by building infrastructure that other languages give you for free, and spending time considering how the infrastructure that you introduce will affect your portability and future options. -- MichaelFeathers

I guess I can pretend to credit myself for being a faster learner. I tried for 6 months to get my C programmer to use C++ back in 1988, because C++ was the obvious choice for an OO C programmer and naturally we couldn't ship in Smalltalk:-). He kept stalling for some reason, and in those 6 months I looked at the discussions being waged on the C++ bulletin boards - like, where is my pointer pointing, and I looked at the different sort of thing happening on the Smalltalk boards, like, classes being exchanged and here's some cool code try it, and I thought then, as I think now.... LifesJustTooShort. Go where you love, and if you love the insides of C++ and DCOM, power to you. I also love all the carpenters and garbage truck crews in the world. -- AlistairCockburn

Hmm. This seems a lot milder than the opinion in your book. Change of heart or just diplomacy? -- PeterMerel

Well, the above version is my historical-recounting-for-polite-society version. What I wrote in the book is my reasonably-toned-professional-consultant-recommendation, a strong but softened (at the reviewers' requests) phrasing that lies in the middle of the politeness spectrum. My lets-be-fair-to-everyone version is: "C++ and Smalltalk are two different work media. Some artists choose to WorkWithClay, some choose to WorkWithStone. When you choose to work in stone, you have to work differently than when you work in clay. You have to plan better, you have to be more careful as you go, you can't afford to keep changing your mind." My lets-be-scientific version is: "C++ was a nice experiment, we learned a lot about contravariance and the limitation of using classes as types... Now let's declare the experiment over, or else treat it like recombinant DNA experiments - only to be continued under strictest isolation and not let out of the lab." The least polite version I save for late night discussion over beer and say, "I wish they would just drop the whole thing into the deepest part of the ocean with a heavy weight." and then I say, as I said above, LifesJustTooShort. I guess if I was going to offend anyone with my C++ views, I probably have managed it by now ...

Actually, I really did try to get this guy to use C++, and quite hard, too. He was remarkably stubborn. Just kept saying, "when there is a preprocessor that generates properly IBM-C compatible code." Over a six-month time frame in 1988 the vendors kept promising and never delivered. By the end of the six month period I had read enough on the bulletin boards that I went back and told him he could keep using C - which he wrote in an 'object-based' fashion, and thanked him for being stubborn. I have thanked him many times since then for saving the project. I think if we had used C++ our project would have died the common death I describe in the book. -- AlistairCockburn

I'm confused. WhatAreTypes? -- MichaelFeathers

Perhaps the problem lies not with the decisions of the language designers and developers, who are trying to facilitate real requirements with mechanisms as elegant as possible, but with the decisions of the program designers and developers who feel compelled to use every feature of the language without good reason or insight. I've been happily programming in pre-standard C++ for ten years, content to go slow in adopting new language mechanisms while trying to become faster at getting things done.

Why would someone try out a language feature they don't need or don't appreciate, then use that as an excuse to abandon the language? I still don't see any need for exceptions (are there really that many practical things you can do once they're raised beyond printing an error message and possibly aborting?) but I haven't let that stop me from programming without them. -- ScottJohnston

The following quote seems appropriate here:

What seems to have been lost over the years [...] is the common understanding of what the design center of the language is. While it is clear that the original design center as enunciated by Stroustrup is no longer sufficient to guide the development of the language, there has been no discussion of a replacement for that design center. Indeed, it is not at all clear that the current community of users is even in agreement about what the language ought to be capable of doing and, perhaps more important, what it should not attempt to do.

The lack of a clearly articulated, generally accepted design center for the language has resulted in a lack of a set of principles that can be used to judge the direction of language change. The danger is that the language will attempt to become something that does everything, with the result that it will do nothing well.

In his book Wonderful Life, Stephen Gould argues that one should not confuse biological evolution with progress. The forces that shape the survival of one species over another, Gould points out, are far more random than what is required to allow one to claim that species for recently evolved are in any way more advanced or superior to those from which they evolved.

Without a clear design center than can be used to determine a notion of progress in the evolution of a language, the changes that have been made [...] take on many of the aspects of biological evolution. The language has been used able to adapt itself to the changing environment of the increasing number of users. But with no goal for the language, the evolution of the language can only be seen as change, not progress towards that goal.

-- JimWaldo?, The Evolution of C++ : Language Design in the Marketplace of Ideas, September 1993 ISBN 026273107X (A Usenix Association Book)

The danger is that the language will attempt to become something that does everything, with the result that it will do nothing well. - don't most language designers strive to preserve the existing features of a language as they add new features? How can a language that once did something well be evolved in this manner to do nothing well? Isn't CommonLisp still good at list manipulation? Wouldn't FORTRANXX still be usable by a FORTRAN77 programmer? Are programming languages really that much like biological organisms where a price has to unconditionally be paid (by the whole community) for each new experimental appendix? Maybe that is so, if all of a sudden you are swamped with new frameworks to adapt that use the latest language features with no choice in the matter. Is that what people have experienced with C++? -- ScottJohnston

One of the great skills in using any language is knowing what not to use, what not to say. C, C++, Smalltalk, Lisp, it doesn't matter ... you can use them well or poorly. A big part of using them well is not using big chunks of what's there ... whether built-in language bits or available classes or frameworks. There's that simplicity thing again ... -- RonJeffries

Hey, look, we figured out how to get energy out of sunlight. So, we dump a little oxygen in the atmosphere... -- EarlyPhotosynthesizer?

CategoryCpp CategoryAntiPattern

EditText of this page (last edited June 11, 2009) or FindPage with title or text search