[xapata]

> you can have your cake and eat it, too.

Like a dynamic language with optional type hints? As I said, both techniques can mimic each other, with the corresponding tradeoffs. As you use more generics in a statically typed language, you're sacrificing safety. As you use more type hints in a dynamically typed language, you're increasing syntax clutter and decreasing flexibility.

[wz1000]

> As you use more generics in a statically typed language, you're sacrificing safety

Actually, in languages like Haskell, the more generic your type, the more "safe" you can expect it to be.

As an example, consider a function that gives you the first element of the tuple you pass to it.

The most generic type of this function is

    fst :: (a,b) -> a

However, it can also have the type

    fst1 :: (Int, Int) -> Int

Now, you can be sure of the behaviour of fst immediately by looking at its type, but that doesn't hold for fst1

Pretty much the only definition of fst that the compiler will accept is

    fst (x,y) = x

However, the compiler will accept all the following definitions of fst1

    fst1 (x,y) = x+y
    fst1 (x,y) = x*y
    fst1 (x,y) = 2^x
    fst1 (x,y) = 7
    ...

[the_af]

No, not like a dynamic language with optional hints. "Optional" here is a huge disadvantage. For example, if a function lacks a hint which would indicate it's pure, is this because it's meant to be impure or because the programmer forgot to add the hint? No, in order to be useful, static typing must be on by default.

Like the other commenter says, generics actually increase safety: there are fewer assumptions (and therefore, incorrect assumptions, aka bugs) you can make when your functions are generic. Also, modern statically typed languages do not increase clutter by much, and can be very elegant and brief.