As somebody in an academic field where many scripts exist for MATLAB (mostly digital signal processing focused), there are few projects I want to succeed more than Octave.
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.
Here's hoping that someday, Octave does to MATLAB what R has done to SPSS and SAS. MATLAB is a dinosaur deeply begging for an asteroid.
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).
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.
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).
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.
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.
> 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.
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.
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?
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.
I spent a few years writing software professionally, a large fraction of it in MATLAB (engineering tools development for gas turbine companies). With every project I lost more respect for matlab, which is very slow, and clunkier than the marketing material would suggest (for instance, IPC. Or accidentally passing a large data set to a vectorized O(n^2) operation). And they charge you $20k/year for a single license!
I still have some old personal code left in matlab, and I have been using octave a bit lately just to keep running it- I have to say I do appreciate octave.
My biggest complaint is how slow plotting is, for instance, I have a method of characteristics supersonic nozzle design software based on the modified Sauer method and methodology of Zucrow and Hoffman, that runs in a couple seconds, but in octave it takes several minutes to plot no more than a couple hundred lines (no, just straight lines with two points). What gives?
One thing that caught my eye was your $20k/year license fee for MATLAB. How many toolboxes did you purchase?! I maintain a commercial license for a single user and it's nowhere near that. I purchased a perpetual license originally:
Toolboxes are in the $5k range (to me that is crazy), so if you get the database, optimization, and power systems toolbox with a license, you're not far from $20k.
This is one reason why if I had to pick commercial software I would choose Mathematica as they put everything in core as part of the standard license and don't require toolboxes for something the default software should have.
I have used Matlab and GNU/Octave in parallel for some years half a decade ago. Octave can do most things that I needed but was slower to run for many things. With Octave you didn't run into licensing problems as those floating licenses had their limits and sometimes I needed to run quite a few instances in parallel.
Now I use Python exclusively. The language is so much better and more sane and almost any library is available. I will never go back.
Today, I would recommend Matlab only in rare circumstances. Currently I cannot think of one use case that I had in the last three years where I would prefer Matlab to Python. Using the Matlab language with a portable Octave installation can be useful for teaching matrix/vector topics to people who have little programming experience and don't know Python. You can get results very quickly. The syntax feels most natural for manipulating matrices and everything seems to be a matrix.
Other than that I think the Matlab language and ecosystem is kind of a dead end. But it will provide profits for a few more decades due to sheer inertia.
Matlab and Octave are both easier to do some basic numeric work for people (frequently engineering and science students) with only rudimentary programming experience. In undergrad you write very little code, but do a lot of plotting and it is helpful that the Matlab IDE has all of that natively builtin. I prefer Python & Julia now, but getting something like Matplotlib working with Python would've been more difficult for me in college. Also, Matlab has native support for matrices and numeric operations (inversion, transpose, solve) that students need without having to learn how to use something like Numpy. My preference depends a lot on whether I'm doing exploratory work or trying to craft high quality software to run in production.
import cmath
import numpy as np
np.exp(-1j*cmath.pi*np.array([0, 0.5, 1]))
Note that you can't use math.exp for complex numbers, and neither math.exp nor cmath.exp works for arrays, you need the separate np.exp. Also, while np.exp actually works on lists, the multiplication doesn't, so you need to keep in mind which variables are python lists (that you mostly cannot do arithmetic on) and which are numpy arrays.
When you are experienced in Python, you know these differences by heart. But if you are a domain specialist and want to test an idea quickly, you will see lots of TypeError messages from Python, you need to google manuals to sort it out, and it will slow you down 10x.
1) there is no need to import anything but numpy to get at pi or e (see constant section of numpy docs).
2) if you wrap all your things you expect to behave like vectors/matrices with np.array() and only use np methods to operate on them you will suffer from shape mismatches instead of TypeErrors, a slightly better fate.
I work as an applied mathematician writing numerical codes and I prefer to prototype in MATLAB/Octave for a number of reasons:
1. I believe it to be far easier to debug an algorithm in MATLAB/Octave than Python. When I drop into the debugger, I can immediately check things like the eigenvalues of a matrix with a simple "eig(A)" or look at the sparsity visually with "spy(A)". Though this is possible in Python, I believe it to be far easier in MATLAB/Octave because the core mathematical functions are immediately available.
2. MATLAB/Octave link into the good factorization codes directly and provide license coverage in different ways. For example, both codes link into things like SuiteSparse, which gives access to fast Choleski and QR factorizations. These routines have different licenses, but the good ones are dual licensed GPL/Commercial. Octave links into the code under GPL licensing. MATLAB provides a commercial license. This means that I can give a customer MATLAB/Octave code and they can choose whether or not they want license coverage using MATLAB or to release the code under GPL and we don't run afoul with the licenses. Candidly, not having to go off and obtain a second license for SuiteSparse is nice.
3. In my opinion, the C-API in MATLAB/Octave is more sane than Python. It's not great, but the matrices are laid out in a rational method in MATLAB/Octave, so it's really, really easy to link into an old C/C++ or Fortran codes. Often, I've used this trick to debug the C/C++ code because I can more quickly visualize the matrices in MATLAB/Octave than I can using the native language.
As for the difference between MATLAB and Octave, I prefer Octave over MATLAB since:
1. Octave is more sane when dealing with the C-API. MATLAB is not bad, but it can be finicky sometimes and I don't feel like I should have to manually set dbmex on.
2. Octave uses the system version of GCC and does not package it's own. MATLAB does and for many years since MATLAB slow played their GCC version, this was a major annoyance when linking to codes that used C++11/14. MATLAB has done a good job in the last few years of catching up, but I still prefer to use the system compiler.
3. There are bugs in some of the Octave packages. MATLAB tends to have fewer such bugs. Most of the time, it doesn't matter till it does. Just file the bug with Octave. They can be slow, but there are a lot of people who volunteer their time and filing such bugs or helping to fix this is just the cost of this kind of software.
And, look, if you like Python, great. I also work with Python. However, again, for prototyping a technical algorithm, I prefer Octave.
That’s a well thought out argument and I appreciate it.
I also use MATLAB/Octave quite a bit for numerical algorithm prototyping, and mostly hate it. The language has a shallow learning curve, true, but for complex software it gets ugly very fast. It’s just not a well designed language, and if you have any CS background that becomes very limiting.
The thing that MATLAB brings to the table is the incredibly high quality numerics toolboxes. Octave gets a few of those but far from all of them, making it in my experience a poor runner up.
Whenever I have a choice I now go first to Julia. The language just makes me happy and the numeric infrastructure is almost complete enough.
Except for something like Simulink. When you need Simulink, there’s nothing else out there that’s a valid alternative.
For sure and I agree with many of the difficulties associated with MATLAB/Octave. When I want to put together a more complete piece of software that does things like: have a GUI, interact with a database, network conductivity, or parse files, I think that MATLAB/Octave is a poor choice.
A language like Julia tries to bridge that gap. My problem with Julia is that we don't get license coverage for things like SuiteSparse even with a JuliaPro license. MATLAB has done a fantastic job of dealing with this and is well worth my license fee every year, so that my customers and I don't have to deal with it. Till this changes, it's a nonstarter for me.
As far as the differences in packages between MATLAB and Octave, I'll contend that it depends. For their lower level routines, they often use the exact same codes. Both use ARPACK for iterate eigenvalue solving. Both use various forms of SparseSuite, UMFPACK, LAPACK, and the like for their algebra. For me, I tend to only use these lower level routines, so there's little or no difference in performance or efficacy between the two. For the toolbox arena, I know there are differences and I agree that can be frustrating. I suppose my point is that it really depends where on the spectrum of lower level to higher level mathematical abstractions that we need. For low level abstractions, I feel that Octave works great and it's been a critical tool for me.
The other thing Octave/Matlab has over Python: it's a lot easier and clearer to express numeric algorithms in Matlab than Python, as Python isn't designed as an array language.
Citation: go on github, search PRML and look at the Python versus Matlab results.
I don't know why people have a problem porting Matlab code to Octave; it's been drag and drop for me except for the more esoteric package dependencies.
I only had short experiences with MATLAB/Octave as a student but found that writing MATLAB/Octave rather than MATLAB or Octave was tricky... (IIRC mostly with differently named library functions)
Is this a nuisance also for you? I would be interest in how do you overcome this (asking for a friend working in image processing in MATLAB)
To me, it depends on how toolbox dependent your code is. Octave Forge has a lot of really nice libraries, but their interfaces tend to differ from MATLAB toolboxes, so getting codes to go back and forth can be a pain. In core MATLAB/Octave, most of the code is the same with some minor differences. For example, Octave doesn't care about wrapping a line with ..., but MATLAB does. Honestly, that's the most common issue that I have, but the MATLAB parser finds it and it doesn't normally take me more than a few minutes to fix things.
I recall there being some minor differences in how mex files are written, but I'm looking now and all the routines I typically use are mirrored between the two. I will say that I don't like building mex files using mex command inside of the interpreter. Personally, I find it easier just to use a build system like CMake. Mex files are just dynamically linked libraries that link either to libmx and libmex on the MATLAB side or liboctinterp on the Octave side. They look for name mexFunction on our end. As such, I have a flag in the build file to switch between MATLAB and Octave headers and libraries depending on what platform that I want to build for. Just be sure to separate out the binaries because those aren't really compatible between the two and the licensing between them is different as well.
As someone who is still annoyed that their degree program (a non-CS engineering) had them use Matlab instead of Python, I find it hard to disagree with those points. I will say that I definitely enjoy the 1 based array indexing.
Should a university use something like Matlab/Octave or Python to teach numerical methods and related classes?
Matlab is usually only ~$20 for an engineering student and the language itself is mostly imperative with matrices as the default data type. Also, plotting and variable inspection are available as part of the default install.
Python is Object Oriented. While that is certainly better (well ...most would argue so) from a software engineering perspective, it is a bit of a hurdle for an engineering student with a little bit of C background. I can still remember most of my numerical methods homework assignments. Build this matrix, invert it, implement Simpson's method...blah blah. This is definitely possible in Python, but I would've had to figure out which libraries to import, which Python distribution to use (if you don't use Anaconda or WinPython, getting certain libraries to work is difficult), and a myriad of other problems.
In short, even though I like Python better, Matlab might have been a better choice by my teacher at the time which allowed us to focus on numerical methods and control systems rather than getting lost in the rich Python ecosystem which has a higher learning curve.
Does that mean Python couldn't have worked at all? No I don't buy that either, but think it requires a different approach. If I was the engineering Dean I would require a course called intro to scientific Python which is all about getting a good Anaconda distribution setup with the Spyder IDE and Jupyter Notebooks with some basic Python coding. Then, when it is time to take your numerical methods, digital signal processing, control systems...etc, the teacher can host Jupyter Notebooks that interactively explore the subject with LaTex, code-snippets, and graphs. There is a university somewhere where the professor has a full DSP book done via Jupyter Notebooks and it seems glorious.
> Matlab is usually only ~$20 for an engineering student
Guess what, apparently the first hit is not always free. There are people posting in this thread who have to pay as much as 20k per year for a fully licensed Matlab.
1.) I'm not sure why you appear to be taking an aggressive tone :)
2.) I've posted several comments on here including one showing that the cost can be up to $20k, so I'm well aware of that fact, but it is irrelevant to the above comment as the $20k is for working professionals and not poor engineering students where the cost is indeed ~$20 as I've paid it. Note that $20k is insane by some standards, but engineering software frequently gets much much higher than that. Yearly licenses in the 0.5 million range are common in my industry, so $20k is not considered unreasonable based on cost alone. It is unreasonable to me when they have free alternatives.
3.) I have said multiple times on here that I prefer Python and Julia as they are deeper and don't cost an arm and a leg. However, my above point still stands that Matlab isn't a bad solution for a student. There is some lock-in of course, but it isn't too bad to migrate away after you graduate and can no longer get the student rate.
There was a little bit more information about that above. I'm a professional and my initial cost was around $2k and my yearly cost is around $400. I don't have to pay the yearly, but I like the updates and I like getting a response when something breaks and I'm on a tight deadline.
I can't stress enough that what you buy with MATLAB is license coverage. Octave and Julia hook into many of the exact same libraries, but they have not negotiated a commercial license for things like linear system solvers. That means that distributed binaries may be subject to things like the GPL. If that's what you want, great. I like the GPL for a certain kind of software delivered to a certain kind of clientele. However, it's a nonstarter for most of my clients, so they buy MATLAB.
That's a pretty good and useful point. I don't sell software (just use what I write), so I'm not worried about encrypted binaries at the moment. If I was actually selling software though I probably would be. The GPL has always been a double-edged sword to me. Sure it is nice and free as in beer and freedom, but it can also essentially mean that it is a complete no go.
The argument for a language like Octave/Matlab is analogous to why GUI software coexist with CLI alternatives. The Octave/Matlab audience may not be as technical and require a tool that has built in modules/libraries for advanced plots (without a lot of technical pain) etc.
I work in an academic setting. If I had the choice I'd prefer Python (or even Julia), but frequently Matlab is what's appropriate in a lower-division STEM (non-CS) course because it's what many engineers are used to and teach or expect their students to know. I'd rather use Octave than Matlab in such settings, and encourage students to do the same. Also, Matlab is still much more common (at least in undergrad engineering courses, not so sure about actual usage in the industry) than Python or other similar tools, and it's good to have a free software alternative.
That said, I sometimes feel Octave is too much a clone of Matlab, warts and all, and I'd rather give up some compatibility for genuine improvement. (Same way I feel about LibreOffice or OpenOffice sometimes.)
For those who also use Matlab/Simulink for simulation, Modelica could be a nice alternative with an open implementation, which also has serious industrial application like controlling power plants.
It's worth noting that the popular Coursera course "Machine Learning" taught by Andrew Ng uses Octave as its tool. This is mentioned in the Octave book's preface; see https://www.coursera.org/learn/machine-learning if you're interested in the course itself. It is possible to use MATLAB instead, but there's often no real reason to do so. I think a lot of people have already decided to use Octave instead, because it solves their problems just fine.
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.
Here's hoping that someday, Octave does to MATLAB what R has done to SPSS and SAS. MATLAB is a dinosaur deeply begging for an asteroid.