[Python-ideas] Why is design-by-contracts not widely adopted?

Marko Ristin-Kaufmann marko.ristin at gmail.com
Sun Sep 23 01:09:37 EDT 2018


Hi,

(I'd like to fork from a previous thread, "Pre-conditions and
post-conditions", since it got long and we started discussing a couple of
different things. Let's put the general discussion related to
design-by-contract in this thread and I'll spawn another thread for the
discussion about the concrete implementation of a design-by-contract
library in Python.)

After the discussion we had on the list and after browsing the internet a
bit, I'm still puzzled why design-by-contract was not more widely adopted
and why so few languages support it. Please have a look at these articles
and answers:

   - https://www.leadingagile.com/2018/05/design-by-contract-part-one/
   -
   https://ask.slashdot.org/story/07/03/10/009237/why-is-design-by-contract-not-more-popular
   -- this one is from 2007, but represents well IMO the way people discuss it
   -
   https://stackoverflow.com/questions/481312/why-is-design-by-contract-not-so-popular-compared-to-test-driven-development
   and this answer in particular
   https://stackoverflow.com/a/28680756/1600678
   -
   https://softwareengineering.stackexchange.com/questions/128717/why-is-there-such-limited-support-for-design-by-contract-in-most-modern-programm


I did see that there are a lot of misconceptions about it ("simple
asserts", "developer overhead", "needs upfront design", "same as unit
testing"). This is probably the case with any novel concept that people are
not familiar with. However, what does puzzle me is that once the
misconceptions are rectified ("it's not simple asserts", "the development
is actually faster", "no need for upfront design", "not orthogonal, but dbc
+ unit testing is better than just unit testing"), the concept is still
discarded

*. *After properly reading about design-by-contract and getting deeper into
the topic, there is no rational argument against it and the benefits are
obvious. And still, people just wave their hand and continue without
formalizing the contracts in the code and keep on writing them in the
descriptions.

* Why is that so? *I'm completely at loss about that -- especially about
the historical reasons (some mentioned that design-by-contract did not take
off since Bertrand Meyer holds the trademark on the term and because of his
character. Is that the reason?).

One explanation that seems plausible to me is that many programmers are
actually having a hard time with formalization and logic rules (*e.g.,
*implication,
quantifiers), maybe due to missing education (*e.g. *many programmers are
people who came to programming from other less-formal fields). It's hence
easier for them to write in human text and takes substantial cognitive load
to formalize these thoughts in code. Does that explains it?

What do you think? What is the missing part of the puzzle?

Cheers,
Marko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180923/13964f76/attachment-0001.html>


More information about the Python-ideas mailing list