[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:
https://abandonmatlab.wordpress.com/2009/07/23/hello-world/
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
do.
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
there.
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.
- Octave's and Matlab's limitations,
Jordi Gutiérrez Hermoso <=
- Re: Octave's and Matlab's limitations, c., 2012/11/21
- Re: Octave's and Matlab's limitations, Dimitri Maziuk, 2012/11/21
- Re: Octave's and Matlab's limitations, c., 2012/11/21
- Re: Octave's and Matlab's limitations, Jake, 2012/11/21
- Re: Octave's and Matlab's limitations, Salva Ardid, 2012/11/21
- Re: Octave's and Matlab's limitations, Kjetil brinchmann Halvorsen, 2012/11/21
- Re: Octave's and Matlab's limitations, Sergei Steshenko, 2012/11/21
- Re: Octave's and Matlab's limitations, Dimitri Maziuk, 2012/11/21
- Re: Octave's and Matlab's limitations, Sergei Steshenko, 2012/11/21
- Re: Octave's and Matlab's limitations, Sergei Steshenko, 2012/11/21