Because there is this urban myth that other languages aren't as complex, yet drop someone with a beginners loved language like Python 3.8 and they will have fun throughout the almost 2000 pages of documentation plus all major libraries in use across the ecosystem, and Python implementations.
> yet drop someone with a beginners loved language like Python 3.8 and they will have fun throughout the almost 2000 pages of documentation plus all major libraries in use across the ecosystem, and Python implementations.
I would agree that the Python ecosystem is as complex as the C++ language.
I would not agree that the Python language is as complex as the C++ language, or that they Python ecosystem is as complex as the C++ ecosystem.
I will agree also that the Python language has very comprehensive first-party tutorial and reference documentation, but that doesn't add to the complexity.
Then it is time to learn some clever use of Python metaprogramming, metaclasses, how slots interact with old style attributes, old and new style classes, clever tricks with magical methods, stackless vs regular Python, multiple ways to format strings, arithmetic semantic changes,...
I think the two major c++ documentation websites are far better than the official Python documentation. They have more examples, the different variants are clear across which version of the language you are using, and I never need to go elsewhere. Python documentation is typically lacking many of the examples you'd really want, and you need to go elsewhere to find those.
Are you seriously arguing Python has about the same complexity as C++?
An extensive standard library is not the same at all as an large base language size. Adding a million books to a language doesn't make it more complex, adding a million words and verb conjugations does.
Totally agree. Look at something like asyncio and how many things have been improved or deprecated since 3.5. it makes it really hard to keep up. Sure, if you want to stick to basic python it's certainly easier to learn than C++, but the language as a whole isn't much simpler
I have spent quite a bit of time invstigating the metaprogramming capabilities of python and I have barely scratched the surface. And I hear they have added a fully parametric type system recently...
It's not "full" in that it can't express the types of many language features well enough that inference works. Something like the attrs package needs to use a kludge[1] to communicate types back to a validator.
Other languages are definitely less complex — you generally don’t see language lawyering for Python or Java — but I think that there are many useful features in C++14/17/20 as well. Writing only C++11 will lead to suboptimal code.
> you generally don’t see language lawyering for Python or Java
But my experience for instance when having to do stuff in C#, Java or Python is that when I'm looking for advice on the internet, stackoverflow, etc etc... 80% is reaaalllly bad, in the sense that if it were C++ everybody would be screaming "wtf don't do that this is insane" and write 12 blog posts and 40 twitter flamewars about why this is a bad idea and you should never ever do this... but apparently the "tolerance to bad code" is much higher in other communities.
One way Herb Sutter looks at it is — most advanced programmers could probably write a Python or a Java interpreter. It might take them a few years, and they might struggle with some complex language features like metaclasses, reflection, or the type system, but the language spec is understandable enough that it’s feasible.
But give them five years and they would generally not be able to write a C++ compiler.
Being more accessible means being usable by less trained/skilled developers, which makes online communities less trained/skilled on average. I wouldn't use that as an argument to prefer to use worse tools and their built-in 'you must be this tall the ride' nature.
Kind of ironic that I would agree with you. The reason I still wrote it is that my opinion just recently changed from liking C++ but understanding the pitfalls to a more pragmatic this is not worth the time or effort.
> Do you learn and use all of any language you use?
Generally, yes for Python (definitely for 2, async shook up 3 a bit), C (barring a few genuinely legacy things like trigraphs), Go, Lua, and I think probably at least 2-3 times a year for anything in Java 12 and earlier.
C++ is the only language I use regularly that I am certain I don't even know of, let alone know or use, all the features of.
Because they are extension points that all have sensible defaults (in most cases, "nothing to see here") but are readily available when one needs to write something magical, not because there's unnecessary complexity in the language.
All Python-like languages have the same or similar mechanisms (for example, a method resolution order whenever there is multiple inheritance) and they are usually not explicit and not customizable.
But the common argument against C++ is that you need to know a large portion of the language because someone somewhere might be using it, and you may have to read and understand their code. So even things that are optional in python should count against python, just like they do in C++.
The difference is that C++ features very much interact with one another in subtle and detrimental ways, so if you are using feature A and a codebase you leverage uses feature B, the interaction of the two can genuinely cause issues. For Python, the extension points are generally hooks into very explicit operations (and some of the symbols you list aren't even extension points).
You need an 8x6 matrix just to know what the compiler will or won't generate (https://i.stack.imgur.com/b2VBV.png) and then you need to know exactly what the defaults will do and whether that breaks your object entirely and you need to override those defaults.
Oh I completely agree. I am mostly just annoyed at the slanted comparisons, saying that something like Python is ”simple” on some absolute scale.
I teach Python to scientific programmers. There are a lot of little details and corners that aren’t as obvious to experienced developers. Just like any language.
There is a big difference between "optional because I don't need do to the thing in 99% of projects" and "optional because I can use one of three alternate features with subtle incompatibilities to do the thing."
The only one I had not heard of before is a relatively recent addition, __class_getitem__. To Python's credit, I immediately (and correctly) guessed what it did from the name. I have used over half of them - if you have even written anything that needs to show docstring/typing information or a plugin loader you already cover nearly of them. I've used __index__, __slots__, and __mro__ more times than I can remember. The ones I haven't used are mostly because they are Python 3.4+.
But, critically, you won't find anything other than __slots__ and __index__ (and maybe __subclasshook__ if the code you're working on was from someone who drank the ABC koolaid back in the day) in "normal code" - they're there for people who want to hook into language internals, the kind of thing you'd usually find #pragma'd in C++.
With C++, on the other hand, you run into this kind of complexity just trying to solve "ordinary" problems. And it bears repeating, the "safe subset" between projects is different. It's not the only language with this problem (Common Lisp suffers greatly from it), but it's the one that offers the least in return and breaks the hardest when you get it wrong.
