Re: GSoC project: new graphics backend

[Igor V. Burago]

> Actually, a friend of mine and a dedicated Ruby user lobbied for just
> the same some time ago, so I tried to go through the tutorial - it was
> much like going through the Python tutorial before, but in the end
> there was no justification for the switch. I already knew Python, and
There is much more differences between Python and Ruby, especially in
OOP organization, believe me. For me Ruby is more elegant and clean
than Perl or Python in many ways.

> there's NumPy, SciPy, SAGE ... it just seems to me Python is more
> popular in scientific computing than Ruby.
It's because Ruby is younger and became widespread only several years
ago. If libraries such NumPy will be created for Ruby, it will become
much more popular in scientific programming.

> It's been discussed many times on the mailing lists that the tough
> part of JIT in Octave is the type inference.
> Still, I think that a JIT compiler with even a very limited scope,
> like compiling only loops that can be determined upon entry to never
> reference out-of-bounds elements, never call functions (or except a
> small defined set) and only access built-in arrays or scalars, would
> still be a superb thing, and would cover 90% of the need for a JIT in
> Octave.
> So, contributions are certainly welcome here :)
I can publish code of my compiler that compiles subset of Octave into
Java bytecode (it hasn't full support of matrices and cell arrays yet
(both of them as well as other built-in types should be realized on
Java and put in compiler's library). So now it's possible to compile
just only simple programs which works fast, though. I planned to
rewrite my compiler using Parrot bytecode which makes possible to
realize full Octave language power with less pain caused by putting
dynamically typed Octave foot into strongly typed Java shoe.

> Not my real problems, then. Concerning the associative array, I can
> usually get away with just using dynamic struct fields or explicit
> lookup table for keys + a cell array for values.
But some of my problems (unfortunately? :). For my feeling these ways
of emulating associative arrays are a little roundabout. (But in some
cases dynamic struct fields are helpful to solve related problems.)

> I'm ready to write it if I need it :)
I'm too, there is no problem for me to overcome that (programming
often forces to adapt current environment to your needs), but
sometimes it's cheaper and simpler just to switch to another
library/language/environment.

-- 
Igor V. Burago