octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC project: new graphics backend


From: Igor V. Burago
Subject: Re: GSoC project: new graphics backend
Date: Sat, 21 Mar 2009 00:15:27 +1000

> Yes I know that "you can do everything in Python" is, in theory, a big
> advantage. But for most of my work, I have the simple scheme "load
> data from files" -> "do bunch of computations" -> "save data to files,
> generate reports and plots" which Octave suits fairly well. Of course,
> the problem arises when you want to, say, get the data from the web
> rather than files, which in Python would be a small step comparably to
> the effort in Octave (even when you have urlget). But I must add that
> Python is a bit self-defeating here, because it's really not hard to
> make Python just use Octave, say, through pipes, and it's way easier
> for me than working in Python from start. Of course, such bridges
> suffer from portability problems...
Yes, it seems that languages such Python and Ruby becomes an
multipurpose "glue" between wide variety of software today...

> so it's all about "yes, Python is better, but it's not better enough
> to be actually better for me".
By the way, may be you should take a look at Ruby. At my opinion Ruby
provides simpler and more consistent way to realize functionality of
Perl and Python.

> Yeah, hey - I have a lot of codes likely to stay in development stage
> forever :)
Oh, so do I!..

> Hopefully Octave will eventually have JIT compiling at least of the
> simple loops. I would, of course, greatly appreciate connecting Octave
> and Python, especially using Octave from within Python.
Last year I sketched a JIT compiler for Octave subset that runs 20 -
40 times faster, but unfortunately I found two things: Java bytecode
isn't a best fit for languages with dynamic typing (such as Octave
too) and (may be most important :) I still have not time to rewrite it
for using Parrot bytecode which suits much better.

> That's its price for being more powerful.
Absolutely!

> And of course Octave's syntax is much closer to the numerics.
I agree, it's one of the strongest arguments for Octave and Matlab.

> These two are good examples of features that I think would be good to
> have in Octave but I never actually needed them.
It's really necessary things for solving real problems!

> I was surprised there
> is no extension package for at least basic support of associative
> arrays - apparently nobody really needs it.
Looking for such a library, I was surprised too.

-- 
Igor V. Burago


reply via email to

[Prev in Thread] Current Thread [Next in Thread]