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