Smalltalk: Requiem or Resurgence? {Dr. Dobb's Journal (05/06/06) Chan, Jeremy}

There's already a language called "Cool" so that's not the answer either. ;-)

I believe "collaboration" which provides "viral marketing" is the
answer and "Croquet" is its new name (for now).

Eventually those who use it will start naming it themselves as they
take ownership of their own content/coding/world-craft.

Darius

[hidden email] wrote: The most recent version appears to be a year old.  0.4.1  It isn't
marked as supporting Linux yet. ... well, except Ubuntu, and it's the
first release for it.
> ...or just use Dolphin for win32 apps - it is really nice for that.
> Or turn the app into a localhost webapp, like we are currently doing
> with the issue tracker we are writing.
>  
Dolphin might be OK, but I'm doing all my development on Linux...for
which there *is* no Dolphin.  Squeak is very nice, but if one can't
easily create a distributable piece of software, it's viability as a
development platform is ... limited.  I had thought that Squeak could
compile it's code to C.
> ...
> regards, Göran
This should be solvable.  One plausible method would be to create a
"live distribution" of Squeak-minimal that could self-install on any
(major) OS, and then make it easy to modify...including a scripted
installation of files from SqueakMap.  It's true that the resulting
applications would be "rather large", but that's much less of a problem
than it used to be, and the alternatives aren't great.  (Well,
compilation to C would be better, but I'm presuming that this is
impossible.)

As to the "controls" issue... how much of an issue that is depends on
your audience.  It also depends on how valuable they find your
application.  "Native" appearing controls *are* a definite plus, and no
two ways about it, but they aren't necessarily a determining factor, not
if the controls you use are any good.  (That said, if wxsqueak *is*
successful, it would be another big plus.)

My point of view:  I'm a Squeak newbie.  I'm still getting the hang of
the language, and haven't yet delved into GUI creation.  Squeak seems a
very promising development environment...but possibly only for
prototypes.  The big problem would be getting programs developed in
Squeak made accessible to people who don't already have Squeak
installed.  The apparence of the controls is a relatively minor
consideration.  HTML subterfuges are unsatisfactory as a general
solution, though they may work well in many special cases.  I'm
currently planning on learning Squeak as a prototyping environment,
while waiting for alternatives ... alternatives which *would* allow the
programs to be readily distributed ... to mature.  Of course, a better
answer would be if Squeak itself were to become that "alternative" (or,
possibly, for me to discover that I already CAN do that in Squeak), but
even if it doesn't I expect to prototype in it.

My sincere apologies. It must be something with the setup of my browsers.
So my experience doesn't illustrate anything.
--- Trygve


At 15:06 12.05.2006, you wrote:

--

Trygve Reenskaug      mailto: [hidden email]
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway

You can definitely distribute an installer that has the VM and required
files to run a Squeak image on a machine that has never seen Squeak before.

I have found that most users do not care that much if the widgets look the
same as the OS as long as they look reasonably good, and behave predictably.
There are a bunch of Java applications out there that do not look native
either.  It would be more helpful if the top level Squeak windows were top
level OS windows, but even that can be OK if the entire Squeak window is
thought of as a single MDI application rather than as separate
applications/windows.  Dialog boxes are more of an issue since the Squeak
dialogs have very low contrast to the windows around them and do not appear
separate from the main Squeak window.  I have not tried it yet, but it may
be possible to open multiple "desktop" windows in one image.  That would
give the application control of multiple native windows and all would be
good.

Michael



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Charles
D Hixson
Sent: Friday, May 12, 2006 9:15 AM
To: The general-purpose Squeak developers list
Subject: Re: Smalltalk: Requiem or Resurgence? {Dr. Dobb's Journal
(05/06/06) Chan, Jeremy}

[hidden email] wrote: The most recent version appears to be a year old.  0.4.1  It isn't
marked as supporting Linux yet. ... well, except Ubuntu, and it's the
first release for it.
> ...or just use Dolphin for win32 apps - it is really nice for that.
> Or turn the app into a localhost webapp, like we are currently doing
> with the issue tracker we are writing.
>  
Dolphin might be OK, but I'm doing all my development on Linux...for
which there *is* no Dolphin.  Squeak is very nice, but if one can't
easily create a distributable piece of software, it's viability as a
development platform is ... limited.  I had thought that Squeak could
compile it's code to C.
> ...
> regards, Göran
This should be solvable.  One plausible method would be to create a
"live distribution" of Squeak-minimal that could self-install on any
(major) OS, and then make it easy to modify...including a scripted
installation of files from SqueakMap.  It's true that the resulting
applications would be "rather large", but that's much less of a problem
than it used to be, and the alternatives aren't great.  (Well,
compilation to C would be better, but I'm presuming that this is
impossible.)

As to the "controls" issue... how much of an issue that is depends on
your audience.  It also depends on how valuable they find your
application.  "Native" appearing controls *are* a definite plus, and no
two ways about it, but they aren't necessarily a determining factor, not
if the controls you use are any good.  (That said, if wxsqueak *is*
successful, it would be another big plus.)

My point of view:  I'm a Squeak newbie.  I'm still getting the hang of
the language, and haven't yet delved into GUI creation.  Squeak seems a
very promising development environment...but possibly only for
prototypes.  The big problem would be getting programs developed in
Squeak made accessible to people who don't already have Squeak
installed.  The apparence of the controls is a relatively minor
consideration.  HTML subterfuges are unsatisfactory as a general
solution, though they may work well in many special cases.  I'm
currently planning on learning Squeak as a prototyping environment,
while waiting for alternatives ... alternatives which *would* allow the
programs to be readily distributed ... to mature.  Of course, a better
answer would be if Squeak itself were to become that "alternative" (or,
possibly, for me to discover that I already CAN do that in Squeak), but
even if it doesn't I expect to prototype in it.

My pages (created in iWeb) require QuickTime.

iWeb also creates some really funky HTML.  However, I've had horrible  
luck with opera on the Mac (crash city) and IE is well, IE.  Don't  
use IE!  Use Firefox or something :)

I used iWeb as an experiment to learn the tool so when my Mom asks  
questions, I can answer them heh.

Steve

On May 12, 2006, at 9:22 AM, Trygve Reenskaug wrote:

Hi folks,

I'm a long time Mac user.  Feb, 1984 to be exact.  I used to be a  
total asshole about UI.  Making our apps look/feel exactly like a Mac.

I still feel this way if I am building a Mac app.  The more  
familiarity one has with your user interface, the more productive  
they are.

However, and I have seen this so many times I can't count - If a tool  
does something the Author wants to do, the Author will adapt.  Almost  
always.  They might complain and want more integration but at the end  
of the day, if there are no other tools, they will adapt.  And to top  
that off, if your alternate UI is decent, it might not even be a  
problem.

Sophie presents some interesting challenges for us.  John has  
integrated the Mac spelling checker, clipboard, file dialogs, etc.  
We've got ideas for mapping our menus into the Mac menubar.  This is  
not just technical, but if you are going to use the default menubar,  
make it fairly similar.

I now keep an open mind.  How many times have developers come up with  
new UI elements that later made it into the OS? SuperClock anyone? :)

I concern myself more with issues such as:

* Do all of our selected objects select similarly?
* Is it clear which object has the focus?
* Is the gesture of dragging clear?
* Is the gesture of dropping clear?

Consistency within your app is very important.  Then you integrate  
with the OS and make the transition for the Author easier.

This is the second 'cross platform' application I have worked on.  
I've said both times, if we build OS clients, then those are  
completely separate projects, teams and budgets.  The file we work on  
is the same, but the UIs, while similar, are very different.  You  
either go 1000% for the best Mac app, or best WIndows app, or do your  
own thing.

Apps that try to look like a Mac but only get there 80% are the worst  
in my opinion.  What I like about Sophie is that we have our own  
look, our own feel and support bridge technologies to and from the  
OS.  But we're not using Aqua, or worse, FAKING Aqua. Like some Java  
crap I've seen in the past.  Bleh.  "Wow that sure looks like a OS X  
scroll bar but doesn't behave anything like an OS X scroll bar!"

Time will tell how well this works.  I like the FFI stuff.  What I'd  
like to see more are OS "kits" that make writing "apps" easier.
 

On some platforms it can be even simpler, requiring no special  
installation at all.
Example 1 - RISC OS (because I know a fair bit about it). Insert  
image in application directory. Insert changelog, if required, into  
application. Zip. Upload to server. User downloads. User can run  
application from within zip (just one of those nice things RISC OS  
has been able to do since DOSosaurs stalked the earth) or simply drag  
the app out of the zip to save somewhere else.
Example 2 - OSX. Build an application bundle - this is what Sophie  
does. Upload to server. User downloads. Run application.

If an OS is making it any harder than that, don't use such a lousy  
OS. And no, I'm not smiling, or being sarcastic or ironic or anything  
other than straight. If you are using an OS that makes life  
difficult, don't.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
You can't make a program without broken egos.

It doesn't work in my up-to-date Firefox browser either. I expect it
probably would if I could remember the plugin setup magic. But my
experience doesn't illustrate anything either. Just sayin'. :)

On 12-May-06, at 9:15 AM, Charles D Hixson wrote:

> (Well,
> compilation to C would be better, but I'm presuming that this is
> impossible.)

Why would compilation to C be better? You wouldn't gain any  
performance in any serious application. Consider a moment; to send  
messages you have to do certain work. If you compiled
'foo doThis: 4'
into C it would have to be something like
messageSend(foo, 'doThis', 4);
and the messageSend function would be pretty much exactly what we  
already have in the VM.
"Ah, but arithmetic would be faster!", cries the C programmer. Well,  
just possibly, if you know you have value restrictions that would  
work in C. Any time there is a chance of overflowing int values, or  
heterogeneous content in an array you're royally screwed.

And so on. IF you have very repetitive work to do on a statically  
limited dataset then C can do better. Sometimes. And in that case we  
write a plugin and get the best of both worlds.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Soft rock

tim Rowledge wrote:
> Why would compilation to C be better? You wouldn't gain any performance
> in any serious application. Consider a moment; to send messages you have
> to do certain work. If you compiled
> 'foo doThis: 4'
> into C it would have to be something like
> messageSend(foo, 'doThis', 4);
> and the messageSend function would be pretty much exactly what we
> already have in the VM.

Well... no. It would use the native stack for call-return which is
significantly faster than what we've got in Squeak today. If you look at
Ian's latest (Pepsi; a statically compiled dynamic language environment,
see http://piumarta.com/pepsi/pepsi.html) the difference is very
noticable (2-5x in speed depending on how you measure).

Cheers,
   - Andreas

On 12-May-06, at 10:34 AM, Andreas Raab wrote:
And this relies on 'compilation to C' how? We can use native stack  
call-return in various ways and I don't think 'compilation to C' has  
any bearing on it at all.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Bother" said Pooh as "Formating Drive C" appeared on the screen...

tim Rowledge wrote:
>> Well... no. It would use the native stack for call-return which is
>> significantly faster than what we've got in Squeak today.
> And this relies on 'compilation to C' how? We can use native stack
> call-return in various ways and I don't think 'compilation to C' has any
> bearing on it at all.

If you are talking about some hypothetical future system you may be
right. Today, however, the only choice of using the native stack is
compilation to C like we do for the VM and that does have significant
speed advantages.

Cheers,
   - Andreas

Hi,
I'm a Smalltalk newbie and just want to drop my 2 cents to this
discussion and maybe vent my frustration a little. Please don't take
it anyone personal.

Hernan Wilkinson schrieb:
<snip>
>    I think the problem with Smalltalk is not technical, nor a problem
> of education either. We all now that Smalltalk has nothing to envy
> from Java, C++, .Net and the like, but the other way around.
<snip>
> We all know that Smalltalk has a great VM, has a great environment and
> tools and no other main stream language can compete with Smalltalk on
> this features.
<snip>
>    The problem with Smalltalk is a MARKETING problem, no technical.
Sorry, but I don't agree with you. And I will tell you why.

It depends what you mean by "Smalltalk". If you just mean the language
by itself, then you are right,
no other main stream language can compete with Smalltalk

If you mean the hole environment, then I can't agree with you.
One thing Java and .Net have in common, C++ is trying to get and
Smalltalk is missing, is a standard
library set. Every dialect of Smalltalk has its own set.
The languages mentioned above, offer a huge choice in libraries.
Smalltalk offers also
quite a good choice in libraries, but scattered to different dialects.
Which makes finding all needed libraries for a project quite difficult,
without
porting libraries to the preferred dialect.
Porting Libraries is not a beginners task and actually all the "speedup"
I gain
by using Smalltalk is in vain if I can't reuse a library.

I don't believe marketing is the main problem, because almost all
programmers
I know, know what Smalltalk is. So, they had contact with  the product,
somewhere,
somehow, but they didn't buy it.

> So, the problem with Smalltalk is that it is OLD.
The only problem with "OLD" is, if you are looking for documentation and
find something form like 1996, I always think: this can't be up to date.
I learned that is doesn't count for the language itself. But if it is some
library, it it ether really stable or abandoned.

I think the hole Smalltalk community is bigger than it
appears to be, but sadly scattered and wasting their energy
reimplementing problems solved in different dialects.

I found in some archives someone bitching about Cincom reimplementing
the Java Servlets API for their Visualworks WebToolKit. Sure the API  is no
way Smalltalk style, but the idea itself is brilliant. I, as a Java
programmer, felt
immediately at home and comfortable. Though is was a known API to me,
it felt much easier to use, because of all the advantages of Smalltalk.
This left a deep impression. And there is the brilliance of this idea:
Combining something known with something as elegant as Smalltalk,
is quite attractive.
Sadly, I came pretty fast to the described library problem. I couldn't find
a library to write JPEG images. I know Squeak has one, but it doesn't
have the WebToolKit and porting is beyond my abilities.
The same goes for databases, etc., etc.

So, here I am, trying to decide which dialect I should use,
if any.

Thank you for reading.

Geetings,

Waldemar Dick

You make a very good point.  I was very surprised that I could not take a
simple Integer benchmark and move it to all the dialects, because one of
them choose to use a different name for the method on Time that measures how
long a block takes to run.  The method was there, but had a different
selector.

When it comes to UI frameworks it is a much wider gap.

There are some differences based on VM design and VW has chosen to redesign
the entire way that classes are defined.  But, to a user it should all work
if it is Smalltalk.  The COM integration for example on VW and Dolphin do
not need to be different, and Squeak did not have to use a different way to
call native methods.  But, they are all competing with each other, or
ignoring each other.  That means that each dialect has to stand alone
against Java and C#.  The industry council did nothing really to bring the
implementations together.

While we often complain that Java and C# did not learn from Smalltalk, I
guess we did not learn from C.  Porting C applications from one system to
another is hard and requires care.  Smalltalk should do better.

Michael



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Waldemar
Dick
Sent: Friday, May 12, 2006 11:31 AM
To: The general-purpose Squeak developers list
Subject: Re: Smalltalk: Requiem or Resurgence? {Dr. Dobb's Journal
(05/06/06) Chan, Jeremy}

Hi,
I'm a Smalltalk newbie and just want to drop my 2 cents to this
discussion and maybe vent my frustration a little. Please don't take
it anyone personal.

Hernan Wilkinson schrieb:
<snip>
>    I think the problem with Smalltalk is not technical, nor a problem
> of education either. We all now that Smalltalk has nothing to envy
> from Java, C++, .Net and the like, but the other way around.
<snip>
> We all know that Smalltalk has a great VM, has a great environment and
> tools and no other main stream language can compete with Smalltalk on
> this features.
<snip>
>    The problem with Smalltalk is a MARKETING problem, no technical.
Sorry, but I don't agree with you. And I will tell you why.

It depends what you mean by "Smalltalk". If you just mean the language
by itself, then you are right,
no other main stream language can compete with Smalltalk

If you mean the hole environment, then I can't agree with you.
One thing Java and .Net have in common, C++ is trying to get and
Smalltalk is missing, is a standard
library set. Every dialect of Smalltalk has its own set.
The languages mentioned above, offer a huge choice in libraries.
Smalltalk offers also
quite a good choice in libraries, but scattered to different dialects.
Which makes finding all needed libraries for a project quite difficult,
without
porting libraries to the preferred dialect.
Porting Libraries is not a beginners task and actually all the "speedup"
I gain
by using Smalltalk is in vain if I can't reuse a library.

I don't believe marketing is the main problem, because almost all
programmers
I know, know what Smalltalk is. So, they had contact with  the product,
somewhere,
somehow, but they didn't buy it.

> So, the problem with Smalltalk is that it is OLD.
The only problem with "OLD" is, if you are looking for documentation and
find something form like 1996, I always think: this can't be up to date.
I learned that is doesn't count for the language itself. But if it is some
library, it it ether really stable or abandoned.

I think the hole Smalltalk community is bigger than it
appears to be, but sadly scattered and wasting their energy
reimplementing problems solved in different dialects.

I found in some archives someone bitching about Cincom reimplementing
the Java Servlets API for their Visualworks WebToolKit. Sure the API  is no
way Smalltalk style, but the idea itself is brilliant. I, as a Java
programmer, felt
immediately at home and comfortable. Though is was a known API to me,
it felt much easier to use, because of all the advantages of Smalltalk.
This left a deep impression. And there is the brilliance of this idea:
Combining something known with something as elegant as Smalltalk,
is quite attractive.
Sadly, I came pretty fast to the described library problem. I couldn't find
a library to write JPEG images. I know Squeak has one, but it doesn't
have the WebToolKit and porting is beyond my abilities.
The same goes for databases, etc., etc.

So, here I am, trying to decide which dialect I should use,
if any.

Thank you for reading.

Geetings,

Waldemar Dick

Hi Waldemar,

on Fri, 12 May 2006 20:30:47 +0200, you <[hidden email]> wrote:
...
> I don't believe marketing is the main problem, because almost all  
> programmers
> I know, know what Smalltalk is. So, they had contact with  the product,  
> somewhere,
> somehow, but they didn't buy it.

A b s o l u t e l y  correct: they all know it.

...
> ... Though is was a known API to me,
> it felt much easier to use, because of all the advantages of Smalltalk.

Again, absolutely  c o r r e c t. API is what makes the curly world go  
'round. Learn the API once and apply it everywhere (isn't that called  
'leverage' in English?).

...
> So, here I am, trying to decide which dialect I should use,
> if any.

Well, coffee has no dialect <grin> it has provenience.

/Klaus

Michael Latta wrote:
> There are some differences based on VM design and VW has chosen to redesign
> the entire way that classes are defined.  But, to a user it should all work
> if it is Smalltalk.  The COM integration for example on VW and Dolphin do
> not need to be different, and Squeak did not have to use a different way to
> call native methods.

And how exactly do you know that? Do you know anything at all about how
the FFI evolved, which tradeoffs were made for what?

   - A.

Waldemar Dick wrote:

> Hi,
> I'm a Smalltalk newbie and just want to drop my 2 cents to this
> discussion and maybe vent my frustration a little. Please don't take
> it anyone personal.

No problem.... but let me just say that because you are new to
Smalltalk, your point of view is not "big" enough, you haven't have the
time to taste Smalltalk... now, please don't you take it personal.
I have worked with Assembler, C, C++, Java and some C#... but Smalltalk
is a "one way street". You take it and when you understand it, you don't
want to go back.

I don't see this as a problem. The main classes are similar and I don't
go from one Smalltalk to other coding. We develop in with one Smalltalk,
why would I need to use other Smalltalk?.
I used to think that one standard library was really important (in my
Java days), I bought that... but now that I work with Smalltalk, I
realized I don't need it.

> The languages mentioned above, offer a huge choice in libraries.
> Smalltalk offers also
> quite a good choice in libraries, but scattered to different dialects.

But what I like about Smalltalk is that if something I look for does not
exists, I can build it really fast... and also I don't care about the
number of "libraries" that exists, I care about how good they are, and I
found Smalltalk solutions to be better that Java and C# ones because
when you create programs in Smalltalk, your mind set is different,
therefore the solutions too.

> Which makes finding all needed libraries for a project quite
> difficult, without
> porting libraries to the preferred dialect.
> Porting Libraries is not a beginners task and actually all the
> "speedup" I gain
> by using Smalltalk is in vain if I can't reuse a library.

But why do you need to port "libraries"? Anyway, if that's your problem,
I understand it, but if you want a broad support for different
platforms, just choose VisualWorks that works in almost all platforms...
(Squeak also ;-) )

>
> I don't believe marketing is the main problem, because almost all
> programmers
> I know, know what Smalltalk is. So, they had contact with  the
> product, somewhere,
> somehow, but they didn't buy it.

Almost all programmers I know,  "believe" they know Smalltalk, but they
see Smalltalk from what they know, they see Smalltalk from a Java, C#
point of view, so they missed a lot of things. For example, they have no
idea about metaprogramming and its importance (¿how do you find all
subclasses of a class in java?, no way!), they do not know the
advantages of programming in the debugger!, every time you want to make
a change they have to stop the system, make the change and restart!, no
need for that in Smalltalk. They have no idea about inspectors, they are
not use to go and touch objects with the inspectors and test the
changes, they don't understand that the debugger is no more that an
inspector on the process stack! and because execution contexts are
objects they can change them, play with them, etc. Almost all people
that use Java and  C# have no idea about lambda expression (blocks in
Smalltalk) and its importance in programming... more over, until Java
came out, they confuse Interfaces with Classes, and still today a lot of
people don't understand the difference.
Don't get me wrong, I'm not saying you don't, but people that has not
seriously programmed in Smalltalk for more that six months, will not
really appreciate all its benefits and its comparison with other
languages will not be complete.

>
>> So, the problem with Smalltalk is that it is OLD.
>
> The only problem with "OLD" is, if you are looking for documentation and
> find something form like 1996, I always think: this can't be up to date.
> I learned that is doesn't count for the language itself. But if it is
> some
> library, it it ether really stable or abandoned.

That's good, but not everybody think like you do.... Smalltalk came out
in the 80's after 10 years or research, so it is really stable. If you
see at the main hierarchies they have not change!, the Collection
hierarchy, the Behavior hierarchy, the Number hierarchy.. (another great
example of what you can not do in Java or C#: just try to get 1000
factorial.... or just one divided by 3 (1/3)... the Number hierarchy has
such a polimorphism that no other language I know have...)

>
> I think the hole Smalltalk community is bigger than it
> appears to be, but sadly scattered and wasting their energy
> reimplementing problems solved in different dialects.

Hey!, the C# community is wasting more money copying Java and vice
versa! I don't think the Smalltalk community is wasting more money than
they do!... and the worse thing is that Java and C# will be obsolete in
10 years or so and Smalltalk will still be alive... of course I can not
prove it, but just looking how OO languages are getting closer and
closer to Smalltalk every ten years or so... In ten years we will all
agree that dynamic typing is better than static typing, that an image is
better that ten thousand files, etc. Now people accepts that a VM is
better than not having a VM, that a garbage collector is better than not
having one, etc. Ten years ago, we do not use to think that way..... So
I believe it is a matter of time...

I understand your frustration... it is rare that VisualWorks does not
handle Jpeg images, but hey, if you like to use other libraries get one
in C or C++ and use it from Smalltalk! ;-)
About databases, have you try something completely different as
GemStone?... if you didn't then again, you don't have the whole picture

>
> So, here I am, trying to decide which dialect I should use,
> if any.

I hope you can make up your mind. My advise, don't take too hard, you
will be able to do amazing things with either one...
And again, I hope you did not get mad, as you said, it is not personal
and if I made an invalid presumption about your knowledge, I apologize.

Bye!,
Hernan


--
______________________________
Lic. Hernán A. Wilkinson
Gerente de Desarrollo y Tecnología
Mercap S.R.L.
Tacuari 202 - 7mo Piso - Tel: 54-11-4878-1118
Buenos Aires - Argentina
http://www.mercapsoftware.com
---------------------------------------------------------------------
Este mensaje es confidencial. Puede contener informacion amparada
por el secreto profesional. Si usted ha recibido este e-mail por error,
por favor comuniquenoslo inmediatamente via e-mail y tenga la
amabilidad de eliminarlo de su sistema; no debera copiar el mensaje
ni divulgar su contenido a ninguna persona. Muchas gracias.
 
This message is confidential. It may also contain information that is
privileged or otherwise legally exempt from disclosure. If you have
received it by mistake please let us know by e-mail immediately and
delete it from your system; you should also not copy the message nor
disclose its contents to anyone. Thanks.
 ---------------------------------------------------------------------

The point is not who's design is better, nor technical issues.  The point is
that from a user of the system the differences in libraries has negative
value.  I do not know or care which is better.  I do know that if I could
take Smalltalk code form one VM to another the market for my work would be
larger.  The way each VM vendor has chosen to head in their own direction
means that they do not build a viable ecosystem.  Each vendor's product
stands alone, and has to build its own ecosystem.  Would it not be better to
share the maintenance burden on at least the core libraries?  Obviously at
this point there are many points where they are too distant to unite again.
But, upon reflection that is probably the largest reason Smalltalk has not
gained as much ground as it deserves.  Squeak certainly started as a
research project where such concerns were not the focus, and has evolved
largely as the users saw fit.  If there was more compatibility however the
VisualWorks ecosystem (Gemstone, and other tools) could be used with Squeak
and Squeak features (Balloon, Connectors) could be used with VW.  I also do
not like the way that VW has chosen to keep dropping "old" features like MVC
support.  As a result code I wrote 10 years ago does not run any longer, and
can not even be loaded to do a port.  At least Squeak has backward
compatible features to a large degree, even if as optional packages.

I do not claim to have a solution for how to move forward, but I did want to
acknowledge that this is a much larger part of the Smalltalk status quo than
I would have seen prior to it being pointed out.  Incompatible libraries,
and libraries that are constantly changing in incompatible ways, cause users
to abandon a platform.  I know one large application (RDD-100) where the
developers complained of having to spend 3/4 of their time keeping up with
image changes for VW.  That is very UN-productive.

Michael



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Andreas
Raab
Sent: Friday, May 12, 2006 1:07 PM
To: The general-purpose Squeak developers list
Subject: Re: Smalltalk: Requiem or Resurgence? {Dr. Dobb's Journal
(05/06/06) Chan, Jeremy}

Michael Latta wrote:
> There are some differences based on VM design and VW has chosen to
redesign
> the entire way that classes are defined.  But, to a user it should all
work
> if it is Smalltalk.  The COM integration for example on VW and Dolphin do
> not need to be different, and Squeak did not have to use a different way
to
> call native methods.

And how exactly do you know that? Do you know anything at all about how
the FFI evolved, which tradeoffs were made for what?

   - A.

Le Vendredi 12 Mai 2006 09:54, Todd Blanchard a écrit :
It is clear that Smalltalk-80 had more than 10 years of advance in the late
70's. But since these glorious days, what major invention came from Smalltalk
UI? I mean something so marvelous that it is copied by challengers...

If you try to mimic the OS native interface, it's only a defensive strategy,
by construction something imperfect and always one version late...
You're wasting development forces to follow the leaders, and don't invent
anymore in this domain...
As already said, emulated feel is worse than emulated look... And i think this
is what is annoying your clients if they have to switch often with native UI.

That is why Dolphin looks a little better than VW: it does not emulate, it
plugs native interface... But Dolphin doesn't care of unix world. That's
something harder to get a common UI on several platforms so that we keep
image portability... Such tentatives often lead to more restricted look and
feel. With these constraints, VW is not a bad trade of after all...

On the other hand, i do not see much killing apps having the oldies ST-80
look. Squeak has kept its freedom, but so far, this did not lead us very
high... It is just a banner, a proof that Smalltalk is something different...

Finally the good side is that, in Smalltalk, we have the possibility to
emulate, plug native, or keep our own UI.
We have a problem of rich persons: choice!
That's also because we lost UI leadership in the 80's, that's a fact.
And I would like to be wrong...

Nicolas

Michael Latta wrote:

>The point is not who's design is better, nor technical issues.  The point is
>that from a user of the system the differences in libraries has negative
>value.  I do not know or care which is better.  I do know that if I could
>take Smalltalk code form one VM to another the market for my work would be
>larger.  The way each VM vendor has chosen to head in their own direction
>means that they do not build a viable ecosystem.  Each vendor's product
>stands alone, and has to build its own ecosystem.
>
The problem with this comparison is that it is treating Smalltalk as a
programming language.
It's much easier if you treat it like an operating system or a SQL
database - it's a platform.

In theory, your C program should just run on HP-UX, Linux, AIX, Windows,
MacOSX, RiscOS, AmigaOS, ...
Why did all those operating system vendors invent incompatible system
calls, libraries, file system conventions?

Or why can't you just take your SQL application from ORACLE to MySQL or
Sybase?
After all, SQL is a standard!

I don't know enough about SQL, but at least in the operating system
world you can achieve a lot of portability by sticking to POSIX which is
supported on most platforms.
Similarly, you get pretty good portability in Smalltalk by sticking to
the ANSI Smalltalk subset.
Of course, GUI widgets etc. are not included in that standard and so are
non-portable.
But does POSIX include standard GUI widgets? Can you write a GUI
application in C and port it from Linux to Windows without a lot of work?

I agree with you that it would be great to have easier portability
between the different Smalltalk systems, so you could switch platforms
when needed without too much work.
But in reality, switching between platforms has never been easy.
Actually, the closest thing to effortless platform migration was/is
*Smalltalk* with its image file which can be run unchanged on a large
number of platforms! I've done it with VisualWorks, Squeak and
VisualAge. The two Smalltalk-80 descendants provide much easier
migration (just snapshot your image and start up on another machine) but
VisualAge is pretty doable as well as long as you're willing to work
around the quirks of the different native widgets under OS/2, Windows
and Unix/X.

Cheers,
Hans-Martin