W dniu wtorek, 9 października 2012 01:21:28 UTC+2 użytkownik Baranosiu napisał:

> > I czym to coś różniłoby się od Ady z wyłączonymi bezpiecznikami? Jaki byłby zysk
z napisania tego kawałka w C?
>
> Taki, że nikt nie potraktowałby tego kawałka kodu narzędziami do Ady

No to bieda, bo ze względu na wsparcie ze strony języka narzędzia do Ady są znacznie
lepsze, niż narzędzia do C.

> (których wcześniej używał i go nie zawiodły, więc im ufał).

No właśnie. Dlaczego miałby nagle użyć innego narzędzia, któremu nie ufa?

> Sam
> pisałeś, że sprawa została w pewnym sensie zlekceważona (na zasadzie
> "wcześniej działało, to i teraz zadziała"), gdyby projektant wymusił
> napisanie tego od zera

No właśnie. Gdyby to napisano od zera, to być może uwzględnionoby nowe warunki
techniczne i wtedy nie byłoby problemu.

> i w innym języku

Pytam jeszcze raz: dlaczego w innym? Jaki byłby zysk z napisania tego w innym języku?

> (i co by nie mówić, to
> napisanie tego w C dało by zysk na szybkości i zajętości pamięci,

Skąd ta teza? Na jakiej podstawie tak twierdzisz?
Myślisz, że operacje na liczbach całkowitych zajmują w Adzie więcej cykli? Albo
więcej pamięci?

> to byłoby to gruntownie sprawdzone jako
> niezależny od reszty "klocek".

Oczywiście. Ale nie ma żadnych przesłanek (poza stereotypową wiarą w C), żeby ten
niezależny klocek robić w innym języku.

> W sumie nie jest ważne w jakim języku,

Ważne, bo języki różnią się w tym, jak wspierają programistę w osiąganiu określonych
celów. Gdyby się nie różniły, to mielibyśmy jeden język do wszystkiego.

> Zarządzanie projektem to nie tylko zarządzanie
> specyfikacjami itp., to przede wszystkim zarządzanie ludźmi, a ludzie
> to nie maszyny - jeśli system zarządzania projektem nie wymusza
> właściwych procedur postępowania i stosowania właściwych mechanizmów,
> to prędzej czy później znajdzie się ktoś, kto sobie "uprości" życie :D

Słusznie. Ale jak to wpływa na wnioski z tej dyskusji?

> > Coś w tym stylu: ktoś każe Ci napisać program, który dodaje liczby z zakresu od 0
do 100. Da się. Potem gość bierze ten gotowy program i wrzuca do niego liczby
większe, niż 100.
[...]

> Moduł nie jest poprawny czy niepoprawny sam z siebie, a jedynie w
> kontekście danych jakie przetwarza.

Bingo. Ten konkretny moduł był poprawny w kontekście danych, do przetwarzania których
został stworzony. Programiści wypełnili swoje zadanie bez zarzutu.

> Nie pisz, że moduł był poprawny,
> bo nie był

Dlaczego nie był? Mógł być w 100% poprawny i zgodny z oryginalną specyfikacją.

> to tak jak ja bym powiedział, że buty które mam w szafie
> są ok, bo chodziłem w nich jak miałem 5 lat i działały bez zarzutu, a
> że teraz mam 36 lat to tylko drobny szczegół (buty oczywiście mogą
> nadal działać w kontekście innego 4-latka, ale w moim już nie działają
> poprawnie).

Masz w szafie poprawne buty. Możesz mieć też głupi pomysł, żeby je dzisiaj założyć,
ale buty nadal są poprawne w kontekście użycia przez dziecko, lat 5.

> > I jaki z tego wniosek w kontekście tematu dyskusji (cokolwiek nim było)?

> Nie twierdzę, że
> to wina Ady jako języka, to wina człowieka, który za bardzo zaufał
> istniejącemu kodowi oraz mechanizmom wykrywania błędów zawartymi w
> języku.

I nadal nie wiem, jaki z tego wniosek. Że systemy sterowania rakietami należy pisać w
językach, które nie wspierają programisty w osiąganiu poprawności, bo dzięki temu nie
będziemy im ufać i przez tą większą podejrzliwość i czujność będziemy łatwiej
znajdywać w nich błędy? I nigdy nie wsadzimy do nowej rakiety starego komputera?

A może nie zapinajmy w samochodzie pasów bezpieczeństwa i w ogóle jeździjmy nocą bez
świateł - wtedy będziemy bardziej uważać a nie rozleniwiać się złudzeniem uzyskanego
tanio bezpieczeństwa. Tak?

> Kwestia indywidualnego podejścia, ja wolę wybierać odpowiednie
> narzędzia do rozwiązywanego problemu,

No właśnie. To jakie narzędzie jest odpowiednie?
Bo z tej dyskusji nadal nie wiem.

> Każdy ma prawo mieć swoje zdanie

Oczywiście.

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