Hard not to say "and nothing of value was lost." MathWorks is a curse especially once you've left university and all the tools you got used to are no longer free.
That said, I still regret not realizing how useful matlab would have been in undergrad, for avoiding wasting time on answers that looked wrong but were not actually meant to cancel out perfectly. Or helping me track down a stray sign change. But this was over twenty years ago, and I’m sure I could find good enough alternatives today.
Course, I’d still probably ignore them as well if I was an undergrad today, because I’m stubborn and prefer to suffer in weird ways...
> Course, I’d still probably ignore them as well if I was an undergrad today, because I’m stubborn and prefer to suffer in weird ways...
I'm surprised--I remember the HP-28 coming out--those things went through engineering undergrads like WILDFIRE.
Mathematica came out about 2 years later--I can't tell you how much I abused that.
Matlab, on the other hand, just never seemed to be useful. If I needed statistics, there were better programs. If I wanted graphing, there were better programs. If I needed to do signal processing work, I was better off writing the algorithm program myself so I understood what its limitations and bottlenecks were.
The only time Matlab seemed useful to me was in modeling RF signal chains.
Today, numpy and scipy in my opinion provide a serious alternative to matlab that's free both in terms of beer and speech, so it's hard to argue for matlab beyond familiarity's sake.
I used MATLAB for 15 years. It had and still has a great IDE, and Simulink is great for control systems experiments. Licensing cost is a perennial issue, but educational institutions get such steep discounts that it's usually not an consideration in academia.
The language is easy to teach and is mostly based on matrix operations. It's great for writing simple functions/subroutines. It's essentially a simplified version of Fortran.
However, it is not a great language for organizing code. The object model is poorly designed and tacked on, to the point that almost no one uses it. Function notation is antiquated -- no support for simple things like optional arguments or default argument values, so you had mess around with magic variables called `varargin` and `nargin`. Matrices and cell arrays are the central data structures, and while these worked great for linear algebra, they are terrible for anything that required a true tabular multitype data structure, i.e. a Dataframe.
It wasn't until only a few years ago that the Table data structure entered the picture (the Statistics Toolbox had a Dataset data structure previously, which was a simplified Table, now deprecated), but by then a lot of very messy code based on cell-arrays had been written. Cell arrays are a terrible hack and easily one of the most inconsistent array types I've ever seen. (the slicing notation gave you unintuitive results depending on how you wrote it)
And, to productionize MATLAB code, you had to buy a $5000 (back in the day) MATLAB "compiler" which packaged your code to be run by a Runtime. You could get around this by running your MATLAB IDE in headless mode on the server, but it's heavy and you'd be consuming one MATLAB license per program.
For many years in the late 2000s, numpy/scipy were still immature and we couldn't move off Matlab, but about 10 years ago, numpy/scipy and pandas became sufficiently mature that we could transition off MATLAB and so we did. Suddenly our code, performance, deployment process, and interop with other parts of the system got a lot better -- just by moving off MATLAB to a real language like Python.
I don't be begrudge people who still use Matlab for research work. But my experience is that it's not the platform you want to be on when you need to productionize your code. Python is just a lot better. Or Julia -- whose syntax looks like it's partly inspired by Matlab (there's a striking similarity down to 1-based indexing), though without any of Matlab's inherent language design weaknesses or deployment difficulties.
Small tidbit, I'm guessing it might more likely be the case that Julia is inspired by Fortran, and Fortran inspired matlab, not the other way around.
That said, as someone who used python (got my phd just a few years ago so I'm younger) while the rest of my cohort used matlab because their professors used it, I am happy now that I never have to worry about licensing or running things on my own PC, and yes, it's an actual programming language and an actual platform for development so, it's definitely easier for me now that I'm actually working. Also, thankfully scipy gives me a .mat reader so I still can send and receive data from colleagues.
I believe you're right -- I'm misremembering from the early days when Julia came out and folks on various forums were remarking how similar its syntax was to Matlab, likening it to a faster compiled Matlab.
7 comments
[ 2.9 ms ] story [ 25.1 ms ] threadCourse, I’d still probably ignore them as well if I was an undergrad today, because I’m stubborn and prefer to suffer in weird ways...
I'm surprised--I remember the HP-28 coming out--those things went through engineering undergrads like WILDFIRE.
Mathematica came out about 2 years later--I can't tell you how much I abused that.
Matlab, on the other hand, just never seemed to be useful. If I needed statistics, there were better programs. If I wanted graphing, there were better programs. If I needed to do signal processing work, I was better off writing the algorithm program myself so I understood what its limitations and bottlenecks were.
The only time Matlab seemed useful to me was in modeling RF signal chains.
The language is easy to teach and is mostly based on matrix operations. It's great for writing simple functions/subroutines. It's essentially a simplified version of Fortran.
However, it is not a great language for organizing code. The object model is poorly designed and tacked on, to the point that almost no one uses it. Function notation is antiquated -- no support for simple things like optional arguments or default argument values, so you had mess around with magic variables called `varargin` and `nargin`. Matrices and cell arrays are the central data structures, and while these worked great for linear algebra, they are terrible for anything that required a true tabular multitype data structure, i.e. a Dataframe.
It wasn't until only a few years ago that the Table data structure entered the picture (the Statistics Toolbox had a Dataset data structure previously, which was a simplified Table, now deprecated), but by then a lot of very messy code based on cell-arrays had been written. Cell arrays are a terrible hack and easily one of the most inconsistent array types I've ever seen. (the slicing notation gave you unintuitive results depending on how you wrote it)
And, to productionize MATLAB code, you had to buy a $5000 (back in the day) MATLAB "compiler" which packaged your code to be run by a Runtime. You could get around this by running your MATLAB IDE in headless mode on the server, but it's heavy and you'd be consuming one MATLAB license per program.
For many years in the late 2000s, numpy/scipy were still immature and we couldn't move off Matlab, but about 10 years ago, numpy/scipy and pandas became sufficiently mature that we could transition off MATLAB and so we did. Suddenly our code, performance, deployment process, and interop with other parts of the system got a lot better -- just by moving off MATLAB to a real language like Python.
I don't be begrudge people who still use Matlab for research work. But my experience is that it's not the platform you want to be on when you need to productionize your code. Python is just a lot better. Or Julia -- whose syntax looks like it's partly inspired by Matlab (there's a striking similarity down to 1-based indexing), though without any of Matlab's inherent language design weaknesses or deployment difficulties.
That said, as someone who used python (got my phd just a few years ago so I'm younger) while the rest of my cohort used matlab because their professors used it, I am happy now that I never have to worry about licensing or running things on my own PC, and yes, it's an actual programming language and an actual platform for development so, it's definitely easier for me now that I'm actually working. Also, thankfully scipy gives me a .mat reader so I still can send and receive data from colleagues.