RE: Re[2]: [stellation-res] Proposed Changes in Bugzilla (#31581 )

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> >Chu-Carroll
> >Sent: February 12, 2003 7:22 PM
> >To: Stellation-res
> >Subject: Re: Re[2]: [stellation-res] Proposed Changes in Bugzilla
> >(#31581 )
> >
> >
> >On Wed, 2003-02-12 at 18:10, Jim Wright - IBM Research wrote:
> >> At 04:38 PM 2/12/2003, Marco Qualizza wrote:
> >> Python also has a number of warts, of course (but it suits my
> >own quirks
> >> better).
> >
> >Python is pretty nifty. It's certainly got some strange quirks, but
> >they don't affect normal day-to-day programming. In general, it's
> >quite a clean an pleasant language. I've really enjoyed programming
> >it. Not exactly a quick language, but acceptable for most things.
> >
> >Back when I started Stellation (it was called Coven in those days,
> >and I was working on it all alone), I tried doing some benchmarks in
> >a bunch of languages to get a sense of which ones would perform
> >acceptably for implementing Stellation. (This was before anyone
> >at Research had seen Eclipse, and I expected to build it using an
> >emacs integration.)
> >
> >I implemented the LCS-based diff algorithm in Perl, Python, C++, Java,
> >and OCaML. (OCaML is my personal favorite programming language.) I
> >ran it on a roughly 500-line input file. I don't have the exact
> >numbers any more, but the order-of-magnitude stuff was:
> >- OCaML: 0.5 seconds.
> >- C++: 0.75 seconds.
> >- Java (IBM JDK): ~3 seconds.
> >- Perl: ~3 minutes
> >- Python: ~2 minutes.
> >
> >So Python does pretty well in the scripting category, but it's slow as
> >hell when compared to the others. (The really impressive thing about
> >that OCaML number is that that's running in the OCaML *interpreter*. It
> >went faster when compiled to machine code. But even the OCaML
> >interpreter was able to beat C. (OCaML has some interesting properties
> >that allow it to do things like String comparisons incredibly
> >efficiently. It can essentially do the equivalent of interning all
> >strings automatically, so that string comparison becomes integer
> >comparison.)
> >
> >> Ruby is another interesting possibility (which I have no
> >experience with)
> >> A comparison of Ruby and Python is here:
> >> http://www.rubygarden.org/iowa/faqtotum/abk8uZHYjd2bA/b/1.11.7.2.5
> >> Not being a Perl hacker (and disliking Perl's syntactic
> >variability immensely),
> >> I'm not drawn to it immediately, but am willing to learn more about it.
> >
> >Ruby is a language that I really want to learn. I haven't yet had
> >the time to sit down and learn it. Unfortunately, it's not
> >particularly Java friendly. There is an effort to build a Java
> >based Ruby interpreter (sort of the Ruby counterpart of Jython),
> >but it's still nowhere near ready for prime time.
> >
> >I really like the look of Dynamic java: http://koala.ilog.fr/djava/.
> >It's darned close to 100% compatible with standard Java (meaning that
> >almost all standard Java code can be run using Dynamic java - the only
> >exceptions being quite esoteric things like comparing Foo.class with
> >Class.forName("Foo"), and the behavior of named local inner classes.);
> >but it also supports very nice lightweight scripty type things. So we
> >can define an API in Java, let people write lightweight scripts,
> >with a natural migration path to convert them into full-blown plugins.
> >
> >
> >> >  BTW are you aware
> >> > > that the Eclipse folks tried to add a scripting facility
> >to Eclipse and
> >> > then
> >> > > backed off as they could not get a satisfactory result
> >apparently. The
> >> > first
> >> > > cut code is in the CVS repository.
> >>
> >> Yes, I knew about that. I'd like to see it revived: it's a
> >clear lack in
> >> the current platform.
> >
> >Yeah, there were actually some research types involved. (Wasn't it
> >Jason Crawford?) If it's the one I'm thinking of, it was Javascript
> >based. Still, it's a shame that they didn't go farther with it.
> >
> >> OTOH - for our purposes, we don't necessarily need fully
> >scriptable control
> >> over all aspects of Eclipse;  an API focused on SCM-related
> >tasks, behaviors
> >> and packaged UI components might be enough to do quite a lot.
> >
> >In fact, a whole lot of what we'd want to script could be done with
> >very minimal UI support. But if we do something that's totally java
> >compatible, then calling Eclipse JFace stuff directly from the script
> >should be possible.
> >
> >	-Mark
It seems to me that so long as we had a way to display results in a
reasonable fashion and some kind of wrapper to allow input from the user we
could do a lot of things. Since a scripting facility would be a tool rather
than an end in itself, I would favour a language that has a high degree of
integration with Java since this would minimize the effort to get useful
results for Stellation.

I also think that this could become a proof of concept for the Eclipse folks
and could then be picked up by them and made completely general purpose.

Long term, I think that a scripting language should have a smart Eclipse
based editor and an API to give access to the balance of Eclipse and
Stellation. The API part may not be that difficult if we choose a Java
friendly scripting engine.

Regards

Jonathan