[prog] State of software engineering profession

[Robert J. Hansen]

> Though portability is not the only problem, let's use it as an example.
> Exactly what economic and intellectual investment are you refering to?

C# and Java come to mind as examples.  Microsoft and Sun have both made
huge economic investments in trying to make sure their code runs
unchanged on as many different platforms as possible--one example of how
they're attempting to solve one way in which our tools are currently
broken.

Insofar as intellectual investments, my college profs continually
hammered into my brain the need to consider the future when designing,
the need to avoid UNIX Programmer's Disease, etc.  That's an
intellectual investment which the field has made in trying to avoid the
worst of the brokennesses.  Etc.

> Inventing yet another language, is not a solution to the portability
> problem.  If the processor manufacturers standardize on a single
> instruction set architecture, we wouldn't have any portability problems at
> all.  A VM is just a software path to this solution, and as a result, it

A few observations:

1.  Who says a VM has to be V?  Look at Sun's PicoJava chips.  Hardware
is just software that's been frozen in silicon, to quote Andy Grove. 
However... Sun discovered that hardware implementations of the JVM were
doomed.  Why?  Moore's Law: in 18 months the speed of software JVMs will
double, but the PicoJava chips won't, not unless Sun made a _huge_
investment in chip fab, in continually updating their designs, etc.

2.  The VM performance penalty is not a realistic argument anymore. 
Very few applications--and I mean astonishingly few--are
processor-bound.  Bottlenecks are overwhelmingly in I/O bandwidth and
latencies.

3.  A completely standardized Assembly instruction set would kill
innovation in the field of hardware, and be nigh-useless in software. 
How many registers does a P4 have?  How many does a PIC have?  The
PowerPC and Intel x86 line are register-based processors: where does
this leave stack-based processors like PicoJava and PostScript chips? 
Please don't say "well, of course we need multiple standards", because
(a) that's a dodge and (b) we already have multiple standards: the Intel
x86 instruction set is an industry standard, as is the PowerPC
instruction set, as is... etc.

> Also, standardising on an ISA could still allow each chip vendor to
> differentiate themselves.  They could design processors with different

I think you're underestimating the cost of a chip fab plant.  Very few
companies can afford to differentiate themselves among the competition. 
The reason is that (a) it costs billions of dollars--literally!--to get
a new chip fab plant running, and (b) the more you differentiate
yourself, the less the likelihood your chip will catch on ("hey, Bob,
should I spend $500 on this new Intel chip, or should I spend $500 on
Uncle Joe's IntelAlike with new instructions for efficiently making
coffee?").

Not only that, but how will different chip manufacturers differentiate
themselves when there's a completely standardized instruction set? 
You're arguing two contradictory views here: the one says we can't have
the differentiation that we currently see, and the other one says
differentiation is good.

> This is THE solution to the portability problem.

"I would consider belief in One True Way to be a childhood disease of
programmers, if it weren't for the fact so many adults seem to suffer
from it."
	-- Bjarne Stroustrup

> I haven't heard of any development process that says peer review is a bad
> idea.  How often does the industry perform peer reviews of design and
> implementation?  Matter of fact, the software industry goes out of its way

Everyplace that I've worked has done in-house peer review of its most
important code.

> willing to accept the poor state of the profession.  Robert, if your
> reasoning is a representation of the industry in general, then I can see
> how we got here and how we are stuck here.

No insult intended, I assume.  :)

> difficult problem.  If I'm having this much trouble just trying to
> describe the situation, imagine the effort in selling the solution to the

If you're having this much difficulty describing the problem, it's a
strong sign you don't understand the problem.  Once problems are
thoroughly understood and their causes clearly identified, they tend to
be very easy to describe.

-- 
Robert J. Hansen <rjh at sixdemonbag.org>