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: Jaroslav Hajek
Subject: Re: GSoC project: new graphics backend
Date: Fri, 20 Mar 2009 08:12:37 +0100

On Fri, Mar 20, 2009 at 7:41 AM, Igor V. Burago <address@hidden> wrote:
> Hello Arseniy!
>
> I interested on that point for a very long time too, but unfortunately I
> was too busy to complete my ideas in code before. I'm sure that languages
> such as Octave must have a good environment including powerful
> plotting engine wrapped into an interface providing a way to modify
> figure's parameters easily. So I'd like to develop such a software for
> Octave or for science library written for Ruby language (which is much
> more powerful than Octave, runs faster, has large number of
> libraries and could be a good solution for science computation, if it
> has rich package of numerical functions ported from some languages
> such as Matlab or Octave).

The same can be said for Python, and I'm not aware of any Ruby
scientific library comparably mature to NumPy/SciPy. Yet somehow SciPy
can't replace Octave/Matlab... besides the existing numerical
libraries, I think an important reason is that the Octave language,
while agreeably being less powerful than Python/Ruby, is also
significantly more simple, which seems to be suitable to many
scientific programmers.
Octave's pass-by-value mechanism (with lazy copy-on-write) is
something that is *far* more simple to grasp than NumPy's inherited
everything-is-a-reference semantics. I do regard myself as moderately
experienced Python programmer, yet every now and then I get shot in
the foot by the reference semantics in Python. In Octave, you just
don't care about mutable and non-mutable objects - everything works
*as if* passed by value. Of course there's a big price to pay for that
- you can't actually pass-by-reference except by ugly hacks, but after
experiencing both Python and Octave I still regard it as a very good
trade.
The "function is a file" paradigm is another super-simplification,
though it is a mortal sin from the point of view of computer science
theory (and of course, when building large projects, you need to keep
strong naming discipline to not end up in a mess).

cheers

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


reply via email to

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