If you have some Matlab background, working with Python is frustrating. It is hard to explain, but vectors and matrices should be the primary concepts, with absolutely minimum extra glue needed.
I don't have much experience with Matlab, so forgive me if this is incorrect, but numpy should be able to do everything that matlab can at comparable speeds. No one performing matrix/vector-like operations is doing so with standard Python lists if numpy is available.
I'm not talking about execution speed but the human interface. The syntax of Python just is not nice and using libraries just adds more and more boilerplate.
I don't expect anyone who has not spent a lot of time with Matlab to "get" it.
concatenates two matrices/vectors, whereas in Python it "wraps" them in an `n+1`-dimensional "matrix".
That said, you get most of what you want with libraries. In NumPy you won't write
[aRow + bRow for aRow, bRow in zip(aMat, bMat)]
because you'll just call `numpy.concatenate`.
Also, Python is mostly not used for mathematical work, and programmers tend to assume matrices are scary or only useful for mathematical work, so it has a "boring" syntax more suited for operating on single items at a time, with lots of loops.
> "The syntax of Python just is not nice and using libraries just adds more and more boilerplate."
I think that is a necessary trade-off for Python as a "general-purpose" programming language. I had used MATLAB and IDL quite intensively before I moved on to Python and R. When writing MATLAB, I felt like a scientist and did not have to bother with programming practices, like coding style, unit tests, writing functions instead of scripts, etc. But Python forces me to think like both a scientist and a programmer. (For example, every time you write `np.array([1, 2, 3])` instead of `[1, 2, 3]` it reminds you that array operation is not a free lunch offered by the language; it comes from the NumPy library. Also, it keeps the namespace pure.) I personally like this way better. But I also agree that not everyone likes it. (In my institution, researchers are kinda split half-and-half between Python and MATLAB.)
It's interesting because those were the reasons I heard from MATLAB users for switching to Python: moving to a language with a cleaner, less ad-hoc design and less boilerplate / copy-paste code made a big difference once you had more than a little code.
Has the language improved dramatically in the last few decade?
Python is much better than MATLAB in non-mathematical domains. Hell, MATLAB didn't even have arrays of strings until 2017! But in the mathematical area, SciPy is really lacking syntax-wise. Here's a quick side-by-side comparison which is also useful for teaching between the languages:
You can go as far as to say that Python is verbose in many cases, and non-intuitive in others (A @ B?).
That said, you would never want to write a webapp in MATLAB, so as people expand from "math scripting" to "programming" they run into MATLAB issues which have absolutely no good solution. This is where the Python pickup comes from: it's still decent for scientific computing, but it also is an actual programming language. However, Julia keeps the nice syntax of MATLAB in the mathematical domain, keeps the technical computing focus of its community, adds some speed, and also is a general-purpose languages where webservers etc. are being written. In that sense, Julia is a really good fit for people looking to ditch MATLAB.
(A lot of MATLAB's bad syntax was bolted on later. It started as MATrix LAB, and later became a programming language. You can easily see the elegance of its initial design, and the terrible choices when extending it.)
Matlab is good for non-software engineers and scientists to explore and solve problems. Once you have a solution there, write it up in some proper language.
I don't think it is likely for a software engineer to understand Matlab's niche and effectiveness. It comes from a different direction.
A ball point pen, a paint brush and a piece of drafting graphite all have their uses.
I'm an electrical engineer oriented towards signal processing and controls, and I'm also incapable of understanding Matlab's niche and effectiveness. I wish Matlab could just vanish. It's a glorified calculator that has mutated over the years into a crap programming language, with random features just bolted on and the strangest semantics of all time.
It also has the drawback that most of its users generate write-only code, so everyone that learns it also learns to write code that way.
I second this. And to make matters worse, a lot of MATLAB users are not aware of coding style. Poorly readable MATLAB code stinks. I sometimes rather wish to read Fortran 90 instead of MATLAB code.
But numpy is the underlying library used by the rest of the SciPy stack, right? I use Pandas, so taking that as an example, it can be slow when you're doing stuff that isn't
mostly leveraging Numpy. If I have to loop over a relatively large dataset to do some complicated row checking/filtering stuff, then it can be very slow, and I might as well take a coffee break. You can rewrite that into using just the numpy values array and it will be performant, but you lose all the nice Pandas features when you do that.
Also, if I'm just restricted to using Pandas on a laptop or small server instance, then loading in a several gigabyte csv file can really tax the memory.
