On 2019-10-03 20:25, heby wrote:
> Ada pokazuje że można z bezpiecznego języka zrobić takie same fajerwerki
> jak z pisania w C.

Tak. Tyle tylko, ze _prawdopodobienstwo_ zrobienia buga w Adzie jest o
ile tak procent/rzedow mniejsze niz w slawetnym C/C++.

_I o to w tym wszytskim chodzi_ ! :)

AK

do góry

On 2019-10-03 20:44, slawek wrote:
> heby <h...@p...onet.pl> Wrote in message:
>> On 01/10/2019 09:22, Maciej Sobczak wrote:> A ja proszę tylko, żebyś rozwiązał
wskazany przeze mnie problem.Proszę:int multiply(int x, int y){ return x +
y;}"Wyniki obliczeń tej funkcji nie będą zależeć od kompilatora".G. prawda. int nie
jest zdefiniowany i wynik będzie zależał od kompilatora, architektury, flag
kompilacji i bugów w kompilatorze.Te ostatnie bywają kłopotliwe z definiowaniu w
sposób pewny.
>
> Piękny przykład - Turbo Pascala na PC - każdy program (exe)
> kalibrował na starcie opóźnienie delay (jakby kiedyś była
> potrzebna). Robił to wykonując jakiegoś nop ileś tam razy. Potem
> sobie coś wyliczał. No i problem: prędkość procesorów wzrosła aż
> tak, że te nop-yBo zajmowały zero czasu (mierzonego z
> dokładnością 55ms czy jakoś tak). Efekt? Piękne dzielenie przez
> zero i crash w startu code... I to zwykle w programach które
> przez wiele lat były "całkiem dobre". Oczywiście - dotyczyło to
> tylko jednego konkretnego kompilatora, jednego producenta. Więc
> nie ma że działanie programu nie zależy od kompilatora. I że
> każdy kompilator jest taki sam - to piękny - ale
> sen.

To prawda.
Tyle tylko, ze to nie wina Pascala, ale Borlanda (tyczy TurboPascala3.x
a nie 4.x czy Delphii).
W owym czasie MC C/C++ praktycznie nie nadawal sie do uzycia (50+
powaznych bugow), dlatego pisalismy w.. Turbo C++ a pozniej w Borland
C++.
PS: Na tymze syfiastym Borlandzie stalo cale Asseco (wtedy COMP Rzeszow)
- vide defBank. Wiec spoko Slawciu. Nie podniecaj sie. Mozna...
Jeno trzeba sie _naprawde_ znac (bebechy kompilerow rowniez).

PS: Moge Ci latwo udowodnic _jak_ trzeba sie bylo znac.
No ale tego ex cathedra nie widac (tylko byle granty;)

AK

do góry

On 03/10/2019 22:01, AK wrote:
> Tak. Tyle tylko, ze _prawdopodobienstwo_ zrobienia buga w Adzie jest o
> ile tak procent/rzedow mniejsze niz w slawetnym C/C++.
> _I o to w tym wszytskim chodzi_ ! :)

I jak zapewne zauważyłeś nie dyskutuje z tą opinią bo jest ona prawdziwa.

Nieprawdziwa jest opinia że Ada jest bezpieczna bo język utrudnia
robienie błedów.

Nie, soft jest tak bezpieczny jak dobrze jest przetestowany. Rodzaj
wybranego języka co najwyżej determinuje narzędzia uzyte w procesie
weryfikacji i komfort pisania. Czy Ada czy Asm na końcu i tak chodzi
tylko o to jak zweryfikowaliśmy to co napisaliśmy.

do góry

On 03/10/2019 21:52, AK wrote:
> Po prostu Pascal jest bezpieczniejszy od C/C++

To jest niestety dyskutowalne. Pascal nie ma absolutnie żadnych narzędzi
gotowych do pisania algorytmami wysokiego poziomu. W związku z tym
wszystcy wymyślali kwadratowe koła. W efekcie jest niebezpieczny
ponieważ ilosć miejsc gdzie można zrobić buga rośnie i są to bugi
cieżkie do zweryfikowania.

> i tego sie _nie da
> zagadac_ pseudo-argumentami.

Pseudo argumentem jest gadanie o wyższości Pascala w obliczu biliona
implementacji listy dwukierunkowej z czego 60% była błędna
algorytmicznie. Drzewo czerwono-czarne znalazłem jedno, w projekcie
komercyjnym. Też z błedami. Kwadratowe koła to ogólnie najczęściej
spotykany przeze mnie bug w Pascalu.

Innymi słowy język może miał być i bezpieczny ale wyszło jak zwykle. To
już wole Adę.

do góry

On 03/10/2019 21:23, slawek wrote:
>> Ba, a słyszałeś że Kangury to nie to samo co spinacze biurowe?
> A jaka jest definicja "to samo"?!

Odwrotność twojej definicji "różne są".

> Poczytaj sobie czym jest myślenie abstrakcyjne.

Ja zaś polecam Prusa. Nie żeby to było w temacie, ale przecież i tak nie
jest.

do góry

On Thursday, October 3, 2019 at 8:04:09 PM UTC+2, heby wrote:
> On 01/10/2019 09:18, Maciej Sobczak wrote:
> >> Pikuś. Nikt tego nie używa w większości projektów embedded. Tam gdzie
> >> się używa wiedzą co chcą osiągnąć. Ale to szum. Ada jest niespecjalnie
> >> uzyteczna masowo.
> > Świeżutki news:
> > https://www.adacore.com/press/european-space-agency-
selects-adacores-qualified-multitasking-solution-for
-spacecraft-software-development
> > Ferrari też nie jest użyteczny masowo. Ale to jednak fajna fura jest.
>
> No. Clojure też jest fajna fura. Te z listy ezoterycznych też są fajne.
> Całe szczęście Pascal nie jest.

Uwaga, teraz mówię ściśle o języku, ewentualnie o tak bliskich narzędziach
jak preprocesor w C/C++. Do rzeczy, osobiście bardzo lubiłem pascala. Ale
języki takie jak Java, C, C++, C# moim zdaniem są fajniejsze. Szkoda że
język D ma małe wsparcie, możliwe że byłby moim ulubionym językiem. PHP
nie lubię, ale używam, ponieważ jest dedykowany do weba i ma pod ręką
masę wygodnych bibliotek przydatnych w aplikacjach webowych.

Pozdrawiam

do góry

> > Świeżutki news:
> > https://www.adacore.com/press/european-space-agency-
selects-adacores-qualified-multitasking-solution-for
-spacecraft-software-development
> > Ferrari też nie jest użyteczny masowo. Ale to jednak fajna fura jest.
>
> No. Clojure też jest fajna fura. Te z listy ezoterycznych też są fajne.

Tak. I nawet każdy z nich ma swój fanclub. Ale do rakiety się nie nadają.
Dopiero co dyskutowaliśmy tu o tym, ale można jeszcze raz.

> Całe szczęście Pascal nie jest.

Czym nie jest? Fajną furą? Użyteczny masowo? Wybrany przez ESA do najnowszego
projektu? Bo się pogubiłem.

Nie znam żadnego nowego projektu, gdzie zdecydowano by się użyć Pascala (oczywiście
nie znaczy to, że takich nie ma). Znam natomiast nowy projekt z Adą, link powyżej.

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

do góry

> int multiply(int x, int y)
> {
> return x + y;
> }
>
> "Wyniki obliczeń tej funkcji nie będą zależeć od kompilatora".
>
> G. prawda. int nie jest zdefiniowany i wynik będzie zależał od
> kompilatora [...]

To w końcu jakie jest rozwiązanie tego problemu?
Wybrać kompilator, z którym wyniki tej funkcji mają najwięcej lajków?

Nadal nie rozwiązałeś tego problemu.

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

do góry

On 2019-10-03 22:19, heby wrote:
> Nieprawdziwa jest opinia że Ada jest bezpieczna bo język utrudnia
> robienie błedów.

Jak juz ustalilismy _nie ma_ (i nie bedzie) jezykow w pelni
bezpiecznych (wszytskim rzadzi prawdopodobienstwo).

Czy Ci sie to podoba czy nie, Ada jest jednak _najbezpieczniejszym_
jezykiem programowania. O (kilka?)rzad wielkosci bezpieczniejszym
od C/C++ czy nawet Pascala.

W dodatku ten jezyk (przez swoj "ekosystem" - weryfikowalnosc jezyka,
weryfikowalnosc kompilatorow - o dziwo jedna z przyczyn "upadku" Ady;)
jako jeden z nielicznych daje mozliwosc weryfikowalnosci programow
(czyli sprawdzalnosci kodu w stosnku do zalozen/projektu).

Stawianie wiec Ady na rowniz z C/C++ czy assemblerem jest po prostu
horrendum... :(

AK

do góry

> > Czyli nie czytałeś raportu z analizy tej katastrofy.
>
> Ależ czytałem. Nie inputuj.

http://sunnyday.mit.edu/nasa-class/Ariane5-report.ht
ml

Zobaczmy.

> > Skrót jest taki: w Ariane 5 wykorzystano moduł opracowany dla Ariane 4, czyli pod
inne wymagania.
>
> I nikt go pod te wymagania nie testował.

Na jakiej podstawie tak uważasz?
Nie dość, że testował, to jeszcze używał:

"unless proves necessary, it was not wise to make changes in software which WORKED
WELL on Ariane 4"

> Słusznie. "inzynier syatemowy" bowiem zakłada magiczność Ady

Nie czytałeś. Inżynier systemowy założył, że można część testów zrobić na symulatorze
a nie na fizycznym module. 3.1 Findings, podpunkt s).

> Jeśli się upierasz że winę nie ponosi ktoś kto napisał kiepską funkcję
> tylko jakiś pierdzący w stołek dyrektor

"It is important to note that the decision [...] was taken jointly by project
partners at several contractual levels."

Wiesz, co to są "contractual levels"?

> to może spuśćmy zasłonę
> milczenia na to jak zakończą się następne projekty tego teamu

No właśnie - jak się zakończyły następne projekty?

> Kod który zakłada że "wynik obliczeń na pewno zmieści się w typie int16
> alnie nie testujemy bo nie chce nam się" jest do dupy z definicji.

Czyli nie czytałeś. To był wynik rzutowania z 64-bitowego float'a. W jaki sposób byś
to przetestował? Rzutując większe wartości i dostając wyjątek i stwierdzając, że
reakcja jest poprawna?
Właśnie taka reakcja była.

> Choćby dlatego że w takim wypadku używa się arytmetyki z saturacją jesli
> ma wystapić niemożliwe.

Jakiś link do standardu, który tak nakazuje.
Jeśli wystąpiło niemożliwe, to znaczy, że nie wiesz, co się dzieje. Wtedy odpala się
procdurę awaryjną, którą w przypadku Ariane 5 było samozniszczenie.

> A tu najzwyczajniej w "bezpiecznym języku"
> odpierdolono byle jak.

Gdzie w tym raporcie jest takie stwierdzenie?

> > Hint: gdybyś był tam *programistą*, to też by pierdykło, bo miałbyś w tej sprawie
dokładnie tyle samo do powiedzenia
>
> Miałbym do powiedzenia znacznie więcej.

Oczywiście.

> Ada pokazuje że można z bezpiecznego języka zrobić takie same fajerwerki
> jak z pisania w C.

Nikt nie twierdzi inaczej. Niektórzy twierdzą jednak, że w dobrym języku o fajerwerki
jest trudniej.

> Zawsze podstawowe pytanie brzmi: czy kod jest zweryfikowany,
> poddany testom, ma pokrycie coverage które definiuje jakiś poziom ryzyka.

I który punkt raportu stwierdza, że tego nie było?

> A tutaj sobie jakiś misio wrzuca kod z jednego systemu do drugiego.

Tak właśnie było.
Dlatego powtórzę: to nie była wina Ady, to nie była wina programistów i nic więcej
nie miałbyś tam do powiedzenia.

Przeczytaj ten raport.

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

do góry