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.

java < emacs

[dankelley]

"Creator of Java"? What's that? How about "the creator of Gosling Emacs"?

"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

Re:"treats the parse tree as the program"?

[Shackleford]

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.

Well, actually, there seems to be more to Jackpot's methods of code visualization than that. Lisp code can be thought of as having a tree-like structure, but it may not be as clear as what Jackpot's visual representation my be. What Jackpot would do is show the annotated parse tree, so it can give much information about how it is constructed. It would be a useful graphical representation that appears to go beyond what Lisp code would show, and with that representation and the source code, you can get the best of both worlds.

Anyway, they also mention that you can implement a "reverse grammar" that would take data formed in parse trees and make code more readable. For example, you can have Greek letters and other mathematical notation such as the square root symbol. If you have long equations in your program, this could be very useful in making your code readable, and thus understandable.

So what Jackpot seems to be is a way of giving different ways of viewing the code you write, which, IMHO, can go a long way in solving problems with it and simply improving on it.

IntelliJ

[MaxTardiveau]

Isn't that what IntelliJ does already? I use it as my main IDE, and it has an amazing understanding of Java -- it allows you to refactor just about anything.
When working in it, you feel like you're not just editing Java -- you're editing the fully integrated structure of your software.

Modified Godwin's Law

[MagikSlinger]

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.

As a Slashdot thread on a programming language progresses, the probability of someone claiming that "Lisp already does that" approaches unity.

Re:Modified Godwin's Law

[MeerCat]

As a Slashdot thread on a programming language progresses, the probability of someone claiming that "Lisp already does that" approaches unity.

If I had mod points I'd mark you up as funny - but have you read and grokked the Meta Object Protocol ?? Because much as I hate Lisp at the lower syntactic levels, I keep on finding that features I like in other languages were actually present in the MOP and similar. That's not to say that other languages don't present the ideas in better and easier-to-use ways, but it still pisses me off that those beardie-weirdie Lisp blokes had already thought of it so much earlier...

We kill what we fear, and we fear what we don't understand....

--

Re:I almost laughed out loud at this line...

[MeerCat]

Ditto.

"Complexity is in many ways just evil. Complexity makes things harder to understand, harder to build, harder to debug, harder to evolve, harder to just about everything." -- Gosling

Software entities are more complex for their size than perhaps any other human construct because no two parts are alike. If they are, we make the two similar parts into a subroutine - - open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound. -- Fred Brooks, Jr.

Which quote tells you more ? Which quote has more insight ? Which quote came 30 years earlier ?

Here's a clue - complexity in software doesn't usually vanish at some magical point, we just aim to achieve a position where our view of inherent complexity in a problem becomes optimally manageable. As the fundamental point of interest within a problem domain changes over time, so will the optimal viewpoint. The point of re-factoring is to move our viewpoint according to what we want to do now, not what we wanted to do when the code was written.

Gosling is talking techno-babble... tell him to draw a parse tree of any meaning in his jargon.

Sounds vaguely functional

[Larne]

Some of this is reminiscent of things the functional programming language folks have been doing for a while. In particular the parse tree concept sounds a bit like graph reduction, which runs programs by repeatedly simplifying the graph which it (where the graph is a generalization of a parse tree). One of the things you can do with such a system is "common subexpression elimination" where common subtrees are moved to single point, ensuring they're evaluated only once. Sounds like a specialized form of refactoring, doesn't it...?

Of course all this is easier in functional languages, because you don't have to worry about state, identical trees will always evaluate to the same value. Not so in Java, if any of the nodes refer to global data.

I wonder how often Gosling talks with Guy Steele, who was pivotal in the development of both Scheme and Java. I'd love to see what they'd come up with if they put their brains together.

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.

Just Great

[sammyo]

When you googled for something *java* it was anoying enough to deal with stupid $tarbuck$
links, with 'Jackpot' an unlucky click and it might take 20 min to undo the popdowns, offers for the *best internet casino*... and oh my gawd, add to the wrong mail list!

(I was going to add an example link but I wouldn't do that to my worst enemy)