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.
The compiler generates different but identically names instances of doprint() in each of the two modules (notice the difference in the definition of struct A). The linker then arbitrarily picks an instance and throws out the other.
The net result is that one of the calls to doprint() ends up using a template instantiation for an incompatible datatype and prints out the wrong things.
With GNU ld, the linker's selection of the instance is determined by the order of parameters on the command line, so you can get different behaviors by switching the parameters around.
I spent a week tracking this down during my dissertation work. It was buried in a 4000 line (not including libraries) numerical analysis code. The offending template definition was buried in a macro expansion defined in an external library.
Needless to say, I've avoided C++ since then. Too many gotchas and subtle behaviors, weirdnesses with virtual methods, etc. Not to mention the const/non-const combinatorial explosion and the other hassles resulting from strong typing.
These days I usually end up using C, Matlab/Octave, or Python depending on the problem. The new Numpy is very very good for numeric computation.
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.
It would be silly to fault someone for not having 20/20 foresight, so I can hardly blame BS for not including things that we know now to be good, but not necessarily then. One example would be pass by value, which at the time seemed like the safest default for parameter passing (the thinking was probably to avoid unintentional side effects). Extending this to objects though causes pains involving copy constructors and other esoteric stuff. Java decided on always pass by reference, and from my experience, unintentioned side effects almost never come up (the fact that the 'native objects' were immutable might have helped).
Yet to read these articles, it's almost like he still thinks that C++ is the top language, and anyone who's not using it is just a poorer programmer who can't handle the power. When I hear him reply with stuff about Java's success coming from 'massive corporate backing' it just sounds like tired whining. C++ did fill an important role, it introduced a lot of people to OO by piggy backing on a very popular language. It also allowed for OO programming on a lot slower hardware. But the cost was it wasn't much of an abstraction. I think it can be put to rest for the majority of projects. There's still some areas where it will shine for quite awhile (graphics maybe) but those are the minority.
I actually code in AOP everyday at work - and couldn't imagine life without it. Sure, it is a bit difficult, but then you start to understand and appreciate its beauty. It is perfect for my job, Hardware Verification.
The language I use is 'e'. Take a gander at http://www.ieee1647.org/ if you are interested.
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.