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.'"
...at a university I know, they start teaching you programming in...Visual Basic. I can imagine the effect that has on the poor confused heads here who never eventually grasp other languages (including VB).
Maybe if they started with something like Pascal or something...but thats just not 'modern' or cutting edge nowadays...
I think this is the case in many institutions leading to low quality coders.
So he doesn't remember how he created C++ huh? That explains a ~lot~!
Agile Artisans
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
This is only my second favorite Stroustrup interview. The first is here: http://www.chunder.com/text/ididit.html (Yes, I know it's a hoax.)
FTFA: "My brief definition is, correct, maintainable, and adequately fast. Aesthetics matter, but first and foremost a language must be useful; it must allow real-world programmers to express real-world ideas succinctly and affordably."
Sounds like Lisp to me.... It's a mystery to me why anyone would voluntarily program in a language that makes the things that should be easy difficult, and makes things like segfaults, which should be pretty darn hard to do, easy enough to accomplish by accident. Yet so many people do it.
"...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.
Stroustrup developed much of the cfront C++ compiler, which itself was written in C++. It received widespread use on most UNIX platforms, and was the default C++ compiler on systems like HP-UX and SCO UnixWare. Numerous organizations licensed it, and some even offered ports to systems like DOS.
He was the head of AT&T Labs' Large-scale Programming Research department for a number of years. I'd imagine you're not familiar with some of the cutting-edge research he was responsible for when it comes to massive software systems. Had you actually been familiar with his achievements, you wouldn't have accused him of coming up "short in the real world department".
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.
To all those people saying C++ is too dangerous/prone to errors and Java/C## is the way ahead:
Stop blaming the tools and look to yourselves.
C++ is like a sharp scalpel. Yes you can hurt yourself if you're unskilled, inexperienced or sloppy.
Java and C# are like those scissors with rounded ends for kids. Totally inefficent but safe for beginners.
Unfortunately it seems that there are a lot of people out there who like to call themselves programmers but have no actual ability. Java/C## does a good job of removing their need to think and hiding their inate lack of skill which is why they prefer it.
But there's a reason why surgeons don't use plastic scissors. The same applies to good software engineers.
mine teaches java prediminantly, and I've had to tutor third year students who seem to lack more then rudimentary programming skills.
The logic they go by seems to be 'Download a class for it, no need to code it yourself'. It drives me crazy.
Well, one good reason to accept the possibility of segfaults is speed. C and C++ allow you to get down as close as you want to the underlying hardware, which (if the programmer is sufficiently skilled) can produce much faster code. Obviously this doesn't matter much in your average desktop software, but there are are any number of application types (3D games, simulations, animation/rendering systems, system libraries) where speed is still very much a concern.
Anyway, the typical unsophsticated (software development-wise) customer can't tell the difference between the two. This is made worse when many managers who were supposedly professional programmers themselves can't tell the difference. As far as I can tell, the only way for a programmer to deal with this is to simply BE great and be ready to move on if the customer can't see that greatness. Eventually they'll get somewhere that will appreciate it.
I also cover some of this in another reply.
The KISS principle is totally lost on that guy.
The moment you have 2 people doing C++ on 1 project, at least 1 person will be faced with code written using features they just don't understand. C++ has features to spare.
Think you know C++? No, you don't. Heck, the compiler developers are often unsure.
This is a recipe for disaster, as we often see.
C was hard enough. Few people truly understood all the dark corners. (sequence points, aliasing rules, etc.)
C++ is addictive. Everybody wants one cool feature. C code is somewhat easy to convert. Soon you're using enough of C++ that you can't go back, and hey, more is better right? The next thing you know, some programmer on your team got the wise-ass idea to use Boost lambda functions (for no good reason) and you find yourself with 14 different string classes and... you have a mess that no one single developer can fully deal with.
Of course surgeons don't use plastic scissors. But how often do you need a surgeon? Most of the time you need a cheap tailor to make you a suit. And that's when scissors come in handy.
C++ can do wonders when used by highly experienced people. But most of the time, it is more cost effective to get entry level coders and use PHP/Java/C#/whatever. You will get a (somewhat) working product cheaper and possibly faster. And time to market and cost is often more important than maintainability/quality.
And don't get me started on 3rd party C++ libraries. You'll need tons of them to move a finger, and you'll spend more time finding/eavluating libraries than coding. This problem is getting worse for other languages too...
--Coder
The problem with C++ is Stroustrup. Specifically, it's that, as what's now called "C++0x", the next revision, got underway, Strostrup insisted that C++ had no major problems - it just needed some cleanup. This was after a decade of trouble with buffer overflows and related safety issues.
C++ is unique in that it has hiding without safety. No other major language is in that space. C has neither hiding nor safety; Java has hiding with safety, as do almost all languages which postdate C++. This is not fundamental to a compiled language; Modula 2 and 3, and Ada, had hiding with safety. Nor is it related to garbage collection, inherent problems of an efficient, compiled language, or the needs of systems programming. Providing backwards compatibility with C while bolting objects onto the language led to safety issues that were never overcome.
Most of the problems with C stem from the "pointer equals array" model, the basic source of buffer overflow bugs. C doesn't even have a way to talk about the size of array arguments (well, C99 does). Dangling pointers are also a problem but a secondary one. C++ tries to paper this problem over with collections, but far too often, collections have to expose a C pointer to get something done. At that point, size information is lost. Right there is the biggest single problem with C and C++.
The C++ revision committee is dominated by people who want to do l33t things with templates, things nobody will ever do in production code but, they think, are really cool. There's a whole "generic programming" cult of abusing the template mechanism to do computation at compile time. Millions of users suffer from unnecessary program crashes, and the US is more vulnerable to malware and cyber-terrorism because of this focus. It's as if the IEEE committee on power transmission standards was dominated by people who were into making big sparks.
Stroustrup could have insisted on actually fixing the safety problems. But he didn't.
(I'm writing this as someone with over ten years of experience in C++, doing everything from protocol stacks to game physics engines to real-time programming. And after ten years, I'm fed up with the mess. This should have been fixed years ago.)
The problem with programming is that too many people that lack the talent are in the programming business. I know because I work with many of them. They are not detail oriented, they don't think strategically, long term, etc and just make a mess of code. They only want to fix the problem they need to fix without worrying about the effect it will have on the system, etc. This is what causes bad programs. Programming is easy enough that any moron can make something work, but to make something continue to work requires an engineering understanding, and this is something most people don't have. It's unfortunate.
Ok, then please explain why Open Source projects are full of flaws just like commercial products. Are all the geniuses exclusively employed by companies that stifle greatness and everyone else is doing Open Source? Please. Programming greatness is rarely achieved... anywhere. The problem developing for profit is that you need a product to profit from. That means you have to ship something that is imperfect just to stay in business and make a living. The problem developing on your own for free is, again, that you need to make a living and really don't have the kind of time to produce greatness (assuming your are capable). Either way, it comes down to resources. One can rarely get enough outside of work and one can rarely get enough AT work. Same problem. Business drives development just as much as it stifles it.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
No benchmark is ever going to be a definitive measure, the best they can ever do is give you an idea or the general qualitative differences. I think you'll find, however, if you were to actually try Ada, Eiffel, D, or OCaml for an entire application, that they do, in fact, compare very well with C++ - it's not like there aren't any significant large applications written in those languages (well, possibly not D): they get plenty of use in various industries and are well known for their efficiency.
Craft Beer Programming T-shirts
Many of the points in the interview implied that software was simply soaking up all the hardware performance, and perhaps we could squeeze more out of the software. I completely agree, except ...
s /NoSilverBullet.html
http://www-inst.eecs.berkeley.edu/~maratb/reading
The problem is that the software is an order of magnitude slower than it needs to be because the hardware has increased in performance by 2 and 3 and 4 orders of magnitude. If we had held the software to the same standards as we used to back when the hardware cost more than the programmers, it would be more efficient - but would only be able to make use of a couple megabyte of RAM and disk. The looseness of current software is part and parcel of harnessing the hardware. The hardware didn't just allow us go loose with the software we wrote - it allowed us to use abstractions which were measurably less efficient, but which had the side effect of allowing us to harness the hardware in the first place.
As a pair of trivial examples, take arrays and dictionaries. When I ask interview questions like "Design a hashtable" or "Reverse a linked list", many candidates have to actually step back and think about the question! 30 years ago, designing a good hashing function was the mark of true talent, and gains were to be had by selecting the linked-list scheme which best suited the problem at hand. These days, many people don't really know why you'd use a map versus a hash_map, or a vector versus a deque. And, for the most part, they don't really need to.
Which means you learn nothing other than a new syntax to program your same old style in (i.e, nothing worthwhile). Not to mention that Dylan's macro system will leave you crying because computational macro systems in a syntax heavy environment just suck. If you're really short of time, you're better off using it to learn Erlang, Prolog, or Smalltalk. With the first two, you'll learn new ways to think about programming; with the second, you'll at least get better tools and have more fun. Either is more useful than Dylan.
That is all.
You want Lisp. Hear me out.
Of course, the character syntax is superficially different. Operators use infix notation ("(+ 1 2)" is analogous to "1 + 2"), and have identical character syntax as function calls ("+", an operator in Lisp jargon, may be implemented as a function).
If you can sleep at night after that, your can define own higher-level language syntax that looks exactly like any other Lisp syntax. Lisp is extremely flexible in its naming of functions and variables (symbols). If you'd like, you could define an operator named .= as a function: (.= string new-character-strings ...) would modify the given string object, string , in-place, appending each specified new-character-string to the end.
Recognizing the downside to modifying random strings in-place, perhaps you'd rather have your .= operator assign a newly-instantiated string to the variable referenced by string . You could, by writing the operator as a macro. The macro would act like a function, taking as input each "raw" argument—symbols and lists, the structure as they appear in your program, before evaluation—and returning as output replacement Lisp code to evaluate in its place. So that your .= operator form of (.= out "lalala") is semantically equivalent to (setf out (concatenate 'string out "lalala")) (like out = out . "lalala"; in other languages).
It's not just simple textual substitution. You can use any function or macro in your macro definition to transform your input arguments into whatever replacement code you'd like. I'm using macros in Common Lisp to generate recursive-descent parsers based on a grammar production expression: the following form defines a function named obs-text that takes a string as input and returns a list of matches found as output:
(defproduction obs-text :* CR :* (obs-char LF :* CR :*) :*))
(LF
This function is defined in place and evaluated and compiled immediately by the Common Lisp implementation.
Macros can be abused, but they add a tremendously powerful capability of abstraction not possible with many other languages.
yes, for Rapid Application Development. However that is *not* the point of studying computer programming.
While a good coder knows when to re-use code. A coder incapable of originating complex code is little more then an automaton.
I'm sick of the 'don't re-invent the wheel' argument being dragged out and used to justify people not studying properly, or for that matter, not teaching properly. I was lucky, I attended a course where most lecturers believed that students should code their own assignments.
Examples being recursive functions, sorting functions, Dijkstra's shortest path algorithm, stuff like that. However I have recently had to cope with people being given exactly the same type of assignment, and being allowed to download pre-built classes for them! What, I ask you, is the point of that?
>> C++ defines container classes which cannot overflow.
>> Try using them next time you write some C++ code.
>
> No, the STL defines container classes, and they suck
> just as badly as the C++ language itself. Performance
> goes out he window unless you spend inordinate amounts
> of time ensuring that all the classes you put into the
> containers are setup to avoid multiple copying. This is
> a major pain in the arse, as different implementations
> of the STL have different semantics, and "accepted best
> practice" is to not to hold a copy rather than a
> reference to an object in a container
On the contrary -- the GP is quite correct. First, the STL ist not called the STL anymore for ages. It is part of the C++ standard library. And that's what it is -- a STANDARD. Compilers that do not follow the semantics described IN the standard are plainly broken and should only be used with care, if at all. But this is always a problem with languages that are implemented by a lot of people. Java for example is simple, because there are only vert few implementations in existance, and most probably 95% of the people using Java uses the one done by SUN. I think only very few use gcj for example.
Also the STL is not that complex as you think and it really is efficient, if used correctly. But that is the case for any library and any tool. Furthermore one can always put pointers to objects in a container, which is the same as using a reference. And if you want to have some safety there, use a smartpointer -- there is nothing complicated about that. The discussion here really shows that C++ is indeed a COMPLEX language and that indeed it is NOT UNDERSTOOD by many of us here. But I think those who have worked with it for some years and REALLY UNDERSTOOD some of the more complex topics of it, will admit that C++ is a powerful, efficient and elegant language. There is no all-purpose language that is ALWAYS simple, efficient and elegant. This just can't happen. But C++ fits a lot of purposes well. For example for many occasions I write small python programs when I need to do some parsing, conversion or small calculations. That's totally great! But I also use C++ for larger programs, because it offers a vast amount of libraries and ideas. Not having to implement my own partition, sort, find or vector every time is really helpful. And those algorithms even run very fast on all my self-created types.
[--- PGP key and more on http://www.root42.de ---]
Paper and pen? Luxury. When I were lad, we had to use papyrus and lump o' charcoal, and compilin' were done by chisellin' machine code int' stone tablet.
Java for example is simple, because there are only vert few implementations in existance
The reason Java is simple is that it didn't try to be a multi-paradigm language, where the inevitable trade offs left C++ inadequate in every paradigm. Java was also well described in a decent specification rather than being standardised too late in the day as happened with C++. There also exists a canonical Java test suite, whereas the C++ standard is littered with opportunities for implementation specific functionality, especially in the STL.
Also the STL is not that complex as you think and it really is efficient, if used correctly.
I can write efficient code for Sun's implementation of the STL that will generate multiple calls to the copy constructor in GNU STL when adding an object to a container. Neither STL version violates semantics as described in Stoustrup's book, it's just one of a vast number of implementation specific features that are allowed in an STL implementation.
There is no all-purpose language that is ALWAYS simple, efficient and elegant.
No, but I struggle to think of a single instance where I have encountered C++ code that proved to be simpler, more maintainable or more efficient than the equivalent written in C, Perl or Java. Of the three large C++ based projects that I have become involved with, two were scrapped and replaced with a mix of C and Java. The third is still proving to be a hindrance to those trying to maintain and extend it, so much so that a parallel system is evolving, largely written in Perl.
A good reason to use some older language like Pascal or FORTRAN would be to avoid the pre-built classes problem.
"The difference between stupidity and genius is that genius has its limits." -- Albert Einstein
I think that students should start with C, move to pascal, then onto perl/python/lisp, and after that C++, or perhaps java (even though I hate that language, and I've had to teach it, so I'm not blindly critical). A smattering of php wouldn't be bad.
nice.
I don't object to java being taught, just the use of premade code to replace having to do stuff yourself.
Do ensure you widen your skillset well beyond java though, single language knowledge is a bad idea. Knowing several and specialising in one is better, since you can move to different languages as the need arises with ease.
Hmm...
:) Not sure where you'd want to throw in a scripting language; or if it's even really neccessary... what skill do you learn from learning a scripting language other than the language itself?
I'd say pascal first as an introductory programming course, then C, then some assembly, then finally C++ or Java.
It's a lot easier to learn sequential programming when you're not busy shooting yourself in the foot... let them hit C after they know what a conditional and a loop are
Maybe in usage, but that doesn't lend itself well to learning. Learning, by definition, is the process of reinventing the wheel so that you understand how the wheel works. They don't teach algebra by presenting the quadratic formula and saying, "Here, use this when solving a polynomial of degree 2" - they lead you every step of the way through the development of the quadratic formula so that you know how it works and why it works. Likewise, programmers learning to program should be writing quicksort implementations rather than ignoring the details because "it's already implemented in a library".
Of course, once you've graduated and are a professional writing a program for somebody else to use, you should reuse what's available as much as possible.
Proud neuron in the Slashdot hivemind since 2002.
That's interesting. I learned Pascal first and then C. The reason I found this helpful was the Pascal was more controlled (I can't remember all of the correct words anymore). C allows all kinds of memory allocations, redefined pointers and such which are brutal on a beginning programmer. Pascal prevents a lot of those mistakes, therefore giving you a chance to learn some concepts without too much disaster. As for perl/python/lisp. I think lisp is great for showing another way/paradigm of programming. Perl/python/ruby allow you to merge everything together. Of course Smalltalk/Squeak would be great for bringing home object oriented programming. After that PHP, JSP, ASP, whatever is just suited to the environment you're working in. Reality is that you'll probably never get that many programming languages into a B.S.
"The difference between stupidity and genius is that genius has its limits." -- Albert Einstein
That's a good question. The purpose of a programming language is much the same of that of mathematical notation, which is to allow you to think at the level of abstraction of your problem while not wasting time with irrelevant details. Modern calculus notation gives university freshmen the ability to solve problems in a few hours that baffled the greatest minds of history for thousands of years.
Note that this doesn't mean that you don't have to think when learning a mathematical language. The concepts of limit, derivative, and integral are difficult to grasp at first, but once you understand them, they offer powerful mathematical methods that allow you to think about the problem at hand and not the notation you're using.
Can computer science make similar claims? The jump from assembly to FORTRAN was a tremendous improvement in productivity, but FORTRAN to C or C to C++ produced small to no productivity improvements, perhaps in part because you have to think more and more about the language. We should be looking for a language that may require thinking to learn, but that once when learned offers powerful methods at a high level of abstraction that allow you to think about the problem without being distracted by the language.
I would suggest that we look at languages like Haskell, Scheme, or Smalltalk, which do require that we learn concepts like currying, higher-order functions, monads, and type classes, but which offer a higher level of abstraction and greater consistency than languages like C++ or Java.
Not enough is made of the sheer obfuscatory nature of C++. C was already somewhat cryptic, but at least it was small. C++ is cryptic and large, and that's really a bad combination. At one point in the interview Stroustrup recounts that half the programmers he polled who said they disliked C++ then admitted they had never programmed an application using C++. He calls that prejudice. I call it perfectly normal human behavior; if you begin to study a language and quickly discover it to be a load of tailings, then you will be disinclined to program applications using it.
That was my experience anyhow. I began studying C++, and at some point I stopped and asked myself, "Why must I endure this? Surely there must be better options." And I was right.
I really have to grit my teeth when Stroustrup talks about C++ "winning" against competing languages. C++ is successful for the same reason that COBOL and Microsoft Windows have been successful: because they happened to appear in the right place at the right time, and were promoted by the right people, to become entrenched. Once entrenched, the world was saddled with them for decades to come. It has nothing to do with their inherent qualities or advantages, it's little more than random chance.
"Coding it? Why? Only to prove to yourself that you can do it! I did it when I was younger. "
No No no no no!
To learn it in the first place! Weren't you paying attention? You even demonstrated my point by saying 'I did it when I was younger'.
Yes, you did, so did I, would I re-write something when someone had a better implementation than me? Perhaps, if I wanted to learn how to do it, but not if I needed it soon, or had reasonable assurance that the existing implementation was better then I could do myself. However I have yet to move into a new area of coding without getting my feet wet by implementing some of the code used in that domain myself, just to know what I was talking about.
What's more use, a programmer who has learned about a thing, then produced on his own an implementation of same, however basic, or one who studied it just to pass an exam and never built it in the real world?
C++ vectors *can* be used safely, but the library designers used traditional, easy-to-read syntax for unsafe access and verbose, hard-to-read syntax for safe access. They clearly meant for unsafe access to be the norm and safe access to be used in special cases. I'm a C++ fan, but in this case they screwed up badly.
it's not-so-strongly-typed variables, funny rounding rules and so on
I know they're like [pagan] Gods to an awful lotta people in the CS community, but The Founders of The Art, guys like Kernighan, and Ritchie, who had the chance to insist that a declaration actually mean something, but hesitated, and hemmed and hawed, and got all wishy-washy, and finally decided [really deferred a decision until it was too late to make a decision] that a declaration could mean any-damned*-thing that the implementor wanted to interpret it to mean, well those guys, those pagan Gods of the Founding Arts, seriously - someone should take them out behind the toolshed and whip their asses** [if not shoot them outright].
So now, fast forward 30 or 40 years, and we've got:
And then you go to do something in VB, or in Javascript, and you get shit** like
or, what's even worse,
and you end up having to write shit**** like
and you scream at your computer, "YES, THESE ARE NUMBERS, NOT CHARACTER STRINGS, YOU GOD-DAMNED***** COMPILER/INTERPRETER/SYNTAX/PARADIGM/NIGHTMARE OF A SACK OF SHIT******!!!!!"
PS: There is a special circle in Hell******* for the sonuva bitch******** who dreamed up the idea of interpreting variable types on the fly...
*Pardon my French.
**Pardon my French a second time.
***Pardon my French a third time.
****Pardon my French a fourth time.
*****Pardon my French a fifth time.
******Pardon my French a sixth time.
*******Pardon my French a seventh time.
********Pardon my French a final time.
From the article:
How often have you worked on a prototype or demo, only to have the time/expense budget slashed because management decided you must be almost finished when they see a demo GUI?
How often have you encountered copy-paste-edit code replicated throughout a system because no one had the time to refactor the replicated code into a reusable module?
When did you last have the time and budget to clean up that rushed prototype via refactoring before the next phase was in crunch mode?
How often were you told you can't refactor code because it's already been tested and put into production?
How many "silver bullet" tools have you tried over the decades, only to find that they're marketing hype and often increase the total workload instead of saving time? (e.g. Now you have to maintain UML models as well as the code and database schemas.)
As long as the "push" is to get it done faster regardless of long-term costs, crap code will continue to churn.
I do not fail; I succeed at finding out what does not work.
And we were thankful! Also, we had to walk through 6 feet of snow to the programming "chisel lab" and it was uphill both ways.
Me too, though this was purely coincidental because where I went Pascal was not a pre-req for C. But when I finally got to my C course, which by the end of the year had a dropout rate of 50%, it was relatively smooth sailing. I already knew how to program from my Pascal course, and heck, even the syntax was close enough. This is from someone who took CS courses just as a curiosity, I actually wanted to be an electrical engineer. I say that to make the point that I had no prior programming experience, and yet after just one semester of Pascal, I was ready for C. Pascal is the perfect primer for C; I dare anyone to name a better language for that purpose.
blah blah blah
I think they should learn computer languages in the order that they evolved: assembler first, then FORTRAN, then Pascal (as the ALGOL representative), then C, then Smalltalk. Maybe throw Lisp in there between FORTRAN and Pascal (even though I believe it's older than FORTRAN). Actually, C is kind of a step backwards from Pascal (limited scoping and no built-in I/O), maybe just tack that on to the last couple of weeks of assembler.
And let's not forget that students should really be studying computer science, not programming. They shouldn't learn how to do a binary search, they should learn why it's such a powerful technique. The implementation falls out naturally from the description. Likewise for trees of various flavors. Teach them how to identify the language features that best support the algorithms they need, and let them figure out which language is most appropriate for themselves. After all, any language they learn in college will be out of favor by midpoint in their career anyway (or earlier, for those of us that learned Pascal...), so better to teach them how to learn a new one from the start.
Just junk food for thought...
Why have pascal in there at all? Let it die just let it die.
Lisp should definitely be in there. Heck, start all the students on Common Lisp and we won't have everyone thinking all languages need to look like Algol.
starting them out at assembler is jumping the gun. surely they should learn to use an abacus and a slide rule before moving on to Babbage's mechanical computer and then assembler programming on punch cards
I hold the exact opposite opinion.
I believe effective learning should be done in a top-down manner, whereby students start from putting building block together, gradually drill down to understanding how the blocks themselves work. This view is echoed in the classic C++ textbook "Accelerated C++".
Real-world programming requires good exposure to design patterns and programming idioms, and effective use of canned routines. As such, colleges should focus on this skillset in order to equip people for the industry. This is exactly the same reason why nowadays colleges no longer teach hardcore assembly techniques like those used in Knuth. It is absurd that colleges these days still make linked list writing mandatory, and design pattern course an elective.
I myself am a real-time system engineer and back a couple years I taught operating system and computer architecture at Hong Kong Univ of Sci and Tech, I have always been of the opinion that the industry does not need a lot of OS gurus. These hardcore stuff is best be left to the graduated and professionals, who choose to develop in these niche areas.
While you can bash the tools as much as you want, the point remains that the majority of the fault for bad programs lies with the programmer.
.S files created by your compiler? Do you even know what they are? Could you load an object file into a disassembler?
Just as an adept sculptor can build a beautiful (though somewhat rough) art piece using a chainsaw, so can a good programmer make do in situations where he is forced to use the wrong tool for the job.
Namespaces can be simulated with a good naming convention.
OO can be accomplished in a procedural language.
Technologies can be married together, and even replaced in part with other technologies at a later date (it's called refactoring, folks!)
I currently program exclusively in Java. I learned from the ground up (Analog electronics -> Digital logic -> Machine code & Assembly -> C -> C++ -> other OO languages & scripting languages, AOP etc)
I'd love to have multiple inheritance in Java, but I hate the fact that you can't rebind a reference in C++.
I'd love to have real properties and closures supported by the Java language proper, but I make do with standardized boilerplate code in the meantime.
I love the quick UI building you can do in VB, but I certainly wouldn't want to write business logic with it!
Access is great for building quick and simple systems, and does its job well, but I'm not going to store 10 million records in it!
Nothing beats the speed of a library written in assembler, but I'm certainly not going to write database access code in it!
Perl is a great tool in the right hands. In the wrong hands, it is the worst disaster ever, and the first thing I get rid of when I take over support of a project (except for 10% of the time when the previous programmer was competent).
I've seen horrendous code in every language I've ever encountered, and it's always a result of the programmer not understanding what he's working with. My personal opinion is that you shouldn't be programming unless you understand at least one layer below where you're working.
Do you know how to examine a core dump? How about interpreting a Java HotSpot dump?
Do you understand how the technology you're working with interacts with the operating system?
Do you know how the auto-code generator deep within the script overlay you're using actually works? Have you even once looked at the intermediate output?
How about the
What will you do when something goes wrong with it? Give up?
Do you follow the generally accepted practices used in your domain? Do you even know what they are?
Do you know what domain driven design is?
Do you understand when it's a bad idea to use inheritance? (Answer: most of the time)
I could go on forever. The point is that good programmers find the right tool for the job because they understand how it all works. Hackers do it fast, but forget to make it readable or maintainable. Bad programmers just plain do a bad job and make things shitty for everyone.
It's not about languages, it's about people. Sure, C will make you track bits and bytes and jiggle with pointers. Everyone should try that and deal with mysterious crashes, etc. And one day switch to Java and track indices in arrays and null pointers and hash codes. But at the end of the day, it's all about people, not languages. If the people are smart, and if they love the field, they will advance no matter what they're taught at school. Very few are those go that far as to learn every new language, and one day reach the level when they just don't care about the tools they use, and cat get any job done with any language at hand.
So, it's about people. We all make errors, we all over-enginner or under-engineer, we all write too complex code because of design errors. We all learn and advance. And not all of us make the best of choices.
So what? This is not just with programming though. Just programming is the most complex task humans do.
For those of us working in the "gutters" - embedded systems stuffed into the sometimes gludgy real world - only a language like C++ will do. A polished user-level GUI app running atop layer after layer of abstraction can be written in something slick and aloof like Java, Lisp, or some nifty obscure language. ...but for those of us writing specialized critical apps running on minimal hardware and dealing directly with the real world, we need something that has only the thinnest layer of abstraction, is comprehensible and predictable, and will reliably affect reality.
Sneer at "gutter"s as you like. Your house/apartment has them, your business/school has them, you don't notice them when they work, but they are quietly everpresent and designed by someone who had to think about them and use specialized tools to make them - and life would be less pleasant without them. Ditto for lots of C++ apps. You don't really expect a Java VM running on your toaster, do you?
Can we get a "-1 Wrong" moderation option?