Personally, I think Python's success is down to the productivity of its peudocode-like syntax letting you hack prototypes out fast and easy. In turn, that makes building libraries more attractive, and these things build on each other. FORTRAN is very fast but it's a less forgiving syntax, especially coming from Python.<p>In that regard, I'm surprised Nim hasn't taken off for scientific computing. It has a similar syntax to Python with good Python iterop (eg Nimpy), but is competitive with FORTRAN in both performance and bit twiddling. I would have thought it'd be an easier move to Nim than to FORTRAN (or Rust/C/C++). Does anyone working in SciComp have any input on this - is it just a lack of exposure/PR, or something else?
IMO the popularity of Python has as much, if not a lot more, to do with the available libraries and frameworks as the language itself. The language itself seems more inherently suited as a successor to Perl - as a powerful scripting language, rather than one really suited to large, complex, multi-person projects.<p>What seems to have bootstrapped the success of Python for ML and scientific use was early adoption by people in these communities who were not hard core programmers, and found it easy to get started with. Once SciPy and NumPy were available, and NumPy became used for ML, then the momentum of ML helped further accelerate the adoption of Python.
Python isn't the language of scientific computing, data science, or high-performance computing.<p>Python is a popular user interface for scientific computing, data science or high-performance computing.
As someone that was at CERN when Python started to be adopted in the early 2000's, Python got popular as saner Perl alternative for UNIX scripting, build tools (CMT), and as means to provide a REPL to C++ and Fortran libraries instead of dealing with ROOT.<p>That was all, it could have been Tcl instead.
Programming languages are a bit like social networks. There's some network effect. People go where other people are. Python is currently where things happen.
I imagine part of it is also that a lot of the code isn't the science part. It's all the setup, things like parsing data for input or output. Languages like Python and Perl have very rich standard library stuff for massaging strings, data formats, etc.
I'm so old that Fortran was actually my first language. Over the years I've seen language bindings to the old Fortran numerical libraries we all rely on but Python/numpy is the first wrapper I've actually enjoyed using. It's more than a wrapper in that it brings a compact representation of slices and vectors.<p>However, if I didn't know how things work underneath I'd be a little uneasy. You can always profile after the fact but it helps knowing how to avoid inefficient approaches.
The slowness of Python meant that nobody thought "it'll be easier just to write this routine" as opposed to looking to re-use existing (most often compiled) code. And if you are doing science, the less time you spend re-inventing code, the more science you will get done.
The date of this discussion (July/2020) really caught my eye. Fortran is actually making quite a comeback (to the extent an ancient scientific language can :-). I casually looked at the TIOBE index[1], flawed as it may be, it gives you sense of the trends of the larger languages. To my not-a-surprise, turns out precisely in 2020/July Fortran was at it's lowest rank on the index since it was tracked from 2001, and has steadily climbed since then. No doubt it is due to vast number of libraries already existing and python is really glue code not something you write the main code in. As someone joked to me, the first rule of python programming in scientific computing is make sure you don't have any of your program go through python. You cannot avoid Fortran/C++ unless you have very trivial or textbook type code.<p>[1] <a href="https://www.tiobe.com/tiobe-index/fortran/" rel="nofollow">https://www.tiobe.com/tiobe-index/fortran/</a>
Tooling is the thing. To keep older languages popular with people new to the industry (and who never get <i>properly</i> introduced to older tools) it would take someone like JetBrains need to create COBOL and Fortran IDEs. People will always go for shiny and new, like it or not.
I wrote a short thing about working with Fortran for AI recently: <a href="https://www.marble.onl/posts/fortran_llms.html" rel="nofollow">https://www.marble.onl/posts/fortran_llms.html</a><p>I'm a big Fortran now for anything fast. If I was doing EDA or any one-of data science stuff I'd be more likely to use python though (or coreutils and gnuplot depending on the circumstances).
I worked hard to replace LabView and Matlab with Python in the lab when I was a PhD student - about 15 years ago. By far the biggest motivation to do this was to remove the friction and cost of obtaining licenses for proprietary software.
I wish Python existed when I was in high school. My school’s compiler wouldn’t remind me that I was missing a semicolon and I would constantly be wasting time looking at syntax rather than grasping bigger concepts.
Not sure if it's real or not, but on my university I'm almost sure python is used primarily for being the free alternative to matlab.<p>That, and how easy it is to install and import things.
Python wins because it’s the lowest common denominator.<p>We have a bunch of people programming, most of them scientists. Even if Python is poorly suited for us, it’s pretty much the only thing everyone can work with.
When you look at the "monster" that is ROOT-CERN, which is a C/C++ interpreter* with very efficient statistics and plot tools (it can digest tons of data), it is completely logic that Python is a good language for daily lab tasks and analysis.
But I'm not sure if it is really used beyond this daily lab task or intern project where performance is not critical. Big simulations I participated were made in C/C++.<p>Nowaday, it seems that at least physics particle community looks enthusiastic regarding Julia development.<p>*: it mimics most of core python features such as no strict typing, data structures that can store different types, on-the-fly coding, graphic interface for representation, no compilation needed.
Python is also a more transferable skill than Fortran.<p>I bet that plays some role too in its popularity in the scientific community, which has many young anxious grad students/postdocs looking to ensure they are employable.
This is less the difference between fortran and python and more the difference between run once for an experiment culture and run as part of a pipeline culture.<p>Languages are mostly funglible, coding culutre is not.
Like just about any technology in our industry, people use it because it’s popular. Competitive advantage be damned - just use what your competitors use.
Original post at <a href="https://cerfacs.fr/coop/fortran-vs-python" rel="nofollow">https://cerfacs.fr/coop/fortran-vs-python</a><p>Contents:<p>- “Python, a slower language”<p>- “more and more”<p>- “time-critical scientific computations”<p>- Is Python ever better suited?<p>- User story : same author, two languages<p>- Speed vs agility<p>- Takeaway
The miracle of python is that it has standard syntax for vectorized code across many packages.<p><pre><code> For i in range(100):
mask = lib.abs2(z) < 4
subset = z[mask]
subc = c[mask]
subcounts = 0
for j in range(100):
subcounts = subcounts + lib.abs2 (subset )< 4
subz = subz**2 + subc
Z[mask] = subset
Counts[mask] += subcounts
</code></pre>
Was that code using numpy, tensorflow, torch, arrayfire, or some proprietary amd gpu lib? It’s hard to say!<p>Try the same with eigen vs arrayfire in C++ or math.js vs tensorflow.js and you will have to do a hell of a lot more than change the value of lib