Impressions of Matlab, Part 1

I've recently been learning Matlab, and I thought it might be fun to record some of my impressions of it as I go. First, a little background. I've been programming for many years, and know a variety of programming languages, including FORTRAN, C, C++, Perl, Python, and a few assembly languages. My preferred languages are Python and C++, depending on whether an application can be interpreted or must be compiled.

Since Matlab is a scripting language (whether or not its users realize it), most of my perceptions of Matlab will be in terms of Python. With its exceptionally clean and spare syntax, Python is a very hard act to follow, even if Matlab came first. And in my experience so far, Matlab suffers in comparison.

Before I go farther, I should point out (or others will) that the SciPy (at scipy.org) provides a bundle of Python extensions that blur the line between the two, in terms of capabilities. So why use Matlab at all? Well, it's a bit of a standard. Also, it offers a breadth and depth of capabilities that are simply unmatched by any other system. Also, of course, there's Octave, which is an excellent clone of Matlab. I won't talk much about Octave here, except that to say that as a clone, it suffers from most of Matlab's flaws. In some cases, the Octave folks have made improvements on those, but to use those improvements would create non-standard, which defeats the purpose. So, to me, the primary value of Octave is that it costs a whole lot less than Matlab.

Now, back to Matlab. My immediate impression after using it for a couple of weeks is that it is a very well designed system overall, and contains many good ideas (many of which have undoubtedly been adopted by others), but it's a bit quirky. Like a camel, parts of it seem to be designed by a committee. Also, it seems to have a number of rules that may make sense to Matlab's from an implementation point of view but don't make much sense to Matlab's users from a usage point of view.

Chief among these is the placement of functions. Each function must be in a separate file having the same name as the function. Local helper functions can be contained in a function files but can't be contained in primary script files - go figure. I know of no other language that works like that.

Another thing I don't understand - from a user's point of view - is why vector/matrix variables are initialized using brackets but must be accessed via parentheses. (In Python, brackets and braces are used to denote different data types - lists and tuples - but then are used uniformly for their associated types.) I find the parenthesis form of indexing to be somewhat hard to read. For one thing, parentheses don't stand out clearly from the parentheses used for function calls. Also, nearly all other programming languages use brackets for arrays.

Since Matlab stands for "Matrix Laboratory" (not "math labor", as some users may suspect), I guess the use of parenthesis is drawn from dogma from Linear Algebra. So be it. But for those of use who are more pragmatic than dogmatic it takes some getting used to.

Then there's Matlab's one-based indexing. Based on a long thread on comp.dsp years ago, that also apparently is drawn from matrix dogma (or maybe from Matlab's original purpose of a scripting language for Fortran libraries.) Since nearly all DSP code is written in assembly, C, or C++, which all have zero-based indexing, zero-based indexing would be a lot more practical for DSP folks who use Matlab. But there I go being pragmatic again.