Re: Octave's and Matlab's limitations

[Salva Ardid]

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

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,
Salva