Bjarne Stroustrup On Educating Software Developers 538
jammag writes "Bjarne Stroustrup, creator of C++ and a professor at Texas A&M, weighs in on the problems in today's CS programs. In particular, Java (there's too much of it), the quality of graduates (companies aren't happy), and the need to balance the theoretical and the practical (long overdue). Not pulling punches, Stroustrup even talks about high schools — 'High schools could teach students to work hard at something (just about anything), to search out information as needed, and learn to express their ideas in writing and orally.' He finishes by giving advice to working developers: 'Serious programming is a team sport, brush up on your social skills. The sloppy fat geek computer genius semi-buried in a pile of pizza boxes and cola cans is a mythical creature, best buried deep, never to be seen again.'" Read on for more choice quotes from the quotable professor.
I have even had questions from strangers in airplanes: "You're a professor? In software? Have you got any students? Here's my card."
The US industry could absorb more good developers than there are currently students enrolled in IT-related programs — but not all of those programs and all of those students would qualify as "good" in this context.
The companies are complaining because they are hurting. They can't produce quality products as cheaply, as reliably, and as quickly as they would like. They correctly see a shortage of good developers as a part of the problem. What they generally don't see is that inserting a good developer into a culture designed to constrain semi-skilled programmers from doing harm is pointless because the rules/culture will constrain the new developer from doing anything significantly new and better.
The contemporary Math, Physics, and Biology books I have seen are far, far more conceptually challenging than what we present to CS and engineering students in the area of programming.
I think the ultimate aim is to make programming more of an engineering discipline, more mathematical or scientific; "craft" and "art" are both needed, but there ought to be a scientifically based core on which people can base their craft and art. Software design and implementation is more than a craft; there is more math, science, and engineering to know and apply than is customary for fields we call "crafts." Incidentally, I find it appalling that you can become a programmer with less training than it takes to become a plumber.
A direct link... (Score:5, Informative)
..is here [earthweb.com].
Re:too much Java ... (Score:1, Informative)
I actually quite like C++ when using the Boost library for fancy algorithms and wxWidgets for GUI support. At least, I find myself doing the same level of algorithm contemplation and such when I'm programming in C++ as I do in Java, and seem to accomplish similar programming tasks in similar amounts of time in either language.
Also, what language is best for designing videogames these days? :)
Re:Good point (Score:3, Informative)
Then go out and look at bridges. If you think that they are bug free, you are very much mistaken. There are flaws in virtually all physical construction that would never be tolerated in software design. The difference is that construction has found ways to hide many of their gross flaws, and the population has just gotten used to seeing them. Basically bugs in bridges don't get called out unless someone gets killed. If we used the same criteria for software, then most software is bug free.
Re:Good point (Score:1, Informative)
Heh sounds like someone else got a good read out of Dijkstra's essay [utexas.edu] as well.
Nice analogy for pointing out that one shouldnt be making analogies between material engineering and computing!
Re:Good point (Score:3, Informative)
There are flaws in virtually all physical construction that would never be tolerated in software design.
For instance, the one that collapsed a few years ago and made national news. It turns out that they never specced a particular load-bearing part properly and ended up using one half as thick as they needed. It lasted 40 years before failing, and there wasn't anything in standard test procedures to spot it.
Re:Better English education as well. (Score:3, Informative)
/gollum Quoteses is also a plural noun. We're sure hobbitses meant to say, "Rrread... ON! for more choice quoteses... fromtheprofessor. My precious."
I told you they were tricksy. I told you they were false.
Re:The companies not happy with grads is pure BS. (Score:3, Informative)
Very technically, a byte can be four bits, it's an octet that specifies 8. Bytes have been defined as 7 bits on some architectures. But still, if you have to give a single straight answer, 8 is much better than 4.
Re:Hypocrit (Score:1, Informative)
Re:On High Schools doing more... (Score:2, Informative)
TRS-80's had built in basic that anyone who could type could code and manuals so anyone who could read could learn. Cell phones don't have those, and there's a real struggle to find those types of tools today.
Re:I also hate bad programmers (Score:1, Informative)
Something else was wrong because the qualifications you describe sound idea for the entry level programmers hired at my company.
Re:Dreaming... (Score:1, Informative)
Let me see if I understand this. Your sample of 1 finds that reliability is more important than features.
Hmm... Probably not enough to make the quarterly, or even hourly sales quotas.
Next!
Re:I also hate bad programmers (Score:2, Informative)
Agreed. Odds are the GP probably has poor job search, interview, or people skills; then again, the GP could also be one of those self-taught programmers who think they're much better than they are. Having written lots of code is not on its own a guarantee that you have good software skills.
Re:Mythical Creature... (Score:3, Informative)
Actually it's never needed, unless you meant multiple inheritance from interfaces.
Interface inheritance is your friend.
Suggestions for job searching... (Score:3, Informative)
On your resume, try to highlight your significant personal projects and why you think they are cool. Your resume scores you interviews. And on your interview, I don't think impressing your interviewer is the goal, but you do need to show you're up to what you claim to be on the resume. Your personal projects can become an advantageous conversation piece during the interview. Try to have a good time with the interviewers because they may be having a long day as well.
Re:Mythical Creature... (Score:3, Informative)
More rubbish I am afraid!
If the compiler/runtime writers can implement highly complicated features that exist in things like hotspot I am damn sure they can implement multiple inheritance! The problem is that there are too many ambiguous cases that can be introduced by using multiple inheritance.
The reason that Java provides both interface implementation (and inheritance between interfaces themselves, including multiple inheritance (which does not have the problems found with multiple implementation inheritance)) is because they are used for two different things. One is used to express common, generic functionality, the other is used to specialize on implementation details. A very short browse through the Java API docs will demonstrate many cases where interface implementation and concrete inheritance are used to great effect.
For me the jury is out on whether I would find MI useful in Java, but you are probably right about operator overloading. As a lone, and fairly experienced Java programmer I would probably find some sensible uses for operator overloading. I am also certain I would sit through more than one deeplying annoying conversation with a junior developer who is trying to explain to me why adding two 'Customer' instances together makes some kind of sense (or worse, dividing them!). Personally, I tend to feel it is not worth the aggro. Mileage may vary.