4 ms·

I applaud the effort to try and dissect the problem scientifically. If a whole program has 1 bug due to being implemented with dynamic types over static types,

I applaud the effort to try and dissect the problem scientifically. If a whole program has 1 bug due to being implemented with dynamic types over static types, and that bug has gone unnoticed, then it can't be particularly important. The other common proposition is that dynamically typed languages are faster to write in than statically typed languages. If this is true then we need to compare the saving in development time with the cost of the bugs which go undetected. My gut feeling says that this line of analysis is never going to prove that static typing in inherently "better".

cageface 14y ago
What? He specifically says that many of the bugs he discovered were exploitable. Just because you missed them doesn't mean some hacker won't.
Deestan 14y ago
> The other common proposition is that dynamically typed languages are faster to write in than statically typed languages. This part is also very tricky, as most of people's hard-earned experience with this is (almost by definition) old. In recent years, type inference has reduced the type-caused slowdown immensely. E.g. in Haskell you can (+) write large statically typed programs without specifying any types at all - they are inferred by the compiler. (+) But please don't.
- Dn_Ab 14y ago
  Heh I had to parse your sentence twice as (+) is a function in Haskell.
- IsTom 14y ago
  Recent years? 70s more like. ML way is to not write type annotations unless they're needed, not that I agree with it, but it certainly works in some way.
johnkchow 14y ago
From my personal experience, the saving in development time is very much real. I used to work on .NET, and you'd have to program against crazy, non-intuitive patterns in order to have your code "clean" (I hated IoC containers as well as writing all that boilerplate code for Attributes. And for Java, remember that hilarious post about Factory-Factory-Factory patterns http://discuss.joelonsoftware.com/default.asp?joel.3.219431? http://discuss.joelonsoftware.com/default.asp?joel.3.219431?) I'm not saying statically typed languages are bad. Type errors always bite me the ass in Ruby, but it's a small price to pay (IMO) for better maintainability. EDIT: By the way, it sounds like I'm an ignorant dynamically-typed lover. I'm not, I still yearn for those type safety net, but I'm just speaking from a pragmatic perspective.
- cageface 14y ago
  The kinds of static type systems you find in C# & Java are too primitive. Something like Haskell with perhaps a little less religion about mutability is a whole different story.
  - michaels0620 14y ago
    Does Scala fit your idea of something in between? It has nice type inference features and does not require pure immutability.
    - deleted 14y ago
      [deleted]
    - cageface 14y ago
      Personally I like Scala but I think it's too complex and a little too clever to escape the FP niche. I'd be happy to be wrong about this.
      - soc88 14y ago
        Interesting. I never perceived Scala to be in a functional niche. As far as I know most people consider it to be an object-oriented language first and foremost, with functional features. Removing inheritance would have made the language (and every other language, too) a lot easier, but seeing that people cope with C# or Java quite well I'm not sure about the merit of the "complex" claim. Comparing the C# and the Scala spec is very enlightening, even though they have different writing styles of course (so I won't bother bringing up page numbers). Checking and realizing which "features" are in one language, but not in the other, is very helpful to gain some insight into this topic. What do you think?
tikhonj 14y ago
An interesting thought: a good type system can actually make a language more expressive. A perfect example is QuickCheck. QuickCheck allows you to write complicated tests very simply by relying on the type system. You just write out the invariant and the type system automatically figures out which random generators to use to run the tests. QuickCheck has been ported to a bunch of other languages, but it's more complex and seems harder to use in dynamically typed languages as compared to Haskell. A simpler example in the same vein is Haskell's read function. Essentially, read is the opposite of toString--it goes from a string to some value. The beauty is that you never need to specify what type you're parsing; it can figure out what type it needs to be thanks to the type system. So instead of having a bunch of functions like parseDouble and parseInt, you have a single read function. This also makes the library prettier by maintaining the symmetry between show and read (toString and fromString).

cageface 14y ago

What? He specifically says that many of the bugs he discovered were exploitable. Just because you missed them doesn't mean some hacker won't.

Deestan 14y ago

> The other common proposition is that dynamically typed languages are faster to write in than statically typed languages. This part is also very tricky, as most of people's hard-earned experience with this is (almost by definition) old. In recent years, type inference has reduced the type-caused slowdown immensely. E.g. in Haskell you can (+) write large statically typed programs without specifying any types at all - they are inferred by the compiler. (+) But please don't.

Dn_Ab 14y ago
Heh I had to parse your sentence twice as (+) is a function in Haskell.
IsTom 14y ago
Recent years? 70s more like. ML way is to not write type annotations unless they're needed, not that I agree with it, but it certainly works in some way.

johnkchow 14y ago

From my personal experience, the saving in development time is very much real. I used to work on .NET, and you'd have to program against crazy, non-intuitive patterns in order to have your code "clean" (I hated IoC containers as well as writing all that boilerplate code for Attributes. And for Java, remember that hilarious post about Factory-Factory-Factory patterns http://discuss.joelonsoftware.com/default.asp?joel.3.219431? http://discuss.joelonsoftware.com/default.asp?joel.3.219431?) I'm not saying statically typed languages are bad. Type errors always bite me the ass in Ruby, but it's a small price to pay (IMO) for better maintainability. EDIT: By the way, it sounds like I'm an ignorant dynamically-typed lover. I'm not, I still yearn for those type safety net, but I'm just speaking from a pragmatic perspective.

cageface 14y ago
The kinds of static type systems you find in C# & Java are too primitive. Something like Haskell with perhaps a little less religion about mutability is a whole different story.
- michaels0620 14y ago
  Does Scala fit your idea of something in between? It has nice type inference features and does not require pure immutability.
  - deleted 14y ago
    [deleted]
  - cageface 14y ago
    Personally I like Scala but I think it's too complex and a little too clever to escape the FP niche. I'd be happy to be wrong about this.
    - soc88 14y ago
      Interesting. I never perceived Scala to be in a functional niche. As far as I know most people consider it to be an object-oriented language first and foremost, with functional features. Removing inheritance would have made the language (and every other language, too) a lot easier, but seeing that people cope with C# or Java quite well I'm not sure about the merit of the "complex" claim. Comparing the C# and the Scala spec is very enlightening, even though they have different writing styles of course (so I won't bother bringing up page numbers). Checking and realizing which "features" are in one language, but not in the other, is very helpful to gain some insight into this topic. What do you think?

tikhonj 14y ago

An interesting thought: a good type system can actually make a language more expressive. A perfect example is QuickCheck. QuickCheck allows you to write complicated tests very simply by relying on the type system. You just write out the invariant and the type system automatically figures out which random generators to use to run the tests. QuickCheck has been ported to a bunch of other languages, but it's more complex and seems harder to use in dynamically typed languages as compared to Haskell. A simpler example in the same vein is Haskell's read function. Essentially, read is the opposite of toString--it goes from a string to some value. The beauty is that you never need to specify what type you're parsing; it can figure out what type it needs to be thanks to the type system. So instead of having a bunch of functions like parseDouble and parseInt, you have a single read function. This also makes the library prettier by maintaining the symmetry between show and read (toString and fromString).