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

[Franklin? Lee]

Those arguments are rules of thumb, which may or may not apply to DbC,
and speculation, based on why DbC isn't more popular, to explain why
DbC isn't more popular. They are general arguments for features in
general, whereas Marko has been giving arguments for why DbC in
particular is good or why it isn't more popular. The general arguments
don't address the specific arguments.

I don't use DbC, but I do use Numpy. Numpy is a very mathematical
library, with many pure functions. It has lots of similarities between
its functions and methods. I can easily see how design-by-contract can
help Numpy users read the documentation and compare functions.

Text is often less structured, so it is less likely to come out
consistent. After all, isn't that why we keep adding structure to it,
such as with Javadocs and Sphinx? Those examples add more syntax,
while Marko's proposal doesn't necessarily require more syntax.
On Tue, Sep 25, 2018 at 8:00 AM Hugh Fisher <hugo.fisher at gmail.com> wrote:
>
> > Date: Mon, 24 Sep 2018 09:46:16 +0200
> > From: Marko Ristin-Kaufmann <marko.ristin at gmail.com>
> > To: Python-Ideas <python-ideas at python.org>
> > Subject: Re: [Python-ideas] Why is design-by-contracts not widely
> >         adopted?
>
> [munch]
>
> > Python is easier to write and read, and there are no libraries which are
> > close in quality in Eiffel space (notably, Numpy, OpenCV, nltk and
> > sklearn). I really don't see how the quality of these libraries have
> > anything to do with lack (or presence) of the contracts. OpenCV and Numpy
> > have contracts all over their code (written as assertions and not
> > documented), albeit with very non-informative violation messages. And they
> > are great libraries. Their users would hugely benefit from a more mature
> > and standardized contracts library with informative violation messages.
>
> I would say the most likely outcome of adding Design by Contract would
> be no change in the quality or usefulness of these libraries, with a small
> but not insignificant chance of a decline in quality.
>
> Fred Brooks in his "No Silver Bullet" paper distinguished between essential
> complexity, which is the problem we try to solve with software, and accidental
> complexity, solving the problems caused by your tools and/or process that
> get in the way of solving the actual problem. "Yak shaving" is a similar, less
> formal term for accidental complexity, when you have to do something before
> you can do something before you can actually do some useful work.
>
> Adding new syntax or semantics to a programming language very often adds
> accidental complexity.
>
> C and Python (currently) are known as simple languages. When starting a
> programming project in C or Python, there's maybe a brief discussion about
> C99 or C11, or Python 3.5 or 3.6, but that's it. There's one way to do it.
>
> On the other hand C++ is notorious for having been designed with a shovel
> rather than a chisel. The people adding all the "features" were well
> intentioned,
> but it's still a mess. C++ programming projects often start by
> specifying exactly
> which bits of the language the programming team will be allowed to use. I've
> seen these reach hundreds of pages in length, consuming God knows how
> many hours to create, without actually creating a single line of useful
> software.
>
> I think a major reason that Design by Contract hasn't been widely adopted
> in the three decades since its introduction is because, mostly, it creates
> more accidental complexity than it reduces essential complexity, so the
> costs outweigh any benefits.
>
> Software projects, in any language, never have enough time to do everything.
> By your own example, the Python developers of numpy, OpenCV, nlk, and
> sklearn; who most certainly weren't writing contracts; produced better quality
> software than the Eiffel equivalent developers who (I assume) did use DbC.
> Shouldn't the Eiffel developers be changing their development method, not
> the Python developers?
>
> Maybe in a world with infinite resources contracts could be added to those
> Python packages, or everything in PyPi, and it would be an improvement.
> But we don't. So I'd like to see the developers of numpy etc keep doing
> whatever it is that they're doing now.
>
> --
>
>         cheers,
>         Hugh Fisher
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/