4 ms·

>Having dynamic types can be awfully convenient at times and I completely relate to why some people like them but static types means your structures and classes

>Having dynamic types can be awfully convenient at times and I completely relate to why some people like them but static types means your structures and classes effectively have written specifications defined in the code itself which the compiler verifies the rest of your program against. So if you’re accidentally trying to write text to a numeric type, your compiler will catch that. In my experience, if I'm writing relatively decent tests and sprinkling of sanity checks these types of errors get caught quickly and are very obvious. I can sympathize with somebody who has largely worked with untested statically typed projects and has moved to untested dynamically typed projects though - this is where the benefit of compiler type checking might seem to be most valuable. I can also sympathize with somebody working with a dynamically typed language with a bad type system (cough javascript). >In my experience the extra up front overhead (in terms of development time) of static typed AOT compiled languages end up saving you development time in the long run Yeah, mine doesn't.

pushpop 8y ago
Like I said, tests are also subject to user error. I’ve seen scenarios where tests passed when they shouldn’t have because the test itself was wrong. Or situations when test coverage was good but a basic type check seemed so obvious it was forgotten to be added. Some of those tests wouldn’t even have been needed in Rust or Go. I do agree that tests are important; hence why I raised that point from the outset. But ultimately in Python you’re still having to add extra tests just to catch up with the default behaviour of Go and Rust. Which is the point I was raising. Go and Rust are better at catching stupid user error. Clearly though you can write large projects in Python if you’re disciplined enough. Same could be said for C, BBC BASIC or even assembly. The question isn’t whether you can, it’s whether other languages makes it easier or not.
- pytester 8y ago
  >But ultimately in Python you’re still having to add extra tests just to catch up with the default behaviour of Go and Rust. You don't though. The tests you'd write which would catch these "stupid user errors" are basic ones which you'd be remiss not to write in any language. The fact that frequently developers do choose not to write any tests at all on large code bases does mean that they start to rely heavily on compiler catching 'stupid user errors' but it doesn't have to be that way. >Go and Rust are better at catching stupid user error. ...if you don't have a basic level of tests, yes. (although rust does provide certain type level protection against, say, data race bugs which python doesn't).
  - pushpop 8y ago
    You’re flip flopping all over the place with your descriptions of tests. Broadly speaking, There are two types of tests being discussed here. Those are positive tests and negative tests. Positive being that the code does what you expect under normal operation. Those you’d obviously need in any language Negative tests are, amongst other things, checking that your functions behave correctly when you put garbage in. If your compiler flat out refuses to send a string type to a function that is designed to accept an integer then you’re already covering a whole class of bugs without needing to write specific tests for it.
    - pytester 8y ago
      >You’re flip flopping all over the place with your descriptions of tests. The straw man of my argument living in your head flip flopped. I did no such thing. When I said "basic tests" I meant demonstrate the behavior under normal circumstances". If you're doing TDD on 60% of your code base you'll write enough of these. >Negative tests are, amongst other things, checking that your functions behave correctly when you put garbage in. This is a completely unsuitable use case for a test. If your function expects non-garbage it should raise an exception if it gets garbage with a sanity check. I wrote one just a few hours ago like so: assert no_nans(dataframe)
      - pushpop 8y ago
        I have no problems with exception per se but what you’ve now done is push your error checking into the runtime which means your application could crash at unexpected times. This might be fine for your typical use cases but it is a terrible way to go about building software if you’re writing headless services. The point of functional tests is they catch developer errors before your codebase hits production. Which you cannot guarantee if your error checking is only in the runtime. Disclaimer: I write services used by millions of people (literally) each day. Some of those services are written in Python.
        pytester 8y ago

pushpop 8y ago

Like I said, tests are also subject to user error. I’ve seen scenarios where tests passed when they shouldn’t have because the test itself was wrong. Or situations when test coverage was good but a basic type check seemed so obvious it was forgotten to be added. Some of those tests wouldn’t even have been needed in Rust or Go. I do agree that tests are important; hence why I raised that point from the outset. But ultimately in Python you’re still having to add extra tests just to catch up with the default behaviour of Go and Rust. Which is the point I was raising. Go and Rust are better at catching stupid user error. Clearly though you can write large projects in Python if you’re disciplined enough. Same could be said for C, BBC BASIC or even assembly. The question isn’t whether you can, it’s whether other languages makes it easier or not.

pytester 8y ago
>But ultimately in Python you’re still having to add extra tests just to catch up with the default behaviour of Go and Rust. You don't though. The tests you'd write which would catch these "stupid user errors" are basic ones which you'd be remiss not to write in any language. The fact that frequently developers do choose not to write any tests at all on large code bases does mean that they start to rely heavily on compiler catching 'stupid user errors' but it doesn't have to be that way. >Go and Rust are better at catching stupid user error. ...if you don't have a basic level of tests, yes. (although rust does provide certain type level protection against, say, data race bugs which python doesn't).
- pushpop 8y ago
  You’re flip flopping all over the place with your descriptions of tests. Broadly speaking, There are two types of tests being discussed here. Those are positive tests and negative tests. Positive being that the code does what you expect under normal operation. Those you’d obviously need in any language Negative tests are, amongst other things, checking that your functions behave correctly when you put garbage in. If your compiler flat out refuses to send a string type to a function that is designed to accept an integer then you’re already covering a whole class of bugs without needing to write specific tests for it.
  - pytester 8y ago
    >You’re flip flopping all over the place with your descriptions of tests. The straw man of my argument living in your head flip flopped. I did no such thing. When I said "basic tests" I meant demonstrate the behavior under normal circumstances". If you're doing TDD on 60% of your code base you'll write enough of these. >Negative tests are, amongst other things, checking that your functions behave correctly when you put garbage in. This is a completely unsuitable use case for a test. If your function expects non-garbage it should raise an exception if it gets garbage with a sanity check. I wrote one just a few hours ago like so: assert no_nans(dataframe)
    - pushpop 8y ago
      I have no problems with exception per se but what you’ve now done is push your error checking into the runtime which means your application could crash at unexpected times. This might be fine for your typical use cases but it is a terrible way to go about building software if you’re writing headless services. The point of functional tests is they catch developer errors before your codebase hits production. Which you cannot guarantee if your error checking is only in the runtime. Disclaimer: I write services used by millions of people (literally) each day. Some of those services are written in Python.
      - pytester 8y ago