Reflecting on my thesis
On Monday I successfully defended my PhD thesis entitled Structuring data via behavioural synthesis. My thesis looked at ways to derive the structure of data given the behaviour of a system. That is, by studying the actions of a system you can determine the structure of the data objects it uses.
It's been a long, hard road getting to the this point. I started my graduate work six and half years ago (January 2002) and started out working in bioinformatics. I then got the itch to work with programming languages and the work finally led me to examine the dynamic elements of programs. In particular, I got interested in context-oriented programming.
Only work from the last two years actually made it into the thesis. While that may seem to indicate the previous four and a half years was a waste, nothing could be further from the truth. The steps leading to the work I did were important because I'm pretty sure I wouldn't have had the background I did without making various mistakes and missteps along the way. Ideas evolve and rarely spring into being, and I think some of the ideas I examined were greatly helped by making the mistakes I did.
Richard Gabriel was my external examiner. I cite him in my thesis and his work motivated me to look at what I did. Needless to say, I was a little nervous. However, he asked some great questions and got me thinking about where to take the work a bit more. I will certainly be exploring different avenues with it.
I want to thank all my friends who have been supportive of me over the years. You have been a big help in keeping me sane. In particular, I want to thank Ren, Greg, Ian, Adam and Les.
I don't say I'm proud of very much, but I'm proud of my thesis. I put a lot of work into it and went through a lot of stress to get it written. Even if no one else ever reads it, I'll be happy with it.
When I have the revisions complete, I will post a link to the thesis. (Some people may like the first two chapters, actually.) I'd rather not provide a version that requires changes. I'll also work on posting it in HTML rather than PDF, since I'm sure few people will want to print it.
ILC Monday
I didn't feel particularly well when I woke up and this persisted all morning. I think I'm coming down with a cold; perhaps the jet lag has caught up with me. I decided to retire for the afternoon and rest. I feel bad for having missed the talks in the afternoon, but I really didn't feel that chipper.
In the morning, there were four talks. Herbert Stoyan traced the origins of EVAL/APPLY via McCarthy's notes on the process and it was interesting to see how complicated it originally was. This was followed by a talk describing a constraint satisfaction solver that tends to perform better than Screamer and allows for slightly better descriptions of the constraints. I would have liked to have seen more discussion on the actual writing of constraints and perhaps a little less on the inner workings.
That was followed by some work done with Dylan that implements a DSL for describing binary data. I must confess to not being very interested in that work, mainly because the talk focused so much on the precise macros used and that it was used solely for ethernet packet descriptions. I applaud the effort, but don't have much interest in it.
Lastly came a small demo of FREEDIUS, which is a "video and image understanding system." I must say that I didn't come away from the talk quite knowing what the system understands, exactly. I did like the fact that when interacting with the GUI, the objects representing the images were available at the Lisp listener. However, I wasn't sure just where the understanding lie. That being said, it gave the impression of a very competent system but again, I don't have much need of it.
At this point, I was feeling worse and hoped that some lunch would fix me up a bit. It didn't. I napped for a couple hours and I felt a bit better, but my throat hurt a little bit when I talked. As I write this, I almost feel good enough to go out for dinner, but I'm not sure.
Tonight I expect I will sit down with the one month trial edition of LispWorks Enterprise Edition that was kindly given out by the LispWorks people to anyone who wanted one — it even came with a spiffy T-shirt. I like the LispWorks IDE and want to a give a more serious go at using it, so I'll take the opportunity to do so. Apparently, Franz is coming out with an IDE for Mac OS X so things are going to get interesting for me in the future.
Appreciating the design of Common Lisp
Over the last little while, I've been thinking about ways to use profiling data to guide program compilation and/or transformations. Yesterday I sat down and sketched out all the thoughts I've had in more detail and played around with how to get such a system to work in Common Lisp (herein referred to as simply Lisp).
The basic flow of control would be as follows:
- Write a general program that is likely slow.
- Run it on some representative data to profile it.
- Use the profiling data to specialize/optimize parts of the code.
The first two steps are easy, but how do you do the third in a semi-automatic way? One way is to define certain parts of the program to be something that can even be affected by such transformations. As an example, say you write your program to work with any sequence, but you're really only using it on strings. Then you can specialize the code that uses sequences to work with strings. However, you are not required to write for strings directly: this can be inferred from the profiling step, assuming the data is representative. (I don't think this is a panacea to ease-of-use programming or anything, but it seems interesting.)
One way to do this in Lisp is to make the "specializable" code portions macros. This is fine, but then the same thing can't be a function. Yuck. So I looked into ways to combine the two in the way I needed. I investigated making a code walker, or mucking with *macroexpand-hook*, or even wrapping the standard function macroexpand. I came up with a solution which was small, but kinda ugly.
At this point, I dug deeper into the language standard and realized I was re-inventing the wheel. Turns out Lisp already has the vehicle I needed to try this out: compiler macros. Compiler macros "permit selective source code transformations as optimization advice to the compiler." The only caveat is that the application of a compiler macro is not mandatory.
I knew of compiler macros, but didn't really think about them that much. Well, I'm glad someone did (and made them standard) because they are going to save me a lot of time and effort (even though I spent a day re-inventing the wheel, basically). Makes me appreciate how much thought must have gone into defining Lisp and how great a language it is for experimenting with language ideas.
As for the rest of my idea above, I'll update more in the near future now that I don't have to figure out how to get code specialization working.
Amusing FizzBuzz discussion
There's a thread going on in comp.lang.lisp about the FizzBuzz programming question which has become somewhat amusing: trying to come up with wacky solutions. The one I like the most is courtesy of Rob Warnock:
(defun fizz-buzz (n)
(loop for i from 1 to n
and three-p in '#3=(nil nil t . #3#)
and five-p in '#5=(nil nil nil nil t . #5#)
do (format t "~a~%" (cond
((and three-p five-p) "FizzBuzz")
(three-p "Fizz")
(five-p "Buzz")
(t i)))))
Note the lack of arithmetic operations and great use of the reader. 
(For those wondering, the #3 and #5 create circular lists at read time. Thus, this is a loop over three items in parallel: the integers 1 to n, a circular list of length 3 and a circular list of length 5. The choice of #3 and #5 are for documentation purposes; they could have been #1 and #2 and it would make no difference.)
If you intend to try this out and want to experiment with circular lists, make sure you evaluate (setf *print-circle* t) at the REPL.
Sussman’s little digs at type theory and Mathematica
In a lecture given for Daniel Friedman's 60th birthday, Gerald Sussman talked about the role of programming as the communication of ideas in a clean way. Near the end, he is pointing out the difference between formality and rigour, and puts up a slide with a quote from Marvin Minsky where Sussman comments,
The only part of this that matters is the title to this paper... "Why Programming Is a Good Medium for Expressing Poorly Understood and Sloppily-Formulated Ideas" [PDF] — exactly the opposite of people who want to plague me with type theory.
While taking questions, someone asked if he had used Mathematica (as much of Sussman's talk was about writing programs for doing symbolic manipulation) and he replied,
I don't know much about Mathematica since I've never used it — I write my own — but I don't much like Mr. Wolfram.
Ouch!
How to criticize programming languages
A great read from a curmudgeon who figures its worth the effort to praise something. Pick a language and say three good things about it.
Although the praise is worthwhile, the best line is the following:
The second reason why I'm grateful to people who created Java, is saving the world from C++. C++ is crime against humanity, and its creator is the programming equivalent of Saddam Hussein.
Beating a dead horse
The static vs. dynamic typing "debate" – even the quotes can't loosen that term enough to make such nomenclature palatable, but that's what it's known as – is one of those verbal spats that makes you wonder why you bother to read programming language discussion groups in the first place.
comp.lang.lisp has been suffering from an onslaught of this utterly pointless discussion (not that it's had much interesting discourse of late anyway). What never ceases to amaze me is the seeming insistence on trying to reason that one is technically superior to the other.
Here's some advice: it's an aesthetic argument, not a technical one. No matter what example the "dynamic" crowd comes up with, the "static" crowd will be able to come up with a way to do it in a language with static typing (likely with type inference). And for the dynamic examples where type checking is obviously a pain to do correctly, the static crowd will retort along the lines of "that's a really bad idea", or "that's a serious performance penalty", or something equally trite.
Static vs. dynamic typing is the Godwin's Law of programming language discussion.
Anyone who continues to argue that it is clear that one is better than the other needs to do two things: define what "better" really means and provide some evidence. At this point, I don't know of any serious study that shows much of anything that is argued by either camp. Frankly, I think it's like arguing that cake is better than pie: it's bound to go nowhere.
The people who insist on beating this dead horse are best ignored until they are willing to fess up to the fact that maybe, just maybe, people simply prefer one to the other for whatever it is they are doing because it suits their style.
Technorati Tags: development, dynamic languages, programming languages, static typing
The Art of the Metaobject Protocol
I've worked my way through The Art of the Metaobject Protocol (AMOP) and I must say that it is one of the best computer science texts I have ever read. It gave me a new appreciation for object-oriented programming and taught me a fair bit about the Common Lisp Object System (CLOS).
AMOP walks you through the design of a simple metaobject protocol for CLOS (called Closette) that lets you extend and change CLOS in various ways. Simply put, you are defining an object system using an existing object system. This lets you have different object systems hanging around so that, for example, you can change CLOS to enforce encapsulation (something it doesn't do by default). You could also change how the inheritance system works.
When you see how something is designed, you gain a deeper understanding of how to use it and why you would want to. When that system is well designed (like CLOS and the MOP are), you learn even more about the process of designing just about anything. This is how I felt reading this book. I gained insight into how such language features are engineered as well as how to approach designs in my own work.
After reading this book, I still view OO programming as a tool, not a model of programming that should be constantly adhered to. The reason I have come to appreciate CLOS is that you don't have to view everything as an object to use it and when combined with a metaobject protocol, allows you to change the way objects are treated to suit your needs.
I think this book should be required reading for fourth-year undergraduates studying OO programming. They won't regret it.
Technorati Tags: Books, CLOS, Lisp, metaobject