> Date: Mon, 24 Sep 2018 09:46:16 +0200
> From: Marko Ristin-Kaufmann <marko.ris...@gmail.com>
> To: Python-Ideas <python-ideas@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@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
