I wish Octave the best of luck, but it faces an uphill battle against MATLAB (established engineering projects) and Python (new starts).
The biggest issue with Octave for me is the slowness of its plotting compared to MATLAB. A major use case for me is visualizing large data sets. I can generate data using any backend (Python, C++, MATLAB, etc.) and want the ability to plot it, zoom in/out to a rectangle, filter to a subset / go back to the full dataset. Simple 2D plotting, no 3D or hard rendering stuff.
In such plotting I find Octave (and to a lesser degree Python's matplotlib) super slow compared to MATLAB. To see it, make a scatterplot of 1-5 million points (say, with x and y random, uniformly distributed in [0, 1]). Zoom to a portion a couple of times. MATLAB response is instant, Octave takes seconds. Do the same for 20 million points (which is still a very small dataset by today's standards) and forget about interactive plotting with Octave :(.
As I said, I still wish Octave the best and hope it succeeds, but with my student days behind me I prefer to just buy an individual license of MATLAB every 5 years or so for my hobby projects.
Curiously, I have the opposite experience as yours between matlab and octave. I have used both, and I find matlab clunky and slow to start, while octave is very lean and responsive. My way of using them is probably not very representative though. I never do plotting, it's mostly saving the computed solutions into files and looking at them with other programs. In the rare cases I need to plot something, I write the data into a file and call gnuplot separately. Also, I do not run the interactive interpreter, but I write scripts that launch a new interpreter for each run. Matlab seems to be extremely ill-suited for this usage. For example, it takes about 3 seconds just for launching (!). Also, there are bizarre problems (apart from ridiculous memory usage), when running several matlab instances in parallel.
Agree completely -- MATLAB is slow to start and is a memory hog. The language itself is horrible (which is why I prefer to use another language for complex back-end computation). Libraries for reading and writing formatted data are a joke (try reading a large XML or JSON file; or even a large CSV file with a mix of numeric and string fields); etc., etc.
But it is just so good for visualization that I am willing to suffer its other problems. For example, try the below and zoom in / out / resize in both MATLAB and Octave:
n = 2000000; x = rand(1, n); y = rand(1, n); plot(x, y, '.')
If your primary concern is only the quality of visualizations and not language or libraries, I'm curious why you'd choose MATLAB over something like Mathematica. I've always found the latter to produce far prettier plots (with far less effort).
I gave a more involved example in a sibling comment, but I need fast, interactive plotting for large datasets; not necessarily the prettiest. And as another user mentioned, MATLAB currently has a lock on fast scientific plotting. It really is in a league of its own for now.
How fast does it have to be? I was curious and implemented a trivial loop in C++ that draws "scatter plot" on your benchmark (scatter plot with lots of [0,1]^2 points). Its concept of "scatter plot" is: 1920x1080 image, draw a non-antialiased (i.e. ugly) filled blue circle of radius 4 at each point, where the unit square is stretched over the entire image.
Doing this (C++, CPU) takes ~0.21 seconds for 2 million points, and ~2.06 seconds for 20 million points. The result is a solid blue rectangle, but that's beside the point.
Doing the same on a trivial GPU implementation using CUDA, where I cheated by not even using atomic operations (so this only works because the dots are solid), takes ~0.23 seconds for 2 million points and ~2.3 seconds for 20 million points. Apparently the (my? (GTX 1050 mobile)) GPU doesn't help here.
For comparison, with matplotlib (`plt.scatter(x, y); plt.show()`): for 2 million points, plt.scatter() takes ~10 seconds, and plt.show() takes about 3 seconds fill first image. Zooms/resizes etc. seem to be the same time, or if less points show, proportional to the number of visible points.
So unsurprisingly my cheap C++ code is faster than matplotlib (it doesn't even anti-alias), but is it faster than Matlab? I have neither Octave nor Matlab, perhaps you can compare with matplotlib?
Thank you for the data point, but I do not think the issue is with rendering of the dots on screen (although I am not sure). In fact, I have done some real-time, frame-by-frame video processing using OpenCV and had no issue processing 1920x1080 images in real-time at 25fps (40ms per frame), including some simple edge detection, segmentation and rendering on screen using my office workstation. Modern hardware is certainly fast enough to render dots on the screen as fast as interactive processing needs.
What I suspect is taking place with Octave/Python/Julia-based tools is the additional information that needs to be handled for each plot. You need to draw axes and ticks, keep tracks of which points are displayed and obscured at at the current axes limits and update all that information every time any of those things change (reset/move/zoom, etc.). It is certainly possible to make abstraction layers that are convenient for software engineers but would not scale well with respect to the number of points that need to be plotted. Or, instead of carefully tracking each state change one could regenerate a large portion of it to make it simpler (and slower). Just a guess though.
I do think it's plotting the points that is hard: note that what I'm measuring is not rendering the image on the screen, but creating the image of the dots in the first place. Creating the image is O(number of dots) work; displaying the image is O(number of pixels) work and GPU-accelerated and peanuts.
I think this because in the end, after all the axis settings and such have been determined (and drawing the axes themselves is surely not the bottleneck), all that remains is just drawing the dots in the rectangular area set out for it. My benchmark does only that part, and as I said, I'm about 50x faster than matplotlib. (C++ and not Python, so I'm not picking on matplotlib, just observing.)
But anyway, if this issue is to be solved it is to be done by contributing to Octave/matplotlib etc, not by throwing around proof-of-concepts on HN. :)
> The biggest issue with Octave for me is the slowness of its plotting compared to MATLAB
I was going to say exactly the same thing. The language implementation is mostly fine-ish. But plotting (which is like half the point of MATLAB) is unusable slow.
It's not just Octave though. All of Julia's plotting libraries are similarly slow. MATLAB still has a monopoly on fast scientific plotting.
Matlab's hobby license is sufficiently cheap that I really would recommend getting that unless you absolutely can't afford it.
This (individual non-commercial license) is my current approach, too. I wonder though, why do we have such a lack of fast scientific plotting, as you wrote?
Is it due to the fact that few people really care or is there some inherent set of hard problems that Mathworks figured out how to handle?
I have no idea to be honest. I don't think there is much that is really hard about it. It's probably a ton of work because to be really useful you have to support a ton of options (like rotated labels, log axes, dashed lines, stepped lines, gaps in lines, etc. etc.). It's a nearly endless list and I guess to do that and to make it not slow is just loooads of work.
Julia is a new player but probably still "too new" for most people (I say this as a Julia fan). Python is a pretty old language at this point, but the data sciencey eco system has only matured relatively recently (compared to the age of Matlab anyway).
It probably is, but new vs old is not a big decision driver for me. The things that matter to me for scientific computing languages are visualization tools (most critical to me, by far), libraries for standard functionality like optimization and signal processing (not critical as I can use another language for back-end processing) and price.
I will try Julia's visualization tools sometime, but if MATLAB is significantly faster will stick to it for now. Just a single user's data point, not claiming that this is a universal view.
> Just a single user's data point, not claiming that this is a universal view.
Definitely not for me. As a matter of principle, I try to keep my computation and visualization tools strictly separate. Even, "artificially" separate, if you may. I would actually like octave more if it didn't provide a plot function. It would be closer to the spirit of the unix philosophy.
Your point is perfectly valid. I do separate my computation and visualization (sometimes both are MATLAB; just separate). For me the MATLAB is primarily an interactive visualization tool, although the main use case for most engineers I am sure is to use MATLAB for its scientific computation functionality.
If your benchmark is plotting 2 million points, it may also be slow. However, I find its ability to rapidly prototype tons of different visualizations useful. I try to avoid needing to plot 2 million points anyway.
I often need to visualize data and unfortunately, plotting and working with many millions of points is a key capability. For example, we might have an expensive piece of hardware that we are using and need to understand if an issue we are seeing is a problem in our user software, a firmware we wrote to interface with it, or comes from the hardware itself.
Having technical representatives from each team (each sure that his team has nothing to do with it; can they please go back to their offices now) in a room looking at the same instrumentation data with ability to quickly dig into various features and subsets is a huge help for such problem isolation. At least in my experience it depends on fast interactive plotting and filtering of large datasets.
Like you, I haven't used either for serious work in many years but the last time I was doing serious work I found Python to be much faster. I discovered this by accident after porting one of my Matlab programs to Python and noticed an immediate 4x speed improvement. I worked with both for many more years afterward and in my experience Python was usually faster with a few exceptions.
That said, Matlab had great tech support and the sales rep was always super helpful. They were much nicer to work with than say National Instruments.
For me the issue is less performance and more correctness/completeness. Mathworks has teams of engineers working on their toolboxes, which helps a lot for users that need features and needs them to work correctly.
It's been some time since I had to use Octave because I didn't want to pay for a Matlab license, but I recall remez() didn't properly implement the Parks-McClellan algorithm and would return suboptimal results (which is a problem, when the algorithm is intended to find the optimal solution).
I know it's not really the point here, but it's nice to see a GNU project with a decent home-page. It's clear, presentable, and modern. (And of course it's not a JavaScript horror-show, but we'd never see that from a GNU project.)
You say that, but I feel like it's a bit of a case of 'dress for the job you want'. Having a modern-ish looking site just gives off some signals like 'this is maintained', 'this has been deemed to still have utility in 2020' and 'the developer has some awareness of current UX'.
It doesn't need to be flashy. Just a nice font, a header, centre justification, some spacing, a paragraph explaining what the thing is, a nice logo, maybe some screenshots or a link to the docs and a download link.
I had this thought recently--is there a class of website where being being unstylish and looking like it came out of an earlier era of web design gives the site more credibility?
You might be right, like *nix utilities that have been around forever? Perhaps https://www.cis.upenn.edu/~bcpierce/unison/ is such a page? Staid, having a sense of permanence, what in Britain we describe as "part of the woodwork" (something that's been around so long, and is dependable, like the very structure of a building).
Sure, sites like Pinboard, SourceHut, and of course HackerNews, that appeal to the bloat-averse traditionalists who believe web pages should be lightweight.
It's not about aiming for an ugly UI, it's about getting out of the way and presenting a clean, simple, fast, functional page.
The designation brutalist web design has gained some traction. (I would have linked to an article on this, but ironically the page I found was offensively spam-ridden.)
I was able to compile GNU Octave 4.4.1 into Web Assembly for my MATPOWER PWA. When Mozilla was still at full force OctIodide might have been an interesting project for them.
Satisfying the BLAS/LAPACK dependency was one of the biggest challenges. I ended up passing LAPACK 3.4.2 through f2c before compiling the result with emcc. PCRE and some SuiteSparse libraries were the only additional dependencies needed for my project and they compiled with Emscripten without too much difficulty. The rest was just hacking GNU Octave's Autotools build system, which gleans a lot of information from the system environment, into working with emconfigure and emmake. My changes to the GNU Octave source code are available here:
This is very interesting and would never have guessed that it is possible. I would love to read a more detailed write up how all this works (is everything bundled to a large blob for the octave interpreter for example?). Also is the a specific reason you used v4.4.1? And playing with the PWA everything seems instant, but Octave is ~1Gb installed, wouldn't the Octave wasm have to be downloaded to the client (which it doesn't seem to do)?
The GNU Octave interpreter and its dependencies are all in the matpower.wasm file. 19Mb is still quite large for a website, but it is loaded asynchronously and WASM get compiled as it streams in. The interpreter runs in a WebWorker using a Promise based interface so the UI doesn't get held up. Many of the dependencies (e.g. FFTW, CHOLMOD, ARPACK, Qt, HDF5) are disabled as they are not needed to run MATPOWER. There was no particular reason for using v4.4.1. The core functionality of GNU Octave doesn't change much and that version was stable and sufficient for my needs.
Thank you for explaining, I will have to explore this further as this opens up a lot of interesting possibilities. I find it very impressive that you have managed to get virtually no perceptible loading time at all, for octave running on a client (I remember threads now and then about statically compiling octave for portability which all eventually end up with it not being possible so I would never have guessed this was viable).
When I left university and did not have access to MATLAB anymore, I spent many a nights hacking away at GNU Octave. I have fond memories of Octave.
I thought Octave will be a valuable skill when I enter the industry but I could not have been more wrong. Does anyone still use Octave? Is it worth learning?
What tools or languages would you recommend as alternatives to someone graduating from university today?
My biomedical engineering thesis was entirely coded on octave, and I still use it daily even though my current employment does not directly relate to it code-wise.
Also, while perhaps this example is overplayed, Andrew Ng's hugely successful coursera nanodegree on Machine Learning is taught on octave. Andrew Ng explains the reasons for this beautifully in his course, and I agree.
As for "I thought it would be a valuable skill; I could not have been more wrong", it depends. To remove the obvious comment, there is octave, matlab, and octave/matlab. Matlab is still 100% huge in the industry, and getting into this path through octave is at least equivalent, if not better (given you also have to learn more under-the-hood concepts than you might have to in matlab).
However, I will assume here that you are referring specifically to the whole "investing in the octave ecosystem on top of already knowing the matlab language" issue. I would argue that octave tends to be more used in teaching and academia, so you're partly right. But at the same time, I would argue that as an open source project, the opportunities for participation and the transferable skills you can get from that are extremely relevant in any resume.
I can only speak from a data science perspective, but a lot of folks I know needed to move from MATLAB/SAS/SPSS to R (using RStudio) and Python (often with Jupyter Notebooks) once they got into the field. Might just be the circles I run in, though.
I personally recommend Python (using NumPy, SciPy, MatPlotLib/Seaborn, Pandas, Keras/PyTorch, Gensim, etc). There’s a lot more that you’ll need to bolt together yourself, but there are packages for pretty much anything you’ll likely need to do in terms of math/science/analysis/ML.
That’s not to say that you shouldn’t advocate for Octave, though! I haven’t used it other than to poke around, but it seems like a great package.
Do any of them use julia in jupyter? I like the syntax and speed much better than numpy. The ffi from numpy into its native implementation is a high overhead.
None in my immediate group of friends, no. I honestly feel a bit behind the curve in terms of not knowing much about Julia these days. Maybe I’ll use it for Advent of Code this year!
> I thought Octave will be a valuable skill when I enter the industry but I could not have been more wrong.
If your skill with Octave makes you more effective in a role, then it's still valuable even if your employer doesn't specifically require experience with it.
I started using Octave after a coworker showed me how he used Matlab as a DSP prototype workbench. At the time I couldn't justify asking the boss for my own Matlab subscription, so I applied what I learned using Octave instead. At this point in my career, Matlab is available to me but Octave does what I need.
I work with small engineering firms (antenna design and chip design). Most of them use Octave because MATLAB licenses are too expensive. Most of them are MATLAB users by training but are happy to use Octave to save the cash.
AFAICT, Python and associated tooling (numpy, Pandas) are taking over many parts of industry where Matlab used to be king. For the rest, it really depends what you mean with "the industry". Different sectors have different languages.
I've seen people use Octave in their workstations but I never worked where Octave code was used in "production". It was more of a individual prototyping/exploration tool for those who knew it.
I worked at a university lab throughout undergrad and grad. I wrote a lot of MATLAB. I graduated and got a job as an engineer at a lab in another university. I write a lot of MATLAB.
I've always preferred MATLAB to Python as the more engineer-friendly programming language. The interface was a plus as well. That being said, given the sheer amount of scientific libraries for Python and universities moving towards it as well, I'm wondering if the effort to maintain Octave is worth it.
One use for it could definitely be running older MATLAB scripts that have deprecated language features. Those were a real pain to make work again.
In my opinion it is absolutely 100% worth "developing" Octave (the word 'maintain' makes it sound like it's an otherwise static project).
The improvements from 3 to 4 were massive. The improvements from 4 to 5 equally so. I can't wait to try 6.
In any case, it is definitely not just a tool for running 'old matlab scripts'. It is a beautiful language and environment in its own right, and if academia manages to wake up at some point they would invest in it for the open source environment that it is, in a way similar to python, and help it get even more amazing.
I use both Python and Octave and I can clearly say that one never replaces the other.
For quick and dirty scientific PoC or obtaining ground truth, Octave/MATLAB is much better since it handles all the quirks of numerical programming with generally slow but with proven solutions.
During development phase of my Ph.D., my professor would scribble something in MATLAB and send it to me with a note "for the given inputs, you should obtain this and that. Attached is the crude math". It was up to me to clean the math, convert it to C++ and make it blazingly fast while solving any attached small but hard problems.
I still have a MATLAB license to test these ground truth scripts against my code.
There is still a lot of mathematics that there are matlab scripts for, and not python. I think it depends on how deep you dive into a particular area of course. But I think it’s definitely worth it.
I spent the majority of my career porting MATLAB to C++. We charge about $70 an hour ($200 billable man-hour) to do it. It’s a slow and arduous process. Often times the features that are running in Matlab needs some C++ library that prevents the sort of speed increase that you hoped to gain out of the C++ port, so a C++ reimplementation of the toolbox needs to be developed anyway; this loosing the benefit of the “verified“ toolbox.
Python, on the other hand can be improved for performance piece-wise through tools like cython and swig. Of course, both offer a C interface, but I prefer the python one to MEX files for a variety of reasons. Also, you don’t have to pay a license to use python. (Same library implementation problems)
Add a minimum, if the MATLAB folks would at least consider moving over to Octave we could illuminate some of the licensing fees, but... once performance matters, you’re still going to have to pay a full-time software engineer to port Octave code to make it performant.
I would be curious to know more about your firm and what customers you are serving? I feel like I have a lot of experience translating or communicating with weird things to MATLAB but I'm not sure who values this outside Academia.
A lot of companies in the (German) automobile industry rely heavily on Matlab and its toolboxes, so I'd assume that people like you are wanted there as well.
MATLAB seems ill condusive for structuring and organising code in a sane manner. It tends to give its users bad habits with respect to structuring code is what I observe.
It seems to lack data structures that are quite pervasive in modern programming practise.
Also python being a general purpose system brings its own benefits, one can easily hook up ones code to fetch or push data to databases and even easily scrape data of the web or extract/reparse/rectify/reformat poorly/complexly structured data before processing.
And I find MATLAB not feature rich in terms of being able to manipulate tabular data in a relational DB like manner, that is querying/projecting/selecting rows/colums to find interesting facts.
You write a function, using nice linear algebra syntax. Already python is worse: you do a bit of import boilerplate and write linear algebra in a gimped notation. You call the function. Not so in python, where you have to import it first. You change the function definition, next call will be redefined function. In python you can try to do an interactive reload via third party software but chances are it won't work right since Guido apparently never considered this something worth designing properly (apart from matlab lots of "real" programming languages are much better at this, including erlang, common lisp and smalltalk).
Your function runs too slow. You press a button and you see a color coded version of the code in your editor window and see instantly where the bottleneck is. In python you break out one of several crappy profilers. You want to save your results from your interactive exploration "save results.mat" -- done. In python there are various ways of saving stuff, which are either not general or slow or don't work between different versions.
I haven't used matlab in years, but as an interactive environment for linear algebra it blew python out of the water and likely still does, even if it has a number of big shortcomings as a general purpose programming language (and probably a worse selection of libraries in quite a few numerical domains these days as well). This is particularly true if the people using it are not trained programmers.
> You call the function. Not so in python, where you have to import it first.
Er, no you don't, if you are using it in the same notebook, module, or REPL session where you defined it. And if you aren't doing the equivalent in MATLAB, you also would have to load the definition.
What on earth are you talking about? If I add `def bar...` to a file foo.py in my PYTHONPATH, it does not suddenly become available in my interactive session, I need to import it first. Further if I change foo.py even importing it again in the repl (or jupyter notebook) will not have any effect. You will need to use one of several reload hacks which in practice won't work reliably for all sorts of reasons. In contrast, unless my memory severely fails me (and I don't think so, since I just checked against octave), in matlab if you edit a file in the path, it will be auto-imported every time you save it as soon as the repl is non-busy.
On the other hand, if all you need to do is to state and solve a few humongous linear systems, or a system of ordinary differential equations, or a partial differential equation, or compute the vibration modes of a solid shape, or perform an elasticity analysis, or simulate the absorption spectrum of a chemical compond, or find the numerical solution of a system of nonlinear equations, or optimize a function that has terms in both the spatial and the frequency domains, then Octave is definitely up to the task and will probably solve your problem out of the box in a handful of lines of code. In python/numpy, the sub-par linear solver will probably fail or be extremely slow on large linear systems (because the scipy developers are a bunch of anti-GPL fanatics that refuse to use the state of the art linear solvers because of license issues). But yes, you have nice strings and dictionaries at your fingertips; too bad they are completely useless for numerical computation.
Still doing many things in Python is a bit more laborious (no surprise and not a drawback of Python, it is general purpose language) than in Matlab/Octave. Plus learning curve is lower for Matlab/Octave, after long years of not using Matlab I've taken some ML course on Coursera that was using Octave and I was able to be productive very quickly.
Depends. If it is about the base language then it should be. But if you're using toolboxes then Octave's packages have numerous unimplemented functions compared to their MATLAB counterpart. And in genera keep in mind that compatibility isn't perfect.
Depends what your expect from it. It got me through University and I had a much better experience with it than most others had with MATLAB. But I used it for maths during compsci. I suspect it's different for engineers trying to use existing code packages to solve mechanics problems for example.
For me Simulink has always been the biggest missing part. Also RTL (or other code, e.g. for DSP chips) synthesis for Octave is pretty non-existent AFAIK.
When I was doing FPGA work Simulink was very handy for plugging together quick signal processing flows. I kind of miss it, but I've moved on to strictly c/c++ embedded work
Not to do down Octave, but if you want a free alternative to MATLAB, Scilab might be worth checking out too, particularly for an alternative to Simulink, as I understand it. It has a different emphasis, like not aiming at compatibility the way Octave does.
It grieves me to see how much money squander on MATLAB (and they're apparently not allowed to compare notes, which says something). The ones I'm familiar with pay around (or more than) enough to fund a full-time support post, so there could instead be a significantly-sized sustainable research support team working in that area, just in the UK.
I have used both Octave and Scilab as a substitute for MATLAB. Scilab is a much more polished system, but it has multiple gotchas if you are moving back and forth between it and MATLAB. Octave aims for full MATLAB compatibility, but I found the system pretty rough all around.
I don't think so. I imagine it would be very hard for Mathworks to claim copyright over mathematical functions and established terms such as "fft" or "rms".
On top of that, Octave isn't even in competition with MATLAB. The much higher performance and capabilities offered by MATLAB that aren't available in Octave (like C++ export including support for GPU acceleration) along with professional support are enough to keep the target audience from considering Octave over MATLAB.
Octave isn't encroaching on MATLAB sales, so I don't think such ruling would be an issue as I doubt that Mathworks would even consider legal action.
Even if they would for whatever bizarre reason, it'd be sufficient to just change the names and parameters of some functions - lots of work, sure but ultimately not too big an issue.
A script could be used to translate between the dialects and people using Octave over MATLAB would continue to do so, since their motivation for choosing Octave wouldn't change due to this.
Currently you either have MATLAB+Toolboxes or Octave+Packages. I always wondered whether there could be a project to create open source toolboxes that would run in MATLAB. That means no effort is needed to maintain the core language features of MATLAB (of course you would need to buy the basic MATLAB licence without the Toolboxes) in that project and all the energy is spent on developing open-source toolbox replacements (which are typically way more expensive than basic MATLAB licence).
The economics don't work well. Softest economy comes from scale, so the best bang for buck is to make free popular things, not to shave $50 off the edge case of your MATLAB outlay.
Is it worth learning Octave/Matlab for ML or Data analysis work? Does anyone use it outside the engineering/scientific research community? Since Andrew Ng teaches his ML course in it, I'm curious. However, I'm wondering if learning Julia or R will be better for my career. I mostly use Python/SQL at work as a data analyst.
In terms of current job openings probably R is best. Julia got its first stable release in August 2018, meaning that more companies could be adopting it now, but R has been around since 1995. If you like Python, Julia is probably easy to pick up though. Octave is incredibly slow and no competition for Matlab, Matlab is terrible as a programming language if you're used to Python, so it's likely you wouldn't enjoy your job if it involved Matlab.
In general, no, especially for typical data analysis tasks. MATLAB used to have an edge in signal processing, but (IMHO) lost it to Python-based solutions (especially when running things on GPUs, ML or not). If you're doing a lot of exploratory data analysis and statistics, R is worth a look.
Thanks for the replies. I did a course on Data Analysis from MIT and used R a bit there. I liked GGplot and RStudio. I don't think Python has anything close to those two. R was a bit harder to learn and I've already forgotten most of it, since I don't use it. I understand that it's based on Scheme and has roots in functional programming. I'm curious about Julia as it's being promoted as one of the fastest languages. I don't see a lot of value in that as I do most of my data intensive (in terabytes) work on pySpark on AWS clusters before I touch Pandas or any other BI tool. I couldn't use Julia on my laptop to do that! I guess sticking to R has more short term benefit as most courses on Statistics are heavily dependent on R. Julia will probably catch up soon.
A general note that applies to some comments in this discussion, but to any discussion of Matlab on HN. Yes, Matlab is still used heavily, even for new code, and it will continue to be used for many years into the future. It doesn't really add much to the conversation to generalize from the small sample that is your slice of one industry/your employer/your inner circle of friends to conclude that Matlab is dead. According to Wikipedia[1], Mathworks had revenue of more than $1 billion in 2019.
> What value can Octave give me, relative to python?
For me the main thing is that math is "native", I don't need to import anything to start doing linear algebra. In python, doing math seems like an afterthought. For example, python offers you strings and dictionaries out of the box, but not ndarrays. In Octave, it is exactly the opposite, and it just feels right.
To me the biggest value octave gives me is its ease of use. When you are trying to learn a new mathematical concept and are manipulating matrices and vectors, Octave/ Matlab is a breeze. Compared to other languages that require you to call the `dot()` function.
Additionally compared to python's matplotlib, Octave / Matlab's plotting syntax is much simpler. Not faster but its functional.
In short, its a great educational tool, prototyping mathematical / engineering models. Bad for production use where you are using the code base to actually solve an engineering / science problem.
You have some crusty MATLAB code that does an analysis exactly the way you need it. It was either written by someone who is long gone, or you don't have the resources to rewrite it in 202x's new computational language.
The biggest issue with Octave for me is the slowness of its plotting compared to MATLAB. A major use case for me is visualizing large data sets. I can generate data using any backend (Python, C++, MATLAB, etc.) and want the ability to plot it, zoom in/out to a rectangle, filter to a subset / go back to the full dataset. Simple 2D plotting, no 3D or hard rendering stuff.
In such plotting I find Octave (and to a lesser degree Python's matplotlib) super slow compared to MATLAB. To see it, make a scatterplot of 1-5 million points (say, with x and y random, uniformly distributed in [0, 1]). Zoom to a portion a couple of times. MATLAB response is instant, Octave takes seconds. Do the same for 20 million points (which is still a very small dataset by today's standards) and forget about interactive plotting with Octave :(.
As I said, I still wish Octave the best and hope it succeeds, but with my student days behind me I prefer to just buy an individual license of MATLAB every 5 years or so for my hobby projects.