On Fri, 30 Apr 2021 13:48:43 +0200, heby wrote:
> 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.

No nie wiem - to byl pewien margines, a kod zazwyczaj w assemblerze
:-)

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

ale czy obsluga GSM nie wymaga czegos lepszego?
No chyba ze - do GSM byl osobny uklad/y, a 51 robil tylko gdzies w
interfejsie.

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

Ale zweryfikowac kod o milionie linii jest zdecydowanie trudniej i
drozej :-)

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

no, 737MAX troche Boeingowi nie wyszedl.

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

Ale to jest obok testow. Jak myslisz, ze testy nalepsze i wszystko
wylapia ...
Z drugiej strony - jak sie mozna pomylic przy algorytmie, przy pisaniu
programu - tak mozna i przy weryfikacji.
A test na symulatorze ... moze wylapie blad.

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

Ale jak to wszystko w windows - najlepiej obsluguje sie myszka :-)

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

W tym przykladzie to IMO niekoniecznie - Heniek z niechecia przerobil
te 100 plikow ... ale tak bylo najprosciej.

> usypanych z 8051, TTLi i BC107 w których się orientują, przed śladem
> złej innowacji.

J.