8 ms·

You quit Python because you tried to use static typing in a dynamic language and for obvious reasons that doesn't work. You could have introduced an UAT enviro

You quit Python because you tried to use static typing in a dynamic language and for obvious reasons that doesn't work. You could have introduced an UAT environment and done basic QA.

jchw 4y ago
We had dedicated QA testing. QA testing failed to create the requisite conditions. Type checking is not a replacement for QA testing. However, it is much cheaper and also finds bugs that might be incredibly hard to find through random chance or through structured smoke testing, because it does not depend on how common a given code path is. QA testing is even less likely to find issues than automated test suites, since at least you can qualify branch coverage with test suites (which still will not enumerate all of the possible code paths, and thus... Type checking is incredibly useful.) So while type checking really is not a replacement for QA, QA is also not a replacement for type checking. I ultimately quit Python for many reasons, but the desire to write more correct code was the big one. Not just me, but my entire team was burned out on Python. Investing so much into unit testing and increasing coverage, upgrading Python versions, and adding type checking as much as possible was still not yielding the benefits we'd hoped for despite how much effort it took. We eventually found much better success with the then-still-new Go programming language, which we used on most new projects going forward. There was still the occasional head scratcher in production, but deployments were as quiet as a church mouse. YMMV of course; there's plenty of success and failure stories with any programming language. I think we were all ready and willing to put a lot of investment into improving our robustness situation and just felt that we got more out of that effort with Go than Python for our programs. Python still has plenty of advantages too, so we didn't completely quit it; we wound up using Django and SQLalchemy here and there, but definitely most stuff moved to Go over time. (And personally, I stopped using Python for those things too, since moving on.)
- ReflectedImage 4y ago
  [flagged]
  - Toniglandyl 4y ago
    Do you have a reference to as study that support your point ?
    - deleted 4y ago
      [deleted]
    - ReflectedImage 4y ago
      [flagged]
  - mountainriver 4y ago
    Static typing is not just about code performance, it’s absolutely about correctness as well. I would really love to see that study as it flys in the face of all my experience
    - ReflectedImage 4y ago
      https://games.greggman.com/game/dynamic-typing-static-typing/ https://games.greggman.com/game/dynamic-typing-static-typing...
      - lostmsu 4y ago
        > has on average 2.5x the number of bugs This claim is not supported by the linked article. In fact, the main claim (only 2% of bugs are type errors) of the linked article also does not make any sense. It is based on the assumption, that typing errors only ever cause TypeError, AttributeError, or NameError in Python, which is, ironically, false, because Python is a dynamic language. To give a concrete example, I went out to GitHub, got into top Python repository (TensorFlow), and searched for a first closed pull request which explicitly mentioned ValueError and did not mention either of the above. It turned out to be this one: https://github.com/tensorflow/tensorflow/pull/47017 https://github.com/tensorflow/tensorflow/pull/47017 This issue is an obvious type error: in statically-typed languages the value of float can not be nil. You could probably repeat that experiment with other closed pull requests, but I can bet you you will find that the rate will be closer to 50% if not 90%.
- HdS84 4y ago
  I often think that may is just bad. It's type system feels bolted on and limiting. Where typescript can do many things and often teases me into a new pattern, mypy is ugly and stifling. It's a pity. I really like types but mypy is just not great. It's ok, buts that's not enough for python.

You quit Python because you tried to use static typing in a dynamic language and for obvious reasons that doesn't work. You could have introduced an UAT environment and done basic QA.

jchw 4y ago

We had dedicated QA testing. QA testing failed to create the requisite conditions. Type checking is not a replacement for QA testing. However, it is much cheaper and also finds bugs that might be incredibly hard to find through random chance or through structured smoke testing, because it does not depend on how common a given code path is. QA testing is even less likely to find issues than automated test suites, since at least you can qualify branch coverage with test suites (which still will not enumerate all of the possible code paths, and thus... Type checking is incredibly useful.) So while type checking really is not a replacement for QA, QA is also not a replacement for type checking. I ultimately quit Python for many reasons, but the desire to write more correct code was the big one. Not just me, but my entire team was burned out on Python. Investing so much into unit testing and increasing coverage, upgrading Python versions, and adding type checking as much as possible was still not yielding the benefits we'd hoped for despite how much effort it took. We eventually found much better success with the then-still-new Go programming language, which we used on most new projects going forward. There was still the occasional head scratcher in production, but deployments were as quiet as a church mouse. YMMV of course; there's plenty of success and failure stories with any programming language. I think we were all ready and willing to put a lot of investment into improving our robustness situation and just felt that we got more out of that effort with Go than Python for our programs. Python still has plenty of advantages too, so we didn't completely quit it; we wound up using Django and SQLalchemy here and there, but definitely most stuff moved to Go over time. (And personally, I stopped using Python for those things too, since moving on.)

ReflectedImage 4y ago
[flagged]
- Toniglandyl 4y ago
  Do you have a reference to as study that support your point ?
  - deleted 4y ago
    [deleted]
  - ReflectedImage 4y ago
    [flagged]
- mountainriver 4y ago
  Static typing is not just about code performance, it’s absolutely about correctness as well. I would really love to see that study as it flys in the face of all my experience
  - ReflectedImage 4y ago
    https://games.greggman.com/game/dynamic-typing-static-typing/ https://games.greggman.com/game/dynamic-typing-static-typing...
    - lostmsu 4y ago
      > has on average 2.5x the number of bugs This claim is not supported by the linked article. In fact, the main claim (only 2% of bugs are type errors) of the linked article also does not make any sense. It is based on the assumption, that typing errors only ever cause TypeError, AttributeError, or NameError in Python, which is, ironically, false, because Python is a dynamic language. To give a concrete example, I went out to GitHub, got into top Python repository (TensorFlow), and searched for a first closed pull request which explicitly mentioned ValueError and did not mention either of the above. It turned out to be this one: https://github.com/tensorflow/tensorflow/pull/47017 https://github.com/tensorflow/tensorflow/pull/47017 This issue is an obvious type error: in statically-typed languages the value of float can not be nil. You could probably repeat that experiment with other closed pull requests, but I can bet you you will find that the rate will be closer to 50% if not 90%.
HdS84 4y ago
I often think that may is just bad. It's type system feels bolted on and limiting. Where typescript can do many things and often teases me into a new pattern, mypy is ugly and stifling. It's a pity. I really like types but mypy is just not great. It's ok, buts that's not enough for python.