[Top][All Lists]

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

Re: The future of Octave

From: Lynn Winebarger
Subject: Re: The future of Octave
Date: Sun, 10 Dec 2000 16:32:37 -0500 (EST)

On Sat, 9 Dec 2000, John W. Eaton wrote:
> If you want to head down that path, then I think it makes more sense
> to use a translator to convert Matlab code to a more full-featured
> scripting language.  A similar translator would be written for Octave
> (or whatever the new environment that does not attempt Matlab
> compatibility is called).  Both translators would share the same
> underlying library and interpreter, so both could be used together,
> along with any code written for the underlying scripting language.
> If you agree with this approach, at least in principle, then you will
> probably want to have your favorite scripting language at the core.
> People will probably argue that one language is more popular or has
> more add-ons than another, so it should be used.  There will be Python
> and Perl advocates, and people who just like Tcl, or Java.  But my
> choice would probably be something like Scheme, which is powerful, and
> should be relatively easy to use as a target for translation.
> Using such an approach, you don't have to write Scheme code if you
> don't like it, you can write Octave code and pass it through the
> translator, and people who want to use the strict Matlab translator
> can still have access to your code.  Likewise, people who use Octave
> have access to all the Matlab code, via the translator.  And both have
> access to any other modules written for the Scheme interpreter.

    Wouldn't it be better to go to a virtual machine + general optimizing
phase compiler core + multiple frontends model?  These other languages are
nice and all, but how well do they support numerical computation?  And how
much cruft would be generated (if you choose Scheme, I would think you're
most of the core code (what's written in C++) would still be in C++ or C,
but with a load of Guile hooks in them.  Is that going to improve the
developer situation or worsen it?
    Personally, the only time I care about Matlab compatibility is when
I see some useful code someone else has written in Matlab and want to use
it with as little pain as possible.  I'd just as soon have a better
language interface for myself, though.  Something with continuations and
run-time macro expansion and a good object system and (drool obscures
further feature lust).
    Plus it would provide a clean separation of concerns so I don't have
to dig to the deep core when I only need something superficial (replace
"I" with "J Random Coder" if you like).  While there's a lot to be
grateful for with Octave, there are problems as well.  And source
documentation has got to be a big one for expanding it developer
base.  Forcing this kind of separation would at least require
documentation of the interface.  And it's been my experience as a reader
of software that the most flexible/cleanest designs are those that read as
interpreters (of their data, not that they have lexers and parsers).
    Take these comments for what they're worth, as I don't have the time
or expertise to help with this.  I'm only offering them as someone who
reads much more code than he writes, and has an opinion on what's easier
to read and thus work on. YMMV.

PS Thanks for Octave.

Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

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