A bit offf topic, but is Matlab relevant still? I’ve heard it’s still in use a lot, but what’s the benefit of going with a walled off proprietary $$$ tool when you can use something like this? Python and R also seem like they’re growing so much and are very open.
I just remember taking a class on Matlab and being pretty disappointed in it with how closed it felt. Will totally check out octave tho!
Yes, in traditional industries. Robotics, automotive, industrial automation, and aerospace are using it.
From my experience in automotive, Matlab alone is not the sole selling point, but the proprietary tooling around Matlab for modelling, hardware-in-the-loop simulation and online calibration for various ECUs is unbeatable and saves the OEMs and manufacturers weeks or months of labor and debugging various platforms. And since it's the industry standard all automotive companies use it to collaborate on projects.
There's also the important fact that many users of these tools are not programmers. They could be mathematicians, physicists, chemists, designers, process engineers, test engineers, test drivers, test pilots, etc. and the GUI block-diagram based visual programing paradigm of Matlab tooling allows them to quickly understand, collaborate and iterate on various control schemes that learning how to code. If you're a test pilot or a process engineer, it's much easier to look at a Simulink block diagram and quickly understand the process going on, than to start reading python code.
There are no open source tools that can do all these things and nor is there a market for them as these companies don't mind sticking with Mathworks & Co. and paying them juicy license fees in exchange for getting the user-friendly tools they want that enables them to get the job done.
The network effect is also too strong to disrupt. Every company in the Michigan area serving the auto industry is running Matlab and so is every company in Stuttgart and Bavaria as most big OEMs have international offices in all these regions which must collaborate together. I assume it's similar in aerospace with the likes of Lockheed, Airbus, Rolls-Royce and many other of their suppliers are also deeply entrenched in the Mathworks ecosystem.
Basically entire industries, that don't get much air-time on the start-up focuesd HN, have standardized on Matlab. In a way, it's similar to the semiconductor industry that standardized exclusively on the tools from Synopys, Mentor Graphics and Cadence. Or how how the CAD industry is run by Autodesk, Siemens and Dassault. None of these players will be disrupted by open source alternatives any time soon. Or ever.
The two big reasons are simulink and the availability of extremely domain-specific modules.
Simulink is a graphical modeling lanaguage for developing/simulating closed-loop control systems among other things. Flight controls people build aircraft controls in simulink and then the software engineers take it and use it to generate code that can be integrated into the rest of the flight software.
Then Mathworks builds and maintains a specific tool box for every niche engineering domain under the Sun. Need a set of simulink blocks and/or matlab functions for simulating phased-array radar systems? Mathworks has you covered, for an expensive license fee.
Both these things, IMO are ripe for replacement by open-sourced Python-based modules that do the same things, but it would take the right people with the right domain knowledge to have the incentive to do the work.
Julia would probably be a better solution for this use case.
The problem isn't performance, it's that matlab is a single click install of everything and an ide that takes care of everything for you. By comparison, managing a python environment is a nightmare.
"Know your users". Something is preventing them from considering those alternatives as replacements.
Some people in teaching roles will even further Matlab's spread irresponsibly out of not wanting to learn a new tool. I have seen this myself. A professor showed the students Matlab, instead of using non-proprietary alternatives. He also did not seem interested in learning about anything else, when I used Python + Numpy instead and showed him.
That's what confuses software engineers about Matlab. They see code and think that the work is software engineering, but that's not always the case.
Imagine the reverse scenario. The professor sees you crunching numbers in Python and tries to convince you to switch to Matlab because it's "better". But you're a software engineer, and you still have to do all your software things that Matlab isn't great for. Why would you be interested in it?
Of course you're right in this comment. Just because something exists doesn't mean people will know about it or trust it. Relationships, support, marketing etc that businesses provide go a long way to helping adoption.
Btw, I don't think obscurity is a significant factor.
Python installation is a headache in a classroom setting. Matlab provides an official installer that guarantees that every kid in the class has a working installation and the same user environment by the time the lesson starts.
It seems like Python and R have taken up residence in fields that had no prior loyalty to Matlab, such as biology.
What I've noticed is that where new graduates used to list Matlab on their resumes, now they list Python. In both cases, whether they can actually do anything useful with it or not. Many of those people didn't actually learn to program. Depending on what courses they took, exposure to Matlab or Python may have consisted of pasting some code written by the TA and running it. Students are not unaware that Python is associated with the job market for programmers -- a career "Plan B" that many are considering. At the same time, if someone can program in Matlab, they can learn Python in a jiffy, or vice versa, so it's not a life-or-death choice.
Whether they actually want to use Matlab or Python in their jobs probably depends on what industry they're in, and their interests. None of the traditional engineers in my workplace (mechanical, electrical) do any programming to speak of. Their CAD software does the engineering calculations that they need. For basic data manipulation, including graphing, they're happy with Excel.
My day-to-day stack nowadays is mostly Python with a smattering of others, but I’ve been using MATLAB for almost 15 years.
Like any other enterprise software, you’re paying for support and generally very good documentation. If you have a technical issue or even just a development question you get a response from a human within a day or two, often just a few hours.
There are also many domain-specific tools (e.g. Simulink) that do not have similarly functional open alternatives. Octave is great, but can lag behind new language features and generally isn’t 100% cross compatible. Whether or not this affects you is really dependent on your use case.
It's interesting how close GNU Radio Companion is getting to Simulink's domain. I don't know if that's their plan or if things are just evolving that way, but I like it.
If your company can afford it, and if it has good toolboxes for your field, MATLAB is a solid tool. Its plotting capabilities are the gold standard for a large portion of science--python's matplotlib and similar plotting libraries in other languages are in large part based on MATLAB's plotting experience. Others in this thread have mentioned Simulink, which is also top of the line for control theory analysis.
I think an underappreciated capability of MATLAB is its C/C++ code generation, which is quite good. It'll transpile MATLAB source code (with some minimal type annotations) into C/C++ source code that you can take wherever you want.
Having said all that, it still has plenty of flaws including its price tag. One field where I get the sense that it lags is AI/ML--I have never seen a paper introducing a groundbreaking result that uses MATLAB's ML toolboxes.
I prefer Julia / Python / C++ for my own work, but will still reach for MATLAB every once in a while.
I think Python is superior, but perceived as difficult for non programmers.
A lot of programmer work is general purpose, create something new in a novel way.
A lot of non-programmer work is highly specialized, tailoring a solution for a specific use case out of existent but adapted parts.
For the latter, it can make a lot of sense to work within a mature ecosystem, where most of the components are already available, even if you sacrifice flexibility when you need to go out of bounds.
And also you adapt your workflow and designs to the tool, not vice versus.
There isn't anything else on the market I know of that comes close.
> "Yea some of the new PhDs try it out until they find out how awful it is!"
I clutched my pearls, aghast, and asked him why he thought Python was awful? He said that the community supported tools have problems, but the toolboxes provided by MATLAB are high quality and just work. I told him that I thought he was misguided, that Python tools work quite well and that the Python community is a strength not a weakness, that when a tool doesn't work well it's an opportunity to contribute.
He listened politely, but wasn't convinced.
My aversion to Python is a personal bias. It is an easy language to pick up and has won its place. I just don't like it. I was using Lush back in the day (Yann LeCun was one of the creators), and I wish it had won over Python due to my Lisp predilection [1]. It is a Lisp-like syntax that compiles to C.
At 14:00, the interactive slider exploration due to the speed is amazing. Over 500 Monte Carlo simulations in less than 60ms.
He listened, but he probably doesn't care.
He uses whatever software helps him gets his job done and that's it. Software developers and enthusiats in general usually care about free software, other people not so much.
And also we can't pretend that free sotware projects like octave are not playing catch up with its commercial counterparts, it's not like hundreds of paid developers and billions of dollars getting thrown at the development of new features don't make any difference.
(Double checked your username, seems we've discussed the Matlab/Python space before!)
That's like trying to convince someone to buy a fairphone and telling them that if the phone is lacking in some area, they can contribute to the design. Maybe you believe in the message and you're willing to make sacrifice, But if you're a math postdoc whose immediate concern is getting a tenured job before time is up, you just use what's easy and works, because you've got other stuff on your plate that is much closer to your expertise (developing new mathematical knowledge).
We do need a better story with dependencies in Python, and I'm happy to see there have been several posts over the last week talking about this issue.
That said I think that for academic projects it can be fairly straightforward to handle after an initial learning curve. A lot of projects can be accomplished with just numpy/scipy/matplotlib and maybe a couple other specialty libraries.
Take a look at this for example https://www.mathworks.com/matlabcentral/fileexchange/49683-l...
As many others have pointed out, Matlab is not only relevant, but thriving in many fields. It's a great package and is deeply embedded into the engineering world.
I won't repeat points others have made, but here are a few of my observations:
* Matlab is a great language for domain specialists -- non-programmers who want to solve technical problems. There is almost no barrier to entry to Matlab for such users -- you just start using it at the command line. Python and Julia assume the user is a programmer -- you need to worry about variable types, quirky syntax, finding and importing the right libraries, etc.
* Julia started out as a next step beyond Matlab for numeric computation. It was relatively easy to use at the beginning. However, the language has now grown and generalized to the point where I find that it has become as difficult to use as C++. For example, error messages thrown by Julia can be multiple screens long and are as hard to read as C++ errors. And getting types right is a pain. Here's the Julia manpage discussing all the types you need to worry about when writing Julia programs:
https://docs.julialang.org/en/v1/manual/types/
Maybe hard-core programmers love the available abstractions, but this level of complexity is a real turn-off for domain specialists who just need to crunch some numbers.
* Matlab is highly performant. The Mathworks implemented a JIT some years ago which largely mitigated the need to write (tortured) vectorized code. On the other hand, "for" loops in Octave are still dog-slow since it's interpreted on a line-by-line basis.
* Matlab has tons of toolboxes implementing advanced functionality. The toolboxes are widely used in industry. Octave mostly lacks this toolbox ecosystem.
* As others have mentioned, Simulink provides a graphical tool used almost everywere to design control systems. The control systems guys at my workplace use it. There is also an open-source alternative to Matlab/Simulink, Scilab/Xcos, which was originally written at a French university but is now owned by Dessault:
Unfortunately, I have never seen anybody on this side of the Atlantic Ocean use Xcos for anything, but I see Simulink all over the place.
* Finally, I'll point out that the Mathworks remains very innovative and continues to invest in their products. Their stuff is improving in quality and extending into new domains. I agree Matlab's price tag is steep for individual users, but for companies the price is a drop in the bucket, and the Mathworks puts its revenues to good use. I can think of many other software companies who charge far more for their stuff, but simply collect their revenues and leave their products to stagnate. The Mathworks is a good model of what a commercial software company should be.
For those who can't pay for Matlab, Octave and Scilab are both good enough for home use.
The good news is this can be fixed by using AbreviatedStackTraces.jl, which will probably be added to the base language in the next update (1.10).
> And getting types right is a pain. Julia's types are almost identical to Python's. Julia is dynamically-typed, with optional type annotations. You don't have to touch types, ever, if you don't want to. I never worry about types when I write Julia programs.