An Improvement Over its Successors (was Re: [squeak-dev] Smalltalk pre-80 (circa 1975))

David T. Lewis lewis at mail.msen.com
Thu Dec 15 03:31:35 UTC 2011


On Tue, Dec 13, 2011 at 08:52:30PM -0800, Casey Ransberger wrote:
> Below. Original message massively abridged.
>
> On Dec 13, 2011, at 8:01 PM, "David T. Lewis" <lewis at mail.msen.com> wrote:
>
> Context: WRT an industrial BCPL application.
>
> > The application is
> > fast, reliable, and flexible, and to this day it remains a great
> > improvement over its successors.
>
> I had to read your reply again in order to catch this line. Well done. I see what you did there!

Of course the phrase "improvement over its successors" is not mine.
Since you noticed it, and since I did not know who I had stolen in from,
I googled around and found that (according to Wikipedia) it may be
attributed  to Tony Hoare, who described Algol 60 as "a language so
far ahead of its time that it was not  only an improvement on its
predecessors but also on nearly all  its successors."

>
> I read recently that a study done on enterprise apps written in many
> different languages found the most defects per capita in Java apps.
> This didn't come as a surprise, but what did: the apps with the lowest
> defect rates were written in COBOL.
>

I do not really know why this is the case. But as luck would have it,
the BCPL application that I mentioned is being replaced by a more
"modern" system implemented largely in Java. And oddly enough, the 
development team for the new system spends a large proportion of its
time and energy on "defect resolution". What I find most interesting
about this is that the supporting tools and processes for the project
are largely organized around management of defects. In other words,
there are meetings held and resources assigned to address the topic
of "defects", as opposed to any number of other topics (such as design, 
requirements, new development, defect prevention, etc), and this seems 
to be accepted as a perfectly normal state of affairs. Even more
strangely, these people are working in an industry (automotive) in
which quality is critical to survival. Can you imagine building automobiles
in an environment where fully half of the production time was consumed
in repair bays and lot repairs, and where the end product was shipped
to customers and dealers with whatever defects did not happen to be
noticed in the repair bays? Unthinkable.

I do not think that this has anything at all to do with Java, and I see
no reason that high quality work cannot be done in Java. But it does
appear to me that Java combined with its surrounding hype and
productivity tools just seems to attract the wrong kind of people.

BCPL on the other hand has a built in "keep the riff-raff out" advantage.
The sort of exuberantly incompetent people who are attracted to
Java and its related technologies have neither the ability nor the
interest to do work in BCPL, and as a result the industrial application
that I mentioned has been nurtured and developed by a small number
of compentent people over the years, while avoiding the sloppy messes
that tend to accumulate around more mainstream applications.

The lesson that I draw from this is that, in some cases, being mainstream
is really not an advantage at all. And of course that technology and tools
are not a substitute for competence, process discipline, and above all a
commitment to quality.

Dave




More information about the Squeak-dev mailing list