Hacker News new | ask | show | jobs
by wyager 3852 days ago
> Matlab will always have its proponents

I honestly can't understand why. I'm currently in a computer vision class that uses Matlab, and it's literally the worst language I've ever used in my life. The design is nonsensical, bordering on malicious

I've always thought that the biggest problem with python was that as programs get bigger, you're likely to run into some confusion due to the lack of static typing and substantial use of implicit conversion (e.g. "Truthy" and "falsy" values), but python has nothing at all on Matlab.

Just last night, a matrix I constructed using the expression "[x, y, (x+scale), (y+scale)]" inexplicably had dimensions 1x8 instead of the visually obvious 1x4, but only after a few hours of matlab slowly evaluating this expression thousands of times without any trouble. I suspect this has something to do with matlab's horrible ambiguous matrix concatenation syntax.

5 comments

> I honestly can't understand why

The answer is fairly obvious though, isn't it? For scientists or novice programmers wanting to do some numerically intensive work, Matlab has typically offered one of the quickest (in time-to-solution) prototyping platforms. One of the keys being that you can get started very quickly, with minimal setup (besides the expensive license and installation, something most academics need not worry about). As a former academic programmer and now a consultant that helps companies commercialize such prototypes, I understand your pain, but at the same time I completely understand why a physicist, imaging scientist, or finance major ends up using Matlab over something like C++ or Python. Same goes for LabView, and if you despise Matlab, I challenge you to give LabView a whirl. The gap between the Matlabs and Labviews of the world and the other programming languages is closing in terms of ease of use and setup time, but we're not there yet and also momentum shifts on this type of thing take a loooong time. If you come into a lab and are working on a research project that was started in Matlab, odds are, in the interest of finishing your thesis on time, you're unlikely to port it to another language, even if you have the skill to do so.

If you single-handedly list Python and C++ together, Matlab should have some ridiculously low entry barrier. I can remember a few other horrible tools that saw widespread use exactly because of that, e.g. Basic and PHP3/4.

Corollary: if you are offered a tool highly praised for its being exceptionally easy for beginners, think about the price the tool had to pay in other departments, and how will it affect you in 6-12 months of use.

> If you single-handedly list Python and C++ together, Matlab should have some ridiculously low entry barrier.

The ridiculously low entry barrier exists wrt importing data and plotting/displaying results.

These are the same case-uses as Excel and Access, and these also end up bloating in size and becoming unmanageable. The problem is that the selection criteria that lead to using Matlab in the first place also lead to never paying down technical debt.
Libraries. Inertia. The IDE is actually far more polished than Spyder. It makes things easier for non-programmers with many wizards, and excellent help files. The toolboxes are uniformly fairly high quality. I should mention again the help files. Matlab documentation is comprehensive and far better than any of its competitors.

There are many research institutions and workplaces where the cost of the tool isn't really thought about at all. In fact, the cost of Matlab and toolbox fees is a small fraction of a senior scientist/engineer's total compensation.

The main competitor is Python. However, using a general purpose programming language is often too hard for non-programming oriented scientists. They are not able to compile a Python package on Windows, never mind actually package and distribute their work to colleagues. On Windows, if the package isn't in one of the distributions like Anaconda, it may as well not exist.

> The main competitor is Python

I would say that it really is R. Python while a good choice is a fraction of the size of R and R as a domain specific language excels in its own realm.

Using R with RStudio and sticking with Hadley Wickham universe with Functional Programming makes R shine. There is a reason why so many companies invest in R.

I think your perspective is too small. R is a DSL for data and statistics. Matlab is used in academia and industry across all engineering disciplines, where data and statistics is but a small subset of its total capabilities.

You will never be able to use R to model a Kalman filter, calculate stresses in a beam, or simulate engine control logic.

I refer you to Matlab's toolbox list. http://www.mathworks.com/products/

You can do all of those things in R except maybe Simulink with a GUI (at least not yet, maybe soon?), and you have the choice of working with multiple implementations. https://cran.r-project.org/web/packages/FKF/FKF.pdf https://stat.ethz.ch/R-manual/R-devel/library/stats/html/Kal... http://stackoverflow.com/questions/1738087/what-can-matlab-d... Unless you are doing something very specific and require a specific toolbox only for Matlab, you're better off just using R (or Python).
I can't disagree more with a blanket statement like that. I would never recommend Python / R to the physicists and scientists that I work with. They don't know how to program well. The code they put out is usually garbage, hard to read, and fragile. Software development is not something they do. Backing up for them is emailing themselves a .zip file of their work and revision control is saving their DocXs and PPTs with different dates in the filename.

My point is, coding is not something they enjoy, or care about, it's just a means to an end. The environment and tooling around R/Python still cannot compare to Matlab in terms of ease of use, for the things that Mathworks (creators of Matlab) care enough about to write a toolbox or gui wizard for. The value is not in the language, or syntax, but in the libraries and tooling. I don't know a single Matlab user who doesn't make heavy use of the toolboxes Matlab sells.

And this is why I believe Matlab is not going to go away. If being free and flexible was all that mattered, Linux would have arrived on the desktop already.

After having worked with enough academicians, the code that I had to deal with was too agonizingly crufty for me to deal with that it made a huge influence over my decision to away from academia (and my subsequent drop in grades in school). I figured that if I had enough problems just dealing with the code, I couldn't imagine having to trudge through everything else that led up to that code. But it shattered my preconceived image of academicians being curious about everything and having a great deal of care and pride in the tooling they use - that I should look to them as reference rather than a bunch of people that dropped out of school for a quick buck, and that simply wasn't true whatsoever.

Matlab is going to be the COBOL of academia without some major groundbreaking research that invalidates or supersedes a great deal of research code, and given the community-consensus nature of so much research done I can't imagine quite something so disruptive happening.

If journals ever demand code that reviewers can read (as they should IMO; who knows whether hard to read garbage is actually doing what they claim it is in the methods section, and the call for reproducibility in science is getting stronger), then academics might be forced to learn to code. And then they might want to use a programming language that's more conducive to readable code.

I don't think MATLAB toolboxes are a huge obstacle. Maybe something like the Aerospace Toolbox is useful for people in aerospace. But for people in my field (neuroscience), people end up writing their own code for their various applications anyway, because the MATLAB toolboxes are too slow or too inflexible for their use cases. The source of inertia is that everyone uses MATLAB, so they end up writing the code in MATLAB. While it takes time to overcome an established userbase, I think it will happen eventually if the alternatives have substantial technical advantages, as I believe Julia does. It only takes a handful of technically skilled people to reproduce the majority of the code in common use, and if there are good reasons for those people to write that code in Julia and for others to use that Julia code, then Julia will eventually take over.

Open Source always wins in the end. Matlab is not a good solution due to its closed propitiatory nature and the need for science to be shared. We see the cracks in the walls on Journals and Research behind closed walls. The code and the tools for science also needs to be free from a closed system.
Sorry you are wrong especially about your first example. For the other two yes there aren't built in toolboxes to handle those but it can be done. R has a lot of packages + it's a language so anyone can effectively write anything: https://cran.r-project.org/web/views/
I can write anything to do any computation in any programming language. The whole point is that there are pre-existing, high quality libraries and toolboxes to do these operations. In fact, that is exactly why R is popular - it has excellent libraries for handling data and statistics.

You're right. R does in fact have a library for modeling Kalman filters. My mistake! Let me pick any other example from the Matlab toolbox product list that R doesn't have! Can you model a radar system in R? Can you tune PID systems in R interactively? Don't be a pedant. Since you are familiar with R, you should know R is 95% used by data scientists and others involved in statistical work.

"There are many research institutions and workplaces where the cost of the tool isn't really thought about at all. In fact, the cost of Matlab and toolbox fees is a small fraction of a senior scientist/engineer's total compensation."

Yeah that's my experience with my current job. Matlab licenses aren't an issue. Also many people have Bloomberg terminals and other expensive tools of that trade that make Matlab look fairly cheap in comparison.

For a language to beat out Matlab it will need to be based on other factors than cost. Most likely performance, documentation, training, tooling and be popular within the pool of candidates for jobs. Hopefully Julia can get there.

> For a language to beat out Matlab it will need to be based on other factors than cost.

There are plenty of cases in which Matlab's cost is a big factor. Maybe not at your company, but some of Octave's most ardent paying customers have been those disgruntled with Matlab's price tag.

if scale is a vector say [1, 2, 3] then x+scale = [1+x, 2+x, 3+x], and in Matlab [ [1,2,3], 4] = [1, 2, 3, 4].

I agree with all you said mind you, and could rant even more about Matlab, just giving a possible explanation for how Matlab parses the expression.

Why? Because professors keep assigning students problems with it, immune to its high cost and suspect coding idioms because they aren't professional programmers.
As (potentially) one of those professors, I'm going to suggest that if you're posting on HN, you have no idea how little computer experience some of the Econ, engineering, etc. students have. Matlab and other programs like it try hard to smooth over some of the rough edges that can trip up complete novices. As long as the main focus of the class is teaching "something other than programming" that's going to be pretty attractive.
I was one of those clueless engineering undergrads back in ancient times...I know the mentality of thinking since you know BASIC and can code up a brutally ugly solution in MATLAB that you know programming, as long as the right number is spit out on the command line. I also know, in my old age, that if the purpose of an engineering education is is about building higher order structures that can communicate intent and be extensible artifacts, that this is not acceptable. We need to put in place tools and methodologies that enforce good practice with code in the same way that we enforce good spelling, grammar, sentence, and paragraph structure in language, from the beginning.
I agree with you, but that's not a decision that can be made unilaterally by professors at the course level without sacrificing _a lot_ of the other content.

You're going to cry if you see the current standards of undergraduate spelling, grammar, and sentence structure, btw. :)

Touche, Prof. Carry on. ;)
It works well enough and there's an incredible amount of infrastructure behind it. It's an academic's job to produce research, not code.
That was the advice I got from my advisor as a grad student. 15 years later, I disagree strongly. I wasted a lot of time writing code that I couldn't read later, that took forever to get right, and that couldn't be reused. I've made a significant investment in programming tools and it has been worth it. Git alone has probably made me twice as productive.

The logic you state (which is dominant) is wrong. Optimizing the speed of writing the first version of a particular piece of code is a bad idea.

* Don't unreliable tools impede research?

* Isn't it a good idea to publish code used to produce the results so as to help fellow scientists verify the results and methods?

1. Who said matlab was unreliable? (There's a difference between "reliable" and "good")

2. Matlab code gets published all the time.

3. Just because it's not matlab doesn't mean that it's, for example, in a state others can use. See for example: http://reproducibility.cs.arizona.edu/v2/index.html (which isn't perfect, but it's something)