🚀 go-pugleaf

"Alan L. Lovejoy" <alovejoy@concentric.net> wrote:

> Doug Bell wrote:
>
> > Well, you left out my definition of workhorse language from my post:
> > 
> > "I would define a 'workhorse' language to be one which is used by a large
> > body of people to produce useful software which is used on a regular
> > basis."
> > 
> > *Maybe* Smalltalk has grown into this role (from the number of people
> > jumping on me for my original post, I might consider this :), but you tell
> > me: Does Smalltalk meet that definition?  Honestly, now, is there a "large
> > body of people" using it?
> 
> Well, define "large."  
> 
> And someone will have to tell both of us what the headcount of Smalltalk
> programmers is.  Tens of thousands, certainly.  Perhaps hundreds of
> thousands.  Does anyone have solid data?  I've seen a yearly growth
> rate of 200% quoted, but that's not an absolute number.

"tens of thousands", producing useful software used on a regular basis
probably meets my definition of a workhorse language. 
Congratulations...if this is where Smalltalk has grown to, then perhaps
you have been fortunate not to have invested your time in a dead-end
language.

> Firstly, if Java is to be used to code applets on WWW pages, then it will
> always be interpreted (when used for that purpose)--unless the world happens
> to standardize on exactly one instruction set to the exclusion of all others.

Here's my opportunity to teach you something.  :)

Currently, Java is executed through interpretation.  This is already
starting to change as the first "just in time" compilers (or JIT
compilers) for java are becoming available.  A JIT compiler will translate
the machine-independent byte-codes of Java into directly executable
machine code.  This translation happens as the code is loaded off the
network, and in fact should occur faster than the code is downloaded
across the network, so there should be *no* additional delays imposed by
this translation.  The resulting machine code is then executed.  Web
browsers most certainly will use JIT compilers in the near future.  Stand
alone Java applications can either be translated as they are loaded, or
translated once for a platform.

The performance of this translated code is yet to be determined, but it
should be able to achieve somewhere between 50% and 100% the speed of
natively compiled C or C++ code.

In addition, Sun is already working on processors which will execute the
Java bytecodes directly.  How these will affect the market remains
unclear, but it serves to point out that there are even greater
performance possibilities already in the works.

> > To give a short analogy (please no flames on this, that belongs in a
> > different newsgroup), I use a Mac.  I am convinced that a Mac is a better
> > tool than a Windows-based PC.  Why, then, is not the Mac the dominant
> > tool?  Two reasons: 1) it was too expensive for a long time; and 2) it was
> > not an open system and the pace of innovation was limited to a large
> > extent to what Apple could manage.  I blame the tool for this.  It doesn't
> > stop me from trying to promote it, but I don't blame everyone who bought a
> > PC for the failings of the Mac.  Nor do I mark it up to "prejudice,
> > ignorance, politics, inertia and the tendency to copy what others are
> > doing".
> 
> Your analogy between the Mac and Smalltalk is more apt than you may know.
> 
> But the Mac is not responsible for its failure.  Apple is.

Agreed.  But the tool and its match to the market is the result of Apple's
mis-steps, so ultimately the tool becomes less useful because resources
and innovation are directed at the PC.

> As Ken Auer once said, "If Smalltalk succeeds, it will be in spite of
> ParcPlace."
> 
> Fortunately, the Mac and Apple are not dead yet.  Nor is Smalltalk.
> 
> Where there's life, there's hope.

Yes, there is hope.  But it still requires capitalizing on the
opportunity, not grumbling about "what should have been."

> The main differences between Java and Smalltalk (as languages, not as
development
> environments or delivery platforms):
> 
> 1. Java is statically typed, Smalltalk is not (although both use dynamic
binding).

Maybe this my lack of understanding (as I bow to the Gods of OOP who have
traveled the road farther than I), but I view Java's strongly typed
behavior as a benefit.  I realize this is probably different from what you
mean by statically typed.

> 2. Smalltalk has block closures.  Java doesn't even have function pointers.

I keep seeing this.  What is a block closure?

> 3. Smalltalk is highly reflexive and permits metaprogramming.  Java isn't and
> doesn't (compared to Smalltalk).

English please... (sorry)

> 4. There are massive syntactical differences that are the fodder for religious
> wars, but have no fundamental significance.  The full grammar of Smalltalk
> can be expressed in about twenty EBNF statements. If it takes you longer
> than a day to learn the syntax, you should consider changing professions.

Syntax is the least significant part of learning a new language.  Design
principles, libraries, standards of use, experience--these are what take a
long time to master.  The more these change from whatever went before, the
longer it takes to become productive in a new language.

BASIC-->Pascal was a much bigger shift (long ago), than Pascal-->C (long
ago also), because the first transistion was from non-procedural to
procedural language while the second was mostly a change in syntax. 
C-->C++ was similarly a larger shift (and really I think C++ is a poorly
designed language, so that didn't help) than 6502-->680x0 or
680x0-->PowerPC assembly because again the paradigm shifted.  Probably the
biggest shift was learning Prolog, because procedural to declarative
required an entirely different mindset.  Not to say that there weren't
benefits gained from these transistions, just that the syntax was never
the issue in any of these shifts.

Doug Bell
dbell@shvn.com