From help-octave-request at bevo dot che dot wisc dot edu Sun Dec 10 02:33:29 2000 Subject: Re: The future of Octave From: Lynn Winebarger To: "John W. Eaton" cc: help-octave at bevo dot che dot wisc dot edu 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. Lynn PS Thanks for Octave. ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html -------------------------------------------------------------