Traits or not Traits that is the question

>(Isn't it a true nuisance that, instead of caring about software and
>complaining about and fixing bugs, we end up having to care about
>legal stuff and complaining about and fixing licensing issues these
>days?)
>
>> How well factored is it?
>
>It's very nice code, and nicely modularised into just 8 classes and 1
>interface: the Squeak interface defines constants. The Main and
>Starter classes are wrappers to get everything running. Then there are
>SqueakVM and SqueakPrimitiveHandler for execution, Screen and BitBlt
>for displaying, and SqueakImage and SqueakObject for representing
>living things.
>
>> Does it have nay hope to be supported by a community?
>
>See above. Since it's not officially released, it's a problem. I'd be
>in that community, for sure.

> > Does it take advantage of the Java/JVM platform, including threading and multi-processor support?
>
>No; apart from garbage collection, it does not take advantage of the
>JVM platform.
>
>> Or interoperate easily back and forth with Java libraries like Jython can?
>
>That is not supported, but should be possible through primitives.
>Object conversion may be challenging, though.
>
>> 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
>
>You are right there. Then again, the difference for objects is larger
>for Java and Squeak than for Java and Groovy - the latter's objects
>are deliberately Java objects, and the entire object model of Groovy
>has been designed with the Java object model in mind. SqueakOnJava is
>"just" a Squeak implementation on top of the JVM, with an approach as
>simple as possible.
>
>> To me, that example just shows again everything wrong with the Squeak
>> development process and why it is so frustrating to deal with it
>
>I really would not put it that way. I don't believe SqueakOnJava was
>intended to be the next big thing in Squeak progress; I rather believe
>it was a case study, or a feasibility study. In other words,
>SqueakOnJava, as I see it, is simply not part of the "Squeak
>development process" (whatever that may be).

>> And yes, in a new Squeak, backarrow assign should be the first thing to be
>> removed from the default image IMHO. :-)
>>
>> --Paul Fernhout
>>
>>  
> Dear Paul,
>
> you are ranting.
>
> The reason this has not happened is that people are busy.  I have been
> wanting to do this for two years and just havent had time.
> Since squeak is open source, if you want something doing... you are as
> much invited to improve things as anyone else is.
>
> In the time you have spent writing your long emails you could have
> tweaked the parser to enable underscores in methods and variables, AND
> still have it available for assignment. Some packages like
> Poststress/Gloop already make similar tweaks.
>
> Since you care about it so much, I look forward to seeing what you come
> up with
>
> cheers
>
> Keith

> Keith-
>
> As I pointed out, I wrote such code for Squeak ten or so years ago.  
> The
> problem isn't making the change. The problem isn't people being too  
> "busy"
> to put a few lines of code in the mainstream image changing a few  
> classes
> and then running a script while having lunch. If it was, in  
> sometime over
> the course of *ten years* someone would have found a few minutes to  
> remove a
> needless incompatibility Squeak has with just about every other  
> dialect of
> Smalltalk in the universe -- this strange us of underscore perhaps the
> single biggest syntactic reason you can't easily exchange code with  
> other
> Smalltalks.
>
> IMHO the issue includes the process and community norms whereby  
> such changes
> get adopted and mainstreamed to remove a *pointless*  
> incompatibility with
> the rest of the world (while still leaving it open to experts to do  
> things
> differently). And I use the underscore issue as an *example*; it's  
> just one
> of many. Namespaces was another big one. Stuff like a left click  
> brings up a
> menu lots of times is another (just plain bad GUI design by any modern
> standard of expectations for 99% of people, with there being  
> practically
> zero benefit to doing things the current way, if anyone can easily  
> even
> *explain* how it works consistently).
>
> I'm all for diversity. The problem is, to have a vibrant free software
> community, you want diversity more at the edges than the core.  
> That's what
> Python has. Or what C has. And if you have diversity at the core,  
> you want
> some way to manage it well (like Igor suggests).
>
> It is my hope a redesign on a common platform, leveraging that  
> standard,
> might push Squeak in positive new directions. I've already spent
> person-months coding that from another direction, trying to make  
> Python more
> Squeak-like (which it its own limits).
>
> While I've long been interested in this issue (new versions of  
> Squeak) I
> started this topic in response to a major maintainer and Squeak  
> contributor
> and booster and Squeak foundation board member saying some really  
> tough
> things to hear.
>
> Again, he said: "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."
>
> I am putting on the table what I think is a big set of issues  
> (complexity
> management) and one possible solution (a rebuild from scratch),  
> thought of
> course there are others (what Igor proposes with loading multiple  
> versions
> of code will likely be the future, and to an extent Les Tyrrell's  
> OASIS
> worked in that direction).
>
> Over the last dozen or so years, I've seen lots of changes fall by the
> wayside with Squeak. Lots of questionable stuff get frozen.  
> Although I'll
> freely admit I am not longer a current Squeak user for pretty much  
> five
> years or so (beyond fooling with it now and then every few new  
> releases,
> usually giving up after a couple of crashes when I stress test it  
> and it
> falls over).
>
> In general, I don't think it is productive on open source / free  
> software
> mailing lists to say "if you want X, do it yourself". The reason  
> for that is
> that feedback from users who do testing and even potential users is  
> often
> very useful in thinking about the evolution of a system -- and not  
> all users
> or potential users have the same level of skill or available time or
> commitment to do something. This is where that line of response can  
> lead IMHO:
>   "Mitch Kapor's Weekend at Bernie's [How Chandler wnet wrong]"
> http://whydoeseverythingsuck.com/2008/01/mitch-kapors-weekend-at- 
> bernies.html
> "The Chandler interface design lead responded. Because I don't want  
> this to
> be personal I will refer to her as DL. DL responded to that  
> statement with
> the following: "Thank you Hank for articulating this. I think this  
> may be at
> the core of issues you are running into. [Note: *its my* issue] ...  
> Think of
> it this way. If you have a tool and you can't predict what the  
> behavior of
> that tool will be, it will *never* be useful. ... And so I issued a
> challenge to the entire OSAF team. I challenged anyone to explain  
> to me what
> the "View" menu did. No takers. It's so complicated even the designers
> couldn't explain it. ... If you let the fact that no one could  
> explain a
> core menu bar function sink in, you might get a clue as to why,  
> despite what
> had to be 10 to 20 million dollars of Mitch's money invested, Chandler
> still, well, sucked."
>
> Now Squeak isn't in that position overall, but *areas* of it are,  
> IMHO. And
> these are often the first areas a Squeak newbie encounters. And a  
> big part
> of that is in relation to not focusing on taming complexity IMHO.  
> And that's
> the reason someone like that board member is so frustrated IMHO.  
> And I'm not
> convinced those problems can be fixed by submitting a few patches.  
> For a few
> reasons, including, one key person who is/was taking in such  
> patches is
> talking about throwing in the towel over how that process isn't  
> working out.
>
> Anyway, I did post some code (but in Java). :-) And it was written  
> months
> ago towards such an effort.
>
> All the best.
>
> And by the way, how would you feel if when you posted "I just  
> discovered on
> Mac OS X 10.5 Leopard that the unix vm (3.9-8/3.9-10) uses  
> leopards  X11
> support rather than the quartz interface." or "When using the latest
> XML-Support/YAXO with universes it is sending the image into an
> un-interruptible state when it tries to parse the xml returned form  
> the
> server." someone replies that you were ranting and just fix it  
> yourself?
>
> Frankly, I wish I *was* ranting, and I could fix it just by  
> myself. :-)
>
> --Paul Fernhout
>
> Keith Hodges wrote:
>>> And yes, in a new Squeak, backarrow assign should be the first  
>>> thing to be
>>> removed from the default image IMHO. :-)
>>>
>>> --Paul Fernhout
>>>
>>>
>> Dear Paul,
>>
>> you are ranting.
>>
>> The reason this has not happened is that people are busy.  I have  
>> been
>> wanting to do this for two years and just havent had time.
>> Since squeak is open source, if you want something doing... you  
>> are as
>> much invited to improve things as anyone else is.
>>
>> In the time you have spent writing your long emails you could have
>> tweaked the parser to enable underscores in methods and variables,  
>> AND
>> still have it available for assignment. Some packages like
>> Poststress/Gloop already make similar tweaks.
>>
>> Since you care about it so much, I look forward to seeing what you  
>> come
>> up with
>>
>> cheers
>>
>> Keith
>

> I feel a little out of place commenting, as I am even less than a newbie
> when it comes to Squeak/Smalltalk.  In fact, I've only started Squeak a few
> times, poked around, and closed it in disgust and/or utter-confusion after
> a time due to the overwhelming complexity (and, IMO, ugliness) of the UI
> that hits like a brick to the face when first starting an image.
>
> So why am I here and why do I care?  I love the core principals of
> Smallktalk (and Seaside!) so much that I've been subscribed to the list for
> awhile just reading and watching and waiting for some sign of... I dunno...
> social growth?

> Hi Dan
>
>>> I'm actually nearly done with this process.  I'm in a ridiculous
>>> discussion about the name.  I had proposed JSqueak and got
>>> "push-back", as they say, from the trademark folks.  It appears
>>> that, if I'm willing to call it 'Idaho' or 'Potato' or something,
>>> then we're good to go.  It's clear Sun is happy to let it go and I
>>> am too.
>
> Excellent. So the problem is squeak in the name? Call it Zork or a
> bean eating animal like Squirrel and we get done.
>
> Stef
>
>

>> 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?
>
> I haven't looked at deeply, but I strongly suspect that no interaction
> is actually possible with Java.
>
> I am currently working on this.
> http://bergel.eu/athena for more info

> The "processMessage" function is essentially an elaboration of the  
> code I
> posted at the beginning of this thread. It knows how to look at the  
> proxy
> and decide how to send the message to it. There are at least three
> dispatching cases for a message. If the proxied object is a plain Java
> object, a function gets called if one matches the message pattern.  
> If the
> Java object has a "processMessage" method, it gets called. If the  
> object is
> a Java/JVM class "SmalltalkInstance" class instance, then Smalltalk-
> ish
> dispatching happens, and the message can also be used as a stack  
> frame item.
> (This merging messages and stack frames is a departure from typical
> implementations and implies a big performance hit.)

> For design simplicity and run-time extensibility, that  
> "SmalltalkInstance"
> class might have a few fields even if they were not usually all  
> used. They
> might be:
> * class (usually a reference to another "SmalltalkInstance")
> * dictionary of instance variables (not an array since I don't want to
> bother for recompiles in keeping things up to date, and for  
> debugging we can
> have symbols as selectors not indexes)

> Calling into Smalltalk from Java I haven't thought through. I know  
> Jython
> does it but I have not looked at that. I suspect you could  
> intercept an
> exception and do something. I'm assuming exceptions could go up the  
> message
> stack, but I admit that throwing them across intervening Java  
> function calls
> within the method stack could be problematical -- the message stack  
> might
> need to be annotated somehow in those cases before calling the  
> function,
> another performance hit.

>
> Bergel, Alexandre wrote:
>>> 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?
>>
>> I haven't looked at deeply, but I strongly suspect that no  
>> interaction
>> is actually possible with Java.
>>
>> I am currently working on this.
>> http://bergel.eu/athena for more info
>
>