Sunday, February 22, 2009

Minimal Abstraction

Ask yourself: don't you often have the feeling that your brand-new 1024-core desktop SUV with 4 TB RAM and hard disk space beyond perception takes aeons to boot or to start up some application? (If the answer is no, come back after the next one or two OS updates or so.)

I don't want to rant about any particular operating system or application—the choice is far too big. Still, honestly, one thing I am often wondering about (and I guess I'm not all alone) is why modern software is so huge and yet feels so slow even on supposedly fast hardware.

All those endless gigabytes of software (static in terms of disk space consumption and dynamic in terms of memory consumption) and all those CPU cycles must be there for a purpose, right? And what is that purpose, if not to make me a, well, productive and hence happy user of the respective software? There must be something wrong with complexity under the hood.

During that conversation about Niklaus Wirth with my friend Michael Engel in Dortmund which got me started about computer science's tendency to regard its own history too little, and during which I had also mentioned my above suspicion, Michael pointed me to an article by Wirth, titled A Brief History of Software Engineering, which appeared in the IEEE Annals of the History of Computing in its 2008 July–September issue. This article contains a reference to another of Wirth's articles titled A Plea for Lean Software, which was published in IEEE Computer in February 1995.

The older article phrases just the problem I pointed out above, in better words than I could possibly use, and it did so more than a decade ago. So it's an old problem.

Here's a quotation of two "laws" that Wirth observes to be at work: "Software expands to fill the available memory. ... [It] is getting slower more rapidly than hardware becomes faster. ..." According to Wirth, their effect is that while software grows ever more complex (and thus slow), this is accepted because of advances in hardware technology, which avoid the performance problems' surfacing too much. The primary reason for software growing "fat" is, according to Wirth, that software is not so much systematically maintained but rather uncritically extended with features; i.e., new "stuff" is added all the time, regardless of whether the addition actually contributes to the original idea and purpose of the system in question. (Wirth mentions user interfaces as an example of this problem. His critique can easily be paraphrased thus: Who really needs transparent window borders?)

Another reason for the complexity problem that Wirth identifies is that "[t]o some, complexity equals power". This one is for those software engineers, I guess, that "misinterpret complexity as sophistication" (and I might well have one or two things in stock to be ashamed about). He also mentions time pressure, and that is certainly an issue in corporate ecosystems where management does not have any idea about how software is (or should be) built, and where software developers don't have any idea about user perspective.

I must say that I wholeheartedly agree with Wirth's critique.

Digression. Wirth offers a solution, and it's called Oberon. It's an out-of-the box system implemented in a programming language of the same name, running on the bare metal, with extremely succinct source code, yet offering the full power of an operating system with integrated development tools. One of the features of the Oberon language, and also one that Wirth repeatedly characterises as crucial, is that it is statically and strongly typed.

Being fond of dynamic programming languages, I have to object to some the ideas that he has about object-oriented programming languages and typing.
  • "Abstraction can work only with languages that postulate strict, static typing of every variable and function."
  • "To be worthy of the description, an object-oriented language must embody strict, static typing that cannot be breached, whereby programmers can rely on the compiler to identify inconsistencies."
Well, no.

My understanding of abstraction (and not only in programming languages) is that it is supposed to hide away complexity by providing some kind of interface. To make this work, it is not necessary that the interface be statically known, as several languages adopting the idea of dynamic typing show. Strict and static typing in this radical sense also pretty much excludes polymorphism, which has proven to be a powerful abstraction mechanism. (Indeed, Wirth describes what is called "type extension" in Oberon, which is called "inheritance" elsewhere.) It is correct that static strict typing allows for compilers to detect (potential) errors earlier, but abstraction works well and nicely with languages that don't require this.

It is puzzling to read that an OOP language must be statically and strictly typed to be rightfully called an OOP language. Ah, no, please, come on! Even as early as 1995, there were programming languages around that one would have greatest difficulties to classify as not being OOP languages in spite of their being dynamically typed. Moreover, it is an inherent property of living systems (which the object-oriented paradigm has always strived to capture) that objects in them assume and abandon roles during their lifetimes—something which to capture statically is hard.

Finally, it is interesting to note that the successor of the Oberon system, A2, features a window manager that supports "possibly semi transparent windows". Do you see the irony in this? End of digression.

As stated above, I really share Wirth's opinion that there is too much complexity in software, and I believe this is still true today. What can be done about it? Regarding operating systems, we depend on diverse device drivers even more than a decade ago, so we need a certain degree of abstraction to allow operating systems to talk to different hardware. Regarding convenience and user experience, the occasional bit of eye candy makes working with systems undoubtedly more comfortable. We should still ask ourselves whether it's really, really necessary though, and perhaps concentrate on the really important things, e.g., responsiveness.

So what to do? I don't really have a definitive answer, but I believe that the idea of minimal abstraction is worth a look. The "minimal" in the term does not necessarily mean that systems are small. It means that the tendency to stack layers upon layers of software on top of each other is avoided.

Minimal abstraction is the principle at work in frameworks such as COLA (a tutorial is available here) or in the work on delegation-based implementations of MDSOC languages I kicked off with Hans Schippers. I also believe that the elegance and (in a manner of speaking) baffling simplicity of metacircular programming language implementations (more recently, such as Maxine) are definitely worth a look.

I am sure it is possible to avoid complexity as we have to observe it today, and to make software more simple, better understandable and maintainable, and I believe the above is a step in that direction.

Friday, February 20, 2009

Computer Science and "Geschichtsvergessenheit"

Yesterday, a friend working at a German university told me over ICQ that for most of his students the name Niklaus Wirth didn't ring a bell. I was mildly shocked, and we ranted (ironically) a bit about today's students' being undereducated and ignorant and all. Eventually, we came up with a quickly and superficially assembled list of some more persons that we think one should know if they're into computer science: Alan M. Turing, Grace Hopper, Ada Lovelace, Edsger W. Dijkstra, David L. Parnas, and Konrad Zuse. Some of these might have been chosen based on personal preference, but most of them undoubtedly have made significant contributions to computer science.

Let's face it: the practical outcomes of academic computer science tend to reoccur in cycles. Distributed systems of yore are somehow residing in the SOA/grid/cloud triangle these days, and concepts that have long been known are re-introduced and hyped with all the marketing power of globalised corporations. While this is typical for industry, it's unsettling that academia jumps on the bandwagon almost uncritically, generating massive amounts of publications at high speed that don't actually tell anything new. The seminal papers that have been published, in some cases, decades ago are mostly not even referenced in these.

I believe this is not a deliberate choice of the authors of said papers. Any academic worth their share will strive to give relevant related and previous work due credit. So what is it that brings this about? Why is computer science so geschichtsvergessen (unaware, if not ignorant, of (its own) history)?

Is it because many, too many, universities focus on teaching students the currently hyped programming language? Is it because education at academic institutions too often and too strongly concentrates on creating industry-compatible computer scientists operators? Is it because computer science education is not designed to be sustainable?

The above questions can, more or less obviously, be answered with yes—and that is sad. Not because students don't know the names of people that helped shape computer science in its early days; that, one could do with. It is much more problematic that ignorance (be it deliberate or not) of previously achieved important, crucial results leads to too much work being done over and over again. It's reinventing the wheel on a large scale.

Most academic disciplines I know of introduce their students to the historical background and development of their subject early in the curriculum. Students of economic science learn about mercantilism, Smith, Keynes, and Friedman early on; and prospective jurists are soon faced with the Roman legal system and its numerous influences on contemporary legal systems. Why does a computer science curriculum start, ironically exaggerated, with a darned Java programming course?

It's the teachers' job to change this. Still, they often themselves don't know their ancestors (and I am not an exception myself). Information is available. Two pointers that spring to mind are these:
  • Friedrich L. Bauer's small volume "Kurze Geschichte der Informatik" (sorry, I don't know if it's available in English) connects computer science to its roots in mathematics and philosophy and depicts its historic development until the early 1980s (sadly, it stops there).
  • The volume "Software Pioneers" edited by Manfred Broy and Ernst Denert collects reprints of seminal papers by various computer science pioneers. It comes with 4 DVDs (!) containing videos of talks of most of these persons, who were gathered at a Software Pioneers Conference in Bonn (Germany) in 2001.
Please, let's not forget where we come from, aye?

Wednesday, February 04, 2009

Der Vatikan etc. ... Nachtrag

Nun reagiert Rom, endlich, und mit der nötigen Konsequenz.

Die Mitteilung des vatikanischen Staatssekretariats stellt einige Dinge klar:
  • wofür die vier "Bischöfe" damals eigentlich exkommuniziert wurden,
  • warum die Exkommunikation nun aufgehoben wurde,
  • dass die Vier nach wie vor nicht voll rehabilitiert sind,
  • dass die Pius-Bruderschaft nicht als kirchliche Organisation anerkannt wird, und
  • dass, soll diese Anerkennung erwirkt werden, die Piusbrüder ihrerseits das Zweite Vatikanische Konzil anerkennen müssen.
So. Na also. Geht doch.

Diese Inhalte sollten sich nicht nur die Piusbrüder, sondern auch andere hinter die Ohren schreiben, die sich in den vergangenen Tagen oft etwas zu weit aus dem Fenster gelehnt haben.

Der Holocaust-Leugner Williamson wird dann noch sehr deutlich aufgefordert, sich, will er als Bischof anerkannt werden, von seinen beschämenden und lügnerischen Behauptungen klar zu distanzieren.

Aber. In der Mitteilung heißt es: "Der Heilige Vater kannte zum Zeitpunkt des Nachlasses der Exkommunikation die[] Positionen [Williamsons zum Holocaust] nicht." (Änderungen im Zitat von mir, zum besseren Verständnis.) Das kann ich nach wie vor nicht glauben, sind doch die Pius-Bruderschaft und auch Williamson selbst in der Vergangenheit schon antisemitisch, sogar Holocaust-leugnerisch in Erscheinung getreten.

Will man nicht zugeben, das gewusst zu haben, oder hat man es nicht gewusst? So oder so wirft es kein gutes Licht auf die Art und Weise, wie der Vatikan in dieser Sache kommuniziert (hat). Ein bitterer Nachgeschmack bleibt.

Der Vatikan, Kommunikation, Timing und die Öffentlichkeit

Viel ist derzeit die Rede von der Unbotmäßigkeit des Vorgangs der Aufhebung der Exkommunikation vierer "Bischöfe" der ultrakonservativen Pius-Bruderschaft durch Benedikt XVI. in Rom. Die öffentliche Meinung entzündet sich dabei hauptsächlich daran, dass einer der Vier sich nicht entblödete, im schwedischen Fernsehen einigen ausgemachten Schwachsinn von sich zu geben, sich damit ganz klar selbst ins Abseits stellte, und dennoch "rehabilitiert" wurde.

Leider ist die Sache wieder mal komplizierter als sie dargestellt wird, und vieles wird, vielleicht bewusst, vereinfacht, um ein paar Schlagzeilen haben zu können. Der französische Erzbischof Hippolyte Simon hat diese Dinge ganz schön zusammengefasst.

Halten wir doch mal fest: die Aufhebung der Exkommunikation ist ein kleiner Schritt in einem größeren Prozess, in dem Rom, vertreten durch den Papst, eine Art Integrationspolitik betreibt, um den ultrakonservativen Rand wieder stärker einzubinden. Das ist wirklich zunächst einmal ein rein kirchenpolitischer und kirchenrechtlicher Vorgang.

Halten wir ferner fest: die Vier sind mitnichten "rehabilitiert". Ihre "Bischofs"-Weihen sind nach wie vor ungültig. Die Aufhebung der Exkommunikation stellt lediglich die Aufhebung eines erfolgten Ausschlusses dar. (Analogien zum Vereinsrecht drängen sich auf, leiden aber daran, dass sie, wie viele Vergleiche, etwas hinken.)

Es ist auch wichtig, darauf hinzuweisen, dass der Vatikan sich sehr schnell nach Bekanntwerden der dummen Äußerungen des Holocaust-Leugners Williamson von selbigen distanziert hat. Es muss auch gesagt werden, dass nach Kirchenrecht die Leugnung des Holocausts keinen Grund für eine Exkommunikation darstellt, weswegen der oben erwähnte Prozess der kirchenpolitischen Annäherung von dem Schwachsinn, den der Piusbruder da von sich gegeben hat, aus kirchenrechtlicher Sicht nicht berührt wird.

Das mag man schlecht finden. Kirchenrecht ist eben, nun ja, Kirchenrecht und damit gewissermaßen seinsbedingt ein wenig weltfremd. Es sei aber auch daran erinnert, dass es Nationalstaaten gibt, in denen die Leugnung des Holocaust nicht unter Strafe steht. (Und deren diplomatische Beziehungen zu Israel gar nicht zur Disposition stehen.)

Rein kirchenrechtlich ist gegen das Vorgehen des Vatikans nichts einzuwenden. In seiner Wirkung auf die Öffentlichkeit ist es dennoch katastrophal, und so etwas passiert in diesem Pontifikat leider nicht zum ersten Mal. Was dahinter steckt, weiß ich nicht: Ungeschick oder Unsensibilität, oder gar kalkulierte Provokation? An der Kommunikationsfähigkeit des Vatikans darf jedenfalls gezweifelt werden.

Die Möglichkeit eines schlechten Timings drängt sich auf. Dass Williamson seinen Mist genau am Vorabend der offiziellen Verlautbarung, seine Exkommunikation werde aufgehoben, kund tut, deutet in diese Richtung.

Der Vatikan muss sich in diesem Zusammenhang aber auch fragen lassen, ob ihm unbekannt war, dass die Piusbrüder, und nicht nur Williamson, bereits seit einiger Zeit durch antisemitische Äußerungen auffallen. Glauben kann ich das nicht. (Hipployte Simons oben erwähnte Erklärung lässt diesen Aspekt auch außer Acht.) Da wäre vielleicht eine bessere Vorbereitung diverser Aktionen sinnvoll gewesen. Das jetzt vorliegende Kommunikationsdesaster ist kaum mehr zu reparieren. Die Grenzen der Sachlichkeit sind längst überschritten, und, seien wir ehrlich, auf den Vatikan einzuprügeln ist doch so schön einfach und schlagzeilenträchtig.

Die katholische Kirche ist nicht homogen, und in ihr, beziehungsweise an ihren Rändern, gibt es halt auch ultrakonservative Spinner, denen die Errungenschaften des Zweiten Vatikanischen Konzils nicht mehr als Häresien sind. Die Piusbrüder sind in der Hinsicht kein Kind von Traurigkeit, und Attribute wie "Rückwärtsgewandtheit" sind angemessen. Verteidigungsversuche, die diese Haltung als "Traditionsbewusstsein" einzuordnen suchen, sind wirklich schwach und durchsichtig.

Und der Papst? Der hat sich zur Aufgabe gemacht, diesen Haufen in die Kirche zu re-integrieren. Mal sehen, wie gut das angesichts der Marodeure in ihren Reihen gelingen kann. In seiner Haut möchte ich nicht stecken.

Monday, February 02, 2009

Convenience for Maxine in Eclipse

Isn't it a bit sad that we've got this marvellous IDE, and yet we have to switch to the command line every now and then to kick off a Maxine build, or run a Java application in Maxine, or look at its and the VM's innards in the Inspector? Yes, it is. So I decided to exploit the capabilities of Eclipse and set up some neat one-click experience facilities to make life easier.

Building Maxine and the Image

The first task I want to make easier is building Maxine. Of course, the command lines one has to use are as simple as this:

~/workspace/maxine~maxine$ bin/max build
~/workspace/maxine~maxine$ bin/max image

But still, switching to the command line is the kind of media break at least I don't like too much. I want to have one task for each of the lines above, because sometimes one wants to build the VM sources without building the image at the same time.

The Eclipse feature to use is called external tools. There is a button right next to the run button in Eclipse (it looks like the one to the right) with a menu attached; click on the black triangle to invoke the menu, and then on External Tools Configurations.... In the dialogue that appears, double-click on the Program item; this will start the creation of a new external tool configuration invoking some application external to Eclipse. (We don't care about Ant tasks.)

The settings that should be applied look like in the two images below. It is quite obvious that these settings just provide a convenient wrapper around the max script, with the path to the script and its working directory and environment settings given, and also with the command line argument (build) being passed to the script. It's that simple.


In the Main tab, I have used the workspace_loc Eclipse variable to avoid having to enter the full path to the max script. Being able to give its location relative to the Eclipse workspace is much more convenient and makes the configuration reusable. The same holds for the working directory setting, which is simply the workspace directory.

The settings in the Environment tab are important because they give the max script the environment variables it requires to be run. I set JAVA_HOME to /usr/jdk/latest, and JUNIT4_CP to ${eclipse_home}/plugins/org.junit4_4.3.1/junit.jar, which is the JUnit distribution that comes with Eclipse. Note that I have once more used an Eclipse variable, eclipse_home, which points to the root of the Eclipse installation.

After having entered all the information, clicking the Apply button will save the settings. Clicking Run will save them and run the script immediately, building the Maxine sources as requested. Note how the script's output appears in the Eclipse console window.

With the wrapper for building Maxine in place, it is very straightforward to create another one for building the image. In the external tools dialogue, just right-click on the Build Maxine entry, and select the Duplicate option from the context menu. This will create a clone of the configuration we just created, and make it available for editing. The only settings that have to be changed are the name (obviously) and the command line argument (set it to image). Once that's done, click on Apply to save, or on Run to see how it works.

Running ''Hello World''

Creating a wrapper for running the Hello World application that comes with Maxine is just as simple. Try yourself, and recall that the command line argument to be passed to max is helloworld.

Interlude: Another Java Application

Of course, it is not enough to be able to (albeit conveniently) execute the simple things from within Eclipse. I want to be able to run any given Java application in Maxine, and, what's more, I want to be able to run Java applications in the Inspector. For the rest of this tutorial, we'll need some Java application that does not come with the Maxine distribution, so we can see how Eclipse facilitates integrating tools spanning several workspace projects.

The application we'll use is deliberately simple; actually, it's just another Hello World, but one that resides outside the Maxine workspace directories and projects. Here's the source code:

public class MyHW {
public static void main(String[] args) {
System.out.println("Hello, world!");
}
}

This is all we need; just create a Java project MyHW in Eclipse, and a corresponding class containing the code above. I won't go into the details of this here.

Just one note: in Eclipse, Java projects have the default property that their source code and binary directories are separate. I haven't changed this default for the MyHW project, so all details given below are chosen to work with this, and no guarantees for other configurations are given.

Running MyHW on Maxine

In terms of the command line, the max invocation for running MyHW is as follows (note the directory I'm in):

~/workspace/MyHW$ ../maxine~maxine/bin/max vm -cp bin MyHW

In detail, this invokes the max script with the vm parameter indicating that the VM should be run, passing the VM an extension to the class path (the standard option -cp is used for this, and the class path is the bin directory of the MyHW Eclipse project), and the application to be run.

To set up a generic configuration for running Java applications on Maxine from within Eclipse, the class path and application in question need to be passed as variable parameters. The rest is rather simple.

Here's the dedicated behaviour: we want to be able to select a Java file in Eclipse's package explorer, then go to the Run External Tool menu and select a tool called Run Application on Maxine. This should trigger execution of the selected application on Maxine.

Let's start with one of our previously created external tool configurations. For instance, let's duplicate the Build Image configuration and rename it to Run Application on Maxine. The trivial thing is to replace the image parameter with vm.

The working directory should be the project directory of the Java application we're about to execute, so that setting should be ${project_loc}. The project_loc Eclipse variable contains, for any selected resource, the root folder of the project it belongs to.

After the vm parameter, we need to pass the class path and Java application name. The class path is the project location with bin/ appended (Eclipse default). The Java application is the name of the resource without the file name suffix. Here is how the full list of arguments to the max script looks:

vm -cp ${project_loc}/bin ${java_type_name}

The interesting bit about this setting is the java_type_name variable: it will, for a selected Java resource, contain that resource's fully qualified Java type. So, just what we need to pass the VM on the command line.

To summarise, the complete settings for the Run Application on Maxine configuration are given in the image below.

Running MyHW in the Inspector

Guess what, setting up a configuration for the Inspector is trivial now. Really, all you have to do is clone the run configuration we created above, and replace the vm command line argument with inspect. Bingo.

Concluding Remark

You may have noticed that running and inspecting Java applications with Maxine is not quite as convenient as usually seen in Eclipse, namely via the Run as... and Debug as... options in a Java file's context menu. While this would certainly be appreciable, it seems to require setting up Maxine as a full-fledged Java runtime environment, which I haven't (yet) figured out how to achieve. Maybe this will happen some time in the future.

For now, I'm happy with the convenience wrappers for the max script. They also relieve me of keeping track with configuration changes in Maxine command lines and things that need to be passed on the command line to get the Inspector up and running, and so forth: just having everything tucked away in the max script is very convenient. Setting up things directly would imply dealing with the gory details.