On 29/04/2021 23:09, Marek wrote:
> On Thu, 29 Apr 2021 21:23:23 +0200, heby <h...@p...onet.pl> wrote:
>> A ja zaryzykuje nastepujące: wolałbym wsiąść w samolot z lat 90 niż w
>> cokowliek nowoczesnego, z powodu overengineering.
> Zdajesz sobie sprawę, że jeśli to nie jest tylko Twoja subiektywna ocena
> to za jakiś czas powiedzenie przypisywane Einsteinowi o kijach i
> kamieniach w 3 Wojnie Światowej jest całkiem realną wizją i to
> niekoniecznie jakiegoś konfliktu zbrojnego ale przyszłych narzędzi życia
> codziennego?

Moje subiektywne i g... warte oceny nie mają *aż* takiego wpływu na losy
świata.

do góry

On Fri, 30 Apr 2021 08:49:16 +0200, heby <h...@p...onet.pl> wrote:
> Moje subiektywne i g... warte oceny nie mają *aż* takiego wpływu na
> losy
> świata.

Ale tu nie o wpływ przecież chodzi ale na zwrócenie uwagi na pewien
jednak obiektywnie występujący trend. Trudno zaklinać rzeczywistość,
że nie występuje.

--
Marek

do góry

On Thu, 29 Apr 2021 21:23:23 +0200, heby wrote:
> On 29/04/2021 17:21, J.F wrote:
>>> Nie brodacze od 8051 którym 40 lat przeleciało za oknem. Wbrew pozorom w
>>> lotnictwie poziom pewności co czym i jak developujesz/testujesz wynika z
>>> procedur. Nie ze średniowiecznych poglądów Henia, co zatrzymał się w
>>> NortonCommanderze i Keilu. Te procedury, to często coś podlegające audytom.
>> No i kto jest pryszczatym nastolatkiem - programisci, czy audytorzy?
>> :-)
>
> Nikt, oni wszyscy mają garnitury i krawaty, więc są profesjonalni.

o garniakach nie mowie, ale ... jesli zatrudnieni od lat, to
profesjonalni.

> Natomaist wszyscy uzywają w jakimś stopniu oprogramowania pisanego przez
> pryszczatych nastolatków.
>
>> A potem mozna przeczytac taki tytul
>> https://antyweb.pl/dwa-16-bitowe-komputery-z-1996-ma
ja-naprawic-konstrukcyjne-bledy-boeinga-737-max-nie-
wiem-jak-wy-ale-ja-do-takiego-samoloty-nie-wsiade/
>
> To może być arument przeciwny archaicznym metodom dev jak i pokazujące
> co przesadna nowoczesność może popsuć.

Akurat mialem na mysli to, ze oni uzywaja starego komputera.
Moze nie 8051, ale starocia. I wymaga starych informatykow :-)

Zastapienie moze nie byc takie latwe, jesli to jakis odporniejszy
procesor, mozna gdzies wyczytac ze "formally verified", i jeszcze
sprawdzony przez 25 lat ... chcesz cos nowoczesnego wstawic?

>> Hm, moze i audytorzy sa pryszczatymi nastolatkami, skoro
>> https://www.komputerswiat.pl/aktualnosci/nauka-i-tec
hnika/boeing-737-max-z-nowymi-bledami-w-oprogramowan
iu-moze-prowadzic-do-utraty-kontroli/xsyt9km
>
> Audytorzy nie ogarniają dużego kodu, będą się skupiać na metodyce pracy
> a nie na tym że przeżytnik ma niepodpięty reset. Kod nie jest pokryty
> testami w 100%, a jeśli nawet jest w znacznej częsci pokryty, to nie
> wiadomo kto testuje te testy itd...

Albo ... Boeing wynajal zewnetrzna firme, co to niby ma doswiadczenie,
ale zatrudnia tanich nastolatkow :-)

> Może zobrazuje to w taki sposób: znaczna część dostępnych symulatorów
> korzysta z czegoś co nazywa się "systemem biblitecznym".
>
> Działa to tak że jakiś kod w HDL jest "kompilowany" i umieszczany w
> "bibliotece" i już można z niego korzystać.
>
> Po kilku iteracjach możesz zauwazyć, że nikt nie kontroluje co w
> biblitece się znajduje, w szczególnosci mogą znajdować się tam
> skompilowane kawałki z plików źrodłowych które już nie istnieją lub
> zmieniły zawartość, napisane kawałki o tych samych nazwach, framgmenty
> od inncyh userów których możemy nie chcieć.
>
> Dlaczego tak jest? Pewnie dlatego, że kilku brodatych Heńków lat temu 30
> nie zuważyło, że istnieje make.

Brodate Henki mogly sie akurat na make wychowac.
Pozniejsze pokolenie nie zna ..

>> Bo tam w srodku jest procesor z 1996 :-)
>
> A ja zaryzykuje nastepujące: wolałbym wsiąść w samolot z lat 90 niż w
> cokowliek nowoczesnego, z powodu overengineering. Dotyczy to
> wszystkiego, od elektroniki do machaniki. Ale najbardzoej elektroniki co
> do której proces devu znam i czasami trzęsą mi się kolana na myśl ilu
> Heńków majstrowało przy samolocie w którym siedzę i jak skrajnie
> popsutych narzędzi, ale certyfikowanych, używali, jak wygląda proces dev
> przeciętnej firmy w EDA i dlaczego uże układy, które sterują tym
> samolotem, weryfikuje się randomizacją a nie formalnie...

I tu sie zgadzamy.

J.

do góry

On Fri, 30 Apr 2021 10:08:23 +0200, "J.F"
<j...@p...onet.pl> wrote:
> Brodate Henki mogly sie akurat na make wychowac.
> Pozniejsze pokolenie nie zna ..

Paradygmat Szumowskiego się kłania....

--
Marek

do góry

On 30/04/2021 10:08, J.F wrote:
> Zastapienie moze nie byc takie latwe, jesli to jakis odporniejszy
> procesor, mozna gdzies wyczytac ze "formally verified", i jeszcze
> sprawdzony przez 25 lat ... chcesz cos nowoczesnego wstawic?

Mamy całkiem sensowne procesory współczesne do cieżkich zadań, których
programowanie jest "normalne" i nie ma problemu ze znalezieniem
programistów.

Do 8051 cieżko znaleźc programistę który ogarnie go i jednoczesnie ma
pojęcie o jakości, procedurach, współczesnych technikach pisania z
naciskiem na jakość. To są biegunowo odległe grupy.

Ale do LEONa nie powinno być kłopotu. Niczym się to nie różni od innych
CPU na których obecnie jedziemy w normalnym programowaniu. Za chwile
wszędzie będzie wciskany RISC-V, któy też jest zupełnie normalny. Nawet
w FPGA go będą wciskać.

>> Audytorzy nie ogarniają dużego kodu, będą się skupiać na metodyce pracy
>> a nie na tym że przeżytnik ma niepodpięty reset. Kod nie jest pokryty
>> testami w 100%, a jeśli nawet jest w znacznej częsci pokryty, to nie
>> wiadomo kto testuje te testy itd...
> Albo ... Boeing wynajal zewnetrzna firme, co to niby ma doswiadczenie,
> ale zatrudnia tanich nastolatkow :-)

Na końcu zawsze są hindusi.

Taka uwaga: nie abym tak uważał, ale mam wrażenie że na stare lata będę
tak uważał: to nie programiści decydują o jakości, tylko procedury i
testowanie. Z tego wynika pewna higiena pisania kodu, oczywiscie, ale to
czy zatrudnisz studenta czy profesjonalistę powinno wpływać na czas i
koszta, ale na jakość, raczej nie. Utopijnie: jakość software powinna
być determinowana przez kontrolę jakości a czas pisania przez poziom
programisty.

> Brodate Henki mogly sie akurat na make wychowac.

Brodate Zygumnty, programiści, tak.

Hanryki od rysowania bramek, nie. Oni dalej je rysują, tylko w kodzie.
Niewiele się zmieniło. Mają bardzo podobne narzędzia, tylko robiąto
odrobinę inaczej (i nadal jest pełno Heńków którzy rysują sieci bramek z
translacją do kodu)

Warto wspomnieć że SystemVerilog wprowadził jakiś czas temu
programowanie obiektowe. I nie w celu syntezy, tylko testowania. Była
niewyobrażalna gównoburza że ktoś Heńkom bezczelnie kazał nagle nauczyć
się czegoś nowego. W efekcie powstało pełno narzędzi które chowają to
obiektowe coś pod interfejsem graficznym gdzie można sobie wyklikać to i
owo. I oczywiscie można sobie źle wyklikac, trudno klikac jak się nie ma
pojęcia, w co sie klika. Efekt: no i co z tego że powstało zaawansowane
narzędzie, skoro sprowadzono je do gryzaka dla niemowlaka.

> Pozniejsze pokolenie nie zna ..

Odwrotnie, współczesne pokolenie zna doskonale. Nawet jeśli nie make, to
koncepcje za nim stojące. Korzysta z tego bardzo dużo języków. Tylko że
to mowa o programistach. W EDA też jest programowanie, ale robione przez
elektroników. I tutaj jest podstawowy problem. Elektronicy od rysowania
bramek nagle muszą ogarniać problemy typowego programisty. I ogarniają
na swój sposób.

do góry

On 30-Apr-21 10:43, heby wrote:
> Mamy całkiem sensowne procesory współczesne do cieżkich zadań, których
> programowanie jest "normalne" i nie ma problemu ze znalezieniem
> programistów.

Ale rozumiesz, że może też chodzić o formalne dowodzenie poprawności
algorytmów.

I przeniesienie kilku milionów linii kodu z 2 czy tam 9 słabszych ale
zestandaryzowanych komputerów na jeden super-duper ale bliżej nikomu nie
znany może oznaczać grube miesiące jeśli nie lata i dziesiątki albo
setki milionów w brzęczącej monecie, które trzeba poświęcić na retesty,
certyfikacje, etc.

I z całym szacunkiem, ale programiści Ci tego nie zrobią bo się po
prostu na tym nie znają.

A już czuć gorący oddech konkurencji na karku ;-)

Piotrek

do góry

On Fri, 30 Apr 2021 10:43:57 +0200, heby wrote:
> On 30/04/2021 10:08, J.F wrote:
>> Zastapienie moze nie byc takie latwe, jesli to jakis odporniejszy
>> procesor, mozna gdzies wyczytac ze "formally verified", i jeszcze
>> sprawdzony przez 25 lat ... chcesz cos nowoczesnego wstawic?
>
> Mamy całkiem sensowne procesory współczesne do cieżkich zadań, których

Ale czy sa odporne na szeroki zakres temperatur, na promieniowanie
kosmiczne itp?

I czy mozna w jakis sposob zbadac, czy nie maja bledow ?

> programowanie jest "normalne" i nie ma problemu ze znalezieniem
> programistów.

Ale tu pewnie tez jest normalne - w C. Ewentualnie w Ada.
Plus system operacyjny i biblioteki, a te i tak specyficzne.

> Do 8051 cieżko znaleźc programistę który ogarnie go i jednoczesnie ma
> pojęcie o jakości, procedurach, współczesnych technikach pisania z
> naciskiem na jakość. To są biegunowo odległe grupy.

8051 ma 8KB pamieci programu, no - 64 czasem, to jeden programista
ogarnia :-)

>>> Audytorzy nie ogarniają dużego kodu, będą się skupiać na metodyce pracy
>>> a nie na tym że przeżytnik ma niepodpięty reset. Kod nie jest pokryty
>>> testami w 100%, a jeśli nawet jest w znacznej częsci pokryty, to nie
>>> wiadomo kto testuje te testy itd...
>> Albo ... Boeing wynajal zewnetrzna firme, co to niby ma doswiadczenie,
>> ale zatrudnia tanich nastolatkow :-)
>
> Na końcu zawsze są hindusi.
>
> Taka uwaga: nie abym tak uważał, ale mam wrażenie że na stare lata będę
> tak uważał: to nie programiści decydują o jakości, tylko procedury i
> testowanie.

IMO - programisci tez.
Ale czy zatrudniasz programistow w roznym wieku, czy starsi jakos tam
dbaja o "ład korporacyjny" w pisaniu programow, uczą mlodszych jak to
sie robi, czy zatrudniasz z doskoku i to najtanszych ...

>> Brodate Henki mogly sie akurat na make wychowac.
>
> Brodate Zygumnty, programiści, tak.
>
> Hanryki od rysowania bramek, nie. Oni dalej je rysują, tylko w kodzie.
> Niewiele się zmieniło. Mają bardzo podobne narzędzia, tylko robiąto
> odrobinę inaczej (i nadal jest pełno Heńków którzy rysują sieci bramek z
> translacją do kodu)

Aczkolwiek ... w PLD byl problem, ze przerzutnik latch na bramkach
wychodzi a na rownaniach nie bardo ...
Verilog/VHDL ... mam nadzieje, ze nie ma juz tego problemu.

>> Pozniejsze pokolenie nie zna ..
>
> Odwrotnie, współczesne pokolenie zna doskonale. Nawet jeśli nie make, to
> koncepcje za nim stojące. Korzysta z tego bardzo dużo języków. Tylko że
> to mowa o programistach. W EDA też jest programowanie, ale robione przez
> elektroników. I tutaj jest podstawowy problem. Elektronicy od rysowania
> bramek nagle muszą ogarniać problemy typowego programisty. I ogarniają
> na swój sposób.

Hm. Make owszem, sie przydaje, ale wymaga narzedzi "command line".
A tu piekne programy zwykly to robic z menu.

Aczkolwiek niedawno widzialem ladne oprogramowanie, mozna sobie
narysowac maszyne w CAD, podlaczyc wirtualne PLC, zaprogramowac to
PLC, i zobaczyc jak bedzie dzialalo.
Tylko cos mi sie widzi, ze make tam nie ma :-)

J.

do góry

On 30/04/2021 11:01, Piotrek wrote:
>> Mamy całkiem sensowne procesory współczesne do cieżkich zadań, których
>> programowanie jest "normalne" i nie ma problemu ze znalezieniem
>> programistów.
> Ale rozumiesz, że może też chodzić o formalne dowodzenie poprawności
> algorytmów.

I dlaczego LEON czy RISC-V miały być do tego gorszy niż Heńkowy 8051?

> I przeniesienie kilku milionów linii kodu z 2 czy tam 9 słabszych ale
> zestandaryzowanych komputerów na jeden super-duper ale bliżej nikomu nie
> znany może oznaczać grube miesiące jeśli nie lata i dziesiątki albo
> setki milionów w brzęczącej monecie, które trzeba poświęcić na retesty,
> certyfikacje, etc.

Nie przesadzajmy. Tych milionów lini kodu *NIKT* nie zweryfikował
formalnie. Tam jest weryfikacja przez zasiedzenie. Jesteśmy w czarnej
d... jeśli chodzi o weryfikację dużych systemów, niby rozwijamy się,
tworzymy nowe metodyki, ale powiedz to Heńkowi, co gita na oczy nie widział.

> I z całym szacunkiem, ale programiści Ci tego nie zrobią bo się po
> prostu na tym nie znają.

Zależy jacy programiści. Po tych w lotnictwie, spodziewam się że
potrafią formalnie dowodzić przynajmniej kilkuset linijkowców dbających
o bezpieczeństwo. Których pewnie nie ma, za to są wciśnięte właśnie
kilkumilionowe potworki do sterowania autopilotem i sterowaniem klimą w
jednym.

do góry

On 30/04/2021 11:06, J.F wrote:
>> Mamy całkiem sensowne procesory współczesne do cieżkich zadań, których
> Ale czy sa odporne na szeroki zakres temperatur, na promieniowanie
> kosmiczne itp?

Tak.

> I czy mozna w jakis sposob zbadac, czy nie maja bledow ?

Tak.

>> programowanie jest "normalne" i nie ma problemu ze znalezieniem
>> programistów.
> Ale tu pewnie tez jest normalne - w C. Ewentualnie w Ada.
> Plus system operacyjny i biblioteki, a te i tak specyficzne.

Na 8051 nie ma "C". jest jakaś proteza ogarniająca dziwaczne tryby
adresowania i udajaca że z C ma coś wspólnego podobną składnią. Skrajnie
utrudnia to testowanie kodu i praktycznie przekreśla przenośność.

>> Do 8051 cieżko znaleźc programistę który ogarnie go i jednoczesnie ma
>> pojęcie o jakości, procedurach, współczesnych technikach pisania z
>> naciskiem na jakość. To są biegunowo odległe grupy.
> 8051 ma 8KB pamieci programu, no - 64 czasem, to jeden programista
> ogarnia :-)

Jak by taka zależności RAM<->ogarnianie była prawdziwa...

>> Taka uwaga: nie abym tak uważał, ale mam wrażenie że na stare lata będę
>> tak uważał: to nie programiści decydują o jakości, tylko procedury i
>> testowanie.
> IMO - programisci tez.
> Ale czy zatrudniasz programistow w roznym wieku, czy starsi jakos tam
> dbaja o "ład korporacyjny" w pisaniu programow, uczą mlodszych jak to
> sie robi, czy zatrudniasz z doskoku i to najtanszych ...

Na końcu jest kontrola jakości. Jesli jest zrobiona na odpiernicz się
albo wcale, to programiści mają wypływ na jakość.

>> Odwrotnie, współczesne pokolenie zna doskonale. Nawet jeśli nie make, to
>> koncepcje za nim stojące. Korzysta z tego bardzo dużo języków. Tylko że
>> to mowa o programistach. W EDA też jest programowanie, ale robione przez
>> elektroników. I tutaj jest podstawowy problem. Elektronicy od rysowania
>> bramek nagle muszą ogarniać problemy typowego programisty. I ogarniają
>> na swój sposób.
> Hm. Make owszem, sie przydaje, ale wymaga narzedzi "command line".

Ciekawostka: przykładowo syntezer Xilinxa nie obsługuje command line.
Trzeba mu dostarczyć plik który interpretuje. Na dzień dobry wybija to
zęby pisząc makefile.

> A tu piekne programy zwykly to robic z menu.

I można syntezować "z menu" ale ma się to nijak to koncepcji "single
click build" która jest uznawana za jeden z poważnych punktów kontroli
tworzenia oprogramowania. Eleiminacji błedów białkowych.

> Aczkolwiek niedawno widzialem ladne oprogramowanie, mozna sobie
> narysowac maszyne w CAD, podlaczyc wirtualne PLC, zaprogramowac to
> PLC, i zobaczyc jak bedzie dzialalo.
> Tylko cos mi sie widzi, ze make tam nie ma :-)

Bo make nie służy do robienia prototypów. Przypuszczalnie Photoshp też
nie ma wsparcia dla make.

do góry

On Fri, 30 Apr 2021 11:24:05 +0200, heby wrote:
> On 30/04/2021 11:06, J.F wrote:
>>> Mamy całkiem sensowne procesory współczesne do cieżkich zadań, których
>> Ale czy sa odporne na szeroki zakres temperatur, na promieniowanie
>> kosmiczne itp?
> Tak.
>
>> I czy mozna w jakis sposob zbadac, czy nie maja bledow ?
> Tak.

Hm ...

>>> programowanie jest "normalne" i nie ma problemu ze znalezieniem
>>> programistów.
>> Ale tu pewnie tez jest normalne - w C. Ewentualnie w Ada.
>> Plus system operacyjny i biblioteki, a te i tak specyficzne.
>
> Na 8051 nie ma "C". jest jakaś proteza ogarniająca dziwaczne tryby
> adresowania i udajaca że z C ma coś wspólnego podobną składnią. Skrajnie
> utrudnia to testowanie kodu i praktycznie przekreśla przenośność.

OK, ale w Boeingu jest jakis lepszy procesor, to moze i C jest
normalne.

A moze tez harwardzki, i kod z 51 sie przydaje :-)

>>> Do 8051 cieżko znaleźc programistę który ogarnie go i jednoczesnie ma
>>> pojęcie o jakości, procedurach, współczesnych technikach pisania z
>>> naciskiem na jakość. To są biegunowo odległe grupy.
>> 8051 ma 8KB pamieci programu, no - 64 czasem, to jeden programista
>> ogarnia :-)
>
> Jak by taka zależności RAM<->ogarnianie była prawdziwa...

Latwiej zapanowac nad malym programem.

>>> Taka uwaga: nie abym tak uważał, ale mam wrażenie że na stare lata będę
>>> tak uważał: to nie programiści decydują o jakości, tylko procedury i
>>> testowanie.
>> IMO - programisci tez.
>> Ale czy zatrudniasz programistow w roznym wieku, czy starsi jakos tam
>> dbaja o "ład korporacyjny" w pisaniu programow, uczą mlodszych jak to
>> sie robi, czy zatrudniasz z doskoku i to najtanszych ...
>
> Na końcu jest kontrola jakości. Jesli jest zrobiona na odpiernicz się
> albo wcale, to programiści mają wypływ na jakość.

Owszem, ale potem przychodzi deadline, kontrola mowi "tego nie mozemy
wypuscic" a szef mowi "musimy" :-)

Poza tym jak programista sie skupi na kontroli, to moze tak napisac
program, ze testy przejdzie ...


>>> Odwrotnie, współczesne pokolenie zna doskonale. Nawet jeśli nie make, to
>>> koncepcje za nim stojące. Korzysta z tego bardzo dużo języków. Tylko że
>>> to mowa o programistach. W EDA też jest programowanie, ale robione przez
>>> elektroników. I tutaj jest podstawowy problem. Elektronicy od rysowania
>>> bramek nagle muszą ogarniać problemy typowego programisty. I ogarniają
>>> na swój sposób.
>> Hm. Make owszem, sie przydaje, ale wymaga narzedzi "command line".
>
> Ciekawostka: przykładowo syntezer Xilinxa nie obsługuje command line.
> Trzeba mu dostarczyć plik który interpretuje. Na dzień dobry wybija to
> zęby pisząc makefile.

IMO - i tak jest niezle, ze przewiduje taki plik,

>> Aczkolwiek niedawno widzialem ladne oprogramowanie, mozna sobie
>> narysowac maszyne w CAD, podlaczyc wirtualne PLC, zaprogramowac to
>> PLC, i zobaczyc jak bedzie dzialalo.
>> Tylko cos mi sie widzi, ze make tam nie ma :-)
>
> Bo make nie służy do robienia prototypów. Przypuszczalnie Photoshp też
> nie ma wsparcia dla make.

A potem masz zadanie "redakcja nie chce png tylko jpg. Jak przerobic
setke zdjec z png na jpg" :-)

J.

do góry