You can start with simple types in Haskell too, FWIW. To take your phone number example, let's say I'm making a very simple program that dials a number. In Ru

You can start with simple types in Haskell too, FWIW. To take your phone number example, let's say I'm making a very simple program that dials a number. In Ruby, I'm talking about something like: aNumber = "+0123456789" def dial(number) # does the dialling return someConnection end dial(aNumber) (It's been a long time since I've done any Ruby, so forgive any glaring syntax faults.) That method expects a string - aNumber is an example of which - but there's no annotation to explain that to the runtime (Ruby doesn't have a compiler in the sense we refer to one here). In Haskell, something similar might look like this (I'm going to be verbose and specify types here, but the compiler can actually infer a few of them): aNumber :: String aNumber = "+0123456789" dial :: String -> PhoneConnection dial number = -- a function which does some dialing -- somewhere else, the above is called as someConnection = dial aNumber The "::" lines are type signatures. The first says that the variable aNumber is a String. The second says that the function "dial" takes a string argument, and returns an instance of the PhoneConnection type (in real Haskell, there'd be some IO monad stuff wrapping it, but we can happily ignore that for now). Type signatures aren't generally used when defining variables, and Haskell can generally infer them for simple functions - but they're very useful when writing code, as alongside informing the compiler of our intent, they inform other developers of what the function does. Anyone coming along in future can easily see that they need to pass the "dial" function a String, for instance, and will get back a PhoneConnection. In Ruby, however, other developers either need to hope you've documented it, or inspect your code to figure out what it expects. FWIW, in Java, the function definition/type signature might look like: public PhoneConnection dial(String number) {} Now, let's say I want to make things a little more obvious to people reading my code. I can make the following nips/tucks: type PhoneNumber = String aNumber :: PhoneNumber aNumber = "+0123456789" dial :: PhoneNumber -> PhoneConnection dial number = -- a function which does some dialing Here, we've used Haskell's type aliasing. All this does is say that the type PhoneNumber is the same as a String. It's not really useful at this point, but it means that it's a little more clear what the dial function requires. Developers inspecting it will see that the PhoneNumber type is really a string, but they can see what it is that String is supposed to store (of course, they still have no idea of intent). There's no real analogy for Java here - it'd be like saying something like: public class PhoneNumber extends String {} (Note that: the Java code doesn't define any new functions for PhoneNumber, the Haskell code isn't really object extension, and the Java String class is final so you can't do this anyway. It's not really like doing that at all, but hopefully it illustrates the point). Now, let's say I want to change this String into an object, to make it more robust. In Ruby: class PhoneNumber def initialize(countryCode, areaCode, number) @countryCode = countryCode @areaCode = areaCode @number = number end end The code inside the dialling function will also change, but the actual function definition _doesn't_ - and any code calling that "dial" function won't be aware that it needs to change. It's still: def dial(number) # ... end dial(aNumber) # which might still be our string, so at runtime, we're going to crash! In Haskell, you might do something like: data PhoneNumber = PhoneNumber { countryCode :: Int, areaCode :: Int, number :: Int } aNumber = PhoneNumber 01 23 456789 dial :: PhoneNumber -> PhoneConnection dial number = -- do stuff Now, because you have that type definition, anything that still uses String numbers will cause compilation to fail. Your code will not produce an executable that you can run. Which is a Good Thing(tm)! Because it means that you've prevented a whole class of runtime error/crash. So, yeah. Static typing is cool because (with a compiler) it helps you catch and prevent runtime errors. Haskell's is particularly cool because it's very terse, and very flexible (I haven't really got into it here, fwiw - this was a very basic example :)) - which prevents some of the extreme annoyances you face dealing with Java's verbose (and, thanks to generic type erasure, slightly broken) type system. PS, as a little extra - Nil/NullPointerException type stuff is difficult to cause in Haskell. When you say a function returns a type - PhoneConnection - it must return that type. If there's a chance of it erroring and returning Nil/null, you return a "Maybe" type which encapsulates it instead. That means, of course, updating your type signature: dial :: PhoneNumber -> Maybe PhoneConnection Which, in turn, means that before you can extract any data out of the PhoneConnection,you explicitly must check that there's actually something there you can work with - which is very, very cool :).