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