Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Jackpot - James Gosling's Latest Project 208

Posted by michael from the bingo-eureka dept.
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."
This discussion has been archived. No new comments can be posted.

Jackpot - James Gosling's Latest Project More

Jackpot - James Gosling's Latest Project

Comments Filter:

  • It's the Matrix! (Score:4, Funny)

    by greg_barton ( 5551 ) * <greg_barton&yahoo,com> on Friday June 13, 2003 @05:29PM (#6195688) Homepage Journal
    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. :)

  • Interesting (Score:5, Interesting)

    by The Bungi ( 221687 ) <thebungi@gmail.com> on Friday June 13, 2003 @05:35PM (#6195724) Homepage
    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.
    • I wouldn't be surprised if DotNet could do this already in its underlying form. The translation of its syntactic languages would be much more manageable if it were in a tree form.

  • java < emacs (Score:4, Insightful)

    by dankelley ( 573611 ) on Friday June 13, 2003 @05:37PM (#6195739)
    "Creator of Java"? What's that? How about "the creator of Gosling Emacs"?
    • yes, java emacs. but gosling emacs real emacs. hell, i'm sure gosling emacs efuns AND gosling emacs efuns. i mean, this is gosling- at least NeWS was a good idea. :)
    • Gosling Emacs, NeWS and SC should also be mentioned. Not all well known now, but all things I've used and appreciated.

    • Re:java emacs (Score:4, Interesting)

      by 73939133 ( 676561 ) on Saturday June 14, 2003 @01:20PM (#6200217)
      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.

  • "treats the parse tree as the program"? (Score:5, Insightful)

    by Ducky ( 10802 ) * on Friday June 13, 2003 @05:39PM (#6195750) Homepage

    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

    • '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 [paulgraham.com] website. Wonder if Gosling will be coming up with something to compete with Graham's ARC...
    • *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*

      • 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 wil

        • >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 ad

    • Modified Godwin's Law (Score:5, Funny)

      by MagikSlinger ( 259969 ) on Friday June 13, 2003 @05:56PM (#6195881) Homepage Journal
      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 (Score:5, Flamebait)

        by MeerCat ( 5914 ) on Friday June 13, 2003 @06:07PM (#6195967) Homepage
        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....

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

        The previous times the people who said LISP could do *everything* were arrogant fools. LISP can do everything, yes, but it could only do those things in a very annoying fashion.

        In this case however, this guy took all the features that LISP had and he took all the annoyances that LISP had and he basicely copied the entire thing. He goes out of his way not to menti


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

        Unlike Godwin's Law, though, the probability that the claimant is correct also approaches 1.

    • Re:"treats the parse tree as the program"? (Score:5, Insightful)

      by Shackleford ( 623553 ) on Friday June 13, 2003 @06:05PM (#6195947) Journal
      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.

    • LISP, the religion (Score:5, Insightful)

      by melquiades ( 314628 ) on Friday June 13, 2003 @06:09PM (#6195984) Homepage
      Yes, yes, I had to deal with all the "Lisp did it first" comments when Eidola [eidola.org] 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 (Score:3, Insightful)

        by Gorobei ( 127755 )

        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 p
        • 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.

          It (the former) tells you the set of messages (or methods, whatever you wanna call them) that it is legal to send to the value in question. It tells you what kind of thing the value is supposed to be. How can that not be useful in analysis?

          Perhaps. I think Lisp programmers tend to worry less about refa

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

            It (the former) tells you the set of messages (or methods, whatever you wanna call them) that it is legal to send to the value in question. It tells you what kind of thing the value is supposed to be. How can that not be useful in analysis?
            I'm sure it's useful in analysis - the question is what the analy
            • For any large system, proofs are impossible

              I would dispute that. All you have to do is prove that each part works as specced and that no interactions throw the whole thing out of whack. In other words, "unit proving" and "integration proving", akin to unit testing and integration testing.

              type checking sees diminishing returns after 300k lines of code or so.

              But type checking alone, without contracts, is only a very formalistic, shallow process - so it's not surprising that it would catch a tiny fract

          • "It (the former) tells you the set of messages (or methods, whatever you wanna call them) that it is legal to send to the value in question. It tells you what kind of thing the value is supposed to be. How can that not be useful in analysis?"

            Well, it doesn't help any in a language where anything and everything can be done at run-time. Most problems that benefit from this type of analysis are hard, and most hard problems are very dynamic. Besides which, what benefit would this have for analysis beyond the

            • Well, it doesn't help any in a language where anything and everything can be done at run-time.

              I don't understand your point. Yes, you may be able to send a "GiveBirth" message to a "Man" object, but that doesn't mean it will make any sense to do so.

              Strong typing in the context of a "pointerfree" language, and appropriately used, only prevents you from doing things that make no sense.

              And also absolve them from the responsibility of designing their classes well the first time.

              Oh come on. Ever heard

      • Re:LISP, the religion (Score:5, Interesting)

        by __past__ ( 542467 ) on Friday June 13, 2003 @08:10PM (#6196602)
        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 [c2.com], 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.

        • 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 analyz
          • Yeah, yeah, OK, I admit, I only actually ever worked in Scheme, and very basic Scheme at that.

            That explains a lot of what you were saying here. While Lisp has one of the biggest language reports, Scheme reports is one of shortest. Both among all programming languages.

            No offense, BTW. I've just tried to explain the major difference between Lisp and Scheme.

    • real power of Lisp being that everything, including the program itself is just a tree structure.

      Lisp 1.5 in someways wasn't Lisp 2.0 because the original form of the language was in terms of "M-expressions" that looked like mathematical expressions and Fortran. The idea was to have a compiler that translated the M-expressions into the internall forms of S-expressions. However as John McCarthy Says [stanford.edu]

      The project of defining M-expressions precisely and compiling them or at least translating them into S-exp

    • I was thinking the same thing. What's the difference between this and LISP or XSLT? I don't think this guy is an inventor of anything. A reinventor and possibly a brilliant marketer, yes. An inventor, I don't think so.

  • I almost laughed out loud at this line... (Score:2, Funny)

    by 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... (Score:5, Insightful)

      by MeerCat ( 5914 ) on Friday June 13, 2003 @05:59PM (#6195902) Homepage
      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.

      • Gosling is talking techno-babble

        Hardly. What he's saying there is (to expand a little), when code becomes too complicated, it becomes hard to understand, and thus people waste a lot of time trying (and often failing at first) to debug, evolve etc.

        Obviously, he skipped a word or two there, making his statement less than 100% accurate - as any normal human being is wont to do in ordinary conversation - a fact which many overly critical Slashdotters are prone to ignoring!

        I'm surprised you find the quote

        • Hardly. What he's saying there is (to expand a little), when code becomes too complicated, it becomes hard to understand, and thus people waste a lot of time trying (and often failing at first) to debug, evolve etc.

          I meant the article was techno-babble. The selected quote (that made me and others laugh) was just plain banal: "complexity is complex" - gee whiz, James, why not say "good is good and bad is bad" - the point is that complexity the fundamental problem we're attempting to manage. If that's as de

          • The quoted sentence was just dumb. The rest of the article was techno-babble. And I'm sorry I haven't convinced you of my right to comment on it, but I stand by my statement.

            Neither is the quote dumb nor is the article techno-babble.

            The article does not ask you to agree in any way with Goslin. The article tells you what Goslin is working on currently. If you dont find his work exciting then there are basicly 2 reasons possible: a) you are not interested in that research area. b) you did not understand
            • Neither is the quote dumb nor is the article techno-babble.

              Hmm, lets take the quote which makes people laugh out loud (why do you think they do that - is it because they think it's a statement of genius ??)....

              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, he says, complexity is hard. Well, that's a truly deep insight. Can you see anything else of value in this quote - I can't.
        • Hardly. What he's saying there is (to expand a little), when code becomes too complicated, it becomes hard to understand, and thus people waste a lot of time trying (and often failing at first) to debug, evolve etc.

          Why does code become too complicated in Java? Because the language was designed poorly and lacks good mechanisms for abstraction.

          If Gosling were concerned with "complexity" or knew anything about how to manage it, he would have designed a better language. Jackpot is not a solution to Java's
    • I *did* laugh out loud at that one. The only thing more amusing would be to see the same quote by the folks who created C++. :) Why Objective-C doesn't get more attention is quite beyond me...
    • Huh? I find the Java API to be incredibly well documented, and usually very intuitive when you need to learn new parts of it. It's only complex if you are trying to learn it in its entirety, and it's not really complex at all compared to the overwhelming amount of stuff you need to do in many programs that it will do for you.

      I challenge you to program in Java for a year or so then go back to C++, Python, or pretty much anything else. It may feel great to stretch your legs out and exercise some syntacti

  • Aw, crap. (Score:3, Funny)

    by Qweezle ( 681365 ) on Friday June 13, 2003 @05:41PM (#6195764) Journal
    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.
  • [infoworld.com]
    Gosling likes idea of open source Java

  • My opinion? (Score:3, Informative)

    by jabbadabbadoo ( 599681 ) on Friday June 13, 2003 @05:45PM (#6195796)
    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.

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

      EmacsOS does not support this yet? Wow, thats weird. (Goes back to controlling his water heater temperature from Emacs)

  • IntelliJ (Score:4, Interesting)

    by MaxTardiveau ( 629919 ) on Friday June 13, 2003 @05:46PM (#6195803) Homepage
    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 (Score:3, Insightful)

      by SpryGuy ( 206254 )
      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 [intellij.com]

      • IntelliJ IDEA just plain rocks. I don't know how I coded without it before.

        Let me give a hearty amen. It's so amazing that a colleague even dropped Emacs for it. That's like quitting the Borg.
        • Exactly. I know several people who gave up emacs for it. One guy has always hated IDEs with a passion, but once he saw the refactorings and ability to easily browse the code, he made the switch and has never looked back. He still hates IDEs, but he loves IntelliJ IDEA :-)

  • Sounds vaguely functional (Score:5, Interesting)

    by Larne ( 9283 ) * on Friday June 13, 2003 @06:00PM (#6195913)
    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 [brighton.ac.uk], 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 (Score:3, Funny)

    by frovingslosh ( 582462 ) on Friday June 13, 2003 @06:01PM (#6195921)
    OK, I read the article. What the hell are they talking about?
  • What's an environment that does the same thing, but for C? I can see that macros could foul up the works unless the system is extensible.

  • Jackpot vs. Sun's Last Stand (Score:3, Insightful)

    by joelparker ( 586428 ) <joel@school.net> on Friday June 13, 2003 @06:13PM (#6196007) Homepage
    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

    • Have you read an article on Java.sun.com lately? Sun makes those kinds of arguments wrt their shipping technologies all the fricken time. Not in an overly pushy way IMO like some companies, and not in a moronic vapid way like those MS ads in Dr. Dobbs Journal (Do MS think that Dr Dobbs readers are complete morons??) But they do. It's refreshing to read an article with a complete lack of such, even if I can't follow it all.

      Sun probably does not want to market a tech which may not go into production for yea

    • You get cleaner, easier to maintain, and easier to debug code, and better multi-threaded scaling simply by avoiding J2EE and some of Sun's other libraries.

      As for "merging apps", that's almost always a stupid idea to begin with. The parts of apps that were designed to be reusable should already be in identifiable libraries. The parts of apps that weren't designed to be reusable shouldn't be merged. If they do need to interact, have them communicate via IPC, RPC, DOs, or some database.
  • Anyone remember seeing the programming language called Whitespace. It uses a similar methodology where indentation and heirarchy are the key to the language. :)

  • Just Great (Score:4, Funny)

    by sammyo ( 166904 ) on Friday June 13, 2003 @06:15PM (#6196027) Journal
    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)

  • Sounds like LISP to me (Score:3, Interesting)

    by Sayjack ( 181286 ) on Friday June 13, 2003 @06:16PM (#6196033) Homepage
    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 (Score:3, Funny)

    by Markus Registrada ( 642224 ) on Friday June 13, 2003 @06:35PM (#6196143)
    Alex Stepanov famously described Java [stlport.org] 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? (Score:2, Interesting)

    by e__alf ( 642611 )
    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 debu

  • Gamma and OO (Score:3, Informative)

    by schouwl ( 658811 ) <schouw AT gmail DOT com> on Friday June 13, 2003 @07:28PM (#6196411)
    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
    • You can discuss your program on a whole other abstraction level.
      GREAT.

      If you used a better programming language, you wouldn't need complicated tools to "discuss your program on a whole other abstraction level".

      The stuff Gamma has been doing is the equivalent of "structured programming for assembly language programmers". It's a set of tricks to make programming in OOLs slightly less awful than it would be otherwise. It is certainly not a great advance in software engineering.

  • Link to Jackpot home page (Score:3, Informative)

    by gwernol ( 167574 ) on Friday June 13, 2003 @07:47PM (#6196506)
    Not a great deal there yet, but if you're interested in Jackpot then the Jackpot home page [sun.com] 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 (Score:2, Interesting)

    by dr2chase ( 653338 )
    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 manipu

    • 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.)
      Eclipse does only 10 of over 100 actual "named" and "known" refactorings.

      And Eclipse does it by looking at a "
      • > What would be if "the AST" had a
        > "push method up" method?

        Then that AST would have to include a global symbol table to resolve references to that method and thus would be, more or less, a compiler front end (albeit without the intermediate representation).

  • Getters/Setters (Score:2, Insightful)

    by oodl ( 398345 )
    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 fe
    • Gosling appears to have oblivious to most of the research

      While this is certainly possible, I doubt it seriously. NeWS was specifically set up to be able to use OO techniques. I also remember that early discussions and descriptions of java mentioned most of the OO languages of interest at the time and discussed their good and bad points. I don't know that Dylan was mentioned, but I'd be very surprised given Gosling's background that he was unaware of it. And I think it would be just as hard for him to b

    • Can you point me to the bit where he says "Wow, isn't this a great idea, we're sure no-one has ever done this before"?

      This isn't an academic paper appearing in a context which has strong norms of citation. This is an informal interview.

    • Java should been designed from the start to enforce getter/setter access to instance variables.

      Yes. In my dream world, somebody at Sun will get a fucking clue and make getter/setter stuff implicit based on keywords when you declare the variables. Then if you need to override the default getter/setter behavior, you just explicitly declare the methods.

      Then we can make the call implicit, throwing out all the foo.getBar().getBaz() crap and just make it foo.bar.baz.

      At a guess, that would remove about half th

  • Juice (Score:2)

    by jefu ( 53450 )
    I can't seem to find any details at the moment, but if I remember correctly (quite unlikely, come to think of it) there was a project called "Juice" presented as an alternative to java back in java's early days that represented programs as parse trees. It was developed by Nicklaus Wirth and was an offshoot of oberon.

    And there are the obvious advantages that might be gained by representing programs as XML trees (internally at least, programmers don't need to see it).

  • 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
  • INTERLISP, Warren Teitelman's variant of LISP used at Xerox PARC, had this from about 1978.

    INTERLISP's internal representation was the LISP s-expression. Programs lived in huge saved binary workspaces rather than text files, at least while being developed. This had pluses and minuses, especially on the underpowered machines of the period.

    There were a number of transformations one could perform on code in this form, and they were guaranteed not to change the semantics of the program. You could designa

  • Very interesting read. Two comments:

    1) SCID [mindprod.com] seems to be a similar thing.

    2) From the interview: For instance, if you've got a static method that takes an object as a parameter, and it modifies that object, then somebody probably just slapped that method in there because it was easy.

    I don't think that's really true. Classes with static methods seem to be very convenient to me. Much like the decorator pattern, where code (here in the static method) only deals with modifying data objects given to it. That
  • ... 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.

  • Gosling has been talking about this for at least two years. I'd really like to see it actually happen, because it's got tremendous potential.

    His talk about complexity is a bit facetious; if you really wanted a simple programming language you'd do it all with S and K (trivial functional operators). The trick is not to minimize complexity but to achieve exactly the correct level of complexity.

    Object orientation is one way of dealing with complexity: you group like functionality together into boxes with li
  • When you construct forwarding methods, they're different from the original methods. You can't just replace all uses of the forwarding method by uses of the moved method, because they actually behave slightly differently.

    That sounds like a language design problem to me. The solution to that should be to fix the language, not to construct elaborate theorem provers and visual representations of the source code. Building tools to deal with a messy language will just mean that the language and software writt

Slashdot Top Deals

My sister opened a computer store in Hawaii. She sells C shells down by the seashore.

Close