The author is totally biased, but that doesn't mean he is wrong. If the bias offends you, you aren't the target audience. I personally have experienced several of the things he rants about, so I know his pain and now as a policy refuse to produce additional IP in that ecosystem. When friends ask me for help, I now send them a python script.
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.
I have seen some horrible shit. Terrible, awful, fucked up stupid undocumented code. I have worked in psychophysics shops (go figure).
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.
> What makes you think it would be any better had they not used MATLAB?
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.
> But what you've identified isn't really a problem with MATLAB, is it?
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.
One of the problems with Matlab is that it does not encourage any sort of partitioning scheme for code. It even makes the simplest form of partitioning (functions) excruciatingly frustrating by requiring them to live in their own files--thank god there are subfunctions, nested functions and anonymous functions.
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.
Yes, the fundamental problem of the Matlab language is the namespace problem.
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.
Back in the day when I was in a psychophysics lab as an undergrad I managed to take the entire mac I was working on (system 7 I think) with my supervisor's crappy psychophysics experiement code. Fortunately one of the uni sysadmins was there cracking passwords on the uni network from the HP-UX cluster and restored it for me PDQ.
1) Matlab is awesome for scientific computing and simulations.
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.
For something to be oversold... it has to be sold as something in the first place. I work at a company which uses Matlab extensively. I don't think anyone here views Matlab as a general-purpose language, even though you can put together some fairly fancy things in it.
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.
I've been working with Matlab for years and have been quite intrigued by claims that SciPy is the new, better, Matlab. But every time I tried it, it felt like a cheap knockoff.
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?
Numpy, Scipy and Matplotlib aren't a 100% clone of Matlab, but they do provide much of similar matrix manipulation and data visualisation tools.
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 description could have been better. However, if Python/SciPy feels like a cheap knockoff, it's entirely your fault. By that logic, SciPy is also a cheap knockoff of BASIC, C#, R, Tcl, etc. "NumPy and SciPy were created to do numerical and scientific computing in the most natural way with Python, not to be MATLAB® clones." [1]
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.
So, basically, you're panning the massive open collaborative effort behind SciPy/NumPy/Pandas because you can't be bothered to learn a slightly different and more flexible syntax? Because that's what it sounds like.
No it runs deeper than that. In my experience Matlab is used by people who are not programmers and don't aspire to be them. Ever. They want to easily prototype ideas and have zero interest in the machinery that makes it run.
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.
Having the dct operate row-wise is not a different syntax, it's broken. The dct is a linear transformation and linear transformations operate on columns, not on rows. (Unless you apply them to the transpose of the matrix, which is what the SciPy dct is doing.)
Paraphrasing the Greenspun's tenth rule of programming:
"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.
In academia I'd say most programs are run (when finished) 2-3 times - once on a smallish testset when you decide that this version is correct, second time on the full data that you have to produce results for the paper (and you don't care how long it runs as long as it finishes before the submission date); and maybe a third time if you get a larger/better dataset somehow.
It's sad, but you're right. In my field, I've found that there is little interest in experiment design when doing data analysis; you'd be asked to perform an analysis on eight or ten data sets, only because the people think that is exhaustive.
MATLAB is a tool that is unmatched in algorithm design. It isn't C, it isn't python, and it certainly isn't Linux. If you happen to work in an industry where you actually do math at your job, then you should probably use MATLAB. Otherwise, just don't use it and stop complaining.
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.
I'm curious... is the matlabbing that happens at your work related to the simulink/realtime/control parts of matlab? Based on the other things you've said it sounds to me like that might be the case. Obviously I might be wrong.
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.
We don't use simulink or anything like that - we just use the typical linear algebra stuff: Markov chains, finding eigenvalues, solving linear systems, etc.
And that's the thing with Matlab, it does the math part really well
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
Well, matlab--ahem, matrix lab--does certain bits of math quite well. But I would say that R/numpy are most than just 'getting better'. They literally do every thing you just mentioned, and typically their implementations go beyond matlab's.
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.
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.
I'm not the parent commenter but I've used matlab extensively and found Numpy clunky in comparison.
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];
or
A = [1 2 3; 4 5 6];
I can input A just like that and it works, try out the python syntax:
A = array([[1,2,3],[4,5,6]])
And it just goes on from there.
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.
It's very easy to write crappy code in python. And that's why I love it - it doesn't try to protect the programmer from themselves, instead it lets you do what you want (for better or worse). Compared to languages like java...
As someone for who matlab was his 5th or 6th language, I can say it's frustratingly opaque. Even once you have a good feel for how the linear algebra works, you find yourself struggling for hours to transform a simple cell array into the format you'd like. I deeply hope that when Julia matures it puts matlab into its grave.
> 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.
Okay, I'll bite on this one. I used matlab quite extensively (for years) in the medical imaging field, as well as other miscellaneous engineering (read: electronics, modeling, FEA. Not web apps) disciplines. I noticed several things about the matlab culture:
- 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 could not agree more with every word you have written here.
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.
The thing is it isn't just about solving their problems. The tough thing is to convince them how much it would help the community as a whole. I have tried many times to download some PhDs code and attempt to get it to compile. Usually it can be done after a lot of effort and tweaking. But it would be beneficial for science if code was treated as important as the paper itself.
That is one point of view. Another is that the entire scientific community is entitled to peer review your work, and you should enable them to. Not just your referees, who will likely not compile and test your code, anyhow.
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 LOVE ipython and its notebook! It is seriously one of the best things to happen in the last few years for scientific computation and teaching! So amazing!
I've had an unfortunate opportunity to have to help out a cousin's girlfriend with python. She's studying informatics and it's their introductory course in programming (recently switched from pascal). But python has really too many abstract constructs to explain easily. One example they had was using the for loop. I don't know python, but from the examples and exercises the professor gave them, it doesn't seem to have a "normal" for loop. All the examples used the function range() to generate an array of indices to loop over. Which is silly, since they don't cover functions and arrays until later. I had a hard choice to either go into details of why it works or tell her to just memorise it. Later on in her materials, after introducing arrays, suddenly the for loop doesn't use indices and she has to unlearn the old way. The other problem was explaining strings and methods, which they use (such as str.uppercase()) but their introductory course doesn't cover OOP. The last atrocity was an example of looping over lines in a file using the for construct. Of course, polymorphism, iterator patterns and so on are too advanced, but it really bothers me that they have to just memorise stuff without knowing why it works. I'm glad I had C as the first language. Firstly you generally learn how the CPU actually handles instructions, since C is so close to metal. Secondly, after C you can really appreciate what other languages have to offer. And thirdly, I really prefer the bottom-up approach. Then again, my perspective might be a bit skewed, since I graduated in computer engineering, which is a bit more involved than informatics.
I'm teaching Python to my kids (ages 10 and 13) right now, after finally ditching Visual Basic myself last year.
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.
Totally agree. I learned C first, then C++. I wouldn't have it any other way. The top-down approach means you truly understand nothing until a year or so down the line. The bottom up approach lets you fully grasp the small world you've been exposed to. And as more concepts are introduced your world expands. At no point are you just left wondering WTF are these magic keywords doing.
> The top-down approach means you truly understand nothing until a year or so down the line.
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.
I more often see the opposite problem in CS academia. People care too much about what tool is best for a job, and as a result nothing is easily interoperable. One grad student writes stuff in Haskell, another one uses OCaml, a third does everything in Python, a fourth uses Common Lisp, and you're lucky if a fifth doesn't use his custom, self-maintained Scheme dialect that he swears is perfectly adapted to the job.
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).
Are you in CS, by chance? ;-) I think the frequency of people who can even comprehend haskell drops off significantly once you walk over to the chemistry building.
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.
> 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.
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 :-/
This is the reason why people should migrate to general purpose languages that can also be used for computation, such as Python and pandas (Python data analysis library, http://pandas.pydata.org/), or languages that are modern and have been designed for such a purpose, like Julia (http://julialang.org/).
Julia seems like an easy transition for any Matlab programmer. The syntax is very similar and the built-in package manager makes finding new libraries way easier. And apart from that, performance is awesome.
Wow, that whole blog is focused on bashing Matlab. I find it a little difficult to trust a source that biased. If they can't find something good in a product that has been around for, according to wikipedia, something like 30 years, then that source shouldn't be trusted. I searched around to see if I could find something about the author but didn't see anything. Curious to see what their reasoning is.
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
As someone who loves Matlab but would rather use a free-software solution, I must say that Octave is not an effective replacement for Matlab. Matlab itself is just so much more feature-complete and polished, turning to Octave feels like going back two decades in technology.
We're actually pretty feature complete wrt Matlab. The biggest things that are missing are the GUI, classdef OOP, and a JIT compiler. All of these currently have very lively and active development. Hopefully our next Octave release will seem less archaic to you.
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.
In what way is Matlab more feature-complete and polished? With respect to just the actual language Octave is nearly a 1:1 implementation of Matlab, which is an primary goal to stride for and maintain, any differences between the two is considered a bug even.
Octave has handle graphics and almost all of the handle graphics properties that Matlab has. Do help us record which particular bits of handle graphics you're missing. It helps us to have a list of what's missing.
Matlab is usually run as an ide with an interactive window (command line interpreter). Graphics are built in and interactive, you can interact with any number of graphics windows and with the command line at the same time (this is difficult to do in python numpy and matplotlib), and you can tweak the graphics windows from the command line to add GUI buttons, boxes, etc. This all comes built in to the most basic MATLAB commercial offering.
Matlab is much faster. For a sense of scale, a relatively simple image processing script ran 125 times faster in Matlab than Octave. This is, most likely, because Matlab has a better code optimizer.
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?
The "code optimiser" you're talking about is "just" a JIT compiler. Loops in Octave are slow. They were slow in Matlab too, but then they got a JIT compiler.
We're currently working on a getting a JIT compiler into Octave too. Here are two GSoC blogs about it:
Not all of them. Some of the most annoying things about the Matlab language we attempt to fix, as long as we can still run existing Matlab code. For example, you can index temporaries in Octave: x = sin([1, 2,3])(2). A few more things here:
In a crowded market, the sales pitch has to anticipate and overcome "negatives." Thus, MATLAB has to be marketed as a "real programming language" to overcome the fear that it will prove inadequate for some task in the future -- especially when you had to beg and plead for the money to buy a license.
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.
Matlab is useful for it's special use case -- for mathematical applications (signal processing, medical imaging, etc). It has good tools to speed up the code too: parfor and the like.
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.
Is there a "Matlab: The good bits" guide out there somewhere? I think a style preference guide, made by an experienced programmer who worked on large matlab codebases would be valuable both for programmers who have to figure out how to work reasonably with Matlab, and the scientists and mathematicians who just don't know any better.
I also did psychophysics in Matlab. However, the author conveniently does not mention the wide variety of toolkits available for psychophysics in Matlab ... e.g. http://psychtoolbox.org/HomePage
Random "LabVIEW isn't a general purpose programming language...except it kinda is" story:
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.
Yes, the cool thing about LV is allows you to turn an idea on a flow chart into code that resembles the original chart on the high level. And, nothing beats it for data acquisition and testing. Like all visual languages big projects and the finer implementation details can get ugly.
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/
I have written a bunch of programs for interfacing with instruments and when I started doing that I was using labview but it was such a pain. It was liberating when I found that VISA has python bindings. I now do all the instrument-interfacing code in Python+Qt. It is so much more productive that it makes me wonder why do people still want to use labview for this kind of job. I mean its visual language is complicated that it makes even the simplest things (like formatting a string) difficult. And on the top of that if you try to make something more complex the block diagram is completely unreadable. Madness.
It all boils down to using the right tool for the job. If you need performance, C will blow python out of the water. If you need a quick solution that’s light on data acquisition and heavy on algorithms, python will probably be a better choice. I’ve run into a highly concurrent, signal processing tasks handled beautifully with LabVIEW and its built in SP modules. Python would have been a terrible choice for that application.
Mathematica, on the other hand, is brilliant. It's a wonderful language with wonderful libraries and functionality, and it's quite clear how to write robust code in it.
Mathematica is also incredibly well documented both online and within the program itself. The program supplied documentation and help is actually useful, something which is unfortunately not common in computing.
What advice or pointers would you give to start learning & using mma for real problems?
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
The solution is basically a cross correlation in a colour channel between the image and a zebra pattern. That can be done in a few lines in more than one language.
Also, 7 lines is hardly a good metric to judge the general effectiveness of an environment or language.
Matlab was my first real programming language. I guess the real "power" of Matlab is the collection of toolboxes (which carry a separate price tag for each) and the graphing capabilities and built-in vector functions that are easy to use. I think it was conveniently entrenched because it was the cheaper than Mathematica(?), I can't be too sure but there weren't many alternatives with a similar set of features.
Mathematica is a lot cheaper than Matlab, in the US anyways. Mathematica excels at symbolic computing, where as Matlab excels at numerical computing. Mathematica happens to be poor at numerical computing, and Matlab happens to be poor at symbolic computing, although Mathematica is becoming better at its current weakness at least.
Matlab is just another tool for your toolbox. Part of programming is choosing the right tool. I found Matlab extremely useful in college for graphing my lab work. Haven't had much use for it since. Did run across OpenTLD AKA predator. It's is a sweet CV app that is primarily written in matlab.
https://github.com/zk00006/OpenTLD
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.