> Robert I. Eachus wrote:
> > But can someone who has never
> > written a significant program in assembler--or even machine
> > language--qualify as a good software engineer?
> Sure. I don't think one has to dig a ditch by hand to be a civil
> engineer nor drive a hot rivet with a hand sledge to qualify as a
> structural engineer. Requiring one to have used early, primitive
> software implementation tools in order to be a software engineer would
> be just as ludicrous as the above examples, IMO.
I think that Robert's *Point* is that one needs to have done the
activities to understand them. I will agree with Matt that his
civil engineering analogy is good. After all, we have equations
the describe how cohesive materials are, so we "know" (well, most
of the time, there are still ditches that collapse while being
worked) how to dig ditches.
However, if you have never built an overlaid program, of any size
(I built a 1.2MB compiler in 1960 that ran in 88K and compiled
programs of size 20,000 symbols in 128k [ PL/S II for IBM OS/360])
I think that it is highly unlikely that you can design programs with
good performance characteristics when memory is short [and it
always seems to be]. The memory-hog programs on today's PC's are but
one example of what happens when people mis-manage memory.
[Let us not get into whether it is the "fault" of microsoft for
their memory model, or the programmer.]
As one who has been writing programs for over 30 years, in a variety
of languages, systems, and hardware, I agree with Robert:
There are very few Software Engineers available.
Unfortunately for our profession, many of the people who call themselves
software engineers know only one language, for one OS, one one hardware.
To carry Matt's anology, I'd hardly call a person a civil engineer if
all (s)he knew how to do was build two-lane bridges for 1 car-at-atime
traffic on lightly traveled rural roads!
**We now return you to team-ada. Excuse the digression **