The thing with Matlab is that, just as software, it's "great-terrible". It has an amazing number of cool little tweaks that allow quick development and it has umpteen convenient algorithms and allows one to work with matrices in a very self-contained way.

But all this niceness means really that the software is more in the realm of spreadsheets than standard programming languages. Maintenance is guaranteed to be a nightmare and conversion to an actual programming language similarly.

The problem is that there can't be any small way to get off the beast. Because Matlab isn't a language but a rag-bag of features, nothing can be compatible with it. Indeed, you could be 100% compatible today and wake up incompatible tomorrow. It's position is like that of the monster desktop applications like Excel, Adobe Creative Suit and other nightmare abominations.

"You may think you're being productive but really, you are just feeling a rush from the grade cocaine of technical dept"

I have to use Matlab professionally in my organization for financial risk modelling and there are some larger legacy codebases. However, I wouldn't share your opinion about maintenance issues. Like with every other language, if the code is well organized, everything is fine.

Matlab integrates with SVN or GIT, you have got the functionality for unit-testing, proper debugging and profiling and namespaces through packages. OOP works also well although you will pay for it in performance. Additionally, you can easily use Java packages and interface with .NET and COM.

Compared to how R is used here, the whole Matlab environment feels much more complete and solid prototyping is certainly an advantage. Nevertheless, we feel the pain when it comes to datasets of 10-100 GB for which we don't want to set up a database. We haven't bought the Parallel toolbox and without this, processing is just very slow. Here R shines with e.g. data.table.

If I would rewrite the applications, I would however not do it in Matlab, because the audience of people looking at the code is more familiar with open source alternatives.

This is more or less my experience in bioinformatics, computer vision, and machine learning. MATLAB is much better than people without MATLAB experience believe. It’s also much worse than people with _only_ MATLAB experience believe. From a robust package perspective, MATLAB is probably more complete than non-statistical R, but in recent years it’s lagged far behind the scientific Python ecosystem. It’s difficult to imagine it catching up to an alternative that’s free and better (from a completeness, performance, or user experience perspective).

I cringe every time that some engineering friend mentions how they has been programming an application with MATLAB. And next time the problem arises this "application" is not applicable anymore. Some manager types do not even realize that there's such a thing as technical debt.

In financial modeling, which is one of the primary applications of MATLAB, you generally throw away your code in 1-2 years anyway (unless it is a generic library that can exist for decades).

MATLAB is a tool for research, not engineering. In research, you check hypotheses; you write a lot of throwaway code. The 0.1% of validated models that end up in production can be rewritten in other languages, but nothing replaces the fast turnaround time of MATLAB. Or similarly organized R Studio.

I've been porting over a bunch of my old academic Matlab to Julia. It's obviously nowhere as close to Matlab syntax as Octave is, but it's a lot closer than Python. YMMV of course, but there are enough similarities that a decent proportion of my code has worked after pretty easy find/replace changes like switching array indexing from parentheses to square brackets. And I usually end up with something that runs about 2x faster than the original Matlab, which is always nice.

Totally. Julia (and NumPy) made a savvy decision adopting MATLAB semantics (and occssiaonally syntax) for many multi-dimensional array creation and manipulation operations. It usually takes me an afternoon or less to port complex methods written in MATLAB to NumPy.

The over dependence of academia on MATLAB when (atleast partial) FOSS solutions existed is what prompted the setup of the FOSSEE project in India https://fossee.in/.

They've been conducting several outreach programs to move academics and students off expensive and proprietary (and therefore often pirated) software to free alternatives (mostly around the Python ecosystem).

The project is quite successful from what I know.

I applaud such efforts, the entrenchment of MATLAB in engineering departments is hard to shake, we need more exposure on open source tools especially in academic conferences.

> It's very hard to recommend that students and colleagues grow invested in toolchains involving proprietary software that they may not reliably be able to afford/activate/use in the future, particularly when some students may end up working in developing nations.

The future is here. As a research student in a developed nation, it's very annoying to deal with MATLAB projects. Our lab has a fairly strict no-new-code-written-in-MATLAB policy. Getting a personal licence is fairly straightforward as a student (for now), but running it on a cluster, or anything beyond my personal computer is very annoying.

I know it’s not cheap but we have exactly one copy of MATLAB on our cluster to use their compiler and then run the compiled code on nodes without licenses.

I love that idea, and it seems like a reasonable way to slowly move a toolchain, provided that there are clean breaks to shift from MATLAB to the next step.

And cluster computing in MATLAB, I agree, is just that: a cluster.

What do you use instead though? Octave is very slow, Julia is even slower and Numpy has an annoyingly verbose syntax because it has to be valid Python.

Additionally I've not found a plotting solution that is as robust and fast as MATLAB.

MATLAB seems to me to be one of those commercial programs that has no good FOSS alternatives. Maybe it's just too niche, like CAD and EDA.

> Julia is even slower

Huh? This has definitely not been my experience -- most of the things I've ported over seem to run about twice as fast in Julia as in the original vectorized Matlab (and probably more like 10x faster than naive non-vectorized Matlab)..

Well written Julia should definitely be faster in most cases unless Matlab is using a specific well performing algorithm that Julia doesn't have built-in.

With that being said, there are a lot of Julia posts on the subreddit or stack overflow that go like "Why is this Julia code 10x slower than my Python code"? One issue is that getting good performance out of Julia isn't always obvious without a pretty good understanding of how it works. Thankfully, people are willing to help you tweak your code to make it much faster.

They should be similar if they both rely on standard LLVM optimizations. I assume both have their own optimization passes on some mid-level IR but I personally don’t know whether one or the other has any particular language features that dramatically improve performance over the other. I’d like to hear more!

I was just saying that getting really good performance out of LLVM with Julia isn't always obvious. This isn't just a Julia thing. People starting with Python + Numpy have issues with speed when they don't take advantage of the vector primitives and drop into regular Python loops for part of the code. First time Haskell users are frequently confused when it is significantly slower to parse text than Perl as one of the default string libraries is really slow and not recommended even though it is what a new user would think should be the first choice.

Overall I'm excited for Julia, but have a lot to learn. As far as Octave/Scilab type applications go, I find them useful for small systems where I need to make sure the math of what I'm doing is correct before writing it in something like Julia or Python + Numpy. Excel is also surprisingly good for the really simple stuff (Ex: inverting a small matrix and doing some matrix multiplications).

I assume they're referring to cases like this [1].

A few years ago I think there were some performance regressions in Julia relative to JIT'd Python (which, using LLVM like Julia, is way faster than normal Python). This seems to be mostly fixed now.

In the example above, the OP was getting 2ms in Numba vs 8ms in Julia three years ago, and recommendations from Julia folks were able to get the latter down to parity with an equivalent algorithm or 386us with an improved algorithm.

On my laptop today, I seem to get 2.0ms in Numba, 2.7ms with Julia 1.0, and 80us using the improved algorithm in Julia 1.0 (and, just to drive home the importance of compilation, 780ms in Python without Numba).

[1] https://old.reddit.com/r/Julia/comments/3x6tg9/why_is_this_l...

It may execute faster when it finally gets around to it. But just loading the plotting library (Gadfly) takes over 10 seconds!

https://github.com/JuliaLang/julia/issues/4373

Starting all of Matlab never took that long.

I don't know what version of MATLAB you're using :P. They definitely have their logo screen open for a minute or two before the program shows up. That's quite a long load time. They just made it pretty.

Have you tried under julia 1.1? Latency issues much better, and will only improve.

R is nice for stats stuff, even if performance can be iffy for certain tasks. The existing libraries for basic ML tasks are largely fantastic. The syntax rubs many people (including me) the wrong way. But I don't like the paradigm for basic ML tasks in scikit-learn (python) much better.

Anything involving matrix computation is great to do in python because of existing libraries (numpy). I think most people who are actually writing code (i.e. grad students) don't mind the syntax because they learned it in school starting in undergrad.

Octave's main appeal to me (and most people I work with) is being able to run existing MATLAB code. However, making it work for nontrivial MATLAB projects, is, well, nontrivial. It's also very slow.

Julia is the language I'm most excited about. It's fast [1] even though it has a slow startup time, and that's improving quickly. It's got a nice grammar-of-graphics-based plotting library [2] that's quickly catching up to R's ggplot2. I think it has potential to be the language of choice for non-neural-network stats/ML (that's python for the foreseeable future). I like the syntax a lot, too. The data types take some getting used to, not unlike R. I also think if Julia moves away from JIT compilation, it has potential to be the language of choice for deployed NN models (right now, that's C++).

As for plotting, R's ggplot2 beats MATLAB any day of the week for me. To each his own.

[1] https://julialang.org/benchmarks/

[2] https://github.com/GiovineItalia/Gadfly.jl

> I think it has potential to be the language of choice for non-neural-network stats/ML (that's python for the foreseeable future).

I think it will overtake python for NNet stuff also: https://julialang.org/blog/2018/12/ml-language-compiler

> Octave does to MATLAB what R has done to SPSS and SAS

It won’t because all those new algorithms aren’t written in Octave (for the most part), but MATLAB (or Python or Julia).

MATLAB is not a dinosaur: it has had line profiler, JIT compiler, 3D plotting, builtin scriptable debugger in the default installation, long before Python or Julia, who still struggle with these highly valuable tools. Now it has notebooks, and plenty of other new stuff inspired by recent new stuff in Python et al. On top of that there is a Python FFI so you can call out to a Python installation if need be.

> Here's hoping that someday, Octave does to MATLAB what R has done to SPSS and SAS.

SPSS and SAS have horrible, horrible scripting languages. R is just ...slighly wonky. So as a language, R was a huge improvement on its alternatives. Whereas Octave is just a clone of the Matlab language, (almost) no improvement, just slower and less access to libraries.

Its funny to me because for a lot of R users programming has very little to do with their use of R i.e. hypothesis testing using libraries like lme4 for mixed models.

If the language doesn't matter, why do you use R and not GLIMMIX in SAS?

Figuring out how to use R is straight forward. It is much like any interpreted scripting language and there is a huge amount of blog posts, stack overflow questions, books, YouTube videos, and courses on how to do things. It is free. SAS is expensive, the training is a joke, figuring out how to use it is bizzare. I could go on and on. I did a training at work on how to use R to a group using SAS to get them off of it and save us a significant amount of money. SAS seemed to be installed on the server and getting the client side to work on my computer took lots of effort between me and IT. SAS does have easy access to the databases we use, but it was really easy to get R database access with ODBC. In my opinion the gulf between Matlab and Python is much smaller than SAS and R. Granted, I'm not a statistician or expert in either R or SAS. I'm sure SAS does have some use cases where it shines (maybe where you need a really clear audit trail), but overall it seemed to be more confusing than it is worth.

I didn't mean it didn't matter, just that it is not at the forefront. The real reason is the open source licensing, the huge number of quality or advanced packages for stat analysis and graphing.

just use Julia. It's faster than Matlab, and a better language.

It will be very hard to displace Matlab out of certain very important niches. For example, across both academia and industry, Matlab is king in control systems design/analysis thanks to its toolboxes, Simulink, and (at least in industry), its autocoder. Matlab is used to generate the flight controls software on a lot of today's aircraft. In a number of other engineering disciplines, Mathworks has been astute in developing toolboxes that answer the needs of industry. There will probably have to bit quite a bit more paid development of Julia and its ecosystem to deal Matlab death blows in industry. I hope for it to happen sooner rather than later, as the 70s-era Matlab language and Mathworks' exorbitant license fees are holding things back.

Agreed. The academic part of my industry is starting to use Julia at the National Labs level, but virtually all University and National Lab code is prototyped in Matlab and textbook examples are Matlab. So it has a lot of momentum with researchers who never learned Python, Julia...etc. I don't think Octave or Scilab are seriously used anywhere unfortunately. When I ask, I'm the only one who has heard of them.

It is a better language indeed. Too bad that their IDE options are not par with it. Julia REPL is just that — a REPL. Julia IDEs are just editors for writing code. MATLAB integrated environment, where you can see all variables immediately, is what makes it popular; why not imitate it?

This is what held me back for a long while too, but Juno (the Atom plug-in) seems to finally have all the features I was missing in Julia compared to the Matlab IDE, including a decent variable inspector.

For what it's worth, the Spyder IDE for python imitates many features of MATLAB and I don't find myself missing much. The data viewer in particular is great.

I haven't used Julia's Juno yet, but have used Python's Spyder and found the combination of editor, REPL, variable inspector, and documentation pane to be great. I can't remember if Spyder can also show charts or if that has to come from the code itself if that makes sense.

Just out of curiosity, what is your opinion on other alternatives that are good with matrices such as Scilab, Python + Numpy, or Julia? Is your focus on Octave due to how close it resembles Matlab?

Just curious, what's your opinion on simulink

I haven't used Simulink since my control systems classes in college.

With that being said, certain tasks (control systems is a big one) naturally map really well to Simulink because the graphical block-diagrams in Simulink are identical to how your teacher draws out the system on the blackboard.

To use an example, power systems texts might use Matlab to show the algorithms for transmission level powerflows (Newton-Raphson, Gauss-Seidel, Fast-Decoupled, DC), but they use Simulink to show how the control systems on a generator are modeled and you can easily inject an oscillation and plot out how it would impact the generator. You could of course model the control systems of the generator with regular code, but I think it would be far harder to reason about. I know Scilab has something called "xcos" or something like that which is the beginnings of a free Simulink competitor, but I haven't seen anything in Julia or Python that can do what Simulink can do. If someone knows how to best do controls work in Python or Julia, please let me know how.