Re: Opinions on Matlab compatibility, Octave development

[Jaroslav Hajek]

2010/6/2 Jordi Gutiérrez Hermoso <address@hidden>:
> I was reading an old article of jwe's from 2001[1] and was
> particularly interested in section 4, which I briefly cite here:
>
>> I no longer believe that compatibility is a reasonable goal. It
>> stifles innovation and places the project in the position of never
>> being a leader, always being a follower, and quite far behind almost
>> all the time.
>
>> If compatibility is a goal, almost no innovation is allowed, because
>> there is the potential for any new feature to be incompatible with
>> future versions of Matlab. (This is not just an imagined problem—it
>> has happened in the past, and I expect it will happen again.)
>
> I am wondering, how do people feel about this at the moment? Playing
> the compatibility game does seem quite boring, but it's a very
> frequent request from Octave users. Furthermore, Octave has been
> listed in GNU's high priority project list[2] for some time as a
> replacement for Matlab.
>

IIRC, Octave didn't start as a replacement project, but eventually
converged into one. That suggests that its best future probably lies
with being a Matlab replacement, Matlab being rightfully the premium
interpreter for the Matlab language.
It should be stressed, however, that it is a mistake to think that
this implies that Octave is merely for those who can't afford Matlab.
Besides the price, there are a number of other reasons why you may
want to consider an alternative interpreter, including the lack of
license restrictions, the freedom to study and modify it, or specific
extra functionality or performance advantages (both exist).
As long as Matlab stays popular, its free replacements will be popular
as well. Octave may not always be the most prominent one, but, with
Scilab evolving into a considerably distinct language and environment,
at least for the nearest future it seems to be one. It's closest
competitor is probably FreeMat, but last time I timed it (~ 1 month
ago) with an indexing benchmark, it severely lagged behind both Octave
and Matlab, despite having JIT capabilities. The public post is
available here (in Czech, but you'll probably understand the numbers):
http://www.root.cz/clanky/sikovny-poctar-freemat/nazory/347467/

I think that Matlab's popularity ensures Octave's popularity to a
strong extent, and that bond is strengthened by Octave pursuing
compatibility with Matlab. If, hypothetically, Matlab ceases to be
developed and licensed, it may be that Matlab users will adopt Octave
or other replacements, but I am not confident about it. We may also
see a massive migration to a different platform such as NumPy,
followed by a total decline of interest. I will regret it somewhat
because I think the core Matlab language and syntax, with its COW
values and simple value-like argument passing, and automatic finding
and reloading functions, is a beautiful and productive design, even
though I dislike many of those bells and whistles added later.

I also value the fact that my Octave scripting skills can be, though
with some effort, converted to Matlab scripting skills, should the
need arise. I like Octave more, but I think few of us can rely on
making their living with free software for ever. Who knows what future
will bring?

So yes, following compatibility is a reasonable goal, but IMHO we
should not exaggerate it. We should attempt to fix or improve on
Matlab's mistakes when they become obvious and there's an opportunity
to do so, to provide some extra value within Octave.
It should not be something like completely redesigning cells and
cs-lists to obtain something supposedly better, but on the contrary I
think it's great to have fixed stupid little inconsistencies such as
indexing with non-integer ranges (yes, for some reason I was
particularly pissed by this one).

regards


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