Actor oriented Programming

Besides having a new and more friendly layout for this blog - no black anymore ;-) - you will find a short presentation of mine about 'Actor oriented Programming'.



These slides have actually been created online at http://www.280slides.com - a great project powered by the amazing cappuccino framework, which allows non-web/non-flash programmers to create stunning rich web applications.

fabidoo

This was a very busy year and I forgot to post new blogs here for the most of the time.

The reason for being so busy was the founding of a new company called fabidoo.

fabidoo is all about making 3D printing available to the masses - which is a true pioneering work as the necessary technology is just at the beginning and requires a lot of work to fill the remaining gaps.

You might want to check out the results here, or take a look at the following widgets provided by fabidoo:





So much for now - let's see how long it will take until my next post.

Cheers
marc

Javas 2 lessons learned

I think Java taught us two important lessons in the IT landscape and was thus very helpful to bring forward the state of art in programming.
The lessons come from both a success and a failure of Java. Now, while most people will agree on the positive lesson learned many people might not have realized yet the negative one which is equally (or even more) important though.

Without doubt, Java was the language which established Garbage Collection in the mainstream. Before Java, Garbage Collection (GC) was not taken seriously by most programmers and languages with GC were brand-marked as academic niche languages unsuitable for real world applications.

This has changed radically. Today, no new language without GC would be able to succeed anymore, so this positive lesson of Java was learned quite quickly.

The negative lesson learned from Java - at least for me - is that making multithreading too easy is not a good thing to do. At my first contact with Java (in the mid 90s) I was fascinated how easy it was to create new threads and that the language offered keywords to create monitors - i.e. synchronized objects.

But this initial fascination quickly turned into deep objection as I gradually found myself thinking more about possible side effects done by concurrent threads than the business logic itself. What Garbage Collection has achieved - relief the programmer from thinking about memory management issues so that he can concentrate on the real problems again - was counter-achieved by multithreading.

With more insight on concurrency problems I found that most - if not all - of my own Java programs were flawed with respect to concurrency in one way or another. And maybe worse - most of any Java program I looked at are unsound too from a multithreading point of view.

The temptation to use multiple threads is increasing further with the advent of multi-core CPUs. But we humans are not especially good in thinking about the countless implications concurrency can have on our code.

To bring back productivity to programming we have to accept the lesson Java has taught us and prevent the easy creation of threads in future languages. How to utilize the power of multiple core CPUs in this case will be on of the hottest topics in the coming years.

Cheers

JavaScript 2.0 - ActionScript 3.0 - ECMAScript Edition 4

In a previous blog I praised the Scala programming language as the 21st century Scheme.

Since that time I got into contact with ActionScript 3.0 though and have to admit that the title for a 21st century Scheme (at least for the first decade of that century ;-) probably goes to JavaScript 2.0.

To cleanup a potential confusion here, both ActionScript and JavaScript are following the ECMAScript-262 standard and so are brothers if not geminies. The Edition 4 of ECMAScript is now the base for ActionScript 3.0 and JavaScript 2.0. Unfortunately Edition 4 is not finalized yet - neither is JavaScript 2.0 - but ActionScript 3.0 is already shipping. It seems that Adobe - the 'creators' of ActionScript - want to speed up the standardization process by taking some decisions on their own. Decisions which can take forever in a gremium - as many of you know by your own experiences.

JavaScript is one the the worlds most used programming languages as it works in nearly every browser out there. The great thing here is that it is a true functional language which I define as having closures. So, at the beginning of the 21st century one of the most used languages is a functional one and that really gives hope.

ActionScript3.0 (i.e. ECMAScript Edition 4) improves a lot on the previous versions and introduces packages and classes as familiar concepts:

* Packages allow to group names into APIs and prevent clashes between same names of different APIs.
* Classes allow an object orient programming style which is more in-line with what most people expect and know from other languages than the prototype based approach of previous ECMAScript Editions. The prototype mechanism is still there in Edition 4 but I expect that most people will switch to the class based concepts instead.

Other new features include optional type annotations (with algol like colon separated postfix syntax ;-) and properties (a.k.a. getter and setter functions).

Independent from Edition 4 is the E4X (ECMAScript for XML) standard which allows to structure and destructure XML within the language. Such a feature is invaluable in todays XML centric worlds and corresponds to the s-expr readers and writers of Scheme.

Missing from ActionScript3.0 is a pattern matching facility as in Scala or other functional languages like ML. But I could imagine that an Edition 5 could include this as the literal object notation '{}' of ECMAScript is beneficial for this task.
Finally, macros are missing but I expect that this could become a trend in the second decade of this century for several languages.

So, contrary to my previous believes the quest for a Scheme successor has not stopped and will go on and on.
JavaScript2.0 - ActionScript3.0 - ECMAScript Edition4 are good contenders though and really fun to program in.

The fun has just begun.

MVC - Revisited

The MVC pattern is easily the best known pattern around. What is interesting though is that everyone understands something different when refering to this pattern which indicates to me that there are concepts within the pattern which are not clearly delineated and have overloaded designations.

I think a key to a better understanding of this pattern is to abandon the too generic name 'Controller' and replace it by more succint names according to what the controller does.

In the classical Smalltalk MVC the Controller interpreted the input (mouse & keyboard) Event Stream and called upon both View and Model to make modifications. But with the advent of Widgets inside of a Window or Dialog, the role of the classical Controller somewhat degenerated into what I would like to call an EventHandler (a.k.a. Interactor).

The EventHandler collaborates with the View part of a Widget and converts the syntactical Event Stream into Semantical Events according to the geometry of the Widget. These Smantical Events are not realized by the Interactor though (i.e. the Interactor does not directly make changes on the Model or View) but he passes the Semantic Events in form of Actions to another instance - the ActionHandler.

The ActionHandler is now a different kind of 'Controller' who receives Actions from the Widgets and then calls upon the Model or View to carry out changes. It thus converts Actions into Commands where Commands reify the changes to be done on the View or Model. The execution of Commands might require user confirmations or the request of additional information from the user.

This latter aspect of requesting further user input might lead to the display of another Window or Dialog with its own ActionHandler. Instead of putting this Window transition logic into the ActionHandlers, a further 'Controller' breakdown consists of introducing an entity who controlls the staging of the separate Forms (i.e. Dialogs or Windows) of an Application - the StageHandler.

When a Command executes on the Model the classical MVC design builds upon a notification mechanism (the Observer pattern) to inform the View to update itself from the changed Model. In the Widget based MVC variant, the update of the View mainly consists of updating the Widgets of a Form. Instead of using notifications Commands are sometimes used to update first the Model and then the View (i.e. the Widgets) by pushing information into the Widgets. The Commands thus also fullfill an adapter role between the Model and the View, which might otherwise not be pluggable.

To allow pluggability between Model and View and thus to free the Commands from the 'manual' update of the View yet another 'Controller' is identified: The ModelAdapter. This ModelAdapter sits between both Model and View and handles interface adaptation, notification handling and the maintainance of Selections, so that the View operates on the intended subset of the Model. The Commands communicate with the ModelAdapter to set, change as well as read the Selections.

The domain knowledge is encoded in the Model. As this is mostly not only passive knowledge but also active behaviour, the Model can be separated into plain Data and an Engine 'Controller'. This Engine might apply 'physical' forces onto the Data and is independent from the GUI/Application layer above.

So, at the end, we exchanged the one classical Controller into the following 'Controller's:

• EventHandler: turns EventStreams into Actions
• ActionHandler: turns Actions into Commands and applies them
• StageHandler: controls the transition from one Form to another
• ModelAdapter: adapts Model and View and holds the Selection
• Engine: applies 'physical' forces to Data
  

I hope, the above can help in finding a common understanding of the MVC pattern for modern client side applications.

Cheers
marc

Scala

I am constantly looking for a modern version of Scheme to programm in.

Scheme is a wonderful functional language but I am badly missing OO capabilities right in the language. Besides, the missing of a standard library/module system keeps me from programming in that language as it locks me more or less into one Scheme provider.

Dylan was a highly interesting language as a Scheme successor but it had not chance against the raising Java wave at that time (which was around 1995).

Then there was Python and Ruby, but for some reason I don't like them - probably because too much hype goes with them.

I nearly lost my hope to find a modernized Scheme when I finally came across the Scala programming language.

Besides being rooted in the same principles as Scheme, Scala also offers:

• true object orientation (single inheritance + mixins)
• ML style pattern matching
• ML style type inference
• Erlang style support for Actor/Agent/P2P based programming
• XML construction and destruction syntax similar to /JWIG
• Platform independent as it targets the JVM

I think I finally have come to a rest on my quest for 21st centry Scheme.

Cheers
marc

Continuation based Web Server

Programming Web Applications is hard. This has to do with the stateless HTTP protocol and with the event driven nature of the human-computer interaction.

To regain control as in the old days of batch programming with straight-forward algorithms continuation based approaches seem to come to help.

For a nice introduction to the topic, please check out the following links:

1. Inverting back the inversion of control or,
   Continuations versus page-centric programming
   
2. The Influence of Browsers on Evaluators or,
   Continuations to Program Web Servers

To learn more about this topic I implemented a Continuation based Web Server in J2ME as explained below. J2ME seems to be very strange as a platform for Web Servers but I like it much for experimental work as it lets you focus on the underlying principles and not get distracted by too many options or libraries to choose from.

The idea was to reimplement the adder application mentioned in [1] in the Java (ME) context.

To decouple the control logic from the view details I added a further abstraction and programmed the logic against that abstraction:

public interface IO {
  void queryValue(String msg, StringCont cont);
  void inform(String msg, Runnable cont);
}

public interface StringCont {
  void cont(String val);
}

public class AdderMIDlet extends MIDlet {
  public void startApp() {
    IO io = new HTMLIO(); 
    startApp(io);
  }

  private void startApp(final IO io) {
    io.queryValue("Enter first value", new StringCont() {
      public void cont(String str) {
        try {
          double val = Double.parseDouble(str);
          addValue(io, val);
        }
        catch (Exception ex) {
          io.inform("Invalid input, try again", new Runnable() {
            public void run() {
              startApp(io);
            }
          });
        } 
      }
    });
  }

  private void addValue(final IO io, final double val1) {
    io.queryValue("Enter value to add to " + val1, new StringCont() {
      public void cont(String str) {
        try {
          double val2 = Double.parseDouble(str);
          double res = val1 + val2;
          io.inform("" + val1 + " + " + val2 + " = " + res, new Runnable() {
            public void run() {
              startApp(io);
            }
          });
        }
        catch (Exception ex) {
          io.inform("Invalid input, try again", new Runnable() {
            public void run() {
              addValue(io, val1);
            }
          });
        } 
      }
    });
  }
}

As can be seen, the control logic uses continuation passing style (CPS) to simulate continuations via closures. Closures themselves are present in Java in the form of anonymous inner classes, which do the job quite well though they are a bit verbose to write down.

The control aspects of the application are quite straight-forward with this approach and thus allow to concentrate on the logic in the normal and execptional cases.

The view (i.e. input and output) apects are hidden behind a clear interface and thus allow for separate modifications.

Now, let's shed a light on how the IO interface is implemented by the HTMLIO class. The two methods of the interface both have to do two separate things:

1. generate a page for presentation within a browser
   
2. extract input from a user and call the continuation with those arguments

The queryValue method thus looks like this:

  public void queryValue(String msg, final StringCont cont) {
    setHttpResponse(200);
    PrintStream ps = getResponseStream();
    ps.println("<html><body>");
    ps.println("<form method=\"get\" action=" + genQuotedUrl(new RequestHandler() {
      public void handle(Request req) {
        String val = req.getValue("input");
        cont.cont(val);
      }
    }) + ">");
    ps.println("<input type=\"text\" name=\"input\">");
    ps.println("<input type=\"submit\" value=\"Submit\">");
    ps.println("</body></html>");
    sendResponse();
  }

The inform is built the same way. The important function is the genQuotedUrl method which generates an URL and associates that url with a RequestHandler object which will be called when the URL is 'clicked-on' by the user.

The inner workings of our HTTP server now is simple: It waits for incomming connections on a server-socket (say port 8080) parses the request and looks up the registered RequestHandler object matching the request URL.

The matching is done by a simple Hashtable which maps URLs to RequestHandler objects. The question remains, when handlers have to be removed from this table again which influences the behaviour of the 'back' button, of window cloning and memory consumption. A simple approach is to use a timer based approach to this kind of garbage collection problem.

I hope, this simple J2ME based overview helps to understand the concept of Continuation based Web Servers.

cheers
marc