I am a big fan of assertions. Whenever I reach a point in my code where I say "that pointer can't possibly be null", I immediately write - assert( p != NULL ); - and whenever I say "this list can't possibly be longer than 256" I write assert len(l) <= 256. If you wonder why I keep doing this, it's because very often I'm wrong. It's not that I'm a particularly bad programmer, but sometimes I make mistakes, and even when I don't, sometimes I get very unexpected input, and even when I don't, sometimes other pieces of code conspire against me. Assertions save me from mythical bug hunts on a regular basis.

So, it's not a big surprise that I'm a big fan of contracts too. If you don't know what contracts are, they're essentially asserts that run at the beginning and end of each function, and check that the parameters and the return values meet certain expectations. In a way, function type declarations, as can be found in C or Java, are a special case of contracts. (Would you like to know more?)

Why not just use duck-typing?

Duck typing is great, but in my experience it becomes a burden as the system grows in size and complexity. Sometimes objects aren't fully used right away; they are stored as an instance variable, pickled for later use, or sent to another process or another computer. When you finally get the AttributeError, it's in another execution stack, or in another thread, or in another computer, and debugging it becomes very unpleasant! And what happens when you get the correct object, but it's in the wrong state? You won't even get an exception until something somewhere gets corrupted.

In my experience, using an assertion system is the best way to find the subtle bugs and incongruities of big and complex systems.

Why do we need something new?

Types are very confining, even in "typeless" dynamic languages. Take Python: If your API has to verify that it's getting a file object, the only way is to call isinstance(x, file). That forces the caller to inherit from file, even if he's writing a mock object (say, as an RPC proxy) that makes no disk access. In any static-type language the I know, it's impossible to say that you accept either int or float, and you're forced to either write the same function twice, or use a template and just define it twice.

Today's interfaces are ridiculous. In C#, an interface with a method that returns a IList<int> will be very upset if you try to implement it as returning List<int>! And don't even try to return a List<int> when you're expected to return List. Note that C# will gladly cast between these types in the code, but when dealing with interfaces and function signatures it just goes nuts. It gets very annoying when you're implementing an ITree inteface and can't use your own class as nodes' type because the signatures collide, and instead you have to explicitly cast from ITree at every method. But I digress.

Even if today's implementations were better, types are just not enough. They tell you very little about the input or the output. You want to be able to test its values, lengths, states, and maybe to even interact with it to some degree. What we have just doesn't cut it.

What should we do instead?

Contracts are already pretty good: they have a lot of flexibility and power, they're self-documenting, and they can be reasoned upon by the compiler/interpreter ("Oh it only accepts a list[int<256]? Time to use my optimized string functions instead!"). But they only serve as a band-aid to existing type systems. They don't give you the wholesome experience of abstract classes and methods. But, they can.

To me, contracts are much bigger than just assertions. I see them as stepping-stones to a completely new paradigm, that will replace our current system of interfaces, abstract methods, and needless inheritance, with "Contract Protocols".

1.  Be able to state your assertions about a function, in a declarative manner. Treat these assertions as an entity called a "contract".  We're in the middle of this step, and some contract implementations (such as the wonderful PyContracts for python) have already taken the declarative entity route, which is essential for the next step.
2. Be able to compare contracts. Basically, I want to be able to tell if a contract is contained within another contract, so if C1⊂C2 and x∊C1 then x∊C2. I suspect it's easier said then done, but I believe that the following (much easier) steps render it as worth doing.
3. Be able to bundle contracts in a "contract protocol", and use it to test a class. A protocol is basically just a mapping of {method-name: contract}, and applying it to a class tests that each method exists in the class, and that its contract is a subset of the protocol's corresponding contract. If these terms are met, it can be said that the class implements the protocol. A class can implement several protocols, obviously.
4. Be able to compare protocols. Similarly to contracts, we want to check if a protocol is a subset of another protocol. Arguably, it's the same as step 3.
5. Contracts can also check if an instance implements a protocol. Making a full circle, we can now use protocols to check for protocols and so on, allowing layers of complexity. We can now write infinitely detailed demands about what a variable should be, but very concisely.

When we finish point 5, we have a complete and very powerful system in our hands. We don't need to ever discuss types, except for the most basic ones. Inheritance is now only needed to gain functionality, not identity. We can use it for debug-only purposes, but also for run-time decisions in production (For example, in a Strategy pattern).

Example

As a last attempt to get my point across, here is vaguely how I imagine the file protocol to look in pseudo-code.

It doesn't do the idea any justice, but hopefully it's enough to get you started.

protocol Closeable:
<pre>    close()

protocol _File < Closeable:
    [str] name
    [int,>0] tell()
    seek( [int,in (0,1,2)] )

protocol ReadOnlyFile < _File:
    [str,!=''] read( [int,>0 or None]? )
    [Iterable[str]] readlines( )
    [Iterable[str]] __iter__( )

protocol WriteOnlyfile < _File:
    [int,>0] write( [str,!=''] )
    writelines( [Iterable[str]] )
    flush()

protocol RWFile < ReadOnlyFile | WriteOnlyFile:
    pass

>>> print ReadOnlyFile < RWFile
True
>>> print implements( open('bla'), ReadOnlyFile )
True
>>> print implements( open('bla'), Iterable )  # has __iter__ function,
True
>>> print implements( open('bla'), Iterable[int] )
False
>>> print implements( open('bla'), WriteOnlyFile )  # default is 'r'
False
>>> print implements( open('bla'), RWFile )
False
>>> print implements( open('bla', 'w+'), RWFile )
True