jperry@UNIX.SRI.COM (John Perry) (05/22/87)
Many people have become jaded on the almost hackneyed issue of
which programming languages are "good" and which are "bad". This
may be due, in part, to two facts: 1) the theoretically better
languages often have practical shortcomings while the worse languages
often have practical features which are so handy that one is tempted
to ignore structural defects and ambiguities, and 2) what can anyone
do about it anyway?
The problem, as I see it, lies in the origin of use of computer
languages. Language use is propagated by folklore and word of mouth
and, by the time a standards committee (such as ANSI) gets ahold of
it, there is already such a large user base that no one wants to
institute wholesale changes because that would antagonize too many
established users. The standards committee acts largely as a
"yes man" and is reduced to quibbling over minor features that make
up less than 10% of the language.
Once the huge user base evolves, the rest of us must simply
learn the syntax of whichever language is the rage at the moment
and become cynical because we cannot fight the inertia. If you
are like me, you get the impression that whether you are discussing
languages or software packages, no theoretical issues govern the
discussion --- only vague quibbling over "features" and ego struggles
over whose language/package will hold the majority opinion. No one
will risk pruning excesses, artificialities, or ambiguities out of
a bad language, nor will anyone suggest prudent additions to basically
good ones.
But how can we expect to discuss theoretical issues when most
practicing computer professionals, who are from related fields but
have little formal computer science training, practice their art
as if it was little more than a bag of tricks and secret bits of
knowledge meant for only the cognoscenti. The situation is akin
to a musician who is technically excellent but whose playing just
sounds like a bunch of notes strung together because they had no
theme in mind while playing the piece.
This "worldview" of programming is reinforced in virtually
every journal extant. This reduces programming to simply the
clever application of memorized syntax and the only criterion
for a "good" program is that its contortions somehow produce
correct output. Of course, this also means that a "good"
programming language is one that does not enforce too much advanced
thinking and can be typed in as quickly as possible --- a "syntax"
that allows good memorizers to hack quickly.
As long as these notions of convenience persist, and as long
as the field is dominated by syntax-dominated thinking, we can
expect software support groups to remain quite busy, users to retain
their usual degree of marginally tolerant frustration, and the world
of computer languages to be dominated by syntaxes whose complications
will assure job security for lots of professionals who don't deserve
it.
John Perry
gwyn@BRL.ARPA (Doug Gwyn, VLD/VMB) (05/23/87)
As I see it, the problem is that 90% of everything is crap (Sturgeon's Law). This applies to programming (or should we say software engineering) as well as to other professions. One thing to keep in mind is this ALSO applies to academia. Good real-world engineering practice (of any sort) does not bear very close resemblence to the theoretical teachings of school. Concentrating on the "theoretical beauty and perfection" of a particular technique will often distract one from noticing that it doesn't meet the actual needs. The best programmers I know of are quite aware of theoretical results in language design, implementations of new languages, structured development methodology, and so forth. But they can get their job done quite well with "theoretically" inferior tools, nonetheless. The sound basic principles of software engineering are not tied to specific language syntax, but can be applied in many contexts. For example, David Gries's "The Science of Computer Programming" is a good introduction to an area of algorithm development methodology, whether or not one has at hand a language very similar to the one used by Gries. On the other hand, the methods of that book are totally outclassed by many real-world problem situations that demand more flexible approaches (although formal methods are still useful for subdomains of the overall problem). Now, it is certainly true that the "hobbyist" publications (everything from Byte on down) tend to show no signs of having heard of progress made in gaining control over the software development process made during the past twenty years; also, many programming practitioners who have been around that long have not kept up with genuine improvements in methodology. This is hardly surprising (Sturgeon's Law), but it is perhaps more than usually dangerous since programming has spread as a profession far faster than traditional engineering professions. It is actually fairly hard to find good programming professionals when so many hackers abound. But they're out there, in that ~10% who know what they're doing. Rather than focus too narrowly on issues of programming language syntax, let's be more concerned about the general educational issue.