Paul G. Allen wrote:
Christopher Smith wrote:
Paul G. Allen wrote:
Once a programmer has learned how to derive algorithms, decompose a problem, and all the other things Stewart mentioned, if he knows one complex language, he can learn another in a short time. It's basically a simple matter of learning a new syntax.
I think this is true for a certain class of programmers. I have, however, seen people who simply can't get their head out of the paradigm of a given language.
I actually should have made the distinction between software engineers and programmers. A programmer generally has a limited knowledge and possibly experience relating to programming languages and programming. A software engineer has gone beyond the simplicity of just writing programs in language A or B. A software engineer has learned the afore mentioned concepts, knows how to engineer a system, and has enough command over the concepts and programming to go beyond the paradigm of a given language.
...until you try to teach them ML and Haskell. :-P
Seriously, most of the people that you'd define as an "engineers" are used to a very specific structure to programming languages. They have a "favourite" language or two, and will program in that languages paradigm even when using a different languages. I know several guys who are better than I am at all the stuff you mention above, except when it comes to using a new language, they invariable try to make it work like their old language, and if the paradigm is sufficiently different, they just fail miserably (I believe someone made a comment about having stuck with C and Perl that kind of hinted at that, and I'm sure they're a great software engineer). Get a real hardcore C engineer who got tons of experience on everything from embedded systems to massive enterprise systems. Not just someone who wrote code for them, but actually designed the systems. Then try teaching them to program in Smalltalk. Sure, they're smart, so they'll be able to make code work, but about 50% of the time you'll find they never really get the zen of Smalltalk and their code still looks like C trying to pretend to be Smalltalk. Take that same guy and have them work on ML or Haskell and that number goes up to about 80%. You see it with even simpler steps than that. Take a guy who's worked with C, Java, and C++, but hasn't used C++ exceptions or templates before. Now try to teach them how to write C++ code with exceptions, and you'll get a 50-60% failure to grok the new paradigm (they'll basically use exceptions but treat them like return codes). Then try to get them to work with templates. About 90% of them will be able to use the STL just fine, but only about 10% will grok the functional programming nature of templates, be able to write new and useful template libraries, and be able to comprehend contents of "Modern C++ Design" even after a tutorial by the author.
My experience has been that they release after Sun, but maybe that's just been unfortunate timing on my part. I will say I've found that the "better and more reliably under Linux" doesn't seem to be quite so true these days. Ever since JDK 1.4 Sun has devoted a lot of resources to making the JDK work well on Linux, and I'd say it's starting to really pay off.
Sun's 1.4 does NOT work as well under Linux as IBMs, nor is it as complete. Nor did 1.3. I tried both, and in both cases IBMs worked better and was more complete. I have more than a couple applications that simply would not work using the Sun implementation due to missing classes, interfaces, or an entire portion of an API.
I don't know what from my statement would make you think I was suggest I was talking about JDK 1.4, let alone JDK 1.3. I'm saying they've really devoted a lot of resources *since* JDK 1.4, and that it's *starting* to pay off. Take a look at JDK 1.5.
--Chris
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
