https://github.com/DanburyAI/SG_DLB_2017/blob/master/Noteboo...
In addition, recent versions of Matlab have broken some common plotting tools, contourf in particular. Where this once produced elegant and light weight results it now generates a tessellated mess with tiny gaps between elements that look awful in paper manuscripts and baloon the file size for no good reason. The Mathworks response? It fixes some edge case.[0]
I find many of students we take on as interns often lack more than rudimentary coding skills making the jump to Python easier.
[0] https://uk.mathworks.com/matlabcentral/answers/162257-proble...
A few of them have transitioned from Matlab. Even though we're a commercial business, buying each engineer a Matlab seat with packages is not a trivial expense, and asking for the money requires more management attention than we really need. With Matlab, it's: "You need Matlab for what? Why are you working on that?"
With Python, it's: "You solved that problem? Great."
But there are of course some caveats. Learning Python per se won't turn you into a professional software developer. A lot of people list Python on their resume's, and our interviewers are engineers and managers who only know that Python is a good buzzword to have. Learning Python ultimately translates into a widely varying ability to actually do anything. One of my colleagues has really taken to it, and has made an effort to develop disciplined programming skills beyond "coding." A couple others are using it for basic scripting, data analysis, and so forth. I've seen some horrendous code, and I'm torn about whether to intervene, when they are in fact getting useful results. Usually, I tell them about some things to learn on their own before they start their next project.
But that problem -- what really constitutes good programming skill for people who aren't formally trained, being hired by people who don't really know either -- isn't confined to Python.
Library support is perhaps better with SciPy, but Octave is free as in freedom, fast, works.
But SciPy is a great project and everyone can learn something from their successes.
(a) writing your research as a bunch of Fortran or C kernels and intrgrate them with automatic bindings such as f2py? Especially Fortran is a great fit for NumPy datastructures - because they are the same.
(b) Use high performance python environments like Numba, NumbaPro (GPU) or even Cython?
With SciPy, the community is much bigger and present in every imaginable scientific field. Whenever someone comes up with a new algorithm, there's a python implementation before you know it. I'm not going to pretend that this isn't a huge added value, but I find the way GP phrased themselves a little bit annoying, as it implies the language Julia is is the issue. It is honestly a more beautiful and more efficient language to program in.
(also, these days you can call out to Python and R without significant overhead, so you can use any package out there; Julia has a pretty good interop story)
