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++!!! 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 ).
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. 2) How hard is each VM to modify? Neither seems to have much if any comments! (bad programmers, bad programmers :-) 3) The graphics model in Squeak seems to be a reasonable graphics model (transforms, etc), but being all in Smalltalk how does it perform? 4) What is the relative performance of the two VMs for headless programming tasks, and for UI tasks?
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 !!!
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? Has anyone tried a Self/Smalltalk to Objective-C translator? Or, are blocks and GC really the performance issues in the equation?
Michael
Michael Latta lattam@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:
- 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.
- 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....
What I could use comments about from anyone that has used both environments:
- 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
- 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..
- 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.
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/
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
Regards Friedrich
----------
On Jun 24, 2004, at 2:27 AM, Friedrich Dominicus wrote:
Michael Latta lattam@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:
- 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.
- 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:
- 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
- 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..
- 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
On Wednesday 23 June 2004 20:59, Michael Latta wrote:
- I like the Self language better, if it only had full blocks. But,
both are far better than Java or C++!!!
As you mentioned in your other email, object literals can often be used in place of non-LIFO blocks. Given that the main use for these is to parameterize behavior in some variation of the Strategy Pattern, my experience is that using actual objects which can have more than one method is an improvement.
But I agree that it would be better not to have this implementation restriction (nothing in the language itself requires it).
See page 9 of http://www.merlintec.com/vmworkshop99/sub.pdf
- Squeak has a much more active community that can provide
support/help/ideas.
I had to decide between Self and Squeak for my project in 1997, and this was the major issue for me. The social aspect tend to dominate over the technical ones.
But I needed some non trivial changes and saw that the community could also be a problem in that a large portion of it was very conservative. There are several subgroups with very different goals. The SqueakLand people interested in stuff for schools (eToys, StarSqueak and so on). Traditional Smalltalkers who would like ANSI compatibility and native widgets. The web people (mostly servers and swiki).
While there was a "Squeak Central", radical changes were possible but very hard to get into the official Squeak. Now I would say it is just impossible. But if Squeak is already exactly as you need it, then this is not an issue.
- Squeak is far larger in terms of libraries.
Right, though the opposite was true in 1997.
- Squeak runs on Windows ( an advantage for comercial projects ).
There is a Windows port for Self (the Linux port+Cywin), but I have never tested it. Even if it doesn't quite work, I imagine it wouldn't be too hard to fix it. And you would have multiple native windows ;-)
And here we come to an issue you didn't mention - licenses. The Mac and Sparc Selfs have a simple, BSD-like license. The Linux and Windows ports are GPLed, which might be fatal for your project. The Squeak license gives rise to a bi-annual moby thread in the mailing list since Debian and the Open Source Initiative don't accept it. As Alan Kay always points out, nothing you do can prevent people from suing your. But that doesn't stop complaints that this makes Squeak unusable for commercial work. I don't agree with that, but you should judge for yourself.
- How stable are the two environments? While I had several
stability issues with Self at the beginning, they seem to be gone now.
I can easily crash Squeak in both Windows and Sparc Solaris. It doesn't happen in normal use, and doesn't seem to happen in Linux. The Squeak image serving my swiki pages has been running continously since 2000, for example.
I didn't understand why one of the goals of the StrongTalk project was to create "an industrial strength implementation of the Self technology". The Self VM itself has always felt very solid to me and looking at StrongTalk I don't see where it improved on that.
It is certainly possible to crash Self, and the Sparc version gives me the impression of being slightly more robust than the others. But I have done plenty of nasty things to it and had it just keep going.
- How hard is each VM to modify? Neither seems to have much if
any comments! (bad programmers, bad programmers :-)
In theory you get to modify the Squeak VM from within Squeak, while in Self you have to mess with C++ and gdb. But often the Squeak Interpreter has been broken in the past with several versions of Squeak being released before it was fixed. That tells me that in practice a different VM development style is being used now.
Depending on what you want to do, Squeak might be simpler to modify. You will probably be creating a fork, however, for as I mentioned above it is essentially impossible to get your changes into the "official" release. See the 3.3 modules effort, Flow, Stable Squeak, "a tale of two exception systems" and others for examples.
- The graphics model in Squeak seems to be a reasonable graphics
model (transforms, etc), but being all in Smalltalk how does it perform?
Squeak has 3 graphics models:
- warp bitblit - balloon - balloon 3D
All of them are written in Slang (a subset of Smalltalk-80) and were translated to C and then to machine language. And at least the last one supports hardware acceleration (OpenGL).
On top of that there are several GUIs:
- MVC - Morphic - OpenCroquet - PenTrails (for Disney PDA, not publicly available)
I think Scratch might have its own GUI, but am not sure.
- What is the relative performance of the two VMs for
headless programming tasks, and for UI tasks?
UI stuff seems slightly faster in Self on my 277MHz Ultra 5, but on the PC or Mac Squeak seems faster.
We would have to run some benchmarks for the headless stuff, but I would expect Self to win by a reasonable margin on platforms where it has the two compilers (Sparc and Mac).
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 !!!
Running an 8MHz 512KB Mac beside a 1GHz eMac is pretty interesting - the latter only seems about twice as fast.
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? Has anyone tried a Self/Smalltalk to Objective-C translator? Or, are blocks and GC really the performance issues in the equation?
A Smalltalk to Objective-C translator did exist a long time ago. I don't think translating Java to native code via GCC would be a good idea for real applications, though I imagine it would be great for simple benchmarks.
-- Jecel
Jecel,
Thanks for the comments. Your point about the Squeak community having multiple large vested interests seems true, and the license is very ambiguous.
That combined with my preference for the Self model is likely to push me in that direction.
Michael
On Jun 24, 2004, at 2:36 PM, Jecel Assumpcao Jr wrote:
On Wednesday 23 June 2004 20:59, Michael Latta wrote:
- I like the Self language better, if it only had full blocks. But,
both are far better than Java or C++!!!
As you mentioned in your other email, object literals can often be used in place of non-LIFO blocks. Given that the main use for these is to parameterize behavior in some variation of the Strategy Pattern, my experience is that using actual objects which can have more than one method is an improvement.
But I agree that it would be better not to have this implementation restriction (nothing in the language itself requires it).
See page 9 of http://www.merlintec.com/vmworkshop99/sub.pdf
- Squeak has a much more active community that can provide
support/help/ideas.
I had to decide between Self and Squeak for my project in 1997, and this was the major issue for me. The social aspect tend to dominate over the technical ones.
But I needed some non trivial changes and saw that the community could also be a problem in that a large portion of it was very conservative. There are several subgroups with very different goals. The SqueakLand people interested in stuff for schools (eToys, StarSqueak and so on). Traditional Smalltalkers who would like ANSI compatibility and native widgets. The web people (mostly servers and swiki).
While there was a "Squeak Central", radical changes were possible but very hard to get into the official Squeak. Now I would say it is just impossible. But if Squeak is already exactly as you need it, then this is not an issue.
- Squeak is far larger in terms of libraries.
Right, though the opposite was true in 1997.
- Squeak runs on Windows ( an advantage for comercial projects ).
There is a Windows port for Self (the Linux port+Cywin), but I have never tested it. Even if it doesn't quite work, I imagine it wouldn't be too hard to fix it. And you would have multiple native windows ;-)
And here we come to an issue you didn't mention - licenses. The Mac and Sparc Selfs have a simple, BSD-like license. The Linux and Windows ports are GPLed, which might be fatal for your project. The Squeak license gives rise to a bi-annual moby thread in the mailing list since Debian and the Open Source Initiative don't accept it. As Alan Kay always points out, nothing you do can prevent people from suing your. But that doesn't stop complaints that this makes Squeak unusable for commercial work. I don't agree with that, but you should judge for yourself.
- How stable are the two environments? While I had several
stability issues with Self at the beginning, they seem to be gone now.
I can easily crash Squeak in both Windows and Sparc Solaris. It doesn't happen in normal use, and doesn't seem to happen in Linux. The Squeak image serving my swiki pages has been running continously since 2000, for example.
I didn't understand why one of the goals of the StrongTalk project was to create "an industrial strength implementation of the Self technology". The Self VM itself has always felt very solid to me and looking at StrongTalk I don't see where it improved on that.
It is certainly possible to crash Self, and the Sparc version gives me the impression of being slightly more robust than the others. But I have done plenty of nasty things to it and had it just keep going.
- How hard is each VM to modify? Neither seems to have much if
any comments! (bad programmers, bad programmers :-)
In theory you get to modify the Squeak VM from within Squeak, while in Self you have to mess with C++ and gdb. But often the Squeak Interpreter has been broken in the past with several versions of Squeak being released before it was fixed. That tells me that in practice a different VM development style is being used now.
Depending on what you want to do, Squeak might be simpler to modify. You will probably be creating a fork, however, for as I mentioned above it is essentially impossible to get your changes into the "official" release. See the 3.3 modules effort, Flow, Stable Squeak, "a tale of two exception systems" and others for examples.
- The graphics model in Squeak seems to be a reasonable graphics
model (transforms, etc), but being all in Smalltalk how does it perform?
Squeak has 3 graphics models:
- warp bitblit
- balloon
- balloon 3D
All of them are written in Slang (a subset of Smalltalk-80) and were translated to C and then to machine language. And at least the last one supports hardware acceleration (OpenGL).
On top of that there are several GUIs:
- MVC
- Morphic
- OpenCroquet
- PenTrails (for Disney PDA, not publicly available)
I think Scratch might have its own GUI, but am not sure.
- What is the relative performance of the two VMs for
headless programming tasks, and for UI tasks?
UI stuff seems slightly faster in Self on my 277MHz Ultra 5, but on the PC or Mac Squeak seems faster.
We would have to run some benchmarks for the headless stuff, but I would expect Self to win by a reasonable margin on platforms where it has the two compilers (Sparc and Mac).
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 !!!
Running an 8MHz 512KB Mac beside a 1GHz eMac is pretty interesting - the latter only seems about twice as fast.
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? Has anyone tried a Self/Smalltalk to Objective-C translator? Or, are blocks and GC really the performance issues in the equation?
A Smalltalk to Objective-C translator did exist a long time ago. I don't think translating Java to native code via GCC would be a good idea for real applications, though I imagine it would be great for simple benchmarks.
-- Jecel
Yahoo! Groups Links
self-interest@lists.selflanguage.org
-
Friedrich Dominicus -
Jecel Assumpcao Jr -
Michael Latta