I have some notes up on my wiki from things I’ve been reading about the Common Lisp programming language. I became intrigued by it last summer when the new edition of Practical Common Lisp was about to come out, and went to read the book’s web version. I found the language a bit big and daunting; I always seem to do better learning a small language or small subset of a language and understanding its theory before moving on to the big language, like when I tried to pick up C++ and found there was just too much to try to keep in my head, but had an easier time with plain ol’ C and got the impression that it would be much preferable to learn the ++ on top of it. Similarly my interest in Common Lisp was renewed upon learning Scheme in Dr. Wallingford’s Programming Languages course at UNI last semester. After typing (define stuff (lambda (stuff) stuff) a few times, the few chapters of Practical Common Lisp I’d managed to get through popped into my head and I had the magical epiphany that CL’s (defun may be just a syntactic abstraction of that idiom, and furthermore, was probably implemented as a macro. Turned out I was on the right track.
Anyway, I’m trying to get going in earnest on a research project in network analysis that I need in order to graduate. Once someone with a bit of modern-day CS background starts learning a little bit about the theory, I gather that the natural thing that springs into one’s head is that it’s practically a textbook case for applying Object Orientation. It did for me. So I decided to have a look into the Common Lisp Object System, or CLOS.
Anyway, I ran across this really cool tutorial. The CLOS is interesting, a bit different, but I think I like it. One key difference from the OO I’d learned in school by way of Java, however, was that the methods of an object don’t conceptually “live inside” the object. This idea struck me as kind of un-OO at first, since I had thought that kind of encapsulation was really at the heart of Object Orientation. Then, near the end of the tutorial, came a section titled “In OO languages the functionality lives in the object” which began with this rather shocking statement:
This preposterous claim is the product of a diseased imagination. However many OO systems feel obliged to try and enforce it. Try to avoid having to program in one of these.
As for that last sentence, I bid ye good luck with that in the context of one’s career. As it turns out however, the way that a CLOS method works – whatever object you want it to act on must be passed as an argument – resolves an old annoyance of mine with the syntax of Java style OO. Those of you who used Java a couple years back probably remember having to compare strings (and other objects, no doubt) this way: MyString.equals(otherString). I guess it’s okay once you’re used to it but it takes the conceptual operation of comparison and forces it to “operate within” one object according to an “argument” that is the other object. This seems to hurt the proper perception of commutability of the equality operation in an annoying way. And it probably drives people with a mathematcs background crazy that you can’t just use the equals sign to compare complex numbers.
This has implications for a project in networks too. Say you want to find out the shortest distance-in-links between two nodes. The algorithm, an old graph theory staple, conceptually should be an operation on the nodes themselves – with nodes passing the same query on to their neighboring nodes – and the operation itself is a commutative relationship between two objects of the same type in which both nodes are on the same footing (neither is subordinate to the other). If the method “lives on” one node at a time, which node should you ask? Should it matter which node is the actor and which is the argument? Of course not. Plus you’ll likely end up having to test the method from both ends to make sure it works the same way.