Jackpot - James Gosling's Latest Project 208
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."
java < emacs (Score:4, Insightful)
"treats the parse tree as the program"? (Score:5, Insightful)
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 [slashdot.org] now, but I suspect in another 5 or 10 years it'll be something else Java will do. =)
-Ducky
Can't RTFA, but... (Score:1, Insightful)
Re:IntelliJ (Score:3, Insightful)
For those of you that have no idea what IntelliJ IDEA is, check it out [intellij.com]
Gosling is a hypocrit (Score:0, Insightful)
Re:I almost laughed out loud at this line... (Score:5, Insightful)
"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.
Re:"treats the parse tree as the program"? (Score:5, Insightful)
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.
LISP, the religion (Score:5, Insightful)
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.
Jackpot vs. Sun's Last Stand (Score:3, Insightful)
if people like Gosling could show Jackpot
and its benefits in a BUSINESS CONTEXT.
- Code gets cleaner, easier to maintain & debug.
- Multi-thread scaling areas get easier to spot.
- Profiling tools speed up based on the algebra.
- IT staff in mergers can finally merge apps.
Sure the technology is "cool" and "entertaining"
but these days Sun needs a profit.
Cheers, Joel
Re:Just Great (Score:4, Insightful)
Chuckle... my poor friend, why don't you just upgrade to the lizard [mozilla.org]? :-)
Re:"treats the parse tree as the program"? (Score:3, Insightful)
I could imagine that, 10 or 20 years from now, it will also have the missing pieces, like fast compilers, a decent exception/condition system (I want restarts, dammit!) and an extensible syntax (i.e. proper macros), although the latter might be hard. It will then be as good as Common Lisp is at least scince it's become an ANSI standard in 1994.
I doubt that XML will be an issue at that time, however. At least right now it seems that current W3C activities make a lot of people look back to the ease and consistency of SGML.
Re:LISP, the religion (Score:3, Insightful)
While it's true that the program is the parse tree in Lisp, that's not a very strong statement.
True.
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.
Hmm, except for the arrays, hashtables, structures, objects, compiled functions, strings, rational integers, bignums, system pointers, etc that Common Lisp provides.
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.
We always have to convert information into meaning somehow. Do I want to recognize a high-level construct such as:
(dotimes (i 10) (format t "~A~%" i))
or maybe I want it represented as a standard looping form:
* (macroexpand-1 '(dotimes (i 10) (format t "~A~%" i)))
(DO ((I 0 (1+ I))) ((>= I 10) NIL) (DECLARE (TYPE (INTEGER 0 10) I)) (FORMAT T "~A~%" I))
Perhaps I want to see it as just variables and gotos, with type information that the system inferred:
* (macroexpand '(dotimes (i 10) (format t "~A~%" i)))
(BLOCK NIL
(LET ((I 0))
(DECLARE (TYPE (INTEGER 0 10) I))
(TAGBODY
(GO #:G1125)
#:G1124
(FORMAT T "~A~%" I)
(PSETQ I (1+ I))
#:G1125
(UNLESS (>= I 10) (GO #:G1124))
(RETURN-FROM NIL (PROGN NIL)))))
Or maybe even as its assembly code:
(defun f () (dotimes
(disassemble 'f)
48262DC0:
DD8: POP DWORD PTR [EBP-8]
DDB: LEA ESP, [EBP-32]
DDE: TEST ECX, ECX
DE0: JNE L2
DE2: XOR EBX, EBX ; No-arg-parsing entry point
DE4: JMP L1
DE6: L0: MOV [EBP-16], EBX
DE9: MOV [EBP-12], ESP
DEC: SUB ESP, 12
DEF: MOV EDX, 671088679 ; T
Reasoning about programs happens at many levels, Common Lisp seems to provide a lot of the tools.
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.
Well static typing makes the parse tree richer in the same way that requiring you to list your religion on a driver's license application makes the DMV's database richer. I'm not convinced of the benefit.
Objects are cool - Common Lisp has them (and they are more powerful than Java's or C++'s by far.)
Access modifiers are either a declaration that you are more intelligent than your users, or a way to hide your bad code from other people. I know that's a bit cynical, but I've noticed that in good programming teams, almost everything winds up public (especially in environments that encourage shared code ownership, support interactive debugging/programming, etc.)
(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.
Perhaps. I think Lisp programmers tend to worry less about refactoring and the like because they have a very powerful macro system, strong compilers that infer a lot of stuff, and a representation that blurs the line between program and data. You write down the stuff you understand, play with it interactively, understand it better, write a few macros or functions to shift code to data and vice versa, repeat until done.
Re:"treats the parse tree as the program"? (Score:2, Insightful)
Oh, absolutely. I agree 100%. My sarcasm intentionally was based on truth.
Basically what I was saying (which is certainly not my own discovery) is that the semantics of Lisp/Scheme/Other Lisp Dialects move "language features" into the realm of the developer (as opposed to the language designers). Plus there is the bonus of being able to operate on the program itself. And for these reasons, pretty much any feature somone is planning to add to a language has either been done in Lisp a long time ago, or is easy to add without acually redesigning the language.
Take Java (which I work with daily) as a complete opposite. You want a new feature? AOP, generics, etc, you^H^H^H the people at Sun have to oficially redesign the language.
Getters/Setters (Score:2, Insightful)
One piece of analysis, therefore, is to find all the public instance variables. But we can find them and also make them private, add all the setters and getters, and account for what it means to actually access the variables via setters and getters.
As I've said before, Gosling appears to have oblivious to most of the research that had gone on in the field of object-oriented languages.
Java should been designed from the start to enforce getter/setter access to instance variables. This feature has long been recognized to be a desirable feature in an object-oriented language. I think Self, Dylan, and other object-oriented languages got this feature right.
Re:James Gosling versus Guido van Rossum (Score:3, Insightful)
Bzzzt! Wrong answer!
What *really* matters (to me, anyway) is staying employed. Your strategy employs two faulty tactics: lying and not focusing on what the customer needs or say they need. If you lie about your experience, then be prepared to accept the consequences when you're found out. If you do a project in Python when a customer specifically requests Java, then be prepared to lose the business.