On 19-05-2013 17:36, Jecel Assumpcao Jr. wrote:
> Frank,
>
>> Well, OK. It depends on what exactly you mean by "Smalltalk". If you
>> mean Smalltalk-80, then definitely not. If you mean ANSI Smalltalk,
>> then probably not. I don't see much value in sticking to "standards"
>> 15 years and older.
> While to many people "Smalltalk" is the same as "Smalltalk-80", I prefer
> a definition what includes Smalltalk-72 as a Smalltalk. Any such
> definition would most certainly include Self and Slate as Smalltalks
> too.
>
> Sort of like the confusion about "Free Software", I got tired of
> explaining my viewpoint regarding my Self/R design and simply renamed it
> to Neo Smalltalk instead.
>
> I do note that none of the various SqueakFests were about Squeak but
> rather about Etoys. So I agree that "Squeak Smalltalk" (which happens to
> be the term I use in all my papers) makes exactly what we are talking
> about very clear without restricting any future options.
>
> There was a time when the term "Smalltalk" caused very negative
> reactions and several projects tried to distance themselves from it. But
> that was when Java was new and needed agressive marketing. I feel that
> the current situation is entirely different.
>
> -- Jecel
>
>
>
I tend to agree with Frank about adherence to old standards & with all
arguments presented by Jecel.

One fact about smalltalk is that it was plagued by fragmentation. The
lack of a mainstream favored the appearance of several "smalltalk
idioms" that quite don't talk among themselves. That reduced
applicability and made disrupting advancements hard to achieve. So,
currently we have some commercial idioms that are simply too proprietary
& expensive for general use and some free software implementations that
are becoming too widely fragmented to allow coherent evolution.

Squeak is a really great platform. But currently is supported by a small
community and important issues just cannot be covered. After the schism,
at least two other versions of "baby squeaks" appeared. One is dealt by
a single developer. I hope him the best luck in the world. The other is
supported by some academic researchers that decided to reinvent the
wheel while designing the next thing in OOL and the result is something
that is just not stable and consistent in one hand and don't touch
important things already achieved by other OOLs in the other hand. So,
IMHO, current state of affairs is bleak at best.

Just to be synced with current hardware and OS technologies, one
important thing would be having squeak working fully 64bits and
multithreaded. It happens that cog is not 64 bits and it seems it cannot
be easily made so. The standard VM can be compiled 64 bits (64bit VM)
but image is still 32bit. Worse than that, multithreading is hard to
achieve. And simply there are not enough people to take care of these
issues. Supposing multithreading could be achieved, then distributed
objects (objects running in loosely coupled computer architectures)
would become important. But IMHO it is just centuries ahead of what can
be done today.

Best regards,

CdAB