Traits or not Traits that is the question

Recently, there are voices from many sides, saying that Traits is
show-stopper and should be retained from future squeak versions.
I'd like to hear an arguments of both sides.

Personally, what i think, Traits have good potential, but sadly there
is lack of support of them in current dev tools, what in own turn,
returns us to discussion about improving dev tools to meet
requirements :)

--
Best regards,
Igor Stasenko AKA sig.

thanks igor, really.
but frankly I do not have the energy anymore.
Normally when I argued with people I could be mad at them but I always  
respect them.
Now I start to feel that would not control myself when arguing with  
some people and start really
bashing them for the sake of it. I'm not part of this community for  
this kind of attitude.
If people wants to follow the people that successfully did 3.10 they  
should go (you know in france we have
sarkozy so somehwere we deserve it - sadly).
If a system does not have a feedback loop this is not a viable system.  
Again I'm not saying that the process
of 3.9 was good: we asked for help and got nearly none after people  
criticized that we took decisions.
Of course we did because we were responsible of not breaking the system.
I'm not saying that we were great for 3.9:
        - the use of mc killed the cool update stream, however we tried for  
real to see
        - pushing traits in the core was certainly an error but so far I  
would like to know
        real examples where people got problems with, especially for merging  
packages of sophie, olpc and croquet
         (the master of adrian is available and all
        the information is there. It should be one of the best documented  
part of squeak).

But again that someone remove traits. I have no problem, I did my job  
and I think that we did well.
Now if people believe that traits are the problems, they are of course.
I can tell you that I will ***never** maintain Squeak anymore and I'm  
really thinking about what I will do.
Because I think that I did a lot for smalltalk in general the last 10  
years and may be this is the time
to do something else to get a large breath of fresh air.

Stef



On Feb 3, 2008, at 1:59 PM, Igor Stasenko wrote:

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

Michael van der Gulik wrote:
>
> Could anybody who is actually *using* traits please raise their hand?
>

There are two examples that I'm aware about. One is the class kernel in
Squeak and the other one is Nile (http://squeaksource.com/Nile.html)
which is a stream library using traits. You can find my analysis of Nile
here:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119295.html

The last paragraph basically sums up the "big picture problems" with traits.

Cheers,
   - Andreas

And, if is easy to extract from the image, and convert it to a  
package. Why don't do it, and all happy?

If you want Traits, load a package and voilá. If you don't want  
Traits, don't install it.

Only my impression.

El 03/02/2008, a las 13:59, Igor Stasenko escribió:

Giuseppe Luigi Punzi Ruiz a écrit :
> And, if is easy to extract from the image, and convert it to a package.
> Why don't do it, and all happy?
>
> If you want Traits, load a package and voilá. If you don't want Traits,
> don't install it.
>
> Only my impression.
>

Because modifying Class and Metaclass is quite a tricky game. It's like
cutting the branch you are seating upon.

Both adding or removing Traits is NOT trivial.

But yeah, on the principle, you are right, that could be

Nicolas.

On Sunday 03 February 2008 20:47, Michael van der Gulik wrote: me!
It's especially a very interesting tool when you are refactoring (but not
only).

Three things:
-One of the very important things while refactoring is to detect and reduce
code duplication. Traits are then very useful because you can efficiently try
new code distribution without changing your classes organization.
I can understand that people are not using traits while implementing new  
developments. Maybe it's because class thinking is then much more important.
Maybe it's because people simply don't try to use traits. Maybe it's because
traits are young.

But, after a while, when you have numerous users, when a lot of clients are
using your component it is very difficult to reorganize your own classes in
order to reduce code duplication. Is'nt it one of the big difficulty of
squeak image refactoring ?

-Maybe a new design without traits is better than a new design with traits.
But it has a cost. Less good design are very often preferred because of money
and time limitation. I think here traits can be very useful again by avoiding
code duplication at less cost than with a pure OO design and with much more
better style than with simple code duplication.

-Another advantage of traits is two clearly indicate WHERE you have code
duplication and WHICH classes could be concerned by a deep refactoring.  
Who have a clear view of code duplication in basic standard squeak image?
Does it makes no sense to think that a good step for squeak image refactoring  
could be to reduce all code duplication with traits. A second step could be
traits refactoring and removing by class re-organization or new classes
introduction. But I'm not sure that all of them will be removed.

alain
 
> Gulik.

nicolas cellier a écrit :
>
> Because modifying Class and Metaclass is quite a tricky game. It's like
> cutting the branch you are seating upon.
>
to sit, I sat, sat, sitting
to sit, I sat, sat, sitting
...

From what I can tell so far, there's nothing stopping you from making a second class+metaclass kernel or hierarchy in the same image. The VM doesn't make any sanity checks, so an object could have any other object as a class provided that instvar 2 (? IIRC) is a sane method dictionary.

In other words, you can have traits and non-traits classes in the same image.

The limitations are in "Smalltalk specialObjectsArray" and another array (which I can't remember the name of) which stores 5-bit indexes to commonly used classes. The classes in these arrays are used by the VM and need to be shared by all your individual metaclass hierarchies.

Gulik.

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

2008/2/3, Michael van der Gulik <[hidden email]>:
/me raises hand

And I have use for stateful traits too.

Philippe

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

On Sun, 03 Feb 2008 20:47:19 +0100, Michael van der Gulik wrote:

me. it's excellent for keeping different roles apart, even if one's  
traitified methods are not re-used in any other class :)

If someone wants/does redo traits for Squeak: when they are stateless (as  
they are now), one sometimes wants to apply them to the class side, but  
that's not possible after they have been defined for the instance side  
(and the same vice versa).

BTW: stateless traits can easily be simulated (with zero performance  
overhead) in a traits-free system: define the traitified methods in a  
separate class structure (which has no variables); from there the  
single-source can be compiled into any other class (using a small script).  
Of course, automated tool support for composition etc would be superior :)

/Klaus

> Gulik.
>
>
>

Although they are research projects, we are doing three things with Traits:
1) Refactorings to go from classes to traits and vice versa
2) Reimplementing the Collection hierarchy
3) SmallLint for Traits

We are not using Traits in our production environment because VisualAge and GemStone don't have them.
My opinion is that even if we finally realize that Traits are a great tool (we are not sure yet, aren't we?), it is going to take some time for it to catch up. Changes in a mature system like Smalltalk take time, much more time in a diverse community like Squeak.
So, if traits do not bother, just give them a try, let other people play with them and see if they work. I think we will not loose too much doing so, but we could loose more not doing it.

Bye,
Hernan.

stephane ducasse wrote:
> Now if people believe that traits are the problems, they are of course.
> I can tell you that I will ***never** maintain Squeak anymore and I'm
> really thinking about what I will do.
> Because I think that I did a lot for smalltalk in general the last 10
> years and may be this is the time
> to do something else to get a large breath of fresh air.

Stéphane-

I sympathize. I think the biggest issue of Squeak is issues with modularity
and managing complexity. These issues translate to frustration for
maintainers (and users :-).

Anyway, I had related frustrations to yours many years ago and they are why
I ended up doing a lot in Python and Jython on the JVM in the last decade,
"Open source VW (was Re: Why FUD?)"
http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/3b3a67ab0ab756e0/6d08b70aa9f6aea1?lnk=st&q=&rnum=1&hl=en#6d08b70aa9f6aea1
  "[Edu-sig] Python & Smalltalk (was Re: OLPC related: pyGTK)"
  http://mail.python.org/pipermail/edu-sig/2006-December/007476.html
  "[Edu-sig] Freedom: some Smalltalk history and Python implications"
  http://www.mail-archive.com/edu-sig@.../msg02717.html
even to the point of working on PataPata.
    http://patapata.sourceforge.net/
That was a Squeak-ish thing on Python, now stalled as I hit fundamental
Python limits related to "Edit and continue" and also see the less desirable
aspects of prototype-based systems.
  " PataPata critique: the good, the bad, the ugly"
  http://patapata.sourceforge.net/critique.html

Now I am looking at mixing Jython, Scala, and the JVM. But I still miss the
Squeak ideals and the Smalltalk syntax. And Jython/Python as a community is
never (or not for a long while it seems) going to focus on stuff like
coding-in-the-debugger or restarting from where an exception is thrown.

Spoon is a good Squeak-ish try in the direction of managing complexity,
although I think building the image from source, like GNU Smalltalk does, is
ultimately a better idea.
  "[Help-smalltalk] Bootstrapping a Smalltalk image"
  http://lists.gnu.org/archive/html/help-smalltalk/2008-01/msg00129.html
But otherwise I think Spoon really has a lot of great ideas like remote
development from one image to another.
  http://www.netjam.org/spoon/

I think the most important single issue in maintaining any large system is
managing complexity (documenting intent maybe comes next, including
well-named variables and methods and functions). This has never been a
priority for Squeak IMHO.

There are several ways to manage complexity, which include:
* modularity (namespaces, packages like Java or GNU Smalltalk or Debian,
letting someone else do that hard work by leveraging libraries or VMs or
languages, like Squeak does by using a C compiler to generate the VM)
* cleverness (brilliant redesign, like traits was hopefully going to be)
* laissez faire, and also to each his or her own image (that is what we have
now, and it is not that bad an idea, if the *core* is small and well thought
out, like Spoon, so the *image* instance becomes the *module*. But alas, it
is not, witness how confusing Morphic is to unravel).

Modularity is the one way to manage complexity which seems to work best in
practice, although the others have their role. However, if Squeak images
could easily talk to each other and share some state, and we had Spoon-like
remote debugging and development, then we could have just one application
per image, and that would be easier to maintain (it would be modular to a
degree but in an unusual way). But I would still suggest such a system built
on well-though out (clever) modules would be more powerful and easier to use
than a mess of spaghetti code, even if we had only one application per image.

Personally, I think a rebuild of Squeak piece by piece, starting from
nothing, but drawing from clearly licensed code (like GST or parts of Squeak
or other systems), using a free license (MIT/BSD or LGPL) on top of the JVM
(not necessarily Java) as a baseline (but also being able to generate VM
with C as a less-supported alternative), perhaps using an intermediate
type-inferencing functional language like Scala (instead of C)
  http://www.scala-lang.org/
to define the VM, would be a great system. Fast. Flexible. Modular.
Extensible. Cross-platform everywhere Java runs (Mac, PC, GNU/Linux,
cellphones, supercomputers) while still open via generating C VMs to
everywhere else (OLPC). Leveraging a world of Java libraries across lots of
platforms, but still with a private VM in C for those times when people want
to run Squeak without the JVM or maybe want a little extra speed. Maybe use
the core GNU Smalltalk code instead of Squeak to get around licensing
worries, but then modify Squeak packages to run on top of that. Use Java
reflection to allow selectively sending either a *message* or a *call* to a
class depending whether it is Squeak-ish (implements processMessage:) or
Java-ish (see code below).

Anyway, that's a vision, but I don't have enough energy and time to pull it
off just by myself. The Squeak community could do it working together -- the
community knows enough and has enough person-power.  I don't see why it
would not take the community (say ten part-time developers or so) more than
a month or two to do, at least to the point where everyone else would want
to jump onboard. :-)

Yes I know there have been a few Java/JVM Smalltalks (including at least two
or three derived from Squeak). But maybe one with a clearer license might
help to push beyond that continuing contentious issue. Personally I can live
with the LGPL or even GPL for the VM, like GNU Smalltalk does, meaning I
personally would have no problems drawing from GNU Smalltalk for the core
(respecting the license). If the system is modular, GPL for the VM and LGPL
for the libraries really should not effect people very much in practice.
LGPL jar libraries for the JVM rarely pose a major problem with using the
JVM for proprietary applications if people worry about that. Personally, I
see such licensing in the *spirit* of the original Squeak license, to share
VM changes and share changes to the core libraries. And all the work done on
Squeak relicensing would pay off in bits and pieces as it could now be
clearer what parts could be added into a new Squeak.

I really would like it if people could see an Alan Kay demo and go and try
it themselves and keep going, rather than what I have seen happen in
practice which is things start blowing up pretty quickly for the average
newbie -- for mostly trivial-seeming (but really deep) reasons related to
complexity (like loading incompatible versions of various software or the VM).

For more on complexity, see for example my comments here seven or so years ago:
  "Belling the cat of complexity" Thu Jun 29 16:17:47 CEST 2000
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-June/001371.html
"Squeak complexity in 2.8 has become a complex cat from the simple kitten
complexity of 1.13(?) in 1996. Back then, Dan Ingalls wrote on 10 Nov
1996 those prescient words: "The Squeak team has an interest in doing
the world's simplest application construction framework, but I suspect
that we will get sucked up with enough other things that this won't
happen in the next two months (but who knows...)." "

For me, the biggest change since I wrote that is Java and the JVM becoming
truly free (well, almost, version seven will be the full change it is said)
and after a decade getting a lot of the bugs out of the core Java libraries
and the JVM. So it is finally a stable-enough and free-enough platform IMHO
to do some good work on. And to let someone else worry about a lot of low
level details and deployment testing (unless you really *want* to worry
about them by generating your own C VM, which you still could).

Or more recently I spoke to this concern here:
  http://mail.python.org/pipermail/edu-sig/2007-March/007822.html
"There is once again the common criticism leveled at Smalltalk of being
too self-contained. Compare this proposal with one that suggested making
tools that could be used like  telescope or a microscope for relating to
code packages in other languages -- to use them as best possible on
their own terms (or perhaps virtualized internally). Consider how the
proposal suggests scripting all the way down -- yet how are the
scripting tools built in Squeak? Certainly not with the scripting
language. And consider there are always barriers to any system -- where
you hit the OS, or CPU microcode, or proprietary hardware
specifications, or even unknowns in quantum physics, and so on. :-) So
every system has limits. But by pretending this one will not, this
project may miss out on the whole issue of interfacing to systems beyond
those limits in a coherent way. For example -- OpenGL works, and
represents an API that has matured over a quarter century, and is linked
with lots of hardware and software implementations; why not build on it
instead of "bitblt"?. Or consider how Jython can use Java Swing
libraries and other such Java libraries easily. Consider this example of
proposed failure: the proposal's decision to punt on printing -- no
focus there in difficulties of interfacing with a diversity of OS
services as a guest -- of relating to prior art. This is where Python
often shines as a system (language plus libraries plus community) -- and
Python is based on a different design philosophy or perhaps different
design ethic. Python has also prioritized "modularity" from the
beginning, which has made a lot of these issues more manageable; Kay's
proposal talks a lot about internal integration, but the word
"modularity" is not even in the document. In this sense, I think Kay's
group are repeating mistakes of the past and also dodging another very
difficult issue -- one that Python somehow has more-or-less gotten right
in its own way."

Some sample Java code to implement this selective dispatch, inspired in part
by Alan Kay's and Ian Piumarta's et al's new efforts:
  http://piumarta.com/software/cola/
  http://lambda-the-ultimate.org/node/2483
(hereby released into the Public Domain :-).

This code defines a "JMessageProcessorInterface", two classes (only one of
which implements the interface), and then a JMessages class which, based on
characteristics of the Java instance, either calls
"processMessage(JMessage)"  or uses reflection to dispatch the message as a
function call. There are probably better ways to do this at the byte-code
level or using a fancier functional intermediate language (like Scala).

public interface JMessageProcessorInterface {
        public Object processMessage(JMessage message);
}

==============

public class JMessageProcessorTest implements JMessageProcessorInterface {
        public Object processMessage(JMessage message) {
                System.out.println("Got a message");
                System.out.println("The message name was: ");
                System.out.println(message.messageName);
                return this;
        }

}

==================

public class JMessageProcessorTest2 {
        public Object foo() {
                System.out.println("foo: You sent no data. ");
                return this;
        }
       
        public Object bar(String data) {
                System.out.println("bar: You sent: " + data);
                return this;
        }
       
        public Object foo(String data) {
                System.out.println("foo: You sent some data: " + data);
                return this;
        }

}

============

public class JMessage {
        String messageName;
        Object sender;
        Object receiver;
        Object context;
        int parameterCount;
        Object parameters[];
       
        JMessage(String messageName, Object[] args) {
                this.messageName = messageName;
                this.parameters = args;
        }
}

====================

import java.lang.reflect.Method;
import java.lang.reflect.InvocationTargetException;

// References:
// http://java.sun.com/j2se/1.4.2/docs/api/java/lang/reflect/Method.html
// http://java.sun.com/docs/books/tutorial/reflect/member/methodInvocation.html

public class JMessages {

        /**
         * @param args
         */
        public static void main(String[] commandLineArgs) {
                System.out.println("JMessages starting...\n");
               
                // Dispatch to an object implementing a JMessageProcessorInterface interface
                System.out.println("Trying to dispatch to JMessageProcessorInterface");
                JMessageProcessorInterface messageProcessor = new JMessageProcessorTest();
                Object[] args = {"Hello world", };
                JMessage testMessage = new JMessage("foo", args);
                Object result;
                // next line is a more direct dispatching
                // result = messageProcessor.processMessage(testMessage);
                result = dispatchMessage(messageProcessor, testMessage);
                System.out.println("The result was: ");
                System.out.println(result);
               
                // now try to dispatch to a an object which does nto implement a
JMessageProcessorInterface interface
                System.out.println("\nTrying to dispatch to JMessageProcessorInterface");
                Object messageProcessor2 = new JMessageProcessorTest2();
                JMessage testMessage2 = new JMessage("foo", args);
                Object result2;
                // The following would result in a compile error of
processMessage(JMessage) undefined for Object
                // result2 = messageProcessor2.processMessage(testMessage2);
                result2 = dispatchMessage(messageProcessor2, testMessage2);
                System.out.println("The result was: ");
                System.out.println(result2);
               
        }
       
        public static Object dispatchMessage(Object receiver, JMessage theMessage) {
                Object result = null;
                if (receiver instanceof JMessageProcessorInterface) {
                        JMessageProcessorInterface messageProcessor =
(JMessageProcessorInterface)receiver;
                        result = messageProcessor.processMessage(theMessage);
                }
                else {
                        System.out.println("Cannot directly dispatch message");
                        // now do magic with Java reflection to see if can match message name
against a function name in the class
                        Class c = receiver.getClass();
                        Method[] allMethods = c.getDeclaredMethods();
                       
                        Method matchingMethod = null;
                       
                        // only finds first match with same name and same number of arguments
                        // does not look at argument types but should eventually
                        for (int i = 0; i < allMethods.length; i++) {
                                Method m = allMethods[i];
                                String methodName = m.getName();
                                System.out.println("The methodName was: " + methodName);
                                if (methodName == theMessage.messageName) {
                                        Class[] parameterTypes = m.getParameterTypes();
                                        for (int j = 0; j < parameterTypes.length; j++) {
                                                Class parameterClass = parameterTypes[j];
                                                System.out.println("  The paramter type was: " + parameterClass);
                                        }
                                        if (parameterTypes.length == theMessage.parameters.length) {
                                                matchingMethod = m;
                                                break;
                                        }
                                }
                        }
                       
                        System.out.println("invoking " +  matchingMethod.getName());
                        try {
                                matchingMethod.setAccessible(true);
                               
                                try {
                                        // does not look at argument types or try casts, but should eventually...
                                        result = matchingMethod.invoke(receiver, theMessage.parameters);
                                } catch (IllegalAccessException x) {
                                    x.printStackTrace();
                                }
                               
                            System.out.println("returned: " + result);

                        // Handle any exceptions thrown by method to be invoked.
                        } catch (InvocationTargetException x) {
                            Throwable cause = x.getCause();
                            System.out.println("invocation failed: " + matchingMethod.getName() +
" Cause:" +  cause.getMessage());
                        }
                       
                }
                return result;
        }

}

Anyway, probably back to lurking for a few more years, unless I hear a
groundswell of grassroots interest to "Burn Our Disk Packs". :-)
  http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_V.html

--Paul Fernhout

Hi Paul,

I agree with you, in my opinion, having Squeak/Smalltalk on a JVM is  
crucial.

Alexandre


On 4 Feb 2008, at 11:43, Paul D. Fernhout wrote:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Hi Alex,

on Mon, 04 Feb 2008 17:05:45 +0100, you wrote:

> Hi Paul,
>
> I agree with you, in my opinion, having Squeak/Smalltalk on a JVM is  
> crucial.

It *is* running on that VM, even has source code,

-  
http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-July/118649.html

/Klaus

As I said in my post: "Yes I know there have been a few Java/JVM Smalltalks
(including at least two or three derived from Squeak). But maybe one with a
clearer license might help to push beyond that continuing contentious
issue." I also brought up up other technology issues related to complexity
and rebuilding from scratch.

As impressive as it was for Dan Ingalls to make that version of Squeak, and
then Pavel to decompile the result into source, so what? What is the license
of it all (either origins or decompiled version)? How well factored is it?
Does it have nay hope to be supported by a community? Does it take advantage
of the Java/JVM platform, including threading and multi-processor support?
Or interoperate easily back and forth with Java libraries like Jython can?

Also, that version is (to my understanding) defining its own objects, not
using Java/JVM's objects, so there is a performances hit as well as other
layers of complexity and interoperability issues (the reason I included that
dispatching code example in Java, which is a different approach than the
usual Squeak VM) I think there might be overall benefits from using Java/JVM
objects but with a Squeak-like dispatching system for Squeak defined code
that was not compiled down to native code (like via translation to
Scala/JVM). Still, using Java/JVM objects is just one possible aspect of
such a system, and not essential to the value of such a thing (it makes
"become:" and proxying harder, while it makes other things much easier).

To me, that example just shows again everything wrong with the Squeak
development process and why it is so frustrating to deal with it -- an
undocumented decompiled hack stands in for "free"-ly-licensed modular robust
software -- and eclipses the possibility of something better. :-)
Squeak's great success is its own worst enemy in that respect. :-)

Other comments by me on Smalltalk on the JVM here:
  http://www.mail-archive.com/help-smalltalk@.../msg00796.html
  http://www.mail-archive.com/help-smalltalk@.../msg00803.html
(although now I am leaning to Scala as an intermediate language above the
JVM instead of Kawa).

--Paul Fernhout

Klaus D. Witzel wrote:
> It *is* running on that VM, even has source code,
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-July/118649.html

Hi Paul,

on Mon, 04 Feb 2008 23:44:38 +0100, you wrote:

> To me, that example just shows again everything wrong with the Squeak
> development process and why it is so frustrating to deal with it -- an
> undocumented decompiled hack stands in for "free"-ly-licensed modular  
> robust software

Interesting. To what do you compare, what's the "free"-ly-licensed modular  
robust software?

/Klaus

Klaus D. Witzel wrote:
>> To me, that example just shows again everything wrong with the Squeak
>> development process and why it is so frustrating to deal with it -- an
>> undocumented decompiled hack stands in for "free"-ly-licensed modular
>> robust software
>
> Interesting. To what do you compare, what's the "free"-ly-licensed
> modular robust software?

Take, for example, Python or MzScheme. Both of these have a much cleaner
separation of what is in the core and what is in libraries. Python
especially has endless libraries, MzScheme not so much.
  http://planet.plt-scheme.org/

For beginners (or experts) they don't confront you with a ball of sticks and
mud, requiring you to be an expert's expert to disentangle the whole thing
and keep the complexity under control (if such was even possible -- Spoon
goes a long way in that direction though).

Both have their own issues of course. The underlying Python C implementation
(and also Jython's Java implementation) have messy parts (Jython
especially). But you generally never have to think about them much. You
don't like the CPython GUI library, use another -- without much fuss.

MzScheme and relations like DrScheme rely (last I looked, several years ago)
on a hacked up version of wxWindows for cross-platform graphics that was
getting harder to maintain.

Nonetheless, above those layers, both strive for modularity.

The JVM (in earlier non-Sun free versions, and now Sun's) supports
modularity in terms of libraries. It has its bugs, and Java is a cumbersome
language, but modular JAR files save the day and people do robust enterprise
work with it with many people on projects (of course, you need many people
since Java itself is a fairly unproductive language, unless you can find the
right prebuilt library, which you often can)..

The whole related set of C modules that support many applications tends to
be modular -- it has to be otherwise your C application would crash like a
pile of sticks since C code can be so brittle. Objective-C is an improvement
in that regard.

Nonetheless, each also has weaknesses. Who wants to program in C (or even
Objective-C) if there are more productive alternatives, especially with
integrated development environments? CPython wasn't designed with "edit and
continue" in mind and has trouble restarting exceptions. MzScheme is, well,
Scheme, which has both great points and bad points about it.

Smalltalk strikes a nice balance -- a loss of language complexity and
terseness (no macros) at a big win of more understandable code and great
tools in a super environment as a creativity amplifier. But I have never
felt as at-home or as confident writing with Squeak as when I wrote stuff
with, say VisualWorks+ENVY (though that is not free, so I stopped using it
seriously ten years ago, and ENVY has since gone to the bitbucket).

As another example, Scala for the JVM was designed with modularity and
scalability in mind. Personally, I prefer more dynamic languages like
Smalltalk for making most (or all) of an application, but for writing a VM
Scala is probably more fun than C or Java, and maybe even in some ways a
better choice than writing restricted type-implicit code in Smalltalk.

Then there is also Ruby, of course. Still getting there though, as a
Smalltalk with C-ish syntax. :-)

In short, most of Squeak's competitors for developer time have better
support for modularity. They have to be since in general they are weaker
systems or less productive systems or less introspective systems. A
Smalltalk environment by default allows handling more complexity than, say,
Java code under Eclipse,. But does that productivity boost mean we should
blow all the extra benefits by maintaining overly complex unmodular code and
still arguing (ten years later!) about how to properly strip mainstream
release images full of stuff (with or without Traits, and so on) and how to
reconcile all the different lines of development out there which differ on
mostly trivial things?

Squeak also deviates from other Smalltalks sometimes for no good reason. A
dozen years later you still can't use underscore as easily as in most other
Smalltalks because underscore is still overloaded as the assignment symbol.
I wrote something to convert my image to use underscores about ten years
ago, but it got lost in the relentless upgrade to new images (I use
underscores in simulations to let me tag methods and variables with units,
as in "rainfall_mmPerDay"). What does this weird use of underscore really
get anyone? And that's just one of multiple idiosyncrasies (which maybe were
pioneering once upon a time but now just confusing for no value).

Anyway being on the JVM is just one aspect of starting over as a
possibility. One would move step-by-step and add modules to bootstrap up
something like Spoon, move beyond it, and then hope the community finds it
worthwhile to expand it. Perhaps support ANSI Smalltalk as a minimum (with a
regular underscore), with other things possible on top of it in different
namespaces. Maybe write some code conversion tools to import old-style
Squeak-ish code down the road.

Alan Kay has several times talked (even at its release) of Squeak being just
as a stepping stone to something better. It is the Squeak community and
Squeak ideals that are the biggest assets -- not the code.

--Paul Fernhout

>>>>> "Paul" == Paul D Fernhout <[hidden email]> writes:

Paul> Squeak also deviates from other Smalltalks sometimes for no good
Paul> reason. A dozen years later you still can't use underscore as easily as
Paul> in most other Smalltalks because underscore is still overloaded as the
Paul> assignment symbol. [...]  What does this weird use of underscore really
Paul> get anyone?

Ahh, you kids, forgetting your roots.  We greybeards understand that "_" is
actually the left arrow in the original fonts for the Xerox Parc Smalltalk80
Release 2 image, from which Squeak is derived (via Apple and Disney and a cast
of thousands).  That it now looks like "_" is merely an artifact of applying a
modern meaning for slot 95 in the ASCII table.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!