4 ms·

Instagram would disagree with you. Seriously, Python is an absolute pleasure for managing large web projects and the lack of static typing has never been an iss

by Lxr 9y ago

Instagram would disagree with you. Seriously, Python is an absolute pleasure for managing large web projects and the lack of static typing has never been an issue for my company (spend the time writing tests instead!)

mixedCase 9y ago
>(spend the time writing tests instead!) Every sufficiently large test suite will contain an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a proper type system.
- nick238 9y ago
  What's the point in testing types if the tests that check it works pass?
  - sidlls 9y ago
    No, the claim is that the tests that "check it works" are really testing the types (as an ad-hoc type checker) and wouldn't need to be written if a sufficiently strict static type system were used instead.
- andybak 9y ago
  Every sufficiently large statically-typed application will contain an ad-hoc, informally-specified, bug-ridden, verbose implementation of half of a decent dynamic language. (I too enjoy a good pseudo-Greenspun) More seriously something I've been pondering a lot recently watching the old pendulum swing back towards an enthusiasm for explicit typing is this: * The advantages of static type systems are obvious and easy to articulate. * The disadvantages of static type systems are subtle and difficult to argue. I started my career as a professional programmer when the pendulum was moving in the other direction. Essays by Paul Graham on Lisp and Python. The marvellous PJ Eby piece quoted above and Peter Norvig's "Design Patterns are artifacts of language flaws". I just feel dynamic languages fit my brain better but maybe that's my own form of Stockholm Syndrome. Maybe I need to try a decent type system rather than the brain-damaged descendents of Java...
  - mixedCase 9y ago
    I think I've never really got the point of a good type system until I started using Elm and then wandered into the rest of the ML world, learning the so called "Type-Driven Development" method. After some time doing that a Java project came up, so I grabbed Lombok, Vavr and started writing Java as if it was just another ML (immutability first, paying attention to side effects and so on) and the whole thing made sense. More sense than all those years of OOP teachings. The code was easy to debug, easy to reason about, easy to change. And it was Java. And that just stunned me for life. Then of course, I started using TypeScript for React development and giggled like a little girl every time I had to refactor something, for I KNEW that it was very unlikely I'd have to stare at the debugger for long periods of time in a wild goose chase like I often had to with plain JS. But the trick was to learn the way of doing things in the languages that really guide you towards that path. I can definitely recommend that you try Elm if you're into frontend development, or something like F# if you want native. As far as docs go, the Elm guide and fsharpforfunandprofit.com are both great; the latter I can recommend regardless of your language choice for making typed functional programming make sense. I can also recommend the book Type-Driven Development with Idris, which has also been an invaluable resource to really understand that way of doing things.
nightski 9y ago
Yes let's waste our companies time and money by writing tests for things the compiler could guarantee for free!
- pmontra 9y ago
  Not for free. You have to think and write types, maybe add some code to cast values between them or implement the same function twice for two different type signatures. Sometimes it still gains time, sometimes it doesn't. Anyway, I doubt that a VBA replacement would need types. The use case is small scripts.
  - nightski 9y ago
    Python is strongly typed. You still have to think about the types. Except now you have to think about them every time you work with the code, not just the first time.
    - pmontra 9y ago
      I work with Python and Ruby (some Elixir.) They are strongly typed in the same way. I hardly think about types. The code just works. The only scenario in which I have to stop and think is when I get some input, for example some JSON. Is that value I have to add to this counter a string or an integer? I can cast it to integer and that's it. To be fair, sometimes an integer gets where there should be a string and boom. Still, I prefer that to having to write types again as I used to when working with C and Java. I fix the code and I don't write tests to check the types of function arguments. Maybe I could accept some type inference, but no more string, int, generics, etc.
      - deleted 9y ago
        [deleted]
    - Godel_unicode 9y ago
      You have to think about the types for some small pieces of your code where those types matter. That's what hints are for. Python lets you, through type hints, only care about the typing in those small cases where it actually matters, and ignore them the rest of the time.
meddlepal 9y ago
Ah yes spend that valuable engineer time writing type validation tests a compiler could do instead of new features. Put me with Op. I'll use Python for prototypes and small tools but get past that and I want a statically typed language. Not just for validation but also refactoring.
cm2187 9y ago
That's one thing I don't understand. The argument I hear against static typing is that it's too much work to write all this type metadata. But if you have to make up the lack of compiler checks with lots of tests for things that wouldn't require tests in a static language, we are not saving any work.
- mpweiher 9y ago
  That's because you're not testing things that wouldn't require tests in a static language. You're testing things that need testing either way, and incidentally also testing the types.
  - sidlls 9y ago
    No, you're testing types and verifying the implementation details of the language. It's rare that a test for logic "incidentally" tests the type system. Usually both the logic and type checks are tested. It's just obfuscated because the bulk of the test is for checking the types and it's easy to look past that.
    - mpweiher 9y ago
      Yes, it doesn't test the "type system" (whatever that even means). However, it tests values for correctness. Values have types. So if you are testing whether something has the correct value, you are also testing implicitly that it has the correct type, because for the values to match, the types must also match.
- gt_ 9y ago
  I love Python but I also don’t mind static types. Maybe I will realize some day what this argument is really about, but I expected that day to come by now.
sidlls 9y ago
I'd rather not write a bunch of tests that are really acting as a static type checker or, worse, testing the Python equivalent of compiler, linker and assembler output. That's what the vast majority of testing is when it isn't simply testing mock code implementations.

by Lxr 9y ago

mixedCase 9y ago

>(spend the time writing tests instead!) Every sufficiently large test suite will contain an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a proper type system.

nick238 9y ago
What's the point in testing types if the tests that check it works pass?
- sidlls 9y ago
  No, the claim is that the tests that "check it works" are really testing the types (as an ad-hoc type checker) and wouldn't need to be written if a sufficiently strict static type system were used instead.
andybak 9y ago
Every sufficiently large statically-typed application will contain an ad-hoc, informally-specified, bug-ridden, verbose implementation of half of a decent dynamic language. (I too enjoy a good pseudo-Greenspun) More seriously something I've been pondering a lot recently watching the old pendulum swing back towards an enthusiasm for explicit typing is this: * The advantages of static type systems are obvious and easy to articulate. * The disadvantages of static type systems are subtle and difficult to argue. I started my career as a professional programmer when the pendulum was moving in the other direction. Essays by Paul Graham on Lisp and Python. The marvellous PJ Eby piece quoted above and Peter Norvig's "Design Patterns are artifacts of language flaws". I just feel dynamic languages fit my brain better but maybe that's my own form of Stockholm Syndrome. Maybe I need to try a decent type system rather than the brain-damaged descendents of Java...
- mixedCase 9y ago
  I think I've never really got the point of a good type system until I started using Elm and then wandered into the rest of the ML world, learning the so called "Type-Driven Development" method. After some time doing that a Java project came up, so I grabbed Lombok, Vavr and started writing Java as if it was just another ML (immutability first, paying attention to side effects and so on) and the whole thing made sense. More sense than all those years of OOP teachings. The code was easy to debug, easy to reason about, easy to change. And it was Java. And that just stunned me for life. Then of course, I started using TypeScript for React development and giggled like a little girl every time I had to refactor something, for I KNEW that it was very unlikely I'd have to stare at the debugger for long periods of time in a wild goose chase like I often had to with plain JS. But the trick was to learn the way of doing things in the languages that really guide you towards that path. I can definitely recommend that you try Elm if you're into frontend development, or something like F# if you want native. As far as docs go, the Elm guide and fsharpforfunandprofit.com are both great; the latter I can recommend regardless of your language choice for making typed functional programming make sense. I can also recommend the book Type-Driven Development with Idris, which has also been an invaluable resource to really understand that way of doing things.

nightski 9y ago

Yes let's waste our companies time and money by writing tests for things the compiler could guarantee for free!

pmontra 9y ago
Not for free. You have to think and write types, maybe add some code to cast values between them or implement the same function twice for two different type signatures. Sometimes it still gains time, sometimes it doesn't. Anyway, I doubt that a VBA replacement would need types. The use case is small scripts.
- nightski 9y ago
  Python is strongly typed. You still have to think about the types. Except now you have to think about them every time you work with the code, not just the first time.
  - pmontra 9y ago
    I work with Python and Ruby (some Elixir.) They are strongly typed in the same way. I hardly think about types. The code just works. The only scenario in which I have to stop and think is when I get some input, for example some JSON. Is that value I have to add to this counter a string or an integer? I can cast it to integer and that's it. To be fair, sometimes an integer gets where there should be a string and boom. Still, I prefer that to having to write types again as I used to when working with C and Java. I fix the code and I don't write tests to check the types of function arguments. Maybe I could accept some type inference, but no more string, int, generics, etc.
    - deleted 9y ago
      [deleted]
  - Godel_unicode 9y ago
    You have to think about the types for some small pieces of your code where those types matter. That's what hints are for. Python lets you, through type hints, only care about the typing in those small cases where it actually matters, and ignore them the rest of the time.

meddlepal 9y ago

Ah yes spend that valuable engineer time writing type validation tests a compiler could do instead of new features. Put me with Op. I'll use Python for prototypes and small tools but get past that and I want a statically typed language. Not just for validation but also refactoring.

cm2187 9y ago

That's one thing I don't understand. The argument I hear against static typing is that it's too much work to write all this type metadata. But if you have to make up the lack of compiler checks with lots of tests for things that wouldn't require tests in a static language, we are not saving any work.

mpweiher 9y ago
That's because you're not testing things that wouldn't require tests in a static language. You're testing things that need testing either way, and incidentally also testing the types.
- sidlls 9y ago
  No, you're testing types and verifying the implementation details of the language. It's rare that a test for logic "incidentally" tests the type system. Usually both the logic and type checks are tested. It's just obfuscated because the bulk of the test is for checking the types and it's easy to look past that.
  - mpweiher 9y ago
    Yes, it doesn't test the "type system" (whatever that even means). However, it tests values for correctness. Values have types. So if you are testing whether something has the correct value, you are also testing implicitly that it has the correct type, because for the values to match, the types must also match.
gt_ 9y ago
I love Python but I also don’t mind static types. Maybe I will realize some day what this argument is really about, but I expected that day to come by now.

sidlls 9y ago

I'd rather not write a bunch of tests that are really acting as a static type checker or, worse, testing the Python equivalent of compiler, linker and assembler output. That's what the vast majority of testing is when it isn't simply testing mock code implementations.