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

Juan Vuletich juan at jvuletich.org
Thu Dec 15 10:37:14 UTC 2011


David T. Lewis wrote:
> ...
> 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
>
>   

So true! Can't stop laughing!

Cheers,
Juan Vuletich



More information about the Squeak-dev mailing list