[Top][All Lists]

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

Re: Octave's and Matlab's limitations

From: Salva Ardid
Subject: Re: Octave's and Matlab's limitations
Date: Wed, 21 Nov 2012 14:23:14 -0500
User-agent: KMail/4.9.3 (Linux/3.5.0-17-generic; KDE/4.9.3; x86_64; ; )

El Dimecres, 21 de novembre de 2012, a les 11:07:26, Jordi Gutiérrez Hermoso 
va escriure:

> 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
>     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.

That's very comprehensive explanation!

I guess it makes sense to spend time learning/using scipy and see how well I 
may adapt to eventually make a more educated decision on what to use in the 
medium/long run.

Thanks to All for your contribution,

reply via email to

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