🚀 go-pugleaf

Doug Bell wrote:
> 
> In article <316E3FB6.38F7@concentric.net>, alovejoy@concentric.net wrote:
> 
> > 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?
> 
> 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.

> > 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.
> 
> Well, I think you miss the big picture if you are going to compare Java's
> resource requirements to Smalltalk's.  Interpreted Java is a transistion
> which I suspect will be left behind sooner rather than later.  The
> resource requirements of Java should actually be lighter than those of
> several conventional languages, with perhaps an exception made for it's
> less efficient use of memory than most conventional languages.
> 
> I wouldn't be interested in Java if I thought that the Java we have today
> was the Java we will have in six to nine months.  If I though it was going
> to be ten years before Java's current resource short-comings were
> addressed, I'd also not be interested, at least not for ten years, at
> which time I suspect there would be something more relevant to the current
> environment than Java which would warrant my attention.  ;)

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.

But of course, there is no reason that Java can not be used outside the
context of WWW pages--in which case the need for wide portability of the
object code does not have quite as high a priority.  However, given the 
language semantics, the same technical difficulties must be overcome to 
compile Java in the way that is traditional for C-like languages as would 
have to be overcome to do this for Smalltalk.  I think this can be done.  
I think it will be done--for both languages.  But C-style compilation is 
important not because it makes the code faster (it probably will NOT make 
either Java or Smalltalk as fast as C for many common algorithms, although 
it may do that in some cases).  The importance of C-style compilation is in 
the fact that it permits a program to be statically linked together with
only the code needed for that application, and it permits dynamic linking
from shared libraries.  The Smalltalk image is a great development
environment.  It is NOT a good deployment vehicle.  The sooner the
Smalltalk vendors realize this, the better.  One of the things I really
like about Java is that it may beat the Smalltalk vendors over the head
with this fact so painfully that they will finally take action.

If CLOS (an OO LISP) can be compiled into a traditional "native code" 
executable, there is no reason that the same could not be done for either 
Smalltalk or Java.  
 
> > 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?
> 
> I'm not "blaming" Smalltalk.  As you and others have pointed out, there
> are environments and projects for which Smalltalk is apporpriate.  But
> Smalltalk had all the advantages (time to mature and innovate, dedicated
> group of proponents, real-world application) over Java to be what Java is
> (net-based, providing a solution for which there is a demand, and easy to
> learn and assimilate for a large base of programmers), and failed.  So
> Java is the better tool for many projects than Smalltalk for these
> reasons.

There is no **technical** reason that Sun could not have chosen Smalltalk
to fill the roles envisioned for either Oak or Java.  For Java's role,
they merely needed their own Smalltalk VM with the appropriate security
features built in.  Back in 1986, the ParcPlace VM was only about 350k,
if I remember correctly, and the image was about 1.2 meg.  Even that
image/VM had several times more functionality than the current JDK.  
I'm not exagerating--I may even be understating the case.  Back then,
Smalltalk had to do all the graphics, windowing, rendering text into
multiple fonts/styles and so forth that today is usually handled by
the host platform windowing system.

I suspect they passed over Smalltalk for business reasons, such as the
desire to completely control the language and its implementation.  The
prejudices of many towards C-like syntax may have played a part, as well.
The fact that they wanted to keep Gosling, and he wanted to implement
a new language, may have something to do with what happened, as well.

Smalltalk's capability to do metaprogramming and reflection make it much
better at dealing with the issues of distributed computing than Java
could ever be.  And Smalltalk is at least as capable of communicating
over the internet as Java is.  Building Java-style security into an
applet-specific Smalltalk VM would be no more difficult than doing the 
same for Java.

The only failure of Smalltalk is that no one with sufficient wherewithal
had the vision to try this until Sun came along--but promoting Java instead 
of Smalltalk.  The Smalltalk community can fairly be blamed for failing to
capitalize on its opportunities. 
 
> Now if the Smalltalk people want to quit sulking over Java's sudden and
> rapid interest and do something to change the situation for the better,
> they should figure out how to adapt Smalltalk to this task.  If you build
> it, they will come.  If they don't come, you haven't built what they
> need.  It's not politics and the stupidity of the masses, it's survival of
> the fittest and the fitness of the tool.

Yup.

> 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.

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.

> But it doesn't follow that you should use Samlltalk whereever you might
> consider using Java, which is what some in this thread have seemed to
> suggest.
> 
> > No one language is right for every and all tasks.
> 
> Ahhh, harmony!  We certainly agree here.

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).
2. Smalltalk has block closures.  Java doesn't even have function pointers.
3. Smalltalk is highly reflexive and permits metaprogramming.  Java isn't and
doesn't (compared to Smalltalk).
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.

A reason to use one language instead of the other would have to be justified
either by one of the technical issues listed above, by differences in the
available class libraries and/or middleware, or else by business considerations 
such as we have already mentioned.  Oh, and of course the maturity of the
development tools would have to be considered.  Is that a technical or a
business issue?

> >>> 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.
> >
> > 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.
> >
> > --Alan
> 
> Well, it's really a difference of symantecs here, but the technical
> evaluation includes, IMHO, the suitability to the environment.  For
> example, your hypothetical language could either be designed to accomplish
> it's technical improvement AND be as familiar as possible to current users
> of English, or it could be designed purely on linguistic merits with no
> compromises to the existing base of users.  Which would be the
> "technically superior" language?  It would depend, in part, on how you
> define "technically superior".

Yup. I try to keep politics, sociology, cultural anthropology and linguistics
separated--except when multidisciplinary thinking seems to be called for.

> Doug Bell
> dbell@shvn.com

For those who have never seen Smalltalk code, here is an example (for VisualWorks, 
which is like saying "for the MFC libraries" or "for Motif" in the context of C++):

The following code opens a window that displays the text for "Hello, Java!":

| window | 			"<--Declares a temporary variable named 'window'"

window := ScheduledWindow new.	"<--Assigns an instance of ScheduledWindow to 'window'"

window component: 'Hello, Java!' asText asComposedText. 

				"^--Assigns a visual object that displays itself as 
				the text for 'Hello, Java!' to be the component of 
				the window; 'asText' is a message to the string
				'Hello, Java!', 'asComposedText' is a message to
				the Text object that is returned by the 'asText'
				message; 'component:' is a one-argument message
				to the instance of ScheduledWindow"

window open			"<--Opens the window"

That's it. Of course, this could be written all as one statement, on one line:

(ScheduledWindow new component: 'Hello, Java!' asText asComposedText) open.

Specifying the font, point size, style and color of the text could be done
with just a few extra message sends.  Still on one line in one statement, if
that suited your fancy.  

--Alan