From octave-maintainers-request at bevo dot che dot wisc dot edu  Fri Dec  8 17:54:21 2000
Subject: Octave & Matlab
From: "Julian A. de Marchi, Ph.D" <julian at matlinks dot net>
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
Cc: <octave-maintainers at bevo dot che dot wisc dot edu>,         "Help-Octave" <help-octave@bevo.che.wisc.edu>
Date: Fri, 8 Dec 2000 18:54:18 -0500

I'd like to expound tersely upon my earlier email.

I think it's fine that Octave continue developing without using Matlab as a
frame of reference.  Its strength as an independent, community-owned (and it
seems, often much improved) numerical processing tool shouldn't be fettered
by concerns of compatibility with a flashier, but not necessarily superior,
de-facto commercial tool as Matlab basically is.

I also think it must be possible to produce compatibility with Matlab at an
interface level without too much compromise in terms of either performance or
fundamental principles (be they scientific or philosophical).  This seems
especially true since Octave is as yet still a hard-core numerical engine,
without a graphical user interface.  I hope that Octave contributors maintain
their awareness of Matlab interface compatibility when possible and in those
instances when it does not compromise performance or usability.  However, I
also agree that it needn't be the driving factor in new design and extension
of Octave features.

Rather than forking Octave, for better or worse, to satisfy both parties in
the debate, I hope that some enterprising contributors (those who are
interested, myself included), can toil together to maintain and improve
Octave compatibility with Matlab in the form of an abstraction layer or babel
fish.  Rather than argue about the two options, perhaps we can, as a
community, agree upon an API or interpreter interface which  facilitates this
option while freeing Octave from the fetters of selective low-level
compatibility.  I'm not even sure that such an interface need specify
anything further than full functional compatibility, as most of the
differences between the two languages are merely syntactic at worst.

And this of course makes further argument on the topic rather moot.  Why not
simply drop the case and work on a Matlab-compatible layer, that uses Octave
as the driving engine?  This would, I believe, encourage more intelligent
folks to get into Octave and help the project grow, and obviate the need for
further argumentation on the merits or pitfalls of one course exclusively
over the other.

Cheers,
Julian