Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #32905 > unrolled thread
| Started by | Roman Tyczka <noemail@because.no> |
|---|---|
| First post | 2019-08-30 09:09 +0200 |
| Last post | 2019-09-04 18:00 +0200 |
| Articles | 17 on this page of 97 — 11 participants |
Back to article view | Back to pl.comp.programming
Jak to robią w NASA Roman Tyczka <noemail@because.no> - 2019-08-30 09:09 +0200
Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-08-30 07:20 +0000
Re: Jak to robią w NASA Roman Tyczka <noemail@because.no> - 2019-08-30 12:27 +0200
Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-08-30 11:09 +0000
Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 18:42 +0200
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-01 10:01 +0200
Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 18:52 +0200
Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 19:43 +0200
Re: Jak to robią w NASA bartekltg <bartekltg@gmail.com> - 2019-09-04 07:39 -0700
Re: Jak to robią w NASA queequeg@trust.no1 (Queequeg) - 2019-08-30 08:06 +0000
Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-08-30 12:49 +0000
Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 19:17 +0200
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-08-31 13:14 -0700
Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 22:44 +0200
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-08-31 13:54 -0700
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-08-31 14:15 -0700
Re: Jak to robią w NASA queequeg@trust.no1 (Queequeg) - 2019-09-01 17:21 +0000
Re: Jak to robią w NASA queequeg@trust.no1 (Queequeg) - 2019-09-01 17:17 +0000
Re: Jak to robią w NASA Adam Klobukowski <adamklobukowski@gmail.com> - 2019-08-30 10:20 -0700
Re: Jak to robią w NASA queequeg@trust.no1 (Queequeg) - 2019-09-01 17:23 +0000
Re: Jak to robią w NASA Wojciech Muła <wojtek.mula@gmail.com> - 2019-08-30 10:21 -0700
Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 19:21 +0200
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-01 10:05 +0200
Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-09-04 17:38 +0200
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 19:10 +0200
Re:Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 20:03 +0200
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-01 13:55 -0700
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-02 08:30 +0200
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-02 05:16 -0700
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-02 21:33 +0200
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-03 00:42 -0700
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-03 18:34 +0200
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-03 01:58 -0700
Re: Jak to robią w NASA Roman Tyczka <noemail@because.no> - 2019-09-03 16:28 +0200
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-03 11:49 -0700
Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-03 12:33 -0700
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-04 00:31 -0700
Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-04 00:53 -0700
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 19:04 +0200
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 19:07 +0200
Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-04 10:54 -0700
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 21:07 +0200
Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-04 14:05 -0700
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-05 04:37 -0700
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-06 07:31 +0200
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-06 01:12 -0700
Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-09-06 08:33 +0000
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-06 03:06 -0700
Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-09-06 10:57 +0000
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-06 06:42 -0700
Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-09-06 14:06 +0000
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-06 12:03 -0700
Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-09-06 19:12 +0000
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-07 01:55 -0700
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-07 08:04 -0700
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-07 10:35 -0700
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-06 17:06 +0200
Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-06 16:48 -0700
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-08 08:13 +0200
Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-07 23:58 -0700
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-08 11:19 +0200
Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-08 03:13 -0700
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-09 17:56 +0200
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-08 02:36 -0700
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-06 17:11 +0200
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-06 09:22 -0700
Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-06 10:14 -0700
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-06 11:28 -0700
Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-06 14:59 -0700
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-04 14:49 -0700
Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-06 09:29 -0700
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-06 12:25 -0700
Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-06 14:00 -0700
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-07 08:21 -0700
Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-07 15:18 -0700
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-08 08:32 -0700
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-08 13:17 -0700
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-10 22:30 -0700
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-11 00:21 -0700
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-11 11:32 -0700
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-12 00:21 -0700
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-12 03:05 -0700
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-12 23:14 -0700
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-11 20:09 +0200
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 19:00 +0200
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-03 18:35 +0200
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-03 11:51 -0700
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 18:43 +0200
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-03 18:43 +0200
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-03 11:04 -0700
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-03 20:26 +0200
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-03 23:32 -0700
Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 18:52 +0200
Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-05 00:20 -0700
Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-03 12:05 -0700
Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-09-04 18:11 +0200
Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-09-04 18:00 +0200
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2019-09-12 00:21 -0700 |
| Message-ID | <bdc3f3c2-7fd5-4cf2-b842-22bb04a48272@googlegroups.com> |
| In reply to | #33031 |
> A konkretnie, co jest na temat a co nie jest i na jaki? Pół dyskusji w tym wątku było nie na temat tego wątku. > Nie wiem co to > jest "verification condition". To jest coś, co zakładamy[1], że jest prawdą albo co musi być wykazane[2], że jest prawdą, żeby program uznać za poprawny. [1] Przykładem takiego założenia jest np. zakres wartości typu int. Tego się nie udowadnia, to się przyjmuje i dane z tego założenia są WEjściem dla innych rozważań. [2] Przykładem takiego warunku jest np. to, co było pokazane dla funkcji max, albo to, że funkcja sortująca faktycznie sortuje albo to, że funkcja abs nigdy nie zwróci wartości ujemnej, itd. Takich rzeczy nie wiemy z góry, ale możemy je wykazać (albo im zaprzeczyć) wnioskując na podstawie informacji, które już znamy. Fachowo, dowiedzenie, że VC (verification condition) jest spełnione nazywa się "discharge". Ale po polsku najlepiej powiedzieć, że jest "spełnione", bo "rozładowywanie warunków" brzmi głupio. Dowody mogą być automatyczne albo ręczne. I teraz ciekawostka: asercja napisana przy użyciu makra "assert" może być traktowana jako warunek do wykazania *oraz* jako nowe założenie dla dalszych rozważań. W niektórych językach do tego drugiego celu służy konstrukcja "assume" i stosuje się ją wtedy, kiedy wiedza na jakiś temat pochodzi z zewnątrz - np. z tego, jak i gdzie dany program jest użytkowany. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2019-09-12 03:05 -0700 |
| Message-ID | <22902c8a-9482-453a-970c-c1cd5dbacf47@googlegroups.com> |
| In reply to | #33035 |
On Thursday, September 12, 2019 at 9:21:42 AM UTC+2, Maciej Sobczak wrote: > > A konkretnie, co jest na temat a co nie jest i na jaki? > > Pół dyskusji w tym wątku było nie na temat tego wątku. > > > Nie wiem co to > > jest "verification condition". > > To jest coś, co zakładamy[1], że jest prawdą albo co musi być wykazane[2], > że jest prawdą, żeby program uznać za poprawny. Na razie rozumiem, że "verification condition" to jest cokolwiek z czego prawdziwości wynika poprawność programu, albo czego prawdziwości jest tożsama z poprawnością programu. Coś w rodzaju X => Y X <=> Y Gdzie X to jest poprawny verification condition, a Y oznacza poprawność programu. Zwykle stosuję słabsze wnioskowanie, np. że z NIE prawdziwości warunków testowych wynika że program jest nie poprawny. > [1] Przykładem takiego założenia jest np. zakres wartości typu int. Tego się > nie udowadnia, to się przyjmuje i dane z tego założenia są WEjściem dla > innych rozważań. Tak, to chyba wynika z prawdziwości zdania "kompilator nie ma błędów". > [2] Przykładem takiego warunku jest np. to, co było pokazane dla funkcji max, Tak, tamto zrozumiałem, choć do składni w adnotacjach bym musiał przywyknąć. > albo to, że funkcja sortująca faktycznie sortuje albo to, że > funkcja abs nigdy nie zwróci wartości ujemnej, itd. Abs i sortowanie stanowią stosunkowo łatwe przykłady. Zwykle nie wiem jak mam zrobić warunki, gdy mam okienko dialogowe np. z 20ma polami i piszę parser czy użytkownik nie wpisał blędnych wartości? Czy parser przepuści jakiś przypadek błędnych danych wejściowych dla programu? Niby sam parser jest takim warunkiem, działa na zasadzie: dane złe, to warunek je wychwyci. > Takich rzeczy nie wiemy z góry, ale możemy je wykazać (albo im > zaprzeczyć) wnioskując na podstawie informacji, które już znamy. > > Fachowo, dowiedzenie, że VC (verification condition) jest spełnione nazywa się "discharge". Ale po polsku najlepiej powiedzieć, że jest "spełnione", bo "rozładowywanie warunków" brzmi głupio. Dowody mogą być automatyczne albo ręczne. > > I teraz ciekawostka: asercja napisana przy użyciu makra "assert" może być > traktowana jako warunek do wykazania *oraz* jako nowe założenie dla > dalszych rozważań. O jakie założenie i o jakie rozważania chodzi? > W niektórych językach do tego drugiego celu służy konstrukcja "assume" i stosuje się ją wtedy, kiedy wiedza na jakiś temat pochodzi z zewnątrz - np. z tego, jak i gdzie dany program jest użytkowany. Nie używałem assume. Widzę że w C/C++ microsofcie coś dodali: https://docs.microsoft.com/en-us/cpp/intrinsics/assume?view=vs-2019 A w GCC zalecają sztuczki: https://stackoverflow.com/questions/25667901/assume-clause-in-gcc https://stackoverflow.com/questions/6031819/emulating-gccs-builtin-unreachable Nie rozumiem, jakie są korzyści z dodania pustej funkcji, albo z operacji bitowej AND z samymi jedynkami: x = x & (~0); Chociaż bezpieczniej byłoby OR z zerami: x = x | 0; Pozdrawiam > > -- > Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2019-09-12 23:14 -0700 |
| Message-ID | <49a1ada8-ef53-4145-8f0b-1078f925606d@googlegroups.com> |
| In reply to | #33036 |
> Zwykle stosuję słabsze wnioskowanie, np. że z NIE prawdziwości warunków
> testowych wynika że program jest nie poprawny.
Więc uściślijmy: chodzi o poprawność względem tych warunków, które zostały określone. Czyli jeśli ktoś nie napisał jakiegoś ważnego warunku weryfikacji, to nie może mieć pretensji, że program jest niepoprawny chociaż wszystkie warunki (te niekompletne) są spełnione i narzędzie mu powiedziało, że jest 0 errors, 0 warnings.
Ale też nikt nie twierdzi, że całe zjawisko poprawności należy tak pokryć. Na weryfikację składają się analizy, przeglądy i testy. Warunki poprawności należą do analiz i jeśli nie są kompletne, to uzupełniamy w pozostałych dwóch. Oczywiście, fani metod formalnych dążą do tego, żeby analiza miała jak największy zakres, bo wtedy można oszczędzić gdzie indziej (na testach).
> Tak, to chyba wynika z prawdziwości zdania "kompilator nie ma błędów".
Tak, to ciekawa uwaga. Jeżeli zakładamy, że kompilator może mieć błędy, to analizy kodu źródłowego nie wystarczają, i tak trzeba mieć komplet testów (i to jest argument przeciwko analizom).
> do składni w adnotacjach bym musiał przywyknąć.
Jak do każdej innej. Faktem jest, że ASCII nie bardzo ma coś do zaoferowania gdy w grę wchodzą bardziej skomplikowane zapisy i się robi sieczka. Dlatego osobiście widzę tu miejsce na integrację z narzędziami takimi jak Mathematica.
> Abs i sortowanie stanowią stosunkowo łatwe przykłady.
Sortowanie to jeden z najtrudniejszych przykładów w ogóle. Nie wystarczy pokazać, że elementy są w dobrej kolejności, trzeba jeszcze pokazać, że to są właściwe elementy (że żaden nie zginął albo nie pojawił z czapy).
> Zwykle nie wiem
> jak mam zrobić warunki, gdy mam okienko dialogowe np. z 20ma polami i
> piszę parser czy użytkownik nie wpisał blędnych wartości? Czy parser
> przepuści jakiś przypadek błędnych danych wejściowych dla programu?
> Niby sam parser jest takim warunkiem, działa na zasadzie: dane złe, to
> warunek je wychwyci.
Dobry przykład. Wtedy można zmienić myślenie z "wychwyć złe wartości" na "akceptuj dobre wartości", czasem to ułatwia projektowanie.
> > I teraz ciekawostka: asercja napisana przy użyciu makra "assert" może być
> > traktowana jako warunek do wykazania *oraz* jako nowe założenie dla
> > dalszych rozważań.
>
> O jakie założenie i o jakie rozważania chodzi?
void foo()
{
// część 1
// ...
assert(x > 0); // VC_1
// część 2
// ...
assert(x > 0); // VC_2
}
Pierwszy warunek sprawdza, czy część 1 jest poprawna a drugi warunek sprawdza część 2. Ten drugi warunek polega na wiedzy (założeniu) z warunku pierwszego, czyli zakładamy, że na początku części 2 jest x > 0, bo mamy taką "gwarancję". I jeśli z części 2 wynika, że *przy takim założeniu nadal* jest x > 0, to wtedy cieszymy się, że część 2 jest poprawna.
I teraz może się okazać, że nie umiemy wykazać VC_1, bo jest to zbyt trudne (powiedzmy, że wtedy pokrywamy to testami). Ale jeśli VC_2 jest spełnione, to nadal wiemy, że część 2 jest poprawna.
To jest forma długu technicznego, bo jeśli się okaże (np. w testach), że jednak część 1 jest niepoprawna, to nasza analiza części 2 jest nic nie warta, bo opierała się na błędnych założeniach. Ale taki dług można podjąć i tak się robi.
Oczywiście mówimy o analizach statycznych, nie o run-time'owym assercie.
> Nie używałem assume.
Bo w run-time to nie ma sensu, więc tego normalnie w C/C++ nie ma.
Ale zobacz tutaj:
https://docs.adacore.com/spark2014-docs/html/ug/en/source/assertion_pragmas.html#pragma-assume
Assume piszemy wtedy, gdy wiemy coś, czego w kodzie nie widać.
--
Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-09-11 20:09 +0200 |
| Message-ID | <qlbd9g$1e41$1@gioia.aioe.org> |
| In reply to | #33013 |
On 2019-09-08 22:17, Maciej Sobczak wrote: > (nazwijmy je raczej warunkami weryfikacji) Trafna nazwa! AK
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-09-04 19:00 +0200 |
| Message-ID | <qkoqil$1dae$1@gioia.aioe.org> |
| In reply to | #32960 |
On 2019-09-03 21:33, godek.maciek@gmail.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
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-09-03 18:35 +0200 |
| Message-ID | <qkm4on$1ila$2@gioia.aioe.org> |
| In reply to | #32947 |
On 2019-09-03 10:58, 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. AK
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2019-09-03 11:51 -0700 |
| Message-ID | <6d568363-b4ea-4063-af6b-3fafa4208489@googlegroups.com> |
| In reply to | #32950 |
> >> 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. -- Maciej Sobczak
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-09-04 18:43 +0200 |
| Message-ID | <qkopis$17kh$1@gioia.aioe.org> |
| In reply to | #32958 |
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
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-09-03 18:43 +0200 |
| Message-ID | <qkm587$1ls3$1@gioia.aioe.org> |
| In reply to | #32947 |
On 2019-09-03 10:58, Maciej Sobczak wrote:
>> PS: Oczywiscie wiem ze Misra(y) to nie tylko j.prog czy AUTOSARowe normy
>> np. do bilbliotek/APIs, ale czesc tyczaca C/C++ zwyczajnie przyprawia
>> o wymioty... :(
>
> 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... ("wiedza" managementu brana z prezentacji i video-konferencji).
Po drugie: Otoz da sie. Bardzo prosto.
Poza tym (jak pisalem) nie jest to niezbedne.
Wystarczy stworzyc kompilator z zaszytymi restrykcjami Misry.
Jezyk niech sie zwie po prostu Misra-C
> I nawet chyba nie należy. Lepiej dać ludziom wytyczne, jakie cele jakościowe mają osiągnąć i niech sobie sami wybiorą, czym je będą osiągać. To jest pole dla konkurencji - tzn. jeśli potrafisz te cele osiągnąć taniej, niż konkurencja używająca języka C, to Twój zysk.
> Tylko jakoś nikt się nie wychyla i dalej wszyscy "konkurują" robiąc wszystko tak samo, jak reszta.
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.
AK
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2019-09-03 11:04 -0700 |
| Message-ID | <7f6fca23-6b1d-4504-b5e9-1bdd3a92d9c7@googlegroups.com> |
| In reply to | #32951 |
On Tuesday, September 3, 2019 at 6:43:54 PM UTC+2, AK wrote:
> On 2019-09-03 10:58, Maciej Sobczak wrote:
> >> PS: Oczywiscie wiem ze Misra(y) to nie tylko j.prog czy AUTOSARowe normy
> >> np. do bilbliotek/APIs, ale czesc tyczaca C/C++ zwyczajnie przyprawia
> >> o wymioty... :(
> >
> > 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... ("wiedza" managementu brana z prezentacji i video-konferencji).
> Po drugie: Otoz da sie. Bardzo prosto.
> Poza tym (jak pisalem) nie jest to niezbedne.
> Wystarczy stworzyc kompilator z zaszytymi restrykcjami Misry.
> Jezyk niech sie zwie po prostu Misra-C
>
> > I nawet chyba nie należy. Lepiej dać ludziom wytyczne, jakie cele jakościowe mają osiągnąć i niech sobie sami wybiorą, czym je będą osiągać. To jest pole dla konkurencji - tzn. jeśli potrafisz te cele osiągnąć taniej, niż konkurencja używająca języka C, to Twój zysk.
> > Tylko jakoś nikt się nie wychyla i dalej wszyscy "konkurują" robiąc wszystko tak samo, jak reszta.
>
> 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?
Pozdrawiam
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-09-03 20:26 +0200 |
| Message-ID | <qkmb7u$hmr$1@gioia.aioe.org> |
| In reply to | #32953 |
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++. AK
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2019-09-03 23:32 -0700 |
| Message-ID | <b202b96d-4cac-4523-a300-c828c57eb7ce@googlegroups.com> |
| In reply to | #32955 |
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.
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-09-04 18:52 +0200 |
| Message-ID | <qkoq43$1b5t$1@gioia.aioe.org> |
| In reply to | #32961 |
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
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2019-09-05 00:20 -0700 |
| Message-ID | <e0e15a4c-e337-454e-a3b8-1c0afe67380a@googlegroups.com> |
| In reply to | #32969 |
On Wednesday, September 4, 2019 at 6:52:22 PM UTC+2, AK wrote: > 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). Ok, ale napisz coś na temat tego czego nie rozumiem, zamiast pisać trzeci raz to co dobrze zrozumiałem. > > > 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ę...). Rozumiem co chcesz powiedzieć, nie mam tylko bladego pojęcia jak to uzasadniasz. Dlaczego wedlug Ciebie C++ nie nadaje się do programowania krytycznych aplikacji. Mowa oczywiście o dobrym C++ w rękach dobrego programisty. > PS: Nic nie mam do gumowych mlotkow. Swietnie nadaja sie np. do robot > dekarskich czy samochodowej blacharki. No ale _nie do wbijania gwozdzi_. W C/C++ jest napisana duża część systemów operacyjnych i sterowników, a dużo systemów krytycznych pracuje na systemach operacyjnych. Dużo bibliotek jest napisanych w C/C++, z których nawet inne języki korzystają. Jeśli C/C++ się nie nadaje do bezpiecznego programowania, to większość systemów nie jest bezpieczna, bo jest mocno(!) zależna od tego co jest napisane w C/C++. Pozdrawiam
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2019-09-03 12:05 -0700 |
| Message-ID | <b45ee637-25d4-4ff4-a11b-89dca1c2700f@googlegroups.com> |
| In reply to | #32951 |
> > 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
[toc] | [prev] | [next] | [standalone]
| From | slawek <x.y@org.org> |
|---|---|
| Date | 2019-09-04 18:11 +0200 |
| Message-ID | <qkonnc$ma6$1@news.icm.edu.pl> |
| In reply to | #32947 |
Maciej Sobczak <see.my.homepage@gmail.com> Wrote in message: > Mnie na tej liście uderzyła reguła, że w kodzie ma być ileś tam assertów. Dziwne także dlatego że assert zgłasza coś tylko wtedy gdy akurat jakoś się zdarzy. Lepiej robić testy jednostkowe - czyli nie czekać aż się zdarzy - lecz aktywnie testować solidność próbując agresywnie zepsuć. Do tego assert pięknie można wyłączyć. A jakby co to in the deep space te asserty będą nawet nie psu na budę. Kompletnie bez znaczenia. ----Android NewsGroup Reader---- http://usenet.sinaapp.com/
[toc] | [prev] | [next] | [standalone]
| From | slawek <x.y@org.org> |
|---|---|
| Date | 2019-09-04 18:00 +0200 |
| Message-ID | <qkon2p$82q$1@news.icm.edu.pl> |
| In reply to | #32933 |
>NASA jako pop-kulturowego brandu, to nie NASA jest frontem walki o jakość - wynika to z faktu, że w tej branży (podobnie jak w wojsku) nie obowiązują reguły certyfikacji czy homologacji takie jak w cywilnych branżach. NASA jest cywilna, choć rządowa. Natomiast wojsko zawsze i wszędzie kocha standardy i regulaminy: kaliber broni, długość onuc, ... Sławetne normy MIL. ----Android NewsGroup Reader---- http://usenet.sinaapp.com/
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | pl.comp.programming
csiph-web