Slashdot Mirror
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."
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.
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.
'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.
Or on Paul Graham's website. Wonder if Gosling will be coming up with something to compete with Graham's ARC...
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
*sarcasm*
Maybe in another 10 or 20 years ALL programming languages will be as powerful as Lisp.
Then 10 years after that, we can start passing around s-expressions instead of XML because "the data is the program".
Wow. The "future" looks grand.
*sarcasm*
-... ---
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.
About 20 years ago, there was a vigorous debate about how to design the ideal Lisp editor. One camp argued that the editor should manipulate the parse tree, and the other camp preferred to leave the user in control of the program as text.
In the end, the text representation proved to be more versatile in practice, largely because of the extensibilty of editors like Emacs.
Gosling of course is intimately familiar with this debate, and with the factors which might now exist to tip the balance the other way. It's likely to be a much more nuanced debate this time around.
When writing LISP you're pretty much expressing a parse tree as a program, and yes, LISP does have some advantages when it comes to expressing certain solutions in an elegant manner.
Such a language, much like LISP, might be quite useful with respect to genetic programming.
In addition, a parse tree language which has lots of internal understanding of data flow might make for a good intermediate step in a compiler or perhaps become a better LISP.
It's good to see that Gosling isn't resting on his Java laurels but applying what he's learned in new areas of research.
-- Good judgement comes with experience. -- Experience comes with bad judgement.
Hmm... most of what he talks about has been available in proper languages for decades! I'll even try, as a public service, not to mention LISP :]
:)
Smalltalk has this:
(3/5) class methodDictionary at: #+
which will give you the + method for the Fraction class. From that object (the CompiledMethod) you can get the original source code (if it's available), or a parse tree. The parse tree will give you indices into the original source, in case you should need to do a GUI for your IDE
Say you're writing a debugger (which you can actually do, unlike in Java, where the debugger needs to run externally).. the MethodContext knowns at what opcode execution stopped, the parse tree knows which part of the source that represents. This means you can step operator by operator through an exression... no "line numbers".
You can *fake* some of these things in java, but it's not pretty - something like IntelliJ has to use its own special compiler and huge amounts of support code, and it's just plain impossible in Java for a system to debug itself.
Go play: free-as-in-beer-for-personal-use and nice / free, cute, fluffy and sluggish
</preach>
(OK, that's enough to prove I'm a SmugLispWeenie, I guess ... ;-)
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. 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.
Programming can be fun again. Film at 11.
Besides Lisp and Eclipse and IntelliJ, this sort of syntax-tree-oriented manipulation has been going on in optimization and programming language research for the last 20 years. (And Eclipse does a fine job -- all that chit-chat about encapsulating public instance variables is just a choice on the refactoring menu, and it's free. I've got no idea why Gosling thinks this is new and interesting.)
For example, people (including me) at Rice University worked on a source-to-source Fortran vectorizer that manipulated ASTs. Derivatives of that AST reappeared in the Dana/Ardent/Stardent compilers for C and Fortran. The Fortran AST was also used in an AST-based editor, a Fortran interpreter/debugger, a pretty printer, an ugly (fixed-format card image) printer, and dependence-displaying Fortran browsers (dependence here refers to loop iteration dependences that hinder parallelization).
One thing that became clear while working on AST-based editors was that people didn't want the tree structure continuously in their face. For example, at the expression level, Fortran programmers (as opposed to, say, Lisp programmers) found tree-based editing to be intolerable. The tree structure can be handy for browsing/skimming code; uninteresting blocks of code could be elided. But, people did not want to be prevented from making changes that were "only" syntactic.
Keep in mind, this is just the Rice-centric view, other people were doing things like program slicing (what code depends on the value of this variable). I'd love to see some of this stuff nicely integrated into an IDE -- that nice integration is the hard part, the theory is generally done and old.
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.
:)
Well, yeah, and that's just the thing -- because it's so wonderfully extensible, your ability to reason programmatically about a program is limited. To analyze an object in Lisp, as I understand it, your analysis system would need to know not just about the language, but about the particular functions and macros you've used to build your object system. Because your atoms are so small, your analysis system starts needing an awareness of molecules. You can still feed your code into a Jackpot-style theorem prover, but there's more case-by-case analysis involved to analyze the code at the same level of abstraction.
So I guess my point is really just that Lisp has very small atoms. Objects, at least as I understand them, are definitely not language-level constructs, because you don't need to code any knowledge of them into the compiler or the runtime. Again, I don't mean to say that's a bad thing, because the MOP is insane crazy cool.
arrays, symbols, objects, structs, characters, numbers, pathnames, streams, packages...
Yeah, yeah, OK, I admit, I only actually ever worked in Scheme, and very basic Scheme at that. You know, you're quite the SmugLis-...oh, you already linked it. Never mind.
Your opinions about Python are all well and fine but if you have the choice between Java and Python on a project, use Java.
.pyc files in there.
Even though I happen to agree that Python is a better language (for the most part), I would always stick to Java. I chose Python on a project I did. I would much rather have that experience on my resume as Java instead. Python is nice, but employers just aren't looking for it.
Sad, but true.
On a side note: Microsoft Site Server 3.0 was written in Python by the original shop that wrote it (an acquired product). No one would touch the source until they moved it to C++ for the next version of the code (it's called Commerce Server now). If you don't believe me, install Site Server and look for the
*sigh*
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
Even though I happen to agree that Python is a better language (for the most part), I would always stick to Java. I chose Python on a project I did. I would much rather have that experience on my resume as Java instead. Python is nice, but employers just aren't looking for it.
Sad, but true.
Python is nice, but employers just aren't looking for it? That's a bad reason, if any...JUST LIE!!!! Does it really matter? What _really_ matters is doing it right and doing so efficiently. If python gives you an advantage in being able to rapidly prototype and develop, then that is every reason to choose it.
Yes, and do you realize the significance of Gosling Emacs? It was its proprietary nature. Gosling Emacs was what finally got GNU Emacs off the ground as a successful open source Emacs implementation for UNIX systems.
Gosling has been hostile to open source from day one. He created NeWS and tried to kill off X11, and he was probably partially behind keeping Java proprietary.
I would much rather have that experience on my resume as Java instead. Python is nice, but employers just aren't looking for it.
If the customer specifically requests java, then that is a different story altogether than lamenting over prior experience being spent on a project in language X over language Y. Clueless customers go with the flow (the buzzwords, etc) without understanding the technology. Do you really want them making your technical decisions for you?
I agree with you that I do not condone lying. But if you are in a situation ["What *really* matters (to me, anyway) is staying employed"] where you really need a job (kids, spouse, rent, etc), then something as trivial as what language a past project was coded in is truly irrelevant. In which case, I can understand someone increasing their chances by 'flipping bits' on their resume; I've seen countless resumes go down the trash shoot for plenty of other trivial reasons ("it looks ugly!!", etc).