Squeak 4.2 final now out! « The Weekly Squeak

Squeak4.2-10966.zip is now available at http://ftp.squeak.org/4.2. This is intended to be the actual-released 4.2 image, unless, as Chris Muller says, “we find some problem, which we won’t!”.

Squeak 4.2 final now out! « The Weekly Squeak.

We read on the startup:

A new virtual-machine, known as “Cog”, is about to be released for Squeak.  It’s a complete rewrite from the ground-up, employing a Context-to-Stack mapping design onto which a JIT compiler for Intel-compatible hardware results in, roughly, a 3X, across-the-board performance improvement.  Specific Benchmarks vary much more widely (from 1x to 5x, with some people claiming 10x for specifics.

Plus, latest squeak feature a Cleaned-up code base, refactoring and unification of Smalltalk and SmalltalkImage globals and much more! Give it a try!

Boosting Squeak: RockSolid images

As some of you know, I was a Smalltalk fan&developer in the last twelve years. I have stopped working on smalltalk years ago… anyway, I am happy to look forward the Squeak Smalltalk Community from time to time.

I republish here an original article posted by me on SqueakPeople, over 4 years ago.
The reason is simple: I am very happy to see a Squeak code fork called “Sapphire” which share most of my thoughts:

Sapphire wants to take a fresh look at the Smalltalk philosophy and current implementations. The idea is to produce high quality open-source packages that will be loadable on a micro kernel. 

 I will take a look to Sapphire, and you will find my throughts here in the next months.

Boosting Squeak: RockSolid images
Posted 30 Dec 2004 by jj
(Journeyer)

I have read the “rant” and “unrant” subject with a mix of uneasiness (embarrassment) and fear. The “Rant” thread began on the 15th of December 2004, and produced a lot of discussion. I will not summarize the thread, because a lot of people read it. Instead, I will go forward and try to find a pragmatic and constructive of helping the community (and yes, I am also very bold and handosome :) << ironic comment).

Part I: The “easy smalltalk”

I think the true problem faced by squeak is to boost harvesting and organize things so that the real problem will be the opposite: too many people fixing bugs :) The stronger danger is the feel of unstablility of squeak; I got some problems when trying to develop a small project in my spare time, forced not to update to the latest squeak because of incompatibilities and so on. On the opposite, mantaining Celeste requires me to be always up to date, and I will not be shocked if the beta release is a bit unstable: I need it!

So my needs change in respect of what I am doing.

On the other side, developing with a stable system is a pre-condition to leverage the community and helping the widley use of squeak in big project. In my opinion, if squeak users feel unstability as a problem, we will never go on without solving it. Decoupling the core release schedule from package release schedules would allow the package maintainers to work at their own pace. This is more or less how it is today. Though perhaps not clearly stated.

We must enforce all these ideas, so I have this proposal: We can have a very dynamic, and tiny “Base Squeak Image”. It will be depurated from all the libs with the exclusion of

   Kernel/Collections and so on   VMRebuilding (needed to generate the SqueakVM)   Mophic   Minimal Sound Support   Minimal Networking Support (only for updating it...)

The base image should be “naked” and only for developers: they can choose the tools to configure it. This could be the goal, the essence of the “Base Squeak Image”: light as a mouse, strong as a tiger :)

Then we can have a “Rock Solid” released about every two or four base Squeak releases. It will have a new version number but the “RS” letters at the end. For example:

 

  Squeak 4.0 RS  Squeak 4.1 (base)  Squeak 4.2 RS  Squeak 4.3 (base)  Squeak 4.4 (base)    Squeak 4.5 RS      <--- Example of delayed Rock Solid release

(Note: there will never be two release with the SAME number, to avoid confusion) The RS should have: a Release notes Workspace and some nice stuff for developing already installed. They will be very very similar to the current releases, at least with some more toys (like Celeste…).

Part II: How will we do it? The incremental step!!

I love the Part I because all seem easy: the trobule went when we JUST try to DO IT.

To obtain a such thing we need to restructure the actual community, and also to change our way of thinking squeaking? Someone said we have tons of things to get a grip on but we are more or less paralyzed unless we change the way the community is “steered”.

The Guides approach may need re-targeting and recalibration, but I will not face this problem now.

The process which brings us to the RockSolid idea will be incremental: let’s start with the actual base image, and start building the first Rock Solid on it.

We can have a Linus-like leader (RockSolid Man or R-Man :) which will do this hard job, asking support to Guides, for example.

We can choose a new R-Man for every RockSolid release, thous freeing it to have too much work on his/her shoulders.

A similar approach will bring to us a more clean evidence of problems, like abandoned code, lazy supporters, alone girls asking for an hero saving them and so on.

On the other side this approach will slow down things at minimum and reduce the “friendliness” of the community of a very very small portion. The squeak-dev mailinglist will have only a new [RS] tag on it.

In summary we have:

We need:

  1. R-Mans
  2. A bunch of SUnits code to build the RockSolid Image. This code will help us to speedup the process.
  3. Voting the above ideas.

The good (?) news is: I will give my work to let the thing born. I will help for emerging of a more vast and accepted way of organizing this thing. I know Squeak, the base kernel, and the collections (and my Italian DNA give me also a lot of good advantages with “alone girls” :)

If you like I can also be the first R-Man (it look like a very bold and handsome position :) << ironic comment).

Javascript and Smalltalk

There is a future for SmallTalk? I was a very strong fan of the SmallTalk language, but in the last five years I have seen more and more contraction of its usage in the IT field.

The OLPC project, which uses also Squeak Smalltalk and its done by the core team fo Squeak, is not going very well.

Anyway, Dan Ingalls, one of the father of Smalltalk, is working on a new project called Lively. It is a rewrite of Morphic in Javascript, especially target  for building a Squeak-like interface.

 The interesting part of this work is a paper outlining the limitation of javascript as programming language. I have tried in the past years to look for ajax and or web 2.0 javascript libraries, but I feel very difficult to develop with them.

From the Paper we underline these parts:

Loading multiple JavaScript applications into the same virtual machine is problematic.[…] For instance, if two programs
happen to use the same names for global variables or functions, the overlapping variables or functions of
the first program will be replaced with the corresponding features of the second program, resulting in
unexpected behavior in the subsequent execution of the first program. Since JavaScript will not typically
give any warning messages or errors in such situations, the resulting behavior can sometimes be a total
surprise; in many cases the errors resulting from such situations may not be discovered until much later.

 

Evolutionary development approach is a necessity. Due to the highly permissive, error-tolerant nature of
JavaScript, JavaScript programming requires an incremental, evolutionary software development
approach. Since errors are reported much later than usual, by the time an error is reported it is often
surprisingly difficult to pinpoint the original location of the error. Error detection is made harder by the
dynamic nature of JavaScript, for instance, by the possibility to change some of the system features on
the fly.

 

A lot of room is left in optimizing JavaScript performance. Current JavaScript virtual machines are
unnecessarily slow. Even though JavaScript is a significantly more dynamic language than, for instance,
the Java programming language, there is no fundamental reason for JavaScript VMs to run two orders of
magnitude slower than Java virtual machines.

 

Memory management capabilities of the current JavaScript VMs are poorly suited to large, long-running
applications. Current JavaScript virtual machines have simple, 1970's style garbage collectors

 The reason of these issue are simple:JavaScript was intially a language for web developers, small and easy to use, and very compact.
Absence of errors or warning is a nightmare, if you care of your digitating time.
And Javascript is slow because no one will write  long script with it.

A very compact and clean discussion can be found in http://javascript.crockford.com/javascript.html 

Fixing these problems is hard. Until the current  implementation will not provide a better way of error detection, writing javascript code will be a very long and time-consuming task.

And using a so old garbage collector, give a chance to a c/64 BasicV2 to beat your code:  you are awared, guys :)

Anyway, there is a good set of javascript libraries out of there (prototype and jquery, for instance but not only), so you should be quite happy 

 

 

 

Software Trends1

The trends of this october are about some upcoming products.
A clear analisys of QuarkXPress failure si sketched in roughlydrafted site.
I do not think the same consideration can be applied to Vista.

As Joel said, M$ can throw away much money before only starting to see its market reduced.

This lead me to the (hoped?) big fear of M$ for open source.
It is a dream, baby.

Open Source in Italy has success because of high costs of developement library.
When I tried to look for a commercial application to delivery some web graphic stuff, the prices was crazy.
The Open Source solution needed us only to buy a book(!).
Open source deliver a sufficient quality at low mantenance costs.
A smart developer in a 3-people team can set it up and deliver a small project.

If really M$, Sun, IBM’d start fear open source, they can cut their prices of 70% and all the drama will end quickly.

But the truth is Linux is not evloving: it is growing in the SysAdmin area only, popping out old dinosaurs like Sun Servers, replaced by cheap PC.
Sun Servers needs custom monitor and mouse (!) and their price is high compared to equally fast high-end pc.

The server segment is so over-priced that even Apple has succesfully proposed its over-priced servers (this is very fun!).

In the last five years I have seen no new on operating systems, or strong standard evolution.
EJB specs seems quite dead, hibernate is old, and the only “new” ideas are RubyOnRails and… PHP5.

On programming languages python seems growing well.

By the way there is much hypo on Ruby, but its base class library is very small compared to python or perl.

Ruby community is very well organized and can eventually bring Ruby to success, but for the meantime I see more success on PHP if you need a rock solid road.

Finally I have started to work on Squeak Smalltalk Weekly News, and I suggest you to look at it sometimes.