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.
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".
mine teaches java prediminantly, and I've had to tutor third year students who seem to lack more then rudimentary programming skills.
The logic they go by seems to be 'Download a class for it, no need to code it yourself'. It drives me crazy.
Well, one good reason to accept the possibility of segfaults is speed. C and C++ allow you to get down as close as you want to the underlying hardware, which (if the programmer is sufficiently skilled) can produce much faster code. Obviously this doesn't matter much in your average desktop software, but there are are any number of application types (3D games, simulations, animation/rendering systems, system libraries) where speed is still very much a concern.
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
You mindlessly claim that allowing people to make operators do different things on different types is a bad thing. Do you actually know what's good about supporting operator overloading? It's the ability to make operators do different things on different types. Now that's a pickle for you. Care for an example? Let's take a class that represents complex numbers. Tell me what's bad about being capable of doing something like:
That piece of code is only possible thanks to operator overloading. The same applies to vectors, matrices, tensors, etc... Heck, what about those extended precision/range number classes? Where would they be if it wasn't possible to overload the basic algebraic operators?So it is easy to see, at least to anyone which has at least a basic grasp on C++, that operator overloading is obviously a good thing. Heck, where's the bad thing about being capable of defining operators on a data type?
OTOH, if you have a problem about the way some coders use operator overloading (i.e., doesn't match your personal taste) then put the blame where it should be put: the coder's decisions. No one forces anyone to use, for example, a multiplication operator to concatenate strings or an addition operator to insert objects into a list. Stroustrup isn't holding a gun to that coder's head, for God's sake. Yet, to some people the use of those operators for those particular tasks is a nice thing to have.
So please don't claim that a feature is bad or broken just because you fail to realize it's usefulness and potential.
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
My recollection is that Stroustrup was:
- encouraging library extensions rather than language extensions, acknowledging that the language was already complex enough as it is
- encouraging language changes/extensions only where they make C++ easier to learn and understand
Specifically, you may want to check http://www.artima.com/cppsource/cpp0x.htmlShort of dropping backwards-compatibility with the current code base, what kind of language changes would you like to see? C++ is unique in that it has hiding without safety. Noting in the C++ standard requires the language to be "unsafe".
If you look at standard C++ library implementations, for example, some are currently providing ubiquitous range-checking (within the library). Compliers have started to provide built-in checks for buffer overruns. You can integrate a garbage collectors as add-on (personally I much prefer RAII). And C++ could be compiled to a virtual machine.
But the standard does not mandate any of the above, because it does not want to preclude the use of C++ for system programming.
And it also just seems that the community of C++ users still remain more interested in the latest optimizing compilers and auto-vectorization capabilities, than in the safety-enhancing features.
Java for example is simple, because there are only vert few implementations in existance
The reason Java is simple is that it didn't try to be a multi-paradigm language, where the inevitable trade offs left C++ inadequate in every paradigm. Java was also well described in a decent specification rather than being standardised too late in the day as happened with C++. There also exists a canonical Java test suite, whereas the C++ standard is littered with opportunities for implementation specific functionality, especially in the STL.
Also the STL is not that complex as you think and it really is efficient, if used correctly.
I can write efficient code for Sun's implementation of the STL that will generate multiple calls to the copy constructor in GNU STL when adding an object to a container. Neither STL version violates semantics as described in Stoustrup's book, it's just one of a vast number of implementation specific features that are allowed in an STL implementation.
There is no all-purpose language that is ALWAYS simple, efficient and elegant.
No, but I struggle to think of a single instance where I have encountered C++ code that proved to be simpler, more maintainable or more efficient than the equivalent written in C, Perl or Java. Of the three large C++ based projects that I have become involved with, two were scrapped and replaced with a mix of C and Java. The third is still proving to be a hindrance to those trying to maintain and extend it, so much so that a parallel system is evolving, largely written in Perl.
CFLAGS += -lgc
That's interesting. I learned Pascal first and then C. The reason I found this helpful was the Pascal was more controlled (I can't remember all of the correct words anymore). C allows all kinds of memory allocations, redefined pointers and such which are brutal on a beginning programmer. Pascal prevents a lot of those mistakes, therefore giving you a chance to learn some concepts without too much disaster. As for perl/python/lisp. I think lisp is great for showing another way/paradigm of programming. Perl/python/ruby allow you to merge everything together. Of course Smalltalk/Squeak would be great for bringing home object oriented programming. After that PHP, JSP, ASP, whatever is just suited to the environment you're working in. Reality is that you'll probably never get that many programming languages into a B.S.
"The difference between stupidity and genius is that genius has its limits." -- Albert Einstein
Which is why I said C++ may be the language you want; certainly there are other candidates. I'm saying I would not reccommend anyone use C++ on an irregular basis. If you're a biologist who does some coding on the side, don't use C++; and don't be surprised if it seems unsuited to your needs.
By analogy, I'm a coder who occasionally does some welding in the garage on weekends. Professional welders would scoff at my hobbyist-level equiptment, and be insanely frustrated by its limited capabilities. But were I to use their equiptment, I would quickly reduce my project to a bubbling pile of slag, and probably set something on fire.
I know sys-admin types, who use a lot of Perl for the myriad little bits of programming they have to do. For real software development, Perl is not an option.
Completely agree, on rereading I realise I misunderstood the last line of your post as implying that if you don't want to use C++ you're not a professional. Mea culpa :)
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
K&R did not commit Javascript, and aren't responsible for the problems in your examples.
K&R invented C. In it, and the myriad that follow it's lead, variables will sometimes get converted to closely related types for the purposes of expressions that need them. I for one want to be able to write
float x = 2.0 + 2;
without the compiler throwing up it's hands in a panic not knowing what to do.
But numbers will not be converted to strings, and of course conversions will have no lasting effect on the variable in question. That would obviously be completely insane, and the utter moron who thought it was a good idea should rightly be forced to write javascript all day, and electro-shocked for every bug.
Finally, if the number of bits in your floats matters, you can specify it precisely. If, with any regularity, you'd rather have a specific number of bits in your floats rather than whatever the processor handles natively (and thus rapidly), you shouldn't be using floats. Floats don't represent things exactly, no matter how many bits they have. (Well, contrary to your example, they tend to represent powers of two exactly, but that's just trivia.)
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.