This page contains some personal anectodes outlining evolutionary traces.

My life with computers began at age 15, on the day my father brought home a pocket calculator with several cards onto each of which a scientific mineralogy program was punched. One of them actually was a game: A Moonlander gravitates towards the surface. The screen displays the vehicle's current height, velocity and the amount of rocket fuel left (e.g. 10000, 120, 200). Your mission is to avoid a rough landing by spending the right amount of fuel at the right points in time (e.g. 10 <ENTER>, ..., 20 <ENTER>, ..., BOOM). Booting the game was easy: you switched on the calculator, inserted the punch card, and you were already playing. Admittedly, the game became boring rather soon.

Later my father worked with a Commodore PET 2001, which had a built-in dataset (that's a tape drive), 8 KB memory, and a BASIC interpreter. Today we have forgotten how much one can actually do with just 8 KB, if being used to economic spending. On SAVE of our programs we had to be careful to remember the current tape counter for future LOADs. Later followed a C64 with 64 KB and a powerful 1 MHz 6502 CPU. That also came with a BASIC interpreter, but could also easily be programmed in assembler. Plus, you could do pixel graphics. People would compete based on counting the number of cycles spent in their assembler graphics routines. That was still the time one could truly be the master of a machine, as every single aspect of it, including the semantics of every memory address and OS routine could be understood by an interested youngster. Already the Amiga 500 and the Macintosh Plus were partly incomprehensible beasts. Of course, all of those things are shredded or in museums nowadays. However, what remains is a helpful perspective on what is going on some hundred abstraction layers below/before the one we are usually concerned with these days.

At University of Linz, the IBM batch processing mainframe motivated thinking hard about what you were doing before submitting a job. That was, because it might take 15 minutes for a job to return with a laconic "syntax error". Besides, a job that went into an infinite loop produced 100 paper output pages (in the CS center of another building) before it would be killed. Nobody cried when the colossus finally was declared a pile of rubbish.

Fooling around with parallel computing on a hypercube was more fun. Fortunately, the cube was rather modern and required no special-purpose programming language such as Occam. Thus, I encountered the C language and Unix.

Later, I was lucky to drop into Guenther Blaschek's department and humble world of thought, which centered, among other things, around human/computer interaction, object oriented programming, language and compiler design, software engineering, and the synthesis of all these. (Get a glimpse or two). Guenther was a truly intuitive language and system designer and a most gifted programmer, one of the kind that can do cleaner, better and faster than a team of fifty. I was thunderstruck by his style. It was then that I understood that the greatest achievement is to produce something that is obviously useful, obviously clever, and obviously so simple that you think you could easily have done it yourself (if you'd only done it). Recall the invention of the wheel, the climbing harness and the beeper that alerts people not to forget turning off the car lights. During two years in Arhus/Denmark I had a great deal of fun working with Guenther's Omega language on toolkits and frameworks, in particular on containers, collections, data structures and algorithms. Even today, Java, Python, C++ and the likes seem a bit like stoneage tools compared to Omega. Thus, I found that with the right tool, just a tiny fraction of the time needs to be spent with coding and debugging, leaving most of the time for conceptual work and tentative refactorings, along the way distilling simplicity and a large degree of reusabilty. This leads to a small set of orthogonal multi-purpose classes and methods that can be customized and plugged together to yield a wide range of powerful behaviours.

Before finishing my M.S. I met Gerti Kappel and got into database systems because these seemed to require concentrated know-how from many other computer science fields. I more or less randomly soaked up all kinds of DBMS related material. This eventually led me to join CERN, where bizarre data management challenges are more common than sand. Index data structures were a promising means of speeding up data-intensive analysis, and that's what kept me busy for quite some time. I came to understand what it means to host production software in a large-scale computer center. Too spoiled by the Omega programming language I looked for a commodity language that would not be too hard of a backslash. Thus, I uneasily turned into an early Java adopter, the side-effect of which was a high-performance toolkit.and the build-up of the public CERN Java infrastructure.

Simultaneously, Ben Segal mentored the team I was with. He had intriguing first-hand experience with networking, the Internet, the WWW, as well as their history and evolution. In stories and episodes he recalled the struggle of Tim Berners-Lee and the diverse strings of evolution that eventually led to what we take for granted now. He opened my eyes to large-scale distributed computing. I began to soak up tons of material in this area and developed hands-on experience with the four simple, orthogonal and effective pillars of the WWW architecture (URI, HTTP, MIME, HTML), Internet protocol stacks, container and HTTP server frameworks, XML related standards, Web databases, distributed transactions, etc. Hence, the then novel concepts of Grid Computing fell on fertile ground in our group, and soon we were deep into building software infrastructures for the European Data Grid. Over time it became clear that Grid computing, like super computing before, would be heading towards an evolutionary niche or dead-end branch, if it were to continue to ignore the recent and countless innovations and commodity tools from the Internet community and industry. Luckily, recent developments seem to have changed directions again. In particular the continuing convergence of the WWW Architecture, Grid Computing, Database Systems, P2P Computing, and Web Services promises to produce powerful emerging synergies. This then leads to the underlying theme of my PhD, a story I'll tell some other day...

---