5 ms·

> I really have no clue why people love this language so much. You get used to it somehow. I did C and Java for about 10 years before Python. My first exposure

> I really have no clue why people love this language so much. You get used to it somehow. I did C and Java for about 10 years before Python. My first exposure to Python was a Computational Physics class and it was maddening not knowing what types went where. Eventually you realize it doesn't really matter as long as you're disciplined and rely on others who are disciplined enough to document their code well. I haven't had the chance to use mypy in the 7 years I've been using Python (across 3 industries; medical devices, scientific devices, and web) but I would be surprised if it significantly reduced the number of bugs I've seen in practice.

jakear 6y ago
It’s certainly possible to write out types in English and cross your fingers and hope they’re correct and stay correct as the file gets edited by more and more people, but why do that when you can do it in a language that an intelligent type checker can understand and validate, and further use to provide smart editor tab-completions/etc? This is especially big for any refactoring work - just yesterday I had to change the format of a config file that gets read by both TS and Python scripts. For ts, I updated the typedef and I instantly got every error in the codebase annotated. For python, I had to manually go through each line, using my own brain as the type checker. My brain is much faster and better at being a “squiggly red line spotter” than a type checker, so I finished my TS work in a few minutes and took probably an hour going through the python, despite the projects being similar in size.
- the_af 6y ago
  This. My experience with Python goes like this: "I have to write a really small script... ok, not so small that I can do it with bash. I know, I'll use Python! This is going to be a small, throwaway utility anyway" (Some weeks later, it's turned into a large monstrosity and I need to refactor something, and everything breaks because refactoring anything nontrivial written in Python is a dangerous proposition) "Ouch! Python: never again!" (Repeat a few weeks later)
  - disgruntledphd2 6y ago
    I mean, you need to write tests before you refactor, but that's true in all languages. I do agree (and have the scars to prove it) that this isn't a panacaea but it does help, a lot. That being said, one of the worst bugs I had in python was in passing in the wrong types to a constructor function, and my tests didn't catch that. To be fair, Mypy would have, but I hadn't annotated that part. At the end of that debugging situation, I would have gladly killed somone for enforced static types in Python. That being said, the data model is a work of art, and a core reason why I enjoy coding in Python. It's just a shame that pandas kinda sucks.
    - the_af 6y ago
      I find the problem with writing tests for Python is twofold: - Most Python programs I write start their life as tiny scripts, always with the certainty they'll never grow (Narrator: they always grow). I don't know many people who write tests for their scripts... - Testing in Python means too much effort in the wrong places. Consider that most refactoring problems would have been caught for free by a language with static typing. I've experienced runtime errors because I changed the return type of a function from a single value to a list (or viceversa). A statically typed language would have let me know of my mistake for free, so that I could focus on tests that really matter.
  - ghostwriter 6y ago
    You can try Turtle next time, if you prefer fully type-checked shell scripts https://hackage.haskell.org/package/turtle-1.5.19/docs/Turtle-Tutorial.html https://hackage.haskell.org/package/turtle-1.5.19/docs/Turtl...
    - the_af 6y ago
      That's awesome. I love Haskell. Will definitely try Turtle next time!
- CraigJPerry 6y ago
  Are types a free lunch or are there trade offs, what are you getting and what are you losing by adopting types? How do the benefits you get, relate to the difficulty of problems you’re solving when programming? Eg if the cost of types is increased coupling of code but the trade off benefit is it makes fixing typos easy then that’s a bad trade. You’ve made a hard problem more brittle in exchange for making a trivial problem even easier.
  - jakear 6y ago
    Could you give an example of how code could be coupled at the type level, but not logically coupled? It seems impossible to me. > trivial problem Type checking is quite non-trivial, especially as the logic and types get more advanced (conditional types, index types, mapped types, etc etc). Not just “typos”.
    - CraigJPerry 6y ago
      >> coupled at the type level, but not logically coupled? float multiply(float a, float b) { return a * b; } You can’t add doubles with this code because it’s coupled to the float type. Summing a for b times has no logical coupling to floats or doubles just as floats or doubles have no logical coupling to either implementation of addition - both types are added by the same operations. You can swap the types or the algorithm. Before you reach for the polymorphism or further pollute the universe of types consider that it costs less lines of code to erase types here. What errors would preserving types help with here? What has more utility, less lines of code spent for the same outcomes or an implementation that exists further along the spectrum of typing in the “at compile time” direction? - I don’t believe that question can be answered but in practice i find less lines of code correlates more strongly with outcomes i care about than the degree of typing applied.
      - jakear 6y ago
        > What errors would preserving types help with here? Pretty simple, it helps when you do a refactoring that changes the type of the value passed somewhere from number to number[] and the compiler instantly tells you that that’s illegal. I did something similar just the other day when I had a shared config file read by both TS scripts and Python scripts and I needed to change the format to support a new feature. On the ts side I updated the typedef and the compiler pointed out to me every area that needed updating, on the Python side I had to spend a good chunk of time manually going through the script to figure out what needed updating.
iso8859-1 6y ago
Are you counting null pointer exceptions? Because I think Mypy is pretty effective at combatting those.

jakear 6y ago

It’s certainly possible to write out types in English and cross your fingers and hope they’re correct and stay correct as the file gets edited by more and more people, but why do that when you can do it in a language that an intelligent type checker can understand and validate, and further use to provide smart editor tab-completions/etc? This is especially big for any refactoring work - just yesterday I had to change the format of a config file that gets read by both TS and Python scripts. For ts, I updated the typedef and I instantly got every error in the codebase annotated. For python, I had to manually go through each line, using my own brain as the type checker. My brain is much faster and better at being a “squiggly red line spotter” than a type checker, so I finished my TS work in a few minutes and took probably an hour going through the python, despite the projects being similar in size.

the_af 6y ago
This. My experience with Python goes like this: "I have to write a really small script... ok, not so small that I can do it with bash. I know, I'll use Python! This is going to be a small, throwaway utility anyway" (Some weeks later, it's turned into a large monstrosity and I need to refactor something, and everything breaks because refactoring anything nontrivial written in Python is a dangerous proposition) "Ouch! Python: never again!" (Repeat a few weeks later)
- disgruntledphd2 6y ago
  I mean, you need to write tests before you refactor, but that's true in all languages. I do agree (and have the scars to prove it) that this isn't a panacaea but it does help, a lot. That being said, one of the worst bugs I had in python was in passing in the wrong types to a constructor function, and my tests didn't catch that. To be fair, Mypy would have, but I hadn't annotated that part. At the end of that debugging situation, I would have gladly killed somone for enforced static types in Python. That being said, the data model is a work of art, and a core reason why I enjoy coding in Python. It's just a shame that pandas kinda sucks.
  - the_af 6y ago
    I find the problem with writing tests for Python is twofold: - Most Python programs I write start their life as tiny scripts, always with the certainty they'll never grow (Narrator: they always grow). I don't know many people who write tests for their scripts... - Testing in Python means too much effort in the wrong places. Consider that most refactoring problems would have been caught for free by a language with static typing. I've experienced runtime errors because I changed the return type of a function from a single value to a list (or viceversa). A statically typed language would have let me know of my mistake for free, so that I could focus on tests that really matter.
- ghostwriter 6y ago
  You can try Turtle next time, if you prefer fully type-checked shell scripts https://hackage.haskell.org/package/turtle-1.5.19/docs/Turtle-Tutorial.html https://hackage.haskell.org/package/turtle-1.5.19/docs/Turtl...
  - the_af 6y ago
    That's awesome. I love Haskell. Will definitely try Turtle next time!
CraigJPerry 6y ago
Are types a free lunch or are there trade offs, what are you getting and what are you losing by adopting types? How do the benefits you get, relate to the difficulty of problems you’re solving when programming? Eg if the cost of types is increased coupling of code but the trade off benefit is it makes fixing typos easy then that’s a bad trade. You’ve made a hard problem more brittle in exchange for making a trivial problem even easier.
- jakear 6y ago
  Could you give an example of how code could be coupled at the type level, but not logically coupled? It seems impossible to me. > trivial problem Type checking is quite non-trivial, especially as the logic and types get more advanced (conditional types, index types, mapped types, etc etc). Not just “typos”.
  - CraigJPerry 6y ago
    >> coupled at the type level, but not logically coupled? float multiply(float a, float b) { return a * b; } You can’t add doubles with this code because it’s coupled to the float type. Summing a for b times has no logical coupling to floats or doubles just as floats or doubles have no logical coupling to either implementation of addition - both types are added by the same operations. You can swap the types or the algorithm. Before you reach for the polymorphism or further pollute the universe of types consider that it costs less lines of code to erase types here. What errors would preserving types help with here? What has more utility, less lines of code spent for the same outcomes or an implementation that exists further along the spectrum of typing in the “at compile time” direction? - I don’t believe that question can be answered but in practice i find less lines of code correlates more strongly with outcomes i care about than the degree of typing applied.
    - jakear 6y ago
      > What errors would preserving types help with here? Pretty simple, it helps when you do a refactoring that changes the type of the value passed somewhere from number to number[] and the compiler instantly tells you that that’s illegal. I did something similar just the other day when I had a shared config file read by both TS scripts and Python scripts and I needed to change the format to support a new feature. On the ts side I updated the typedef and the compiler pointed out to me every area that needed updating, on the Python side I had to spend a good chunk of time manually going through the script to figure out what needed updating.

iso8859-1 6y ago

Are you counting null pointer exceptions? Because I think Mypy is pretty effective at combatting those.