[self-interest] Self vs. Squeak
lattam at mac.com
Thu Jun 24 15:47:37 UTC 2004
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
>> 2) Squeak has a much more active community that can provide
>> 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
They both lack good documentation on the implementation for sure.
>> What I could use comments about from anyone that has used both
>> 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
> 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
>> (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
>> 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
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
> 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:
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
> 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
though the Apple Java2D library calls the Objective-C library for basic
The comments about blocks and GC were specifically because Objective-C
does not have blocks, and uses a different memory management model.
> Yahoo! Groups Links
More information about the Self-interest