← Back to context

Comment by rekenaut

20 hours ago

This is great aspect of it, but that doesn’t diminish that it feels so tedious to work with compared to Julia and Matlab. Some of that is just from trying to shoehorn Python as a scientific computing language, but I think it’s time to revisit whether Python should have first party support for vectorization, arrays in memory, and broadcasting as Julia and Matlab have.

Where are these people who use Matlab properly? All I ever see in other people’s Matlab code is for loops. Their idea of speeding up their code is using parfor.

Obligatory licensing rant: you have to pay extra to use parfor, as I found out one day when the license server at work told me I couldn’t run somebody else’s code because we were out of licenses for that iteration construct. This is just Mathworks taking advantage of ignorant people who don’t understand what Matlab is to inflict more misery with their insane licensing scheme. It’s not just that it’s expensive, it’s that it’s weirdly unpredictable. I mean, come on, the code was slow and chock full of errors as it was. To have it randomly fail because the license server was out of parallel toolbox licenses is just insulting.

NumPy allowed a PEP for the in-memory representation of arrays in Python. This is tremendous useful for making APIs.

I've never understood the "so tedious" argument of Python vs Matlab. Sure, having to import numpy and use np.array to create numpy arrays is a bit typing, but other than that I don't see major differences.

Given what inconsistent mess Matlab is aside from matrix manipulation, I take NumPy any day.