Back in 1983, when I entered college to study programming, my academic advisor told me that there were two courses that would form the foundation for every future line of code we would write: Algorithms 101, and Data Structures 101. He said that in algorithms class, I would learn the fundamentals of solving problems within the confines of a computer. In data structures, I would learn how to organize the data that my algorithms would work on.

My academic advisor was right. Over the next four years, I learned what linked lists, hashes, arrays, and binary trees were, and how to search them, sort them, and traverse them. I learned how to process and organize data in a myriad of ways, and could implement what I had learned in Pascal, C, Assembly, and a bunch of other interesting languages.

When I got my first job after college, I have to admit I was quite proud when I implemented my first heap sort, and could say with understanding that it was of order log2n. I also got great satisfaction from implementing efficient linked lists, and fast binary searches. I'm glad I enjoyed doing these things so much, because as my career progressed, I found myself doing them over, and over and over again. In each new project I encountered, almost as much time was spent on re-implementing and debugging these low level constructs as was spent on designing and implementing the things that actually addressed application level issues.

When C++ started to catch on, I remember my excitement as I read through my first book about this new object oriented programming paradigm that everyone was saying would revolutionize the way code was written. As I began to use it in my work, I was impressed at how this new language made my life easier. And yet, as I used it more and more, I became increasingly aware that while C++ and other modern programming languages helped to make basic coding and organization easier, they often left the data structure implementations as an exercise to the reader. I still found myself spending far too much time implementing things like lists and trees that by my estimation should really be integral features of the language.

A few years later I found myself working at Sony on a system for inserting commercials into an on-air video system. It was a neat project, with multiple computers performing different tasks, and, in the case of a failure, dynamically reconfiguring themselves to take on the responsibilities of any computers that went down. It was on this project that a number of new gripes about programming really solidified themselves in my mind: things like "Boy, it sure is hard to transmit information between computers", and "Does multi-threading really need to be this hard?" It was here that I first dreamed of creating dynamic objects (the forerunner to aggregates in L), but sadly never got the chance to implement them before the project was cancelled.

Some time after Sony came a project for SGI that involved the verification of hardware for 3D graphics chips. It involved writing C++ code to generate test signal "packets" that could be fed to input buses and compared with output buses of blocks of Verilog code run in a simulator. Initially I used C++ polymorphism to represent the various types of command packets to be fed to or read from the Verilog buses. But the tedium of creating constructors, destructors, and output functions for hundreds of command packet variants that only differed slightly from each other was soon unbearable. So it was here that I resurrected and finally implemented the dynamic object I had first dreamed up at Sony a few years earlier.

SGI was also the place where Martin and I first had the opportunity to work together. Martin and I had always wanted to, but until then we had always been assigned to different projects. Now at long last at SGI we had been given our chance, and the result was magic. We collaborated on the dynamic object class, and its use on a number of Verilog blocks, and quickly found that we were well suited to working together. Each of our weaknesses was complemented by the other's strengths, and the results of our efforts were always much more than the sum of our respective contributions.

Unfortunately, working together didn't last long, as Martin got reassigned to a different project at SGI. But we still had lunch together every day, and quickly decided that if we couldn't work together, we'd program together on some side projects of our own. We dreamed up a bunch of silly little programs we called "Futilities" that we imagined would be fun to have... sort of high-tech pet-rocks for computers. We talked about them at lunch every day, and started devoting a few nights a week to working on them.

At that time, I was very impressed by the fancy GUIs on programs like Play's Amorphium, and MetaCreation's (now Corel's) Bryce. I had also been playing a lot with a program called WindowBlinds, which lets you replace the boring look of standard Microsoft Windows with "skins" of your own design. Influenced by these "swizzy" looking programs, we decided that even little apps like our "futilties" should have cool GUIs. So we took (what we thought would be a short) detour to write a graphics library that would simplify the creation of swizzy GUIs under Windows. Unfortunately, everything we wanted to do in a GUI proved to be difficult to accomplish under the standard Windows "document/view" model. And so we decided to take (what we thought would be another brief) detour, and create a new app framework based on our newly rethought dynamic object that would be easier to use than Windows' fixed message based system.

Well, part way into that, we found ourselves whining about how the notation for accessing the members of dynamics in C++ was awkward, and just wanted to be able to say things like object.member the way you do with C++ classes. So one evening I started writing up the description of a new language based around the idea of the dynamic object. I brought the description to lunch the next day at SGI, and said to Martin, "Imagine a language L, based on dynamic objects. I think we should create a compiler for it and do the framework and graphics library in that."

Martin looked at me like I was nuts. And probably rightly so... I mean talk about a huge detour... making a compiler for a new language to implement an entirely new application framework, to use a new graphics library just to make some little pet-rock applets look good? Yikes! But after he stopped laughing, and a few moments of contemplative silence, Martin said something like "Well, I always wanted to write a compiler..."

And that's how L got started. After two years of collaboration and hard work, we present the L language you see now.