Jackpot - James Gosling's Latest Project

Pete Bevin writes "Artima has a fine interview with James Gosling, creator of Java, about his latest project. It's called Jackpot, and it treats the parse tree as the program. This makes refactoring much, much more intuitive. The article has some good insights into code visualization, technical writing, and making your programs more understandable."

Comments

Interesting

[The Bungi]

I don't know much Java, but .NET has an entire CodeDOM namespace that can be used to generate assemblies and code on the fly. DOM being the keyword - it presents C# code as a parsed object tree. I haven't played with it beyond generating simple assemblies but I wonder if it could be somehow cajoled into creating a tree representation that also understands flow. That would be a neat thing to play around with.

"treats the parse tree as the program"?

[Ducky]

I've heard that somewhere before...

Oh yeah. In my ANSI Common Lisp book. Something about the real power of Lisp being that everything, including the program itself is just a tree structure.

I guess programming languages really are slowly merging. Java isn't getting macros now, but I suspect in another 5 or 10 years it'll be something else Java will do. =)

-Ducky

LISP, the religion

[melquiades]

Yes, yes, I had to deal with all the "Lisp did it first" comments when Eidola was on Slashdot.

While it's true that the program is the parse tree in Lisp, that's not a very strong statement. Lisp's elegance comes from the fact that there are so few constructs in the language, and basically everything is a list -- even your programs. But they're basically just lists, that's all. So you have this wonderful flexibility, but the parse tree doesn't actually tell you very much about the program; you have to "parse the parse tree" to recognize higher-level constructs.

Now languages with lots of language-level constructs -- like strong static types, objects, access modifiers, etc. -- tell you a whole lot about high-level structure with their parse trees. (And, for those following along at home, Lisp is not such a language -- not that that's a bad thing, but it isn't. Lisp builds these high-level constructs out of a very few language-level atoms.) To my knowledge, applying the "language is the parse tree" principle to non-functional languages is still largely the domain of research projects like Jackpot, Eidola, and Intentional Programming, and visual languages.

Moral: Lisp is very, very, very cool, but it has not already done everything every other language is doing. So yes, it may sound familiar from you Lisp book, but it's not the same.

Re:LISP, the religion

[__past__]

Lisp's elegance comes from the fact that there are so few constructs in the language,

There are 978 symbols defined in the ANSI Common Lisp standard, some of which concurrently name types, classes, functions and declarations.

and basically everything is a list

.. except arrays, symbols, objects, structs, characters, numbers, pathnames, streams, packages...

(OK, that's enough to prove I'm a SmugLispWeenie, I guess ... ;-)

But they're basically just lists, that's all. So you have this wonderful flexibility, but the parse tree doesn't actually tell you very much about the program; you have to "parse the parse tree" to recognize higher-level constructs.

No. You can parse the parse tree to reason about or modify programs. You can as well use higher-level constructs, for example asking for the class of an object and manipulate it, the declared types of variables and functions, etc. The whole metaobject protocol is about giving you an object-oriented interface to your program internals, and the same style shows in various other places. Basically, a lot of what is lost at compile-time in most other languages is a live first-class object in Lisp - for a simple example, you can get the package of a symbol, see what other packages it imports, change its name, and make some symbols in it not being exported.

Moral: Lisp is very, very, very cool, but it has not already done everything every other language is doing. So yes, it may sound familiar from you Lisp book, but it's not the same.

Indeed. But Lisp is the only language so far that allowed adding new concepts in portable ways, without having to modify the underlying implementation. CLOS, the object system, is basically a bunch of functions and macros, and if you don't like its class/generic-function based approach, just load a package that implements a prototype-based one and use that. An implementation of Eiffel-style design by contract is about two screenful of code, adding final and abstract classes is less.

Are these additions "language-level constructs"? Hard to tell. The syntax the programmer deals with is just as if it were, even if everything eventually gets expressed in lower-level terms. The distinction is just not meaningful in Lisp - there just is no hard barrier between the language designer and the user, Lisp users design their language all the time.