[Top][All Lists]

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

Octave's and Matlab's limitations

From: Jordi Gutiérrez Hermoso
Subject: Octave's and Matlab's limitations
Date: Wed, 21 Nov 2012 11:07:26 -0500

On 21 November 2012 10:26, Salva Ardid <address@hidden> wrote:

> So all this intro is to ask, why do you think Octave is not as
> 'good' as Scipy or R? This was to me coming from you as a Octave
> developer, and I would like to know more if possible...

Basically, I agree with every post in this blog:

But, for the purpose of full disclosure, here are the things that
peeve me off the most about this language:

    0) Using () both for function calls and indexing makes the code
    very difficult to read and causes so many bugs. Likewise, using '
    both for strings and transposition makes some kinds of code very
    difficult to parse.

    1) Very limited data structures. The "everything is an array"
    mentality made sense when this was Fortran and Netlib we were
    talking about. Not having linked lists nor hashes is frustrating.
    Matlab has "solved" this by gluing Java data types onto the
    original Fortran roots, a dubious solution in my mind.

    2) Impossibility to have true reference semantics. Matlab has
    "solved" this by introducing the horribly complex handle and value
    classes in classdef style. Which we now need to produce in Octave
    too, which has turned out to be an intractable mess of its own.

    3) String manipulation is totally clowny, basically because
    strings are Fortran arrays. Strings are a fundamental type in any
    language. They should be easy and natural to use.

    4) Manipulating data in non-array format is difficult. So having a
    log file, non-tabular data, data of mixed types are all awkward to

    5) The namespace situation is horrible. Almost every major feature
    that Mathworks has done to Matlab since its creation has been
    attempts to partition the namespace, and they all suck in their
    own ways: subfunctions, nested functions, classes, packages; these
    are all namespace hacks, and none of them actually solves the
    namespace problem.

    6) Confusing semantics for the data types that we actually have.
    Cell and struct arrays are understood by no one. What the hell is
    a cs-list, and why do you get one of those from cell and struct
    arrays, shall I explain yet again?

    7) The Matlab interpreter is needlessly restricted to refuse
    certain kinds of perfectly reasonable syntax such as
    sin(1:3)(end), but at least this we can solve in Octave. Until
    recently, the Matlab interpreter didn't even a emit a useful
    diagnostic about this. Now the Matlab parser seems to be able to
    recognise this syntax, only so it can better complain about it.

    8) Surprising Matlab bugs that we cannot ever fix due to Matlab
    compatibility, and I guess they don't fix due to backwards
    compatibility, such as the short-circuiting rules for & and | or
    the precedence of ^ in 2^2^3.

    9) No one-dimensional arrays, so you gotta keep figuring out the
    orientation of your vectors or arrays and transpose as necessary.

These are just off the top of my head, but ten is a good, round
number, so I'll stop there. I could go on. Matlab is a horrible,
*horrible* general-purpose programming language, and I'm appalled that
people use it to build web servers and GUI applications and who knows
what other atrocities they build with it. Octave has to follow most of
these things from Matlab, because our goal is to fully liberate all of
the many thousands upon millions of lines of free Matlab code out

And to be fair, fine, Matlab and Octave are ok for array-based
numerical computations, but people rarely used them for only that.
They usually want to do things other than crunch numbers.

> I know every language has pros and cons, and this has also to be
> true for Scipy and R, not only Matlab and Octave.

Sure, but Scipy comes from Python, which is a general-purpose
language, so it was built with solving the problems that programmers
generally have. Matlab instead was built to be a wrapper to Netlib and
then grew features like a toad grows warts.

R is a language that was originally for statisticians, so it is
*marvelous* at handling data, and not just the matrix data that a
numerical analyst likes (Matlab originally was for numerical analysis,
not for data manipulation).

I am kinda frustrated how one of Matlab's and Octave's primary use
cases is to draw graphs from data without actually doing any
significant computations on that data. I learned Octave to do
interesting numerical computations such as solving hyperbolic PDEs or
figuring out cantilever problems with FEM, not to produce plots that
would look good on publications. If you just want to grab your data
and create plots for journals, particularly if you're a scientist who
wants to state that your p-value is significant, R is far better
suited for this task.

And even if you *do* want to do numerical analysis, we're having new
contenders like the Julia language which are already being better
designed from the ground up, much better than Matlab ever was, by
people who actually design programming languages professionally.

> Would you encourage people to stop using Octave and migrate to
> Scipy/R if Matlab compatibility is not a must and if time and effort
> to alleviate the learning curve of learning new languages or
> migrating codes is not an issue?

Absolutely. The only reason Octave needs to exist is to liberate
existing Matlab code. Which is a pretty big reason, and the reason why
I keep working on Octave. If Matlab usage went down, so would
Octave's. Or, we may be able to finally make Octave less stupid, if
nobody wanted to make it run Matlab code anymore.

- Jordi G. H.

reply via email to

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