W dniu poniedziałek, 1 października 2012 19:31:11 UTC+2 użytkownik Sebastian Biały
napisał:

> > Tak właśnie było z Ariane 5, bo użyto tam modułu z poprzedniego
> > modelu, gdzie był zarówno bezpieczny jak i szybki.
> > No, ale w nowym modelu był już tylko szybki.
>
> Nie zgadzam się.

Ale mi wisi, czy się zgadzasz, czy nie. Pisałem, już, że temat jest mi znany. Ty
najwyraźniej postanowiłeś się z nim zapoznać jedynie w takim zakresie, jaki jest Ci
potrzebny to trollowania.

http://www.di.unito.it/~damiani/ariane5rep.html

"The design of the Ariane 5 SRI is practically the same as that of an SRI which is
presently used on Ariane 4, particularly as regards the software."

"The value of BH was much higher than expected because the early part of the
trajectory of Ariane 5 differs from that of Ariane 4 and results in considerably
higher horizontal velocity values."

Również, na temat projektowania pod kreskę:

"It has been stated to the Board that not all the conversions were protected because
a maximum workload target of 80% had been set for the SRI computer."


Ogólnie, poczytaj to, nie będziesz musiał tworzyć teorii z domysłów.


> Ten kawalek kodu nie miał prawa wejść w jakikolwiek
> komputer sterujący

Nopaczpan. Nie miał, a wszedł.

[...]
> No patrz, Ada to taki jezyk z silnym typowaniem, super-wyjątkami,
> genialną składnią i kupką szitu pozwalającą legalnie wszystko wsadzić
> między bajki.

Tak, można legalnie zrobić memcpy. Pisałem już o tym wielokrotnie, ale skoro z takim
uwielbieniem się nad tym pastwisz, to mogę napisać jeszcze parę razy. Chociaż coraz
mniej rozumiem, po co to robię - ani ja ani Ty na tej dyskusji nie korzystamy a jeśli
ktokolwiek to jeszcze czyta, to i tak się pewnie zdążył ustawić.


> I teraz - tadaaaam - zmierzamy w kierunku oczywistym: bezpieczeństwo
> kodu zależy nie od języka tylko od programisty.

Pudło. Zależy od obu tych rzeczy, bo dany programista napisze lepszy kod w tym
języku, który jest bezpieczniejszy. Twój "argument" można porównać do stwierdzenia,
że bezpieczeństwo jazdy zależy wyłącznie od kierowcy. Otóż niespodzianka: zależy
również od samochodu, jego sprawności technicznej i wyposażenia typu ABS, ASR,
AirBag, etc. Tylko dlaczego ja takie rzeczy tu piszę?

> To zbiór czynników poza
> językiem decyduje w najwiekszym stopniu o jakości kodu. Takie duperele
> jak code review, formalna weryfikacja, analizy statyczne, dynamiczne,
> testowanie, ... Ada akuratnie niewiele pomaga, nie na tyle żeby to
> nazywać bezpiecznym kodem. Zapewne pierdyliard rzeczy poza Adą lepiej
> weryfikuje kod niż język.

Zapewne? Masz jakieś dane na ten temat? Pytam poważnie, bo temat mnie interesuje
zawodowo. Ale nie, czekaj - przecież tylko trollujesz. W dodatku nieudolnie, bo
tematu nie znasz, co udaje Ci się w każdym poście wykazać.

> Ale nie, przecież trolowanie i flame na tym polegają że nie. Nie nie nie.

Sorry - przymierzam się do opuszczenia wątku.

Spróbuj napisać coś merytorycznego, bo takie pierdolenie jak tu uprawiasz nie wydaje
mi się rozwojowe.

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

do góry

On 2012-10-01 23:08, Maciej Sobczak wrote:
> Spróbuj napisać coś merytorycznego, bo takie pierdolenie jak tu uprawiasz

Zakład uważam za wygrany :)

Ktoś mi bedzie teraz winien zgrzewkę :P

Nie miej do mnie urazy Macieju, ale byłeś łatwym celem.

do góry

W dniu poniedziałek, 1 października 2012 22:24:38 UTC+1 użytkownik Sebastian Biały
napisał:
> On 2012-10-01 23:08, Maciej Sobczak wrote:
>
> > Spróbuj napisać coś merytorycznego, bo takie pierdolenie jak tu uprawiasz
>
>
>
> Zakład uważam za wygrany :)
>
>
>
> Ktoś mi bedzie teraz winien zgrzewkę :P
>
>
>
> Nie miej do mnie urazy Macieju, ale byłeś łatwym celem.

O, jestes taka wersja kenobiego tylko z klasy sredniej i po wyzszej uczelni.

RW

do góry

On 2012-09-29 00:37, Edek Pienkowski wrote:
> Dnia Fri, 28 Sep 2012 07:57:31 -0700, Roman W napisal:
>
niej dominującym".
>
> Wracając do Ady, nie wiem w jakich kręgach jest modna ani
> dlaczego, sam się akurat z Adą bezpośrednio nie zetknąłem,
> ale nie miałbym nic przeciwko, nawet gdyby mi niespecjalnie
> "leżała".
>
Trochce przesadzajac, rozumiem iz jak moj nastepny projekt bede robil w
brainfucku moge sie zglosic do Ciebie ;-) ? Wydaje mi sie ze jednak
jezyk powinien "lezej" programiscie.

Pozdrawiam

Marek

do góry

Dnia Mon, 08 Oct 2012 10:05:58 +0200, Marek Borowski napisal:

> On 2012-09-29 00:37, Edek Pienkowski wrote:
>> Dnia Fri, 28 Sep 2012 07:57:31 -0700, Roman W napisal:
>>
> niej dominującym".
>>
>> Wracając do Ady, nie wiem w jakich kręgach jest modna ani
>> dlaczego, sam się akurat z Adą bezpośrednio nie zetknąłem,
>> ale nie miałbym nic przeciwko, nawet gdyby mi niespecjalnie
>> "leżała".
>>
> Trochce przesadzajac, rozumiem iz jak moj nastepny projekt bede robil w
> brainfucku moge sie zglosic do Ciebie ;-) ? Wydaje mi sie ze jednak jezyk
> powinien "lezej" programiscie.

Jeżeli jesteś akwizytorem brainfucka, możesz dzwonić ;)

Zgadzam się, język powinien być fajny, kolorowy, łatwy, przyjemny,
miło pachnący i dobrze zareklamowany. Z tym że te cechy nie są
- dla mnie akurat, takie skrzywienie - najważniejsze.

--
Edek

do góry

Dnia 01.10.2012 Maciej Sobczak <s...@g...com> napisał/a:
> W dniu poniedziałek, 1 października 2012 19:31:11 UTC+2 użytkownik Sebastian Biały
napisał:
>
>> > Tak właśnie było z Ariane 5, bo użyto tam modułu z poprzedniego
>> > modelu, gdzie był zarówno bezpieczny jak i szybki.
>> > No, ale w nowym modelu był już tylko szybki.
>>
>> Nie zgadzam się.
>
> Ale mi wisi, czy się zgadzasz, czy nie. Pisałem, już, że temat jest mi znany. Ty
najwyraźniej postanowiłeś się z nim zapoznać jedynie w takim zakresie, jaki jest Ci
potrzebny to trollowania.
>
> http://www.di.unito.it/~damiani/ariane5rep.html
>
> "The design of the Ariane 5 SRI is practically the same as that of an SRI which is
presently used on Ariane 4, particularly as regards the software."
>
> "The value of BH was much higher than expected because the early part of the
trajectory of Ariane 5 differs from that of Ariane 4 and results in considerably
higher horizontal velocity values."
>
> Również, na temat projektowania pod kreskę:
>
> "It has been stated to the Board that not all the conversions were protected
because a maximum workload target of 80% had been set for the SRI computer."
>
>
> Ogólnie, poczytaj to, nie będziesz musiał tworzyć teorii z domysłów.


Jeśli potrzebowali wydajności, to mogli użyć wydajnego narzędzia,
jeśli potrzebowali bezpieczeństwa, to nie powinni "wyłączać
bezpieczników". Jeśli potrzebowali kompromisu, to trzeba było to co
się da zaimplementować w Ada bez "wyłączania bezpieczników" a część
wymagającą wydajności zrobić jawnie w czymś innym (C, ASM czy
czymkolwiek innym). Wtedy wiadomo, że to co w Ada ma swoje
"bezpieczniki" a dodatkowe rzeczy trzeba sprawdzić jako osobne,
niezależne moduły. Projektanci chcąc pogodzić wydajność i niezawodność
popełnili błąd mieszając kod wysokopoziomowy i niskopoziomowy w ramach
jednego "klocka" - kompromis nie zadziałał co jest chyba
wystarczającym dowodem na to, że to był zły pomysł. Wina nie leży tu w
użyciu tego czy innego języka (bo mechanizmy każdego języka mogą być
użyte dobrze lub źle), tylko na błędnym podejściu do sprawy.

Mechanizmy żadnego języka nie zwalniają od myślenia, mogą być pomocne,
ale nie zniwelują błędów w projekcie. Ślepa wiara w mechanizmy języka
może sprowadzić na manowce, bo zawsze może pojawić się coś tak
trywialnego, jak błąd w kompilatorze czy innym narzędziu i całe
cudowne mechanizmy mające zapewnić niezawodność mogą przestać działać
:D

do góry

Dnia Mon, 08 Oct 2012 17:00:31 +0000, Baranosiu napisal:

> Mechanizmy żadnego języka nie zwalniają od myślenia, mogą być pomocne, ale
> nie zniwelują błędów w projekcie. Ślepa wiara w mechanizmy języka może
> sprowadzić na manowce, bo zawsze może pojawić się coś tak trywialnego, jak
> błąd w kompilatorze czy innym narzędziu i całe cudowne mechanizmy mające
> zapewnić niezawodność mogą przestać działać :D

Dlatego tworzone są kompilatory "Coq verified", wspierają niezły subset C.

A spora część ludzi mało myśli, głównie myśli że myśli, a żyje... powiedziałbym,
że w zasadzie wszyscy tak robią, kwestia tylko skali problemu.

--
Edek

do góry

W dniu poniedziałek, 8 października 2012 19:00:36 UTC+2 użytkownik Baranosiu napisał:

> Jeśli potrzebowali wydajności, to mogli użyć wydajnego narzędzia,
>
> jeśli potrzebowali bezpieczeństwa, to nie powinni "wyłączać
>
> bezpieczników". Jeśli potrzebowali kompromisu, to trzeba było to co
>
> się da zaimplementować w Ada bez "wyłączania bezpieczników" a część
>
> wymagającą wydajności zrobić jawnie w czymś innym (C, ASM czy
>
> czymkolwiek innym).

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?

> Wtedy wiadomo, że to co w Ada ma swoje
>
> "bezpieczniki" a dodatkowe rzeczy trzeba sprawdzić jako osobne,
>
> niezależne moduły.

Nie różni się to niczym od sprawdzenia modułów z wyłączonymi bezpiecznikami. Nie
sprawdzono tego, więc równie dobrze nie sprawdzono by tych modułów, gdyby były
napisane w C.

> Projektanci chcąc pogodzić wydajność i niezawodność
>
> popełnili błąd mieszając kod wysokopoziomowy i niskopoziomowy w ramach
>
> jednego "klocka"

Chyba mieszasz pojęcia. Kod może być bezpieczny będąc niskopoziomowym. Poziom
abstrakcji i poprawność to dwie niezależne sprawy. Nie ma sensu mówić, że projektanci
pomieszali kod wysokopoziomowy i niskopoziomowy tylko na podstawie tego, że gdzieś
bezpieczniki były włączone a gdzieś wyłączone, bo poziom abstrakcji tych kawałków
mógł być niezależny (w szczególności mógł być taki sam).

> - kompromis nie zadziałał co jest chyba
>
> wystarczającym dowodem na to, że to był zły pomysł.

Nadal chyba nie czytałeś tego raportu. Przypomnę: ten kod został stworzony dla
poprzedniego modelu rakiety, gdzie był w 100% poprawny, bo działał w ramach innych
warunków technicznych. Przeniesiono moduł do nowej rakiety, która miała inne
prędkości i w ten sposób poprawny moduł stał się niepoprawny. To nie jest kwestia
kompromisów w kodzie, tylko błędu wdrożeniowego.

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. Program się wywala. Czy to był błąd programisty? Nie ma sensu rozwodzić się
and tym, czy właściwie pomieszałeś kod niskopoziomowy z wysokopoziomowym albo które
kawałki powinieneś napisać w C, bo nie tu powstał problem. Problem powstał przez złe
użycie gotowego i poprawnego w swoim oryginalnym kontekście modułu.

> Ślepa wiara w mechanizmy języka
> może sprowadzić na manowce, bo zawsze może pojawić się coś tak
> trywialnego, jak błąd w kompilatorze czy innym narzędziu i całe
> cudowne mechanizmy mające zapewnić niezawodność mogą przestać działać

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

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

do góry

Dnia 08.10.2012 Maciej Sobczak <s...@g...com> napisał/a:
> W dniu poniedziałek, 8 października 2012 19:00:36 UTC+2 użytkownik Baranosiu
napisał:
>
>> Jeśli potrzebowali wydajności, to mogli użyć wydajnego narzędzia,
>>
>> jeśli potrzebowali bezpieczeństwa, to nie powinni "wyłączać
>>
>> bezpieczników". Jeśli potrzebowali kompromisu, to trzeba było to co
>>
>> się da zaimplementować w Ada bez "wyłączania bezpieczników" a część
>>
>> wymagającą wydajności zrobić jawnie w czymś innym (C, ASM czy
>>
>> czymkolwiek innym).
>
> 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
(których wcześniej używał i go nie zawiodły, więc im 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 i 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, a z
tego co pisałeś, to właśnie ze względu na obciążenie rzędu 80%
zrezygnowano z zabezpieczeń), to byłoby to gruntownie sprawdzone jako
niezależny od reszty "klocek". W sumie nie jest ważne w jakim języku,
może być i Ada, byleby nikt nie oparł się pokusie "skopiowania starego
kodu" czy stosowania rutynowych testów bazujących na
"bezpiecznikach". 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

>
>> Wtedy wiadomo, że to co w Ada ma swoje
>>
>> "bezpieczniki" a dodatkowe rzeczy trzeba sprawdzić jako osobne,
>>
>> niezależne moduły.
>
> Nie różni się to niczym od sprawdzenia modułów z wyłączonymi bezpiecznikami. Nie
sprawdzono tego, więc równie dobrze nie sprawdzono by tych modułów, gdyby były
napisane w C.
>
>> Projektanci chcąc pogodzić wydajność i niezawodność
>>
>> popełnili błąd mieszając kod wysokopoziomowy i niskopoziomowy w ramach
>>
>> jednego "klocka"
>
> Chyba mieszasz pojęcia. Kod może być bezpieczny będąc niskopoziomowym. Poziom
abstrakcji i poprawność to dwie niezależne sprawy. Nie ma sensu mówić, że projektanci
pomieszali kod wysokopoziomowy i niskopoziomowy tylko na podstawie tego, że gdzieś
bezpieczniki były włączone a gdzieś wyłączone, bo poziom abstrakcji tych kawałków
mógł być niezależny (w szczególności mógł być taki sam).
>
>> - kompromis nie zadziałał co jest chyba
>>
>> wystarczającym dowodem na to, że to był zły pomysł.
>
> Nadal chyba nie czytałeś tego raportu. Przypomnę: ten kod został stworzony dla
poprzedniego modelu rakiety, gdzie był w 100% poprawny, bo działał w ramach innych
warunków technicznych. Przeniesiono moduł do nowej rakiety, która miała inne
prędkości i w ten sposób poprawny moduł stał się niepoprawny. To nie jest kwestia
kompromisów w kodzie, tylko błędu wdrożeniowego.
>
> 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. Program się wywala. Czy to był błąd programisty? Nie ma sensu
rozwodzić się and tym, czy właściwie pomieszałeś kod niskopoziomowy z
wysokopoziomowym albo które kawałki powinieneś napisać w C, bo nie tu powstał
problem. Problem powstał przez złe użycie gotowego i poprawnego w swoim oryginalnym
kontekście modułu.
>


Moduł nie jest poprawny czy niepoprawny sam z siebie, a jedynie w
kontekście danych jakie przetwarza. Nie pisz, że moduł był poprawny,
bo nie był, 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).


>> Ślepa wiara w mechanizmy języka
>> może sprowadzić na manowce, bo zawsze może pojawić się coś tak
>> trywialnego, jak błąd w kompilatorze czy innym narzędziu i całe
>> cudowne mechanizmy mające zapewnić niezawodność mogą przestać działać
>
> Tak. I jaki z tego wniosek w kontekście tematu dyskusji (cokolwiek nim było)?
>

Taka, że ktoś założył, że skoro moduł przeszedł testy ze starym
systemem, to jest poprawny i nie trzeba "wnikać", automatyczne testy w
nowym systemie nie wykazały niezgodności (bo "bezpieczniki" nie
zadziałały) ale całościowo w praktyce system poległ. 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.

Kwestia indywidualnego podejścia, ja wolę wybierać odpowiednie
narzędzia do rozwiązywanego problemu, inni wolą przystosowywać jedno
narzędzie do wszystkich problemów :D Każdy ma prawo mieć swoje zdanie
i nikt nikogo do niczego nie musi przekonywać, wyraziłem swoją opinię
i to wszystko, nie podchodź do tego jak do "świętej wojny" :D
Z mojej strony EOT

do góry

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

do góry