Wednesday, June 22, 2005

Lately I've been thinking a lot about mixing Java and Lisp. The reason: Lisp is powerful stuff, but limited by it's text-based I/O. Java is powerful stuff, but limited by some of it's cumbersomeness and lack of flexibility. So, I started looking for anything that exists that might combine the two, hopefully in a way that allows Lisp to access the Java libraries and also compile directly to bytecodes to ensure interoperability on different platforms.

I found some Java-based Lisp implementations, and I found stuff that lets Lisp access the Java libraries, but I had a hard time finding something that did both. Finally, I came across Armed Bear, which seemed to be what I was looking for: it was completely Java-based, right down to the editor, could access the Java libraries, yet was at version 0.0.6 and had some major restrictions.

Then I started thinking some more about why Lisp had the limitations it did. Lisp was developed in the 1950s, and way back then, all you had was text input and output. And when the ANSI Common Lisp standard was defined (1990s) there was mostly text I/O. GUI's didn't come around until the 90s. So why would it include anything but text input and output? GUIs changed everything.

The next logical question is, why isn't there a "new" Lisp that deals with GUIs and such? Was the language to complicated to begin with? To simplistic? Is it not conducive to functional programming or interpreted programming? Can we redo functional programming so that it works with a decent GUI? And what GUI should be used--Xwindows, Windows, Java style? Standardization is an issue with that. Used to be, you had a command prompt with a flashing cursor, and no matter where you were, that command prompt would be there (usually). There was a place to input, and a place to read output.

Is Java the modern Lisp? Many would say "no", because it takes longer to code stuff. Maybe it just takes longer because people want more than just a text I/O. I think maybe this is why Paul Graham happened to be so successful--the internet spoke in text and static graphics when he was a success. As such, he could manipulate the text (html) all he wanted, and the graphics weren't going to change anyways, so it didn't matter. But even now, 10 years later, we're seeing more and more interactivity with the internet, which results in dynamic graphics, and graphics are difficult to do with text. Not impossible, mind you, but difficult.

Should it be so hard? Can it be done more easily than Java classes and inheritance and implements and such?

Let's suppose I give it a go--I start building a Lisp program that will output either Java code or bytecodes directly--it shouldn't matter which, just one will be more concise, one will be clearer. Now, the JVM seems to be based on the concept of classes, which makes perfect sense for Java--everything in Java is inside a class. Should the Lisp code be embedded in the classes, or should it supercede the classes? If it's embedded, we lose out on the "interactive" aspect of Lisp. We'd just have classes like normal Java, a bit of Lisp code to carry out stuff, and it'll all run like normal Java.

I think that's a losing proposition. What if instead, each entry in Lisp submitted a new .class file to the JVM. That ensures the "interactiveness" of Lisp, but each Lisp statement would have to be contained as a class. I don't *think* that would be too much of a problem. I'll keep looking into it and update as I learn more about the JVM, Java, and Lisp.

0 Comments:

Post a Comment

<< Home