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."
It is,
int main()
{
cout "Hello World" eol;
return 0;
}
Very cool at first, then it just goes down from there.
Please... he's one of the most influential people in the field of computer science today, at least spell his name right.
My understanding was that much of Google was in python.
Why try to imagine it, can't we just remember it?
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!
WorldWideWeb, being on a NeXT box, was written in Objective-C, not C++.
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
FTFA: I hope you didn't put too much money on it! I don't see aspect-oriented programming escaping the "academic ghetto" any day soon, and if it does, it will be less pervasive than OO. When it works, aspect-oriented programming is elegant, but it's not clear how many applications significantly benefit from its use.
Totally agreed. AOP is a strange form of "dynamic" insertion of code at special "cut points" of execution within the code and represent a very very lazy way to avoid good OOP structure of your applications.
In a bigger framework AOP can be totally unpredictable and wreck otherwise locked and working code.
When AOP started to pick some speed in the beginning I was naturally both interested and slightly annoyed that so short after OOP here's yet another concept for programming I have to learn and implement in my software.
Not so fast though, since as much as OOP provides useful abstractions that makes your code more readable and predictable, AOP does exactly the opposite except in few very limited cases.
The cons outweigh the pros.
Javac is the coolest program written in C++ :-)
Some drink at the fountain of knowledge. Others just gargle.
Where in "Plain Old Text" you have to escape < as <
Claiming Google as a cool C++ program is about 1/3 true. Most Google code is written in C++, Java, and Python: C++ for performance-critical stuff, Python for scripting, and Java for everything in between. The trend is definitely toward Java at the expense of the other two.
Also, for what it's worth, Google's use of Aspect-oriented programming is ramping up pretty fast.
"Severe resource constraints"? Since when a datacenter with half a million servers in it is called "resource constraints"?
Ooh, but your analogy can extend! Sure, I can go down to Home Depot and buy some interior paint to spruce up my living room, or some 2x4s to build a new deck, or something like that. But have you ever heard of building inspections? Anytime you do serious work, like an addition or a new building or even heavy electrical, you're probably going to have to get permits, submit plans, and then have a licensed building inspector come out and check your work. And it if ain't done to code, you're going to have to rip it all out and hire somebody who know what they're doing.
The reason behind all this bureacratic, intrusive government oversight is that building codes are written in blood. Code specs have emerged over time because people died when buildings collapsed, or bad electrical wiring caused fires. The lesson is that if you're not doing something that could cause injury or death, go ahead and do it yourself. If not, you'd either better learn the right way to do it or hire somebody.
Code divides into similar categories, although I the decision point is different: Is the failure of this application tolerable? It may be a question of lives at risk (avionics, air traffic control, miliary systems, automotives braking/control, medical) or it might just be economic (my business stops and I lose money when our servers bug out). It's only prudent to analyze your situation and come to a rational decision about whether you want to tolerate the risks of hiring professionals (or learning professional methods and implementing them yourself), versus playing pickup ball.
Having lived through a couple of start-ups, both successful and unsuccessful, I can tell you that the different approaches do make a difference. I think that's what Bjarne is getting at: if the application matters, you'd better do it right.
The problem is that two different translation units define two different versions of struct A.
... in a program provided that each definition appears in a different translation unit, and ... each definition of [the name defined more than once] shall consist of the same sequence of tokens ..."
Relevant parts from Section 3.2 of the cpp standard:
"There can be more than one definition of a class type
In the example provided, two translation units have definitions for struct A. However, they are not identical; in particular, one has members that are ints, the other, shorts.
However:
"If the definitions of the [name defined more than once] do not satisfy these requirements, then the behavior is undefined."
In other words, the compiler is not required to diagnose violations of the ODR (One Definition Rule).
In this particular example, the compiler compiled bar as if doprint had a four-byte argument* (two shorts) but then threw out one of the definitions of doprint, leaving the other to treat shorts as if they were ints.
*or maybe an eight-byte argument with misc padding that wasn't cleared
Um. Yeah. Er.
"WorldWideWeb was written in Objective-C."
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
What is a language anyways but a context free grammar? The school I goto teaches Java as the primary language, but once you get into the junior, senior classes you branch out into C and C++ (they even teach Cobol, ewww, I know). Once you take on Automata and Computability, and learn about CFG's then the language isn't the problem. On the other hand, learning a paradigm (like OO vs Structural) can be a bitch.
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
You might think twice about using C++ after reading this interview with Mr. Stroustrup.
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.
No, the reason is very simple, C++ was to be compatible to C and C uses pass by value as default. What kind of language would have resulted from passing variables of type int by value and objects by reference? Sorry, but I don't think I would want to program in that.
And I always thought that was what the Java developers said, that they made the language simpler by removing the confusing parts from C++ which are rarely needed. By simple reasoning you get exactly what Bjarne Stroustrup said, no? C++ is more powerful but also much easier to get wrong. So it needs better and more experienced developers (which it rarely gets and that is in large part why C++ is blamed so often). Is it so hard to accept that there might be languages which are "better" (I don't even know, if harder and needing more experienced programmers is "better") in some way or other?
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
What kind of language would have resulted from passing variables of type int by value and objects by reference? Sorry, but I don't think I would want to program in that.
But that is exactly what Java does. I thought it sounded bad at first too, but it works really well.Is it so hard to accept that there might be languages which are "better" (I don't even know, if harder and needing more experienced programmers is "better") in some way or other?
When I first started on Java (I was 'forced' to learn it for a Uni class) I thought it was lame. 'How will I be able to do anything without pointers?!' After a few weeks I gave up the ghost deciding that there was a lot of stuff in Java that made life easier. C++ does need developers that are very experienced--in C++, but I don't think that necessarily makes them 'better'. As I said, it has its place in a few specialised areas, but it's not the general purpose tool it one was. It just seems like Bjarne can't really see that.Power is the problem.
The most powerful flow control construct is if/then goto. It's more power than you need.
Likewise C++ has more features than anybody needs, although most of the features may be needed by somebody some of the time.
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. 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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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.