[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-smalltalk] GNU vs. Squeak vs. VW
Paul D. Fernhout
Re: [Help-smalltalk] GNU vs. Squeak vs. VW
Sat, 14 Jul 2007 09:17:25 -0400
Icedove 220.127.116.11 (X11/20070607)
I feel the same sort of frustrations with using Smalltalk to develop
free (or commercial) software. All the Smalltalks have various issues --
just different ones. It is very frustrating.
Squeak has licensing issues and is not modular, but it is very
cross-platform and has a big community. GST is modular and well
licensed, but can be difficult to install and has a small community and
the GUI is incomplete and not very complete or cross-platform (things
continue to improve off course). VisualWorks is modular and very
cross-platform but it isn't free-as-in-freedom (or even
free-to-distribute-commercial as in buy it once). VW also lost ENVY
which I liked. OTI had a great embedded Smalltalk but it is very
proprietary. Dolphin is windows only and not free-as-in-freedom.
Smalltalk/X has a sort-of-free license but not quite IIRC, and no
history as a free software community. The Java Smalltalks are orphaned
for the most part and incomplete (but cross-platform and mostly free,
except for the Squeak-derived ones which suffer from the Squeak
Because of their communities, it seems to me that GST and Squeak are the
major players if you want a free platform going forward.
You can see my comments on Squeak when I was active on the Squeak-dev
list, say here:
"Belling the cat of complexity (was: Ship it with Squeak)"
That was one reason I experimented with creating "Embedded Squeak"
(which was a headless Squeak, like GNU Smalltalk in some ways) though
that code is so old don't use it. :-)
You can see an example of my frustration with the Squeak licensing here:
Even though they are (many years) trying to fix it now, I still question
if they are getting a proper copyright assignment from *Disney* which
has a copyright statement in the code. But I can hope.
Beyond the licensing issue, here are other related links on Squeak
issues from around 2000:
>From that middle link:
"I'm sorry if I keep coming across as a broken record in most of my
posts to the list over the past few years. A major thrust of what I say
is always the same (perhaps becoming clearer over time as other people
To become a serious platform, Squeak needs:
* to be modular (namespaces, buildable image, maybe inter-VM/"object
* to have at least one stable, easy to use, lockable, scalable GUI,
* to be event driven, and
* to interface easily with the outside world of code.
I wanted to fix the Squeak issues and was willing to put time into them
(way back when) but the community just wasn't focused on fixing the
deeper issues of modularity or licensing -- in general the responses on
that topic were very discouraging -- and without fixing the license, the
changes might be worthless, and without fixing modularity, they would
likely or not just have been lost. In some ways I think Squeak killed
Smalltalk more than Java:
"Bambi Meets Godzilla: I watched Smalltalk die."
because Squeak was exciting and had the big names attached to it, but it
also had this fundamental licensing problem which prevented any real
progress or diversification as either "open source" or "free" software.
I think if the licensing issues finally get cleaned up, we may see some
real progress there. Alan Kay himself says he wants to be a
Smalltalk/Squeak slayer and get something better -- but the Squeak
community doesn't seem to understand or accept this; when ever I
proposed doing things in that direction, it never went down well.
Which leaves only GST as a Smalltalk with a truly free license and
somewhat of a community. I'm not sure how much of installability would
be fixed by just having a bigger community for more testing -- I suspect
it would somewhat (though the build process still seems overly
convoluted). The other specific issues can be fixed, as Paolo says, and
he seems willing to integrate back in the changes.
I've wandered around the idea of rolling my own Smalltalk on Java,
perhaps drawing from GST. But that was not straightforward because GST
has (forgive me) some excessive internal complexity in how it defines
itself which it was not easy to see how to map onto Java. I still think
it is a good idea to have a Smalltalk that runs well on Java though --
ideally one that, like Python, runs on Java and runs on C.
One possibility I have wondered about is the possibility of a
Squeak-like GUI core for GST as an alternative to TK, where essentially
you have one or more framebuffers (as windows) with event loops (GUI
events) and draw emulated widgets. Then, as with Squeak, the only
cross-platform stuff needed is a thin layer of a few hundred lines of C
code to interface with bitmap windows on various OS's -- and that part
could likely be borrowed from Squeak under some licensing arrangement,
or at the very least, one can look at Squeak to see how the base
interface to the OS is done (all that stuff except for the original old
Mac GUI primitives in Squeak was contributed so direct relicensing is
possible too). That's probably a few person-weeks of work at least to
get one platform up like, say, GNU/Linux -- most of it making the basic
widgets -- the actual platform specific code is probably only a day or
two. I think that could be a big win for GST, to bring in some of the
Squeak ideas onto its more solid base.
But I always get distracted then by wanting prototypes (like in Self)...
Although I am perhaps moving past that phase:
In practice, in the past I've ended up using Python for lots of various
reasons (licensing, libraries, easy syntax to sell to C++ or Java shops,
Jython-Java integration, etc.). It also has always been free, which I
think has direct implications in the type of community around it, see
for example my comments on that here:
"Python & Smalltalk (was Re: OLPC related: pyGTK)"
But I still miss the Smalltalk syntax which I think is still the best
ever developed for the kind of way I generally want to write software.
And the Python community simply does not get the value of "edit and
continue" like coding in the debugger or why Python should be altered to
do that, see for example:
"More OLPC chatter (PataPata; Edit&Continue)"
That lack of "Edit and continue" brings down my productivity in Python
compared to a good Smalltalk by a factor of three I guess. If there is
one community and version of Smalltalk that has the potential to be more
like Python, I would think it is probably GST more than any other one IMHO.
When/if I ever get some spare cycles again though, I'm hoping to revisit
the Smalltalk issue. If I could rewind time, I think it might have been
better to have invested the time and emotion I put into Squeak and
Python and Jython into improving GST (but drawing on ideas from Squeak
and Python and Jython on Self). But I can't, so I'm stuck with things
the way they are for now. :-)
- [Help-smalltalk] GNU vs. Squeak vs. VW, Bill Schwab, 2007/07/10
- Re: [Help-smalltalk] GNU vs. Squeak vs. VW, Paolo Bonzini, 2007/07/10
- Re: [Help-smalltalk] GNU vs. Squeak vs. VW, Stephen Compall, 2007/07/11
- Re: [Help-smalltalk] GNU vs. Squeak vs. VW,
Paul D. Fernhout <=
- Re: [Help-smalltalk] GNU vs. Squeak vs. VW, Frank Sergeant, 2007/07/18
- Re: [Help-smalltalk] GNU vs. Squeak vs. VW, Mark Aufflick, 2007/07/18
- Re: [Help-smalltalk] GNU vs. Squeak vs. VW, Stephen Compall, 2007/07/18
- [Help-smalltalk] Re: GNU vs. Squeak vs. VW, Paolo Bonzini, 2007/07/20
- [Help-smalltalk] Re: GNU vs. Squeak vs. VW, Stephen Compall, 2007/07/20
- Re: [Help-smalltalk] Re: GNU vs. Squeak vs. VW, Paolo Bonzini, 2007/07/20