This has been around for a while. However, it's clear to most people now that Python/Scipy is a better solution, rather than simply trying to copy Matlab. Python as a language is far, far better than Matlab. And the ecosystem has matured a lot, to the point that for many research algorithms, the Python offering is superior to the Matlab one.
Scilab development started from the same Fortran code Matlab did, around the same time; also it rarely attempts to copy Matlab syntax or behaviour. (I'm just saying it should be seen more as an alternative to Matlab, not a copy.)
I personally would tend to agree that developing in a general purpose language is better for most problems but an imperative math-oriented language that's simple to apprehend remains a large use-case for scholars and engineers. For that I feel that the rewrite of most of the code in the past few years has been a worthwhile endeavour.
Agree with first sentence. Before mostly switching to R more than 10 years ago I tried out Octave/Scilab (and preferred the latter).
As for the alternative I'd say, Julia is (will be) a good choice also. Long in the making with a beautiful syntax which somewhat resembles Matlab. Sound "inner" foundation. And speed. Speed like no other dynamic language (important with increasing data abundance). Friendly and helpful community.
I'm scared of network effects for Julia, personally.
Python is garnering tremendous amount of users.
But then, I remember a computer vision teacher 3 years ago laughing at the idea of using Python instead of Matlab as Matlab is the "obvious industry standard".
You are right that the current adoption rate of Python makes it seem like Julia is in a losing position, but on the other hand it took Python a long time to get in to the position it is right now and systemic changes take time.
The two arguments that speak for Julia from a user perspective (there exist much stronger arguments for package developers).
a; Low overhead interoperability with Python, R, C and Fortran (and C++); You don't need to rewrite your code and you can start using Julia and slowly transition.
b; User code as fast as package/base library code. You are not stuck with what already exists.
There are also some niches where Julia already has a strong position compared to Python (which I use and like), e.g. optimization and differential equations.
I think these are areas where the 2-language model makes Python quite a bit less productive than Julia.
Python has pretty good optimization support as well as handling differential equations quite well. The latter also have very good support in R. Python also handles symbolic computation pretty well and in the freeware space dominates anything else in that respect. Julia is interesting but still has a ways to go for overall flexibility.
Your question has been asked here [1]. I never used Numba myself but assume from the discussion that it is difficult/impossible to bring user objects into Numba and that due to the extremely rich Python object model one can only make Python fast for a small subset of the language.
Example: in Julia I can easily define my own primitive type, let's say a ModInteger (an old video is here [2]) and it will be as fast as a normal "built in" integer in a for loop (and benefit from possible speedups: simd, parallelization, cuda, GPU - but don't have (much) experience in this area).
Likely such a ModInteger couldn't be as easily integrated in Numba?
Yep I was expecting you might mention user defined types. Numba supports them but with an object model which is more sympathetic to acceleration.
The other place where Julia might see better speed is when you have an optimization algorithm and the objective function both written in Julia, which allows for optimization across functions, whereas in Python you could write a fast objective function with Numba but couldn't optimize across function call with the optimizer written in Fortran.
As someone who's watched the rise of R and Python from its beginnings, who pulled my hair out in frustration over the longevity of MATLAB long ago, and who has tried just about every numerical programming language it seems, I think the threat to Julia probably comes more from other LLVM-based languages like Nim or Crystal, or things like Rust or Kotlin.
Julia's adoption rate is really impressive compared to R or things like numpy, etc. so I'm not worried about that. But I do think it will have to contend with a number of competitors in the same space.
I think you nailed the key insight here... The Matlab community maybe needed a really close alternative at the beginning, but we should really strive now for python-centric solutions (and/or Julia/R...).
Matlab is a tremendously poor ecosystem. Not flexible at all in terms of libraries, slow, closed source and poorly designed as a language.
You could just see what Python has achieved in the last years as a scientifical tool: awesome libraries, interfaces with web/mobile applications, tons of rich courses/tutorials.
I hope it teaches other fields that open source can really be key in making tremendous progress.
I know that this is the common opinion, but I don't agree in every case.
Clearly for writing an application Python is superior. But for doing calculations, I much prefer Matlab (or Octave, for really small Stuff).
> reports of the death of Matlab (in favour of Python)
MathWorks provides a way to call Python from MATLAB with the same simplicity as it can call Java. I don't think anyone declared MATLAB dead but it's a clear indication that they're losing ground.
Octave tries to make every Matlab program run unmodified. A difficult goal, but that is the goal.
Scilab doesn't try that exactly. They have their own syntax and some compatibility converter from Matlab code to Scilab code, but I don't thik it's as complete as Octave's.
As a sibling comment mentions, Scilab has Xcos which tries to be a modelling helper like Simulink and Octave has nothing comparable.
I’m a long term Matlab user who now enjoys using Python. Students still like to stick to Matlab because of its pretty simple IDE and decent documentation. The various Python IDEs like Canopy and PyCharm are too often complicated for engineering students who just want the simplicity of Matlab’s Workspace to get whatever problem they have solved.
Scilab is ancient; I was using it in grad school. They also made a decision at one point to make it just slightly incompatible with Matlab, which was probably a mistake. Octave is actually better at this point; they've managed to reproduce the best of Matlab's UI, which was always quite good.
While I rarely develop things in Matlab, it is worth noticing that it is a very elegant way of expressing linear algebra and numeric oriented programs. Python is a vastly more useful language, but numerics are an afterthought, and expressing numerics is abominable in Python. When I'm looking up how to implement some classic numerics algorithm, the Matlab way is usually concise and its vector oriented operations are usually the right way to express it in any interpreted language, as it keeps you in Lapack-land (remember, Matlab's origins were a repl for Eispack/Linpack).
> Python is a vastly more useful language, but numerics are an afterthought, and expressing numerics is abominable in Python. When I'm looking up how to implement some classic numerics algorithm, the Matlab way is usually concise and its vector oriented operations are usually the right way to express it in any interpreted language
This is a really strange statement to me. Python has much better syntax for vectorised operations than Matlab. I have written a great deal of both (Python by choice, Matlab when required to), and in my experience almost everything numerical is easier to express in Python.
Numpy is in large part a thin wrapper over fast low-level libraries, but with an excellent well-designed interface, unlike the undesigned growth-by-accretion of Matlab.
I've worked a lot with numpy (hundreds to thousands of hours, depending exactly what you count). I've also worked with numerical arrays in several other languages, and of those I've tried I've found numpy the cleanest and simplest.
I'm wondering why there is no comment about the toolboxes in MATLAB. Several standard toolboxes are the main reasons, that I'm still staying in MATLAB.
Scilab is one of the two major open-source alternatives to MATLAB, the other one being GNU Octave.[1][2][3][4] Scilab is similar enough to MATLAB that some book authors (who use it) argue that it is easy to transfer skills between the two systems.[5] Scilab however puts less emphasis on (bidirectional) syntactic compatibility with MATLAB than Octave does.[1][6][7]
I believe Scilab has a Simulink equivalent, whereas I do not think Octave does?
I'm a control engineer by training, and to be honest there's really no equivalent to Matlab/Simulink right now for control system design. Fortunately I'm currently working on statistics/sensor-fusion related stuff, and Python works just fine for that.
I tried doing sensor fusion with simulink and I thought it was horrible. Then me and my team switched to python instead and it worked really well. Never understood why to use simulink for other things then just controls.
Been playing around with it for the past hour or so, looks like the program is trying to replicate MATLAB/Simulink with Scilab/Xcos. The menus/UI and other features very closely parallel MATLAB. Can even convert MATLAB code to Scilab code. Looks like it's being positioned as a cheaper alternative for a lot of educational establishments in developing countries.
I am surprised that Julia hasn't been mentioned yet. It is the language/program that I normally use when I don't want or for some reason cannot use MATLAB. Many times I don't want to start MATLAB because of how ling that process takes on my computer, especially for easy tasks. I definitely recommend checking out Julia.
As soon as you ask me for a name,email, DNA sample, etc for a download...you lose. Python doesn't do that. Which is why it is kicking Scilab, Matlabs et al arse.
SageMath is technically really a large Python library, with over 1 million lines of actual code in Cython and Python. Most Sage development is motivated by pure mathematics research (combinatorics, number theory, algebraic topology, manifolds, algebraic dynamics, etc.) and also undergrad mathematics education. For numerical computation, Sage has some interesting things, e.g., wrapping GSL using Cython, very good interval arithmetic, etc., but we ended up mainly punting to Numpy/Scipy/etc. because most Sage developers are not doing applied math/engineering.
sagemath is monolithic, and incorporates many other foss libraries within it. Other commenters here are discussing comparing scilab with Octave, and sagemath includes all of Octave.
I wish — unfortunately, SageMath doesn’t actually include Octave. I tried to include Octave at one point, but it took far too long to build from source and replicated too much functionality already available in Numpy/Scipy to make it worth the work at the time. I did write a (maybe not so great) pexpect interface between Sage and Octave, and there is also a Jupyter kernel that lets you call Octave from Python. Similar remarks apply to SciLab. A big point of Sage after all is getting open source math software to work together rather than compete. We are all on the same team!
