Last time I tried Octave it was several times slower than Matlab. Why use Octave instead of R, Python, or Julia? There is nothing Octave/Matlab can do that they can't. And anybody needing Matlab surely can afford to pay the licence fee?
On top of that Octave is not 100% MATLAB compatible, especially if are into more complex projects with toolboxes. I wasted tons of time try to do a college assignment in Octave before turning to MATLAB.
My experience: you get code from a fellow researcher using matlab, and nobody in your institute is using matlab.
Getting approval for licenses is much harder than you'd think. The money is the smallest part.
In the end you just want to run the code once or twice, most of the time octave is going to be enough with zero or minimal changes. Cannot count the amount of times octave saved the day.
I've tried this many times in my career and it unfortunately almost never works out of the box for me for anything but the most trivial examples. Either they're using some library or toolbox that Octave doesn't have, or they've used it in a way that isn't 100% compatible with Octave.
I can believe this, the status of the various libraries/toolboxes is not all made equal so YMMV depending on the field.
We had a few cases where this was the case involving the signal processing toolbox for example and couldn't reproduce the same results. In such cases we just refused to participate in the consortium.
In my old field we were mostly using R. If there's no active use of matlab, it doesn't make any sense to license it for a single collaboration. By the time you need it again, the license would be expired. And this completely ignores the "how do you want to run it", which for us involved a linux-only cluster. It's literally trashing money and time.
Commercially-licensed software is a true pain for research and collaboration, it doesn't matter if it's any good or not.
Commercial software is indeed a pain unless your entire organization uses it. If you're the one person in your organization that needs commercial software "X" it can be very annoying. First of all it's a major pain for the purchasing team, then your IT folks or yourself have to get it to run and there seems to always be some library or DLL missing or something.
Missing the point by a country mile. No-one complains about AWS licencing because it's easy: create an account and pay for what you use. Most commercial software is a pain because you have to keep track of licenses.
Oh, and working with Open Source software means I get paid approximately double what an equivalent Microsoft specialist does. Learning Linux has been the biggest payoff of my career.
I didn't. One-for-one products like AWS instances lend themselves to less obtrusive enforcement. One-for-many products like desktop software require pain-in-the-ass key management.
You're an IT guy for a [insert commodity here] manufacturer. Nothing wrong with that. When the IT itself is what's being sold, you have to protect your product.
When tied to academic research this has bigger implications.
Reproducibility is difficult or impossible to assess when there's no source, and it also requires higher barriers to entry (= money). The output of that research will also be tied the commercial license: academics can often get better offers, but you as a user are going to be outpriced.
I'm biased for sure, but I'm a deep believer in open research. The output of what I do/did should be free for everyone.
R being fully open and free is a big part in what it made it so popular in research.
Agreed. Software that is free for academics might be $10,000/year for an industry user with a ton of red tape to boot. I hate it, but they have to get the money from somewhere unless it's fully open source. Sometimes that works and sometimes it doesn't as well.
As it sits, they like to get users hooked in college and then they're less likely to ever switch.
First up, as the gp explains, the cost isn't the biggest hurdle.
Secondly, research institutes have little money. For example: you may think the world has been on HDMI since somewhere around 2010 or so. Think again. End of 2021, my research institute replaced their monitors, which meant i no longer was using VGA out on a daily basis.
(Computers typically are on a 3- or 4-year replacement cycle; monitors, projectors, keyboards, etc. aren't. )
If the code is only a few pages, I would expect it to be rather easy to translate for most cases.
Mathematica is a rare exception as it is generally used in a much more functional programming esque approach than the imperative/OO style common elsewhere. I find pushing data to black box Mathematica functions to be very simple (and they have stuff for practically everything), but some very simple stuff eludes me due to the language model.
So I guess your point stands (especially if it's a large code base).
We were interested in using a library that was originally written in MATLAB and had also been ported to Python. First thought was obviously to use the Python one, but it was unbelievably, unusably slow. I fired up Octave (have never used it before) and got the MATLAB equivalent working, and it was blazing fast. I'm not a MATLAB programmer and will not learn it; I just need to call this one library.
Yeah I can't really see a reason to use Octave. The Matlab language is mediocre at best. People use Matlab because it has a great IDE, great plotting support and rock solid toolboxes for just about everything. Yes Octave really only duplicates the language.
The Octave IDE is okish, but the plotting support is really far worse than Matlab. Honestly no open source plotting tool I've found (and I've looked a lot) comes close to Matlab which is why I eventually ended up just paying £125 for it, which I think is a very reasonable price considering it is a perpetual license and very niche software.
I wish there was some CAD software that had such a reasonably priced hobby use option, but SOLIDWORKS is $99 per year, Alibre has a cheapish option but they slightly annoyingly shift a lot of features into the £1000+ versions. Probably the best option at the moment tbf (other than piracy).
Yes, once you understand the idea of a "grammar of graphics", ggplot is really the best and most flexible plotting system available. There's a reason that people have tried to clone it (with varying degrees of success) as libraries for python and Julia.
Can you zoom in and out on the R plots? I've used ggplot2 and it didn't seem heads and shoulders above any of the other major tools (Matplotlib and the other Python plotting libraries or Matlab) and was way behind what you can do with .NET.
> I wish there was some CAD software that had such a reasonably priced hobby use option, but SOLIDWORKS is $99 per year, Alibre has a cheapish option but they slightly annoyingly shift a lot of features into the £1000+ versions. Probably the best option at the moment tbf (other than piracy).
FreeCAD as a general purpose CAD software is not that bad. I've used it in combination with KiCAD that we use at our company to design PCB and for our needs is more than enough and works fairly well.
For small projects, Octave is easier to get started with because Octave/Matlab functions tend to be designed and documented more pragmatically. You can look up a function and start using it right away.
In Python and Julia, things tend to be documented more "bottom-up". Which is good for large projects, but tends to get in the way when you're just trying to get a small script to check one result or get one plot. (I don't have as much experience with R, so can't say which direction their docs lean towards.)
For Julia or Python one has an option to look at the source as the ultimate documentation. It is not ideal, but good documentation is expensive both to produce and maintain.
It depends on the function. For basic stuff, Matlab uses MKL. MKL is available no-cost.
You could use LD_PRELOAD or LD_LIBRARY_PATH to get Octave to link MKL (or I’m sure you could compile the whole thing for MKL, but LD_PRELOAD let me use the disto version and I’m lazy). You also may have to tell MKL to use GNU threads. I’ve done it, got decent speed ups with a 6 core AVX2 system, so I guess something more recent could be even better.
Because a lot of legacy stuff is written in Matlab. And Octave is not so much slower than Matlab. matlab’s killing features are all those libraries for everything.
And I for example don’t like using matlab - it’s not free (as in freedom), it’s very bulky, GUI is slow and heavy, there’s no way to use it as a console app in linux afaik.
I used to do that too back when I used MATLAB professionally (also circa a decade ago), but I found with each successive release it worked less and less reliably as use of Java spread through MATLAB's internals.
I've used MATLAB my entire professional life, never met a user not using the IDE. This is amazing to read. Perhaps a Matlab central article is warranted to describe this setup.
I bet that someone like Ned Gulley might be interested in writing a MC blog entry on that subject! He’s super nice/approachable, and can be emailed at his contact info on his profile*
The original generation of MATLAB creators and developers like Cleve tended to come from an academic UNIX/mainframe/HPC type background, and so they were big CL users and lived in vim/emacs. And that carried over to a lot of the programmers working at The MathWorks to this day.
For a lot of engineers I worked with who hack on the “guts” of the products (the language parser/interpreter/JIT, math internals, computational geometry and stats libraries, etc), the only time they’d fire up the IDE was at the pre-release bug bash every six months lol!
In my original post, saying the “majority” of TMW ran this way is probably an exaggeration, but a “sizeable minority” would be true.
Maybe Ned could run an internal poll and include those results in the blog post :)
I prefer that behavior. Integers should behave like integers, if you want the floating point division you should write 2.0/7 . Of course now that we have distinct / and // its less of a problem but then it becomes a problem of which behavior do you expect more often, integer or float.
The difference (as I see it) is that Matlab/Octave are more easier to use for a person that doesn't know a programming language, such as a math student. While to a programmer Matlab language doesn't make sense (array starting from 1, syntax, a multitude of functions in the global namespace, etc) to a mathematician it does since it more resembles the language of a graphical calculator (that was what Matlab started with).
It's true that Python with the use of Jupyter notebooks is getting closer to be a simple to use tool, but you still need to know some programming to use it.
This so much. Running scripts in Octave and being able to inspect every variable makes debugging so much easier when you are new at programming. Especially with the GUI and variable explorer.
Well, when you have thousands of Matlab functions you wrote over a decade, you would rather use Octave instead of rewriting them in Python. I also suppose that Octave is slower than Matlab because OpenBLAS is inferior to MKL.
Well the licence fee of matlab is pretty massive (2500€ / user, and then each toolbox is 500 or 1000 euros each..), and then you have do deal with activation issues if you happen to switch computers quite often. Octave is a good alternative to run your matlab code if you don't need the "fancy" matlab ide.
The octave interpreter is slower than matlab, but that's because there is a JIT compiler in matlab. octave is still a good tool in my opinion.
The one thing I miss from Matlab's IDE is the ability to properly rename variables. Octave lacks this (not sure about this new release) and I so far haven't found a Matlab/Octave LSP that can be used for other code editors.
I use Octave daily, for many numerical tasks (and also python and julia). It has some advantages with respect to Python:
1. The sparse linear solvers in octave are considerably more performant than those available in a default scipy install.
2. No need to import external libraries written in other languages just to multiply two matrices.
3. Translating a formula from the blackboard to octave is really straightforward. This is often not the case for numpy.
As for julia, the base language is even better than octave. However, it is not as useful for one-off scripts due to the slow startup time. You can use octave as a calculator for your shell scripts. For instance, one day I had to warp a collection of images by a collection of affine maps; the affine maps were the product of two matrices stored in individual files. Thus I wrote a three-line shell loop that called octave for each file and did the deed. The loop processed 200 files in five seconds (even without parallelism). In julia this would take a few minutes.
I would encourage you to try this again on Julia 1.8. Startup time has improved a lot. A few minutes seems way too long to process some images. Even plotting should happen within 20-30s now.
Will try! The image warping was done by an external program. Julia was used just to multiply two matrices of size 3x3 for each image in the collection. Launching the interpreter took almost a whole second, the rest of the computation was instantaneous.
Working this way is pretty common for small tasks. As has been suggested, Julia 1.9 is a lot faster than it was before. I find it's more like 4 seconds than 0.5 seconds, though.
With plot.jl as
$ cat plot.jl
using Plots
x = range(0, 10, length=100)
y = sin.(x)
plot(x, y)
Plotting is a complicated beast. If you just want to multiply matrices, there's no "using" statement and you get sub-second running times. Still geologically slow, but at least somewhat manageable.
> 2. No need to import external libraries written in other languages just to multiply two matrices.
I suppose I maybe get the "no need to import external libraries" thing, 'pip3 install numpy' is technically an extra step that wouldn't have been necessary if the standard library contained a decent matrix module.
But why do you care about the "written in other languages" part? That has literally never caused issues for me with Python. Especially something as popular as numpy just works across all platforms I've tried (x86_64 Windows, Linux and macOS, aarch64 Linux and macOS). Do you frequently encounter issues which are caused by the Fortran portion of Numpy's source code?
> Do you frequently encounter issues which are caused by the Fortran portion of Numpy's source code?
No practical issues at all. The problem is not the pip install numpy that only happens once, but the import numpy that must appear on every single one of your programs. I interpret it as a permanent reminder that numerical computation is not natively supported in the language, and that we will always be foreigners in there.
The difference between Matlab/Octave and Python/Julia is the difference between Windows and Linux. Windows is a product that is designed to get out of the way, so the user can do what they are actually interested in (watching movies/doing business tasks), and the Linux is constantly in your face about your freedoms and which combination of libraries and packages you need [1].
To learn and use Matlab/Octave requires learning very little programming or the intricacies of programming. To use Python, one has to figure out packages and libraries and object-oriented programming. To even use Julia, which is much better, one has to think about, how can I write my code to avoid the initial JIT delay.
When I am thinking science, I don't want to think about any of those things. I want to think about science and science alone. The intricacies of the programming language should not bother me.
>Windows is a product that is designed to get out of the way,
I get your drift but I think your analogy is opposite. I absolutely could not function in windowsland because it's constantly getting in the way of what I want to do whereas Linux just works.
Maybe because you have a niche Linux uses and very specific distro. On Windows, there are no distro and no gui manager. Everything works. I have been to old folks home teaching computing. From starting Windows to surfing Internet to print out take less than 15mins. The teaching is very straight forward. The same for Linux which I taught a bunch of teenagers are nightmare when they bring their own laptops. So many drivers missing and breakage here and there. The irony is that wsl actually save the day because it just works. I can setup a scenario where closing my eyes and select 25 brands and install python anaconda and minecraft to just work. I can bet 100K usd you cant do the same in the same amount of time on Linux of ANY distro of your choosing. Simply you are damn good with your specific Linux and your niche habits doesnt translate to majority computer users worldwide. Take building controls very specific niche, Linux equivalent GUI server simply rare and usually lack the full feature of Windows equivalent. Yes, one can run Win VM in Linux to get it done, but boy that is getting complicated for engineers working in that field.
I dunno, there was a time about 10 years ago when drivers on windows were a nightmare, but Linux just worked. I mostly use stupid Linux distros (system 76) and not even installing the Linux (just as one usually doesn't install windows).
You should use it because it's a super cool language, it's open source, and if people used it more to develop the package ecosystem a bit more, it would easily end up trumping all the others you mentioned.
Anecdotally, I used Octave during my PhD and it was a breath of fresh air (where matlab wasn't, for reasons I cant quite explain myself tbh).
I have also used (and still use) R, Python, and Julia. Octave is still the language I go to first to get things done fast.
Why is that a bad thing? I don't use matlab or octave, but I'm glad there is choice. The ecosystem would be much worse if everyone just stopped working on less fashionable projects. I'm happy to see that people are still working on this.
From a hiring perspective, I'd like to know how bifurcated the Python skills employment ecosystem is from the Matlab employment ecosystem. Is Python all the ML & dstascience folks, and Matlab is all the 'true-blue' mechanical, aerospace/automotive, & controls engineers?
All else equal, is having either software package on a resume an inadvertent signal to the hiring manager that you're only in one ecosystem / community and not the other? Strategically should a job seeker emphasize experience in one of the packages for roles in one ecosystem (while downplaying/hiding skills in the other), and the inverse for facing comparable roles in the other ecosystem?
> Strategically should a job seeker emphasize experience in one of the packages for roles in one ecosystem
If you're on the data science job market, you should know Python because that's basically all the jobs right now (the Python vs R debate was relevant 5-6+ years ago and Matlab was never that big). I don't know enough about the engineering job market to comment on it.
I just hired a R engineer, so not that tiny. For a data science job with a lot of stats and math. R still beats Python for stats/data science programing. In my market, R people have more math/stats than Python applicants,
A lot of that classical engineering stuff is moving to Python. At least that's what I'm observing at uni.
The last real stronghold of Matlab is controls engineering, because dynamic systems and simulink are just a good match, but even there sympy is used for the symbolic calculations.
Generally speaking most data science stuff appears to mostly be Python with a little R and then a very very small amount of many other ecosystems (e.g. most of the elite banks do a lot of kdb+ in addition to a lot of Python).
In engineering fields, it all just depends. Control systems (via Simulink) is still pretty rooted in Matlab last I checked and is a lot better documented than Python. In power systems (my field) most "programming" is either at the application level (like C, C++, or Fortran) if you're a vendor and at the scripting/API level with 95% of that being in Python and the other 5% probably being something like C#, Java, or shell script. All data analysis is either in Python or SQL. SQL is better if the data is already in a database. We deal with such large quantities of data that pandas usage is relatively rare though. It's more common to use a Python script to push a bunch of data to a SQL database to then do analysis.
I do know some places that do post jobs with Matlab as a requirement and those are mostly the little R&D sections of those companies that tend to hire workers from academia that haven't been exposed to Python as much as Matlab.
Comparing the two language ecosystems (what matters), I'd say that Python is much easier to do general programming in and ML, but Matlab has easier and definitely more consistent facilities for charting and graphs. I prefer Python for a lot of scripting work, but Matlab is still pretty nice if your company can afford a license. I wouldn't want to just be stuck in Matlab, but there are plenty of cases where I might reach for it over Python if available.
At the end of the day though, they're both scripting languages and aren't very hard to learn. Any sane hiring manager should accept candidates with experience in either one as long as they don't need to hire a super expert to lead a big effort on day one.
Matlab is still heavily used in sensor development (a good part because of the simulink aspect). For reasons I don’t understand, you’ll notice that Matlab’s camera calibration is better than OpenCV and more repeatable hence why a lot of major camera users still use it.
Programming in untyped python feels a little wrong everytime i do it. Functools and the typing module are nice but there are still so many untyped or dirty dependencies with unexpected behavior imo. A bit of a mess.
I find it curious that people against paid software and supposedly proponents of open source software have no problem using and supporting tools that directly copy paid software, such as that found in Octave, matplotlib, and Julia, which likely breaks licenses. For example, you will find algorithms in Julia directly copied from open source bits of MATLAB (at least that was several years ago). I make the assumption that Octave does the same, beyond the API copying. Isn't that against the supposed philosophy of GNU software?
Am I missing something? I just don't understand how to reconcile blatantly copying tools, at least the APIs are copied, with the apparent philosophy of open source software, particularly GNU software.
They tell you what to do with your own software, but they are embarking on basically creating a free (as in price) version of paid, proprietary software. Even if there are not direct violations of MATLAB licensing or IP claims, it feels the two approaches are in conflict.
This is an honest question, because it isn't clear to me what the resolution of this apparent conflict is. Maybe someone has some insight.
I work for a large corporation, and a few people around me use Matlab. I don't, and I don't know Matlab (I used it for just a bit in a numeric analysis course 22 years ago and don't remember much).
Anyway, how reasonable would it be for me to tell them "Try to run your code with Octave"? i.e. how likely is this to succeed?
Depends what they're doing with it. If they're depending on some particular toolbox including its advanced functionalities, it'd be a tough move. If they only need base Matlab and maybe some basic features from some toolboxes, Octave probably has them covered.
Last time I use Octave for my NLP class assignment, I have to create some sort of Matlab stub to make it work since the scripts from the materials provides has many 'version checks' inside, besides that it works perfectly. And I encountered some compatibility issue the other way (Octave back to Matlab) because the professor uses Matlab to run the code we submitted to grade them.
Good choice if you don't want the whole Matlab monstrosity on your computer, but still have to deal with some itty bits.
105 comments
[ 6.1 ms ] story [ 165 ms ] threadGetting approval for licenses is much harder than you'd think. The money is the smallest part.
In the end you just want to run the code once or twice, most of the time octave is going to be enough with zero or minimal changes. Cannot count the amount of times octave saved the day.
We had a few cases where this was the case involving the signal processing toolbox for example and couldn't reproduce the same results. In such cases we just refused to participate in the consortium.
In my old field we were mostly using R. If there's no active use of matlab, it doesn't make any sense to license it for a single collaboration. By the time you need it again, the license would be expired. And this completely ignores the "how do you want to run it", which for us involved a linux-only cluster. It's literally trashing money and time.
Commercially-licensed software is a true pain for research and collaboration, it doesn't matter if it's any good or not.
Commercially-licensed software is a true pain
I'm sorry the fruits of our labor don't come free. Some of us enjoy resort vacations.
Oh, and working with Open Source software means I get paid approximately double what an equivalent Microsoft specialist does. Learning Linux has been the biggest payoff of my career.
You're an IT guy for a [insert commodity here] manufacturer. Nothing wrong with that. When the IT itself is what's being sold, you have to protect your product.
It's a big world out there kid.
Reproducibility is difficult or impossible to assess when there's no source, and it also requires higher barriers to entry (= money). The output of that research will also be tied the commercial license: academics can often get better offers, but you as a user are going to be outpriced.
I'm biased for sure, but I'm a deep believer in open research. The output of what I do/did should be free for everyone.
R being fully open and free is a big part in what it made it so popular in research.
As it sits, they like to get users hooked in college and then they're less likely to ever switch.
Secondly, research institutes have little money. For example: you may think the world has been on HDMI since somewhere around 2010 or so. Think again. End of 2021, my research institute replaced their monitors, which meant i no longer was using VGA out on a daily basis.
(Computers typically are on a 3- or 4-year replacement cycle; monitors, projectors, keyboards, etc. aren't. )
Mathematica is a rare exception as it is generally used in a much more functional programming esque approach than the imperative/OO style common elsewhere. I find pushing data to black box Mathematica functions to be very simple (and they have stuff for practically everything), but some very simple stuff eludes me due to the language model.
So I guess your point stands (especially if it's a large code base).
There's value in running exactly the code which a researcher used in research to evaluate said research.
The Octave IDE is okish, but the plotting support is really far worse than Matlab. Honestly no open source plotting tool I've found (and I've looked a lot) comes close to Matlab which is why I eventually ended up just paying £125 for it, which I think is a very reasonable price considering it is a perpetual license and very niche software.
I wish there was some CAD software that had such a reasonably priced hobby use option, but SOLIDWORKS is $99 per year, Alibre has a cheapish option but they slightly annoyingly shift a lot of features into the £1000+ versions. Probably the best option at the moment tbf (other than piracy).
God damn Adobe for getting everybody onto the subscription model for professional software.
FreeCAD as a general purpose CAD software is not that bad. I've used it in combination with KiCAD that we use at our company to design PCB and for our needs is more than enough and works fairly well.
In Python and Julia, things tend to be documented more "bottom-up". Which is good for large projects, but tends to get in the way when you're just trying to get a small script to check one result or get one plot. (I don't have as much experience with R, so can't say which direction their docs lean towards.)
You could use LD_PRELOAD or LD_LIBRARY_PATH to get Octave to link MKL (or I’m sure you could compile the whole thing for MKL, but LD_PRELOAD let me use the disto version and I’m lazy). You also may have to tell MKL to use GNU threads. I’ve done it, got decent speed ups with a 6 core AVX2 system, so I guess something more recent could be even better.
And I for example don’t like using matlab - it’s not free (as in freedom), it’s very bulky, GUI is slow and heavy, there’s no way to use it as a console app in linux afaik.
You absolutely can. Many of the Matlab users I know never touch the GUI/IDE. They'll just code in Emacs and run their code from the terminal.
The original generation of MATLAB creators and developers like Cleve tended to come from an academic UNIX/mainframe/HPC type background, and so they were big CL users and lived in vim/emacs. And that carried over to a lot of the programmers working at The MathWorks to this day. For a lot of engineers I worked with who hack on the “guts” of the products (the language parser/interpreter/JIT, math internals, computational geometry and stats libraries, etc), the only time they’d fire up the IDE was at the pre-release bug bash every six months lol!
In my original post, saying the “majority” of TMW ran this way is probably an exaggeration, but a “sizeable minority” would be true. Maybe Ned could run an internal poll and include those results in the blog post :)
* https://www.mathworks.com/matlabcentral/profile/authors/1409...
It's true that Python with the use of Jupyter notebooks is getting closer to be a simple to use tool, but you still need to know some programming to use it.
IMO Octave really shines as a REPL you can write short scripts and functions for.
I'd go further to say this is useful for anyone with any level of experience programming!
The octave interpreter is slower than matlab, but that's because there is a JIT compiler in matlab. octave is still a good tool in my opinion.
Or if you're a gui person, right click on a variable in your workspace and click Rename
I use Octave daily, for many numerical tasks (and also python and julia). It has some advantages with respect to Python:
1. The sparse linear solvers in octave are considerably more performant than those available in a default scipy install.
2. No need to import external libraries written in other languages just to multiply two matrices.
3. Translating a formula from the blackboard to octave is really straightforward. This is often not the case for numpy.
As for julia, the base language is even better than octave. However, it is not as useful for one-off scripts due to the slow startup time. You can use octave as a calculator for your shell scripts. For instance, one day I had to warp a collection of images by a collection of affine maps; the affine maps were the product of two matrices stored in individual files. Thus I wrote a three-line shell loop that called octave for each file and did the deed. The loop processed 200 files in five seconds (even without parallelism). In julia this would take a few minutes.
With plot.jl as
I find that yieldsI suppose I maybe get the "no need to import external libraries" thing, 'pip3 install numpy' is technically an extra step that wouldn't have been necessary if the standard library contained a decent matrix module.
But why do you care about the "written in other languages" part? That has literally never caused issues for me with Python. Especially something as popular as numpy just works across all platforms I've tried (x86_64 Windows, Linux and macOS, aarch64 Linux and macOS). Do you frequently encounter issues which are caused by the Fortran portion of Numpy's source code?
No practical issues at all. The problem is not the pip install numpy that only happens once, but the import numpy that must appear on every single one of your programs. I interpret it as a permanent reminder that numerical computation is not natively supported in the language, and that we will always be foreigners in there.
https://github.com/dmolina/DaemonMode.jl
To learn and use Matlab/Octave requires learning very little programming or the intricacies of programming. To use Python, one has to figure out packages and libraries and object-oriented programming. To even use Julia, which is much better, one has to think about, how can I write my code to avoid the initial JIT delay.
When I am thinking science, I don't want to think about any of those things. I want to think about science and science alone. The intricacies of the programming language should not bother me.
[1] I say this as a 15 year exclusive linux user.
I get your drift but I think your analogy is opposite. I absolutely could not function in windowsland because it's constantly getting in the way of what I want to do whereas Linux just works.
Anecdotally, I used Octave during my PhD and it was a breath of fresh air (where matlab wasn't, for reasons I cant quite explain myself tbh).
I have also used (and still use) R, Python, and Julia. Octave is still the language I go to first to get things done fast.
All else equal, is having either software package on a resume an inadvertent signal to the hiring manager that you're only in one ecosystem / community and not the other? Strategically should a job seeker emphasize experience in one of the packages for roles in one ecosystem (while downplaying/hiding skills in the other), and the inverse for facing comparable roles in the other ecosystem?
If you're on the data science job market, you should know Python because that's basically all the jobs right now (the Python vs R debate was relevant 5-6+ years ago and Matlab was never that big). I don't know enough about the engineering job market to comment on it.
The last real stronghold of Matlab is controls engineering, because dynamic systems and simulink are just a good match, but even there sympy is used for the symbolic calculations.
That's not an industry and employment observation though.
In engineering fields, it all just depends. Control systems (via Simulink) is still pretty rooted in Matlab last I checked and is a lot better documented than Python. In power systems (my field) most "programming" is either at the application level (like C, C++, or Fortran) if you're a vendor and at the scripting/API level with 95% of that being in Python and the other 5% probably being something like C#, Java, or shell script. All data analysis is either in Python or SQL. SQL is better if the data is already in a database. We deal with such large quantities of data that pandas usage is relatively rare though. It's more common to use a Python script to push a bunch of data to a SQL database to then do analysis.
I do know some places that do post jobs with Matlab as a requirement and those are mostly the little R&D sections of those companies that tend to hire workers from academia that haven't been exposed to Python as much as Matlab.
Comparing the two language ecosystems (what matters), I'd say that Python is much easier to do general programming in and ML, but Matlab has easier and definitely more consistent facilities for charting and graphs. I prefer Python for a lot of scripting work, but Matlab is still pretty nice if your company can afford a license. I wouldn't want to just be stuck in Matlab, but there are plenty of cases where I might reach for it over Python if available.
At the end of the day though, they're both scripting languages and aren't very hard to learn. Any sane hiring manager should accept candidates with experience in either one as long as they don't need to hire a super expert to lead a big effort on day one.
Am I missing something? I just don't understand how to reconcile blatantly copying tools, at least the APIs are copied, with the apparent philosophy of open source software, particularly GNU software.
For example, from Octave's documentation:
https://wiki.octave.org/wiki/index.php?title=FAQ&mobileactio...?
They tell you what to do with your own software, but they are embarking on basically creating a free (as in price) version of paid, proprietary software. Even if there are not direct violations of MATLAB licensing or IP claims, it feels the two approaches are in conflict.
This is an honest question, because it isn't clear to me what the resolution of this apparent conflict is. Maybe someone has some insight.
This was not done to piggy back on matlabs IP. It was so people could easier migrate their projects
So, yes, it's right to clone tools and API's. GNU has been doing that since... forever.
> Isn't that against the supposed philosophy of GNU software?
Anyway, how reasonable would it be for me to tell them "Try to run your code with Octave"? i.e. how likely is this to succeed?
Good choice if you don't want the whole Matlab monstrosity on your computer, but still have to deal with some itty bits.
I have mixed feelings about the move towards "matlab strings", but I suppose given matlab compatibility as a project goal this was inevitable ...