-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!feeder.erje.net
!2.eu.feeder.erje.net!news.uzoreto.com!eternal-september.org!feeder.eternal-sep
tember.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: heby <h...@p...onet.pl>
Newsgroups: pl.comp.programming
Subject: Re: POpularno?? j?zyk?w programowania ??
Date: Sat, 5 Oct 2019 23:21:17 +0200
Organization: A noiseless patient Spider
Lines: 89
Message-ID: <qnb1gg$68i$1@dont-email.me>
References: <ZFueF.189972$Jh2.55867@fx39.am4>
<b...@g...com>
<5d835054$0$525$65785112@news.neostrada.pl>
<qm5o8c$6mr$1@news.icm.edu.pl>
<5d867c27$0$17361$65785112@news.neostrada.pl>
<qm5va9$c07$1@dont-email.me> <5d86b148$0$520$65785112@news.neostrada.pl>
<qm7c3j$pl6$1@dont-email.me> <5d87968d$0$503$65785112@news.neostrada.pl>
<qm875f$g8o$1@dont-email.me> <5d87b31a$0$522$65785112@news.neostrada.pl>
<qm8e0j$s55$1@dont-email.me> <qmgven$som$1@z-news.wcss.wroc.pl>
<f...@g...com>
<qmnls7$tml$2@news.icm.edu.pl>
<b...@g...com>
<qmtap2$kfe$1@dont-email.me>
<4...@g...com>
<qn5dj9$qh9$3@dont-email.me>
<b...@g...com>
<qn82tb$4uq$1@dont-email.me>
<0...@g...com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 5 Oct 2019 21:21:21 -0000 (UTC)
Injection-Info: reader02.eternal-september.org;
posting-host="56941da0c8b79fb0d789e7fc0caa0dc5"; logging-data="6418";
mail-complaints-to="a...@e...org";
posting-account="U2FsdGVkX1+fDNMpS8tuUNaXMGRw6l7M"
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
Thunderbird/60.9.0
Cancel-Lock: sha1:cPvryX0EIS0raQE/PsE86/hYLD8=
In-Reply-To: <0...@g...com>
Content-Language: en-US
Xref: news-archive.icm.edu.pl pl.comp.programming:214280
[ ukryj nagłówki ]On 05/10/2019 22:12, Maciej Sobczak wrote:
> No więc - skoro już poprawiliśmy tą naszą funkcję, to jaka jest wartość dodana z
użycia kilku kolejnych kompilatorów?
Bardzo prosta. Twój kompilator w poprawnej funkcji dodawania przypadkiem
zrobił mnożenie kiedy x=15 i y=90. Shit happens. Czasem to tylko mignie
szybciej diodą a czasem wyśle samolot w kierunku gruntowym.
> Bo tego cały czas nie pokazałeś.
No więc wyobraź sobie sytuację w któej unit testy posiadają
asymptotycznie pokrycie w 100% zgodne z testplanem.
A kod działa przypadkiem tylko dlatego że kompilator w jakimś miejscu
zamiast referencji użył wartości. W kodzie produkcyjnym użyje referencji
bo tak wyszło kompliatorowi. I wykryje buga na produkcji załączając
odwracacz ciągu w powietrzu.
Dodając dodatkowe narzędzia weryfikacyjne (tak, w tym wypadku kompilator
jest takim narzędziem) możesz zrealizować nastepne poziomy weryfikacji
kodu które wynikają z wymogów bezpieczeństwa. I może, dzięki szczęściu,
błąd wykryjesz. Bo w pewnym momencie niestety kończą się środki formalne
a zaczynają statystyczne.
> Wiemy tylko, że "w dużych firmach", czy jakoś tam. Ale tak konkretnie, po co?
Aby zweryfikować narzędzia do weryfikacji. Ponieważ nie potrafimy tego
robić formalnie ani pewnie, pozostaje weryfikacja statystyczna.
Najprościej poprzez użycie podobnych bądź identycznych narzędzi kilku
róznych firm w celu analizy różnicowej.
>> Kiedy już te i masę innych etapów weryfikacji przejdziezsz po drodze
>> ktos zapyta czy dajesz wiarę w kompilator.
> I tu jest cały trick. Kompilator nie jest celem ani centrum tego ćwiczenia.
Jest narzędziem które odpowiada na pytanie czy kod działa czy nie. Jesli
odpowie źle to możesz sobie całe to unit testowanie wsadzić w dupę.
Czasami odpowiada źle.
> Celem (i ostatecznym produktem) jest kod wynikowy - a jego poprawność właśnie
wykazaliśmy wszystkimi tymi metodami, o których wspomniałeś.
Nie. Wykazałeś że w jakiś warunkach Twój kod działa. A czy to te same
warunki kiedy będzie używany produkcyjnie?
Nie da się tego stwierdzić. Dlatego używa się croos-checków. To jest
BARDZO powszechna praktyka w symulacjach HDL i spotykana praktyka w
programowaniu tradycyjnym.
> Czyli mamy poprawny kod wynikowy.
Nie, testy tego nie wykazują. Testy wykazują że mamy poprawnie
działający kod pod testami. To może być wystarczające jeśli wymogi
bezpieczeństwa są przeciętne i może to być za mało jeśli są wysokie.
Może wyjaśnie na przykładzie. Znam człowieka pracujacego dla poważnej
instytucji związanej z lotnictwem. Aby ich kod przeszedł certyfikat
pozwalający na stosowanie w samolotach musieli, poza wykazaniem
testowania we wszystkich odmianach, zarządzania jakością, weryfikacji
formalnej również to czy zweryfikowali narzędzia. Ponieważ smutni
panowie od certyfikowania nie są z kosmosu i znają realia to zapytali w
ILU różnych symulatorach potwierdzono działanie kodu i czy ich
producenci sami są certyfikowani do użycia w takiej branży.
Z punktu widzenia przeciętnego misaczka programującego pierdoły to jest
bez sensu.
Z punktu widzenia dopuszczeń do zastosowań krytycznych jest kluczowe.
Zarządzanie ryzykiem może prowadzić do czasem pozornie absuralnych akcji.
> Więc po co kolejne kompilatory?
Aby metodami statystycznymi podnieść pewność że to co testujesz nie jest
związane z błędem kompilatora.
>> Istnieją ryzyka gdzie nie można zaufa kompilatorowi.
> Ależ ja mu ani przez chwilę nie ufałem. Ani przez mikrosekundę.
> Ale też nie on jest w centrum uwagi. Więc?
Ale to on napisał na koniec na ekranie "100% testów przeszło".
Możesz mu nie ufać. Cerytyfikator też nie będzie jesli ma się podpisać
pod czymś montowanym jako rozrusznik serca.
PS. A zupałnie na marginesie wszelkiej certyfikacji. Odpalam mój kod pod
trzema kompilatorami. clang, gcc i vc oraz dodatkowo okresowo pod
valgrindem. Codziennie, głównie w celu łownienia różnic składniowych, na
ciągłej integracji. Po kilka razy na co najmniej dwóch z nich. Zgadnij
ile bugów znalazło się w kodzie na jednym z nich który to kod wykazywał
brak błedów na innym? Nie, nie składniowych. 100% testów przeszło na
unit i integracji. A pod innym GPF. Życie.
Następne wpisy z tego wątku
- 05.10.19 23:36 heby
- 05.10.19 23:40 heby
- 05.10.19 23:59 J-23
- 06.10.19 08:50 AK
- 06.10.19 08:52 AK
- 06.10.19 08:54 AK
- 06.10.19 08:55 AK
- 06.10.19 08:56 AK
- 06.10.19 08:57 AK
- 06.10.19 10:31 AK
- 06.10.19 10:32 AK
- 06.10.19 10:37 AK
- 06.10.19 10:42 Mateusz Viste
- 06.10.19 10:43 AK
- 06.10.19 10:45 Mateusz Viste
Najnowsze wątki z tej grupy
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
- Ada 2022 Language Reference Manual to be Published by Springer
- Press Release - AEiC 2023, Ada-Europe Reliable Softw. Technol.
- Ada-Europe - AEiC 2023 early registration deadline approaching
- Ada-Europe Int.Conf. Reliable Software Technologies, AEiC 2023
- Ile cykli zajmuje mnożenie liczb 64-bitowych?
Najnowsze wątki
- 2024-05-15 Mini Netykieta polskich grup i list dyskusyjnych
- 2024-05-15 Warszawa => Key Account Manager <=
- 2024-05-15 Millenium czyli DEBILE bankowości
- 2024-05-15 Warszawa => Frontend Developer - React <=
- 2024-05-15 Marki => ERP Implementer <=
- 2024-05-15 Marki => Wdrożeniowiec ERP <=
- 2024-05-15 System operacyjny dla 6800?
- 2024-05-15 Ulm => IT Netzwerktechniker (m/w/d) <=
- 2024-05-15 Ulm => Technischer Rollouter (d/m/w) <=
- 2024-05-15 Zabrze => Junior HelpDesk <=
- 2024-05-15 Wrocław => Consultant/Implementer Comarch ERP XL <=
- 2024-05-15 Niemcy: "Alles fuer Deutschland" jest zakazane (dla AfD - nieprawomocna grzywna)
- 2024-05-14 Ustawy o rejestracji obcych agentów (wpływu): fuj Gruzja/Rosja v. cacy USA
- 2024-05-14 VMWare :)
- 2024-05-14 Ulm => Solution Engineer (m/w/d) Data Center Technologies <=