Hacker News Reader

Comment by w_t_payne | Hacker News Reader

I've a lot of experience with both MATLAB and Python. I find Python to be the better designed language, with fewer rough edges. But MATLAB still promotes and encourages the most productive approach to programming, one that NumPy just falls short of.

View on HN

For exploratory work MATLAB and the MATLAB IDE are pretty good and shorter scripts are fine. However once you start trying to write actual programs and pass 1-2 kLOC or so, MATLAB just gets more and more painful.

And "MATLAB packages" are especially painful. The fact that you "install packages" by adding folders to the path is somewhat insane, especially since that is somewhat of a silent global change. I think the hardest thing to do with MATLAB is get someone else's scripts running, because it's always like "oh I forgot to give you my special plot function which I keep in this folder, but requires other things, so just add this whole thing to your global state, but it's incompatible with XXX since I use a function named A". Remembering those incidents makes me shed a tear... while Python and Julia allow you to import without sending every internal name and you're done. And in Python and Julia, people add continuous integration tests to packages.

I like to say that Matlab was designed by applied mathematicians who don't want to care about software engineering, and python+numpy+scipy was designed by software engineers who don't want to care about applied mathematics :P

I don't know that that's strictly true but it gives you a general idea for why things are the way they are.

Somehow it's nice to have a global namespace so I dont have to remember which libs have "plot()" or "sind()".

Nothing beats Matlab/Gnu Octave for me when I just want to make some quick calculations.

Julia "default" behavior (the 'using' keyword) is also importing everything (that is exported on the selected module) to the global namespace, using multiple dispatch to safely assign the optimal implementation of each function for each argument set without clashing. It's not unusual in Julia to have one function with more than a hundred implementations, and the user doesn't need to care which one will be chosen.

Though you can also use 'import' to keep the namespaces separate.

It's not really a default though. You have to always choose to do `using` instead of `import`. A lot of people choose `using`, because it's generally more safe than something like MATLAB or Python because of multiple dispatch, but there's nothing in the language that actually defaults to `using` other than the convention of some people.

When you say numpy falls short, do you also include pandas?

Try using R's data.table and then use pandas. Pandas is just awful to use in comparison.

I'm of the same mind, and have been surprised for a long time that this isn't commonly said. dplyr/tidyverse also suits my thinking process around working with data much better than pandas, which is by far the worst of the lot.

h2o.ai has been working on data.table for python (https://github.com/h2oai/datatable). Hope it matures quickly

Reply on news.ycombinator.com