Ship it with Squeak
giovanni.giorgi at mlab.disco.unimib.it
Tue Jun 27 07:23:02 UTC 2000
Paul Fernhout wrote:
> Thanks for the great comments. Just what I want to hear!
> (Not that I'd not want to hear disagreements.)
I'd like to promise I can help you about your idea, but
I have no much time in this moment, and so I cannot :(
But If we find some pepole interested in doing a Developement o deployment kit
for Squeak, I will try to help you in my free weekends!!
I think a stable subset of Squeak library would help a lot "newbie" too.
>More than anything, a deployment kit would create some
> additional clarity in Squeak by trying to modularize parts of it.
>Stephan Rudlof had a similar one in his strategy for
> basing less stable libraries only on more stable ones. As he points out,
> we also need to differentiate between the interface stability and the
> implementation stability.
This is an hard point.
VisualWorks has a "parcel" concept which is not so simple and with a bit of
The parcels can used for deploy new code into a running image, but
conflits can arise easily: if two parcels re-define the same
object or method in different ways, you will have a problem when do you want
"unistall" one of them in different order and so on.
****I think the modularisation must be resolved in conjunction with the
NameSpace problem. If we draw a good NameSpace environment, we can use it for
Namespace and interfaces are important for a collaborative developement as
And interface are best used with a bit of NameSpace***
> > For example, I do not know how mucch Morphic is stable and usable for a true
> > commercial product.
> I'm wondering how stable Morphic is in terms of:
> * internal APIs
> * implementation within those APIS.
> Would people who know for 2.8 have any comments?
> If I write Morphic widgets, is it likely they will run on next year's
This is a big question.
Morphic structure is a little safe because a lot of the interface is exposed in
the Morphic Base object.
Only a crazy man will modify that interface, destroying all the widget working
> Problem is if I say six months, my wife (& business partner) probably
> won't let me do it. It's a stretch as it is. It's really got to fit in
> four or less -- even if that means cutting stuff.
> The question is, what can I cut and what can't I cut? And what can I
> leverage for a Squeak deployment toolkit that others are working on or
> willing to support?
I think you can use the basic Morphic engine, and try to use only the widget
provided. If you are carefully you can speed up your porting.
If you need of a new widget, design it carefully so it is open, and can be
Read <http://coweb.cc.gatech.edu/squeakbook/21> about extreme programming in
Squeak: you will need it.
> > I will not be upset, but a SourceForge project with a different mailing list is
> > the best idea :)
> Good point. My major concerns are that the SourceForge project would
> start with zero traffic and then people would have to check two lists.
> And also, much of the (deployment) issues will be relevant to the main
> distribution. But it makes sense not to clutter the list with details on
> deployment in general if there is a lot of traffic about it.
> Isn't there already a Squeak SourceForge project by the way?
Yes, it's SqueakNOS.
I think you can solve legal problems in Squeak for a commercial product.
Squeak is a open-source-like project (it is not GNU, but open source is good
[snip about my fews difficulties....]
> Could you detail those difficulties?
> What would make it easier?
(I ask to the squeak-list to comment my idea here, thank you!!)
First, tutorials and documentation should be a lot more.
The book of Mark Guzdial,
"Squeak: Object-Oriented Design with Multimedia Applications"
(http://coweb.cc.gatech.edu/cs2340/8) is a dream, but it is not sufficient.
Second, Squeak has not a stable library in all its parts.
I take for example a my small application.
When Squeak 2.7 came out, I must fix some small problems I do not have in
I use an instance variable called "array" (a bad name, I apologize myself) in a
In Squeak 2.8 someone add a instance variable array in a superclass, and so my
code cannot be filed-in for a "redefinition" error.
It was easy to fix but if you develop a big application for Squeak 2.6 it
will likely not work in Squeak 3.0...too differences!!
If we can mantain old interfaces for compatibility (using for example namespace
and so on) I think we will have less problems.
Third, we do not have javadoc-like system: altrough it will be easy to add it
because of the hypertext documentation system (very good, a dream!!).
I have builded a small application called AutoDoc which will generate the
documentation of a set of class, but not the comments for every method and so
on (only comment class, hyperlink to superlcasses and so on).
I think I forget a lot of things, but one is not-missed: Smalltalk ide, Browser
and method finder are a fantastic resource for debugging and developing (and
the new private methods are a good evolution of Smalltalk towards information
> > If I will have (dream!) a semi-professional kit, a lot of my bugs will be
> > discoveredy early!!
> I'd like that too.
> I realized that "professional development" and "deployment" are two
> different issues.
> I'd love to have professional development tools for Squeak (better
> version control, better native code compiler, refactoring browser, good
> documentation, etc.).
> But I'm realizing what I can't live without as a commercial developer is
> deployment -- and related stability.
This is true.
We need of a more "BSD-like" idea of Squeak image, with a focus on young
developer, who know only Java and (uh!) VisualBasic.
About multiplatform developement. network and filesystem differences must be
tested across the three major platform (Unix, Win,Mac).
You can have the same problem in Java, in my experience.
> By now many people practically think Java originated the virtual
> machine, the cross-platform GUI, garbage collection, and maybe MVC too
> given Swing. This is true in much the same way many people now think
> Bill Gates invented personal computing (instead of Doug Engelbart, Alan
> Kay, J.R. Licklider, and others).
I agree with you.
I think in the next five years someone will "discover" the code-block-as-object
in Smalltalk, the iterator as a language extension (Java has a similar thing
And finally, someone will say "dynamic languages are slower than statically
typed languages, but are simpler and less error prone..."
> I like your Squeak buzzwords though. It would be amusing to see a glitzy
> marketing web page for Squeak that used terms like that.
We must only choos the "right words" and the right logos: Smalltalk can be the
future and must be free.
// Giovanni "Daitan" Giorgi
// Assibit S.r.l.
//mailto: giorgi_g at geocities.com GSM: +39-(0)347-30-76-419
More information about the Squeak-dev