On Wed, 30 Aug 2017 14:09:33 -0700 (PDT), Adam M
<a...@m...com> wrote:
> To ze standard nie jest stosowany lub co gorsza stosowany tylko
czesciowo n=
> ie jest przeslanka do stwierdzenia ze standard nie jest potrzebny.


Owszem.

Ale można wywnioskować że standardodawcy są teoretykami-marzycielami.
I mają wiarę w magiczne działanie tekstu napisanego. Co z kolei
podważa ufność co do jakości samego standardu.

do góry

> MISRA nie jest magicznym lekarstwem na wszystko - ale ustala jakies standardy -
dzieki czemu cos mozna zweryfikowac ze dziala poprawnie.

Nie, nie można.

Po pierwsze, te ciekawsze punkty w standardzie zawierają informację, że
"undecidable", czyli że standard nie daje narzędzi do stwierdzenia, czy kod jest w
ogóle zgodny z daną regułą, czy nie jest. To jest mega-dziura w sprawdzaniu
poprawności.
Np. punkt, który mówi, że nie wolno wyjeżdżać poza zakres tablicy (ogólnie, jest to
Rule 18.1), jest właśnie szczerze określony jako "undecidable". To jest zalecenie
typu "pisz dobrze, to będzie dobrze".

Po drugie, poprawność systemu ma sens tylko w kontekście jego wymagań. A tymi MISRA
się nie zajmuje - zajmuje się wyłącznie warstwą kodu źródłowego. Dlatego można mieć
kod źródłowy zgodny z MISRA-C (ale patrz wyżej, "undecidable"), który robi kompletne
bzdury, np. mnoży zamiast dodawać. Czyli zgodność z MISRA nie jest gwarantem
poprawności programu i nawet jest na to odpowiedni disclaimer.

Był też ciekawy wątek dot. niezgodności - otóż niezgodności (tzw. "dewiacje", czyli
odstępstwa od zaleceń) są częścią kultury użycia tego standardu. Każdy projekt
decyduje, jakie dewiacje chce mieć i ich dokumentacja jest częścią całego procesu.
Dlatego nie ma sensu pisać, że jakiś projekt miał 1000 niezgodności, jeśli nie
wiadomo, ile chciał mieć i dlaczego. Może właśnie dokładnie te i tyle chciał mieć - i
wtedy nie jest to problem.

> Dodakowo MISRA jest standardem dla "jezdzacego" oprogramowania

Nie, nie jest. Historia tego standardu zaczęła się w branży automotive, ale celowo
się od tego odcinają. Ten standard jest stosowany (bezpośrednio albo pośrednio -
przez referencje z innych standardów) właściwie wszędzie.

> "latajace" oprogramowanie ma wlasna specyfikacje standardu - jeszcze bardziej
wymagajaca niz MISRA.

Nie, nie ma. MISRA-C jest tylko standardem kodowania a branża latająca ma standardy
obejmujące całość procesu. Jednym z wymagań całości procesu jest to, że projekt
latający ma mieć standard kodowania. I bez problemu tym standardem może być MISRA-C
(i często jest).
Natomiast dodatkowy rygor wynika chociażby z wymagań na etapie weryfikacji
poprawności, którą MISRA się w ogóle nie zajmuje.
I nie jest to specjalne osiągnięcie branży latającej, bo w automotive też tak jest,
MISRA-C to tylko element większej układanki.

Natomiast użyteczność standardu MISRA-C (czy w ogóle jakiegokolwiek innego standardu
*kodowania*) polega na unifikacji, dzięki której łatwiej można zdefiniować i wdrożyć
inne procesy. I dlatego, pomimo tego, że MISRA sama w sobie nie gwarantuje
poprawności, to, jako element większej układanki, się do niej przykłada.

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

do góry

> I prosze nie wycigac mi tu Ady - jesli Ada byla by lekarstwem na wszystko to
systemy wbudowane by jej uzywaly

Przecież używają. Ale nie dlatego, że jest lekarstwem na wszystko (bo nie jest),
tylko dlatego, że to dobry język jest. Zwłaszcza do systemów wbudowanych.

> niestety Ada ma swoje wlasnie problemy

Jak wszystko.

A jakie problemy ma Ada?

> Nie chece mi sie nawet zaczynac dyskusji nad Ada - bo to nie ma sensu.

Sens dyskusji nad Adą nie odbiega od sensu wszystkich innych podwątków w tym wątku.
:-)

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

do góry

On Thursday, August 31, 2017 at 4:56:12 AM UTC-4, Maciej Sobczak wrote:
> > I prosze nie wycigac mi tu Ady - jesli Ada byla by lekarstwem na wszystko to
systemy wbudowane by jej uzywaly
>
> Przecież używają. Ale nie dlatego, że jest lekarstwem na wszystko (bo nie jest),
tylko dlatego, że to dobry język jest. Zwłaszcza do systemów wbudowanych.

Tak - uzywaja (Ada Ravenscar)- ale nie jest to bardzo popularny jezyk. Rozumiem ze
kolega programuje w Ada (widzialem kilka postow na comp.lang.ada) - z ciekawosci
zapytam zawodowo czy tylko jako hobby.
>
> > niestety Ada ma swoje wlasnie problemy
>
> Jak wszystko.
>
> A jakie problemy ma Ada?

Powiedzial bym ze podstawowym problemem Ady jest brak wiekszej ilosci dobrych
programistow na rynku pracy. Ada jest tez postrzegana jako bardzo wymagajacy jezyk z
powodu swojej zlozonosci (co nie do konca jest prawda - C++ tez stal sie
skomplikowany).
>
> > Nie chece mi sie nawet zaczynac dyskusji nad Ada - bo to nie ma sensu.
>
> Sens dyskusji nad Adą nie odbiega od sensu wszystkich innych podwątków w tym wątku.
:-)
>
> --
> Maciej Sobczak * http://www.inspirel.com

do góry

> > Przecież używają. Ale nie dlatego, że jest lekarstwem na wszystko (bo nie jest),
tylko dlatego, że to dobry język jest. Zwłaszcza do systemów wbudowanych.
>
> Tak - uzywaja (Ada Ravenscar)

Ravenscar to osobne zwierzę, to jest próba ujarzmienia wielowątkowości w kontekście
safety-critical. Tymczasem większość takich systemów jest jednowątkowa, więc
Ravenscar to trochę taki akademicki pomysł, chociaż dobry.
Natomiast nie jest potrzebny, żeby Adę użyć w embedded.

> ale nie jest to bardzo popularny jezyk.

To jest zdecydowanie bardziej popularny język, niż większość egzotyki, która była w
tej dyskusji wymieniona.

> Rozumiem ze kolega programuje w Ada

Również.

> z ciekawosci zapytam zawodowo czy tylko jako hobby.

Również.

> Powiedzial bym ze podstawowym problemem Ady jest brak wiekszej ilosci dobrych
programistow na rynku pracy.

To jest mit. Tzn. prawdą jest brak programistów, ale mitem jest oczekiwanie, że treba
znać Adę od pierwszego dnia pracy w projekcie. Zatrudniamy ludzi umiejących
programować *w czymkolwiek* (w szczególności w C) i mających naturalne wyczucie
poprawności i tacy ludzie prędzej się nauczą Ady, niż zrozumieją wymagania właściwego
projektu. Nie ma problemu, naprawdę - zwłaszcza, że w kontekście embedded i tak nie
używa się całego języka, tylko jakiś jego niewielki, "bezpieczny" podzbiór.
Wiem, że w innych firmach mają podobne doświadczenia.

> Ada jest tez postrzegana jako bardzo wymagajacy jezyk z powodu swojej zlozonosci

Patrz wyżej, w embedded nie używa się całego języka. MISRA-C to też jest mały
podzbiór C.

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

do góry

Użytkownik "Adam M" <a...@m...com> napisał:

> > Dodaktowo wymaganiem jest wysoka niezawodnosc oprogramowania - polecam poczytac
MISRA C i MISRA
> > C++ standard.
>
>> Taaa. Koszmarek MISRA (zwana przez nas pieszczotliwie SZMIRA) zamiast chocby Ady.
[...]
> ze sterownik silnika dostanie BSOD lub sterownik ABS postanowi przeprowadzic
odsmiecanie pamieci i
> hamulce
> zadzialaja ale z opoznieniem.

Czy MISRA C sama z siebie zapewnia/wspiera/weryfikuje realtime ? Hę :)
Prosze o odpowiedni akapit :)

> I prosze nie wycigac mi tu Ady

A wlasnie ze tak!. Po trzykroc tak!
Ada jest chyba jedynym jezykiem programowania _od poczatku przemyslanym i
zaprojektowanym
z mysla o moznosci zweryfikowania zgodnosci kodu programu z zalozeniami.
Zadna MISRA nei tylko ze tego nei gwarantruje ale jest do tego w pelni "ortogonalna".
Ot kolejny (wciaz dziurawy) standard kodowania ktory z C robi zupelnie inny (podset
C) jezyk
w ktorym sie koszmarnie pisze, a i tak Adzie nie dorasta do piet.

PS: Byc moze wlasnie niezwykle trudny/restrykcyjny proces dopuszczenia/standaryzacji
kompilerow Ady
byl
jedna z przyczyn jej stangacji, ale nei zmienia to faktu ze poroiwnanie Ady z MISRA C
jest po prostu
nieprzyzwoite:)

PS1: Trakruje MISRE C/C++ jako zwyczajny restrykcyjny coding style (no doobra, nieco
wiecej ale
tylko nieco:)
i nie zmienie zdania dokonca swych dni.

AK


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe
Avast.
https://www.avast.com/antivirus

do góry

On Thu, 31 Aug 2017 09:28:08 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:
> jekcie. Zatrudniamy ludzi umiejących programować *w czymkolwiek* =
> (w szczególności w C) i mających naturalne wyczucie poprawno=
> ści i tacy ludzie prędzej się nauczą Ady, niż zroz=
> umieją wymagania właściwego projektu.


True.

Nie musi być C.

Może być cokolwiek, nawet Lisp. Co prawda Lisp nie przypomina Ady,
ale ktoś kto zna Lisp prawdopodobnie da radę i z Adą.

do góry

On Thu, 31 Aug 2017 19:19:40 +0200, "AK" <n...@n...net> wrote:
> faktu ze poroiwnanie Ady z MISRA C jest po prostu
> nieprzyzwoite:)

True

do góry

On Thursday, August 31, 2017 at 12:28:10 PM UTC-4, Maciej Sobczak wrote:
> > > Przecież używają. Ale nie dlatego, że jest lekarstwem na wszystko (bo nie
jest), tylko dlatego, że to dobry język jest. Zwłaszcza do systemów wbudowanych.
> >
> > Tak - uzywaja (Ada Ravenscar)
>
> Ravenscar to osobne zwierzę, to jest próba ujarzmienia wielowątkowości w kontekście
safety-critical. Tymczasem większość takich systemów jest jednowątkowa, więc
Ravenscar to trochę taki akademicki pomysł, chociaż dobry.
> Natomiast nie jest potrzebny, żeby Adę użyć w embedded.
>
> > ale nie jest to bardzo popularny jezyk.
>
> To jest zdecydowanie bardziej popularny język, niż większość egzotyki, która była w
tej dyskusji wymieniona.

I tu sie z kolega w 100% zgodze - z punktu dyskutowanych tu jezykow Ada jest o wiele
bardziej popularna i na pewno na 100% solidna i bezpieczna w uzyciu.

Jest to bardzo dobry jezyk (jedyny praktycznie dla ktorego nie trzeba pisac
komentarzy w kodzie jesli uzywa sie sensownych nazw dla zmiennych i metod) ale ciagle
niepopularny. Zlozylo sie na to wiele zaszlosci historycznych a wspolczesnie Ada, C++
i recznie kodowane C sa wypychane na systemach wbudowanych przez genercje kodu z
Matlab/Simulink do C dla docelowej platformy.
>
> > Rozumiem ze kolega programuje w Ada
>
> Również.
>
> > z ciekawosci zapytam zawodowo czy tylko jako hobby.
>
> Również.
>
> > Powiedzial bym ze podstawowym problemem Ady jest brak wiekszej ilosci dobrych
programistow na rynku pracy.
>
> To jest mit. Tzn. prawdą jest brak programistów, ale mitem jest oczekiwanie, że
treba znać Adę od pierwszego dnia pracy w projekcie. Zatrudniamy ludzi umiejących
programować *w czymkolwiek* (w szczególności w C) i mających naturalne wyczucie
poprawności i tacy ludzie prędzej się nauczą Ady, niż zrozumieją wymagania właściwego
projektu. Nie ma problemu, naprawdę - zwłaszcza, że w kontekście embedded i tak nie
używa się całego języka, tylko jakiś jego niewielki, "bezpieczny" podzbiór.
> Wiem, że w innych firmach mają podobne doświadczenia.

To tez jest prawda - problemem jest ze wiekszosc firm nie ma zamiaru i nie chce
inwestowac w programistow - sa traktowani jak trybiki w maszynie - i jesli trybik ma
niewlasciwe zabki (nie zna Ady w tym przypadku) to go sie nie przyjmuje do pracy -
smutne ale prawdziwe.
>
> > Ada jest tez postrzegana jako bardzo wymagajacy jezyk z powodu swojej zlozonosci
>
> Patrz wyżej, w embedded nie używa się całego języka. MISRA-C to też jest mały
podzbiór C.
>
> --
> Maciej Sobczak * http://www.inspirel.com

do góry

On Thursday, August 31, 2017 at 1:35:33 PM UTC-4, slawek wrote:
> On Thu, 31 Aug 2017 09:28:08 -0700 (PDT), Maciej Sobczak
> <s...@g...com> wrote:
> > jekcie. Zatrudniamy ludzi umiejących programować *w czymkolwiek* =
> > (w szczególności w C) i mających naturalne wyczucie poprawno=
> > ści i tacy ludzie prędzej się nauczą Ady, niż zroz=
> > umieją wymagania właściwego projektu.
>
>
> True.
>
> Nie musi być C.
>
> Może być cokolwiek, nawet Lisp. Co prawda Lisp nie przypomina Ady,
> ale ktoś kto zna Lisp prawdopodobnie da radę i z Adą.

No tu nie byl bym taki pewny - Lisp to jezyk funcjonalny - Ada typowo imperatywny -
wiem ze duzo programistow imperatywnych przechodzi ciezki szok przesiadajac sie na
jezyk funkcjonalny - prawdopodobnie to samo dziala w druga strone tez.

do góry