Slashdot Mirror
Bjarne Stroustrups and More Problems With Programming
Phoe6 writes "As a follow up to the first part of his interview, Technology Review Magazine has another article running titled 'More Trouble with Programming'. Bjarne Stroustrup shares his point of view on good software, bad software design and aspect oriented programming." From the article: "Technology Review: Name the coolest and lamest programs ever written in C++, and say what worked and didn't work. Bjarne Stroustrup: Google! Can you even remember the world before Google? (It was only five years ago, after all.) What I like about Google is its performance under severe resource constraints. It possesses some really neat parallel and distributed algorithms. Also, the first Web browsers. Can you imagine the world without the Web? (It was only about 10 years ago.) Other programs that I find cool are examples of embedded-systems code: the scene-analysis and autonomous driving systems of the Mars Rovers, a fuel-injection control for a huge marine engine. There is also some really cool code in Photoshop's image processing and user interfaces."
Why try to imagine it, can't we just remember it?
How could something that large and efficiency-dependent be written in non-native code?
I should probably add that i 100% agree with this statement
I think that would be misguided. The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.
Very interesting read all together!
Java and C# dont really augment c++. I think what Bjarne meant was they have augmented the programming paradigm in the sense that developers are able to focus more on adressing the problem space rather than the nitty gritty implementation of the the solution.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Programming, yes, but not in C++. Generally, Computer Scientists use languages like Smalltalk, Scheme and Haskell which aren't bundles of watered-down paradigms.
Please, for the good of Humanity, vote Obama.
Programming, yes, but computer science doesn't use C++.
Bull. At least sort of.
First, it depends in part on what your definition of computer science is. Most CS courses are taught in a C-like languages. At my undergrad institution, most of my programming assignments were done with C++. Sure, there was exposure to ML, but my impression is that most places that's mostly confined to the PL classes. (There are some notible exceptions that use ML or Scheme for intro courses.) Even at those institutions, I expect that later classes have assignments in a C-like language.
Second, there's a lot of CS that relates to C++. Compiler theory of how you implement things about it, and language design. It's not about C++ specifically, but it certainly relates.
Third, there is a fair bit of work in PL that directly relates. Not all PL is people in ivory towers coding in ML and Lisp. CCured is a very nice bit of work, though it's only C because it's built on top of the C Intermediate Language (CIL). There's early work now to create a CIL++, and I'm sure that it hasn't escaped anyone there about the potential to extend CCured to C++ once that's done. The parser for CIL++ will be something called Elsa, which was a major part of the research of one of the people there. My own research is indirectly related even. I'm looking at static analysis of binary code. Earlier work done in my group was explicitly directed to being able to find vtable pointers that C++ compilers produce.
You're right to the extent that the core of CS is really in some sense applied math, and is entirely language-neutral. However, to say that C++ has no relation to CS because it's just programming (which CS isn't about) is just wrong.
"Severe resource constraints"? Since when a datacenter with half a million servers in it is called "resource constraints"?
True, but there are huge classes of applications which are tremendously useful, for which a failure is tolerable, and which are relatively easy to write. So I strongly favor the existence of languages which allow people to write code with only a few months training. And as a professional software developer/computer scientist, I don't feel threatened by it - I wouldn't want to write those applications. When they need something more complex or more robust, they'll come to me.
Severe ranting ahead, you have been waned...
That's just the problem, a lot of companies don't come to professionals when they need something more complex or robust. They usually start off hiring a bunch of amateurs who have no firm grasp of professional software design because they are cheap to employ and let them loose without proper supervision. These people cobble together some system that works, it doesn't work very stably, but by and large it works if you constantly monitor it and as long as it the system is still relatively small. This system gets maintained for a while and added to. These additions are usually badly designed or even worse, quick fixes intended to patch up problems that could have been avoided if the system had been properly designed in the first place. As I said before, while the system is still relatively small the bad design does not matter so much but as the system's complexity, the load the system is subjected to and it's importance to the company grow the instability and constant hiccups due to bad design begin to become a liability. This is usually the point the company finally decides to call in the professionals who are then confronted with a system that badly needs a complete rewrite and an employer who expects the necessary rewrite to be done in a couple of weeks and on a shoestring budget. My experience is that a lot of the time (not to be read as: **always**, there are companies out there who proper design work) the professionals are called in to clean up messes created by people who learned to write code with only a few months training. Way to many of the jobs I get involve cleaning up problems created by people who committed basic errors such as duplicating code all over the place instead of building it into class libraries and who didn't seem to be aware of the existence of nifty utilities like 'javadoc'/'doxygen' and 'subversion' or even revolutionary concepts like 'multi-line code comments'. Not that I am complaining mind you; the clumsiness of these badly trained developers and the frugality of the managers who hire them keeps me, a professional university educated software developer, employed but it's still a frustrating way to make a living because a lot of the crap I have to deal with could have been so easily avoided.
Only to idiots, are orders laws.
-- Henning von Tresckow
You know why schools teach Java instead of C++? So they don't have to teach pointers first. At least that's how it seems to work at Georgia Tech...
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Penicillin. Lisp. BSD. Shannon's information theory. Smalltalk. The Web. The Internet. All of these came out of academia. Saying that academia is bull is saying that pure research counts for nothing. Well, look at number theory. Once considered unsullied by practical applications it now is used in cryptography. The atomic bomb started as pure research.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
What is a language anyways but a context free grammar?
What? What kind of question is that?
If anything, it's the context free grammar part of languages that is LEAST interesting and, with the arguable exception of C++, easiest part!
A language is a mapping of syntactic elements to an actual action that the computer will perform. Saying "x ? y : z" is a legal expression means almost nothing; saying "x ? y : z means that the computer will evaluate x, convert it to a boolean value; if it is true, the computer will evaluate y and that will be the result of the expression, otherwise the computer will evaluate z and that will be the result of the expression" is what a language IS.
Even ignoring semantics, there's a large number of syntactic rules that can't be specified in a CFG. For instance, "int main() { return x; }" is not a legal C++ program, but there's no way to say that variables must be declared before they are used. "5.4 + "hello world"" is (I hope and think) not a valid C++ expression, but the CFG doesn't capture that.
The language part of the C++ standard is about 300 pages. The context free grammar is about 25. (And that's not doing much to make it compact either; that might be one column of grammar rules per page.)
AOP solves the N times problem nicely. For instance, if you wanted to take an object with N methods and add a call x() to each of them, if you used ordinary OOP, you'd have to override every method, then call x() from each method. What's the elegance of that? I don't see how "proper" OOP can solve this sort of problem better than AOP.
AOP is largely mysterious and confusing because it's not something (yet) integrated with any standard languages. If it were integrated, then there would be proper tool support, recommend methodologies, references, implementaiton refinements to make AOP easier.
And in a sense, AOP isn't new to Java. Have you ever used the Java "Proxy" class? AOP really just provides a java.lang.reflect.Proxy "version 2.0".
Maybe AOP won't be used except by container providers, i.e. people writing EJB3 implementations.
Vividly... Searches for Hippopotamuses turned up porn. Searches for C++ turned up porn. Searches for Slashdot turned up porn...
Other than the porn, there were dozens upon dozens of pointless hits for sites that only in-passing included the search term you wanted, and perhaps not even that, as search engine databases were often years old, and sites completely changed in that time. What's more, there was never any spell-checker, so with a trivial mistake, you could be wasting all that time with the wrong term, and never find what you want.
Finding anything was laborious and extremely time consuming. Now with Google, almost ALL search engines have raised their standards near the Google level (alltheweb seems to be somewhat of an exception) and now only a tiny fraction of searches turn up page after page of pointless crap.
However, Google doesn't seem to be improving much these days, while there are obviously other ideas to be explored. On vague or expansive subjects (or just if you aren't particularly good at searching) Clusty tends to be a better bet, as it automatically categorizes your results for you, allowing you to trivially easily narrow them down... much moreso than if you just included additional categorizing terms in the search.
Yes... fondly. Links neatly grouped together in the same spot on every page, not in colors that blend in with the background, in tiny font sizes, or hidden in buggy, inconsistent javascript sub-sub-sub menus.
No god awful color schemes, or Flash-only sites. No sites that have huge columns on the left and right sides (with almost nothing useful in them) that squish the center column (content) down to one-word-per-line (I'm looking at you, Slashdot).
Never a single site that depended on your screen resolution (now all but 0.01% of websites are utterly unusable in 640x480 or below).
No cookies, no javascript, no background images, no BLINK element, no pop-up windows, etc. To make a site, you actually needed CONTENT, not overindulgent designers.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
AOP is object oriented come from. It can trash maintainability. In any program using AOP you can't look at any call in the entire program without assuming there's an arbitrarily large block of code somewhere else messing things up.
While it's true that AOP can help the classes of problems it solves are fairly small compared to the cost it brings. Instead, adding calls to the first/last line of method implementations is no big deal. Less consistency checking but more debugability. If all you've got is binaries then AOP will get you going but in that case your solution of a derived class is workable and documents the fact that you've changed the behavior of the entire class.
---
Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.
The downside is that you'll have to explain what " public class " is. What " public static void " means.
The best intro language remains to be pascal. I don't know why people get so fed up with it. Sure it's not as powerful or as popular as C/C++/Java, it's a bit verbose, but the language is clean and readable.
Don't quote me on this.
I have quite a bit of experience with C++ and this example is just _one_ of a seemingly unending list of problems that bite the unwary C++ programmer. And without 10s of years of experience, there is _no way_ you can know about all of these. Some of my other 'favourites' are problems related to ordering of construction/destruction of static objects, virtual overrides becoming overloads without warning (try to change one of the arguments of a virtual function to be 'const' in the base class and what happens if you forget to do the same change to the override in some derived class?), all kinds of memory overwrite bugs caused by hanging on to pointers to memory that have been freed, being able to pass the address of an object on the stack out of a function (there is no excuse for this, the kind of program analysis done by optimising compilers could catch this easily -- the worst thing is the code often works at first but breaks much later when no-one has a clue where the bug is). And so on, and so forth...
Unfortunately the code I write is performance critical, so I have to put up with the nightmare that maintaining and extending a million line of code C++ project is...
The interactive way to Go -- http://www.playgo.to/iwtg/en/
And the three Smalltalk books describing it are even more pages than the C++ book, so obviously ObjC is inferior to both? What a stupid way to compare programming languages.
ObjC is a language which has a core with a static type system, which is somewhat weak because of the ease of casts and on top of that a language with a dynamic type system. So basically you have the worst of two worlds. It is neither as efficient as C/C++ nor as elegant as Smalltalk. And yes, C++ is multiparadigm, structured if you basically use the C core, object-oriented when you use the class system and generic when you program with templates. ObjC is also multiparadigm, structured and object-oriented, but dynamic typing doesn't need generics, so it has no concept for it.
And sorry, but the learning speed of a language is not determined by the number of symbols. Without the supporting libs you can't do anything in either and I doubt you learnt the OpenStep libs in a day. The same is true of C++ and expecially Smalltalk. That language is so small that its syntax graph fits on two pages of the first Smalltalk book. So by your reasoning you should use Smalltalk, why don't you?
Please understand me right. I don't like ObjC as you obviously don't like C++. I have my reasons and you yours. But I really, really dislike the claim of ObjC being "basically C + Smalltalk" because that is simply not true. And I have programmed in all four languages, C, Smalltalk, ObjC and C++, although the least amount in ObjC because I heard the claim "it is like Smalltalk" (which I already knew at the time before trying ObjC) and was very disappointed, no, it is not like Smalltalk. Interestingly I never heard someone claim it who also knows Smalltalk.
Apart from the fact that the #includes are missing it's not C++. Shure (with the missing includes) it might compile. But it is not the way it is done in C++.
The C++ (as well as C99) standart define 0 to be the null pointer. With older C standards that was different and there where indeed some platforms with:
#define NULL ((void*)-1)
which means that
if (s && s[0] != '\0')
won't work. But that' all over now - it's the null pointer is 0 now. on the other hand C++2008 is likely to get an extra null pointer keyword.
But it does show the greatest problem of C++ programming: Most C++ programmers don't actualy know how C++ works. And just because MS used NULL it does not mean it is current standart.
Martin
I suspect that's because, in the grand scheme of things, parsing is easy, particularly if you can structure your language so that it's simple to parse. It's also easy to write a textbook on parsing, because it's basically a cookbook of the usual methods with a few examples thrown in (though most authors don't seem to be very good at that part, which makes me question how much they really understand themselves and how much is just regurgitating what they once read in someone else's notes).
On the other hand, writing a compiler that optimises well (particularly in languages that don't lend themselves to easy optimisation), or a virtual machine that uses JIT compilation efficiently, or code generation engines that support compatible ABIs so you can link across programming languages... those things are seriously difficult. Even with all the effort concentrated on the big commercial tools or the big OSS players like the GCC, it's only in fairly recent times that JIT has become popular, and optimisation over the whole code base of a language like C++ is performed.
I've been interested in this field for a long time, and I've never seen a book or a set of lecture notes that come even close to the kind of detail you'd need to understand to write code that does these things. As you said, most of the standard references are just a checklist of compilation stages and a few kiddie examples of parsing that don't really convey the significance of each step anyway. All in all, I think compilation techniques are probably the least understood (and perhaps most misunderstood) of all the major programming areas. That's a shame, because we could certainly do with someone developing a good programming language one of these years! :-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The answer to this is not to hire unwary C++ programmers, but rather competent professionals. C++ is not a language for newbies or cash-grabbing McProgrammers, and I rather doubt Bjarne or anyone else on the standards committees has ever claimed it was.
A professional would immediately tell you that you should not rely on the order of construction or destruction for statics, that the derived class implementation will hide the base class one in your const modification case (precisely to prevent the kind of problem you described, actually), that you should rarely need to use simple pointers in C++ code so your released memory problem shouldn't be a problem in practice, that pretty much any recent compiler will warn if you try to return a reference to a local variable, etc.
Most of this stuff is in the better introductory books, the main FAQ, and countless "how not to shoot yourself in the foot" guides. Anyone who hasn't come across them doesn't know their subject well enough to be using it for real. If you want to hire people in that category, sure, give them Java or something, where the balance between safety and expressive power/performance is different. Just don't expect the kind of results you could have had by paying for professionals to do the job with more powerful tools.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
This is not a criticism of Stourstrup; C++ simply implements what everyone thought was necessary in a high performance OO language twenty five years ago.
Sorry, no, that's false. People knew pretty much as much about OOP and high performance language implementations back then as they do today: dynamic compilation, dynamic optimization, generational garbage collection, incremental compilation, runtime class updating, method dispatch optimization, etc.
Since the paradigm was not in widespread use, it's no surprising that the design is different from what we'd come up with today.
We haven't "come up" with anything "today". What happened is that people like Stroustrup incorrectly postulated 25 years ago that efficiency was more important than good design and designed languages without what they naively considered "inefficient" constructs. We have been spending the last 25 years putting these features back in again. Today, Java and C# are almost where OOLs were before C++, except that Java and C# are far more bloated and less consistent.
Stroustrup was simply wrong, and he could have known better if he had done his homework.