> > Przemysł ma inne zdanie. Nie da się zakazać używania języka C.
>
> Po prwwsze: Przemysl nieraz dowiodl (i ciagle dowodzi), ze za madry
> nie jest...

Ale ma moc podejmowania decyzji. Mądrych bądź nie.

> Po drugie: Otoz da sie. Bardzo prosto.

Szkoda, że zapomniałeś napisać, jak.
Zauważmy tutaj, że w systemach (mniej lub bardziej) demokratycznych to właśnie
przemysł ostatecznie powołuje i finansuje te wszystkie komitety. Taki jest kierunek
przepływu kasy.
Jako ćwiczenie wyobraź sobie, że jakiś minister zabroniłby palić węglem (bo smog,
itd.). W efekcie to nie węgiel by zniknął z rynku, tylko ten minister. Tak to działa.

Dlatego węgiel oraz język C zostaną.

> Wystarczy stworzyc kompilator z zaszytymi restrykcjami Misry.
> Jezyk niech sie zwie po prostu Misra-C

Czyli potwierdziłeś właśnie, że rozwiązaniem jest zachować język C. No i tak się
dzieje.
A kompilator z restrykcjami, oczywiście - bierzemy jakibądź kompilator i dodajemy do
niego jakibądź tool do sprawdzania reguł. I mamy kompletne narzędzie. Tak się właśnie
dzieje. Nie trzeba robić nowych narzędzi, wszystko już jest gotowe, nawet jest w czym
wybierać.

> Nie da sie zakazac przybijania gwozdzi gumowm mlotkiem.
> Co wiecej przy "odrobinie" wytrwalosci i fizyce (ciekly azot -> Mi-sry)
> da sie to zrobic. Tyle tylko ze takiego "fachowca" nalezy (przynajmniej)
> tym samym mlotkiem w leb potraktowac.

Ale tak się nie robi. Pisze się wymagania, że gwóźdź ma być wbity i tyle. A firmy
konkurują wbijając gwoździe gumowymi młotkami, bo tylko tak umieją a ci co wiedzą
lepiej akurat nie prowadzą żadnej własnej firmy, żeby w tej rynkowej konkurencji w
ogóle mieć coś do powiedzenia i mogą sobie co najwyżej bezproduktywnie popyskować na
grupach dyskusyjnych. I skoro ostatecznie gwóźdź jest wbity zgodnie z wymaganiami a
klient i tak płaci, to w czym problem?

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu wtorek, 3 września 2019 20:49:52 UTC+2 użytkownik Maciej Sobczak napisał:
> > Z asercjami nie jest napisane, że ni mniej ni więcej niż 2, tylko że co
> > najmniej dwie na funkcję, czyli nie ma górnego limitu.
> > Inna sprawa, że to pełnej sensowności tej regule nie nadaje.
>
> Tak. Można stwierdzić, że w ogóle nie powinno być żadnych asercji w kodzie
programu, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.

Co za bzdura.

Równie dobrze mógłbyś powiedzieć, że w kodzie programu nie powinno być żadnych
komentarzy, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.

Albo że funkcje i zmienne mogą być nazwane byle jak, bo w systemie krytycznym one nie
pełnią tam żadnej sensownej roli.

Wygląda na to, że wśród programistów szeroko jest rozpowszechnione błędne
przekonanie, że asercja to "sprawdzenie czegoś w runtimie".

do góry

On Tuesday, September 3, 2019 at 8:26:10 PM UTC+2, AK wrote:
> On 2019-09-03 20:04, M.M. wrote:
> >> Nie da sie zakazac przybijania gwozdzi gumowm mlotkiem.
> >> Co wiecej przy "odrobinie" wytrwalosci i fizyce (ciekly azot -> Mi-sry)
> >> da sie to zrobic. Tyle tylko ze takiego "fachowca" nalezy (przynajmniej)
> >> tym samym mlotkiem w leb potraktowac.
> >
> > Dlaczego porównanie języka programowania do gumowego młotka jest
> > dobre?
>
> Dlatego ze dosłowną wrecz implementacją "paradygmatu" gumowego mlotka
> w dziedzinie okraszonej slowem "safety" jest wrecz stworzony do
> problemow j.prog. C/C++.

Zrozumiałem jak używasz porównanie jednej nieefektywnej pracy do drugiej.
Nie rozumiem zaś co ma wspólnego gumowy młotek z językami programowania.
Tak samo ja bym mógł powiedzieć, że proponowane przez Ciebie metody
tworzenia krytycznych programów są jak cokolwiek nieefektywnego, np.
jak kopanie studni głębinowej szczoteczką do zębów, i też byś nie
wiedział co ma wspólnego szczoteczka do zębów i studnia głębinowa z
proponowanymi przez Ciebie metodami.

Pozdrawiam.

do góry

> > Tak. Można stwierdzić, że w ogóle nie powinno być żadnych asercji w kodzie
programu, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.
>
> Co za bzdura.
>
> Równie dobrze mógłbyś powiedzieć, że w kodzie programu nie powinno być żadnych
komentarzy, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.

Ale nie równie dobrze, bo komentarze są pożyteczne.
Natomiast asercje to tzw. dead code. Z założenia. To jest kod źródłowy, który
pozostawia ślad w kodzie maszynowym, ale którego nie da się pokryć testami. Taki kod
jest zabroniony w procesach krytycznych. I tyle.

Powtórzę dla skupienia: MISRA-C i AUTOSAR w ogóle nie poruszają tematu asercji. Co
biorąc pod uwagę ilość innych rzeczy, które poruszają, jest co najmniej interesujące.
Otóż rozwiązanie tej zagadki jest bardzo proste: w kodzie krytycznym asercji się nie
używa. Bo one stoją w konflikcie z innymi celami, które należy osiągnąć.

> Albo że funkcje i zmienne mogą być nazwane byle jak, bo w systemie krytycznym one
nie pełnią tam żadnej sensownej roli.

Dryfujesz. Komentarze i nazwy są istotne dla czytelności. Mogą być nawet istotne dla
śladowania (ang. traceability), wiec czasami nawet nie są sprawą wolnej woli kodera.

Bo jest jeszcze taka możliwość, że potraktujesz asercje jak komentarz. To bardzo
dobry pomysł, ale komentarze piszemy w komentarzach.

> Wygląda na to, że wśród programistów szeroko jest rozpowszechnione błędne
przekonanie, że asercja to "sprawdzenie czegoś w runtimie".

Dla pewności sprawdziłem jak to opisuje standard C. Otóż właśnie dokładnie tak.

Oczywiście możesz sobie wyobrazić (albo nawet mieć) narzędzie, któro statycznie
skanuje kod i sprawdza asercje (efektywnie traktując je jako static_assert), ale
takie narzędzie potrafi też wyłuskać adnotacje z komentarzy. Więc nadal twierdzę, że
te asercje nie powinny być w kodzie.

Natomiast ja chętnie stosuję asercje w skryptach testowych. Nie chce mi się używać
wydumanych frameworków do unit testów a w testach asercje pasują idealnie.
Ale nie w kodzie.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu środa, 4 września 2019 09:31:05 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Tak. Można stwierdzić, że w ogóle nie powinno być żadnych asercji w kodzie
programu, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.
> >
> > Co za bzdura.
> >
> > Równie dobrze mógłbyś powiedzieć, że w kodzie programu nie powinno być żadnych
komentarzy, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.
>
> Ale nie równie dobrze, bo komentarze są pożyteczne.

Asercje też są pożyteczne.
Asercje są formą komentarza, który dodatkowo można zweryfikować.

> Natomiast asercje to tzw. dead code. Z założenia. To jest kod źródłowy, który
pozostawia ślad w kodzie maszynowym, ale którego nie da się pokryć testami.

Asercja to postawa propozycjonalna.
Możesz sobie napisać
#define assert(x) do {} while(0)
i nie masz śladu w kodzie maszynowym.

> Powtórzę dla skupienia: MISRA-C i AUTOSAR w ogóle nie poruszają tematu asercji. Co
biorąc pod uwagę ilość innych rzeczy, które poruszają, jest co najmniej interesujące.
> Otóż rozwiązanie tej zagadki jest bardzo proste: w kodzie krytycznym asercji się
nie używa. Bo one stoją w konflikcie z innymi celami, które należy osiągnąć.
>
> > Albo że funkcje i zmienne mogą być nazwane byle jak, bo w systemie krytycznym one
nie pełnią tam żadnej sensownej roli.
>
> Dryfujesz. Komentarze i nazwy są istotne dla czytelności.

Asercje też są istotne dla czytelności.
Po to, żeby programista wiedział:
"aha, ten a ten warunek jest (ma być) tutaj spełniony."
Co może być przydatne przy rozumieniu kodu, jego refaktoryzacji i debugowaniu.

> Bo jest jeszcze taka możliwość, że potraktujesz asercje jak komentarz. To bardzo
dobry pomysł, ale komentarze piszemy w komentarzach.

Co jest kiepskim pomysłem, bo błędnego komentarza nie wykryjesz za pomocą narzędzia,
a błędną asercję możesz.

> > Wygląda na to, że wśród programistów szeroko jest rozpowszechnione błędne
przekonanie, że asercja to "sprawdzenie czegoś w runtimie".
>
> Dla pewności sprawdziłem jak to opisuje standard C. Otóż właśnie dokładnie tak.

Asercja nie jest pojęciem wprowadzonym przez standard C.

> Oczywiście możesz sobie wyobrazić (albo nawet mieć) narzędzie, któro statycznie
skanuje kod i sprawdza asercje (efektywnie traktując je jako static_assert), ale
takie narzędzie potrafi też wyłuskać adnotacje z komentarzy.

?

> Więc nadal twierdzę, że te asercje nie powinny być w kodzie.

No to nie dość, że sam błędnie rozumiesz, to jeszcze próbujesz to swoje błędne
rozumienie promować.

> Natomiast ja chętnie stosuję asercje w skryptach testowych. Nie chce mi się używać
wydumanych frameworków do unit testów a w testach asercje pasują idealnie.
> Ale nie w kodzie.

A skrypty testowe to nie kod?

do góry

On Friday, August 30, 2019 at 9:20:11 AM UTC+2, Mateusz Viste wrote:
> On Fri, 30 Aug 2019 09:09:43 +0200, Roman Tyczka wrote:
> > https://fossbytes.com/nasa-coding-programming-rules-
critical/
>
> To raczej ciekawostka, bo do normalnego życia ma się nijak - NASA to
> jednak dewianci są. :)
>
> "Do not use goto"

To jest zalecenie wydane przez Dijkstrę w epoce fortrana łupanego.
Podstawa programowania strukturalnego i pochodnych.

> "No function longer than 60 lines of code"

Akurat dość dobre, z gatunku czytelności kodu.
Jesne, jeśli akurat wyjdzie 70 linii niepodzielnego kodu
(jakaś procedura numeryczna) to nie jest to zbrodnia.

> "Do not use dynamic memory"

"... after inicjaization". Możesz zaalokować tyle, ile trzeba.
Nie baw się jednak np w dynamicznei rosnącą tablicę.

To jest specyfika dziedziny. Dość częste zalecenie tam,
gdzie rzeczy mają być niezawodne, wiec deterministyczne.
Ale tylko do tych specjalistycznych zastosowań.

> Żadne z powyższych do mnie nie przemawia, ale oczywiście gdybym pisał
> programy sterujące rakietami ziemia-jupiter to na pewno też miałbym
> stracha.

Ogolnie, wszystkie zalecenia to albo estetyka, albo ograniczenie
dostępnych klocków, aby bylo prościej.
Dziwi mnie rekurencja wsadzona w wzięte z assembleera setjump i longjump.
O ile te ostatenie, razem z goto psują programowania strukturalne,
utrudniają analizę kodu i są zwalczane od kilkudziesiaciu lat,
to co tam robi rekurencja.
Jesne, rozumiem związane z nią "zagrożenia", na poziomie, gdzie wymagają
dowodliwego ograniczenie na liczbę obrotów pętli, można się bać nieskończonej
rekursji czy skonczenia stosu. Ale to inna kategoria niż goto;-)
Wywalenie rekurencji pośrednio mocno ogranicza dostępne struktury danych.
Drzewa pisze się znacznie gorzej. Ale znow, to do krytycznych fragmentow
kodu.


pzdr
bartekltg

do góry

On 2019-09-03 20:51, Maciej Sobczak wrote:
>>>> Dlatego, że zamiast dopracować "nowy" język programowania typu "safety"
>>>
>>> Uniwersytety robią to w tempie 3 języki na rok. Nic z tego. To tak nie działa.
>>
>> Ada nie powstala na uniwersystecie. PL/I tez nie.
>
> Chciałeś, żeby był nowy.

Taaak? Tez się starzejesz ;)
<cycat>Dlatego, że zamiast dopracować "nowy" język programowania</cycat>

AK

do góry

On 2019-09-04 08:32, M.M. wrote:
> On Tuesday, September 3, 2019 at 8:26:10 PM UTC+2, AK wrote:
>> On 2019-09-03 20:04, M.M. wrote:
>>>> Nie da sie zakazac przybijania gwozdzi gumowm mlotkiem.
>>>> Co wiecej przy "odrobinie" wytrwalosci i fizyce (ciekly azot -> Mi-sry)
>>>> da sie to zrobic. Tyle tylko ze takiego "fachowca" nalezy (przynajmniej)
>>>> tym samym mlotkiem w leb potraktowac.
>>>
>>> Dlaczego porównanie języka programowania do gumowego młotka jest
>>> dobre?
>>
>> Dlatego ze dosłowną wrecz implementacją "paradygmatu" gumowego mlotka
>> w dziedzinie okraszonej slowem "safety" jest wrecz stworzony do
>> problemow j.prog. C/C++.
>
> Zrozumiałem jak używasz porównanie jednej nieefektywnej pracy do drugiej.
> Nie rozumiem zaś co ma wspólnego gumowy młotek z językami programowania.

Bo C/C++ _jest_ typowym gumowym mlotkiem w dziedzinie 'safety' (wbijanie
gwozdzi).

> Tak samo ja bym mógł powiedzieć, że proponowane przez Ciebie metody
> tworzenia krytycznych programów są jak cokolwiek nieefektywnego, np.
> jak kopanie studni głębinowej szczoteczką do zębów, i też byś nie
> wiedział co ma wspólnego szczoteczka do zębów i studnia głębinowa z
> proponowanymi przez Ciebie metodami.

Stosowanie C/C++ w 'safety' to... kopanie studni... odbezpieczonym
granatem. Wiadomo, ze wybuchnie (reka sie zmeczy) tylko nie wiadomo
kiedy i co urwie (d..pę czy głowę...).

PS: Nic nie mam do gumowych mlotkow. Swietnie nadaja sie np. do robot
dekarskich czy samochodowej blacharki. No ale _nie do wbijania gwozdzi_.

AK

do góry

On 2019-09-03 21:33, g...@g...com wrote:
> Wygląda na to, że wśród programistów szeroko jest rozpowszechnione błędne
przekonanie,
> że asercja to "sprawdzenie czegoś w runtimie".

Alez oczywiscie, ze w C/C++ zwykla asercja jest "sprawdzana" w runtime!.
To nie zadne bledne przekonanie. To niezaprzeczalny fakt!.

PS: Tak to jest jak jakis niedouczony w C/C++ Lispowiec bez
zastanowienia/sprawdzenia strzepi jezor na temat o ktorym nie ma
zielonego pojecia (C/C++)

AK

do góry

On 2019-09-04 09:53, g...@g...com wrote:
> Asercja to postawa propozycjonalna.
> Możesz sobie napisać
> #define assert(x) do {} while(0)
> i nie masz śladu w kodzie maszynowym.

Chlopcze. Prosze, doucz sie o assercjach w C/C++.
Naprawde w C/C++ wystarczy, ze skompilujesz bez (N)DEBUG-a :(
Zapewniam Cie, ze w k.maszynowym nie bedzie sladu po kodzie asercji.

AK

do góry