Python leads Tiobe Index for first time in 20 years
tiobe.com
tiobe.com
What is fascinating that Classic Visual Basic jumped from 19 to 11. TIOBE is like that
I've been teaching Python for the last few years and there has been a marked increase in using Python to "Automate the boring stuff".
Adult students come to tell me that Pascal or C++ taught in school was just not something they could use practically, however Python is very practical across many disciplines.
Of course if we could solve the deployment issue on a fresh computer...
This has made Python very accessible and useful to Perl refugees.
This explains the pervasive use of Python to "Automate the boring stuff".
It seems clear that the harder a language is to understand, the more a programmer will make searches. Not a linear relation, but it is common sense.
It seems clear that [reason somebody would do a search] ...
[0]: https://insights.stackoverflow.com/survey/2021#technology
I don’t know what they’re measuring exactly and how but on the surface it doesn’t pass the smell test.
edit: Here's the actual method - https://www.tiobe.com/tiobe-index/programming-languages-defi.... It doesn't count searches.
Probably. A lot of things I would add the language name to while searching for another language I qiickly learned tagging MDN on instead gets the best JS info, and once on MDN, navigating between topics rather than doing a new search for a related topic os much more common than the haphazard set of resources that you end up with for many languages.
Of course, that's a minor reason among the vast number of reasons why number of web searches explicitly targeting the language is a horrible measure of language popularity or impact.
> The ratings are calculated by counting hits of the most popular search engines. The search query that is used is +"<language> programming". The number of hits determines the ratings of a language.
https://pypl.github.io/PYPL.html
Which ranks languages based on number of tutorials searched for (via Google trends). It also has python at number 1.
I lucked out and learnt python 10 years ago so feel "ahead of the game". It's a language that feels so malleable...
Thre only negative is that type annotations aren't part of the core language. You have to run a separate tool (mypy) to check your types. Feels like it should be a flag on CPython or something.
The syntax
And it has one giant plus over PHP:
The module system
There is still one giant benefit of PHP over Python:
Performance
Let's hope that the Python devs will focus on performance so we get the best of all worlds at one point!
Personally, I would only consider languages very close in popularity to the leading one when deciding on the language for a new project.
Still, I don't think I would choose Visual Basic to build the next big thing though :)
Python's competition isn't PHP; it's Typescript.
[1, 2, 3, 4].map(x => x * x).filter(x => x < 10)
x = [1, 2, 3, 4]
x = map(lambda x: x*x, x)
x = filter(lambda x: x < 10, x)
x = list(x)
```py x = [xx for x in [1, 2, 3, 4] if xx < 10] ```
[x [asterisk] x for x in [1,2,3,4] if x[asterisk] x < 10]
which is still a little annoying because the x [asterisk] x gets computed twice. This is one of those little details that really annoys mathematicians, as I saw with SageMath for decades (I started SageMath -- which uses Python -- and got no end of complaints about the above). In the Magma programming language there is a "where" version of comprehensions that eloquently solves this problem as explained here: http://magma.maths.usyd.edu.au/magma/handbook/text/10
For example,
{ xx : x in [1 .. 4] | xx lt 10 where xx is x*x}
which you can try at http://magma.maths.usyd.edu.au/calc/
You can escape asterisks with a backslash. \* => *
from itertools import repeat
from operator import pow,gt
x = list(filter(partial(gt,10), map(pow, [1, 2, 3, 4], repeat(2))))
(please don't do this)
Python's problem isn't a lack of lambdas, it's a lack of consistency; for some things you use functions and for others methods.
filter(lambda x: x < 10, map(lambda x: x * x, [1, 2, 3, 4]))
def square(x):
return x * x
def less_than_ten(x):
return x < 10
filter(less_than_ten, map(square, [1, 2, 3, 4]))
That's probably the most underrated feature of python. Decisions about how the language should function like this which seem "restrictive" from one perspective, and yet force you down the avenue of good decision-making for readability/maintainability. Sure, it's possible to write terrible python, but you're generally cutting against the grain to do it.
You can express the above as:
[x * x for x in [1, 2, 3, 4] if x < 10]
Which in set notation is {x^2 : x in (1, 2, .., 4), x < 10}.
[x * x for x in [1, 2, 3, 4] if x * x < 10]
There is a subtle shift in semantics. The functional form defines a sequence of function applications whereas the list comp notation is more of a declaration.
>>> (lambda x: x+1 if \
... True \
... else x+x)\
... (10)
11
The namespace feature is more of a comfort tool to make those long names shorter.
In a 100KLOC codebase, 99% of the performance issues are going to come down to 5 or 10 lines of code.
Don't get me wrong, I'm extremely happy that MS is funding a multi-year project to improve Python performance, and I think it will confer enormous benefits to the ecosystem. And frankly I think that it's absolutely needed.
But for me it would also be weird to choose languages based on some notion of average performance. Like sure, a line of Go might be faster than a line of Python on average, but if the entire bottleneck of your codebase revolves around one line of regex then what is doing a rewrite actually going to accomplish?
80/20 rule? Probably. Then 80% of CPU time is spent in 20K lines of code.
But 1%? I don't think so.
A web project of 100KLOC will be a shit ton of features and CPU time will be spent in hundreds of different places.
Another issue is what I would call "code depth". Even if you find a few lines deep down in a framework or library that makes your specific use case slow - what can you do? Patch the framework? That comes with a ton of issues on its own.
% cd Python-3.9.1
% wc -l `find . -name '*.py'` | tail -1
843196 total
% cd ~/clones/numpy
% wc -l `find . -name '*.py'` | tail -1
256900 total
% cd ~/clones/scipy
% wc -l `find . -name '*.py'` | tail -1
397250 total
% cd ~/clones/django
% wc -l `find . -name '*.py'` | tail -1
383167 total
VB in the top 10? Matlab, R and Fortran so high?
Kotlin and Dart in the 30's? And JS not top 3?
With tons of ready-to-use libraries for string processing, machine learning, images, graphics, game development, web, etc., there is not much to dislike about it. It is my goto language for quick scripts -- works flawlessly on Windows/Linux/Mac.
The only downside is efficiency and being one-threaded, but if you are gluing together library calls, which you are most of the time, then it is good enough.
I used to love ruby, but their inner workings seem more ad hoc if you look under the hood (AST and broken operator logic)
I'm sure to some degree it's just that nobody likes whichever package system is the "one more" in their workflow.
I'm not saying Python packaging doesn't suck, it definitely does. But so does JS and the mess that the npm ecosystem is makes working with it it much more painful.
That's part of the problem. Python has lots of things that cover lots of things, but nothing does everything.
> It's mostly people thinking bare `pip install` is a reasonable way to add various applications to your system that complain about python packaging.
It is reasonable in JS, and I think it should be. Having to worry about virtual environments is a pain, and having to learn new tools to avoid that is a pain too.
> I'm not saying Python packaging doesn't suck, it definitely does. But so does JS and the mess that the npm ecosystem is makes working with it it much more painful.
I don't think that's a good point. The JS ecosystem adapted quickly to TypeScript, while Python is lagging behind. Most of the new JS features are reasonable, and the backwards compatibility is top-notch. Meanwhile, Python is spending brain power on pattern matching and :=. JS is missing something like Django, but on the other hand Python has no React equivalent. All of that without mentioning speed or the fact that JS has multiple implementations that works very well with almost all the ecosystem.
It's not. Even if npm install -g happened to work for you, it's insane to rely on it. These language package managers have a purpose in isolated environments but are incapable of building reliable, modifiable and updatable systems on their own. It's a good thing pip fails quickly so people don't attempt this.
My guess is that easily 95% of Python projects will never hit these issues. In all my years of professional Python programming we didn't hit them.
Most projects simply do not need to scale, and will not benefit from it.