Why doesn’t Interface description language become popular? 

Software is designed with contracts primarily because it is difficult to build it all at once.  Interfaces form a scaffolding that lets components be designed independently. A language used to define interfaces is enhanced to include many keywords to derive maximum benefit of describing the contract.  Software engineers love the validation that can be offloaded once the criteria is declared this way. Yet Interfaces or contracts do not become popular. Technologies that used such contracts as Component Object Model (COM) and Windows Communication Framework (WCF) were replaced with simpler and higher granularity and stateless mechanisms. This writeup tries to enumerate the reasons for this unpopularity. 

Contracts are verbose. They take time to be written. They are also brittle when business needs change and the contract requirements change. Moreover, they become difficult to read and orthogonal to the software engineers efforts with the component implementation. On the other hand, tests are improved because the success and the failure of the components as well as their functional and non-functional requirements can now be determined.  If the software does not work as expected, it might end up to be a miss or incorrect specification in the contract. 

Contracts are also static and binding for the producer and consumer. If they are static, it is easy to ship it to the consumer for offline software development. At the same time, the consumer might need to articulate changes to the contract if the interface is not sufficient. This bring us to the second drawback that changes to the contract are going to involve escalations and involvement.  

Contracts whether for describing services or for component interactions, are generally replaced by technologies where we use pre-determined and well-accepted verbs so that the lingo is the same but the payloads differ. Here we can even browse and determine the sequence of operations based on the requests made to the server. This dynamic discoverability of the necessary interactions helps eliminate the need for a contract. Documentation also improves the need to have explicit contracts and the chores needed to maintain them.  

Conclusion: Contracts provide the comfort for participants to work independently, offload validation, determine functional and non-functional requirements but the alternative to work with granular stateless requests that are well documented are a lot more appealing. 

#sqlexerrcise
Consider a set of players each of whom belongs to one and only one league. Each player may have several wins and losses as part of the games between leagues. A league may have any number of players.
Define a suitable schema and list all those players who have more wins than losses.
write a table valued function for SELECT player, count(*) as wins from GAMES where result='win' GROUP BY PlayerID
write a table valued function for SELECT player, count(*) as losses from GAMES where result='loss' GROUP BY PlayerID
Use the results A and B from above to determine count as
SELECT A.PlayerID, A.wins, B.losses from A INNER JOIN B on A.PlayerID = B.playerID where A.wins - B.losses > 0;
or we could use the PIVOT operator with the sum aggregate in this case.