5 ms·

What if most type system security is a waste? I don't personally believe this is the case, but I also can't tell you I know it to be false. What I do know is t

What if most type system security is a waste? I don't personally believe this is the case, but I also can't tell you I know it to be false. What I do know is that types have a non-zero cost, and I think sometimes that's ignored, and only their benefits are acknowledged. But the efforts to bring types to historically dynamic languages show that not all common dynamic language idioms are amenable to reasonable type signatures. While some idioms (e.g. monkey patching) are problematic, that's not the case of all of them.

walshemj 7y ago
Apart from a bit more typeing up front I cant see many costs to typing.
- osrec 7y ago
  They can also be more difficult to refactor and adjust at a later date. This can be especially problematic if you're in an environment where logic needs to be altered rapidly in response to changing external conditions/requirements.
  - dahfizz 7y ago
    The added "difficulty" is just the cost of doing a proper, correct refactor. Dynamic languages are not helpful just because they let you write bugs faster.
    - chrisan 7y ago
      I wouldnt even call that difficulty. That is a bloody loved feature in my book
    - sjy 7y ago
      Developers are expensive though. If dynamic languages let you write buggy code in half the time that it would take to write perfect code in a static language, that would be an acceptable trade-off in many contexts.
      - walshemj 7y ago
        Fixing bug later on get progressively more expensive, I though we had got over the KLOC metric decades ago.
      - adwn 7y ago
        > If dynamic languages let you write buggy code in half the time that it would take to write perfect code in a static language, that would be an acceptable trade-off in many contexts. Shit at 50% off is still shit. You're not being paid to produce shit, even if you might be really, really efficient at doing so.
        sjy 7y ago
        I assure you that many developers are being paid to produce shit.
  - walshemj 7y ago
    Can you give some examples why - do you mean changing a variables type? that should jut be a matter of a find and replace.
- rstuart4133 7y ago
  Try programming in Rust. The upfront cost in figuring out how to write the code to minimise unsafe()'s can be very high. This is because Rust's type system is so strong it both does the work of the garbage collector and catches things other languages would miss, like memory leaks. That aside, that "bit" of typing can amount to a lot. Python programs are usually very compact compared to statically typed languages. Yes, this means writing more unit tests to cover the bits the type checker would have caught, but in my experience the total LOC with unit tests for 100% coverage in Python is still less than a statically types language. That said, I still prefer statically types languages. The big difference between statically typing and unit tests is when the error is caught. Static typing catches the errors very early. In fact in modern IDE's that do incremental compiles it's literally after you have typed the statement. Errors that hang around tend to ripple through your code because your mental model is wrong, so catching them early means less errors in total. The effect can be large.
  - Too 7y ago
    Python is very compact even with heavy use of type annotations. It's not the types that add the bulk of the code, other languages usually are more verbose in other ways also.
    - anoncake 7y ago
      In a statically typed language, you sometimes have to make the code more verbose to satisfy the type checker. In Python, you can just not use it in those cases.
- raverbashing 7y ago
  That's because you (and many others) are drinking the static typing koolaid Now try serializing things in XML instead of JSON. But not one type of message, multiple types, with flexible formats. "Oh but this never happens" except it does. Not to mention the iteration speed whenever you need to fix something.
  - walshemj 7y ago
    ?? sorry what do you mean, I was happily reading multiple types of logs with multiple different format records for a Billing system using statically typed PL/1G in the 80's Apart from both json and XML are a PITA to work with in the first place
    - ptx 7y ago
      JSON is wonderfully simple to work with - in a dynamic language. Having to map it to a statically known schema, as you would in a statically typed language, loses that simplicity and can be, as you say, a PITA.
      - Gibbon1 7y ago
        I think that's a defect of JSON not statically typed languages.
        raverbashing 7y ago
        "defect of JSON" while it could be better, it has some type definitions and as I said, people are too deep in the static world to see outside of it
- tsimionescu 7y ago
  There are costs, and they go up significantly the more sophisticated your type system is/the more speicifc you try to be with your types. The way I see it there are two kinds of costs type systems may impose. Very simplistic type systems, such as the ones in C, Go, and even C++, Java, C#, often force you to write code that is too specific, thus forcing duplication (C and Go especially suffer terribly from not having generics - in Go especially its impossible to write a well typed function that can be passed an array of any kind and return an element of that array). On the other hand, of your type system is powerful enough, you still get a similar problem when trying to write code that is abstract enough to be reusable, but specific enough to be safe. For example, if you were writing code for a physical simulation system, you would want to have all quantities carry their measurement unit in their type, to avoid mismatches. However, you wouldn't want to rewrite maths code for each measurement unit. However, to properly keep track of types in complex maths code gets pretty ugly pretty quickly. For example, a function that wants to compute the scalar product of 2 2-dimensional vectors would only work if the first values of each vector have the same/convertible units as the second pair, in any order (m,s dot s,m should be ok). If you move to matrix multiplication, the types become even more complicated, and this is still very basic algebra. If you want your function to be applicable to arbitrary matrix sizes you're already writing a complex library.
- acjohnson55 7y ago
  I have two thoughts on this. First, static typed languages often simply subtract features that would be available in dynamic languages. So, that's a cost that's paid on day zero, and it can be easy to forget about. Secondly, there are absolutely times when something that is conceptually easy to describe is a real beast to model in a type system. Think DSLs for SQL, for example. A non-trivial amount of time can be lost fighting these battles.
- kybernetikos 7y ago
  That's because some of the cost you pay by changing the way you think so that it doesn't even occur to you to write programs that the type system won't like.

walshemj 7y ago

Apart from a bit more typeing up front I cant see many costs to typing.

osrec 7y ago
They can also be more difficult to refactor and adjust at a later date. This can be especially problematic if you're in an environment where logic needs to be altered rapidly in response to changing external conditions/requirements.
- dahfizz 7y ago
  The added "difficulty" is just the cost of doing a proper, correct refactor. Dynamic languages are not helpful just because they let you write bugs faster.
  - chrisan 7y ago
    I wouldnt even call that difficulty. That is a bloody loved feature in my book
  - sjy 7y ago
    Developers are expensive though. If dynamic languages let you write buggy code in half the time that it would take to write perfect code in a static language, that would be an acceptable trade-off in many contexts.
    - walshemj 7y ago
      Fixing bug later on get progressively more expensive, I though we had got over the KLOC metric decades ago.
    - adwn 7y ago
      > If dynamic languages let you write buggy code in half the time that it would take to write perfect code in a static language, that would be an acceptable trade-off in many contexts. Shit at 50% off is still shit. You're not being paid to produce shit, even if you might be really, really efficient at doing so.
      - sjy 7y ago
        I assure you that many developers are being paid to produce shit.
- walshemj 7y ago
  Can you give some examples why - do you mean changing a variables type? that should jut be a matter of a find and replace.
rstuart4133 7y ago
Try programming in Rust. The upfront cost in figuring out how to write the code to minimise unsafe()'s can be very high. This is because Rust's type system is so strong it both does the work of the garbage collector and catches things other languages would miss, like memory leaks. That aside, that "bit" of typing can amount to a lot. Python programs are usually very compact compared to statically typed languages. Yes, this means writing more unit tests to cover the bits the type checker would have caught, but in my experience the total LOC with unit tests for 100% coverage in Python is still less than a statically types language. That said, I still prefer statically types languages. The big difference between statically typing and unit tests is when the error is caught. Static typing catches the errors very early. In fact in modern IDE's that do incremental compiles it's literally after you have typed the statement. Errors that hang around tend to ripple through your code because your mental model is wrong, so catching them early means less errors in total. The effect can be large.
- Too 7y ago
  Python is very compact even with heavy use of type annotations. It's not the types that add the bulk of the code, other languages usually are more verbose in other ways also.
  - anoncake 7y ago
    In a statically typed language, you sometimes have to make the code more verbose to satisfy the type checker. In Python, you can just not use it in those cases.
raverbashing 7y ago
That's because you (and many others) are drinking the static typing koolaid Now try serializing things in XML instead of JSON. But not one type of message, multiple types, with flexible formats. "Oh but this never happens" except it does. Not to mention the iteration speed whenever you need to fix something.
- walshemj 7y ago
  ?? sorry what do you mean, I was happily reading multiple types of logs with multiple different format records for a Billing system using statically typed PL/1G in the 80's Apart from both json and XML are a PITA to work with in the first place
  - ptx 7y ago
    JSON is wonderfully simple to work with - in a dynamic language. Having to map it to a statically known schema, as you would in a statically typed language, loses that simplicity and can be, as you say, a PITA.
    - Gibbon1 7y ago
      I think that's a defect of JSON not statically typed languages.
      - raverbashing 7y ago
        "defect of JSON" while it could be better, it has some type definitions and as I said, people are too deep in the static world to see outside of it
tsimionescu 7y ago
There are costs, and they go up significantly the more sophisticated your type system is/the more speicifc you try to be with your types. The way I see it there are two kinds of costs type systems may impose. Very simplistic type systems, such as the ones in C, Go, and even C++, Java, C#, often force you to write code that is too specific, thus forcing duplication (C and Go especially suffer terribly from not having generics - in Go especially its impossible to write a well typed function that can be passed an array of any kind and return an element of that array). On the other hand, of your type system is powerful enough, you still get a similar problem when trying to write code that is abstract enough to be reusable, but specific enough to be safe. For example, if you were writing code for a physical simulation system, you would want to have all quantities carry their measurement unit in their type, to avoid mismatches. However, you wouldn't want to rewrite maths code for each measurement unit. However, to properly keep track of types in complex maths code gets pretty ugly pretty quickly. For example, a function that wants to compute the scalar product of 2 2-dimensional vectors would only work if the first values of each vector have the same/convertible units as the second pair, in any order (m,s dot s,m should be ok). If you move to matrix multiplication, the types become even more complicated, and this is still very basic algebra. If you want your function to be applicable to arbitrary matrix sizes you're already writing a complex library.
acjohnson55 7y ago
I have two thoughts on this. First, static typed languages often simply subtract features that would be available in dynamic languages. So, that's a cost that's paid on day zero, and it can be easy to forget about. Secondly, there are absolutely times when something that is conceptually easy to describe is a real beast to model in a type system. Think DSLs for SQL, for example. A non-trivial amount of time can be lost fighting these battles.
kybernetikos 7y ago
That's because some of the cost you pay by changing the way you think so that it doesn't even occur to you to write programs that the type system won't like.