Matlab is oversold as a general-purpose language
abandonmatlab.wordpress.com
abandonmatlab.wordpress.com
The rage doesn't really come from MATLAB (every language has warts); the rage comes from being forced by the social conditions of the academic workplace to collaborate on problems with totally inappropriate tools. Nobody wants to hear about how you've been procrastinating with python or git... they just want to push some new parameters into the lab's creaky matlab model and publish a new paper.
Anybody who---as the lab's "code guy"---has been handed a disk full of broken, undocumented Matlab code that mysteriously no longer works after the latest update knows what I'm talking about.
What makes you think it would be any better had they not used MATLAB?
I actually like MATLAB. It really excels when used as a glorified calculator and you can plug lots of things into it and have it 'just work' without much fuss. When I worked in a tutoring lab sometimes it was cool to have around because I could quickly whip up something interesting and visualize the whole thing to explain concepts. When I worked in the research lab (after I completely trashed the old application and started my own) I could hook up the computer to some cool hardware, run the experiment and do the statistical analysis all in one place. At my job now, people who aren't good at programming can use a computer to solve very hard problems.
I don't know why it's getting so much hate. I agree that it's not a good tool for every problem and that in the scientific community (and especially the psychology community) it is overused. But I don't really see why switching to another language would make things better.
Probably the most general cross-disciplinary reason MATLAB worsens an already bad situation is that it isolates scientists and engineers from people who are good at programming. When you seek out help for a particular problem, it's often a blind-leading-the-blind situation. How can you learn to program well if you've never seen a good piece of MATLAB code? Good luck finding good examples and role models to learn from if your programming universe is limited to MATLAB. Poor quality and practices proliferate because there is almost never anyone skilled reviewing changes and helping you get better. People just make a change and pray it still works.
From my own experience, though... I'm doubting you. I really don't think these people see a problem with what they're doing and wouldn't care even if they did - so why would they ask for help? You'd have to have someone sitting over their shoulder all the time training them (most colleges already have introductory MATLAB courses, so apparently that doesn't help much) - no one would like that arrangement.
But what you've identified isn't really a problem with MATLAB, is it? It's a problem with the culture of people who tend to use it. It's a real problem, but I'm not sure what can be done about it other than to try to get at these people while they're still young and learning.
Yes, it is. Everybody that knows what they are doing moves away from MATLAB as fast as they can. That's MATLAB's fault.
Except for teaching, mind you. The entire problem is that MATLAB is a great teaching tool, and a completely worthless tool for anything else. Guess what, lots of people stick with what they learn at school.
But there is still no notion whatsoever of namespacing, modules or a usable class hierarchy. It is thus very hard to organize code in a modular manner. Matlab actively encourages globally-scoped script files and long long functions. This makes constructing medium to large sized systems very painful and error prone.
TL;DR Matlab is fine for a single script or two. But anything larger than that is immensely complicated by it's lack of code organization.
The hilarious thing is that basically every feature added to the Matlab language since the beginning has been an attempt to control the namespace problem, and they still can't solve it. Besides subfunctions, nested functions, and anonymous functions (and does anyone using them actually understand all of their scoping rules), you have old style classes, new style classdef, packages, and sometimes case-sensitive and sometimes case-insensitive identifiers.
It's a mess. And I don't think it will ever get fixed.
It's a terrible language. One function per file, you need to special case LxMxN matrices where N is variable in the case N=1, can't do myfun()[0:4].
Use it for a while and you will run into painful limitations.
2) Many Matlab users don't write any code but scientific code. They couldn't care less about how flexible python (or other language) is, when they already use and know Matlab.
3) Matlab doesn't make money from colleges or grad schools, they make money from industry customers. Of course the engineers and scientists of those deep pockets get trained at colleges and grad schools.
4) If you can write python, c++, or javascript, and if you keep publishing scientific code in that language even when Matlab is better suited, then it is possible that others will come with you. I am rooting for you. Just so you know, depending on the field, if you published your code in Matlab or R or whatever is the most popular for the field, you'd probably get more citations. Since academia is rounding error in Matlab's income, you will only be hurting yourself, if you chose not to use Matlab in a problem that it is best suited for.
5) Projects fail for many reasons. But, in your case, could the common denominator be the university rather than Matlab? In universities, it is hard (and I'd say unethical) to keep students for very long, so a research group may end up with a lot of code without owners if they are not careful. Good labs manage their projects, codebase, and hand-offs better.
What we do view Matlab as is an exceptional domain-specific matrix manipulation and data visualization language. The IDE is exceptionally easy to use, and combined with the great graphs/plots makes debugging and iteration very easy. If we need to do something Matlab can't, we write it in a different language and use files for IPC. This approach covers 99.9% of everything we do.
I get that Matlab is super expensive, and that annoys me too. I'd love to use it at home, and not struggle instead with terrible development environments(I use SciPy/Matplotlib at home - mostly from an IPython shell - Spyder doesn't cut it, even though I wanted it to so much). But my workplace pays real engineers and scientists fairly large sums of money, and doesn't bat too much of an eye at paying for productivity tools, the cost of which I feel is the main disadvantage of Matlab.
For example, let's say I want to apply DCT to a matrix. In Matlab it's simply dct(A). How do you do that in Python? Well, there's scipy.fftpack.dct, but when I try it, it turns out it operates on the rows of A, instead of the columns. So I start searching the help, and find there's a parameter called "axis", with the useless description "Axis over which to compute the transform." So I try axis=1, axis=2, then finally axis=0, and presto, it works. So sure, it's functionally equivalent to Matlab, but do I really want to go through all this every time I want to accomplish a simple task?
Scipy/Numpy/Pandas are, at the moment, not the comprehensive, well documented and consistent platform that Matlab is. Simple things like a less than painless install process and numpy examples like "a*b" can be element wise multiplication or matrix multiplication pending if "a" is array or matrix are enough to put of my coworkers off for at least a year or two before contemplating a switch again.
Where they really shine though, is scientific code that needs to do a bit more than numerical computation. I've tried Matlab briefly, and it was hell. Things like parsing strange text files for the source data, scraping data from websites, pulling data in from a SQL database, or publishing the computation as a web service are all easy with Python.
Spending a small bit of extra time on the core matrix code is okay to get the rest of the Python ecosystem and libraries (and even for loops that make sense).
SciPy's DCT is meant for multidimensional arrays. Array indexing begins at 0 in Python, just like it does in many other languages. So, it's only natural that they'd count axis numbers that way too.
> do I really want to go through all this every time I want to accomplish a simple task?
Entirely your choice. Your choice is not a reflection on the quality of the product.
"Any sufficiently complicated C or Fortran numerical program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of MATLAB/Octave/Scilab."
This could be called Gastón's corollary :-).
MATLAB, Octave and Scilab are like the UNIX shell but for matrices instead of text streams; this is they problem domain. If you can explain a problem with matrices and their operations, you can profit from MATLAB/Octave/Scilab. If you need more speed from your program, you should profile it and develop a mex-function in C or Fortran.
In academia and engineering most programs are developed to run at most thousands of times (<10,000), and this statement could be greatly exaggerated; the developing time must be reduced in order to work in other projects. The usual approach is brute force.
The greatest problem that I find with MATLAB is that doesn't allow multiprocessing. In my last project, I ended developing several interpreters in Bison/Flex/C that ran concurrently in order to control a robot, but the main program was developed in MATLAB because it was simpler that way.
Things for which MATLAB is not good:
-Systems programming -Web programming -Scalable business logic programming
Things for which MATLAB is good:
-Robust simulations -Computationally intensive desktop applications -Any computationally complex tool or utility -Mathematical data processing
Things for which MATLAB is the absolute best tool available:
-Design and rapid prototyping of DSP and GPU bound algorithms. -Windows desktop calculator for engineers -Prototyping communications system (Labview maybe better for very complex systems, but certainly not simple ones) -Design of financial, image processing, communications, signal processing, or control systems algorithms.
----------------------------------------------------------
MATLAB® is a high-level language and interactive environment for numerical computation, visualization, and programming. Using MATLAB, you can analyze data, develop algorithms, and create models and applications. The language, tools, and built-in math functions enable you to explore multiple approaches and reach a solution faster than with spreadsheets or traditional programming languages, such as C/C++ or Java™.
You can use MATLAB for a range of applications, including signal processing and communications, image and video processing, control systems, test and measurement, computational finance, and computational biology. More than a million engineers and scientists in industry and academia use MATLAB, the language of technical computing.
----------------------------------------------------------
I work at a place where people use (and abuse) MATLAB a lot. The thing is, they're not programmers. As smart as they are (and they are truly brilliant) they're not especially good with computers, programming or computer science. If they tried to use a 'real' programming language, things would undoubtedly be even worse!
MATLAB is awesome at giving you powerful functions baked right in. That's good because people who aren't good at coding efficiently don't have to. Instead of messing up the whole program from start to finish, they only mess up the top level and that often isn't as big of a deal as messing up the small components that get used again and again and have to be as efficient as possible.
I agree that MATLAB isn't a general purpose programming language, but I don't think that that's how MathWorks is really selling it (note that "[creating] applications" is at the end of the list and analyzing data is at the beginning). They're mainly saying it's good for solving a specific group of problems - those that technically minded people (like scientists, engineers, economists and financial analysts) have to solve. I actually agree, especially when you take into consideration the fact that the people who really like MATLAB the most aren't really into programming or even that good at it.
Of course that's just my opinion. I'd like to hear how you guys disagree with me.
In any case, I've found that those parts of matlab can actually be used pretty effectively. I think the reason is that, even though matlab as a language is pretty crappy (IMO), these domains aren't actually dominated by programming languages. Take for example industrial control. It's extremely common to use PLC's, PAC's or FPGAs. These tools are, like simulink, largely operated via proprietary graphical environments.
Essentially, I agree with your points for uses of matlab where you don't write much custom code, and/or where your custom code is very insulated from the 'real world' and even from the rest of the system.
All I ever did in matlab involved matrices (usually differential equations with matrix coefficients and other things of that nature) and matrices are super easy to use in MATLAB:
A = [1 2 3
4 5 6];
A = [1 2 3; 4 5 6];
A = array([[1,2,3],[4,5,6]])
Even if you're doing complicated operations because matrices are the essential building blocks of MATLAB it is easy to use, not so much in python.
I tried building my FEA (finite element analysis) project in python after i finished programming it in matlab it and found it to frustrating to continue.
Maybe R and Numpy are getting better, but try to invert a matrix, find and eigenvalue, find the solution to a polynomial, fit an equation, etc Not to mention the most advanced things outside Matlab
Simulink is a whole different world inside Matlab as well
Here's something that doesn't look like it's covered by NumPy 100% http://www.mathworks.de/de/help/signal/ug/iir-filter-design....
Yeah that's exactly the kind of stuff I meant when I was talking about pulse coding and such. Although the last time I had to do some filtering stuff I did manage to use python+scipy, but yeah it hasn't progressed as far as matlab in a lot of those niche engineering areas yet.
Where I've found matlab to still be ahead is in the area of domain specific engineering. For example, if you want to manually pulse code a signal using some specific modulation scheme, matlab has a tool for just that. In python you still have to manually write a bit, interface it to the fitting routine, and convolve it across your signal.
> The first problem is that the MathWorks actively markets MATLAB as a “general purpose programming language” with all the trappings, something which it is manifestly not.
From MATLAB site http://www.mathworks.com/products/matlab/ :
> MATLAB® is a high-level language and interactive environment for numerical computation, visualization, and programming.
"high-level" != "general-purpose". The author grossly misrepresents Mathworks' stance regarding MATLAB
- In academia, people really do not seem to give a fuck about using the right tool for the job. I used to try to explain to the people in my lab why their software was crashing, why it took four days to finish running, or why it would be easier to write new code than try to adapt the code written by the undergrad from 5 terms ago. About 70% of the time is was because the code had been written in the most naive way possible. The rest of the time it was because it was written is matlab. Seriously, it takes tremendous effort to write matlab code that doesn't suck. And even when you manage that, it's still crappier than if you'd used a proper programming language. So, yes, the author is right to rag on matlab as a language. But you know what? NOBODY CARES! The process goes: Carve off a problem, write some code, produce plot, publish paper, put figure-indicative-of-progress into grant renewal application. The people in charge don't care if twelve undergrads lost their eyesight debugging the code, and it stops working if the lab door is shut too loudly.
- I learned that if I just wrote my software in the proper language, in the proper way, and didn't tell anybody I was doing it that way, everything worked out extremely well. The above cycle was allowed to complete, the people in charge usually didn't even ask, and in a month when they asked me to adapt my work to include the marvelous thing the ultrasound lab had come up with I could just say "Okay!" without wondering if matlab would inexplicably fall on its face when I was 90% through the development.
- Even if you manage to get a conversation about choice of tools going, most of the people present will nod and pretend to be interested, but won't change anything at all. The people who will "see the light" and make an active attempt to improve their understanding are generally the ones who would have done it on their own eventually. (side note: I did successfully--and accidentally--convert a large sect of the physics department to python, and it's all they use now. They even started using proper SCM!)
- When working with matlab, I always had my best results when I did two things. First, keep the approach to coding as simple as possible. Don't try to make things too generic, don't try to make the code too fault tolerant, don't try to implement STM. Second, use the built-in shit! There's a toolbox for that? Use it, ship it. The idiomatic way to do something makes you ashamed to operate a keyboard? Do it anyway (usually). In other words, don't fight it, because you will never get what you want. That doesn't mean don't do any error checking. That doesn't mean blindly use libraries that give you the wrong answer. But overall I found the path of least resistance produced my highest productivity with matlab.
- Sometimes, matlab is actually kind of okay. I can still fit a univariate curve faster in matlab than I can in python, excel, gnuplot, or mathematica. I think R still probably has the most concise syntax for this task. Learn to understand the niche areas where matlab shines, and take advantage of that.
- As soon as the default performance of matlab is not good enough (i.e. profiling your code shows no obviously large improvements available), either change approaches, make your problem smaller, or stop using matlab. There are lots of options for improving the performance of matlab code: distributed computing toolbox, mex files (calling to C), proprietary optimizers/compilers like Jacket, contorting your problem to fit matlab's memory layout... it goes on. However, I've found every one of them to be more trouble than it's worth.
- Matlab is not a general purpose programming language. Know that, and be free.
I would like to add that scientists are neither averse to change, nor too lazy to learn new tools. However, they typically only care about the solution to their problem, not about programming in general. It is thus futile to try to convince them to use a different tool from a programmers' point of view--you need to convince them by showing them how much simpler they can solve their problems.
We are right now in the process of switching the introductory programming courses at our university from C to Python and I very much hope that we will be able to phase out Matlab as the default choice for the intermediate courses in the coming years.
Of course I'm at liberty to improvise my "syllabus." I decided to introduce lists before program flow. I introduced range() as a way to populate a list. And then we started doing things with lists using constructs like [x2 for x in range(-10, 10)].
At that moment, my daughter asked: "Can we use Python to make a graphing calculator?" With my syllabus in tatters, we installed matplotlib and played with it a bit. I've explained to my kids that in programming, sometimes we have to look up and use things before we fully learn how they work.
This approach would probably make no sense for teaching C, where looping comes before lists. But in my idiosyncratic mental map of Python, lists come before looping.
I'm not dogmatic about what first language to learn. My only intention right now is to see if my kids will take an interest in it.
However, I am teaching an introductory programming course and I have seen many a student terribly confused by manual memory management and low level data types. My hope is to be able to introduce the very basic parts of programming (variables, assignment, branching, looping, functions) without having to go into any OOP or containers.
There are always people who will never get even those most basic concepts, but there might be some who will get a basic glimpse of what programming means who would otherwise fail at basic C data types. In the end, they will all need to understand all of Python, then C, then (sadly) Matlab.
What you are describing is indeed very interesting. One has to be very careful to not introduce too many concepts too early. So maybe, one should restrict looping to while loops until lists are introduced. And string processing could be taken as the introduction to OOP.
Is that really true? I think my language ordering went something like: qbasic, perl, visual basic, python/c, php,<others>, more c, c++, <others>
So strictly speaking it was at least a year or two before I learned C for the first time. However, while I certainly wasn't as well informed as I am now, I wasn't completely clueless. I knew that the things I was doing in perl were actually allocating memory, that perl was helping me with lots of book keeping, that there were things called pointers that pointed to things, etc.
I might not have actually worked in detail with the concepts yet, but I did have an idea that there was something below what I was working with. I think that by bearing that in mind, I was able to 1) know that I would have to learn the 'hardcore' stuff eventually and 2) focus on the actual programming, in the sense of making the computer do what I wanted.
One could argue that it isn't. In science, the concept is usually more important than the implementation.
But I totally agree. Scientific code tends to be awful and I wish I knew what to do about that.
The concept may be the most important thing, but what good is a paper asserting some new concept if everyone can't verify it? I think it is the approach that folks like Fernando Perez at ipython are pushing with their html notebooks. Reproducible, comprehensible science.
I'm not a big Matlab fan, but I do sometimes envy the areas where there's a default environment everything is expected to plug in to, whether it's Matlab or R or something else (Python, increasingly).
That said, I'm not against a uniform environment; there are definitely advantages to having everyone on the same platform. I would just prefer we all piled into a greyhound bus instead of a retrofitted rail carriage powered by a pack of dogs.
I couldn't agree more. WHile I've had only a brief stint with MATLAB at an internship, the code was possibly the ugliest thing I'd ever seen. Given that I'm a physics major and will probably be encountering matlab quite frequently, I sure hope that it won't be so horribly documented, and just so unreadable.
I was so offended, I had to rewrite over 2000 lines of code in python, and on completion, the python code was a little of 700 lines, clean, and so god-damn readable.
To any other academics out there, I urge, no plead with you to consider using a more general purpose programming language. It is a nightmare for undergrads like me to try and extend matlab to further applications.
However, I'm glad to say that the first computational physics course we will be taking at our university teaches us python, thankfully someone in the department had a clear view of what was going to benefit us.
Coming from another physics major... don't get your hopes up. Just do your thing and hope that others follow suit.
> I was so offended, I had to rewrite over 2000 lines of code in python, and on completion, the python code was a little of 700 lines, clean, and so god-damn readable.
It's amazing how easy it is to rack up 2000 lines of matlab repmat mashing. On the bright side, at least your lab didn't insist that you stick with their nightmare of .m files.
> the first computational physics course we will be taking at our university teaches us python
Indeed, that should be fairly pleasant. Particularly because you can easily implement a lot of the iterative algorithms without needing to translate all of the mathematical 1-indexed stuff into c-like 0-indexed memory. Can't tell you how many bugs I had because of that.
My first comp phys course was taught using only barebones C. We had to implement all the numerical routines from scratch, with nothing but stuff like stdlib.h, math.h, etc. In later courses they allowed us to use whatever we wanted really, but often the techniques would be very complex and the prof would provide some matlab code for us (e.g. an n-dimensional meshing routine) that was too much of a hassle to re-implement, so I ended up doing a lot of it in matlab anyhow :-/
If you've been through the same thing, I would definitely want to be able to contact you in case you have any advice on such matters.
Could I request you to provide me some way of remaining in touch with you?
Thank you!
If having an IDE is an issue, Julia also has one (http://forio.com/julia/index) which looks a lot like Matlab.
It's free software and the language is 99% compatible with Matlab.
Edit: and yes, Matlab is not intended for any generalisation/abstraction. It's a big scientific calculator with REPL. And complicated program in it still feels like big calculator
http://wiki.octave.org/FAQ#What_features_are_unique_to_Octav...
This is all in development and almost completely functional in the current Octave dev branch. I hope our next upcoming release will satisfy you more.
I don't see a compelling reason to use Octave unless you're trying to avoid paying for a Matlab license. If you're going to switch tools, why not switch to NumPy/SciPy and get the advantage of using a full-featured programming language?
We're currently working on a getting a JIT compiler into Octave too. Here are two GSoC blogs about it:
http://octave-jitc.blogspot.ca/
http://jit-octave.blogspot.ca/The language itself is very feature complete, however. Our main current goal has been for you to be able to grab your Matlab code and run it without modification in GNU Octave. For 99.9% of the lines of code in your code (assuming you don't use classdef), this works. The problem is that you might not always want to modify the remaining 0.1% lines of code to make them run in GNU Octave.
E.g., here's a note from the implementors of a probabilistic modeling toolkit, which prominently includes Kevin Murphy [http://code.google.com/p/pmtk3/wiki/WhyMatlab] and here's a note from someone vacillating between several languages [http://jack-kelly.com/which_programming_language_for_my_disa...], either of which shows more nuance and intelligence than the blog in the OP.
And amateurs (including me) don't always see the difference between the language and the libraries, so the demand for a "real programming language" results in a huge bloated product festooned with every possible bell and whistle.
I wouldn't have a problem with a tool that falls short of completeness (Turing- or otherwise) if it's simple and does something useful for me. I love spreadsheets.
But the cost gets to me. It inhibits collaboration, and costs a ton for non-academics. From scientific computing[1]:
> $1,900 for the commercial Matlab; $2,800 for Simulink; and typically $800 for each toolbox.
The whole Matlab suite doesn't sit well with me, so I'm most likely a Pythonista. The speed of Numpy/Scipy is comparable, and the quality of the Matplotlib plots wonderful. In fact, I've done a speed comparison[2] between between Python and Matlab. I would have optimized more in Matlab, but didn't have access to the Optimization toolbox.
[1]:http://www.scientific-computing.com/review1.html [2]:http://nbviewer.ipython.org/urls/raw.github.com/scottsievert...
About a decade ago, my then-boss dragged me to a weeklong LabVIEW training course. The course was geared toward scientists and engineers (like my boss — I was sysadmin/programming/IT), and the instructor wanted people to bring data, problems, etc. from their own research to work on during the "hands-on" afternoons. I didn't have research, but I did notice that LabVIEW could open TCP sockets...
By the end of the week, I had written a barebones graphical MUA (e-mail client) that could read mail via POP3 and send via SMTP. "Written" entirely in LabVIEW. (The "code" was spaghetti – tons of boxes of all sizes and a rats nest of wires connecting everything together.)
The instructor asked for a copy to take back to NI, and I'd like to think that some NI engineers got a good laugh and/or vomit out of it.
Most people focus in LV's visual programming paradigm. But I think its real power come from the Flow Based Programming model. Functional programming is the trendy solution to the problem of concurrency these days. But I think FBP could offer some solutions in this domain too. NoFlo looks a promising new technology in this area. http://noflojs.org/
No, really, Mathematica is great. It can do some amazing things and it's really easy to write reusable code for.
I tried to learn it a few times and it worked great for toy problems, but when I tried to write an entire script a la python/c/matlab, I failed miserably
Also, 7 lines is hardly a good metric to judge the general effectiveness of an environment or language.