Reasons Python Sucks
Most of the points in this article fall on a continuum between irrelevant to dead wrong.<p>1 (versions) and 2 (installation) have to do with the ecosystem, not the language. Unsigned packages are a real problem, but hating on community-maintained software is just weird. Most software in your local Linux distro&#x27;s repository is maintained by a &quot;community&quot; that might just be one person working in their spare time.<p>3 (syntax) seems to be about not supporting the author&#x27;s <i>own</i> highly idiosyncratic habits, which include deep nesting and putting debug code in the first column (ugh). The result actually seems better for maintainability than the author&#x27;s own unconstrained code would be.<p>4 (includes) is in the &quot;exactly wrong&quot; category. Includes as in C&#x2F;C++ are a <i>horrible</i> way to handle module interfaces. Really, just about the worst option available. Modules are far better, and if the author hates the fact that importing a module might run initialization code wait until s&#x2F;he finds out about constructors (including __init__ and __attribute__((constructor)) even in C).<p>5 (nomenclature) is also a bit insane. Lists aren&#x27;t called arrays in Python because they&#x27;re <i>not</i> arrays. Next!<p>6 (quirks) criticizes quote handling in Python, but mentions bash&#x27;s quote handling without a word of comment about how that&#x27;s even worse. Different languages have different quoting conventions. Python&#x27;s might not be perfect, but many are far worse. Get over it.<p>7 (pass by reference) is another totally-wrong one. Passing by value is <i>not</i> the universal norm in other languages, and it&#x27;s not even clear what it means sometimes because of deep vs. shallow copies. Passing by reference is almost certainly better for efficiency, and often for correctness as well when copies becoming inconsistent with each other is a concern. I&#x27;d rather have pass-by-reference as the default, and have to work to make copies, than the other way around.<p>8 (local names) barely even make sense. Shadowing names, whether of variables or of modules&#x2F;libraries, is a bad idea anyway. If you want the library and the program not to have the same name, use a prefix for each role. Expecting the language to handle this for you is just asking for trouble.