Bjarne Stroustrup on the Problems With Programming

Hobart writes "MIT's Technology Review has a Q&A with C++ inventor Bjarne Stroustrup. Highlights include Bjarne's answers on the trade-offs involved in the design of C++, and how they apply today, and his thoughts on the solution to the problems. From the interview: 'Software developers have become adept at the difficult art of building reasonably reliable systems out of unreliable parts. The snag is that often we do not know exactly how we did it.'"

Comments

Problems with Programming

[pchan-]

I wouldn't take programming advice from a guy who overloads the bit-shift operator to perform I/O.

Re:Problems with Programming

[_merlin]

That's the outflow of an inherent problem with allowing operators to be overloaded. People will inevitable make them do different things on different types, making it impossible to know what an operator does without knowing something about the types of the arguments.

Of course, there are arguments for the other side, two. One is that people will create similarly named methods on different objects that do completely different things, and ambiguous operators are no worse than ambiguous method calls. Another is that in cases where the normal operation of an operator is meaningless, it should be acceptable to overload it with different functionality.

Overloading the bit shift operator on I/O streams is a case of the second way of thinking: a bit shift makes no sense on an object, so why not use it for something else.

Re:Problems with Programming

[2short]

Why, because you've been confused by that? Because anyone has ever been confused by that ever? So you see:

cout << "You are a bazooty head";

and you think, obviously, that is supposed to shift the bits of the standard output stream left by "You are a bazooty head"?

I wouldn't even call it an overloaded operator except in an overly technical sense. It's an operator that means two different things, and while that may in general be a bad idea, in this case the possible contexts for those meanings are so different, it's not anything close to a problem.

Now I'm sure people will deluge me with examples of cryptic, intentionally obtuse code that dumps the results of shift expressions directly to streams, and thus abuses this construct to create confusion. That's not the point. In decently written code, it's not a problem.

Re:Problems with Programming

[epine]

I've been involved in more threads than I wish to recall slinging mud at C++ and there is always a strong representation from the crowd who aren't willing to invest the time to understand the object they are criticizing. The criticism fundamentally boils down to: why should a language force me to think?

The fact of the matter is that the conceptual challenge of writing pointer-correct code is isomorphic to other forms of resource-correctness which one must still confront in whatever saintly language one employs. When I worked with microcontrollers (fairly hefty ones), in actual practice I never lost any sleep over pointer correctness. However, I did sweat bullets over real-time response in my nested interrupt handlers. Pointers were small potatoes compared to fundamental challenges posed by the design of the hardware we employed. A few small changes to the hardware design would have saved enormous challenges in the software layer. No language would have spared me that challenge.

Certainly overloading can be abused. Has it ever caused me a problem? Never. Excess delegation in an object-oriented framework? Nightmares.

Another post blames C++ for having an accretion-based design process. Oh, that stings. It was an explicit design approach to gain real-world understanding of one feature before designing the next. The two areas where the C++ design process got ahead of itself were multiple inheritance and templates. The former Stroustrup has confessed was perhaps a misguided priority. The later was caused by discovering that templates were an exceptionally fertile mechanism very late in the standardization process. C++ templates evaluate at compile time as a pure functional language. What makes templates difficult is that they are too much like other languages (e.g. Haskell) that the same people go around praising.

If one fully understands the cascade of implications of the original decision to take a relatively hard line on backwards compatibility with C, there isn't much in C++ that strikes me as "could have been vastly better". OTOH, I've come to the opinion that for someone who lacks that deep historical perspective, the overhead involved in mastering all the syntactic quirks that stemmed from that root is excessive. I don't regard C++ as a language that justifies the learning curve unless the person is suited to the kind of challenge involved in writing a real-time correct interrupt handler on a random piece of hardware that wasn't necessarily designed to make this easy.

Just the other day I commented out a section of PHP code in website skin (a language I use irregularly) to roughly this effect:

<!--
<markup> ... </markup> <?php require ("somefile.php"); ?> <markup> ... </markup>
-->

somefile.php executed regardless and emitted an HTML comment which closed my open comment in the first line above, leaving my closing comment exposed in the rendered document. Sigh.

At the end of the day, I find it extremely obnoxious the sentiment that some kind of pure language design can save us from this misery. There is no salvation to be found among programmers who brag mostly about thinking less.

Re:Problems with Programming

[2short]

As a former co-worker once put it "C++ is a professionals language"; while this sounds at first like snobish looking down ones nose at other languages, it's not. If you're going to be spending much of your productive work hours over some significant chunk of your career writing code, C++ may be the language you want to do it in. If not, it's probably not.

Re:Problems with Programming

[hey!]

I wouldn't take programming advice from a guy who overloads the bit-shift operator to perform I/O.

Well, in the real world we have these things which often seriously limitthe elegance of our designs. They're called constraints.

In the case of C++, Stroustrup wanted to add extensions to C that would turn it into a complete object oriented programming language. With the hindsight of years of experience, some things that were then thought to be critically important turned out to be of only marginal value. Multiple inheritance for one thing. Another thing was allowing object classes to act as "first class types", which implies the need to create and overload operators. However, given the state of knowledge at the time, they were reasonable goals.

So, Stroustrup needed to implement operator overloading. He also chose to implement C++ as a preprocessor that converted C++ into C. There were some undesirable consequences of this, but for the most part it was a good decision for the language. What he accomplished at one stroke was creating a complete and highly capable object oriented programming implementation available on a vast number of systems. The big advantage of C is that is small size made it the most portable language ever; piggybacking on it brought much of this advantage to C++, with minimal effort (another real world constraint).

IIRC, one of the undesirable consequences of his implementation approach was that it was much more convenient to limit C++ operators to tokens that are recognized as tokens in the C compiler. This means that to allow classes to be first class types, the operators we define on those classes were "overloaded" C operators.

From a design standpoint, this kind of "overloading" is a totally different kettle of fish from normal operator overloading. "Overloading" proper implements a kind of conceptual parallelism: floating point addition is analagous to integer addition, even though it has a totally implementation. True OO operator overloading plays the same role in expressions that polymorphism does in method calls. The C++ use of existing C operators to implement new concepts (e.g. I/O) is a pure kludge.

This is what is known in the real world as a trade-off.

We thought, back in 1979, that making classes first class types with their own operators was pretty important. Stroustrup needed to implement it then, but he also wanted to piggyback C++ on the existing C compiler for the reasons noted above. This trade-off satisfies both constraints at the cost of some aesthetic inelegance. Redefining the bitwise shift operator for I/O is conceptually inelegant, but it gets the job done and creates no confusion in practice. This is also a good trade-off.

In retrospect, Stroustrup could have left certain of the features of C++ out, becuase either they have proved more problematic than they are worth (e.g., multiple inheritance) or they are not really as useful as people thought they were going to be (operator overloading). Perhaps what we really needed was more like Objective C. But C++ became the dominant systems programming language, and Objective C did not. Speaking as somebody who worked through the era of C++'s rise to dominance, this is a direct result of Stroustrup's choice of trade offs. C++ was more widely ported. And C++ was a convincingly complete implementation of nearly everything we thought was important to have in an OO language at the time.

There is no doubt that C++ is a work of genius -- what's more a rare mix of pragmatic ane theoretical genius. If you need proof, consider that after twenty five years, C++ remains an indispensable systems programming language, if not the indispensible language. You can hardly fault Stroustrup if it is not quite what we'd come up with today.

Code Structure vs. Function

[Salvance]

Bjarne says:

Think of the Mars Rovers, Google, and the Human Genome Project. That's quality software

but then goes on to say:

On the other hand, looking at "average" pieces of code can make me cry. The structure is appalling, and the programmers clearly didn't think deeply about correctness, algorithms, data structures, or maintainability

I doubt he has seen the code to the Mars Rovers, Google, or many other applications that he/we consider quality. He's judging it based on the software's function. If we were to judge software purely on how it worked, quite a bit of software could be considered quality. But if you were to look at the same software's code, you'd probably "cry" like Bjarne. Look at Firefox. That is a Quality application, but programmers I've spoken to said the code is a mess.

"On the other hand, ..."

[TransEurope]

"...looking at "average" pieces of code can make me cry. The structure is appalling, and the programmers clearly didn't think deeply about correctness, algorithms, data structures, or maintainability."

Maybe it's because the average programmer is enslaved in company business. They don't have the
time to create masterpieces or art in programming. Instead of that they are forced to create
something adequate in a given time. Happens almost everytime, when science becomes business.
I don't like that, you don't like that, no one likes that, but that's the way commercial industries
are working (at the moment).

Re:In my experience...

[americangame]

Well in my experience they had me learning C on Unix, then Bjarne Stroustrup (along with another professor) taught us C++. I must say that learning a programming language from the creator isn't the best way to do so, as he will begin to go into the extreme detial of how a pointer in C++ works with no regard for the fact that it might be too much information for the first week of class. But it is a great way to scare the ever living piss out of freshmen in college that are considering to become computer engineers.

Re:In my experience...

[Garridan]

VB is a rapid prototyping environment. And just like an RP machine, it makes a flimsy product that you can send back to the drawing board without much expense. But you don't ship a product you've made on an RP machine -- it's crap. You take your prototype, and make a real product out of it using sturdy materials. Same goes for VB. You make something that works the way you expect, then you make it work in a real language. Good thing about VB is that you can replace pieces at a time with DLLs compiled from C++. If that isn't a part of the VB curriculum, it's a waste of time.

couldn't say "NO" to a feature

[r00t]

The KISS principle is totally lost on that guy.

The moment you have 2 people doing C++ on 1 project, at least 1 person will be faced with code written using features they just don't understand. C++ has features to spare.

Think you know C++? No, you don't. Heck, the compiler developers are often unsure.

This is a recipe for disaster, as we often see.

C was hard enough. Few people truly understood all the dark corners. (sequence points, aliasing rules, etc.)

C++ is addictive. Everybody wants one cool feature. C code is somewhat easy to convert. Soon you're using enough of C++ that you can't go back, and hey, more is better right? The next thing you know, some programmer on your team got the wise-ass idea to use Boost lambda functions (for no good reason) and you find yourself with 14 different string classes and... you have a mess that no one single developer can fully deal with.

Re:Its crazy

[EvanED]

C++ is like a sharp scalpel. Yes you can hurt yourself if you're unskilled, inexperienced or sloppy

"C++ gives you enough rope to shoot yourself in the foot"

Java and C# are like those scissors with rounded ends for kids. Totally inefficent but safe for beginners.

I'm not convinced of the "totally inefficient" bit. I think you'd be pressing it to do time-critical systems (indeed, current GC is more or less incompatible with realtime systems), OSs, etc., but I'm not convinced that they're not just fine for applications. This especially applies to C#, because C# GUIs are actually responsive. (Swing and to a lesser extent SWT lag a little.)

But there's a reason why surgeons don't use plastic scissors.

There's also a reason carpenters don't use scalpels. It's because different tools are good for different jobs.

There's only one real problem: lack of talent

[CPE1704TKS]

The problem with programming is that too many people that lack the talent are in the programming business. I know because I work with many of them. They are not detail oriented, they don't think strategically, long term, etc and just make a mess of code. They only want to fix the problem they need to fix without worrying about the effect it will have on the system, etc. This is what causes bad programs. Programming is easy enough that any moron can make something work, but to make something continue to work requires an engineering understanding, and this is something most people don't have. It's unfortunate.

Re:In my experience...

[arivanov]

Exactly.

C, C++, Java and god forbid VB should be prohibited by law for university courses and any person teaching them during the first 2 semesters in CS should be prosecuted for child abuse. Pascal (even without the object oriented extensions) remains the best language for teaching the first years in CS. Once students are past their data structures course and know how to deal with linked lists, pointers, objects hashes and the like you can switch to C, C++ or Java with minimal fuss. Before that its outright criminal. In fact the total amount of hours spent till the point when the students can produce something that will pay their daily bread will most likely end up being less than the required when teaching directly in C/C++.

There was a very good article on the subject by Joel called The perils of Java schools and I tend to agree with it 100%. In fact I will extend its reasoning further to C and C++. Probably the most important part of teaching a data structure course is to teach it in a language that has a clear syntax and "one way to get it right" for pointers, linked lists and the like. C and C++ are insufficiently clear and unambiguous. Java simply does not allow you half of the things you need to do in that course.

Many people advocate for the usage of Java and especially VB from the perspective of "look how fast can I learn to program in these". That is irrelevant as far as university courses are concerned. What is relevant is will the student learn to produce literate, commercially viable code or not. If he has been subjected to VB - never, Java or C++ - not bloody likely, C - it may work but it will be anything but readable for the first 10 years of his career.

Re:In my experience...

[RAMMS EIN]

I don't think the main issue is which language you start with. What's important is that you teach people multiple paradigms and multiple languages, so that they are aware of them and their strengths and weaknesses.

Re:In my experience...

[$pearhead]

I disagree. Programming isn't something you learn from someone else. Programming is something you learn by yourself. Of course, you can get excellent help/lectures/tips/advice/insights/whatnot at an university for example, but my point is that in the end you have to sit down and think and then write some code (and figure out why it doesn't work) by yourself. I would say it doesn't matter if you start with Visual Basic or Pascal; if you haven't got the ambition/derive/whatever to really sit down by yourself and figure things out, you will never be a (good) programmer.

There is no silver bullet.

[shess]

Many of the points in the interview implied that software was simply soaking up all the hardware performance, and perhaps we could squeeze more out of the software. I completely agree, except ...

http://www-inst.eecs.berkeley.edu/~maratb/readings /NoSilverBullet.html

The problem is that the software is an order of magnitude slower than it needs to be because the hardware has increased in performance by 2 and 3 and 4 orders of magnitude. If we had held the software to the same standards as we used to back when the hardware cost more than the programmers, it would be more efficient - but would only be able to make use of a couple megabyte of RAM and disk. The looseness of current software is part and parcel of harnessing the hardware. The hardware didn't just allow us go loose with the software we wrote - it allowed us to use abstractions which were measurably less efficient, but which had the side effect of allowing us to harness the hardware in the first place.

As a pair of trivial examples, take arrays and dictionaries. When I ask interview questions like "Design a hashtable" or "Reverse a linked list", many candidates have to actually step back and think about the question! 30 years ago, designing a good hashing function was the mark of true talent, and gains were to be had by selecting the linked-list scheme which best suited the problem at hand. These days, many people don't really know why you'd use a map versus a hash_map, or a vector versus a deque. And, for the most part, they don't really need to.

You want Lisp.

[piranha(jpl)]

You want Lisp. Hear me out.

Of course, the character syntax is superficially different. Operators use infix notation ("(+ 1 2)" is analogous to "1 + 2"), and have identical character syntax as function calls ("+", an operator in Lisp jargon, may be implemented as a function).

If you can sleep at night after that, your can define own higher-level language syntax that looks exactly like any other Lisp syntax. Lisp is extremely flexible in its naming of functions and variables (symbols). If you'd like, you could define an operator named .= as a function: (.= string new-character-strings ...) would modify the given string object, string , in-place, appending each specified new-character-string to the end.

Recognizing the downside to modifying random strings in-place, perhaps you'd rather have your .= operator assign a newly-instantiated string to the variable referenced by string . You could, by writing the operator as a macro. The macro would act like a function, taking as input each "raw" argument—symbols and lists, the structure as they appear in your program, before evaluation—and returning as output replacement Lisp code to evaluate in its place. So that your .= operator form of (.= out "lalala") is semantically equivalent to (setf out (concatenate 'string out "lalala")) (like out = out . "lalala"; in other languages).

It's not just simple textual substitution. You can use any function or macro in your macro definition to transform your input arguments into whatever replacement code you'd like. I'm using macros in Common Lisp to generate recursive-descent parsers based on a grammar production expression: the following form defines a function named obs-text that takes a string as input and returns a list of matches found as output:

(defproduction obs-text
(LF :* CR :* (obs-char LF :* CR :*) :*))

This function is defined in place and evaluated and compiled immediately by the Common Lisp implementation.

Macros can be abused, but they add a tremendously powerful capability of abstraction not possible with many other languages.

Re:Which university is that?

[rucs_hack]

yes, for Rapid Application Development. However that is *not* the point of studying computer programming.

While a good coder knows when to re-use code. A coder incapable of originating complex code is little more then an automaton.

I'm sick of the 'don't re-invent the wheel' argument being dragged out and used to justify people not studying properly, or for that matter, not teaching properly. I was lucky, I attended a course where most lecturers believed that students should code their own assignments.

Examples being recursive functions, sorting functions, Dijkstra's shortest path algorithm, stuff like that. However I have recently had to cope with people being given exactly the same type of assignment, and being allowed to download pre-built classes for them! What, I ask you, is the point of that?

Re:In my experience...

[Flodis]

VB is a rapid prototyping environment. And just like an RP machine, it makes a flimsy product that you can send back to the drawing board without much expense. But you don't ship a product you've made on an RP machine -- it's crap. You take your prototype, and make a real product out of it using sturdy materials. Same goes for VB. You make something that works the way you expect, then you make it work in a real language. Good thing about VB is that you can replace pieces at a time with DLLs compiled from C++. If that isn't a part of the VB curriculum, it's a waste of time.

Sigh... To me, this sounds like a typical rant from someone who doesn't have any actual experience.

Anyway... I think the problem may be that VB is too easy to use. People who would not be able to write the makefile for their 'Hello World' program in C++, are able to write working but very rickety/ flimsy VB programs.

I happen to make a living as a computer consultant. This means I get to see a lot of different organizations and their in-house software... This means a LOT of VB code... And of that VB code, a lot (maybe 90%) is written by people who may know their business but don't have a clue about programming. I can definitely see how that would create the reputation that VB programmers are bad, but not how it makes the LANGUAGE bad.

As for stability, I can promise you that some of my VB programs are a hell of a lot stabler than the memory-leaking SEGF/GPF-ing C++ hacks they replaced. In case you didn't know - it's perfectly possible to write shitty C++ code too. It's just that you have to get above a certain level to even get the compiler to work, so most of the would-be self-made computer wizards turn to something easier instead.. Like VB.

The big question here is: Is it better to have a flimsy but functioning VB program or a defunct makefile? I'm not sure of the answer myself. A defunct makefile is a 5-minute job to fix, whereas some of the VB messes I've seen would literally take years to get straightened out. (I hate people who think they can program just because their $h!+ compiles.)