[awj]

Well written Haskell code pushes as much of the business rules as possible into the type system. It uses the type system as a tool to keep you from forgetting to check corner cases or prevent you from creating states that make no sense in the context of business rules.

The canonical example here is using a distinct type that can only be produced by conversion functions to ensure that user input is always escaped correctly on it's way to the database or a web page. Code that fails to perform this escaping won't just send dangerous data somewhere, it will fail to compile. With care, the same can be done for ensuring business rules are also observed. In many ways the distinct-types-with-conversion-functions pattern is the tip of the iceberg here.

It's obviously possible to not do this, but that's a bit like using a database by shoving all of your data into one giant string then complaining that the database doesn't help you with anything.

[jasonjackson]

Cool, this can be done in any language with typing. For languages with dynamic typing, you would just check the type at runtime.

[beala]

There is a big difference between static and dynamic checking. In a statically checked language like Haskell the error is guaranteed to be caught at compile time rather than maybe being caught runtime.

[gizmo686]

One of the main things that drew me to Haskell is how little effort it takes to define a new type.

[awj]

It can be, yes, but it's easier to do so in Haskell. Some of the compiler extensions allow you to push truly crazy invariants through type checking.

Also, for most dynamic languages, checking the type at runtime goes against the grain of the language. Python or Ruby code that is littered with type checks is often unnecessarily brittle.