1. 13
  1.  

  2. 20

    I often feel like I’m the lone developer in the world screaming into the void that python is a flawed language and it’s massive adoption recently is a mistake that we haven’t begun to see the costs of yet.

    The language itself, the grammar, operational semantics of the core language, documentation, and common library design idioms are all bathed in enormous complexity. The type system is a worst of both worlds compromise that manages to cause frequent crashes with no real upfront checking (mypy is a very small step in the right direction but has a very long way to go and probably can’t ever become as good as it needs to be) yet also don’t offer enough dynamism to justify the absurd cost of not having compile time checking.

    I just don’t get it.

    1. 10

      I’ve been using Python a very long time, and I have to admit that when I read your comment looking for something objective rather than subjective, all I find is something that doesn’t match my own experience (“manages to cause frequent crashes”) and really seems to be the same “dynamically-typed languages are all bad and constantly break” stuff that’s not at all backed up by the available literature on defect rates for static versus dynamic typing.

      1. 9

        I’m not going to try to make an objective argument against any language because I just don’t think we’re at a point in our understanding of software engineering yet where we can make substantive objective claims about languages outside of some very narrow cases. I’m familiar with the literature you’re referring to and while I grant that the conclusions did not support static typing, I’m not convinced by the research for several reasons (methodological concerns as well as concerns about how broadly you could extend the conclusions given the pretty limited number of cases that were actually studied).

        That said, I’m glad you’ve never had a problem. I have, and I’ve talked to quite a few other people who have as well (although they are generally dismissive of the problems). But it’s not strictly a matter of ahead of time type checking vs runtime checking as an absolute good/bad, it’s a matter of trade-offs.

        Ahead of time type checking can eliminate categories of bugs, at the cost of not admitting some valid programs. More sophisticated type checking can admit more programs at the cost of sometimes higher requirements for the programmer to think about types (dependently typed languages for example can express far more granular constraints but might be harder for a programmer to use than something like Haskell (omitting dependents Haskell for the sake of this discussion), and there is a large range of languages along this curve).

        Very dynamic languages on the other hand focus on flexibility of features at the cost of programs being less provable. A language like lisp, ruby, or erlang may have many programs that use this flexibility in ways that would make it very difficult to type check programs.

        The problem as I see it is that python is the worst of both worlds. It offers no guarantees though type checking, requiring at best the programmer to manually implement their own verification through runtime type assertions, unit tests, or manual proofs outside of the program itself, or at worst programs crash while running. At the same time, the languages own grammar and idioms do not seem to support the dynamism that other languages offer in exchange for giving up safety.

        In short, the problem with python isn’t that it’s dynamically typed per-se, but that it’s dynamically typed while being no more powerful or expressive than statically typed languages.

        1. 4

          It offers no guarantees though type checking,

          Well, it offers some.

          >>> "3" > 3
          Traceback (most recent call last):
            File "<stdin>", line 1, in <module>
          TypeError: '>' not supported between instances of 'str' and 'int'
          

          If that doesn’t seem like much, consider that couple of the most popular programming languages today do not offer even this level of type checking.

          1. 3

            The problem is you still don’t find that out until runtime. That’s my fundamental point- to whatever degree there’s value in the sort of dynamism you’d get from having ‘3’ > 3, you give that up in python, but you don’t get anything in return. You just have to run it, and hope you exercise that code path early so it crashes while you’re in the office and not at 2am when you have to groggily debug stack traces under an SLA.

            1. 1

              The problem is you still don’t find that out until runtime.

              Yeah, I get that, and have made the same arguments in mounting levels of anger when looking at logs with many versions of 'NoneType' object has no attribute 'foo' that nobody knows where they’re coming from. The unfortunate part is that the people who decide these things don’t really care that some engineers have to suffer from it.

              but you don’t get anything in return

              I’m not sure if that’s true, but I find proving that point difficult. One benefit of python is a greatly enhanced support for explorative programming that many stricter languages in practice do not give you – although some, like Haskell, are close. The language is stupidly simple (in a good way) in my opinion, and I think the dynamism is part of that somehow.

              1. 2

                I’m coming from Haskell as my primary language, but lately I’ve been forced into python at work. I find python far less capable for exploratory programming than Haskell, not just because of the lack of type safety but also the general lack of flexibility in the language. I’ll concede the situation might be different if the reference point for a typed language was Java or something.

                1. 1

                  Perhaps things have changed since the last time I coded Haskell (which was ~10 years ago), but doesn’t ghci lose all local bindings when you reload your modules?

                  1. 2

                    Yes, that’s still a pain. I’m not going to defend Haskell as flawless or anything, it has a bunch of painful and irritating deficiencies. On balance though I still find it a nicer experience than python for exploratory programming.

          2. 1

            I tend to think of Ruby as being very similar to Python (though I haven’t spent a lot of time with Ruby). What makes it more dynamic than Python? What are the marginal features that you think make the dynamic nature of Ruby more worthwhile?

            1. 3

              Ruby is certainly the least differentiated from python of the three I listed, but I think there are some important differences in idioms at least, if not fundamental capabilities. In particular, ruby’s metaprogramming feels much more dynamic than python’s decorators (which in practice feel much more like something you’d get out of a preprocessor in any given statically typed language). Writing an embedded DSL in ruby, it feels much more dynamic and mutable than trying to do the same thing in a “pythonic” style.

              Ultimately, because of the metaprogramming capabilities and slightly more flexible syntax, idiomatic ruby “feels” more like a very dynamic message-passing OO system. Python, on the other hand, “feels” much more structured; like writing C or C++ but instead of types the compiler people spent all their time anal-rentatively trying to prevent you from using code formatting they don’t like.

            2. 0

              I’m really not trying to be dismissive, but again this feels like a rehash of the same “dynamic typing is bad, you have to write unit tests to assert literally everything in your program” that always comes up in static-versus-dynamic debates, and unfortunately that tends to be a highly subjective argument. Summaries of what research there is on the topic (this one is often cited) are very far from conclusive on anything, for example.

              So while I respect that you don’t care for Python, I also respectfully ask that you keep in mind how many other people have had experiences with dynamically-typed languages which don’t line up with your own.

              Also, it’s worth noting that if you want something with Python syntax and static type checking, Python 3 supports annotating with types and there are static checkers, like mypy, available. Though personally I dislike the fact that mypy went all-in originally on a nominal-typing approach when I find that real-world Python tends to want a structural approach, but that’s my individual preference.

              1. 4

                I get that people might have had different experiences, but at the end of the day my experiences are my experiences, and they’ve lead me to the conclusions I’ve articulated. I don’t see any reason I shouldn’t share them on a discussion forum where they are on topic just because some people have had different experiences.

                You like python? Never had a problem with it? Fantastic go write it all you want. I’ve had no end of trouble with it and furthers any discussions to hide the fact that I and others have come to the same conclusions about why, at least for some of us, it doesn’t work.

                1. 1

                  Sharing opinions and experiences is fine!

                  My issue was with the way the original comment phrased things seemingly as assertions of fact; that style of argument too often dominates any discussion of dynamic versus status typing, and reality is that nobody’s really in a position to make such assertions – the most anyone can do is share their experience and opinion, and accept that someone else might have different experiences and opinions.

            3. 2

              I at least somewhat agree with Rebecca. Python is a pleasure to write and a disaster to debug. My last bug was a missed comma in a statement:

              if word in [ 'keyword1' 'keyword2' ]
              

              Hidden within a couple of hundreds of lines, it can be very hard to figure out what’s going on.

            4. 3

              You’re not alone -

              Python’s syntax makes me want to yank my hair out, while Ruby’s makes me gnash my teeth during the day, and grind them to a fine dust at night.

              I agree with your points on Python - and have tried assembling a similar, grounded, reasonable list for Ruby, but that was before my descent in madness.

              1. 2

                Python’s syntax makes me want to yank my hair out, while Ruby’s makes me gnash my teeth during the day, and grind them to a fine dust at night.

                Good example of how much peoples’ opinions on these matters differ. I find both Python and Ruby to be in the top 5 of most beautiful programming languages.

                1. 2

                  And that’s how we can still all be civil friends: all it boils down to is beauty.

              2. 3

                I agree, and I would also say that I feel python has become a bit of a worse language in recent years. I think it peaked around python-2.7. I was hopeful for python-3, and it seemed pretty decent at first, but I was really disappointed that the “twisted style async” was the version that won out with asyncio, and I feel it has only gotten worse over the years (more complex, stranger/weirder syntax additions, i find the “type checking” bolt-on very awkward, etc).

                1. 2

                  I agree, this has been my experience as well.

                2. 5

                  I enjoyed these musings. For me, I think what makes Python a great language is the standard library. Pretty much anything you might ever want to do is built right in.

                  1. 2

                    I think more and more for most developers, the standard library is crucial. Syntax is easier to pick up than a new standard library. I remember looking at Phoenix/Elixir a few years ago and thinking “wow, for most projects I’d probably just use rails because where are all the gems?”.

                    Makes me wonder what would cause another major language (of the scope of python or java) emerge. I guess we saw that with golang, where the stdlib was big enough and it filled a sweet spot between c and dynamic languages.

                    But it does seem like a great standard library is table stakes now.

                    1. 1

                      In some ways, I think Python’s popularity is in spite of it’s standard library. It’s so inconsistent, it’s really hard to remember function & module names. It is rich, for sure, but it’s hard to navigate without help from Google.

                      1. 4

                        It is also quite terrible, which prompted a cleanup in Python 3 to some degree. For many years it was just a dumping ground of sort of useful libraries people in the early days wrote (asyncore & asynchat) never to be updated ever again, and then it had like 3 libraries to talk HTTP, each with their own uniquely bad API. The standard library was where project went to die, like how many command argument parsers does one need in the standard library? Why would Python adopt a Java-style logging framework, that feels completely alien?

                        1. 2

                          That is an interesting perspective. When I first started using Python I read:

                          keep this under your pillow

                          Under the library reference link in the main docs and took it literally. I could imagine it being difficult to navigate but I’ve read most of it so many times that its second nature at this point.

                          I think this has made me spoiled because I am consistently disappointed when every other standard library does not have every imaginable use case already implemented. :)

                        2. 0

                          Not related to Python, but Go has one of the best standard libraries I’ve ever used.

                        3. 5

                          Everything in there applies to Scheme but it is much more easier. Learn everything but call/cc and GOOPS. When you need Object Oriented code rely on GOOPS. When you need more syntactic sugar or performance looks into advanced macro system. Eventually, read on nanopass framework, for most advanced use cases.

                          1. 4

                            Just add “to me” to anything not measured by a sensor.

                            I’m glad people have personal experiences that are ok with computers. Flask and pipenv are so close but so far away. If python succeeds in academic machine learning code, get ready to experience a singular success and culture like Rails did with Ruby. People are still trying to sell “Ruby is more than Rails”. Yeah. I mean it is but culture man. Culture. PHP isn’t wordpress. Ok, I get what you are saying but it might turn out to be a pejorative.

                            Keep trying out new languages. Don’t be mono lingual. Don’t be mono culture. Python has a great stdlib, fine. I’ve had that same feeling in many other languages so it becomes less blinding. I have good and bad things to say about Python but I’ll make $0 by stating something or fighting about something so I just don’t want to deal with that right now. I’m going back to trying to get pipenv to work in Docker and CI. I had zero effort and issue getting a Go binary to ship in Docker. Them’s the trade-offs.

                            1. 2

                              The thing is, Python was popular before all of the ML boom happened. Ruby on the other hand, got popular mostly because of Rails. I honestly know only one Ruby project that isn’t Rails, while with Python I know a big bunch of projects in a variety of different fields.

                              1. 2

                                Python has been through several waves of success in particular domains. When I first learned it lo these many years ago, Python was big mostly as the “readable” scripting language for sysadmin types. Then web stuff took off and that became the biggest part of the Python community. Then scientific computing took off and became a huge thing in the Python world. Then ML/AI stuff took off and is now the hot reason everyone wants to learn Python.

                                I wonder what thing will be the hot reason to learn/use Python five years from now.