[
Lists Home |
Date Index |
Thread Index
]
Rick Marshall wrote:
> it [COBOL] also helped create the myth (and to some
> extent reflected the optimism of the time) that
> anyone could be a programmer (and by implication
> a good programmer) with a language that allowed
> them to express their instructions more naturally.
> with hindsight we know that's not true. just like
> not everyone, with best will in the world, can
> become a "brain surgeon".
Sure, not everyone can be a "brain surgeon" but just about
anyone can learn to use a pin or tweezers to pull a splinter out of
your toe (minor surgery)... Similarly, just about anyone with an
above-room-temperature IQ can learn to become a "programmer." The
question isn't one of kind, it is one of quality.
Different languages serve different purposes and different
audiences. One of the wonderful hopes for COBOL was that it would be
language that non-programmers could *read* -- not necessarily *write*.
The idea was that managers would be able to review the code to ensure
that algorithms were correct. And, one of the features that was
intended to encourage this was the fact that COBOL supported really
long variable names (at the time, that was unusual). I remember
listening to Grace Hopper complain -- at Digital, where she ended her
career -- about the way people were creating variable names. She said
that you were supposed to have readable variable names like
"last-years-net-revenue" so that managers could review the code,
however, lazy programmers were using variable names like "LYNR" to
save on typing. Worse, the "data dictionary" fad was heavily in force
in those days and even the vaguely meaningful "LYNR" was being
replaced by indecipherable crud like "A0942B"...
I also can't help being reminded of the debates we had in the
Visual Basic team at Microsoft about some of the essential elements of
VB's design... There were many things that you couldn't do with the
original Visual Basic but that wasn't seen as a problem since the
language was targeted at "Solution Builders" not "Component Builders."
We explicitly decided, for instance, to support only aggregation, not
inheritance, in order to keep the complexity level low enough to
empower people who combined together components written by Component
Builders (using C++, etc). If we had supported inheritance, pointers,
etc. in Visual Basic, it would have been "just another language" and
would never had had the success it has had. VB was built for folk who
knew more about the applications they wanted to use and were closer to
the business problem than the component builders who were closer to
the machine and understood more about computers than business
processes. Of course, this distinction has been lost today. The Visual
Basic of today is little more than "yet-another-syntax" for doing .NET
stuff. We have lost something important and useful by making it harder
for the non-CS geeks to build applications.
Just about everyone can be a "programmer" and just about
everyone has a chance to be "excellent" at what they do as long as
they are careful not to go beyond their limits. It is no "myth" that
everyone can be a "good programmer." The myth is that "programming" is
a single, undifferentiated set of skills. It is not. There are many
kinds of programming and I've never met anyone who was "good" at all
of them.
bob wyman
|
