I’m curious, are there any Octave users on HN? What are your use cases, in particular different to just an open-source Matlab-like clone? Why Octave not Python?
I use Matlab-likes (actually Scilab rather than Octave) for one offs and interactive use. That’s usually playing with a dataset, test some analysis techniques, quick regressions, solving linear equations systems, this sort of things. I hate having to set up the whole machinery when doing this in Python. Also, the general-purpose nature of Python gets in the way, whereas the Matlab-like syntax is very focused and much less cumbersome. This does not matter much in a script, but is a pain for interactive use. On the other hand, Matlab is terrible to write scripts, with its inconsistencies and its almost-Fortran-but-weirder syntax.
Once the pipeline is set, Python is for scripts that need to be run more than about a dozen times, or need to be run on several datasets, or for things that need to be reproduced exactly (like stuff that goes into a paper). I also use it to prepare datasets from large numbers of calculations where the useful results need to be gathered from dozens/hundreds of files in a more or less complex file structure, often on different computers, with the occasional pass with some post-processing tools.
I really dislike Matplotlib, so rendering is done in something else, usually gnuplot.
That’s for my stuff (mostly atomic-scale modelling and quantum chemistry in materials science), it might be different for other use cases...
I really like matplotlib: while it is not intuitive and the documentation is sometimes lacking, there are a lot of examples online and stackoverflow answers all my questions.
That said I may use matplotlib much less than you do (I used it a lot when I was a student, now maybe 6 times a year).
> I really dislike Matplotlib, so rendering is done in something else, usually gnuplot.
This! My biggest gripe against Python numerical stuff was matplotlib, until I realized that it is an entirely optional component of the stack, and you can plot by other, much saner means.
Yes, there are many good alternatives. Seaborn, Plotly, and many more. I still use Matplotlib for most things (with the OO API), as I can control its fine details and it's more versatile. For non-graph visual things that I could use Matplotlib for, I've been generating SVGs and displaying them directly in Jupyter notebooks (with Cairo is one option, but just directly is pretty easy too).
You may have other reasons for preferring Matplotlib, but I don’t think anything allows more control over fine details or is more versitile than gnuplot.
I've never had much use for Gnuplot. It can do lots of things, but in my experience, it's been easier to get what I want in other tools. Most of my plots are created in Python programs, Latex documents, or interactive web pages, where I use tools focused on that purpose and embed the code where it fits. For most of my one-off explorations there are better tools too.
If I'm using Matplotlib, I'm almost always plotting things calculated in Python, so all my data and variables are right there ready to go. I think the fine details are controllable in more programmatic ways than Gnuplot. I use other Python libraries when they're a better fit. Being Python and object oriented makes it easy to figure out how to do many things (e.g. autocomplete).
If I'm doing one-off throwaway plots, there are better and easier tools than Gnuplot: Desmos, GeoGebra.
If I'm making interactive demos, there are better tools than Gnuplot: Desmos, GeoGebra, JSXGraph, Jupyter.
If I'm plotting a function for a high-quality PDF document, TikZ gives me more control than Gnuplot, and makes it easy to make many plots with consistent (and changeable) style, though being a Latex-based tool it has limitations to go with its power. TikZ is great for diagrams too. Asymptote is more powerful than TikZ in some ways for this kind of thing, but often harder to use.
I can’t really disagree. It takes a while to come to grips with its concepts and language for settings. But basic plotting is concise and intuitive.
I was mainly commenting on its configurability. Gnuplot lets you (once you figure out how) control everything; for example, the exact shape of the arrowheads in a vector plot.
Yeah, Matplotlib is capable, but it’s heavy and verbose. It’s fine as an API, but the syntax gets in the way very quickly.
My use case is not a scratch pad with one plotting window; it’s dozens of windows with regressions and stuff. Each window is a completely different context; some of them are short lived and some of them are used for weeks. Using as many notebooks is very impractical. For example, seeing where one parameter is going in one calculations is trivial and quicker than starting a notebook and setting it up. Works transparently over ssh, too.
I am more or less fluent in Matplotlib, because I work with people who use it and I need to understand whatever the students are doing (and some of them use Python and some use R, which is a whole other discussion). I just dislike it and don’t use it much for my things. Ultimately, gnuplot’s syntax for regression and complex plots is much more concise.
I any case I think it’s good intellectual hygiene to use several tools regularly, lest you end up stuck in a way of thinking, so I encourage students to try others. It’s also good to have discussions about these things that don’t end up in holy wars; we need to be curious.
You just want to plot the sine function, but first you have to import libraries, declare symbols (with a scary correspondence between strings and variable names), and finally plot the damn function.
I literally always have a Jupyter QtConsole open with one tab having Sympy loaded, and every single letter variable defined as a symbolic variable, and another tab with numpy; this is my constant daily-use calculator. In that context, it really is just "plot(sin(x))". It's not really anything more than having a terminal open with Gnuplot running, and no less elegant.
Edit: plus, if I'm plotting with Sympy it's almost certainly something I've calculated symbolically with Sympy, so everything is defined and ready, and it's much more elegant than switching to a separate program. For a one-off "what does function look like?" question, both these tools are far too clunky, and I'd use Desmos or GeoGebra.
Because the vast majority of Python programs aren't doing symbolic maths with Sympy. It's not a hack, and it's pretty trivial. I type "a," and press up, and run the line from my command history with all the letters in it. Sympy also has a submodule named abc you can import variables from, but I like defining them as real number variables so I don't get complex answers when they don't make sense.
Sympy is just a Python library, and one of the types it defines is symbolic maths variables, so you define Python variables just like with any other library, and then use them.
> Because the vast majority of Python programs aren't doing symbolic maths with Sympy.
And this, my friends, is why mathematicians will never feel at home using Python+libraries. Instead of having a programming environment ideally suited to the needs of math, you need to fit your math to the Procrustean bed of Python syntax.
That is what I wanted to say. The Python scientific ecosystem seems like it is written by programmers for scientists, while Matlab/Mathematica seem like they are written by scientists for scientists.
Eh, it's fine even despite your hyperbole. Applied mathematicians such as myself often use python without complaint. Setting up sympy takes no effort. Plus, #python on freenode.
It does not. I tried to replicate some symbolic computation code I wrote during my PhD in Mathematica in SageMath, and I just failed to get anywhere despite weeks of trying. I don't think I don't understand SageMath enough.
> I really dislike Matplotlib, so rendering is done in something else, usually gnuplot.
I'm glad I'm not alone. I was starting to feel crazy—how can something with this bad an API (Matplotlib) be this popular in the Python ecosystem which is known for its lack of verbosity and clarity? How can it be integrated with every other package instead of some sane alternative?
I tried Seaborn (a wrapper effectively), and it is way better for doing basic plots. But as soon as you get beyond that you're back in arcane Matplotlib territory. The best thing I could have done would have been to ignore its integrations and start with a better plotting API to begin with. The little bit of extra integration effort would have been worth avoiding Matplotlib. And there are several alternatives in the Python landscape.
No offense to the authors—it's clear they've done a lot of great work. But I think they got stuck with a bad API that they started with and it became so common-place that they were forced to continually be backwards compatible with something that really needed an overhaul.
seaborn is nice because it let's you do plots with one line that would take a page of code in basic matplotlib, but if you need to change one specific thing it might become really hard.
I honestly moved on to gui based plotting programs like grace or veusz, there's just a button for the things you want to do
Matplotlib is terrible (once you get to the point that you need to do non trivial things with it), that's why you use the excellent plotting library for python called "Bokeh"
could you give an example of an "non-trivial" thing you're talking about (i.e a few lines of code)? And how you solve it with "Bokeh"?
I agree that matplotlib's functional interface is somewhat messy, but that is somewhat historical, and stems from wanting to mimic how matlab works. I personally find matplotlib's OO interface both very powerful, and somewhat intuitive, once one gets a hang of it, hence I'm curious of specific cases where it fails for you.
See my other post in this comment chain. Matplotlib is not good with handling large (e.g. more than 100K) datapoints in 2D or 3D if you want interactivity or animations. Bokeh handles it like a champ!
For me? I care mainly about 2D and 3D scatter plots of large datasets. The GPU acceleration and automatic subsampling means that animated or interactive scatter plots of large amounts of data (for me it's language vectors) is super easy and fast rather than slow and crappy with matplotlib...
(I think matplotlib has an openGL backend that slightly improves but doesn't fix the issues with matplotlibs handling of large datasets)
Bokeh is also made to create embeddable, interactive plots for html/js. You can create quite sophisticated graphics with it from the backend alone. (We use it for web apps at $WORK)
I did all my work and wrote my entire biomedical engineering (specifically medical image analysis) thesis on octave.
In the beginning I had started with matlab because my lab mostly used matlab functions. Obviously it's not that I couldn't finish my work on matlab, but I found octave nicer to use, better publication-quality graphs, very friendly open-source community, submitted bugs typically fixed within a couple of days (which was not the case when I submitted bugs in matlab, of which I had reported plenty, particularly when it came to misbehaving graphics), interesting outlooks from studying its source code, ability to keep or distribute my code in the absence of a prohibitive matlab licence, etc.
It is probably true that it is not necessarily as quick as matlab or julia these days, however there is a big red flag when one looks at "benchmarks" online, which is typically that these are used in such contrived ways that a proper octave user would probably not consider as good octave code. (I remember this was also true of julia's benchmarks against python for instance).
Octave in fact is very powerful. Not to mention that to the serious user, much of its power comes from its incredibly powerful interface to its vast library of open-source c++-implemented functions.
As for the why octave and not python (or any other X) question ... honestly, I don't know. E.g. why Linux and not Windows? Honestly, both are fine. But, without having an explicit list of arguments, I just find linux is more enjoyable and gets out of my way, whereas on windows I find myself having to do extra steps and double-check things at every turn. Well, somehow, I have the same vibe when working on octave vs python or julia. But that's not to say I don't enjoy those other languages too. To me it just feels Octave is just ... nicer and gets out of your way somehow. It's definitely my language of choice for quickly trying ideas out.
I have my own answer at the end of the article. It is: use Julia if you’re serious; but Octave will serve you well if you’re already used to MATLAB or have MATLAB scripts and just want to do some numerical work.
I didn't see it anywhere, so: Octave start up speed is magnificent. If you have a larger shell script and just need to grab some eigenvalues, Octave can be as fast to startup, do its work and exit, as awk or grep would be for text manipulation.
MATLAB takes a while to start, Julia and Python need to spend a good amount of time importing/compiling.
As a MATLAB license holder, I'm currently migrating some MATLAB code to be compatible with both.
My license doesn't allow multiple computers, so MATLAB is living on my laptop. I'd rather run longer computations on my desktop system, which can handle these loads for a long period time without getting stressed thermally.
My use case is to run ground-truth code designed by my professor and cross-check the results generated by my scientific software. These MATLAB/Octave generated values are also incorporated to sanity check and CI pipelines to test developed software's sanity and computational integrity.
This is the main use case where I've used octave: working with someone of a group who has developed fairly involved Matlab codebase and we need to make it more scalable in some way, either for long running computation, reducing license costs, perform distributed memory work, or enable more robust parametric space exploration.
The Achilles heel here is that in Matlab, there's quite often a licensed toolbox dependency which makes portability more challenging. Every now and again I've seen pure Matlab code and the Octave transition is smooth. Sometimes there are so many toolbox dependencies that it just isn't even worth trying.
The luck in my case is, since we're testing either algorithms for formulations, most (if not all) code is written in pure MATLAB and has no toolbox dependency.
However, we're living in a matrix world. MATLAB is slow and Octave is even slower while working with matrices. I have no idea how to fix that part.
> MATLAB is slow and Octave is even slower while working with matrices.
I'm curious what you mean with this. Matlab was always fast with matrices (but my experience is now from 2 decades ago). The thing that was slow was loops. That is:
for i = 1:100
c(i) = a(i) + b(i);
end
would always be slower than this:
c = a .+ b;
The trick in my work was to always find matrix/vector operations that were equivalent to my desired loop and conditional structures. I could improve execution by 100x or more for many programs doing this.
MATLAB/Octave's main advantage over Python is that the syntax for manipulating matrices is way way way nicer. They also have a lot of toolboxes and maths related functions that would really take a long time to find/implement in Python.
MATLAB had another significant advantage over Python. Its plotting support is really really really good. Given how much time scientists spend making graphs it's hard to understate how important that is, or how much better MATLAB is at plotting than Python or Octave (or Julia).
I would actually say Python's matrix manipulation syntax is better, but Matlab's matrix literal syntax is much nicer and more minimal.
Having made hundreds/thousands of plots in each, I think Matplotlib's plotting is a bit better than Matlab's, especially for complex plots where you need control and have subfigures, etc. Matlab's 3D plots are better than Matplotlib's (which are fake-3D), but for sophisticated 3D visualisation Python has powerful options like VTK that Matlab can't really match.
> how much better MATLAB is at plotting than Python or Octave (or Julia).
To make sure I’m understanding you correctly, you’re saying Matlab is much better at plotting than Octave? I’ve only ever used the latter, so I guess that would be one reason to consider switching to the former.
I have always used Octave and never Matlab. The professor who introduced me to Octave some 15 years ago was quite the free software activist and did not even tell us that it was a clone.
Today, I am a heavy user of Octave's linear algebra algorithms for large sparse matrices. I also use Python/numpy for other things, and sometimes for linear algebra too (due to the insistence of my coworkers), but it is much less pleasurable and quite annoying. Also, the linear solvers in scipy are sub-par compared to the state of the art solvers in Octave. Once, we found a well-conditioned 6x6 system that linalg.solve failed to solve!
As an aside, I have never used Octave for plotting, and I hate the gui interface; my use case is 100% non-interactive, using scripts.
I wouldn't call it a clone, anymore than I would call, say, Linux, a "clone" of Windows for needing to have a similar feature-set to appease newcomers. Much like linux vs windows, octave and matlab started life as completely different things, but octave being the 'underdog' and having a similar enough syntax necessarily tried to match matlab's syntax, to the extent that they pride on compatibility (and treat non-compatibility as 'bugs'), but extend the matlab language to include other features.
Now that both projects are mature, I think it's safe to say that matlab has 'borrowed' a lot of octave's nicer features over the years too (though obviously it's not something that can be publically admitted), like implicit broadcasting, command-line functions etc.
Obviously, neither matlab nor octave are strict subsets of each other. Also, I get the impression that matlab has started taking octave's compatibility very seriously in recent years, and has taken non-trivial steps to break it (annoying, but totally fair, in my view), which octave has resisted for the sake of backwards compatibility. Ironically this often makes octave a more reliable base for runnin older matlab scripts, than matlab itself. (e.g. in the same way that Wine is more reliable for running Win98 applications than Windows 10)
> I wouldn't call it a clone, anymore than I would call, say, Linux, a "clone" of Windows for needing to have a similar feature-set to appease newcomers. Much like linux vs windows, octave and matlab started life as completely different things, but octave being the 'underdog' and having a similar enough syntax necessarily tried to match matlab's syntax, to the extent that they pride on compatibility (and treat non-compatibility as 'bugs')
Nobody calls Linux a "clone" of Windows or vice versa, because even when they implement the same features, in the vast majority of cases the command syntax, APIs, etc, are radically different. There are a few commonalities, but when they exist, they are almost always because both have decided to implement some pre-existing standard. Even when Windows borrows features from Linux/Unix, it normally changes the API in incompatible ways – Windows 10 added pty support copied from Unix and Linux, but came up with an incompatible API to do it (CreatePseudoConsole)
It is the fact that Octave quite intentionally copied a lot of Matlab's syntax which leads it to being called a "clone". If they hadn't done that, nobody would apply that term.
> I think it's safe to say that matlab has 'borrowed' a lot of octave's nicer features over the years too (though obviously it's not something that can be publically admitted), like implicit broadcasting, command-line functions etc.
When Matlab "borrows" features from Octave, does it intentionally choose the same syntax, or does it implement the feature in an incompatible way? The former would constitute cloning, the later would not.
Signal processing, 15 years using Matlab/Octave and 10 years using Python. It's easier to prototyping signal processing algorithms in Matlab/Octave. Some important functions in Scipy perform much worse than Matlab/Octave.
In several cases over the years, I’ve inherited matlab code and tried to run it on octave. Never worked, once. There were always just one small missing syntax, function, edge case of handling filenames...
Once I inherited code written for octave. Did its job, worked like a charm, mostly. The CLI interface was clunky compared to typical shell tools so I had to do some shell wrappers and incantations to automate what I wanted. I don’t know if this is due to the author or to octave but I suspect its focus is on interactive use to the detriment of developing programs.
I keep a jupyterlab docker container running at all times on my win10 laptop, with windows-home mounted. Instantly available notebooks from my browser - works like a charm for interactive use.
I much prefer python since it lets you move continuously from one-off hack in a notebook cell to a web scale application, parses any weird file, serves web content in 3 lines, etc.
I use it often. Even after 20 years of using numeric/numarray/numpy, I still feel more productive in Octave and Matlab. Mostly time series analysis, signal processing, image analysis. Occasional modeling and simulation work. I think for me it’s that octave does it’s job well and doesn’t try to do other things. Python grates on me occasionally since it’s libraries seem to lack focus and try to be too much for too broad of an audience. I like focused, simple tools. I do use Python, but not as my sole tool. I don’t understand he mindset that one tool/language should do everything. Easier for me to learn many languages than one language and have to learn many independently designed libraries.
Matlab never feels a particularly elegant system to me, and most Matlab codebases I have seen are huge messes, with not much structuring and organization. In that respect I prefer python, that it naturally seems to lead to saner manner of organizing code, and also being very helpful in massaging/parsing/reformatting data into forms more amenable to processing.
I can confirm this, but, Conway's Law suggest that this reflects more the user group that the language. Matlab provides all the typical suspects for structuring codebases (packages, classes, functions, globals, etc) but look what users do with it. This suggests simply that research groups " communication structure"s are huge messes.
I wonder how much of this is due to the availability of the dot-operator syntax beside the extensive libraries and the easy extensibility (just create a new function in the Matlab search path and Bob's your uncle - no further installation or registration rituals needed).
Here is my story. We used Matlab, but then the polling of the license server got more and more aggressive(or we were unlucky). Just when you want to work on the 8h flight the thing popping up and saying 'need to connect to the internet' is not fun. Now we had a volume license(I think). And it needs server access every 10 times you run a script. Try making software which wants to use the Ethernetport with something else, it is just annoying. So you pay a lot of money and get annoyed...
Octave is slower than Matlab (at least last time, no loop acceleration), and no GUI library. So we went straight to python.
To get fast you need to vectorize. I found that vectorizing algorithms in Matlab makes them unmaintainable (maybe I am not good at that). In python this is much smoother.
> I found that vectorizing algorithms in Matlab makes them unmaintainable. In python this is much smoother.
Are you using numpy? If so, can you give a concrete example?, in my case the opposite seems to be true. The numpy notation seems to be much clunkier.
Apart from that, this sentence:
> To get fast you need to vectorize.
describes a very sad tragedy of numerical computing. It makes no sense that in 2021 interpreters for scientific languages are not able to optimize loops. The so-called "vectorization" should be a non-issue in a modern interpreted language. The running time of calling "C=A*B" and that of the triple loop to fill the elements of the matrix C should be identical.
I hope I remember these things correct. Let's assume you have two 3D arrays and you want to form the point wise product and sum over the middle index, you can probably write sum(a*b, 1). Anything more complicated there is numpy einsum (check it out) https://numpy.org/doc/stable/reference/generated/numpy.einsu...
Letme know how these things can be nicely done in Matlab.
One problem I had in Matlab is some vectorization requires to permute the indices, but this is expensive if your array is hundreds of megabyte.
I use it to do general linear algebra scripts and as a linalg calculator. The language is imo much nicer at this than python, and it also starts up way faster.
Also, symbolic calculation is a lot less cumbersome than in python!
I actually went the other way from Octave to scipy, numpy and matplotlib. This really long ago though - around 2007. As a programmer moving into quants needing to process huge amounts of data python/matplotlib seemed a much better fit for me. It also enabled me to run multiprocess number crunching on my 8-core desktop at home. Octave would be able to use just 1 core, I could code the python scripts to use all 8.
Octave was really good to prototype and enabled me to get somethings done really quick. But once I got to know the python libraries better it just seemed easier. I could do all my data processing and quants in a single language.
I'm sure much has changed and was actually quite sad when the original author of Octave (John Eaton) mentioned in 2017 that he was unable to maintain it.
I've lost touch on Octave over the years and genuinely pleased to see that it is still being actively maintained. I think its time for me to see what I've missed in the past 13 years.
I use for it for the various RF/EE/Controls related matrix stuff, as others have said it is often quicker to use to do some sanity checks even though at work we have actual MATLAB/CST Studio etc.
Using Octave over matlab is preferable for me for the same reasons many people use GIMP over photoshop. I use octave for things that are reasonably self-contained, like the metaphorical editing of a single image. I like Python over octave for the kinds of uses that might cause someone to use python over GIMP for image processing, to extend the metaphor.
I use it from time to time. Octave performs very well to the point, where you have several encapsulated for-loops, where Matlab is several times faster in my experience.
I don't use Octave, but I have a little in the past, and I have to teach students to use Matlab (2021 should be the last year of that before we switch to Python though), and I've done a lot of numerical and other programming in Python and Matlab, in each for ~20 years.
In my opinion Matlab is a terribly designed language that has haphazardly grown features by accretion. Anything other than matrices and vectors is far more difficult than it needs to be. Therefore I consider Octave a bit of a lost cause; I think aiming for compatibility with terrible won't lead anywhere good.
Actually Octave has one useful feature Matlab is missing, operators +=, -=, etc., so perfect compatibility is not exactly the goal.
It seems to me the only reason to use Octave is if you happen to have a large legacy Matlab code base that doesn't depend on any of Matlab's proprietary toolboxes (unlikely, as those toolboxes are one of the main reasons people use Matlab).
I believe Python is superior to Matlab/Octave in almost every way. I think Matlab/Octave has two or three very small advantages over Python, and one larger but very niche one:
1) Matlab/Octave's matrix literal syntax is nicer and less verbose ([1 2; 3 4] vs. np.array([[1, 2], [3, 4]])). Irrelevant in most cases, as most substantive programs will have few literals in them. Note that those missing commas are a frequent source of bugs, too, e.g. [1 -2; 1 - 2] is an error, so really the Matlab/Octave is better written as [1, 2; 3, 4].
2) Because Matlab/Octave is primarily for numerical calculations, you don't need to import libraries to get started. Not a big deal as I always have a Jupyter QtConsole running with Python, Numpy and Sympy ready to use.
3) Basic 3D plotting in Matlab is still a little easier (Python is better for complex 3D plotting though). Not sure what Octave's story is for 3D plots.
4) The aforementioned proprietary Matlab toolboxes, if you happen to be working in one of the narrow niches they're good for. Python has similar large library advantages in other (and more) areas. Octave has some equivalent open source library bindings, but that's the biggest incompatibility with Matlab.
20 years ago Matlab was pretty good, but it's barely changed since then, and Python has long overtaken it in most areas. Octave seems to have caught up with Matlab on the GUI front (but Jupyter Notebooks are much nicer for many things (Octave can do Jupyter too), and Python has a selection of mostly equivalent IDEs, e.g. Spyder). Python, being a general purpose programming language, can do all the non-maths things surrounding the maths much easier. Data input/output, data processing, string processing, network access, etc., as well as UI things like Jupyter Notebooks. In my opinion Python's also better at quite a lot of maths stuff, like large integers, arbitrary precision, symbolic algebra, higher dimensional arrays, or dataframes with Pandas. I also much prefer 0-based indexing and half-open ranges.
Matlab's licensing is quite problematic. Licenses for business/research use are incredibly expensive, and licenses for student use are relatively cheap. I consider it unethical to teach students to use a proprietary language that will cost their future employers thousands, but that's been Matlab's sales strategy for decades. Switching to Octave is an option for teaching and some business/research use, but switching to Python, with its much bigger ecosystem, seems more sensible to me (unless you have a big existing Matlab code base).
I agree wholeheatedly. Python is everything matlab the language could hope to be and more, if you just want to crunch matrices python beats matlab as it's own game (just the broadcasting features in numpy alone are an amazing step up from matlab's approach, let alone trying to ingest data which isn't a csv). But, some of those toolboxes are pretty damn good and don't have an equivilent in python. For example, if you're doing almost anything with control theory then there's some pretty killer toolboxes that don't have any real competition, especially in the open-source space (there's some basic stuff but it's not particularly usable).
I have never understood why MATLAB hasn't introduced proper broadcasting like APL and its successors. My problem with Numpy is its awkward notation/syntax when compared to Matlab/APL.
“ 20 years ago Matlab was pretty good, but it's barely changed since the “ How do you define “barely” looking at just changes from 2015 to 2020 in just core MATLAB shows at least the following changes.
It's important to be aware this says more about you and your personal preferences (and possibly experience and skill in either language) than about octave and its overall value-proposition as a project though.
If I'm allowed to offer a (non-opinionated) counterpoint, I have almost the opposite experience and opinions to you (both in the positives and negatives).
Background: I have been working daily with python for the last 3 years in a scientific field. Before this, I worked daily with octave for about 3 years in a similar field. I'm equally happy and skilled in both languages.
So, to counter:
point 1: I mostly agree, though I think the 'frequent source of bugs' point is slightly dramatic. If anything, to me it feels like the numpy system is much more conducive to bugs (e.g. given all the acrobatics one needs to do to ensure compatible ranks).
point 2: You absolutely do need to import libraries in octave. And that is generally a positive thing for a number of reasons, not too dissimilar to python. However unlike python, the octave team maintains relatively strict control and quality-processes for 'official' and 'endorsed (third party)' packages. This has an advantage over python where for each popular package there are 100 clones and variants and poor or unfinished packages, sometimes even phishing packages.
As for 'packages' in matlab, it's true you don't need to 'import' toolboxes, but this is only because of matlab's business model which sells them as add-ons. You can think of 'enable in licence' as an import of sorts if you'd like.
point 3: Octave derives its plotting syntax from matlab, and for the most part it's very intuitive. I always felt matplotlib is a poor attempt at replicating that syntax, but thankfully there are alternatives.
point 4: It's true that octave's biggest compatibility problem with matlab is in the 'toolboxes vs equivalent package' case. Which is partly why octave has been providing bindings to equivalent python packages as a workaround (same as Julia). One of the more successful examples is octave's reimplementation of python's sympy package, to create a symbolic package using matlab's api and simplicity of syntax, but calling python's sympy under the hood.
As for the "python has more stuff", this is purely the networking effect. And while obvioulsly the networking effect is not a trivial issue for any language, as an open source project it is always a matter of time, which is not something that can be said for something like matlab. And I'm sure that octave's rising popularity in recent years through its promotion in things like Andrew Ng's introductory course to machine learning, can only lead to an increased engagement with the language, and we can expect lots of good packages to crop up as a result.
point 5 (not labelled as such). I don't think the "python > matlab/octave" mantra is necessarily true. It's just personal opinion + engagement. It is certainly true that python has more users, but there are many reasons for that which cannot be reduced to a simple "python > matlab/octave". As for jupyter notebooks, I really dislike them and much prefer matlab/octave's 'publish' for producing straightforward html reports. But, again, that's just personal preference. Also, I much prefer 1-bassed indexing and closed ranges, as I find them much less prone to bugs.
I agree about the prohibitive nature of Matlab's licence, but I do not necessarily agree that the "natural" choice is therefore python. Surely the decision is more multifactorial than that. After all, if it's ecosystem you're after, why not julia? or c++? or java? In my view, octave is a reasonable contender regardless of an existing matlab codebase. It is a friendly language, with a big open-source community, excellent math and graphing facilities, and can easily interface with other languages if you really need that extra pizzaz on occasion, without the overhead that comes from needing to have your whole project based on those languages.
I'm hoping the next generation will move off of TI-8x calculators and into things like Octave for grade school use.
There was a point in my education where I had mastered my trusty TI-83; I knew the purpose of every single function and how to use them. But then, I started running into problems in the real world that required more than 32 KB of memory to solve. When I moved to a laptop I had to relearn all of that knowledge again. Haven't touched my TI-83 since.
It would be nice if the tools we learned how to use in school could also be useful in solving our problems after we graduate!
I wish they'd rather use python or Julia. GNU Octave is great. But as a clone of Matlab it's constraint by compatibility and doomed to always be second* and at worst an enabler for Matlab. I'd rather break the dominance that Matlab has in many fields and replace it with free software.
* There are a few aspects where it is better. For example I believe the variable editor introduced one or two releases ago is nicer as it allows inline evaluation.
> rather use python or Julia .. break the dominance that Matlab has in many fields and replace it with free software
I still think Octave has a niche to fill for students and HPC where software engineering (package management, compilation etc) is of insufficient concern.
At least in the US, high school education still and probably will use TI calculators for the foreseeable future. They are a long existing standard and very practical for that environment. However, most AP classes do allow the use of the TI-Nspire which is a much more capable platform than the TI-8x series. And even in that series, the TI-84 and variants are much more popular now.
At the college level, at least for engineering programs, at my school there was a pretty big emphasis on doing a lot by hand besides trivial stuff like addition and multiplication. The extent that we would utilize calculators seemed very minimal. Most of the degree programs including teaching students one or more of Mathematica, matlab, octave, and R. But I would say it sounds like the depth you had for the TI-83 doesn't really exist in the modern education, rather it is a more broad use of multiple platforms.
Not sure what kind of lobbying & campaign contributions have built the TI stronghold on the education market, but highschool kids today seem to use pretty much the same TI-85 that I had in the 1990s, except with a more colorful shell.
Was in high school in the 2010s and I had to buy a TI-84. They have a version with more storage and a color display but it’s still that same calculator all these years later.
Matlab licensing is prohibitive for everyone in a team to have one and WAN licences are 4x the cost of a seat, so we tend to have code capable of running in both octave and matlab in general. The model is all users can use octave for lower level / common code components and it works finw, and then the system level guys who really require matlab for its toolboxes can also use them and that common code also. If it was not for the advanced matlab toolboxes (and some key engineers who know only matlab) we'd probably have moved to python or Julia.l to get away from this two tier use model
I’m curious, not saying either option is bad.