On 30/04/2021 13:22, J.F wrote:
>> Kod z '51 nigdzie się nie przydaje, poza Bytomiem i zegarem szkolnym.
> W zasadzie tak, ale ... to skad to narzekanie na '51 ?

Bo zostaly po nim techniki pisania kodu, które Heńki przenoszą na inne
dziedziny EDA.

>> Może jeszcze jakiś modemach GSM, ale tam napisano go w średniowieczu i
>> jest konsekrowany.
> Tam juz chyba cos lepszego potrzeba ... a moze nie?

Jakieś zastosowanie Bytomska najszybsza bryczka na świecie miała. Ponoć
w telefonach i ponoć w układach GSM. Masz wtedy 60x szybciej naliczanie
sekundowe i 200x dokładniejszy zegar uarta do komend AT!

>> Nie wydaje mi się, 64kB to 64 tysiące mozliwości spieprzenia czegoś.
>> Weryfikacja formalna kodu nie będzie zastanawiać się ile masz pamięci
>> RAM, bardziej ile masz stanów osiągalnych bez synchronizacji itd.
> Za to dosc istotne bedzie, jaki rozmiar ma ten kod zrodlowy.
> W 64KB nie zmiescisz paru mln linii programu :-)

Problem w tym, że to ma niewielkie znaczenie. Można mieć
nieweryfikowalny kod na tysiąc linijek i weryfikowalny na milion
zajmujacy gigabajt flash.

Kryterium pamieci czy długości kodu jest czynnikiem, ale raczej nie
decydującym, o możliwosciach stwierdzenia czy kod jest czy nie "dobry".

>>> Owszem, ale potem przychodzi deadline, kontrola mowi "tego nie mozemy
>>> wypuscic" a szef mowi "musimy" :-)
>> Takie rzeczy nie mogą miec miejsca, jeśli mówimy o poważnym sofcie od
>> którego zależy moje życie.
> Dobrze piszesz ... ale szef ma nieco inny punkt widzenia :-)

Dalej nie wydaje mi się aby crunching miał miejsce w firmie zajmującej
się produkcją poduszek powietrznych czy autopilotów. To nie kolejny
zegarek szkolny.

>>> Poza tym jak programista sie skupi na kontroli, to moze tak napisac
>>> program, ze testy przejdzie ...
>> I dostaniesz dobry program, jesli testy są dobre.
> Musza byc bardzo szerokie.

I są. Baza testów powinna być zdecydowanie większa niż kod, szczególnie
w zastosowaniach safety. Jaka będzie tego miara to inna sprawa, ale bez
wątpienia, ilość roboczogodzin napisanych na testy będzie większa niż na
kod.

>> Jeśli testy są złe, wiele z nich można przejśc return 4;
> OWszem, ale przewidzisz wszyskie sytuacje ?

Po to jest weryfikacja formalna aby przewidzieć *wszystkie*. Programista
ma tak pisać, aby mozna było *przynajmniej* wydzielić bloki kodu, które
są formalnie weryfikowalne lub są napisane w sposób pozwalajacy je
traktować i weryfikować osobno. To powoduje że testowanie wszystkiego
nie brzmi już tak utopijnie.

>>> A potem masz zadanie "redakcja nie chce png tylko jpg. Jak przerobic
>>> setke zdjec z png na jpg" :-)
>> I tutaj wchodzi make, cały na biało, razem z kilkoma innymi toolami w
>> konsoli.
> O ile sa toole.

Do tej konwersji? Na pęczki. Np. imagemagick.

>> Kończą, zanim Heniek odpali photoshopa i znajdzie w menu
>> funkcje konwersji. Ale Heniek będzie potem gadał wszystkim że on robi to
>> *prościej*, bo co łatwiejszego niż klikanie.
> Bo tez moze byc odwrotnie - Heniek juz przerobil 100 plikow, co mu
> zajelo 2 godziny, a oni ciagle czytaja dokumentacje :-)

I tu jest problem Heńka: 40 lat przeleciało za oknem i nagle trzeba się
orientować. Nic dziwnego że Heńkowie tak strasznie bronią swoich okopów
usypanych z 8051, TTLi i BC107 w których się orientują, przed śladem
złej innowacji.