>I'll tell you why. The "better" or more definitive solutions just aren't
>profitable. If anybody could get their work done easily and cheaply, who
>could sell a working force for the kind of money this industry is
>manipulating?

There is another reason.  If you are building applications in a dynamic 
language, you have a competative advantage in that you can feature evolve 
faster than your competition which uses C/C++/<whatever>.  On the other 
hand, if you tell people that "this app was written in 
Scheme/Lisp/Smalltalk/<dynamic>", people question the choice of language 
rather than really looking at the application.  So most of the real 
success stories never get told.

A basic problem I find is that many people assume a sw technology 
solution as opposed to understanding the design space and doing the 
cost/benefit for particular projects which shows which development 
technology to use.  Having the marketing VP dictate choice of 
implementation technology  is kind of like being an engineer designing a 
bridge and being questioned on why you are choosing a particular kind of 
steel and concrete.  The thing to do is be an engineer and talk about 
functional requirements like carrying capacity and geology of support 
structures, etc.  For some projects C/C++/machine-language is the best 
solution.  But trying to scale up device-driver technology to use in 
major projects is like trying to scall up wood from building small dams 
to build Hoover scale dams--the implementation technology works well in 
the small but does not always scale.  Sense of scale, knowing technology 
match to design and business requirements, and cost/benefit are the ways 
to convince upper management that particular technology choices make 
sense.

[Aside: I find it interesting that the trend to open source software 
(GNU, Linux, Squeak, &c) are catching on in the business world].

Cheers,
-KenD