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

It's the Matrix!

[greg_barton]

So you can write what is kind of like a reverse grammar, where you associate structural patterns with what you can think of almost as TeX descriptions of how to represent the patterns graphically. What you see on the screen has been generated from this pattern matching. So we can, on a user chosen basis, turn various program structures into all kinds of visual representations.

Why, methinks he's reinvented the Matrix. :)

Re:Here are the tips

[Anonymous Coward]

Always document your code so that a mentally retarded 6 year old can understand what you mean.

I learned that when doing math proofs. It it wasn't written so retarded 6 year old can understand it, the TA took off marks.

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"?

[namespan]

'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...

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

[swagr]

*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*

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.

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

[__past__]

Maybe in another 10 or 20 years ALL programming languages will be as powerful as Lisp.

Actually, the other languages do make progress in that direction. Look, for example, at Python: It has objects, metaclasses, introspection, an interactive environment, functions as data (even if lambdas could've been done better), strong dynamic typing, runtime extensibility (albeit clumsy), not to mention small conveniences like keyword and rest args or docstrings.

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:"treats the parse tree as the program"?

[swagr]

>Actually, the other languages do make progress in that direction.

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.

I almost laughed out loud at this line...

[Anonymous Coward]

"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."

So says the creator of Java. I wonder if he's bothered to browse the API lately?

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.

Aw, crap.

[Qweezle]

Does this mean it will be any easier for me to learn Java? Probably not. Will I ever learn Java? Of course. Let's be honest, Qweez No. Probably not.

My opinion?

[jabbadabbadoo]

Gosling + Martin Fowler = Jackpot! If you didn't know, Fowler is THE refactoring guy. They should team up.

Now, put this support straight into emacs and I'll be happy.

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.

Re:IntelliJ

[SpryGuy]

IntelliJ IDEA just plain rocks. I don't know how I coded without it before. Anything else seems like coding with freakin' NOTEPAD.EXE (shudder)

For those of you that have no idea what IntelliJ IDEA is, check it out

Re:IntelliJ

[SpryGuy]

No, it is not free nor is it open source. You do, however, get what you pay for. The cost is a factor, though, so it may not be for you.

It's supremely configurable, very keyboard friendly, and has more and better features than its rivals, and runs faster with a better UI.

I personally have not used Eclipse, so I cannot make the judgement myself, but I've read threads debating the merits of the two, and IntelliJ's IDEA seems to come out ahead in the end.

Personally, I like the ease of use and intuitiveness. You don't need to work 'its way', but the more you use it, the more features you learn about, and many times the reward is big enough to warent changing long-time habits. One example:

Type out the word 'new' and the first few letters of the class you want. Then hit the 'code completion' key, and then hit 'introduce variable'. Wham. It completes the entire line, declaring the variable in line. You save a vast amount of typing. Or you can 'program by intention'... just start typing code. If you type a method name or variable that doesn't yet exist, just hit Alt-Enter and it'll let you create it. A simple 'back' button and you're back where you were to continue coding.

Code inspections find potential Null Pointer Exceptions and other common issues and errors; never worry about managing imports again; fold away code you don't want to see; automatically detects out of date or erronious javadocs and flags them; incredible refactoring support (rename variable, method, class; push method or varible up or down the inheritance hierarchy; introduce methods and variables; extract methods from inline code; inline methods; change method signatures; etc); real-time syntax checking and error/warning highlighting (see at a glance if you have any unused variables, private methods, typos, etc); awesome code completion; great code navigation (jump to implementation/declaration, forward/back); intelligently "find usages" of specific variables or methods; call and inheritence hierarchy trees; ....

I could go on forever. Plus, if there's anything you think is missing, or don't like, you can easily write a plug-in to add it or modify the behavior. Many people have. IntelliJ even has a WIKI site for users to post their own plug-ins. They also have an excellent bug reporting system, and they're very responsive.

Re:Here are the tips

[skepton]

Hey this is my first post. I have angry half-baked opinions tho. I find that commenting for a retarded 6 year old makes code unreadable. Have you ever tried to find anything in the apache tomcat sourcecode using only notepad? Why is there a comment on "getInfo()" that says "Returns the info."??? Some classes I was trying to understand I just went through and deleted every comment so I could read the damn thing. Turns out the class was only like 12 lines of code. It was like shaving a cat.

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:Modified Godwin's Law

[JamesOfTheDesert]

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

I don't understand you. Does that mean I have to kill you?

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.

babblefish translation please

[frovingslosh]

OK, I read the article. What the hell are they talking about?

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

[Gorobei]

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: .ENTRY "LAMBDA NIL"() ; (FUNCTION NIL NULL)
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: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.

Re:LISP, the religion

[melquiades]

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. :)

Jackpot vs. Sun's Last Stand

[joelparker]

Sun would have a better chance surviving
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

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)

Re:Just Great

[rsborg]

'Jackpot' an unlucky click and it might take 20 min to undo the popdowns

Chuckle... my poor friend, why don't you just upgrade to the lizard? :-)

Sounds like LISP to me

[Sayjack]

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.

Appropriate

[Markus Registrada]

Alex Stepanov famously described Java as "a money-oriented programming language". I guess that makes the name "Jackpot" an appropriate name. I suppose the next projects will be "Jingle" and "Jyp".

So what's new?

[e__alf]

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>

Gamma and OO

[schouwl]

For me as along time programmer this feels like moving from C to C++. You can discuss your program on a whole other abstraction level.
GREAT.
Things are getting very interesting in the field of improving the coding process. I still remember Sniff C++ started by Eric Gamma in the early 90-ties. This was the first product to visualize/navigate over large C++ projects that blew me away. One can certainly see this approach in Eclipse - one of the latest projects of Eric Gamma.
A few very smart IDEs appeared - CodeGuide, Eclipse, IDEA.
Eric Gamma was working in an IT research lab in the UBS in Zurich in Switzerland before he became really famouns with his GoF book.
Lars

Link to Jackpot home page

[gwernol]

Not a great deal there yet, but if you're interested in Jackpot then the Jackpot home page would be worth bookmarking for future reference. Their early work on source code metrics is interesting and the published papers listed are a good starting point for more detailed information than can be delivered in an interview.

Not new

[dr2chase]

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.

Getters/Setters

[oodl]

Gosling spoke:

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.

The Refactoring Browser

[JustAClam]

Most of this stuff isn't new. The first general refactoring tool I ever saw was the RefactoringBrowser built by John Brant and Don Roberts at the University of Illinois at Urbana-Champaign. It uses Smalltalk parse trees to analyze code, perform refactorings, lint checks and code rewrites. It's free and has been incorporated into VisualWorks Smalltalk, Dolphin Smalltalk and Squeak, and is available as an add-on for VisualAge Smalltalk. To see the kinds of refactorings supported, check out: http://st-www.cs.uiuc.edu/~brant/RefactoringBrowse r/Refactorings.html

To see the lint checks available, look at:
http://st-www.cs.uiuc.edu/~brant/RefactoringB rowse r/Lint.html

And to see the parse tree based rewrite tool, go to: http://st-www.cs.uiuc.edu/~brant/RefactoringBrowse r/Rewrite.html

To see how long this has been available and something of it's evolution, check out the HyperNews page at http://st-www.cs.uiuc.edu/HyperNews/get/Refactorin gBrowser.html and look at the dates. People use this free tool set every day.

Re:James Gosling versus Guido van Rossum

[Da VinMan]

Your opinions about Python are all well and fine but if you have the choice between Java and Python on a project, use Java.

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 .pyc files in there.

*sigh*

Re:James Gosling versus Guido van Rossum

[daveinthesky]

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.

A commercial Lisp system did this...

[alispguru]

... in 1987. I worked for Xerox AI Systems at the time and was one of the developers for the Lyric release of LOOPS.

LOOPS had:

A single-inheritance object system with GUI support (class, method, and object browsers).

Editing with structure editors that manipulated the parse tree directly. The structure editor was also used as the inspector in the debugger.

refactoring support in the browsers (select a method and move it to another class, etc).

automated global refactoring based on code analysis - this being 1987, it had a pseudo-natural language interface (EDIT ALL METHODS CALLING FOO AND REFERENCING *BAR*...).

LOOPS is one of the primary predecessors of CLOS (the other being Flavors).

Parse-tree-based editing has been around for awhile - Google for "syntax directed editing". Paradoxically, it works much better in Lisp than in other, more syntax-heavy domains; when your editor insists that everything be syntactically and semantically well-formed all the time, it's best that there be very few, very general syntax rules. This is why it also works in Smalltalk.

Re:java emacs

[73939133]

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.

Re:James Gosling versus Guido van Rossum

[Da VinMan]

That's a bad reason, if any...JUST LIE!!!! Does it really matter? What _really_ matters is doing it right and doing so efficiently.

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.

Re:James Gosling versus Guido van Rossum

[daveinthesky]

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).