Saturday, January 24, 2009

Logo in Java: why do it at all?

The plan: implement a version of the UCBLogo interpreter in Java.

To begin, let me just say that I start and abandon a lot of projects. It starts by me choosing a project that I have few doubts about. However, soon after I start, there's an inner skeptic in me that says I should forget about the whole thing and do something useful. Usually, my mentality is to ignore my skeptical thoughts and just go on with the project. "Screw you doubts, I'm going to go and do it anyway!" These doubts, unresolved, then fester and grow as I'm working out the project details. As soon as I hit a tough point, the doubts take over and soon I abandon what I'm working on and start the cycle anew by searching for another doubt free project.

This time, I'm going to take a different approach. I'm going to get the doubts out of the way now, so I can push through the initial development phase and end up with something of value.

So here it is, the three main reasons why this project is a giant waste of time:

1) It's been done and it's been done better.

There already are many logo implementations already out there. According to Wikipedia, there are 187 working implementations of Logo. If someone wants to write a program in Logo, they can pick any one of these implementations. Moreover, there are several rock solid implementations, like UCBLogo, FMSLogo, and Microworlds, which are better than anything I could ever come up with. There's even a really cool web based one being developed!

2) Logo is old, boring, and dying

Logo is over 40 years old. Its main purpose was to be an educational programming language for kids. In recent years, there have been other exciting developments in educational programming languages. Alice lets you create programs in your own 3D environment. Scratch lets you snap together blocks and share your programs on the web. Logo is just turtle graphics, which no kid thinks is exciting. Logo is dead, long live Alice and Scratch.

3) Java is the wrong language

Let's face it, Java is not the ideal language for implementing a Logo interpreter. The biggest problem with choosing Java as my language is the lack of built in continuations. You see, Logo (or actually UCBLogo) requires tail call elimination. The easiest way to implement tail call elimination is with a language that supports continuations. In Brian Harvey's C based version of UCB Logo, this problem was solved with an evaluation procedure that used GOTO statements to avoid explicit recursion and a stack to store the execution state. Java doesn't have GOTO, so tail call elimination will need to be implemented by either inventing continuations on top of the JVM or some other more convoluted way. Why not implement the language in something that already has continuations so I don't have to deal with this stuff?

To summarize the above: Why make a cement wheel with a hammer and chisel when you can get a better one, made of rubber, at the hardware store for less?

I chose Logo because I'm interested in Computer Science education, and what better way to learn about the ideas behind CS education then by learning every detail of a language rich in those ideas.

I chose Java, or explicitly the JVM, because it can run in a browser, it runs on all platforms, and because it's popular. When I'm done, I want someone to be easily able to use it for their own purposes. As for continuations, I'll deal with them when I get there.

And for the point that it's been done and it's been done better. Well, erhm... this point is rather embarrassing. You see, I've never written a compiler or interpreter before that wasn't for a class, and I've certainly never written one that was any good. Many people say that writing a compiler or interpreter yourself is a right of passage as a programmer. I know it's doubtful anybody will call me a better programmer after writing this thing, but it's even more doubtful that they will if I don't write it. This is one right of passage that I need to take.