I’ve used MATLAB almost ever single day for the last year, and I can say confidently that two things are true of MATLAB:
- Every engineer has used it.
- No engineer likes using it.
Certainly, there are lots of great things about MATLAB – and MathWorks would be glad to tell you what they are. So instead, here goes with my top 5 reasons for hating MATLAB.
Reason #5: MATLAB arrays are 1-indexed instead of 0-indexed.
x, you would index at 0, i.e.
x. To iterate over all the elements in an array with n elements, you would proceed from
x[n-1]. Simple, easy, great in
MATLAB? No. Supposedly because mathematical arrays are indexed from 1 to n, MATLAB uses the convention that
x is the first element of the array. (In fact, in MATLAB, you’d have to use parentheses instead of braces, but I’ll get to that in Reason #4.) So to iterate over the set, you start at 1 and stop at
Doesn’t seem like such a big deal, right? Maybe not to someone who only codes in MATLAB (or R, which uses the same convention), but if you’re like me and spend a lot of time programming in C++ or Java, it’s absurdly frustrating. It’s like going back and forth between QWERTY and Dvorak keyboards – each time you switch, you make a lot of mistakes getting re-adjusted.
Reason #4: inconsistent interpretation of matrix indexing
To access array elements in C, C++, and Java:
elementIwasLookingFor = x[index]
To access array elements in MATLAB:
elementIwasLookingFor = x(index)
Why parentheses? Great question. I’m still waiting to hear the reasoning on that one.
Reason #3: poor concept of objects
The dominating paradigm in systems programming nowadays is, of course, object-oriented design. And sure, MATLAB supports really basic struct-like objects – for example,
object.property = value
But what about objects that can do things, like set private members, intelligently update and return values, and other cornerstones of OOP? Negative.
“But MATLAB is just an interface on top of C! You shouldn’t need objects in MATLAB!” you might say. Fine, I shouldn’t be building huge systems in MATLAB. Or should I? With tools like SimuLink and the Image Processing Toolbox, objects would make total sense, especially given that sometimes I would like to add functionality to the object without rearranging all of my code. That’s what OOP does, and why it sucks that MATLAB doesn’t support it.
But that’s all popcorn compared to my real complaint. I love programming in other languages for a really simple reason: auto-complete. On 90% of occasions, I forget how I spelled that public member function, and auto-complete saves me about half an hour of search-for-the-name time on a daily basis. But since MATLAB doesn’t understand objects, it can’t auto-complete those functions, meaning you have to look up how it’s spelled/called. Ridiculous.
Reason #2: String handling
Have you ever tried to concatenate two strings in MATLAB? Then you know how much it sucks. In most languages, you can type
String result = "I go to " + "the store"
and you’ll get
result = "I go to the store"
In MATLAB, though, the strings are treated as arrays of characters, such that adding two strings is the equivalent of adding two numeric arrays. To actually concatenate the strings, you have to use a kludgy piece of ridiculousness like the sprintf workaround:
result = sprintf("%s%s", "I got to ", "the store")
It’s just one more thing that makes good reporting and text formatting nearly impossible.
Reason #1: they didn’t even write their own math engine!
Engineers use MATLAB primarily due to its fast, robust, effective matrix operations. Even with 1,000,000 x 1,000,000 matrices on a weak Acer PC like mine, MATLAB can crank out matrix products, singular vector decompositions, exponentials, and the like without even breaking a sweat. It’s great! The problem is, we don’t have MATLAB to thank for that – the credit belongs to the free, widely distributed, available-for-immediate-download LAPACK.
So with that, even MATLAB’s most essential feature set isn’t a unique advantage. We engineers put up with a lot of MATLAB’s inconsistencies and faults, just to get access to LAPACK without needing to use FORTRAN.
Personally, I’m eagerly awaiting the day when the very MATLAB-like (but free!) Octave or the statistics-focused (and also free!) R have enough of a following to become industry standards in and of themselves. But until they do, the majority of code examples, training, and industry expertise will remain trapped in MATLAB, the Microsoft Windows of mathematical computing and simulation tools.