Slashdot Mirror
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.'"
...at a university I know, they start teaching you programming in...Visual Basic. I can imagine the effect that has on the poor confused heads here who never eventually grasp other languages (including VB).
Maybe if they started with something like Pascal or something...but thats just not 'modern' or cutting edge nowadays...
I think this is the case in many institutions leading to low quality coders.
I wouldn't take programming advice from a guy who overloads the bit-shift operator to perform I/O.
Crack - Free with every butt and set of boobs
Now that is just ridiculous. I'm using IE7 to post this article, and have been using it since its release, and I can say
This is only my second favorite Stroustrup interview. The first is here: http://www.chunder.com/text/ididit.html (Yes, I know it's a hoax.)
"...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).
The Firefox codebase is indeed a mess. Don't take my word for it, view it yourself: http://lxr.mozilla.org/seamonkey/source/.
Part of the problem is the severe over-architecturing. This over-architecturing has added much unnecessary complexity to the overall design of Gecko and Firefox. Much of it is "justified" in the name of portability. But then we find that other frameworks, including wxWidgets and GTK+, do just fine without the overly complex and confusing architecture of Gecko and Firefox.
It's just not easy for most developers to become up-to-date with the Mozilla codebase because of all this added complexity. Unless a volunteer developer has literally months to spend learning even the small portion of the code they're interested in working on, it's basically inaccessible to most programmers.
The constraints of the real-world often come into play, and we have developers modifying code they don't necessarily understand fully. And so we get the frequent crashes, glitches, memory leaks and security problems that Firefox 1.5.x and 2.x have become famous for.
It's likely that Mozilla should ideally rewrite a vast portion of their code, keeping simplicity in mind. That likely won't happen, and thus we will most assuredly still run into problems with Firefox and Gecko, problems caused directly by the overcomplication of the Mozilla architecture.
Stroustrup developed much of the cfront C++ compiler, which itself was written in C++. It received widespread use on most UNIX platforms, and was the default C++ compiler on systems like HP-UX and SCO UnixWare. Numerous organizations licensed it, and some even offered ports to systems like DOS.
He was the head of AT&T Labs' Large-scale Programming Research department for a number of years. I'd imagine you're not familiar with some of the cutting-edge research he was responsible for when it comes to massive software systems. Had you actually been familiar with his achievements, you wouldn't have accused him of coming up "short in the real world department".
The good thing about working in software-centric companies (besides understanding the programmer psyche) is that they often don't balk as much at being told something can't be done in a timeframe. Blizzard doesn't blink an eye when it has to delay a game by a year (probably more like 2 or 3 years when compared to internal, non-public set dates). Microsoft finally decided to nuke WinFS once they finally conceded that you're not going to get it within this decade, no matter how much they throw chairs. Google apparently has almost no schedules.
To all those people saying C++ is too dangerous/prone to errors and Java/C## is the way ahead:
Stop blaming the tools and look to yourselves.
C++ is like a sharp scalpel. Yes you can hurt yourself if you're unskilled, inexperienced or sloppy.
Java and C# are like those scissors with rounded ends for kids. Totally inefficent but safe for beginners.
Unfortunately it seems that there are a lot of people out there who like to call themselves programmers but have no actual ability. Java/C## does a good job of removing their need to think and hiding their inate lack of skill which is why they prefer it.
But there's a reason why surgeons don't use plastic scissors. The same applies to good software engineers.
Anyway, the typical unsophsticated (software development-wise) customer can't tell the difference between the two. This is made worse when many managers who were supposedly professional programmers themselves can't tell the difference. As far as I can tell, the only way for a programmer to deal with this is to simply BE great and be ready to move on if the customer can't see that greatness. Eventually they'll get somewhere that will appreciate it.
I also cover some of this in another reply.
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.
Of course surgeons don't use plastic scissors. But how often do you need a surgeon? Most of the time you need a cheap tailor to make you a suit. And that's when scissors come in handy.
C++ can do wonders when used by highly experienced people. But most of the time, it is more cost effective to get entry level coders and use PHP/Java/C#/whatever. You will get a (somewhat) working product cheaper and possibly faster. And time to market and cost is often more important than maintainability/quality.
And don't get me started on 3rd party C++ libraries. You'll need tons of them to move a finger, and you'll spend more time finding/eavluating libraries than coding. This problem is getting worse for other languages too...
--Coder
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.
No benchmark is ever going to be a definitive measure, the best they can ever do is give you an idea or the general qualitative differences. I think you'll find, however, if you were to actually try Ada, Eiffel, D, or OCaml for an entire application, that they do, in fact, compare very well with C++ - it's not like there aren't any significant large applications written in those languages (well, possibly not D): they get plenty of use in various industries and are well known for their efficiency.
Craft Beer Programming T-shirts
Sounds like what you want is simply not what C++ designed to deliver. Blame yourself for not choosing the right tool, not the tool itself.
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 ...
s /NoSilverBullet.html
http://www-inst.eecs.berkeley.edu/~maratb/reading
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. 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 :* CR :* (obs-char LF :* CR :*) :*))
(LF
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.
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?
Hmm...
:) Not sure where you'd want to throw in a scripting language; or if it's even really neccessary... what skill do you learn from learning a scripting language other than the language itself?
I'd say pascal first as an introductory programming course, then C, then some assembly, then finally C++ or Java.
It's a lot easier to learn sequential programming when you're not busy shooting yourself in the foot... let them hit C after they know what a conditional and a loop are
Maybe in usage, but that doesn't lend itself well to learning. Learning, by definition, is the process of reinventing the wheel so that you understand how the wheel works. They don't teach algebra by presenting the quadratic formula and saying, "Here, use this when solving a polynomial of degree 2" - they lead you every step of the way through the development of the quadratic formula so that you know how it works and why it works. Likewise, programmers learning to program should be writing quicksort implementations rather than ignoring the details because "it's already implemented in a library".
Of course, once you've graduated and are a professional writing a program for somebody else to use, you should reuse what's available as much as possible.
Proud neuron in the Slashdot hivemind since 2002.
it's not-so-strongly-typed variables, funny rounding rules and so on
I know they're like [pagan] Gods to an awful lotta people in the CS community, but The Founders of The Art, guys like Kernighan, and Ritchie, who had the chance to insist that a declaration actually mean something, but hesitated, and hemmed and hawed, and got all wishy-washy, and finally decided [really deferred a decision until it was too late to make a decision] that a declaration could mean any-damned*-thing that the implementor wanted to interpret it to mean, well those guys, those pagan Gods of the Founding Arts, seriously - someone should take them out behind the toolshed and whip their asses** [if not shoot them outright].
So now, fast forward 30 or 40 years, and we've got:
And then you go to do something in VB, or in Javascript, and you get shit** like
or, what's even worse,
and you end up having to write shit**** like
and you scream at your computer, "YES, THESE ARE NUMBERS, NOT CHARACTER STRINGS, YOU GOD-DAMNED***** COMPILER/INTERPRETER/SYNTAX/PARADIGM/NIGHTMARE OF A SACK OF SHIT******!!!!!"
PS: There is a special circle in Hell******* for the sonuva bitch******** who dreamed up the idea of interpreting variable types on the fly...
*Pardon my French.
**Pardon my French a second time.
***Pardon my French a third time.
****Pardon my French a fourth time.
*****Pardon my French a fifth time.
******Pardon my French a sixth time.
*******Pardon my French a seventh time.
********Pardon my French a final time.
I think they should learn computer languages in the order that they evolved: assembler first, then FORTRAN, then Pascal (as the ALGOL representative), then C, then Smalltalk. Maybe throw Lisp in there between FORTRAN and Pascal (even though I believe it's older than FORTRAN). Actually, C is kind of a step backwards from Pascal (limited scoping and no built-in I/O), maybe just tack that on to the last couple of weeks of assembler.
And let's not forget that students should really be studying computer science, not programming. They shouldn't learn how to do a binary search, they should learn why it's such a powerful technique. The implementation falls out naturally from the description. Likewise for trees of various flavors. Teach them how to identify the language features that best support the algorithms they need, and let them figure out which language is most appropriate for themselves. After all, any language they learn in college will be out of favor by midpoint in their career anyway (or earlier, for those of us that learned Pascal...), so better to teach them how to learn a new one from the start.
Just junk food for thought...
Why have pascal in there at all? Let it die just let it die.
starting them out at assembler is jumping the gun. surely they should learn to use an abacus and a slide rule before moving on to Babbage's mechanical computer and then assembler programming on punch cards
While you can bash the tools as much as you want, the point remains that the majority of the fault for bad programs lies with the programmer.
.S files created by your compiler? Do you even know what they are? Could you load an object file into a disassembler?
Just as an adept sculptor can build a beautiful (though somewhat rough) art piece using a chainsaw, so can a good programmer make do in situations where he is forced to use the wrong tool for the job.
Namespaces can be simulated with a good naming convention.
OO can be accomplished in a procedural language.
Technologies can be married together, and even replaced in part with other technologies at a later date (it's called refactoring, folks!)
I currently program exclusively in Java. I learned from the ground up (Analog electronics -> Digital logic -> Machine code & Assembly -> C -> C++ -> other OO languages & scripting languages, AOP etc)
I'd love to have multiple inheritance in Java, but I hate the fact that you can't rebind a reference in C++.
I'd love to have real properties and closures supported by the Java language proper, but I make do with standardized boilerplate code in the meantime.
I love the quick UI building you can do in VB, but I certainly wouldn't want to write business logic with it!
Access is great for building quick and simple systems, and does its job well, but I'm not going to store 10 million records in it!
Nothing beats the speed of a library written in assembler, but I'm certainly not going to write database access code in it!
Perl is a great tool in the right hands. In the wrong hands, it is the worst disaster ever, and the first thing I get rid of when I take over support of a project (except for 10% of the time when the previous programmer was competent).
I've seen horrendous code in every language I've ever encountered, and it's always a result of the programmer not understanding what he's working with. My personal opinion is that you shouldn't be programming unless you understand at least one layer below where you're working.
Do you know how to examine a core dump? How about interpreting a Java HotSpot dump?
Do you understand how the technology you're working with interacts with the operating system?
Do you know how the auto-code generator deep within the script overlay you're using actually works? Have you even once looked at the intermediate output?
How about the
What will you do when something goes wrong with it? Give up?
Do you follow the generally accepted practices used in your domain? Do you even know what they are?
Do you know what domain driven design is?
Do you understand when it's a bad idea to use inheritance? (Answer: most of the time)
I could go on forever. The point is that good programmers find the right tool for the job because they understand how it all works. Hackers do it fast, but forget to make it readable or maintainable. Bad programmers just plain do a bad job and make things shitty for everyone.
There's actually a language called D that is related to C++ and is supposed to fixe a lot of C++'s problems, and annoying syntax. Features.
There are 11 types of people, those who know unary and those who don't.