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.'"
I wouldn't take programming advice from a guy who overloads the bit-shift operator to perform I/O.
Crack - Free with every butt and set of boobs
Now that is just ridiculous. I'm using IE7 to post this article, and have been using it since its release, and I can say
"...looking at "average" pieces of code can make me cry. The structure is appalling, and the programmers clearly didn't think deeply about correctness, algorithms, data structures, or maintainability."
Maybe it's because the average programmer is enslaved in company business. They don't have the
time to create masterpieces or art in programming. Instead of that they are forced to create
something adequate in a given time. Happens almost everytime, when science becomes business.
I don't like that, you don't like that, no one likes that, but that's the way commercial industries
are working (at the moment).
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.
The good thing about working in software-centric companies (besides understanding the programmer psyche) is that they often don't balk as much at being told something can't be done in a timeframe. Blizzard doesn't blink an eye when it has to delay a game by a year (probably more like 2 or 3 years when compared to internal, non-public set dates). Microsoft finally decided to nuke WinFS once they finally conceded that you're not going to get it within this decade, no matter how much they throw chairs. Google apparently has almost no schedules.
VB is a rapid prototyping environment. And just like an RP machine, it makes a flimsy product that you can send back to the drawing board without much expense. But you don't ship a product you've made on an RP machine -- it's crap. You take your prototype, and make a real product out of it using sturdy materials. Same goes for VB. You make something that works the way you expect, then you make it work in a real language. Good thing about VB is that you can replace pieces at a time with DLLs compiled from C++. If that isn't a part of the VB curriculum, it's a waste of time.
C++ is like a sharp scalpel. Yes you can hurt yourself if you're unskilled, inexperienced or sloppy
"C++ gives you enough rope to shoot yourself in the foot"
Java and C# are like those scissors with rounded ends for kids. Totally inefficent but safe for beginners.
I'm not convinced of the "totally inefficient" bit. I think you'd be pressing it to do time-critical systems (indeed, current GC is more or less incompatible with realtime systems), OSs, etc., but I'm not convinced that they're not just fine for applications. This especially applies to C#, because C# GUIs are actually responsive. (Swing and to a lesser extent SWT lag a little.)
But there's a reason why surgeons don't use plastic scissors.
There's also a reason carpenters don't use scalpels. It's because different tools are good for different jobs.
I've worked in project that was/is probably the most largets VB project in the world. It started in 93 and I don't think they are going to end it soon. I personally hate VB, it's not-so-strongly-typed variables, funny rounding rules and so on, but I wouldn't say that all you can do with it is crap!
The software we were making just works. It has worked for 13 years and keeps working. Maybe it could be little faster if written with some other language and tools or it might have more fancy UI blaablaablaa but it doesn't need those. And rewriting those hundreds of thousands lines of code... Let's just say that I wouldn't like to be in that team.
You don't know what you don't know.
I disagree. Programming isn't something you learn from someone else. Programming is something you learn by yourself. Of course, you can get excellent help/lectures/tips/advice/insights/whatnot at an university for example, but my point is that in the end you have to sit down and think and then write some code (and figure out why it doesn't work) by yourself. I would say it doesn't matter if you start with Visual Basic or Pascal; if you haven't got the ambition/derive/whatever to really sit down by yourself and figure things out, you will never be a (good) programmer.
Anyway... I think the problem may be that VB is too easy to use. People who would not be able to write the makefile for their 'Hello World' program in C++, are able to write working but very rickety/ flimsy VB programs.
I happen to make a living as a computer consultant. This means I get to see a lot of different organizations and their in-house software... This means a LOT of VB code... And of that VB code, a lot (maybe 90%) is written by people who may know their business but don't have a clue about programming. I can definitely see how that would create the reputation that VB programmers are bad, but not how it makes the LANGUAGE bad.
As for stability, I can promise you that some of my VB programs are a hell of a lot stabler than the memory-leaking SEGF/GPF-ing C++ hacks they replaced. In case you didn't know - it's perfectly possible to write shitty C++ code too. It's just that you have to get above a certain level to even get the compiler to work, so most of the would-be self-made computer wizards turn to something easier instead.. Like VB.
The big question here is: Is it better to have a flimsy but functioning VB program or a defunct makefile? I'm not sure of the answer myself. A defunct makefile is a 5-minute job to fix, whereas some of the VB messes I've seen would literally take years to get straightened out. (I hate people who think they can program just because their $h!+ compiles.)