Among developers, Python is the most popular programming language, followed by C, Java, C++, and JavaScript; among employers, Java is the most sought after, followed by C, Python, C++, and JavaScript.
Or so says the 2017 IEEE Spectrum ranking, published this week.
IEEE Spectrum, a publication of the The Institute of Electrical and Electronics Engineers, a technical advocacy organization, says it evaluated 12 metrics from 10 sources to arrive at this conclusion.
It claims to have culled data from Google Search, Google Trends, Twitter, GitHub, Stack Overflow, Reddit, Hacker News, CareerBuilder, Dice, and its own digital library.
https://www.theregister.co.uk/2017/07/21/python_java_c_programming_languages/
(Score: 5, Informative) by andersjm on Saturday August 05 2017, @07:16PM (3 children)
Two of the Python language's design tenets:
It's a language where programming errors tend to express as exceptions, instead of silently doing the wrong thing. Which means you get a chance to fix it, and a traceback text that very often points you at exactly where the error was made.
I don't know what it is about Python's syntax that makes you make mistakes, but for me it's a language that helps me produce robust code.
(Score: 0) by Anonymous Coward on Saturday August 05 2017, @08:08PM
Usually when I see that sort of language, what the person is actually trying to say is, "I can't copy-paste my code from one place to the other and it still works." While that is true, because Python uses white space to denote most blocks of code, it is also true that the same things can happen in languages that use braces. Sure, Copy-paste of a simple if block is more likely to be a problem in Python than other languages, but there are other constructs that will get you in more trouble being copy-pasted in other languages than Python.
The real problem is that people need to not blindly copy-paste, regardless of the language.
(Score: 4, Insightful) by lentilla on Sunday August 06 2017, @03:14AM (1 child)
I didn't realise "errors should not pass silently" was an explicit part of Python's design. Aside from the whole indentation thing, what we could term "silently introduced errors" is what trips me up again and again when using Python.
For example:
Autovivication. The gift that keeps giving. (The program prints "red", by the way - as it should, but it probably wasn't what the programmer expected.)
I find myself using spell-check on variable names (!!) a great deal when programming Python! At least in Perl, when autovivication ceases to be useful (in programs longer than a few lines), a simple "use strict;" at the top expunges that entire class of mistake.
Which is sort-of-cool, but in many cases I'd prefer an error at compile time. Exceptions are nice but I don't want to have to manually hunt down every logic path to find all my stupid mistakes.
I love Python, idiosyncrasies and all. Van Rossum has been very clear about documenting Python's behaviour and rationale from the start (doesn't mean I always agree with him) but at least the contract is clear. And when I shoot myself in the foot, as I do on a regular basis when writing Python - like that sample above - I laugh and think "did it again, you fool, eh? At least it only cost a couple of hours."
(Score: 0) by Anonymous Coward on Sunday August 06 2017, @11:48PM
Well, you could always use one of many static analysis tools for Python programs. Most will catch that specific error, due to an initial assignment outside of __init__ or thinking you are missing a property decorated function definition. A quick run through a test suite or bytecode compilation (PYCMD -m compileall -fq -j0 -d /tmp INPUT_DIRECTORY) will find many as well. Also, if you have a problem with indentation (PYCMD -m tabnanny INPUT_DIRECTORY) can catch many of those as well.