On 2018-11-18 00:10, Maciej Sobczak wrote:

>> Zasada jest taka że jeśli kod
>> kontrolujący stan miałbym mieć więcej linijek niż goły algorytm to
>> *zaciemnia* kod
>
> Tak, to ważna obserwacja. Może da się te rzeczy rozdzielić? Tak jak rozdziela się
interfejs
> od implementacji? Zwłaszcza wtedy, gdy jakieś warunki faktycznie należą do
interfejsu? Akurat
> niezmienniki pętli należą do implementacji (i potrafią pięknie zaciemnić kod), ale
takie rzeczy
> jak "parametr powinien być między 0 a 20" albo "wartość zwracana powinna być w
zakresie indeksów
> tablicy" to intefejs. I może da się to wtedy zapisać gdzieś w okolicy deklaracji
tak, żeby
> użytkownik to widział (i mógł się pod to sprawdzić)? Tak działa SPARK i przyznam,
że podoba
> mi się.

Np. w Pythonie do takich rzeczy (DBC) dobrze nadają sie dekoratory
funkcji/metod/klas (ich dzialanie jes o wiele szersze/bardziej
dynamiczne niz dekoratory/annotacje z innych jezykow programowania
np.Javy).

>> Po jakiś 20 latach stukania w klawisze
>> widziałem kod opakowany DbC po brzegi i wymagał on niesłychanie dużo
>> czasu aby zorientować się gdzie jest algorytm a gdzie checkery.
>
> Nie zawsze sama koncepcja programistyczna musi ją przekreślać.
> Tzn. to nie musi być wina DbC, że kod jest nieczytelny.

Racja.

> A może wtedy należy odwrócić kolejność i zamiast szukać języka, gdzie to jest
> czytelne (albo zamiast doklejać DbC do używanego języka), można taki język zrobić?
> W sensie - zamiast rezygnować z DbC, bo jest nieczytelny, zróbmy język tak,
> żeby to było czytelne. To nie są zupełnie teoretyczne pytania.

..czasem wystarczy w danym jezyku dobrze to zaiplementowac.
Np. w Pythonie "od lat" stosuję zope.interface i bardzo sobie chwalę

https://pypi.org/project/zope.interface/
https://zopeinterface.readthedocs.io/en/latest/
np.
https://zopeinterface.readthedocs.io/en/latest/READM
E.html#invariants

AK