7 ms·

>When you see a huge codebase in python grown over several years and try to refactor it, reason about it, or just enhance it, you will inevitably come to the co

>When you see a huge codebase in python grown over several years and try to refactor it, reason about it, or just enhance it, you will inevitably come to the conclusion that the omission of static type checking is a grave error from a system-design perspective. I inevitably came the exact opposite conclusion. Perhaps because at the start of my career I was trying to do the same thing with Java, and it added overhead and expense without a commensurate payoff in safety. Frankly, I think velocity is ridiculously underrated: * Because of the age old "customer doesn't know what they want" issue - hence you throw away a lot of the code that was not fit for purpose. * Also because the right kind of architecture is only obvious in retrospect - hence you throw away a lot of the code that was not fit for purpose. * And finally, because the only times in my career where I've had significant success in refactoring a large mission critical codebase it was python and it was because I'd managed to quickly build custom tooling infrastructure (e.g. testing) to support that refactoring. I do take some issue with python's type system (e.g. the whole truthiness thing), but on the whole it balances safety and velocity in a highly pragmatic manner.

youerbt 7y ago
I can't help the feeling that your post is about Python vs Java rather than static vs dynamic. And I don't see how your 3 points about the velocity thing are affected by static types.. Like, come on, many points can be argued over compiler usefulness, but help with throwing away code is rather not one of them.
- pytester 7y ago
  >I can't help the feeling that your post is about Python vs Java rather than static vs dynamic. Because the OP was about python and because python and java are the two languages where I have worked on refactorings of large scale code bases. I can't help but feel that if you make a hypothesis (e.g. "static typing is naturally better"), you need to be open to examples that disprove this hypothesis. >And I don't see how your 3 points about the velocity thing are affected by static types.. Static typing usually means a lot of time spent satisfying the compiler. I don't disagree that this can be useful because it catches bugs (although a lot of stuff caught by compilers are not bugs). I disagree that this isn't a cost/benefit trade off that naturally works out.
  - youerbt 7y ago
    I don't think you disprove the hypothesis, though. I think you are talking about equally, if not more, important thing - ergonomics. Java is not an example of static types not bringing in benefits, it's an example of overcoming those benefits by other things. > I disagree that this isn't a cost/benefit trade off that naturally works out. I agree, it is. I just think that programming languages are a whole package and Java is really bad with this cost/benefit ratio. I'd rather see something else being an ambassador of static types.
    - pytester 7y ago
      >I don't think you disprove the hypothesis, though. I think you are talking about equally, if not more, important thing - ergonomics Types are an intrinsic part of ergonomics. >I'd rather see something else being an ambassador of static types. I'd be happy to see another language be an "ambassador of static types" provided the tip of the iceberg of 'visible things built in it' doesn't compromise of say, one spam filter and a file converter. I'm getting pretty tired of hearing about how awesome and productive haskell's type system is for 15 whole years and seeing a whole lot of evidence that it's waaaaaay too unproductive to build anything of use in it. Rust is a fine ambassador of static types (and has some great usage examples), but rust and python address extremely different non-overlapping markets and rust isn't shy about the fact it makes it fucking hard to compile things in.
      - youerbt 7y ago
        > Types are an intrinsic part of ergonomics. For example creating new type in Java and Rust is a whole different world. If you can't separate Java the language from the idea of static typing and type systems, you are probably not a person suited for such discussion. As for your remarks about Haskell, welp, I have build things with Haskell and Python, and it's not even close. But I guess chasing runtime exceptions during development is an acquired taste.
        pytester 7y ago
        >If you can't separate Java the language from the idea of static typing and type systems I can. It's people who make blanket statements about static or dynamic typing who can't. >I guess chasing runtime exceptions during development is an acquired taste. Much like building software people actually use.
cjfd 7y ago
Well, java tends to be one extreme and python the other. Java appears to be the most bureaucratic language around where most code is written by people who are just a bit too enthusiastic about OO so every class becomes a FactoryManagerPatternVisitorImplementation and every struct 'of course' needs getters and setters. Python on the other hand is often written without any safety and I have frequently witnessed how every typo becomes a new variable maybe just because the cat stepped on the backspace key and how one developer changes the signature of a function but not all places where it is called. I think there are great benefits to compile/lint time type checking for anything bigger than just a throwaway script. For python one can use mypy, which helps. There is no need to, though, to turn everything into a festival of object orientedness. Most classes need neither parent nor child. And some functions can just be global functions.
- pytester 7y ago
  I think a lot of java's "bureaucracy" is simply duct tape around its badly constructed type system. >Python on the other hand is often written without any safety Oh for sure, but I find it easy to start dialing up python's safety from day one of starting on a project (e.g. start writing asserts), no matter how complicated. Working around java's horrible type system? Less easy.
- marcosdumay 7y ago
  I'll have to agree with pytester, and say something strongly discouraged by the article... But, well, Java can not be an extreme, its type system is very basic, it can represent very few stuff, so it can not check much. If you want something closer to the extreme, go for Haskell. But then, you can't complain much about bureaucracy. There is an annoying tendency of people to base their opinions on technology directly copied from the 70's.
choeger 7y ago
> I inevitably came the exact opposite conclusion. Perhaps because at the start of my career I was trying to do the same thing with Java, and it added overhead and expense without a commensurate payoff in safety. It really sounds like your code base simply wasn't too big after all. When you change a Java API, how much time does it cost you to find all broken client code? How much in the same case for python? > Frankly, I think velocity is ridiculously underrated Again, it sounds like your projects were still rather young. IME, throwing away code practically never happens when it has been installed for at least half a dozen customers. So python helps you to build stuff quicker, because it does not force you to be sound. But soundness is exactly what you want after a certain threshold.
- pytester 7y ago
  >When you change a Java API, how much time does it cost you to find all broken client code? How much in the same case for python? With a decent test suite and a bunch of well crafted asserts, it ends up being much quicker. Indeed, for the really subtle broken stuff, pretty much only a decent test suite can catch it. >Again, it sounds like your projects were still rather young. Probably just better tested than yours. In time, you might learn to appreciate this quality but who knows...
  - choeger 7y ago
    > With a decent test suite and a bunch of well crafted asserts, it ends up being much quicker. Indeed, for the really subtle broken stuff, pretty much only a decent test suite can catch it. I think you don't understand the point. Unless you propose that my test suite tests the libraries I am using, testing does not find code affected by API breakage. And even if you do test your used libraries in your client code, think again about how much effort it cost you to do what a machine can do just better. > Probably just better tested than yours. First of all, I doubt it. Second, you just sound rather arrogant. I hope you are aware that a) testing by necessity will always be incomplete and b) type systems by necessity will always be restricted. The developer who just discards one of these tools sounds like a woodworker who discards a chainsaw because he loves his splitting axe so much.

youerbt 7y ago

I can't help the feeling that your post is about Python vs Java rather than static vs dynamic. And I don't see how your 3 points about the velocity thing are affected by static types.. Like, come on, many points can be argued over compiler usefulness, but help with throwing away code is rather not one of them.

pytester 7y ago
>I can't help the feeling that your post is about Python vs Java rather than static vs dynamic. Because the OP was about python and because python and java are the two languages where I have worked on refactorings of large scale code bases. I can't help but feel that if you make a hypothesis (e.g. "static typing is naturally better"), you need to be open to examples that disprove this hypothesis. >And I don't see how your 3 points about the velocity thing are affected by static types.. Static typing usually means a lot of time spent satisfying the compiler. I don't disagree that this can be useful because it catches bugs (although a lot of stuff caught by compilers are not bugs). I disagree that this isn't a cost/benefit trade off that naturally works out.
- youerbt 7y ago
  I don't think you disprove the hypothesis, though. I think you are talking about equally, if not more, important thing - ergonomics. Java is not an example of static types not bringing in benefits, it's an example of overcoming those benefits by other things. > I disagree that this isn't a cost/benefit trade off that naturally works out. I agree, it is. I just think that programming languages are a whole package and Java is really bad with this cost/benefit ratio. I'd rather see something else being an ambassador of static types.
  - pytester 7y ago
    >I don't think you disprove the hypothesis, though. I think you are talking about equally, if not more, important thing - ergonomics Types are an intrinsic part of ergonomics. >I'd rather see something else being an ambassador of static types. I'd be happy to see another language be an "ambassador of static types" provided the tip of the iceberg of 'visible things built in it' doesn't compromise of say, one spam filter and a file converter. I'm getting pretty tired of hearing about how awesome and productive haskell's type system is for 15 whole years and seeing a whole lot of evidence that it's waaaaaay too unproductive to build anything of use in it. Rust is a fine ambassador of static types (and has some great usage examples), but rust and python address extremely different non-overlapping markets and rust isn't shy about the fact it makes it fucking hard to compile things in.
    - youerbt 7y ago
      > Types are an intrinsic part of ergonomics. For example creating new type in Java and Rust is a whole different world. If you can't separate Java the language from the idea of static typing and type systems, you are probably not a person suited for such discussion. As for your remarks about Haskell, welp, I have build things with Haskell and Python, and it's not even close. But I guess chasing runtime exceptions during development is an acquired taste.
      - pytester 7y ago
        >If you can't separate Java the language from the idea of static typing and type systems I can. It's people who make blanket statements about static or dynamic typing who can't. >I guess chasing runtime exceptions during development is an acquired taste. Much like building software people actually use.

cjfd 7y ago

Well, java tends to be one extreme and python the other. Java appears to be the most bureaucratic language around where most code is written by people who are just a bit too enthusiastic about OO so every class becomes a FactoryManagerPatternVisitorImplementation and every struct 'of course' needs getters and setters. Python on the other hand is often written without any safety and I have frequently witnessed how every typo becomes a new variable maybe just because the cat stepped on the backspace key and how one developer changes the signature of a function but not all places where it is called. I think there are great benefits to compile/lint time type checking for anything bigger than just a throwaway script. For python one can use mypy, which helps. There is no need to, though, to turn everything into a festival of object orientedness. Most classes need neither parent nor child. And some functions can just be global functions.

pytester 7y ago
I think a lot of java's "bureaucracy" is simply duct tape around its badly constructed type system. >Python on the other hand is often written without any safety Oh for sure, but I find it easy to start dialing up python's safety from day one of starting on a project (e.g. start writing asserts), no matter how complicated. Working around java's horrible type system? Less easy.
marcosdumay 7y ago
I'll have to agree with pytester, and say something strongly discouraged by the article... But, well, Java can not be an extreme, its type system is very basic, it can represent very few stuff, so it can not check much. If you want something closer to the extreme, go for Haskell. But then, you can't complain much about bureaucracy. There is an annoying tendency of people to base their opinions on technology directly copied from the 70's.

choeger 7y ago

> I inevitably came the exact opposite conclusion. Perhaps because at the start of my career I was trying to do the same thing with Java, and it added overhead and expense without a commensurate payoff in safety. It really sounds like your code base simply wasn't too big after all. When you change a Java API, how much time does it cost you to find all broken client code? How much in the same case for python? > Frankly, I think velocity is ridiculously underrated Again, it sounds like your projects were still rather young. IME, throwing away code practically never happens when it has been installed for at least half a dozen customers. So python helps you to build stuff quicker, because it does not force you to be sound. But soundness is exactly what you want after a certain threshold.

pytester 7y ago
>When you change a Java API, how much time does it cost you to find all broken client code? How much in the same case for python? With a decent test suite and a bunch of well crafted asserts, it ends up being much quicker. Indeed, for the really subtle broken stuff, pretty much only a decent test suite can catch it. >Again, it sounds like your projects were still rather young. Probably just better tested than yours. In time, you might learn to appreciate this quality but who knows...
- choeger 7y ago
  > With a decent test suite and a bunch of well crafted asserts, it ends up being much quicker. Indeed, for the really subtle broken stuff, pretty much only a decent test suite can catch it. I think you don't understand the point. Unless you propose that my test suite tests the libraries I am using, testing does not find code affected by API breakage. And even if you do test your used libraries in your client code, think again about how much effort it cost you to do what a machine can do just better. > Probably just better tested than yours. First of all, I doubt it. Second, you just sound rather arrogant. I hope you are aware that a) testing by necessity will always be incomplete and b) type systems by necessity will always be restricted. The developer who just discards one of these tools sounds like a woodworker who discards a chainsaw because he loves his splitting axe so much.