IEEE Spectrum Declares Python The #1 Programming Language (ieee.org)

An anonymous reader quotes IEEE Spectrum's annual report on the top programming languages: As with all attempts to rank the usage of different languages, we have to rely on various proxies for popularity. In our case, this means having data journalist Nick Diakopoulos mine and combine 12 metrics from 10 carefully chosen online sources to rank 48 languages. But where we really differ from other rankings is that our interactive allows you choose how those metrics are weighted when they are combined, letting you personalize the rankings to your needs. We have a few preset weightings -- a default setting that's designed with the typical Spectrum reader in mind, as well as settings that emphasize emerging languages, what employers are looking for, and what's hot in open source...

Python has continued its upward trajectory from last year and jumped two places to the No. 1 slot, though the top four -- Python, C, Java, and C++ -- all remain very close in popularity. Indeed, in Diakopoulos's analysis of what the underlying metrics have to say about the languages currently in demand by recruiting companies, C comes out ahead of Python by a good margin... Ruby has fallen all the way down to 12th position, but in doing so it has given Apple's Swift the chance to join Google's Go in the Top Ten... Outside the Top Ten, Apple's Objective-C mirrors the ascent of Swift, dropping down to 26th place. However, for the second year in a row, no new languages have entered the rankings. We seem to have entered a period of consolidation in coding as programmers digest the tools created to cater to the explosion of cloud, mobile, and big data applications.
"Speaking of stabilized programming tools and languages," the article concludes, "it's worth noting Fortran's continued presence right in the middle of the rankings (sitting still in 28th place), along with Lisp in 35th place and Cobol hanging in at 40th."

Comments

Re:What is the interpreter written in?

[steveha]

There are no Python to machine code compilers out there.

Interestingly, you are incorrect. There is one: PyPy. It's Python written in Python. And it's fast!

http://pypy.org/

Re:What is the interpreter written in?

[steveha]

Even the Python folks tell you to write your high performance code in C or C++.

True, but one of the smartest things Guido van Rossum did early on was to make it easy to interface C and C++ code to Python. It's why SciPy is winning so big in the sciences; it's the convenience of Python with the performance of Fortran. The libraries that do the work for SciPy are old numerical libraries that are very well optimized, very well debugged, very well understood, and very very useful. So, you can work in Fortran... or you can work in Python, enjoying the much friendlier interpreted language, and barely give up any performance vs. the pure Fortran. The hard work is done in Fortran, and the overhead of using Python to set up your calculations is trivial compared to the work of the calculations themselves.

https://www.scipy.org/

Python also provides a "lab notebook" environment through the Jupyter project. Nobody is going to try to use Fortran or C directly in the notebook.

http://jupyter.org/
https://www.datacamp.com/community/tutorials/tutorial-jupyter-notebook

And pretty much every library you might want to use has already been glued into Python by someone. Computer vision? Running code on a GPU? Signal processing? Solving equations? Whatever you need to do, you can do it conveniently in Python and it will be fast.

So yeah, if you write your own matrix multiply in pure Python it will be roughly 50x slower than compiled C. But nobody does that, and in the real world Python is fast enough to do real work.

Re:I tried Python

[TheRaven64]

Semantic whitespace isn't a terrible idea, but like almost everything in Python it's let down by the implementation. Tabs are a variable-width character, spaces are not. Mixing the two in an environment that treats the amount of whitespace as having semantic importance is a recipe for disaster. Python treats a tab as a fixed number of spaces and so the indent that your editor displays is not necessarily the same as what the interpreter picks (I've had to fix a bug in someone else's Python resulting from this[1]). The only sane thing to do is for the interpreter to reject any inputs that mix tabs and spaces at the start of a line as invalid input. I believe that Python now has an option to do that, but it took 20 years to add and it's still an option. This pretty much sums up Python: the obviously sane thing takes 20 years to add to the language and is then optional.

That said, it doesn't bother me nearly as much as a language claiming to support functional programming but not doing tail-call optimisation (1000 recursive calls and your program dies) or else clauses on while loops (another bug in someone else's code that I had to fix was caused by the fact that there are two plausibly sane meanings for this. Python chose the third and the developer assumed they chose one of the others).

[1] My irrational hatred of Python is largely caused by the fact that every time I am given the release version of a Python program I end up finding a bug that I have to fix before I can use it for its intended purpose. No other language manages to be quite this reliable in allowing people to ship completely broken crap that they believe to be working.

Re:I tried Python

[TheRaven64]

There are a couple of reasons 0-based indexing makes sense. The first only really matters in low-level languages: the indexes represent the offset from the array. The address of array X and index 0 into array X are the same. The second relates to concatenating arrays. The place that you insert into the first array is the length of the array. This idiom crops up sufficiently often that zero-based indexing saves a surprising number of +1 calculations in a program - it's very common for programmers to accidentally clobber the last element in an array in languages that index from 1. Mathematics understands that cardinals and ordinals are different, but programmers often forget...