Arguably they are supported in virtually every programming language.
What you need are "assertions".
These are easily coded as "if" statements:
if (!assertion) then AssertionFailure();
With this, you can write contracts by placing such assertions at the top of your code for input constraints; those at the return points are output constraints. You can even add invariants throughout your code (although aren't really part of "design by contract").
So I argue they aren't widespread because programmers are too lazy to code them, not because you can't do it.
You can make these a little more efficient in most languages by defining a compile-time boolean constant "checking" and revising the statements a bit:
if (checking & !Assertion) then AssertionFailure();
If you don't like the syntax, you can resort to various language abstraction techniques such as macros.
Some modern languages give you nice syntax for this, and that's what I think you mean by "modern language support". That's support, but its pretty thin.
What most of even the modern languages don't give you is "temporal" assertions (over arbitrary previous or following states [temporal operator "eventually"], which you need if you want to write really interesting contracts. IF statements won't help you here.
Adjectives are really just attribute evaluation. Here's how I might handle it in JavaScript.
function PersonAdjectiveConstructor(person) {
this.isTall = (person.height >= 6);
this.isRich = (person.pocketMoney >= 1000000);
this.isSmart = (person.iq > person.shoeSize);
this.isInsufferable = ( this.tall && this.rich && this.smart );
//formerly (for comment context):
//this.isInsufferable = ( this.smart && this.rich && this.smart );
}
function PersonConstructor(personAttributes){
for(var x in personAttributes){
this[x] = personAttributes[x];
}
var adjectives = new PersonAdjectiveConstructor(this);
for(var x in adjectives){
this[x] = adjectives[x];
}
}
var bob = new PersonConstructor({ shoeSize:11, iq:12, height:6.25, pocketMoney:2000000 });
console.log(bob.isInsufferable);//true
Best Answer
Let's let Eric Lippert answer this one:
In the next article, he explains how asynchrony and continuations are exactly equivalent to one another, and goes over a demonstration of taking a simple, (but blocking,) synchronous network operation and rewriting it in asyncronous style, making sure to cover all the hidden gotchas that have to be covered in order to get it right. It turns into a massive mess of code. His summary at the end:
Both articles, and the following series on a new C# language feature that moves all this mess into the compiler and lets you write your code as normal control flow with a special keyword to mark certain parts as asynchronous, are well worth reading even if you're not a C# developer. I'm not, but it was still quite the enlightening experience when I ran across it for the first time.