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 

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 




Java Session Fancy Printing

    public static final String convertToString(HttpServletRequest request) {
        StringBuffer msg = new StringBuffer();
        try {

            msg.append("*RequestURI:" + request.getRequestURI() + "\n");
            msg.append("*ContentType:" + request.getContentType() + "\n");

            msg.append("== Request Header\n");
            Enumeration headers = request.getHeaderNames();
            while (headers.hasMoreElements()) {
                String headerName = "" + headers.nextElement();
                msg.append(headerName + ":" + request.getHeader(headerName) + "\n");
            Enumeration attr = request.getParameterNames();          
            ArrayList l = new ArrayList();
            String att;
            while (attr.hasMoreElements()) {
                att = (String) attr.nextElement();
                l.add(att + " -> " + request.getParameter(att));
            msg.append("=== Request ( " + l.size() + " ) ===\n");
            Object a[] = l.toArray();
            for (int i = 0; i < a.length; i++) {
                msg.append((String) a[i]);
            msg.append("===   ===   ===\n");
            // Process the Session
            HttpSession session = request.getSession();
            // msg.append("\n");
            Enumeration e = session.getAttributeNames();
            TreeMap t = new TreeMap();
            String k;
            while (e.hasMoreElements()) {
                k = (String) e.nextElement();
                Object oggetto;
                try {
                    oggetto = session.getAttribute(k);
                } catch (Throwable notSerializableException) {
                    oggetto = "NON DESERIALIZZABILE. Chiave:" + k;
                t.put(k, oggetto);
            Object orderedKeys[] = t.keySet().toArray();
            msg.append("=== Session  ( " + orderedKeys.length + " " + (usertempz != null ? "+ 1UT" : " NO UT!") + " )===\n");
            Object elem;

            for (int i = 0; i < orderedKeys.length; i++) {
                elem = t.get(orderedKeys[i]);

                msg.append("\t-> ");
                if (elem != null) {
                    nicePrintSessionObj(msg, elem);
                } else {
            return msg.toString();
        } catch (RuntimeException e) {
            return msg + "\nERR: Cannot print session/request!!" + e.getMessage();



Celeste is a mail reading and organizing program. The name “Celeste” is a reference to an earlier mail reader named Baba, which was written at Xerox PARC by Steve Putz and John Maloney.

Nowadays, Celeste is maintained by Giovanni Giorgi (me).

Latest Feature

A new revision is planned for the end of September 2006, and code name will be “Sonic”.
Sonic will include a smart mailing-list filter and a better “leave message on server” option.
I implemented years ago an auto-filtering system in AppleScript.
The filtering engine used the
RFC2369 and some other tricks to detect yahoo mailing list.
Sonic will have also an auto-filter for google mailing list too.

The leave message on server option is quite bad now. It creates a lot
of duplicated messages.
The new implementation will avoid dowloading twice a message, using
a mix of messageId and timestamp to detect duplicated messages.

Version policy

I have found a misleading versions for celeste.
Celeste uses a “versionString” to mark a version in every sent email.
versionString labelled something like

As far as I started mantaining Celeste, we used a lower version (for example 1.23).

To avoid confusion I have started to renmbering all the stuff starting from revision 3.0.

Anyway, the version name is the first thing you should consider. I plan to do very few releases.

Celeste Auto Filter Capability (BETA)

Some busy users subscribe and unsubscribe to a lot of mailing list.
Managing them with filter is possibile, but can be done only by hand.
Worst, email programs tend to be very slow if a single folder is full of stuff,
and this can be true for Celeste too.

The Celeste Auto Filter option will enable a smart archiving system,
packing the email in seasons.
For instance “2006Q1-squeak-dev” will contain all the emails of squeak-dev of the first three month of 2006 (=the first quarter).

The Auto Filter will understand YahooGroups, Mailman and GoogleGroups mailing list, auto-dispatching them to the right category.
The filter will be enabled by default.


You can find released versions on SqueakMap and development versions on SqueakSource.

Old resources: