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."
No, not the data-crunching engine, not the indexer, not the ranker.... Python (and java, and ruby) is cool, but, frankly... sometimes you need the most of your hardware.
Your ad could be here!
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.
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.
Actually the vast majority of recently written (last 5 years) code I've seen from CS departments (at very good schools) has been in Java, with C++ a somewhat distant second. This seems to apply across the board, from hard-core long term research projects to undergrad frameworks to quick experimental coding.
... One important point that many people seem to ignore is that java seems to have huge number of freely available libraries, often for somewhat specialized subjects.
I don't particularly like java (and it's particularly painful watching the hoops people jump through to make it perform well), but while it doesn't seem to really be the best at anything, I guess on average it turns out pretty well -- it's pretty safe, pretty fast, pretty readable, pretty well supported, pretty widespread,
The languages you mention are all great languages, and have carved out productive niches, but they seem to remain niche languages, even in academia...
[Disclaimer: I have never written a java program (!), though I have read many...]
We live, as we dream -- alone....
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.
As a bit of anecdotal evidence, I offer up my university - UW Milwaukee. All required programming courses are C++. Electives exist for most of the languages you mention, but no student is required to learn any of them. From what I hear of people I have hired from UW Madison, that school is a Java shop - again, with electives for the more obscure language.
But then, of course, this is Wisconsin we are talking about. We tend to be practical up here, and have students learn stuff they will actually use in the industry. Learning the other stuff helps with the theory, since most of them have better models - but no significant real world usage.
Agreed.
There is also another little spoken of field of Computer Science called Systems. Many people claim that all systems research is dead, but there's really still much more to do. In systems they care ALOT about languages like C++. More recent experimental OS' like L4 are often implemented in C++ (often ignoring the bulk of the language features). PL people even are actually very interested in languages like C++. Yes they blelieve such languages are the bane of our very existant and the fact that any systems written using it work is nothing short of a miracle (a point I actually happen to agree with). But they also still have to look down occasionally at what is actually used and what does work, and figure out what bits of those systems are and aren't interesting.
Yet another huge point here is that when C++ was designed and written it really had one goal in mind, which was to bring the wonders of object orientedness to the unwashed masses of computer programming. At the time real code was written in C, Fortran, Pascal, Lisp, and Cobol primarilly. The more practical of these are very unstructured languages. C++ was an attempt to add structure to C, without breaking it's fundamental usefulness as a systems lanaguge. This was, in a very real sense, a research project. Someone invented a language and set it loose on the world to see if OOP could really hold it's own. Much to the anguish of many PL people it appears to have fluroushed in the jungles of industrial programing, but this was certainly an experiment.
Now as it happens I personally detest C++ (though I've certainly coded in it from time to time), but it's invention was most certainly well within the realm of computer science. Arguing that it's not is like arguing that Von Neumann wasn't a computer scientist because he was just an "systems guy" not a hard-core mathematician.
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.
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?
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.