Python overtakes JavaScript as most questioned language on StackOverflow | Hacker News Reader

Python overtakes JavaScript as most questioned language on StackOverflow

globalapptesting.com

303 pointsnnx161 comments

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...

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.

> 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.

Not saying anything about the parent comment, but the method of studying a large population by using a sample size is pretty common and time tested.

Yes, but SO participation is self selecting (self-selection bias), and is not a random sample of the larger union of non-SO and SO population.

And the 'statistics' on the data was presented as a word cloud, which is not a time-tested way to understand statistical relationships.

> 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.

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.

>”string” and “list” far outweigh “dictionary” and “object”

“Dictionary” probably loses a ton of hits by the split with “dict”. And “object” is basically a dead word in python now.

Plus, string and lists are typically hit by newcomers before they are taught dictionaries and classes. A lot of SO questions come from homework.

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!

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 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.

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.

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.

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.

> can't even use a dict as a dict key

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

Not often, but when you do want to do it, it’s frustrating (and unusual for Python) that the natural and obvious way doesn’t work.

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()).

Ah nice. Yes that last suggestion is probably a more simple and elegant approach than anything I'd mentioned / thought about

You don't really need a FrozenSet if you're already willing to iterate over this dictionary. You can just use a tuple, which is also hashable.

tuple(d.items())

That depends on the order in which the values are are returned by items(), which you likely do not want.

    >>> tuple({1:2,3:4}.items()) == tuple({3:4,1:2}.items())
    False
    >>> frozenset({1:2,3:4}.items()) == frozenset({3:4,1:2}.items())
    True

Good point

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?

More detail on this issue is explained here: https://wiki.python.org/moin/DictionaryKeys

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())`.

Good information, and well put. A small quibble: you should probably almost never use tuple(), even on recent Python:

    >>> tuple(dict(a=1, b=2).items())
    (('a', 1), ('b', 2))
    >>> tuple(dict(b=2, a=1).items())
    (('b', 2), ('a', 1))

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:

    >>> frozenset(dict(a=1, b=2).items())
    frozenset({('b', 2), ('a', 1)})
    >>> frozenset(dict(b=2, a=1).items())
    frozenset({('b', 2), ('a', 1)})

(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.

    dict(a=1,b=2) == dict(b=2,a=1)

is True (on 3.7.3). I'm not too keen on introducing a third type of equality on the same type, even if it makes some theoretical sense.

And worse, the dict's values may themselves be mutable. So even tuple(point.items()) is not a sensible dict key in the general case.

id(dictionary) is the key you want: immutable, reliable, cheap.

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

Several times, when working with Lua, I’ve made what I call “Janus tables”.

Give them a string, they return a table or function. Give them the table or function, they return a string.

It’s a useful technique that you can only apply if your hashmap can map anything to anything.

What's a use case for needing to be able to do this?

https://en.wikipedia.org/wiki/Bidirectional_map

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.

Yeah, I don't actually know if Python computes hashes for dicts by content or "identity".

I just assumed it was the former, based on the fact that dicts are disallowed as keys.

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.

This is definitely the proximate reason.

The reason for that choice is because the object is mutable.

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.

Python probably has a set type, but a common general use case for use an associative array as a key is when making a set.

dict = { "foo" : "bar" }

set = { dict : true }

set.has_key?(dict) # true

I'm sure there are other use cases where dict keys can be convenient.

Yes, Python has both a set type and the immutable "frozenset" type, that can be used as a dictionary key.

someset = {"one", "two", "three"}

"one" in someset # true

frozen = frozenset(someset)

somedict = {frozen: "example"}

frozen in somedict # true somedict[frozen] # "example"

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.

> Can't say I've found the same with dicts tho

I would think a NamedTuple would do the trick? (https://docs.python.org/3/library/collections.html#collectio...)

Jack of all trades, master of none

but often better than master of one

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.

protip: you can also increase your StackOverflow clout by merely asking or answering the most generic basic questions.

You'll look like a community expert and thought leader in no time.

Helps the resume inhalers that weigh these arbitrary things.

More complex questions about specific frameworks or how that might work with your ORM and memory cache just don't get the attention.

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.

I did, you just abstract the problem out.

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.

I graduated 5 years ago and I still use it daily.

StackOverflow/Python version of Eternal September.

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.

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.

Like for this specific example:

https://stackoverflow.com/questions/2612802/how-to-clone-or-...

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.

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.

Python's documentation is not the worst, but it's certainly nowhere near the best.

As for JavaScript, these days I almost entirely rely on the MDN documentation and hardly go to Stack Overflow for that topic.

Same, I find I don't need to go to Stack Overflow because MDN has good documentation.

Came here to write this. MDN is a blessing.

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).

If anyone is interested in engaging by the way: https://sopython.com/

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.

That's a good point! Though I think a big part of it is that the web stack changes a lot more often which breeds a lot of fear that kills empathy.

I've met some of the nicest people I know in the JavaScript open source community and some of the most empathic though.

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.

That's because programming in python is fun so we aren't as stressed! I'm only kidding but there might be some truth in this worth exploring.

> 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)

( https://js.tensorflow.org/api/latest/#tf.LayersModel.compile ) There is just consensus in JavaScript that things that don't get well documented don't get adoption.

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:

https://yeelight.readthedocs.io/

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.)

[1]: https://docs.rs/reqwest/0.9.15/reqwest/#structs [2]: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_... [3]: https://developer.apple.com/documentation/corevideo [4]: https://doc.qt.io/qt-5/qtwebengine-index.html

What do you mean by index? This is what I think of when I hear "index":

https://yeelight.readthedocs.io/en/latest/yeelight.html

Rust does the same, as far as I've seen (although the docs are a bit too index-heavy). Do you mean something different?

Maybe they mean something more like this page https://yeelight.readthedocs.io/en/latest/genindex.html which your Sphinx setup appears to be generating but the theme doesn't seem to be linking to.

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:

https://stackoverflow.com/a/42310803/28196

The default theme adds a link to it for you in the header and footer. I'm not sure why some other themes don't.

This is exactly what I was thinking of.

Thanks for pointing this out, and thanks to Stavros for promptly engaging too :-)

MDN is a wiki though, run by a nonprofit and written by the community.

Yes, but it’s backed by enough interests and money that it’s still not fair to compare to a typical FOSS or hobby project :p

There is no such things as the js doc. Only a huge number of 3rd party websites such as w3school, mdn, so, etc.

Also python has readthedoc for non stdlib doc, for js it's very heterogenuous.

All in all, I think the doc situation could be much improved, but not compared to JS.

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.

I have my problems with Python, but I'm not aware of any language where it's not "really easy to create really messy code that no one can follow".

Bingo. I’ve made disgusting messes of Java, JS, OCaml, C...

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.

No if you see the questions, they are the same over and over, for js or python. Simple things you can google, answered a 100 times.

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.

They don‘t and many of the dynamic features of Python (and Ruby) cannot be efficiently compiled. That‘s why it relies heavily on C modules.

> 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 perl, a lot of my searches end up at perlmonks. A lot of great answers for more arcane :) perl.

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__

Well, x.__len__() is the same as len(x). You’re just supposed to remember not to use it (makes you wonder why they chose len(x) instead of x.len())

or x.length, since length should be a property like it is in Ruby and JS.

In Pandas, a DataFrame's shape is a property and not a function or method.

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.

Is it happening because of Python getting more popular or getting more complicated to use?

Maybe due the usage of Python in AI

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.

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.

Ooooh that's an interesting idea.

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.

@dataclasses?

People have not caught up with 3.5+ yet. I see plenty of code not using f-strings, chainmaps, pools and the likes.

We can't expect them to known about dataclasses yet.

>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.

I looked at it last a month ago. It was terrible.

> setting up a new documentation is very easy with Sphinx

As per my original comment, the idea that documentation should require some kind of external markdown static site generator is bizarro land.

How would you want this to work? The alternatives to Sphinx I've used (Javadoc, Doxygen) more or less work the same way.

I think there's a big difference.

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.

Exactly on the money. I want to document my library, not create a website.

Having just had the pleasure of using Sphinx for the first time, I can only underline what you wrote.

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).

> the hell that is making POD/Perldoc work for medium-to-large projects

Such as?

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 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.

In this sort of context, "most questioned" is probably not much more than a synonym for "most popular".

Couldn't disagree with you more.

"most questioned" is some combination of:

- many beginners

- incomplete or outdated documentation

- not taught (or taught well) in schools

- SO users who don't search for old answers before posting again

See how none of those things, even mixed together, are a good proxy for popularity?

We don't know the mix of the above factors for Python, but without better analysis, the headline here is meaningless outside of its specific claim.

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.

> See how none of those things, even mixed together, are a good proxy for popularity?

I'd say that having many beginners alone is enough to qualify as "popularity". There are more people learning programming that programmers.

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?"

It has mattered, you're seeing the result of the survivor bias of what can be implimented. No language is a cure-all, python included.

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.

Sure thing.

Until the last paragraph.

There comes a point in every amateur programmer's evolution when learning which way is up and picking more powerful tools is the right thing to do.

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.

It's not the same thing.

In Python you don't have the full power of the language at your disposal, you can't add primitives like if/class/etc; in Lisp, the sky is the limit.

The lambdas are crippled; as are the threads, using processes is a completely different game.

I would consider spending some of that energy on learning Lisp.

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.

Just a guess, of course.

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.

I find the term 'questioned' almost hilarious

A lot of universities are now using Python at the beginning of their curriculum, that may be one of the cause.

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.

I think it's partly because a lot of academia use it and most of those people are without formal CS degree which is completely fine.

That indicates how fast data science and ML are growing

And yet there isn't a proper Python to JavaScript transpiler, like ClojureScript is to Clojure. I wonder why.

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.

That actually makes sense (the difference between CLJS and syntactic sugar transpilers).

Do questions about JavaScript libraries like React/Vue get included as "JavaScript" questions?

Is typescript counted into the js category of questions?

Of course, each noobie is confused about who to properly do things :)

As in: "Why on earth did you implement this in Python?" ;)

I'll take a stab at it.

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.

Reply on news.ycombinator.com