Yes, Matlab has very good compatibility, I think. Been using Matlab for 25+ years, and whatever breaking changes they have introduced have been simple to fix. The automatic “kronecker-thingy” was probably the scariest. So I don’t get some of the Matlab “bashing”.
Mex-ing bottleneck functions has been trivial, and once in a while some rudimentary C coding has been necessary. I also like the simple and accessible plotting, profiling, and debugging functionality, particularly when sharing code with coworkers–all will know and use the same basic tools. And lately, for-loops have become significantly faster and sometimes even besting vectorized calls.
But, over time, likely for efficiency reasons, function after function (in core Matlab) has been converted from Matlab code to compiled code, which means that I have no way of (1) checking the behavior or (2) being inspired by the Mathworks programmers (since the source code is proprietary). Furthermore, a number of Matlab bugs (e.g. sort with complex numbers and bsxfun+and+sparse) have generated hard-to-detect errors where people have spent significant time trying to debug their own algorithms only to find out it’s a Matlab issue. This has typically meant that we have had to waste time coding around the bug while waiting for the next release. I suspect (know) such issues are dealt with much faster in Julia. And, yes, often the speed of execution is slow…
So, going forward, I look more and more to Julia as the tool to solve our problems. And it’s very encouraging to see the debugger development; this certainly removes one “but, it doesn’t support” argument.
I think too that universities are a good place to introduce people to Julia. But there is a lot of old code base lying around, that absolutely no one wants to touch. That is the main reason why I learned Fortran and even had to go through the pain of Fortran70.
I understand that this happens, but it is somewhat disturbing from a scientific reproducibility perspective, because this means that even with the source code available, the functionality is effectively a black box because understanding and modifying it is prohibitively costly.
We can’t review and understand every piece of code we use, but ideally there should be at least a small number of people who do it from time to time.
Improving the bad old code base and creating new algorithms which are faster and more generic is precisely the research activity of a lot of Julians though!
Julia, and any open source tools, are “free” only if your time is free. I did my PhD in a SAS-centric instituions, all computers had it, license was free for students, and code just moved between professors and students. I like FOSS, and I already had some knowledge of R and went against the current, but I know I would have saved some time if I’d just used SAS like 99% of campus. Same applies with any OSS, there’s no money cost upfront, but there’s certainly a time cost that can be even higher.
I agree with you that this is not ideal, but for me we are now entering politics, because in my country basically all basic research within academia is done by phd-students/postdocs who are on fixed-term contracts. These contracts are around 3 years, and from my perspective there is not enough time to overhaul huge code bases even if you wanted to and do meaningful research on the side (“publish or perish”…).
That sounds awesome! I was told that I should focus on getting my research done, instead of modernizing old Fortran70 code (that often is quite fast, which does not make it easier to make a case for modernization).
This mostly depends on whether you are using something that is very standard and already packaged in software, or need to write code to implement new methods/algorithms, or just something custom.
I don’t necessarily disagree with your summary though — you can save a lot of time by not straying from the beaten path. But I think this is a dangerous mindset in general, and especially in research, as it can lead people to choose some method not because it is ideal, but because it is available.
That said, if someone is working with methods for which there is existing software available and it serves all of their requirements, they are obviously not the target audience for Julia at this moment. This is fine, and it should be just acknowledged.
I think the reason MATLAB isn’t threaten yet by Julia (And to some degree Python) is that they don’t hurts its main selling strengths.
MATLAB strengths are:
Easiest Language Around
You can open any code (Not Object Oriented) and just learn.
I could do this on my first days with MATLAB. Yet on Julia I can’t understand most of the code.
I think it is because Julia code is written by people with high programming capabilities while MATLAB community is all about the concept of the program.
Fastest Out of the Box Linear Algebra Speed
MATLAB utilizes Intel MKL out of the box. It is still faster than anything out there which uses OpenBLAS for pure Linear Algebra. I think the gap is even wider on AVX 512 enabled machines.
Great Development Workflow / Experience
Beside Visual Studio, nothing gets close to the great development experience I have with MATLAB (Opinion shared with most of the Engineers I know). Writing code, Debugging, Plotting, Toolboxes, etc…
Documentation and Easy to Access Code
Since there are so many algorithms implemented in MATLAB and the simplicity of the language it means it can be a tool to learning new things. MATLAB documentation is really great. You can literally work with MATLA with no Internet connection.
Focused Language
MATLAB is for people doing scientific programming. It is focused on that. It means Language design choices are clear - As close as possible to Algorithm Pseudo Code. No need to design, polish and move towards features for general programming.
Yes, it has many weaknesses as well, which many of them Julia targets. Yet those weaknesses are being targeted with each iteration of MATLAB (Loops are getting faster and faster with the new engine). The real down side is that large parts of the internal code is rewritten in C / C++ and is hidden from the user. I wish they didn’t do that, but they do.
So I think teams on many projects which MATLAB is a phase in development (Prototyping, Proof of Concept, etc…) still find it to be the best tool around for that.
Debugging, plotting, yes, etc. But not writing code. The Matlab code editor is pretty primitive when it comes to the pure text editing experience, aeons behind modern editors like sublimetext, atom and vscode, and I guess, vim/emacs too.
Honestly, it’s almost staggering how little progress has been made to text editing in Matlab.
You’re still stuck with singular dispatch (OOP) or no dispatch at all for regular functions. No optional arguments or keyword arguments (except by hacking around with nargin, varargin and strings–well, I guess you have the inputParser class, but that’s an awkward solution to a simple problem), no way of indexing into an expression (e.g. sum(MyMatrix)(2)).
My code is full of input parsing and branches (“if first argument is a number, then if second argument is string, then if nargin < 4, …” etc. ad nauseam.) No vectors, only matrices. Oh, and even though Matlab is ostensibly column major, it still returns row vectors (1xN matrices actually) all over the place.
There’s a thousand little ways that Matlab are behind in making it easy to work with. Julia is more advanced, yes, but it’s also far more ergonomic. Once you learn the basics it’s really easier, the code is clean and simple, far simpler then my Matlab spaghetti code.
I agree with your assessment, just want to add that if someone has no experience with dynamic dispatch, they will never miss it. Same applies to other elegant and advanced features. The majority of scientists (and programmers) are content to write spaghetti code for all their career.
Yes, I didn’t exactly miss multiple dispatch. But I have spent many agonizing hours (still do) designing functions that could handle varying inputs. I certainly missed something better. And I knew about Python’s optional and keyword args, and very much missed that.
This is probably underrated around here since so many devs here just think “why not build it with XYZ?”, when in reality, the pre-built binaries are Julia to most people. MKL.jl is a great advance in this area, but it still needs more development, along with JuliaBLAS. But for a lot of people, A\b being faster in MATLAB for large matrices “right out of the box” is something that is appealing to someone who doesn’t know what a BLAS is.
This opinion is only shared with engineers until you go parallel. MATLAB’s tools for debugging, plotting, etc. when parallel computing is involved is horrific. Plus you need one license for every core you want to use unless you make binaries, so you have clusters asking for $100k from grant money if you want to do any parallel analysis interactively. Remote execution is lacking too. With Juno and RStudio you can get execution happen remotely in just a few minutes, whereas MATLAB still needs to forward X windows and all of that jazz. I think the interaction with parallelism, remote work, cloud computing, etc. is where MATLAB is really starting to fall behind.
And as @DNF states, the text editor part is pretty bad. How do you do column selection in MATLAB? You open a non-MATLAB text editor like Atom to edit your code, then re-open it in MATLAB . But the tooling integration is quite good. The profiler, debugger, and data editor windows are especially good and parts to strive for. Their linting isn’t all that bad either.
Let’s be honest though, most of the toolboxes are pretty abysmal. A lot of them, like the GPU computing parts, were better (and faster) before MATLAB acquired them and snuffed out competitors (who were selling MATLAB toolboxes!). Global optimization, machine learning, etc. are all pretty bad. There are some good parts though, especially Simulink and system identification, which are hard to find elsewhere.
Matlab has some serious limitations in its type system and performance, i.e. subarrays copy, no pointer types (actually, it is possible to do pointer type by wrapping variable into a class deriving from handles). By the way, after some time coding in Julia, I’ve started to hate Matlab-style curly braces for cell array indexing.
Also, they have quite old GUI designer and are slowly moving to their new App designer, but it is strange - a single file with packed GUI markup + source code with some text parts blocked from editing (at least, less boilerplate with GUI data handles - just a single class with methods).
But Matlab JIT compilation is very helpfull - you can always edit some callback functions and watch how they change their behaviour on the fly with no recompilation.
Oh yeah, that was one of the big things I should have mentioned, that you cannot have general arrays of things, but instead need to dump things into a ‘cell array’, with non-standard indexing. Arrays of strings are a very recent (and welcome) addition, but since old-fashioned strings-as-matrices-of-chars are still the norm, they are quite hard to find use for.
I’m dumping on Matlab, which is perhaps not good etiquette, but as a 20-year user of Matlab, and now for many years a holder and payer of a business license, I feel entitled to. Matlab has good qualities too, as listed by @RoyiAvital, but I think he went overboard and complimented Matlab on too many fronts, so I had to vent
!!
. But the tooling integration is quite good. The profiler, debugger, and data editor windows are especially good and parts to strive for. Their linting isn’t all that bad either.