> | Seriously, languages must be designed for average, garden variety of
> | programmers, not CS graduates.
that makes unwarranted assumptions about the programming ability of CS
graduates. people who spend a few semesters writing bunches of programs
under a thousand lines each are not prepared to deal with languages
designed to work well when applied to multimillion line projects.
> you forgot to state the primary requirement of those languages this applies
> to: that you want to advertise the language itself in the mass media and
> likewise with programmer positions, and that you want to pay chicken feed
> to those you hire. if you have somewhat higher aspirations, you design a
> language so that average, garden variety programmers don't understand it,
> or won't flock to it.
rather, you need to design it without "understandable by mediocre
programmers" in the specification. it is difficult to justify advanced
language features like closures, continuations, and lots of other stuff
schemers take for granted if most programmers have been corrupted by
exposure to BASIC-like langues such as VB.
> | US DOD stated that conversion to parallel processing is not advisable
> | because only 1/3 of their programmers could program in appropriate
> | languages.
> precisely. note the converse: if you would like to retain the best third
> of your programmers, convert to parallel processing.
well, more likely, if you convert to a paradigm understood by a fraction
of your progammers, you will get bad code (like when someone learns C and
then has to write in a language like ML...you get C implemented in ML).
> those who argue for quantity over quality have yet to demonstrate that the
> lower prices carry smaller costs in terms of reduced quality than it saves.
i think history has demonstrated quite well the power of poor programming
to raise life-cycle costs.