The homogenization of scientific computing (2013)
talyarkoni.org
talyarkoni.org
Just out of curiosity, what's the best one?
But across subfields and concentrations Python is almost always the second best language. Also Python kills for rapid prototyping and testing a concept on a small scale before the much more labor intensive porting to a lower-level language.
Bob likes R. But he'll take Python second. Ted likes Matlab. But he'll take Python second. Etc.
The point is everyone agrees Python will do. Consensus plays in to the OP; even if Python isn't perfect for the domain, it's probably good enough, and the lingua franca.
Jack of all trades, master of none,
Often times better than a master of one.A PhD friend of mine who does scientific computing works almost exclusively in FORTRAN.
There are Python bindings to ROOT (pyROOT) but I've found Python in my experience to be a bit too slow when handling the large (10TB+) datasets.
As an aside, it's interesting how ROOT attempts to provide C++ with some basic reflection[2] and saving of C++ objects to dis. Unfortunately it doesn't necessarily do a very good job of it, but perhaps things will change with ROOT6 as it transitions to being based on clang, as opposed to in-house C interpreter.
[1] http://root.cern.ch/ [2] http://root.cern.ch/drupal/content/reflex
The best language for large-scale scientific computing is C/C++, which surprises some people. Python binds to these libraries. C/C++ has two big advantages: it can run much faster than any other language and the language is better suited for designing massively parallel codes than most others. The latter point makes sense when you realize that HPC software only runs a single process per core and explicitly, adaptively schedules execution and messaging in order to optimize throughput. It is a bit like very old school single-threaded UNIX server programming.
R is a lot like vim or javascript. It has a lot of warts, but it's an incredibly expressive toolkit for its task. I usually buy into a language once I find a few extremely gifted developers working with it (and who seem to do so voluntarily). For instance: for vim it's Tim Pope, for R, it's Hadley Wickham, for javascript it's Mike Bostock.
Python, despite its many good decisions, is likewise full of warts. So, who are good developers to follow in the python/numpy community?
Off the top of my head: Travis Oliphant, creator of numpy and founder of two companies in the scientific Python space; Jake Vanderplas, enthusiastic developer and blogger and Fernando Perez, creator of IPython (disclaimer: I work for Fernando). In the broader Python world, Kenneth Reitz, the author of requests.
Performance is, of course, an issue. But in one case I noted that the week or so it took me to write and execute some Python code was almost certainly less time than it would have taken just to write the code in C/C++. I concluded that -- for this problem at least -- the extra performance I might have gotten out of C++ simply did not matter.
However, these days I do not do much with large scientific models or anything resembling big data. Performance is not the issue for me that it would be for others. And with articles having titles like "Why Python is Slow: Looking under the Hood"[1] out there, I find it difficult to see how Python can displace Fortran (or maybe C) in the realm of traditional supercomputing.
[1] https://jakevdp.github.io/blog/2014/05/09/why-python-is-slow...
with this ?
There is also CFFI, which I haven't really used, but lots of people seem to like it.
He himself seems to be talking more about standard stats and data analysis or prediction. In this field R is growing at least as fast as Python. R is the no1 Kaggle language and the no1 academic stats language, Python 2nd and stable there. The software carpentry movement to train scientitsts concentrates on both R and Python.
Then the biggest scientific programming field is bioinformatics - which really is a mish mash of Python, Perl, Java, C++ whatever piped CLI and a lot of R again. Here Python is growing mostly at the expense of Perl (there is a big Perl legacy) but as most software is designed for piping together in Bash scripts the diversity is not too big a deal. My own perusal of Job adverts on this area sees employers asking for "R Perl or Python" which are viewed as interchangeable.
But really, just this second part is the point. Why wasn't this post written five years ago, when Python had already become a popular and established language? Well, if you look at it a little differently, it took roughly five years from the time Python took over undergrad CS courses to the time it became the lingua franca of scientific computing -- see a connection?
I personally find I use C# for almost everything. You can find good libraries for virtually everything you need. And it has the best tooling I've found. Is it actually the best language for everything? Absolutely not, but its close enough that I'm probably the most productive in virtually everything with it.
Python is great for mobile when it comes to hacking on-the-fly - I actually traced down and fixed few bugs in early Openmoko while getting bored in tram etc. thanks to the most useful parts being implemented in Python. Unfortunately, on Freerunner the difference in performance was very visible - however it shouldn't be as bad on more recent hardware.
People have made valient efforts to overcome this issue in both Python and Clojure: Kivy, Py4A and Clojure on Android, in particular. But they still can't provide reasonable performance compared to native mobile frameworks.
It's just a product on Python implementation: too much complexity and too heavyweight objects (and almost everything is an object!).
To a certain extent, the same applies to Clojure -- there is a price to be paid for abstractions and (and in the case of Clojure) immutability, and it rears its ugly head the most when trying to fit these language implementations on resource-constrained mobile platforms.
http://wiki.ecmascript.org/doku.php?id=strawman:value_object...
Faster than Python using LAPACK and other native libs?
Not good enough, or any other reason?
I'm curious.
Zope 3 was not backward compatible with Zope 2.x, nor with the impressive ecosystem of Zope 2.x plugins, and for years there was confusion about the direction, momentum, and relative importance of those two parallel projects. Zope 3 never gained any significant traction, because in adopting a "component architecture" they decided to use XML to connect those individual components, and it felt like you spent more time writing XML than Python. IMO this was a strategic mistake.
In 2005 the Django framework was released. In 2006, Ruby on Rails was released. After a couple years of confusion about the Zope roadmap, developers now had multiple options. You couldn't sell management on new Zope 2 apps, Zope 3 wasn't ready for prime time, and Rails was a significantly(!) more productive environment than Zope 2. (Django presumably is, too, but I have no Django experience and so cannot say.)
In 2010, the Zope community renamed "Zope 3" to "bluebream" to clarify their messaging, but that was after six years of ambiguity. Developers moved to other tools and frameworks, and Zope's developer community shrank until it no longer had a critical mass of developer interest.