Paul G. Allen wrote:
Software engineers *need* to know a variety of languages. They need to
know assembly and for embedded systems, they need to know it well. For
embedded systems, they need to have an excellent knowledge of the
hardware architecture and not just assembly for the platform the
system uses.
That's just someone in a lead role, and that's certainly not a role one
need to be ready to perform right out of school (indeed, for most
people, this would be terribly unwise). Whatever you learn in school,
said knowledge needs to be tempered by the reality of working world
before you're in a good position to make these kinds of decisions no
matter how many languages you know.
I've said many times that I think engineers should learn assembly
first, followed by higher level languages (I learned BASIC and
I would argue that learning assembly first focuses too much effort in
the wrong area to start with. Sooner or later one needs to develop an
understanding of the internals of a computer system, but it need not be
the first stepping stone.
assembly first, and after assembly all others came fairly easy).
Yeah, I hear that one all the time ("after X all others came fairly
easy"). I've heard it for assembly, Scheme, LISP, CLOS, Ada, Modula-3
(yeah, I couldn't believe it either), C, C++, Eiffel.... You tend not to
hear about it with scripting languages, because they are designed to be
easy to pick up and use. There's an old expression that I remember from
when I was first learning programming: "The first ten languages are the
hardest". It's a joke of course, but there is a kernel of truth to it.
As you learn each new language, particularly if it is a very unique
paradigm, learning subsequent languages becomes much easier. Sometimes,
one language does become foundational for your understanding subsequent
languages, but my own opinion is that has more to do with the affinity
of the programmer for said language than anything else (and can often
indicate a lack of flexibility in understanding other languages).
Java should be learned as a first step to learning OO concepts,
Ugh... but it teaches sooo many bad habits.
I have found in more recent years that "Software Engineers" coming out
of school really don't know squat as compared to the "old school"
engineers who learned Pascal, assembly, etc. the way CS programs used
to be taught. As a result the quality of software systems these days
suffers greatly resulting in "Beta" software that can really only be
considered early alpha.
So, I started out with some mix of BASIC, PASCAL, FORTRAN, LOGO and C,
and from there it went to a lot of other places. I didn't actually learn
any assembler until much later, and in all fairness never really
developed much of a fondness for it. In general, I'm not a hardware guy,
but of course I did educate myself in how computer systems work
(importantly, little of this was learned in school), so it's not like
I'm totally ignorant, and I have coded device drivers when necessary.
It's just not anything resembling a strength of mine. It turns out
though, that there are plenty of projects where such work isn't at all
part of the job, and a good understanding of systems is sufficient.
There are certainly is work that requires a solid foundation in assembly
programming, but there is *plenty* of work that doesn't, and a shortage
of talent (and even a shortage of the "talentless" VB/C# folks for that
matter). I feel pretty confident that market forces will do a pretty
good job of making sure people learn the right skills (indeed, part of
the reason for the "decline" of the talent pool is that there is a lot
more work out there these days that doesn't require much talent in the
first place... that plus the supply/demand curve being somewhat one
sided will produce fairly predictable results no matter what the
structure of one's curriculum).
--Chris
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
