[hibikir]

Optional typing like the one we see here is not uncommon in other dynamic languages: For instance, Clojure has core.typed and prismatic schema, which approach the problem in ways related to what the article shows.

However, while optional typing gives you some benefits over purely dynamic typing, the fact that it's all bolted-on causes a variety of problems. First, there's the fact that you'll have code with types interact with code without them. This eventually causes more trouble than it solves.

IMO, the biggest issue though is that what we really see from most of these systems is to add optional type systems that are comparable to very simple type systems, like Java's. But those strongly typed systems are not really that powerful! The real power of static typing doesn't come from being able to make sure we don't mix strings and integers, but in doing type checking for much more complex abstractions. Type systems like Scala's, or Haskell's. Creating an optional typing linter that looks at that high a level, and doesn't cause much of pain, is not something I've ever seen. Type inference with generics, existential types, higher kinded types, algebraic types. That's where the real value is, and where modern typed languages are.

Aiming optional typing at where typed languages were 20 years ago is not going to help bridge the gap. If anything, I think it makes it wider, because then fans of dynamic languages think they understand the position of proponents of type systems when, in fact, they are looking at a strawman from the past.

[zimbatm]

It's more helpful to think about classes of errors and what the type system prevents.

A simple type system prevents type mismatch errors. A more complex type system like Haskell's might be able to encode interfaces and other rules but might also has it's limits.

The trade-off is usually that the more classes of errors you remove, the more complex the type-system becomes. Over the lifetime of your program, how much time did you spend hunting bugs vs time spent in long compilations or encoding all the rules.

I guess my point is that a lite-weight type system might also be enough.

[tome]

> time spent in long compilations

Type checking Haskell, for example, is actually incredibly fast and adds basically nothing to compilation time. This isn't one of the drawbacks of a type system.

[PeCaN]

For the record, I've never really had a problem with GHC having long compilation times. If anything it's remarkably fast for what it does (IMO, it's the closest thing to a "sufficiently smart compiler" currently available).

[matt_kantor]

I haven't had an opportunity to actually use it, so take this with a grain of salt, but the optional/gradual type system of TypeScript looks decently expressive (http://www.typescriptlang.org/Handbook).