links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Interview Andreas Raab 2005
Last updated at 5:34 pm UTC on 10 February 2019
The original version of this interview is archived here:

SqueakViews: an interview with Andreas Raab

Welcome back to SqueakViews, the column in which we interview the Squeak hackers and developers. In this second installment, Giovanni Giorgi has met (by e-mail) Andreas Raab, Tweak mantainer and the author of the first Squeak port ever.

GG: First of all, please share a little about yourself and your background. Where are you from, your studies and your current job.

AR: I'm from Germany, studied at the University of Magdeburg and did my PhD there. Afterwards ('98) I went to work with Alan at Disney until we left Disney. I returned to Germany ('01) and together with Michael Rueger and Maic Masuch founded Impara there. In '04 I joined Hewlett Packard and I'm still there (despite rumors otherwise).

GG: About your recent works: Tweak seems the most cool thing out of there you are working on. Can you introduce us to Tweak's basic ideas?

AR: The base idea behind Tweak is simple: Combine the best of Morphic with the best of MVC. Morphic is a wonderful architecture as far as direct manipulation is involved but it's a terrible architecture to build reusable systems. Morphic simply doesn't have any abstractions and that makes it very hard to build re-usable and flexible components. BTW, it's not impossible to build reusable components it's just very hard because the architecture itself doesn't help with it (it's like writing secure code in C - yes it is possible to do it but it is very hard).
MVC, on the other hand, has some excellent properties as far as abstraction is concerned. Because MVC is a "viewing architecture" it encourages a better separation of concerns between the (domain) model and the (graphical) view. Unfortunately, that's where MVC stops. It doesn't allow you to use the same principles for building views itself - once you get to the views things get messy since there is no abstraction any more (e.g., it's not "turtles all the way down").
Tweak approaches this problem by combining the best of the two. It is as directly accessible as Morphic and it provides a viewing architecture similar to MVC. It achieves that by having one "primary view" that we call an object's "costume" which is responsible for handling all of the graphical requests sent to the object. That's what makes it possible for a user to think of "just using an object" whereas, in reality, you are actually always interacting with a pair of player (model) and costume (view). And contrary to MVC you don't have to worry about creating views for every object - you can start out straightforwardly just like in Morphic, but when the time comes there is an architecture that will allow you to build generalizations from the concrete object.
Another key idea in Tweak is that of asynchronous event handling. Unfortunately I can't say I invented that (though at the time where I came up with the idea I wasn't aware of anybody else doing it) but it turns out that this is what is now typically referred to as "event-loop concurrency". The idea here is that all responses to events are asynchronous messages, e.g., are executed some time after the event has been signaled. The reason this is important is that by using asynchronous events you do not expose internally inconsistent state to a listener. When you use synchronous events (callbacks) you end up with
the problem that the listener (inadvertently or not) may request temporarily inconsistent state or otherwise violates the invariants of the computation (like raising an exception). A good (or rather bad) example is the system notification mechanism in Squeak - it allows listeners to interfere during the compilation process with unclear results what might happen if there is any problem. In Tweak this simply cannot happen - you get to execute your code only when the computation that signaled the event is completed. There are actually many other reasons why asynchronous events and event-loop concurrency generally are
a good idea (check it out here).
I also think that we've made some major usability advances by using method annotations for method triggers (e.g., events triggering methods). They look like here:

     "Handle a mouseDown event"
     <on: mouseDown>

     "Handle the button's click event"
     <on: click in: button>

and are displayed with icons in the latest versions of the Tweak-enabled browser. Being able to see what event triggers a method is a major advantage to the way things are done today.
Tweak also allows a little more "centralized control" for making simple graphical objects. What this means is that I always envied the fact that other systems (VisualBasic for example) get away with a single place to do all their stuff as long as they don't get too complex. For example, in VB you start out with a simple form that you design and then you write some event responses for it. For the simple things you never leave that form, it's exactly like programming in a procedural language "inside the object" (yes, VB uses objects these days).
The reason I like this is because it avoids needless context switching, it's one of these simple things that really ought to be simple. Compare this with Morphic - at the least you have to write some initialization
 aMorph when: #mouseDown send: #onMouseDown to: self
in a separate method and often this won't work because many Morph's implement the event responses improperly (even some of the Morphic tutorials teach broken techniques by avoiding the appropriate "super" invokations).

And of course, if you want to change the initialization you need to destroy the old and create a new object which feels very much like a "compile, link, run" cycle to me.

In Tweak, you use an event with the
annotation, which cannot be improperly overwritten and which is recognized so your objects on the screen will react to the changed annotation in real-time.
Using events in this way avoids having to poke around in other objects and enables us to have a relatively well-understood centralized component to deal with the integration aspects of your various UI elements.

GG: Tweak is essentially a replacement of Morphic. I was a young student(!) in the old 1997 when Morphic wasn't even the default Squeak GUI. Now I have seen Morphic at work, and the first question arise is: why invent another GUI? Morphic doesn't seem to me yet finished but it works very well for basic purpose. We haven't a full GUI Builder for it, so changing it seems to me a bit "danger", isn't it?

AR: First of all, I do like Morphic. And I like MVC, too. And one might have argued like you are doing back in '97 (MVC wasn't finished either in Squeak!) when Morphic was introduced.
The point of switching from MVC to Morphic was to get a more lively user interface framework. And that worked beautifully. But at the same time, we lost some things that were wonderful about MVC (clear abstractions, viewing ...) And it's time to get them back without giving up the good things from Morphic. The best and easiest way to do that is to introduce a viewing architecture like in Tweak. And from there, Tweak is simply the logical consequence of MVC and Morphic.
Talking about switching to Tweak, I have been very careful not to make any promises (or threats). The fact of the matter is that people will decide for themselves what they want to use. I'm neither in a position to decide for you nor do I want to be in that position. You'll switch when you are ready and not before (perhaps never). Remember, there is actually a community of people using MVC in Squeak and they seem to be quite happy.

GG: About the other projects you are on, what is the most focused one, excluding Tweak?

AR: Most of my time I'm actually spending on Croquet. That does include time spent on Tweak btw (Tweak is but one part of Croquet).

GG: On the Squeak 3.9 release plan I read also about the "Post-3.9" plans to have full 64bit support on Squeak4.0 which would break compatibility with the 3.9 stream.

AR: Squeak 4.0 would. The 64bit changes wouldn't.

GG: I have read on the mailing list in the past month a lot about it but I don't feel 64bit a true priority now. Why is 64bit so important in your own opinion?

AR: I think it's as important as being able to run Squeak on any other major platform - the overall market share of 64bit systems is surely not going to decline.

GG: Changing architecture is important, but I think we should be more focused on exploring new ideas and move the 64bit-porting in the Squeak 4.2 or even beyond. What do you think?

AR: I hardly think in terms of "we should", since in reality there isn't much of a point to that. "We should" do lots of things but only a fraction of those will get done and if you ask me which ones you might as well flip a coin. I simply don't know.

GG: What are the plan for the future (not only limited to the current projects)?

AR:There's lots of stuff on my plate right now but the key pieces are Croquet and Tweak. We're also involved in the hundred dollar laptop project but that's a different issue alltogether.