[self-interest] Self vs. Squeak

[Michael Latta]

On Jun 24, 2004, at 2:27 AM, Friedrich Dominicus wrote:

> Michael Latta <lattam at mac.com> writes:
>
>> I am still getting to know both environments after a long absence from
>> Smalltalk doing Java projects.
>>
>> I am trying to compare the two environments from several angles to
>> decide which is a better jumping off point.
>>
>> Here is what I have observed so far:
>>
>> 1) I like the Self language better, if it only had full blocks.  But,
>> both are far better than Java or C++!!!
> What is missing in Self? I do not understand why you do not see the
> self stuff as full blocks.

Self does not support non-LIFO blocks.  You can not create a block and 
use that block after the creating method exits.

In many cases this is not an issue, and in many more (where the block 
does not reference enclosing context) it could be implemented
in the current VM but is not.

The stated work-around (and it is just that) is to use an object 
created in-line.  While the object can act like a block, the user is 
forced to decide:
"Can I use a block here?", when they should not care.  The LIFO block 
and the block that does not reference context could be optimizations on 
the general case,
and the general case would force the call stack to be objectized on 
method exit.

>> 2) Squeak has a much more active community that can provide
>> support/help/ideas.
>> 3) Squeak is far larger in terms of libraries.
>> 4) Squeak runs on Windows ( an advantage for comercial projects ).
> Well that all could be changed, you are right of course.
>
> But what I'm missing about Squeak is kind of realy good
> introduction. My experiences to understand he Morpic stuff were
> frightening....

They both lack good documentation on the implementation for sure.

>>
>> What I could use comments about from anyone that has used both
>> environments:
>>
>> 1) How stable are the two environments?  While I had several stability
>> issues with Self at the beginning, they seem to be gone now.
> Well did not get Self either on Mac OS X and Linux running
> properly....
>
> At least the base squeak system runs very nicely on Windows, Linux and
> Mac OS X
>
>> 2) How hard is each VM to modify?  Neither seems to have much if any
>> comments!  (bad programmers, bad programmers :-)
> There exist some documentationa about the Squeak stuff out there..
>> 3) The graphics model in Squeak seems to be a reasonable graphics 
>> model
>> (transforms, etc), but being all in Smalltalk how does it perform?
> Well you can try it IMHO it's ok.
>
>>
>> I started a company that built one of the first commercial Smalltalk
>> applications (still an active product) in 1986, so I know it can be
>> done.  The issue today is higher expectations on the part of the 
>> users,
>> and far faster hardware.  While the hardware should make using
>> Smalltalk / Self easier, the graphics requirements seem to do just the
>> opposite.  A large Java project I am working on is far slower than our
>> Smalltalk app was in 1986 on a Mac II !!!
> Don't you think this unfair? What does you Java do today and what did
> your Smalltalk app back in the late 80ies?
>
> I propose you send us some timings to back up this claims.

My point exactly is that it is unfair.  The expectations of users keep 
getting higher, and software
keeps getting more bloated (the OS in this case).  Now we have TrueType 
fonts that look great but take
about 3000% longer to render, we have graphics hardware that is faster 
than the CPU but only really used
in games.

What it takes to launch a successful product or platform these days is 
a lot more work than it used to be.  What I am
trying to decide is whether Self or Squeak can be the basis for one or 
both of these.

>
>>
>> There apparently is a Java to native code compiler for GCC that
>> produces much better performance than the current VMs, has this
>> approach been attempted for Self or Smalltalk along the lines of
>> Objective-C?
> Sorry I do not buy the superior gcc based solution. If you really do
> heavy C++ programming I would bet Java and C# are not much worth than
> G++. Well I have no figures at hand, but:
> http://www.findinglisp.com/papers/case_study_java_lisp_dns.html
> http://page.mi.fu-berlin.de/~prechelt/Biblio/
> http://www.flownet.com/gat/papers/

The Mac Java mailing list had cited figures that showed the compiler 
output about 2x the HotSpot performance.  Unfortunately the GCC 
solution does not have AWT support as of yet.
But, with Java having declared types I would expect a good static 
compiler to do quite well.  Of course this declared typing cause a host 
of other problems (coupling between types and users of the types, 
coupling of the methods and types, and maintenance nightmares when you 
need to change an existing API that is in use).  And since casting is 
used heavily to treat objects as other interfaces, the strong typing 
does not provide the reliability guarantee it is supposed to provide.

>
> Sorry that is just about Java/Lisp/Scripting languages.
> Feel free to flame me on that.
>
>
>
>
>> Or, are blocks and GC really the performance issues in the
>> equation?
> Why do always tools for higher productivity like GC and closures aka
> blocks be blaimed for any performance shortcoming. What about the
> choosen algorithms, what about the many abstraction layers and and and

Having spent the last 5 years on a large Java project, yes algorithm or 
design changes can impact performance far more than
language choice.  But, language performance does make a difference.  
Using Objective-C I can get 2x the frame rate of Java quite reliably 
even
though the Apple Java2D library calls the Objective-C library for basic 
graphics operations.

The comments about blocks and GC were specifically because Objective-C 
does not have blocks, and uses a different memory management model.

>
> Regards
> Friedrich
>
> ----------
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>