🚀 go-pugleaf

Doug Bell wrote:
> 
> In article <316D8523.74D7@concentric.net>, alovejoy@concentric.net wrote:
> 
> > Would you consider VisualBasic to be a workhorse language?  Are there
> > or are there not many useful programs written in VisualBasic that
> > are widely-used?
> 
> Yes.  And yes.

If both Java and VisualBasic are suitable as "workhorse languages," what
is it that disqualifies Smalltalk?  
 
> > There are valid reasons why Smalltalk (or other advanced languages) may
> not be
> > a good choice for many projects.
> 
> And I'm sure there are also valid reasons why they *are* the language of
> choice for certain projects.  Just not as often as "work-horse" languages
> currently meet the criteria.

I might agree that Smalltalk (for example) would not meet the criteria for
a shrink-wrapped PC application, operating system, device driver or embedded
system as often as would C (for example).

But I must disagree about that in the case of most business apps developed for 
internal corporate use--the context in which more programming is done than in
any other.

> 
> > But the reason a language such as Smalltalk
> > is not used in most cases has more to do with prejudice, ignorance, politics,
> > inertia and the tendency to copy what others are doing than it does with the
> > technical merits of Smalltalk or the requirements of the project.
> 
> Now you're starting to sound like the guy I was originally responding to.
> Why would you assume that the match between the technical merits of
> Smalltalk and the requirements of the project *don't* have anything to do
> with it not being accepted on a broader basis?

Why would you assume there was a particularly strong correlation between
these things?  It's possible to be dumb and lazy--but rich.  And it's possible
to be smart and hard-working--but poor.  There are many reasons for this,
but the most important one is that the competitors don't start the game
at the same time with equal initial stakes.  Such is the case with technologies
and programming languages.  A ten-year head start can be parlayed into an
almost impregnable market position.  It's not just how good is the language,
but how widely used it is.  How easy it is to get trained, experienced talent.
The availability of mature, tested code libraries.  The loyalty of hordes
of dedicated users who want to capitalize on their ten years of experience
in the old language instead of being newbies in a new, unproven language.

Also, the environment in which the competition takes place is undergoing
constant, rapid change.  Smalltalk was simply not as viable ten years ago,
or even five years ago, as it is today, because of its memory footprint
and reliance on a virtual machine.  Imagine if this were 1986, and Sun
had just introduced Java! Imagine the excitement of running Java...on
a virtual machine...on a 16Mhz 386 with 640k of memory...with no virtual
memory...in real mode...

Smalltalk's age is irrelevant. What is relevant is that the ever-increasing
capabilities and performance of the hardware have made it suddenly very
viable--so much so, that a language with very similar performance constraints
and resource requirements is now the hottest computer language in two
decades.
 
> >> Let's just say that to some extent, the answers a language *does* have
> >> must be relative to the impact of the software which results from it.
> >> What other measure would you apply?
> >
> > I would say that the impact of the software implemented in a language
> > is the **intersection** (NOT the **union**) of the power of the language,
> > the talent of those using it, and the assignments that the language gets
> > dealt by the market.  Once one tool achieves dominance, it is very difficult
> > for other incompatible tools to become widely used--regardless of relative
> > merit (e.g., Windows, x86, S360/370, gasoline, chinese ideographs, etc).
> > So very good tools can have relatively small impact--because they don't
> > get used.
> 
> Here is the crux of the issue.  If a tool can't meet the requirements
> necessary to fit the demands of the market, pool of available talent, and
> integration with existing systems and infrastructure, then that is the
> fault of the tool, not the fault of the conditions under which it must be
> deployed.  The technical merits of the tool can only be properly judged in
> the environment in which it is to be deployed, not in the confines of the
> laboratory.

If "a tool can't meet the requirements necessary to fit the demands of the
market" because of its technical shortcomings, then you have a point.  If
the tool is rejected by the market because a) there was not a sufficient
supply of trained/experienced talent; b) the market had no confidence in
the tool because it was not blessed by <insert name of market-dominating
company of your choice here>; or c) because the market was going ga-ga over
some other tool that was no better (perhaps even worse) than another, and was
in no mood to even hear about any tool other than the one it had become
infatuated with--then you can't really blame the tool for being no good,
can you?

> This is the issue I have with those who look down from their ivory towers
> on those of us building productive software *despite* the failing of the
> tools, the crappy OS's and all the other realities under which any system
> must move forward.  It's idealistic, unrealistic and unproductive to take
> the position that if only the everyone could become enlightened and we
> dumped all the legacy systems and infrastructure, then we'd be in software
> heaven.  It wouldn't happen, even if we could do it, because you'd have to
> stop the pace of innovation as well, or heaven would start to look like
> what we have now--flawed.

You do what you have to do.  If you have to build shrink-wrapped PC software,
operating systems, device drivers, low-level graphics libraries, engineering
or scientific software, RSA encryption algorithms, weather forecasting
simulations or a Virtual Machine for a dynamic programming language, then I 
don't blame you for using assembly, or Modula-2, or C.  Those are the right
kind of tools for those kinds of jobs.  (However, I have always thought that
C could be much improved upon, so that it would be an even better high-level,
statically-typed assembly language: I'd start by changing the type declaration
syntax so that it was more like that of Modula-2).

But you should use a language such as Smalltalk (there are other languages
that are more or less comparable technically) for most custom business 
applications.  There is a reason that this market is dominated by languages
such as COBOL, RPG, VisualBasic, Delphi, PowerBuilder, Forte and Smalltalk,
all of which are very different than C. No one language is right for every and 
all tasks.

> BTW, this isn't directed at you, rather at those who take a holy-than-thou
> attitude, which is not how I read your response.
> 
> > Example: one could use modern linguistic science to design a much better
> > language than English or any other natural language.  Aren't you excited
> > by the prospect of using such a language?  I know, you just can't wait
> > to learn and start using this language.  Right?
> 
> Wrong.  Your natural language doesn't meet the requirements necessary to
> fit the demands of the market, pool of available talent, and integration
> with existing systems and infrastructure, so it isn't a better tool than
> the existing language, despite it's technical merits.
> 
> Doug Bell
> dbell@shvn.com

Precisely my point.  The corollary is that the fact that a tool has failed
in the market does not prove that the tool is technically flawed, or that
it could not possibly be much better from a technical standpoint than the
more popular tools.

You should study the history of the resistance to Arabic numerals by those
who were accustomed to using Roman numerals.  They were not impressed by the
fact that long division was many orders of magnitude faster using Arabic
numerals.  You should consider the possibility that your reaction to a new
programming language resembles the behavior of a Roman numeral user.  Do you
like Java because they've made the Arabic numerals look as much as possible
like the old familiar Roman ones?

--Alan