On 23/03/2012 14:49, Tomasz Kaczanowski wrote:
> W dniu 2012-03-23 15:36, Andrzej Jarzabek pisze:
>>>
>>>> I wiadomo, że prawdopodobieństwo tego wynosi 100%?
>>>
>>> Prawdopodobieństwo czego?
>>
>> Tego, że "wszystko jest w niewłaściwej obudowie i zadziała przez to
>> źle".
>
> znowu nisko latające kwantyfikatory....

Nie mówię o kwantyfikatorach, tylko o prawdopodobieństwie. Bo jak się
rozpatrza niezawodność, to się operuje na prawdopodobieństwach, nie na
kwantyfikatorach. Jeśli mówisz "skoro z prawodpodobieństwem p obudowa
będzie niewłaściwa i całość zadziała źle, to co za różnica, jakie będzie
prawdopodobieństwo, że w oprogramowaniu będzie błąd, powodujący, że
całość zadziała źle". Otóż jedyna wartość p, przy której nie ma różnicy,
to 100%.

> Podałem przykład, co moze byc
> źle, ba jeden z przykładów z życia. Pokazałem Ci, że na to by urzadzenie
> istotne dla bezpieczeństwa działało dobrze istotna jest praca innych niż
> programista osób.

To nie znaczy, że praca programisty jest nieistotna.

> Dlatego musiałbys certyfikować nie tylko programistów,
> ale i projektantów elektroniki, projektantów elektryków i pewnie jeszcze
> kilku innych. Zamiast tego certyfikuje się urządzenie - bo jest pewniej
> i duzo taniej.

W wielu innych dziedzinach już jest certyfikacja. Na przykład do
projektowania instalacji elektrycznych trzeba mieć uprawnienia.

>> Czy może twierdzisz, że są takie obudowy, przy których właśnie
>> programy z UB, data races, deadlockami, nieobsłużonymi wyjątkami,
>> wyciekami zasobów, napisane w nieczytelny sposób i źle zaprojektowane
>> - będą chodzić najlepiej?
>
> Co to ma do rzeczy. Czy osoba z certyfikatem, czy bez tak samo może nie
> obsłużyć wszystkich wyjątków, choćby z czystego lenistwa, albo błędów w
> projekcie.

To jest jeszcze raz ten sam debilny argument, co z certyfikacją pilotów
i spadającymi samolotami. Już drugi raz używasz tego debilnego
argumentu. Zastanawia mnie, z czego to wynika?

>>>>> całość nie będzie działać. Tak więc widzisz, oprogramowanie jest tu na
>>>>> szarym końcu tego co może zawieźć. Więc 10 krotnie certyfikowany
>>>>> programista nic nie zdziała. Bo problem zazwyczaj leży gdzie indziej.
>>>> Skoro tak twierdzisz, to zapewne potrafisz podeprzeć to wiarygodnym
>>>> badaniem?
>>> Co mam potwierdzać badaniem?
>> Że "oprogramowanie jest na szarymkońcu" i "problem zazwyczaj leży
>> gdzie indziej".
>
> Tylko po co mam Ci to wykazywać badaniami.

Bo inaczej powiem: "pierdzielisz".

> Może zatrudnij się w
> przemyśle, popracuj przy rzeczywistych projektach, a sam zobaczysz,
> gdzie pojawia się najwięcej problemów.

Widzisz, debilom się wydaje, że jak jakiś Iksiński pracuje w przemyśle i
zobaczył w swojej pracy, że najwięcej problemów pojawia się gdzieśtam,
to znaczy, że właśnie tam najwięcej problemów się pojawia. Ludzie
posiadający choć trochę inteligencji, wiedzą, że Igrekowski może też
pracować w przemyśle i zobaczyć, że najwięcej problemów pojawia się
gdzie indziej, a Abacki - jeszcze gdzie indziej. Dlatego inteligentni
ludzie rozumieją, że żeby mieć wiarygodny obraz tego, gdzie się
pojawiają problemy, trzeba zebrać doświadczenia różnych Iksińskich,
Igrekowskich i Abackich i dopiero wyciągnąć z nich wnioski, a nie samemu
się zatrudnić w przemyśle i zobaczyć.