Matlab is, to the programmer with experience in almost any other language, a tremendous horror. The language is almost as cobbled together and inconsistent as PHP with the added bonus of being worked on almost exclusively by engineers instead of people who actually want to write programs (this coming from an engineering student here).
That being said, if you have the mathematical chops to rearrange your problem into something solvable via matrix transformations, you can probably write it quickly and elegantly in Matlab without worrying too greatly about execution speed. Better, the built in toolboxes have already solved huge (engineering) problem spaces. Code already written is better than code potentially written...
Unless you want a solution that is repeatable or more general than Matlab affords. At that point you'd be better off doing the math by hand. I feel that the Python et al and C solutions fit into this niche. Prototype the math in Matlab, implement in a language that doesn't suck.
I don't agree Matlab is a horror - and I am a CS person, not an "engineer" as you say. It is an excellent domain-specific language. It might not be a good general-purpose language, but it was never intended to be that. True, some of the "bolt-on" parts of Matlab feel inconsistent, but the matrix/vector/tensor core is very elegant and powerful.
I would consider Matlab to be a DSL grown out of control. If you are working purely with matrix/vector/tensor math, as you say, you can be reasonably comfortable with the language as long as you remember to double-check the docs on nearly every function before you use it just in case there is some strange edge-case it handles awkwardly.
Unfortunately, in any real project I've ever done with Matlab you cannot survive just inside the matrix DSL and once you start touching the bolted-on bits you lose patience very quickly.
So, I suppose I agree, it's a nice DSL, but I'd also wager that the majority of people using it don't realize the limitations implicit there.
Or stupidly. I don't know if the following should qualify as an edge case generally, but it does in Matlab.
The controls lab in the aerospace department at the U of W had a wonderful inverted cart-pendulum device that a grad student was doing some seriously freaky non-linear control research on. We were tasked, as part of a lab, to write a controller in Matlab that would balance the pendulum and move the cart to a designated position. After trying for days to come up with a combination of gains to result in stable control, I decided to write an evolutionary algorithm to choose a controller.
It was dead simple. The genome was a list of gains. The code created generations of genomes and then ran them through the simulation. The tricky part (for me at that time) was finding the settling time (walk backwards from the end of the data, checking for values outside of the tolerance). Choose the winners, perturb, preserve best performers, and go around again. Doing all the steps by hand worked wonderfully.
When I ran the code, I got combinations of gains that resulted in massively unstable systems; systems that overshot off the chart as soon as physically possible given the hardware. What was going on?
It turns out, when I ran the simulation from the command line, Matlab graciously accepted my 5-second simulation time. However, when run from a script, Matlab ignores that parameter and runs the simulation until the output careers off the chart. Because I was looking for a minimum time with no overshoot, my algorithm was finding combinations of gains that overshot steeply enough to convince Matlab to stop simulating ASAP! It was bizarre. My secondary condition was minimum overshoot, so I got solutions that were exactly steep enough to cause the simulation to stop when the output hit the desired value!
A friend of mine stumbled on to a workable combination of gains. I used those.
You're misrepresenting the situation a bit. Matlab was not stupid here. The evolutionary algorithm you implemented found a way to satisfy your constraints that you didn't think of. That would have happened regardless of the language you chose.
I'm not arguing that Matlab is beautiful - it's not. I have worked in Matlab for years and years, and know most of its ugliness. But your example highlights your frustration with the task more than any particular weakness of Matlab.
The point is that the behavior changes based on whether you are running from the command line or from inside a script, that this is completely arbitrary, and that there was no override possible for this behavior. When run from the command line, simulations for combinations of gains that caused the system to career away did indeed career away, they just continued to do so for the full length of time specified in the function call. That kind of abject flakiness renders the program unsuitable for professional use in that you can't plan for those kind of quirks. I had invested hours by the time I worked out what the bug was, and invested hours more trying to fix it. I finally had to give up, after investing my time and effort, because the platform was fundamentally and fatally incapable of doing what it was asked.
It is completely unacceptable for a package to have such wildly different (and undocumented) behavior for the same exact function call. Matlab was indeed stupid. It was a buggy minefield of stupidity when I was using it.
Finally, it looks like your defense of this awful weakness on the part of Matlab is, ironically, a result of your commitment to the platform rather than a reasoned response to the case outlined.
It seems I didn't read the final paragraph in your original post very well.
I was not defending a weakness of Matlab, but instead misunderstood what you said. Indeed, I'm a pretty harsh Matlab critic myself because I know its ugly parts well.
That being said, if you have the mathematical chops to rearrange your problem into something solvable via matrix transformations, you can probably write it quickly and elegantly in Matlab without worrying too greatly about execution speed. Better, the built in toolboxes have already solved huge (engineering) problem spaces. Code already written is better than code potentially written...
Unless you want a solution that is repeatable or more general than Matlab affords. At that point you'd be better off doing the math by hand. I feel that the Python et al and C solutions fit into this niche. Prototype the math in Matlab, implement in a language that doesn't suck.