Re: [groovy-dev] making the bytecode generation more understandable

On 8 Oct 2004, at 00:25, Miles Parker wrote:

> Neil Ellis wrote:
>
>> Changes to Groovy to make it of comparable speed would require a total
>> rethink/rewrite of the parser (or at least the bytecode generation
>> aspect) and would probably require fundamental changes to the 
>> language.
>
> I agree slightly with the first part and less slightly with the 
> second.  Yes, a more flexible bytecode gen would certainly be a big 
> help. But no truly fundamental changes would be required to achive 
> enormous performance improvments and very simple changes should make 
> it possible to truly have the best of both worlds. (See discussions on 
> sealing and 'any' keyword just for example.)
>
>> The thing is the Groovy community lines up to two points of view:
>> 1) Groovy is like Ruby but for the JVM.
>> 2) Groovy is Java++
>
> Can I substitiute JavaTalk or JavaDylan, or something like that? The 
> point is not (I hope) to load Java up with a bunch of features and 
> syntax detritus ala C++, and not that Groovy can replace Java or 
> should it, but to create a much more expressive language that can -- 
> unlike other approaches -- leverage the enormous investment in Java.
>
> And, I do not think that these are in any way mutually exclusive 
> points of view. In fact, they are self-supporting. There is nothing 
> that says a lanuguage has to be either statically typed or dynamically 
> typed, it can be both/and. As it stands, reflection is order(s) of 
> magnitiude slower than direct invocation -- this simply puts Groovy 
> out of the picture for a large portion of science and 
> data-manipulation applications among other things.
>
> As you point out, there are many applications that require some degree 
> of type-safety and some degree of performance. Wouldn't it be neat to 
> be able to tune the language to those needs? I submit -- and I know 
> this is controversial -- that such a thing is quite possible, and has 
> actually been done before. When or if it is worth persuing may be a 
> different question but I am certain that it can be done.

Totally agree.

Its also worth saying that we never really implemented the static 
dispatch side of things, as thats just in a implementation detail :) 
However if we sort out the bytecode generation stuff, it'll be much 
easier to sort out this area and get super-fast code.

James
-------
http://radio.weblogs.com/0112098/