13 ms·

How would a type system hinder those people?

sametmax 9y ago
Most of those people are not dev. They don't write libraries, don't have time to learn many docs or type many lines. They have 30x 200 lines longs scripts and couldn't care less about code quality. They just want the result.
- DarkKomunalec 9y ago
  I am unable to find an answer to my question in what you just said.
  - sametmax 9y ago
    Path of least resistence. A strong type system is much more extra work than you think.
    - DarkKomunalec 9y ago
      I have worked with strong and no type systems, and have found that the absence of a type system is extra work. Instead of the compiler telling me exactly what something is, what I can do with it, and if it makes sense to pass it to some function, I have to figure all of that out myself, greatly slowing me down. Edit: It occurs to me I have yet to hear an answer to my question of how types hinder anything, especially if they are inferred. The only exception is the trivial requirement of sometimes having to cast between numeric types.
      - emodendroket 9y ago
        Yeah, you basically make initial implementation easier at the expense of maintenance and debugging, which sounds like a good tradeoff until you think about the relative amount of time you spend doing one thing vs the other.
        loup-vaillant 9y ago
        > at the expense of maintenance and debugging, Do you realize how insane that sounds? Static typing makes programs harder to debug? Harder to maintain?? On the contrary, static typing helps debugging and maintenance: changes that break invariants are more likely to be caught by the type system. This speak of tradeoff sounds wise on the surface, but this is hardly a tradeoff at all. For many people (including me), a good static type system makes prototyping and maintenance easier.
        emodendroket 9y ago
        It probably sounds insane because you have interpreted my post to mean the exact opposite of what I intended.
        loup-vaillant 9y ago
        Your comment sounded like this to me: > Yeah, you [DarkKomunalec] basically [use static typing to] make initial implementation easier at the expense of maintenance and debugging It was not clear that "Yeah" was an approval (and not a dismissal), and it was not obvious that "you" was a general "you" (and not a personal "you" directed at DarkKomunalec). Nevertheless, you were still talking about a tradeoff, and I personally see none: in my experience, dynamic typing makes initial implementations harder (or longer), because so many errors are caught too late. Static type systems have a much tighter feedback loop.
        cwyers 9y ago
        Many, many people have a very different amount of time spent doing each that what you imagine. There's a lot of scripting code that is written once and then never maintained.
        emodendroket 9y ago
        If your claim is "Python is great for toy scripts" then fine, I don't have any issue with that.
      - sametmax 9y ago
        But you are a dev. These people are not. Code is not their product.
      - Verdex_2 9y ago
        I really like type systems. I think that if you take the time to learn about type theory, then you are more likely to create better solutions (both with code and in life in general). However, it isn't free. Type theory is a kind of math that most people have very little exposure to, so there's going to be a lot of work in order to start becoming proficient. Additionally, there's more than one type of type theory. Are you using a system F like system? Are you going to have sub-typing? Is it going to be structural sub-typing? Maybe you want row polymorphism. Is there going to be a kind system? What about higher order poly kinds? Dependent typing? Intensional or extensional? Additionally, there's more than one type of implementation of these type systems. Ocaml functors ... is it a generative or applicative functor? Haskell ... are you using gadts, functional dependencies, or type families? In the end I think that type systems will eventually be able to get you a completely typed experience that feels exactly like a completely dynamic experience, but with compile and design time checks that always make you feel good about the experience. However, I don't think we are quite there yet and I don't think you can expect everyone to be able to take the time to get sufficiently familiar with an arbitrary type system in order to be productive with it.
        kiriakasis 9y ago
        i would be pleasantly suprised to find an extensional type system in a mainstream language :)
    - gordaco 9y ago
      That might be true at the start of the project. But to be honest, having worked quite a few years with strong type systems, weak type systems and dynamic type systems, I've found that not having a strong type system is precisely what makes work grow faster than expected. Maybe it's because I'm accustomed to big projects, but I've been bitten too many times. I'd even choose Java over any language that doesn't have a dependable type system.
      - pmoriarty 9y ago
        "having worked quite a few years with strong type systems, weak type systems and dynamic type systems" Sorry to be pedantic, but you probably mean static type systems, not strong type systems. See: "What to know before debating type systems" - http://blogs.perl.org/users/ovid/2010/08/what-to-know-before-debating-type-systems.html http://blogs.perl.org/users/ovid/2010/08/what-to-know-before...
  - Turing_Machine 9y ago
    A programmer sees 2 and 2.5 as different types. A normal person doesn't care. He just wants, and expects, 2+2.5 to yield 4.5. He doesn't want to use a cast, or write the 2 as 2.0, or use some sort of baroque type conversion procedure, or anything like that. This answer is not Python-specific, of course, but it's a good example of the overhead that gets introduced when a language becomes too type-happy.
    - emodendroket 9y ago
      I'll bet he starts to care if floating point arithmetic introduces errors into his results. You can only push off the complexity for so long if you want to do things that aren't trivial.
      - Turing_Machine 9y ago
        Can you think of a (non-contrived) example where automatic promotion to float is going to cause a non-trivial error when computing (say) a household budget? "You can only push off the complexity for so long if you want to do things that aren't trivial." There are a lot of things that aren't "trivial" that nonetheless don't require a totalitarian type system.
        emodendroket 9y ago
        Isn't the biggest non-programmer audience who has any interest in writing Python scripts scientists? I don't think it's totally contrived to imagine that floating-point precision is an issue in such cases.
        sametmax 9y ago
        Fun fact: half of the professional programmers I met in my life don't even try to do anything for floating point precision issues. You are living in your bubble. The bubble of people who knows what they are doing. Get out, you'll be surprise how much amateurish the world is. Yet it runs.
hajile 9y ago
I think that would depend on the type system. Dart has an optional type system (no types, some types, strong mode) with different levels of safety. Interestingly though, even if you write strong mode code, the types are completely thrown out before execution. It's a bit of an aside, but I don't know (libs aside) why anyone would choose python over dart. Types are great for large projects, but tend to add verbosity and development time for small scripts (thus why there are so few strongly typed scripting languages). SML/ocaml show that there is a nice middle ground where most types are inferred, so you can keep your types without too much work. Unfortunately, they've been around for decades with little usage in the profession.

Most of those people are not dev. They don't write libraries, don't have time to learn many docs or type many lines. They have 30x 200 lines longs scripts and couldn't care less about code quality. They just want the result.

DarkKomunalec 9y ago
I am unable to find an answer to my question in what you just said.
- sametmax 9y ago
  Path of least resistence. A strong type system is much more extra work than you think.
  - DarkKomunalec 9y ago
    I have worked with strong and no type systems, and have found that the absence of a type system is extra work. Instead of the compiler telling me exactly what something is, what I can do with it, and if it makes sense to pass it to some function, I have to figure all of that out myself, greatly slowing me down. Edit: It occurs to me I have yet to hear an answer to my question of how types hinder anything, especially if they are inferred. The only exception is the trivial requirement of sometimes having to cast between numeric types.
    - emodendroket 9y ago
      Yeah, you basically make initial implementation easier at the expense of maintenance and debugging, which sounds like a good tradeoff until you think about the relative amount of time you spend doing one thing vs the other.
      - loup-vaillant 9y ago
        > at the expense of maintenance and debugging, Do you realize how insane that sounds? Static typing makes programs harder to debug? Harder to maintain?? On the contrary, static typing helps debugging and maintenance: changes that break invariants are more likely to be caught by the type system. This speak of tradeoff sounds wise on the surface, but this is hardly a tradeoff at all. For many people (including me), a good static type system makes prototyping and maintenance easier.
        emodendroket 9y ago
        It probably sounds insane because you have interpreted my post to mean the exact opposite of what I intended.
        loup-vaillant 9y ago
        Your comment sounded like this to me: > Yeah, you [DarkKomunalec] basically [use static typing to] make initial implementation easier at the expense of maintenance and debugging It was not clear that "Yeah" was an approval (and not a dismissal), and it was not obvious that "you" was a general "you" (and not a personal "you" directed at DarkKomunalec). Nevertheless, you were still talking about a tradeoff, and I personally see none: in my experience, dynamic typing makes initial implementations harder (or longer), because so many errors are caught too late. Static type systems have a much tighter feedback loop.
      - cwyers 9y ago
        Many, many people have a very different amount of time spent doing each that what you imagine. There's a lot of scripting code that is written once and then never maintained.
        emodendroket 9y ago
        If your claim is "Python is great for toy scripts" then fine, I don't have any issue with that.
    - sametmax 9y ago
      But you are a dev. These people are not. Code is not their product.
    - Verdex_2 9y ago
      I really like type systems. I think that if you take the time to learn about type theory, then you are more likely to create better solutions (both with code and in life in general). However, it isn't free. Type theory is a kind of math that most people have very little exposure to, so there's going to be a lot of work in order to start becoming proficient. Additionally, there's more than one type of type theory. Are you using a system F like system? Are you going to have sub-typing? Is it going to be structural sub-typing? Maybe you want row polymorphism. Is there going to be a kind system? What about higher order poly kinds? Dependent typing? Intensional or extensional? Additionally, there's more than one type of implementation of these type systems. Ocaml functors ... is it a generative or applicative functor? Haskell ... are you using gadts, functional dependencies, or type families? In the end I think that type systems will eventually be able to get you a completely typed experience that feels exactly like a completely dynamic experience, but with compile and design time checks that always make you feel good about the experience. However, I don't think we are quite there yet and I don't think you can expect everyone to be able to take the time to get sufficiently familiar with an arbitrary type system in order to be productive with it.
      - kiriakasis 9y ago
        i would be pleasantly suprised to find an extensional type system in a mainstream language :)
  - gordaco 9y ago
    That might be true at the start of the project. But to be honest, having worked quite a few years with strong type systems, weak type systems and dynamic type systems, I've found that not having a strong type system is precisely what makes work grow faster than expected. Maybe it's because I'm accustomed to big projects, but I've been bitten too many times. I'd even choose Java over any language that doesn't have a dependable type system.
    - pmoriarty 9y ago
      "having worked quite a few years with strong type systems, weak type systems and dynamic type systems" Sorry to be pedantic, but you probably mean static type systems, not strong type systems. See: "What to know before debating type systems" - http://blogs.perl.org/users/ovid/2010/08/what-to-know-before-debating-type-systems.html http://blogs.perl.org/users/ovid/2010/08/what-to-know-before...
- Turing_Machine 9y ago
  A programmer sees 2 and 2.5 as different types. A normal person doesn't care. He just wants, and expects, 2+2.5 to yield 4.5. He doesn't want to use a cast, or write the 2 as 2.0, or use some sort of baroque type conversion procedure, or anything like that. This answer is not Python-specific, of course, but it's a good example of the overhead that gets introduced when a language becomes too type-happy.
  - emodendroket 9y ago
    I'll bet he starts to care if floating point arithmetic introduces errors into his results. You can only push off the complexity for so long if you want to do things that aren't trivial.
    - Turing_Machine 9y ago
      Can you think of a (non-contrived) example where automatic promotion to float is going to cause a non-trivial error when computing (say) a household budget? "You can only push off the complexity for so long if you want to do things that aren't trivial." There are a lot of things that aren't "trivial" that nonetheless don't require a totalitarian type system.
      - emodendroket 9y ago
        Isn't the biggest non-programmer audience who has any interest in writing Python scripts scientists? I don't think it's totally contrived to imagine that floating-point precision is an issue in such cases.
        sametmax 9y ago
        Fun fact: half of the professional programmers I met in my life don't even try to do anything for floating point precision issues. You are living in your bubble. The bubble of people who knows what they are doing. Get out, you'll be surprise how much amateurish the world is. Yet it runs.

hajile 9y ago

I think that would depend on the type system. Dart has an optional type system (no types, some types, strong mode) with different levels of safety. Interestingly though, even if you write strong mode code, the types are completely thrown out before execution. It's a bit of an aside, but I don't know (libs aside) why anyone would choose python over dart. Types are great for large projects, but tend to add verbosity and development time for small scripts (thus why there are so few strongly typed scripting languages). SML/ocaml show that there is a nice middle ground where most types are inferred, so you can keep your types without too much work. Unfortunately, they've been around for decades with little usage in the profession.