6 ms·

Oh I know, but my opinion and experience in half a dozen statically typed languages over a decade is that most type systems add much more overhead to developmen

Oh I know, but my opinion and experience in half a dozen statically typed languages over a decade is that most type systems add much more overhead to development than agility. I do want types when building native software, because these sit directly on the CPU and have to match the hardware. Other than that I feel they at best give you the illusion of robustness - unless the type-system is actually sound but very, very few are.

wvenable 10y ago
Type inference makes all the difference in my opinion. Once you have even simple (C# level) type inference than the overhead of static typing is so low there isn't much reason to use dynamic typing.
- jeremiep 10y ago
  Yes I agree type inference is wonderful! But when the underlying type-system is just C# I feel like I'm given a half-assed solution. What good is having a int type if you can't limit its range? I'm not going to maintain BOTH static types and tests. The ROI is way too low on that and won't even come close to guarantee robustness. Assertions over composable predicates gives me much more out of the time invested to write it. They are right there in the code at runtime, not separate like unit tests or in a different phase like static types.
  - wvenable 10y ago
    > What good is having a int type if you can't limit its range? Well then you don't have to test what happens when someone passes a string, an object, or a boolean. Most dynamic languages will silently convert many of these values into an int and produce incorrect results. > I'm not going to maintain BOTH static types and tests. You have to maintain documentation and you have to maintain tests and you have to maintain assertions for the implied types of your functions anyway so you might as well make them explicit in the code.
    - jeremiep 10y ago
      > Well then you don't have to test what happens when someone passes a string, an object, or a boolean. That's useless, I still need to test the value's range which implicitly checks the type. > You have to maintain documentation and you have to maintain tests and you have to maintain assertions Not if I can generate most of it from the specification data.
  - wvenable 10y ago
    > What good is having a int type if you can't limit its range? Most types in the program aren't ints anyway; they're interfaces. If I want to have a range-limited value, I could just create a new type for it.
coldtea 10y ago
>Oh I know, but my opinion and experience in half a dozen statically typed languages over a decade is that most type systems add much more overhead to development than agility. In what sense? With type inference you don't have to manually specify them. With a variant type, you don't have to confirm to a specific type, but can accept all, if you want it. And you still need to conform to an interface in a dynamic language, if your function is x.indexOf(x) you still need to make sure to use it on two strings, if it's a math function on some numbers (and depending on the function, on a range), etc (1). So you are not even spared that -- instead, you just lose the help from the compiler when it comes to it. (1) You could e.g. let a numeric type string autocoerce of course, but auto-coercion can also happen in static languages, is orthogonal to static vs dynamic typing, and is also generally to be avoided).
lloyd-christmas 10y ago
> most type systems add much more overhead to development than agility I think this is true to a certain extent, but with a language like JS, there is a lot more composition of generics than there is inheritance. I see: add5toStuff<T extends {stuff: number}>(item: T): T; drastically more than: class X {} class Y extends X {} class Z extends Y {} The latter is always a nightmare of fighting the compiler. The former is a breeze to deal with. Your type casting will be limited almost completely to IO.
- jeremiep 10y ago
  Both styles still encourage a lot of mutability and complexity throughout the codebase. The vast majority of typed web codebases I've seen were exercises in Java Enterprise development of various degrees. Generics or not the time spent typing everything is not matched by the advantages of static typing. You'd get more robustness by managing complexity and state; I've spent far more time hunting down bugs that passed through the type-system and tests than fixing typos in dynamically typed languages.
  - lloyd-christmas 10y ago
    > Both styles still encourage a lot of mutability and complexity throughout the codebase. > You'd get more robustness by managing complexity and state; The top function has a return value of T. That's not encouraging mutability. It's only mutable because JS pass by reference, which is irrelevant to static/dynamic. If you use the return value instead of the passed value, it's "effectively" immutable and is a great way of managing state.

wvenable 10y ago

Type inference makes all the difference in my opinion. Once you have even simple (C# level) type inference than the overhead of static typing is so low there isn't much reason to use dynamic typing.

jeremiep 10y ago
Yes I agree type inference is wonderful! But when the underlying type-system is just C# I feel like I'm given a half-assed solution. What good is having a int type if you can't limit its range? I'm not going to maintain BOTH static types and tests. The ROI is way too low on that and won't even come close to guarantee robustness. Assertions over composable predicates gives me much more out of the time invested to write it. They are right there in the code at runtime, not separate like unit tests or in a different phase like static types.
- wvenable 10y ago
  > What good is having a int type if you can't limit its range? Well then you don't have to test what happens when someone passes a string, an object, or a boolean. Most dynamic languages will silently convert many of these values into an int and produce incorrect results. > I'm not going to maintain BOTH static types and tests. You have to maintain documentation and you have to maintain tests and you have to maintain assertions for the implied types of your functions anyway so you might as well make them explicit in the code.
  - jeremiep 10y ago
    > Well then you don't have to test what happens when someone passes a string, an object, or a boolean. That's useless, I still need to test the value's range which implicitly checks the type. > You have to maintain documentation and you have to maintain tests and you have to maintain assertions Not if I can generate most of it from the specification data.
- wvenable 10y ago
  > What good is having a int type if you can't limit its range? Most types in the program aren't ints anyway; they're interfaces. If I want to have a range-limited value, I could just create a new type for it.

coldtea 10y ago

>Oh I know, but my opinion and experience in half a dozen statically typed languages over a decade is that most type systems add much more overhead to development than agility. In what sense? With type inference you don't have to manually specify them. With a variant type, you don't have to confirm to a specific type, but can accept all, if you want it. And you still need to conform to an interface in a dynamic language, if your function is x.indexOf(x) you still need to make sure to use it on two strings, if it's a math function on some numbers (and depending on the function, on a range), etc (1). So you are not even spared that -- instead, you just lose the help from the compiler when it comes to it. (1) You could e.g. let a numeric type string autocoerce of course, but auto-coercion can also happen in static languages, is orthogonal to static vs dynamic typing, and is also generally to be avoided).

lloyd-christmas 10y ago

> most type systems add much more overhead to development than agility I think this is true to a certain extent, but with a language like JS, there is a lot more composition of generics than there is inheritance. I see: add5toStuff<T extends {stuff: number}>(item: T): T; drastically more than: class X {} class Y extends X {} class Z extends Y {} The latter is always a nightmare of fighting the compiler. The former is a breeze to deal with. Your type casting will be limited almost completely to IO.

jeremiep 10y ago
Both styles still encourage a lot of mutability and complexity throughout the codebase. The vast majority of typed web codebases I've seen were exercises in Java Enterprise development of various degrees. Generics or not the time spent typing everything is not matched by the advantages of static typing. You'd get more robustness by managing complexity and state; I've spent far more time hunting down bugs that passed through the type-system and tests than fixing typos in dynamically typed languages.
- lloyd-christmas 10y ago
  > Both styles still encourage a lot of mutability and complexity throughout the codebase. > You'd get more robustness by managing complexity and state; The top function has a return value of T. That's not encouraging mutability. It's only mutable because JS pass by reference, which is irrelevant to static/dynamic. If you use the return value instead of the passed value, it's "effectively" immutable and is a great way of managing state.