Gah, those wordclouds are horrible attempts of analyzing "what the questions are about". There is no attempt at normalizing term frequency, or removing non-informational words. So words like "get" and "using" get a high score.
It may also seem that the text analyzed is the entire post including metadata. For instance "closed" and "duplicate" both show, maybe just be because of "closed as duplicate"...
Maybe even including the answers. Which could explain why "pip" would show up so often.
The summaries are also pretty off. "vector" mostly because C++ is about 3D graphics vectors? No, probably just a whole lot of std::vector...
It's much better to just use a table of phrases/keywords, even if it takes a little more effort. Phrases are specific and have clear intent - using only the most common words leaves out critical context!
Some of the simple words and their prominence can be amusingly informative, though.
Take data structures for example. "string", "array", and "object" are about as equally prominent in both JavaScript and Ruby (where the dictionary is called "hash"). In Python, however, "string" and "list" far outweigh "dictionary" and "object", which probably says something about what kind of data structures Python developers deal with the most in their lives. Meanwhile, C# and Java seem to be all about strings -- Are people just casting everything to string because they don't want to deal with strict types? -- and PHP is the only language where more people feel like they need to ask about arrays than they do about strings. Which is not surprising since PHP uses arrays for basically everything.
Are people just casting everything to string because they don't want to deal with strict types?
No? How would that even work? It's not really a sensible way to draw conclusions about what people do with the language. For instance, you're much more likely to type 'Object' in Javascript than you are in Python.
> In Python, however, "string" and "list" far outweigh "dictionary" and "object", which probably says something about what kind of data structures Python developers deal with the most in their lives.
This statement is not true at all. There are plenty of developers that don't post questions to or answer questions on StackOverlow.
> but the method of studying a large population by using a sample size is pretty common and time tested.
Yep, and so is abusing it and making the wrong conclusions. It's equally as likely that dictionaries require far fewer questions than strings either because their methods are more intuitive or the questions most people come up with have easily searchable existing answers.
Seems like the most difficult programming is no longer cache invalidation and naming things. Its now about strings, and to duplicate arrays ... The stats are skewed because hordes of beginners. Mainly driven by what schools teaches and what languages has the most hype. That said Python is huge
. Damn you significant white space.
I'm sure there's lots of beginners to programming but most of the time when I find myself asking basic questions like "how to duplicate array Python" isn't because I couldn't spend 2 minutes writing a function to do it but because there already exists a generally accepted best way to perform this operation that leverages the standard library and there is seemingly no other way to discover what that is.
Knowing the right thing to do requires you be informed about the history of Python language design. Like you could just read the documentation and see that lists have a copy method but it doesn't give you a good grasp of what the alternatives are and why you might choose them. And prior to Python 3.3 you're expected to know that the best practice way to do this is to leverage an edge case in the slicing syntax or the list function. Doesn't matter if you're the best computer scientist in the world, sifting through the massive corpous of documentation and historical knowledge required to write good Python is nigh impossible unless you're willing to dedicate yourself Python.
This is something that languages need to tackle because the gap between doing a thing and doing that same thing in a way that follows language conventions and best practices is too damn high.
The best way to perform a specific action can sometimes change depending on what method is currently fastest. Copy, slice, instancing a new list object, the copy module, each can have their own code base. It would not be surprise me at all if which one is the fastest method has shifted several times between 2.7 and latest version.
That said, copying is in this case the end result of distinct different methods. In the stackoverflow answer, the only redundant way to copy is the .copy method list has. If I understand right it is just a convenient method in order so new programmers don't need to import the copy module.
list() is a common way to create a new list, and the constructor can take a initial sequence. Lists are sequences, so list can take a list, but that is just a side effect.
Slicing is very useful for taking the first or last objects of a list. if you take all the first and all the last objects, you get a copy. Its not the primary function of slicing, but a useful side effect.
The copy module is a lower level interface to work with python objects. As any other lower level interface it mostly used in exception cases when you really want a "deep copy". I have used that trick once in my whole programming career, and it was to work around a restriction in a third-party module for a corner case which they clearly didn't consider.
Python documentation is some of the best of any language, a lot of times you'll be able to find your answer quickly if you just look. The SO questions are almost all answerable with links directly to the docs.
This, above many other things, keeps me coming back to Python year after year.
1990 is calling and wants you back... But seriously, many of us simply don't remember that sort of book learning.
If it comes to you naturally, fine, just realise that people are different and have different skills, memorization techniques and care about different things.
Some programmers are like you (a tiny minority afaik) and can read a dry spec or a book and remember all the intricacies and gotchas. It takes a certain type of mind to do that. And I would note that none of the people I knew who could do that were particularly good programmers.
Others, most as far as I've seen in my more than a decade career, learn by making, experimenting and adapting examples.
This is made worse now in some ways because back in the day many editors used to have fantastically well written and edited help, and that has generally disappeared.
Press F1 on a type or function and you'd get reams of well written examples and explanations.
Now most programming languages don't, the documentation is sparse and they simply rely on Stack Overflow and Google to provide all the examples for them.
However, that means that old ways of writing things can stick around as often no-one edits a SO answer to correct it.
> many of us simply don't remember that sort of book learning.
You mean you haven't heard of books, or can't read, or can't be bothered? Presumably none of these so what are you saying?
> just realise that people are different and have different skills, memorization techniques
Fine, I agree totally, use those! But here's what the original poster said "generally accepted best way to perform this operation that leverages the standard library and there is seemingly no other way to discover what that is". If you can find the answer on SO, that's fine - you have your answer! But that's not what he said. He said there's no way of finding it. I said it's in books, you say it's on SO, so there clearly is.
> Some programmers are like you and can read a dry spec or a book and remember all the intricacies and gotchas
Which I can't and don't. Please re-read my penultimate sentence where I said it's ok not to, nor was there need to. Kind of twice in fact ("You're there to deliver results correctly to the business, not deliver idiomatically perfect code." -and- "There's NO shame in not crawling into the furthest, darkest corners of a language.")
> And I would note that none of the people I knew who could do that were particularly good programmers
Oh noes, I haz been trolled :)
> Now most programming languages don't,
No language I've ever used ships with a tutorial (oh wait, delphi's did. Rather crap but it was there). Python's online docs are ok (not great, ok). So pick a book. I already recommended one. Reading is the same whether it comes from paper or phosphor. Just don't complain it needs work. It does. Sorry.
From experience: not knowing how your tools work is a recipe for vastly increasing your workload. Reading a book is a boring, tedious shag but will give you the greatest savings of time overall.
> learn by making, experimenting and adapting examples
Yup, that too. Books AND that. You're quite right. I should not have overlooked that.
Sorry, phrased that badly, I meant that being able to reel off tech specs wasn't an indicator of being a good programmer. For example, one guy was pretty good, but another was literally terrible, couldn't actually program, just able to talk about it.
Hmm, you're right, I agree, but you need to understand a language before working on a project (OK, maybe that's my style, maybe others interlace working + reading).
But the original poster claimed info was just so hard to get and I said it wasn't.
Horses for courses, ok. In reality it's books + SO + lots of online info + your local expert (there's usually one at least, though expertise is relative) + transferable skills from other languages.
All I'm saying is you need that info, and it's there, one way or another. There's so much info now out there compared to when I started programming. It's there, use it.
I did, years ago before I had a computer and when I got an opportunity I would type programs at school/terminals/store computers. I think being forced to visualize the code before can help because when you sit down it's just typing.
I often say that Python is the best at nothing, but pretty good at most things. And hence it became huge by the sheer appeal of being versatile. Life is short and most people needing to program are not programmers. Also many programmers didn't start as such, and were simply looking for an easy way to solve a task.
There is a bit more insight to be found by reversing that - Python is simpler than other programming languages and achieves that by sacrificing a little power.
Compare it to C, which it has displaced as an introductory language. Python and C are superficially interchangeable to a beginner, but to learn C you have to invest time into pointers and memory management. Python sacrifices the efficiency of direct memory management to avoid the complication of pointers. Arguably, this is a significant benefit because it also cuts down on ways to introduce bugs.
Compare it to a Lisp - Python has a pretty inferior set of basic capabilities (can't even use a dict as a dict key, drives me mad), but that just means there is only one easy way to do things that everyone uses. Less room to think up clever ways of doing things, less complexity reading other's code.
Being the 'best' language for a task has a huge cost - incidental complexity created by including specialist constructs. Python's success suggests maybe programmers prefer this complexity to be encapsulated in a library rather than the language core.
Curious, is this actually something you want to do often? While there is no hashable+immutable frozendict ala frozenset, you could throw one together or even define a hash function on a subclass and "swim at your own risk" not to mutate it later.
I've encountered this enough with lists and the obvious solution is to cast them to tuples. Can't say I've found the same with dicts tho.
As for the comparison with lisp - in most lisps this is a non issue because nearly all structures are immutable
Absolutely. For me it is a 50-50 chance whether I have data in a dict that needs to be mapped to something or have data in a list/tuple that needs mapping.
Many major programming languages undersell how natural key-value data structures are; usually by providing unwieldy mapping data types. Clojure has spoiled me.
> you could throw one together
Yeah, I do. Most Python programmers wouldn't see a need for that, but that can be attributed to Python not having the capability by default and so they've just internalised not to use dict for anything that needs to be a key. World's mildest form of learned helplessness, I suppose.
> Most Python programmers wouldn't see a need for that, but that can be attributed to Python not having the capability by default and so they've just internalised not to use dict for anything that needs to be a key.
You're being extremely uncharitable here.
To a Python programmer "using a dict as a key" is a nonsensical idea for the same reason "using a list as a key" is — both dicts and lists are mutable. Python programmers don't think of dicts or lists as synonymous with their content.
I'm assuming you don't want to literally use a dict as a key, you want to use the keys and values contained in a dict as a key. Nothing stops you. You just have to say it:
point = dict(x=4, y=5, z=1)
point_reviews = dict()
point_reviews[tuple(point.items())] = "A+++ great coord would point to again"
You might wonder why you can't just use dicts directly. Again, dicts are mutable. What happens if you write:
point = dict(x=0, y=9001)
point_reviews = dict()
point_reviews[point] = "Love how it's over 9000 here!"
point["y"] = 8999
result = point_reviews[dict(x=0, y=8999)] # Is this a KeyError or not?
In the simplest case where you have a predefined list of keys, I'd suggest using a namedtuple instead of a dict. If you need to treat a dict's content as hashable but can't enumerate the keys, `tuple(d.items())` is probably the best choice in recent Python versions. Be aware though that in older Pythons you can't rely on stable sort order of dictionary items, so you have to use something like `frozenset(d.items())`.
Of course, if you can absolutely guarantee how the dictionary has been constructed, it is possible. No rules are absolute. But in my experience, frozenset() is probably better:
(Or sometimes even id(), as, if you are confident enough that the dictionary is identical, that might be because it came from the same place. If you are building a reverse dictionary, say, or a cache of indices. Though obviously that it is much more situationally dependent.)
Well. Now that dictionaries remember their order in newer Python versions, there is a case to be made that dict(a=1, b=2) is not the same dictionary as dict(b=2, a1). So they should be different dict keys, if they could be dict keys.
That value will not change when the contents of the dict are updated. You’re keying on the dict itself rather than the hashed contents. That’s what you want in some situations, but it’s not what the parent post is looking for.
It's also not reliable, since the same address can be reused if the dict is GCed. This is actually really easy to induce in Python, since it uses immediate refcounting. In my REPL (3.7.3):
>>> a = {}
>>> x = id(a)
>>> del a
>>> a = {}
>>> y = id(a)
>>> x == y
True
Any hashmap will have problems with storing mutable objects, where the hash value itself can change after the object has been stored, causing some very unwanted paradoxes.
And that is the problem with Python dicts as keys.
I don't think mutability is a concern if your goal is to get a bidi map between strings and (mutable) _instances_; i.e. if you just want to use the reference to the dict itself as the hash rather than the contents of the dict itself.
It’s been a while, but I’m pretty sure the reason why a dictionary can’t have a dictionary as it’s key is because the dictionary class doesn’t implement the __hash__ method that would compute the hashcode.
Sure, but as others have mentioned, you can make your own choice by subclassing dict and defining your own hash function, as long as that function is defined in a way that follows the appropriate rules.
When I read this my first thought was "you should use a FrozenDict", but looking into it, it seems that it doesn't exist; I assumed so because of FrozenSets (hashable sets).
You can still create a hashable key from a dict with FrozenSet(mydict.items()).
What Lisps are you thinking of? In Common Lisp, Scheme, and Emacs Lisp, at least (IIRC), all composite data structures (strings, vectors, etc) are mutable, or can be. The only Lisp I can think of in which "nearly all structures are immutable" is Clojure.
Good C bindings and a willingness to accept that it wasn't ever going to be good at doing low level fast code are an underrated facet of how python grew so popular.
Golang, by contrast, is really quite schizophrenic sometimes about whether it wants to be a high or low level language.
Bingo. When you just need to get something done, Python is great. Some quick googling to find the right libraries for the task, and then some caveperson programming, and the deal is done.
Outside of lisps, I find Python to be one of the simplest syntaxes, so the only effort is the logic to solve the problem.
I've been programming since I was a teenager, and for a long time I found myself struggling with my syntax and edge cases. Once I started using python, about 10 years ago, programming quickly turned into "what's the best way to solve this problem", instead of "wtf do you mean null pointer".
The feeling is quite the same when switching from C to D. You don't have to use the advanced features of the language, but they're there if you want them.
I actually use Stack Overflow to look for idiomatic ways to do things in languages that I don't have a lot of experience with. So I literally search for things like how to duplicate arrays, even though I'm quite capable of achieving the required output myself. In fact, I use SO almost exclusively for "Is this a bug with a common workaround" and "Is there a more idiomatic way to do this" questions.
Any Q&A board is going to run into this problem. It takes a lot more work to become an intermediate or advanced user. Given enough time and popularity a topic will be overwhelmed with beginner q&a.
Do people really use StackOverflow for answering job-related programming questions? The only time I found the questions on there useful was when I was a first year student learning programming. Maybe I am just bad at searching / asking.
Some programming language and frameworks have more active communities on StackOverflow than others.
So in my sprints, I would typically have 3 tasks in progress at once: 1 I would work on myself, 1 would go on Stackoverflow waiting for the answer, and 1 would be something that required progress from a different team in the company (like a new API endpoint so I could do something on a frontend, or different service)
It was pretty efficient for me. In some communities, the real thought leaders and framework developers are on stack overflow, watching the hashtag like a hawk.
You can also use github issues on the actual package you have issue with pretty well too, alongside it.
So you're really crowdsourcing a lot, and evaluating if that solution is correct enough for your implementation.
But so many times, especially with frameworks, the answer is a good copy and paste job. your mileage and use case may vary.
Definitely a lot of beginners, many learning it in school, and many learning programming not as their main thing, but as a tool to use in whatever field they are in. More like MATLAB than Java or C#.
But I believe that a fair bit of them will continue to use Python in the future (and get over the beginner problems), as they get jobs, startup ideas, side-projects. Curious to see what effect that has over time.
I think a big part of it is how much canonical documentation and resources has improved in JavaScript vs. how much people are struggling with it in Python (as someone who does more Python than JS but does both).
Python libraries tend to have less documentation and their documentation tends to be less live whereas JavaScript has been more stable lately (something I didn't think I'd ever write).
Funnily enough the last time I really struggled with a JavaScript library's docs it was Tensorflow.js (a Python port).
Also, I'd love to see a comparison that checks "all" JavaScripts (+TypeScript).
Another thing I've noticed is that the Python community in StackOverflow is very nice and considerate most of the time compared to the JavaScript crowd. (Being a part of both).
This seems true of the Python community in general. I've yet to meet anyone that's not nice and really supportive (there are bound to be some, but I've not knowingly interacted with them).
I think it's a great measure of a programming language's ecosystem when taking part in the community is such a pleasure.
From the beginning the language has taken great pains to be readable and comprehensible. It makes sense that would breed a community that values empathy.
I don't recommend heading over to #python on Freenode then, if you want to maintain that belief! They're a bunch of purists, it's hard to squeeze a practical response from them a lot of the time.
> Funnily enough the last time I really struggled with a JavaScript library's docs it was Tensorflow.js (a Python port).
I think it's interesting how you mention that you struggled with the docs of Tensorflow.js and attribute that to it being a Python port, rather than it being the absolute cutting edge of machine learning. Are other state-of-the-art , pure JS ML (or similar level of complexity and novelty) libraries better documented?
That's a fair point. In this particular case the documentation was significantly worse than most new JavaScript libraries I'm used to and pretty similar to most Python libraries I'm used to.
Sometimes parameters were missing, what values you can pass in were missing and there was a general lack of documentation on how to do things (sans a few tutorials).
I can name a bunch of examples. Here is a very simple one: what values can I pass as a loss function to LayersModel#compile? (I had to dig through the code to figure it out)
Hmm, this has not been my experience with Python libraries (I can't speak for JS ones). The vast majority are well-enough documented that I've never had a problem, and I strive to document my important libs at least this well:
It always amazes me that the Python community is okay just missing indices for their API documentation. I’m so used to Rust [1], MDN [2], Apple [3], Qt [4] starting their docs off with great indices. Obviously, those are all “commercial” docs, but just indices alone is a huge help.
To be clear, I think you’ve done an absolutely great job writing the prose — I just don’t get the cultural conventions around Readthedocs :p
(There’s still wild differences in quality between those four. It seems like documentation UX would be more of a solved problem by now.)
Oh, thank you, that is extremely useful to include. Too bad Sphinx doesn't make these things easy, I spent some time reading the docs to figure out how to include a link to the index and there was no reference to it. In the end, this Stack Overflow answer was the only thing I found that actually mentioned how to create it:
I like Python and it's my main language currently after years of C++ and Java. My main problem with Python is that it's really easy to create really messy code that no one can follow. And I see it often because everyone is using Python these days. For example, you have an undocumented function with 6 arguments and have no idea what these are (having bad names also doesn't help, but that's not a Python specific issue).
Type hints and annotations are a step in the right direction. But the adoption is still not high. That's the blessing and curse of Python - it supports many good practices but it doesn't force you to use them so it really depends on the programmer.
True but take my function example. In Java for example you will have the types to click on to figure out quickly what the arguments are. Another example? In Python it's "easier" to make spaghetti code because of the scoping of variables that are less strict. I can give many more examples like this.
Anecdotally, it does feel like a slightly worse problem in Python. It's got an 'easy to learn, hard to master' thing working against it. It's a little TOO accessible (if that makes sense).Hiring Python devs has always been the hardest in my experience. It's tough to separate the wheat from the chaff.
It's less a problem with the language syntax and more a problem of the low bar for entry.
To put it another way, "3 years of experience writing Python code" could mean hacking on scripts or it could mean Enterprise level system design and implementation. Hard to hack around on scripts in Java.
I think that the main problem is that novice programmers write python code just because they are domain experts since it’s quite easy to pick up.
But sadly it’s not a kind of code that any seasoned programmer would write.
It happened to me to reduce a >500 loc monstrosity to a rather manageable 50 or 20 loc or something like that...
Agree. And as someone that is guilty of writing really messy code and then later Karma had its revenge as I had to clean up and professionalize someone else's tangle of python scripts, I think this is common for scripting languages. A lot of times things start out as one-off scripts, which then become personal scripts, which then become shared scripts, which then become critical to back end automation. Especially in the infrastructure/automation space, you'd be amazed at the horror stories of ducktape holding things up behind the scenes. Even in fancy places like big banks, or fortune 100 businesses. Things emerge organically, and most automation doesn't go through a formal specification/design/test/acceptance process.
Few people set out to intentionally write messy code. If I had to do it all over again, my earlier code would have been much cleaner.
It just means that almost all trivial questions about JS have been asked and answered, now it's Python's time.
---
Also I bet that if each language's words were compared to the overall vocabulary for SO, or at least to the cumulative one for these languages, the differences would stand out more.
And of course, the usefulness of a word cloud visualization is highly dubious to me.
I’ve used python for a while but mainly for small scripts. I’m often googling answers. (Is it myvar.len() or len(myvar) or myvar.__len__.?) do I use conda or pip or... 2.7 or 3.?. Oddly I’ll use books for other languages (Perl/JavaScript).
It’s a fine language and easy to get running but it seems harder to memorize things in it vs others (if I was 100% of my time using it, it probably would easier).
> ...it seems harder to memorize things in it vs others
This x10. I love Python, and use it for small scripts when I get the chance (just used it to test some probabilities last night even), but it seems like I constantly have to look things up all the time in it and can't seem to remember even common, basic syntax in it, despite having used it quite a bit. I really don't know why. I can leave and come back to other languages and not have anywhere near as much difficulty.
Interesting - I had the complete opposite experience: Python was the first language I'd tried in a long time that just worked as I'd expected it to. After understanding the initial indenting rules, most of the code I tried could be written as pseudocode, which surprisingly worked the first time.
I was really impressed, most languages have so many stupid syntax requirements, which really shouldn't be be needed these days - everything compiles to the same assembler code so lets not pretend these languages are doing magical things.
The goal should be for programmers to get the logic across to the computer in the simplest form - and Python is pretty good for that (apart from zfil - seriously, can you get any more unintuitive)
> everything compiles to the same assembler code so lets not pretend these languages are doing magical things.
Nope. Some languages get compiled into binaries that are more performant with a smaller footprint. Some have a runtime that provides features like garbage collection and runtime evaluation. Others let you define macros that run at compile time, extending the syntax of the language. Some are graphical live environments. Others offer full high-level concurrency.
Languages have different syntaxes to support the features that their interpreters or compilers can convert into the code that can run on the target environment. This is not going to be the same across all languages, and there are tradeoffs.
For a language that sets out its principles so clearly its amazing the hostile outcomes that have resulted.
For example, unlike every other language there is no "unique" function that operates on streams /iterators. Why is that? Because you can do that by creating a set(...) and Pythonistas think there should be only one and one good way to do something. So now nobody ever knows the answer to this and 100% of people learn it by googling and finding the answer on stack overflow.
It doesn't help that nearly everything is untyped and consequently IDE completion is all but useless.
It's not actually. You never call dunder methods directly, you use them through the built-in function or operator. So it can be neither myvar.len() nor myvar.__len__
15 years of Python here, started in 2.4. Day to day Python is not more complicated to use. It's actually easier due to many bugs fixes, quality of life features and better error messages.
However, Python does provide more tools to do more complicated things (async, type hints, etc), but that's not what most people use. They actually don't even know about it, and don't have to care. So it's not the questions you see on SO.
Python has gotten much, MUCH more popular, and we are currently facing a wave of new beginners. Particularly from schools (it's now the default teaching language in most countries) and from loads of workers that can benefit from manipulating data with programming and are attracted to Python for this.
It is precisely because Python is still easy that it's that popular: it doesn't benefit from massive existing code bases like Java or accidental monopoly like JS. We just have a lot of people creating a lot of libs for pretty much everything, because everybody can do it.
I also think the aesthetic of the language plays a big role. Python has been designed to allow you to dev with it with just MS notepad if you have to. It means you don't need to learn about a gigantic and complicated ecosystem to be productive with it (although it does exist): it's a huge help for all those people that are just getting started or not a programmer at heart. It's also harder to create very ugly code because you don't know what you are doing, and if you do, the result will not be as bad as with other languages because Guido made sure of it.
It's also why you don't get multi-line lambdas. Everything is a compromise.
I mostly agree with you, but still think that Python could be way simpler and equally powerful. I'd love to see a language similar to Python, but with named structs instead of classes, for instance.
That is one thing about Python that has always been interesting. For new programmers, it's such an attractive language because it's very simple to get up to speed and pump out usable code.
But to really start leveraging Python for more serious projects it's extremely useful to use Classes. And that's actually an appreciable bump in difficulty for inexperienced devs. I've seen go to great lengths to avoid it.
Maybe named structs would be a simpler way for them to level up complexity, especially if they're coming from a C background.
>It's also why you don't get multi-line lambdas. Everything is a compromise.
Arguably too much of a compromise. This is just Guido doing a "because I say so" and imposing his bias against functional programming. Give me a properly-designed language like Ruby any day over Python's bag of compromises.
On the other hand, as someone who reads other peoples code just as my as I write my own, maybe by the time your lambda is many lines it should have its own name. And maybe the name should be really informative about what the function does.
And yet Ruby never took off outside of RoR and is dying. Lisp and Haskell are still niche languages.
So somehow, languages promoting big chunks of anonymous code never win never win the public heart.
In fact, when you are force by an accidental monopoly to use ine, you get js. What do people do in JS ? Multline lambda are mapped to property names or replaced with await. Registries are used in every framework. We spent 2 decades fixing JS to use as little callback hell as possible.
Coming from Perl, Python library documentation makes me want to tear my eyes out. No I don’t want a cutesy fucking module homepage, I want reference documentation with some examples. Authoring PyDoc was the worst experience too. No I don’t want to install and configure a static site generator in order to have rich text documentation.
It's strange to see this is your experience, because I had the exact opposite: Python documentations are usually very comprehensive, nicely formatted. Important projects have very good documentations and setting up a new documentation is very easy with Sphinx. Maybe you should try it again, it might have changed a lot since you looked it.
Sphinx starts from the point of view that you're going to write your documentation as if you were writing a book, then on top of that it has some optional features for pulling in information from source files.
Most of the others start from the view that you're autogenerating documentation from source-code comments, and on top of that there are some optional features for pulling in some extra content from documentation-specific files.
I think the Sphinx way tends to produce better documentation in the long run, but it takes more effort to get to something just-about-adequate.
I understand your point, and Go is probably better in this regard, but it's pretty easy to get started with Sphinx with autogenerating documentation from code. You don't have to manually write anything.
Some python documentation conventions are weird, to be sure. But I’d rather have an eternity of Sphinx build toolchains than the hell that is making POD/Perldoc work for medium-to-large projects (or small ones, for that matter).
I started with python 1.7, two decades ago, and I don't find it any harder to use than back then. The language is pretty much the same as in the late 90s, complexity wise.
But back then, it was an insider's language, my teachers didn't know it existed. Then, year after year, I saw it become more and more popular.
But it is still so easy to use. Nowadays, I use it to teach programming to teenagers, and in less than a week I can teach them pretty cool and complex stuff (UCB algorithm, markov chains, simulated annealing, traveling salesman problem) because the language is so easy it does not get in their way.
Probably both. Python ecosystem is expanding super fast. Look what is happening in data-science. Newborn Python libraries getting outdated too soon just like in JS ecosystem.
Expanding? Hope they expand & knock down most of the garbage documentation I've seen in python. I don't need any more library ref static sites like they do with java but with a python feel to them. Give me a functional example of how to use your code, not that you have lots of special methods that do things. Show me how those things are done.
Userguides and references are both important parts of software documentation. A guide that covers problems and their solutions is a good way to start learning how to use a library but when you want to do something that isn't covered by the Userguide you absolutely need a reference that just lists what functions are available on which time in a bare bones manner.
More popular, especially for homework assignments (i.e. among people who don't know how to search and don't understand Python well enough to read the docs).
I'd say the former: Python is becoming more and more common as an introductory language, and is used as "glue" in many fields that people try to get into (AI, "data science", ...). There's also been a few areas where complexity has been added (asyncio in my mind being the main new source of confusion), but I don't think those are common enough to have a huge impact.
I do agree with the original contention that it's just a proxy for popularity. All of the things that you just mentioned may be factors. But at the end: these factors are probabilities that are mixed together in a nonmonotonic way somehow, and then multiplied by the total number of people out there doing stuff with the langauge. I would expect that that latter aspect is the dominant one in determining the ranking by language.
I would expect advanced people to ask just as many questions as beginners (they just do more advanced stuff, and ask questions relating to more advanced things pertaining to the langauge). Good documentation does not stop people from asking questions, as questions are frequently asked to which "RTFM" is the answer. Schools? Actually pupils asking "do my homework" questions is probably a driver in the opposite direction.
I can't disagree with you because that's an issue of semantics. I would define "popularity" as the number of people using the language, regardless of skill level.
By that definition, I'd guess that Python is near the top due to its recent dominance in data science, but Stack Overflow isn't proving or disproving the idea either way.
Using my definition (and likely yours), JavaScript is certainly the most popular. But it's hard to discount the many huge organizations using Java and C#. Their beginners might not be using Stack Overflow as heavily because they have in-house mentorship.
Seem to me that Python has won. What I mean by that is that it is used almost everywhere and there is almost no compelling reason to use anything else. You want web? Django, plus a million other frameworks, all well tested and documented. Machine learning? Tensorflow, Keras or PyTorch. Scientific computing? Numpy.
For the last two decades people have complained about (C)Python not being multi-threaded, not jitted, not having tco, being to simplistic and so on. In practice it seem to have mattered very little. For the applications where it do matter, like if you are writing your own language vm, compiler (but see PyPy) or garbage collector, you have to ask "Yes, ok, but how often do you do that?"
There are plenty of compelling reasons to use other languages. Macros, types, threads, interfaces, lambdas, tail calls etc.
But what matters in this world is short term profit. Python is easy to get started with, has a ton of frameworks than can be duct taped into semi-working software by mostly anyone and is taught in many schools.
The majority of the people in the world that can benefit from writing computer programs for the most various purposes are not professionals, nor desire to be.
Computation is a powerful tool wide incredibly wide applications, and Python makes this tool accessible to humanity in general. That is no small thing.
Macros, types, threads, interfaces, lambdas, tail calls, etc. are incredibly niche interests, and perfectly unnecessary for the vast majority of computations that people would like to perform.
While python does lack in many areas i think your list is a bit off. For macros, Python is one of the most meta-programmable language ever (for better or worse). Types, interfaces and lambdas exist. Threads also, caveat GIL, but also multiprocessing.
One exception is GUI applications. There are Python bindings to popular GUI frameworks but my experience it doesn't always feel like 100% pythonic. Python is not perfect choice if you want to deploy your application as binary. Actually it is downside of all interpreted languages.
This may reflect the recent addition of features to Python that were not really needed.
Another problem is "virtualenv". With more "version pinning" capability, there's an increasing tendency for Python programs to require their own special snowflake environment.
I keep seeing install instructions which begin "Install virtualenv".
Package authors then worry less about backwards compatibility. That's the sort of thing that generates Stack Overflow questions of the form "Why isn't X working with Y".
My first thought on reading this was the guess that, while the questions about Javascript are about fewer topics, the questions about Python are more widespread (because it gets used for more different kinds of things). In other words, if you looked at the volume of questions _read_, you might still see a substantial lead for JS, but it's even more likely that your question has already been asked (and answered) on SO, thus fewer new questions than for python.
I wonder if this is a combination of JavaScript frameworks becoming more sophisticated and offloading concerns from developers and the sheer exhaustion of trying to get a question answered from SO without the host of problems involved in simply asking the question.
It's often easier to ask and answer your own question on the corresponding Github issue tracker and let Google index it, then to run the SO moderation gauntlet.
The biggest Universities in Norway switched some years ago from Java to Python as intro language. Think the Universities are a large driving force in the long run.
Yes, that always puzzled me. Same with Jython which has a much smaller following than JRuby. I think with Clojurescript it's a case of really adding value whereas Python to JS is largely syntactic sugar.
Ask a question for (server) Javascript- 99% of people aren't going to try because the code is too unruly to deal with. Its simply faster to google and debug.
Ask a question in python- python code is simple enough to copy paste into SO. And given python has hordes of newbies, they don't realize google is probably a better place to look.
This synergy of situation is why Javascript is getting less questions.
EDIT: I program in both, I don't see why this is invalid.
It may also seem that the text analyzed is the entire post including metadata. For instance "closed" and "duplicate" both show, maybe just be because of "closed as duplicate"... Maybe even including the answers. Which could explain why "pip" would show up so often.
The summaries are also pretty off. "vector" mostly because C++ is about 3D graphics vectors? No, probably just a whole lot of std::vector...