3 ms·

I started using python 3 with mypy, which provides (optional) static typing, and my gosh has it reduced the time I spend looking for stupid problems by orders o

by anyfoo 8y ago

I started using python 3 with mypy, which provides (optional) static typing, and my gosh has it reduced the time I spend looking for stupid problems by orders of magnitude. I got a somewhat direct comparison when I mypy-ified a small program where I used a lot of async and await (basically implementing own event loops and schedulers, it was interfacing very custom hardware that handled very different but interacting streams at once). So basically I did it because I was tired of not noticing mixing up "foo()" and "await foo()", but then the static typing continued to catch a myriad of other, unrelated problems that would have ruined my day way late (and often obscurely) at runtime. For small ("scripty") to moderate sized things, mypy absolutely recovered my faith in it. I also completely switched to python 3 after being in python 2 unicode hell just once. There are very good reasons for python 3.

o10449366 8y ago
Agreed. As part of the transition process from Python 2 to 3, I pushed for typing on all of the critical components. I had to fight the management a little on the commitment, but in the long run it's saved us a ton of time identifying and preventing bugs and its made the entire codebase much more cohesive.
- em-bee 8y ago
  does the management agree with that assessment? these kind of changes are often hard to evaluate because ot is not easy to compare. did development really go faster because of types, or do we just think it did? i agree that typing saves time but i am struggling to produce evidence for that
  - anyfoo 8y ago
    It's not very hard to find the evidence before you move to static typing. Just think about this not uncommon scenario: "The program crashed two hours into testing because apparently, we somewhere set this element in this deep structure to an integer instead of a list, and are now trying to iterate over that integer. But we cannot easily fix it, because we don't know yet where and why we set it to an integer." The compiler would have immediately given you an error instead. So, collect all the errors that are, e.g.: - Addressing the wrong element in a tuple, - any problems arising from changing the type of something; not just the fundamental highest level type ("list" or "integer"), but small changes in its deeper structure as well, e.g. changing an integer deep in a complex structure to be another tuple instead, - "missed spots" when changing what parameters a function accepts; this overlaps with the former point if it still accepts the same arguments on the surface, but their types change (in obvious, or subtle "deep" ways), - any problems arising from nesting of promises and non-promise values, and many, many other problems where you can trivially conclude that the compiler would have spit out an error immediately, and explain to management how various multi-hour debugging session could have been resolved before even running your thing.
salex89 8y ago
I suppose you are right. But with a huge code base, migration is not an overnight process...
nikofeyn 8y ago
as a serious question, why even use python if you have to go through hoops to make it work even half as well as other languages? are you reliant upon some python only library?
- targafarian 8y ago
  > go through hoops mypy and types are only "hoops" in comparison to non-annotated Python (in terms of added syntax / coding effort), yet compared to explicitly typed languages where you have to declare types, that's just standard thing you have to do so there is no extra effort in comparison to these other languages (and then the judgment that it only works "half as well" is controversial (Edit: or at least needs qualification)).
  - nikofeyn 8y ago
    i prefer ml dialects like f# or ocaml or something like racket that gives you both static and dynamic languages that can interoperate. in f# and ocaml, the type inference handles most things, although you do need to manually declare types sometimes. it is often a good idea anyway. and what i mean by hoops is that python is not designed to have static types. thus, any type system added is tacked on by definition and will lead to "hoops". in something like f#, at no point will the existence of its type system and inference be a surprise. the language is built around and with the type system.
- nikisweeting 8y ago
  My experience when switching to other languages is "why do you have to go through so many hoops to make this work even half as well as Python"...
- magduf 8y ago
  In my experience, Python is usually used because of a low barrier-to-entry and the availability of a lot of libraries. It's great for slapping something together quickly to do something useful. However, if you want something that's high-performance and well-engineered, it just isn't the right tool for the job usually.

by anyfoo 8y ago

o10449366 8y ago

Agreed. As part of the transition process from Python 2 to 3, I pushed for typing on all of the critical components. I had to fight the management a little on the commitment, but in the long run it's saved us a ton of time identifying and preventing bugs and its made the entire codebase much more cohesive.

em-bee 8y ago
does the management agree with that assessment? these kind of changes are often hard to evaluate because ot is not easy to compare. did development really go faster because of types, or do we just think it did? i agree that typing saves time but i am struggling to produce evidence for that
- anyfoo 8y ago
  It's not very hard to find the evidence before you move to static typing. Just think about this not uncommon scenario: "The program crashed two hours into testing because apparently, we somewhere set this element in this deep structure to an integer instead of a list, and are now trying to iterate over that integer. But we cannot easily fix it, because we don't know yet where and why we set it to an integer." The compiler would have immediately given you an error instead. So, collect all the errors that are, e.g.: - Addressing the wrong element in a tuple, - any problems arising from changing the type of something; not just the fundamental highest level type ("list" or "integer"), but small changes in its deeper structure as well, e.g. changing an integer deep in a complex structure to be another tuple instead, - "missed spots" when changing what parameters a function accepts; this overlaps with the former point if it still accepts the same arguments on the surface, but their types change (in obvious, or subtle "deep" ways), - any problems arising from nesting of promises and non-promise values, and many, many other problems where you can trivially conclude that the compiler would have spit out an error immediately, and explain to management how various multi-hour debugging session could have been resolved before even running your thing.

salex89 8y ago

I suppose you are right. But with a huge code base, migration is not an overnight process...

nikofeyn 8y ago

as a serious question, why even use python if you have to go through hoops to make it work even half as well as other languages? are you reliant upon some python only library?

targafarian 8y ago
> go through hoops mypy and types are only "hoops" in comparison to non-annotated Python (in terms of added syntax / coding effort), yet compared to explicitly typed languages where you have to declare types, that's just standard thing you have to do so there is no extra effort in comparison to these other languages (and then the judgment that it only works "half as well" is controversial (Edit: or at least needs qualification)).
- nikofeyn 8y ago
  i prefer ml dialects like f# or ocaml or something like racket that gives you both static and dynamic languages that can interoperate. in f# and ocaml, the type inference handles most things, although you do need to manually declare types sometimes. it is often a good idea anyway. and what i mean by hoops is that python is not designed to have static types. thus, any type system added is tacked on by definition and will lead to "hoops". in something like f#, at no point will the existence of its type system and inference be a surprise. the language is built around and with the type system.
nikisweeting 8y ago
My experience when switching to other languages is "why do you have to go through so many hoops to make this work even half as well as Python"...
magduf 8y ago
In my experience, Python is usually used because of a low barrier-to-entry and the availability of a lot of libraries. It's great for slapping something together quickly to do something useful. However, if you want something that's high-performance and well-engineered, it just isn't the right tool for the job usually.