7 ms·

that is static typing FUD. if it takes you a few days or weeks to learn to use the type checker and it saves you from expensive runtime errors later, then whats

by dmead 11y ago

that is static typing FUD. if it takes you a few days or weeks to learn to use the type checker and it saves you from expensive runtime errors later, then whats the problem?

chimprich 11y ago
The problem is the overhead in adding typing. The time taken to learn the type system is a one-off but static typing has running costs in slowing down development, discouraging exploratory programming, extra cognitive load in reasoning about the type system, and "false positives" in disallowing otherwise correct programs. It does nearly eliminate a class of bugs - this is wonderful, but the bugs it does eliminate tend to be ones that are fairly obvious to find.
- erdeszt 11y ago
  Do you have any evidence to prove this? I've read a few papers that disagree with your opinions...
  - Skinney 11y ago
    Probably based on personal experience. For me, whenever I start a project from scratch I usually start with the most dynamic environment I can find, then hack away until I have something that resembles the functionality I need, before locking it down. In the beginning of a project I don't care if something is 100% correct, I just want to see what my idea looks like, and what I actually need. I don't want to deal with synchronizing my types with a database schema, or make sure the JSON I send to the server satisfy the type system. I really don't care about interfaces or abstract classes or whatnot, I just want to retrieve the value I know to be in the object I got. Then, when I have a working'ish prototype, I can start nailing it down with types, assertions, tests and contracts. Of course, people are different. Some people do all of this on paper before writing a single line of code. Others plan by making types and interfaces, then proceed to implement those. I just like making prototypes.
    - dllthomas 11y ago
      "Some people do all of this on paper before writing a single line of code. Others plan by making types and interfaces, then proceed to implement those. I just like making prototypes." Of these, I sound the most like you - think just a little, then sit down and start coding to get a feel for things. Yet I find a good type system essential (or at least conspicuously missing when I write Python). There is a notion that, if one has static type checking, one has to get the types right before writing code. There's no reason that has to be the case. Get a sketch, start writing code, refine your sketch. With type inference, the sketch can even be somewhat incomplete and still help me find where my assumptions clash.
    - jbeja 11y ago
      Don't know why people are downvoting you, your approach is perfectly valid.
  - yogthos 11y ago
    That's the thing though, there are lots of papers that support both sides of the argument out there. For example, take this http://macbeth.cs.ucdavis.edu/lang_study.pdf http://macbeth.cs.ucdavis.edu/lang_study.pdf large scale study of GitHub projects. In the study, Clojure is right up there for correctness with hardcore statically typed languages like Haskell. There's plenty of software written in both typing disciplines in the wild. Yet, nobody managed to conclusively demonstrate that software written in statically typed languages is produced faster and with less overall defects or that it has lower maintenance cost. The very fact that we're still having these debates says volumes in my opinion. Majority of arguments regarding benefits of static typing appear to be rooted squarely in anecdotal evidence.
    - erdeszt 11y ago
      I agree with this comment of yours but the first one has a few overstatements and that prompted my reply. Also if you feel that strong types slow you down I suggest you try some gradually typed language where you can start out without types, do the exploring and add the types when you know what you want. I've tried this in TypeScript and it was a fairly good experience.
      - chimprich 11y ago
        It wasn't my intention to overstate the benefits of dynamic typing, just to point out that static typing isn't just a free lunch. I think yogthos sums up the situation pretty well.
      - yogthos 11y ago
        Clojure also takes this approach with core.typed as well https://frenchy64.github.io/2015/06/19/gradual-typing.html https://frenchy64.github.io/2015/06/19/gradual-typing.html I personally haven't found a place where this is necessary yet, but who knows what might happen in the future. :)
- cantankerous 11y ago
  What about the cognitive load of chasing down things like null reference errors, which in some strongly typed languages don't even exist? And no, they're not always fairly obvious to find, especially when you're fixing somebody else's code.
  - Skinney 11y ago
    The keyword being "some". I've rarely had any problems with null/nil reference errors in Clojure, because nil is treated both as false and as the empty list, so most of the time you do the right thing in case of nil. You also don't call methods on objects, but send values to functions, which eliminates a large source of NPE right there. Clojure is also a compiled language. So things like calling a function with the wrong arity, and calling a variable/function that doesn't exist are caught at compile time. This is, by far, the most common runtime bugs I've experienced in Javascript and Python, due to spelling mistakes in and out of refactoring.
    - JadeNB 11y ago
      > most of the time you do the right thing in case of nil I can't remember where, but I was just reading something yesterday to the effect that a solution that works most of the time is worse than a 'solution' that never works: at least you'll notice the latter quickly, whereas you might not notice the former until it's buried so deep in your code that you've forgotten the hidden assumptions it involves.
      - Skinney 11y ago
        By that logic, most object oriented languages like Java, C# and C++ are fundamentally flawed as calling a method only works most of the time. Besides, code in general only work most of the time. Static typing does not protect you from bugs.
        the_af 11y ago
        > Static typing does not protect you from bugs. But it does. It doesn't protect you from all bugs, but nobody claimed it did.
- sebastianconcpt 11y ago
  That's a really important point. Lots of time sunken in confirming the compiler that could have been used in exploratory programming. Humans are fundamentally explorers not conformists. Nice duality you exposed right there!
jstuxx 11y ago
More like its FKF (Fear of the Known and Familiar). Most (if not all) programmers have experience with static typing and most of those experiences were not pleasant hence why a lot of people don't like static typing. People start to hate it even more when it gets shoved down their throats i.e. "You must absolutely must use static typing otherwise your software is unreliable and buggy". Static typing requires discipline, it is no magic cure for bugs which will automatically make your programs correct, same way forcing everything to be in class in Java does not automatically make readable, modular and reusable code, its just restrictive and annoying. The disciplines required for static typing to be effective can be employed in dynamic typing however merely having a static type system does not mean the discipline will be developed. In order for a static type system to not be restrictive (like Java's or C++'s) it has to be flexible i.e. it has allow types of varying degrees of vagueness. If I am an inexperienced programmer with no discipline nothing stops me from picking the vaguest type possible and making a complete mess. Type errors do not prevent all bugs, in-fact they prevent only a minimal subset of bugs, most bugs are related to logic errors involving an ill-thought out algorithm or data errors related to invalid data provided by the user which often can only be caught by dynamic type systems.
- deleted 11y ago
  [deleted]
- dllthomas 11y ago
  There are too many things wrong with this comment for me to address any subset of them coherently... I'll leave it at responding to the bit I do agree with, which is that many people have had poor experiences with poor checkers for poor type systems.
- sebastianconcpt 11y ago
  That's a good observation

by dmead 11y ago

that is static typing FUD. if it takes you a few days or weeks to learn to use the type checker and it saves you from expensive runtime errors later, then whats the problem?

chimprich 11y ago

The problem is the overhead in adding typing. The time taken to learn the type system is a one-off but static typing has running costs in slowing down development, discouraging exploratory programming, extra cognitive load in reasoning about the type system, and "false positives" in disallowing otherwise correct programs. It does nearly eliminate a class of bugs - this is wonderful, but the bugs it does eliminate tend to be ones that are fairly obvious to find.

erdeszt 11y ago
Do you have any evidence to prove this? I've read a few papers that disagree with your opinions...
- Skinney 11y ago
  Probably based on personal experience. For me, whenever I start a project from scratch I usually start with the most dynamic environment I can find, then hack away until I have something that resembles the functionality I need, before locking it down. In the beginning of a project I don't care if something is 100% correct, I just want to see what my idea looks like, and what I actually need. I don't want to deal with synchronizing my types with a database schema, or make sure the JSON I send to the server satisfy the type system. I really don't care about interfaces or abstract classes or whatnot, I just want to retrieve the value I know to be in the object I got. Then, when I have a working'ish prototype, I can start nailing it down with types, assertions, tests and contracts. Of course, people are different. Some people do all of this on paper before writing a single line of code. Others plan by making types and interfaces, then proceed to implement those. I just like making prototypes.
  - dllthomas 11y ago
    "Some people do all of this on paper before writing a single line of code. Others plan by making types and interfaces, then proceed to implement those. I just like making prototypes." Of these, I sound the most like you - think just a little, then sit down and start coding to get a feel for things. Yet I find a good type system essential (or at least conspicuously missing when I write Python). There is a notion that, if one has static type checking, one has to get the types right before writing code. There's no reason that has to be the case. Get a sketch, start writing code, refine your sketch. With type inference, the sketch can even be somewhat incomplete and still help me find where my assumptions clash.
  - jbeja 11y ago
    Don't know why people are downvoting you, your approach is perfectly valid.
- yogthos 11y ago
  That's the thing though, there are lots of papers that support both sides of the argument out there. For example, take this http://macbeth.cs.ucdavis.edu/lang_study.pdf http://macbeth.cs.ucdavis.edu/lang_study.pdf large scale study of GitHub projects. In the study, Clojure is right up there for correctness with hardcore statically typed languages like Haskell. There's plenty of software written in both typing disciplines in the wild. Yet, nobody managed to conclusively demonstrate that software written in statically typed languages is produced faster and with less overall defects or that it has lower maintenance cost. The very fact that we're still having these debates says volumes in my opinion. Majority of arguments regarding benefits of static typing appear to be rooted squarely in anecdotal evidence.
  - erdeszt 11y ago
    I agree with this comment of yours but the first one has a few overstatements and that prompted my reply. Also if you feel that strong types slow you down I suggest you try some gradually typed language where you can start out without types, do the exploring and add the types when you know what you want. I've tried this in TypeScript and it was a fairly good experience.
    - chimprich 11y ago
      It wasn't my intention to overstate the benefits of dynamic typing, just to point out that static typing isn't just a free lunch. I think yogthos sums up the situation pretty well.
    - yogthos 11y ago
      Clojure also takes this approach with core.typed as well https://frenchy64.github.io/2015/06/19/gradual-typing.html https://frenchy64.github.io/2015/06/19/gradual-typing.html I personally haven't found a place where this is necessary yet, but who knows what might happen in the future. :)
cantankerous 11y ago
What about the cognitive load of chasing down things like null reference errors, which in some strongly typed languages don't even exist? And no, they're not always fairly obvious to find, especially when you're fixing somebody else's code.
- Skinney 11y ago
  The keyword being "some". I've rarely had any problems with null/nil reference errors in Clojure, because nil is treated both as false and as the empty list, so most of the time you do the right thing in case of nil. You also don't call methods on objects, but send values to functions, which eliminates a large source of NPE right there. Clojure is also a compiled language. So things like calling a function with the wrong arity, and calling a variable/function that doesn't exist are caught at compile time. This is, by far, the most common runtime bugs I've experienced in Javascript and Python, due to spelling mistakes in and out of refactoring.
  - JadeNB 11y ago
    > most of the time you do the right thing in case of nil I can't remember where, but I was just reading something yesterday to the effect that a solution that works most of the time is worse than a 'solution' that never works: at least you'll notice the latter quickly, whereas you might not notice the former until it's buried so deep in your code that you've forgotten the hidden assumptions it involves.
    - Skinney 11y ago
      By that logic, most object oriented languages like Java, C# and C++ are fundamentally flawed as calling a method only works most of the time. Besides, code in general only work most of the time. Static typing does not protect you from bugs.
      - the_af 11y ago
        > Static typing does not protect you from bugs. But it does. It doesn't protect you from all bugs, but nobody claimed it did.
sebastianconcpt 11y ago
That's a really important point. Lots of time sunken in confirming the compiler that could have been used in exploratory programming. Humans are fundamentally explorers not conformists. Nice duality you exposed right there!

jstuxx 11y ago

More like its FKF (Fear of the Known and Familiar). Most (if not all) programmers have experience with static typing and most of those experiences were not pleasant hence why a lot of people don't like static typing. People start to hate it even more when it gets shoved down their throats i.e. "You must absolutely must use static typing otherwise your software is unreliable and buggy". Static typing requires discipline, it is no magic cure for bugs which will automatically make your programs correct, same way forcing everything to be in class in Java does not automatically make readable, modular and reusable code, its just restrictive and annoying. The disciplines required for static typing to be effective can be employed in dynamic typing however merely having a static type system does not mean the discipline will be developed. In order for a static type system to not be restrictive (like Java's or C++'s) it has to be flexible i.e. it has allow types of varying degrees of vagueness. If I am an inexperienced programmer with no discipline nothing stops me from picking the vaguest type possible and making a complete mess. Type errors do not prevent all bugs, in-fact they prevent only a minimal subset of bugs, most bugs are related to logic errors involving an ill-thought out algorithm or data errors related to invalid data provided by the user which often can only be caught by dynamic type systems.

deleted 11y ago
[deleted]
dllthomas 11y ago
There are too many things wrong with this comment for me to address any subset of them coherently... I'll leave it at responding to the bit I do agree with, which is that many people have had poor experiences with poor checkers for poor type systems.
sebastianconcpt 11y ago
That's a good observation