On 18/11/2018 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ć?

To następna obserwacja: jeśl wpływa to na runtime release należy to
odrzucić. Wszelakie checkery asercyjne, za wyjątkiem programowania
defensywanego, nie mogą istnieć w kodzie produkcyjnym. Z marginesem
dyskusji o językach w których jest kłopot z warunkową kompilacją.

>> 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.
> Czy czytelność kodu nie jest też kwestią umiejętności piszącego?

Jest, ale w przypadku nadmiaru checkerów nie da się pisać czytelnie.
Nazjwyczajniej nie widać gdzie jest algorytm w morzu makr, asercji czy
fake funkcji. Widziałem kiedyś IDE które klapsowało asercje. Niestety
tylko asercje.

> Nie zawsze sama koncepcja programistyczna musi ją przekreślać. Tzn. to nie musi być
wina DbC, że kod jest nieczytelny.

Tak, ale nadmiar DbC generuje zaciemnienie kodu. Taki smutny praktyczny
wniosek. Biorę jednak pod uwagę że pracuje z toksyczym językiem.

>> Znacznie
>> bardziej ufam unit testom i coverage niż ręcznie pisanym DbC.
> W porządku. Testy też są potrzebne. A co jeśli część DbC można sprawdzić
statycznie?

Potrzebujemy kompilator który to by potrafił :) Jakiś porządny lint. Mój
język, C++, ma wyjątkowo popieprzony problem z side effects i kiesko
widzę kontrole DbC na poziomie statycznej analizy kodu. Może dla
prostych przypadków, ale takich za dużo nie ma.

> A co jeśli wtedy można by niektórych testów w ogóle nie mieć?

Dlatego używam np metaprogramowania do kontrolownia różych obliczeń.
Jednak dalej brakuje mi czegoś takiego jak int a<4-200> i kontroli
komilatora w debug kiedy a zmieni się poza zakres. Contraints by się
przydało i już powoduje to zniknięcie kilku lini DbC.

>> Być może
>> to jednak efekt języka, czyi w moim przypadku C++, nie wykluczam że
>> można to czytelniej zapisać gdzie indziej.
> 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ć?

Nie. Poza przypadkami jak clojure nie znam w zasadzie nic co mogło by
być uznane za projekt języka do potrzeb. Języki które są popularne mają
bibliteki, języki wymyślane nie. Na sam koniec wyjądujesz projektując
jeszcze jeden niszowy język na bytecode javy i z nią kompatybilny
którego nikt nie użyje poza helloworld.

Obserwuje że ludzie nie chcą języków bezpiecznych. Potrzebują zabawek
typu python albo stosu kupy typu perl i są zadowoleni.

> 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.

Język ten nie zdobedzie popularnosci. Wolałbym dodanie czegoś do
istniejących języków.

Na początek chciabym w C++ takie coś:

debug {
// O(N^2) checker
}

I ide kolapsujący te sekcje.