<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div><div>Hi,<br><br></div>(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.)<br><br></div>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:<br><ul><li><a href="https://www.leadingagile.com/2018/05/design-by-contract-part-one/">https://www.leadingagile.com/2018/05/design-by-contract-part-one/</a></li><li><a href="https://ask.slashdot.org/story/07/03/10/009237/why-is-design-by-contract-not-more-popular">https://ask.slashdot.org/story/07/03/10/009237/why-is-design-by-contract-not-more-popular</a> -- this one is from 2007, but represents well IMO the way people discuss it<br></li><li><a href="https://stackoverflow.com/questions/481312/why-is-design-by-contract-not-so-popular-compared-to-test-driven-development">https://stackoverflow.com/questions/481312/why-is-design-by-contract-not-so-popular-compared-to-test-driven-development</a> and this answer in particular <a href="https://stackoverflow.com/a/28680756/1600678">https://stackoverflow.com/a/28680756/1600678</a><br></li><li><a href="https://softwareengineering.stackexchange.com/questions/128717/why-is-there-such-limited-support-for-design-by-contract-in-most-modern-programm">https://softwareengineering.stackexchange.com/questions/128717/why-is-there-such-limited-support-for-design-by-contract-in-most-modern-programm</a></li></ul><br></div><div>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<i>. <br><br></i>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<i> </i>and continue without formalizing the contracts in the code and keep on writing them in the descriptions.<br><br><i> Why is that so? </i>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?).<i><br><br></i></div><div>One explanation that seems plausible to me is that many programmers are actually having a hard time with formalization and logic rules (<i>e.g., </i>implication, quantifiers), maybe due to missing education (<i>e.g. </i>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?<br><br></div><div>What do you think? What is the missing part of the puzzle?</div><div><br></div><div>Cheers,<br></div><div>Marko<br></div><div><br></div></div></div></div></div></div></div></div>