On 2019-10-03 22:26, heby wrote:
> To jest niestety dyskutowalne. Pascal nie ma absolutnie żadnych narzędzi
> gotowych do pisania algorytmami wysokiego poziomu.

Przepraszam, co Ty smolisz?
Pisalem w Pascalu na Odrze na _naprawde_/wylacznie wysokim poziomie.

AK

do góry

On 2019-10-03 22:26, heby wrote:
> 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.

Zapewniam Ci ze w _kazdym_ jezyku biblioteki posiadaja wiele bugow
(zwlaszcza w C/C++ - mam na to dowody - do Turbo C 2.0 musialem
napisac - tak tak, w assemblerze, a jakze - _calą_ bibliotekę
standardową, aby mozna bylo to C uzywac _w ogole_.

To jednak nijak nie swiadczy o jezyku, ale o producentach
kompilatorow (w tych czasach najbardziej zbuggowany byl MS C/C++)
z jego slynnym wyrobem QuickC - tenze quick _w ogole_ nie dzialal
(GFP itp itd) poza trybem debug.

AK

do góry

W dniu 04.10.2019 o 08:18, AK pisze:
> On 2019-10-03 22:26, heby wrote:
>> To jest niestety dyskutowalne. Pascal nie ma absolutnie żadnych
>> narzędzi gotowych do pisania algorytmami wysokiego poziomu.
>
> Przepraszam, co Ty smolisz?
> Pisalem w Pascalu na Odrze na _naprawde_/wylacznie wysokim poziomie.
>

Ja już przestałem komentować jego wywody bo to nie ma sensu.

Prawda jest taka że polityka Embarcadero sprawiła że Pascal jest do
tylu. Lazarus rozwija się zbyt wolno. Tak jak pisałem gdyby ktoś się
wziął z pełną energią za Lazarusa to on byłby dalej niż obecnie Delphi



Pozdrawiam

do góry

On Fri, 4 Oct 2019 16:40:43 +0200, J-23 wrote:

>>> To jest niestety dyskutowalne. Pascal nie ma absolutnie żadnych
>>> narzędzi gotowych do pisania algorytmami wysokiego poziomu.
>>
>> Przepraszam, co Ty smolisz?
>> Pisalem w Pascalu na Odrze na _naprawde_/wylacznie wysokim poziomie.
>>
>
> Ja już przestałem komentować jego wywody bo to nie ma sensu.
>
> Prawda jest taka że polityka Embarcadero sprawiła że Pascal jest do
> tylu. Lazarus rozwija się zbyt wolno. Tak jak pisałem gdyby ktoś się
> wziął z pełną energią za Lazarusa to on byłby dalej niż obecnie Delphi

Tylko po co skoro są języki i środowiska lepsze, kompletniejsze, bogatsze,
z większym community i sprawniejszym teamem deweloperskim?

I piszę to mimo, że na codzień w tym łajnie siedzę.

--
pozdrawiam
Roman Tyczka

do góry

On 04/10/2019 07:48, Maciej Sobczak wrote:
>> 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ą.

Wątek wyrasta głównie z tezy ze Pascal się nadaje lepiej niż inne.

Natomiast Ada to tylko taka mała mina na którą co chwile wchodzisz i
wybuchasz. Niezmiennie.

> Dopiero co dyskutowaliśmy tu o tym, ale można jeszcze raz.

Wiem, działa za każdym razem.

>> Całe szczęście Pascal nie jest.>
> Czym nie jest? Fajną furą? Użyteczny masowo?

Nie jest ani jednym ani drugim.

> Wybrany przez ESA do najnowszego projektu?

Jeszcze by tego brakowało.

> Znam natomiast nowy projekt z Adą, link powyżej.

Ja znam milion nowych w Verilogu. Też krytycznych, często bardziej niż
żelastwo w kosmosie. I wiesz co, wybrali tym razem język wyjątkowo
gówniany. Co robić, taki świat.

do góry

On 04/10/2019 07:51, Maciej Sobczak wrote:
> Nadal nie rozwiązałeś tego problemu.

Ten problem (czyli pomyłka mnożenia z dodawaniem) rozwiazuje każda
kolejna warstwa inżynierii programowania od co najmniej 50 lat. Od unit
testów, przez code review po testy integracyjne, wszędzie zostanie
wyłapana z dokładnością do asymptoty. Na 99% bug taki zostanie wyłapany
już w unit testach, przynajmniej u mnie i zaryzykuje że w każdym
poważniejszym programowaniu. Jeśli Ci się wydaje że o takie błedy chodzi
wybierając kilka kompilatorów to naprawdę postaraj się zakładać że
rozmówcy nie są idiotami i od razu będzie lepiej.

Kiedy już te i masę innych etapów weryfikacji przejdziezsz po drodze
ktos zapyta czy dajesz wiarę w kompilator. Prawdłowa odpowiedź brzmi:
zalezy od ryzyka. Istnieją ryzyka gdzie nie można zaufa kompilatorowi.
Nie da się też go zweryfikować formalnie. Choć można mocno wierzyć, ale
to raczej nie przejdzie podczas certyfikacji.

do góry

On 04/10/2019 08:16, AK wrote:
> Czy Ci sie to podoba czy nie, Ada jest jednak _najbezpieczniejszym_
> jezykiem programowania. O (kilka?)rzad wielkosci bezpieczniejszym
> od C/C++ czy nawet Pascala.

Nikt nie twierdzi inaczej.

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

I nikt jej tutaj nie stawia. Wskazuje jednak palcem że możesz sobie
wybrać dowolny język weryfikowalny po zęby i dalej mieć bugi. Co usilnie
religia Adowców próbuje wciskać do głów managerów to opinia jakoby
magicznie rozwiązują się wszelakie problemy inżynierii programowania i
weryfikacji kodu. Najwidoczniej wyjatkowo dobrze zadziałało to z
Ariane5. Wolałbym też aby na tej religii nie był projektowany respirator
którego może będę musiał kiedyś użyć.

do góry

On 04/10/2019 08:17, Maciej Sobczak wrote:
>>> 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"

"Skoro silnik do motorówki pracował na jeziorze to nie ma sensu
weryfikować czy się sprawdziw odrzutowcu bo pracował przecież dobrze".

Tak, weryfikowali jak widać.

"internal variable related to the horizontal velocity of the launcher
exceeding a limit which existed in the software of this computer."

No przecież w motorówce działało!

>> 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).

Czyli software nie jest gotowy na jakieśtam wskazania czujników i nie ma
ani grama zabezpieczenia przed tym kiedy te czujniki wariują. Bo
symulator przecież nie wariuje. Great job, dev!

>> 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"?

"Heniek, a programiści nie mają nic przeciwko żeby to wsadzić do
większej rakiety?"

"Eeee, nie, dwóch się zwolniło a ten trzeci w kiblu siedzi, więc
zakładamy że zadziała, przecież to Ada, co może pójść źle?".

>> 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?

Tego teamu nie ma zapewne. Po takiej przewrotce ludzie może i robią to
samo ale nie tak samo.

>> 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.

Przecież to tylko ironia. Ponadto i tak mam racje:

"The floating point number which was converted had a value greater than
what could be represented by a 16-bit signed integer."

> 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.
W dowolny. Jeśli reakcją rakiety jest detonacja bo czyjnik lub inny
element systemu zwrócił za dużą wartość (z powodu mechaniki czy błedu
systemu) to nie jest to dobra reakcja. Choć nie wykluczam że TAK BYŁO W
SPECYFIKACJI.

>> 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.

Zdrowy rozsądek nie miewa standardów niestety.

> 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.

Procedura awaryjna którą jest samozniszczenie. Fantastycznie. A
wystarczyło dodać ifa. Ale TAK BYŁO W SPECYFIKACJI ZEBY GO NIE DODAĆ
AKURAT W TEJ FUNKCJI CHOĆ WSZEDZIE INDZIEJ BYŁO.

>> A tu najzwyczajniej w "bezpiecznym języku"
>> odpierdolono byle jak.
> Gdzie w tym raporcie jest takie stwierdzenie?

Skoro funkcja pobiarająca dane z czunika lub innej częsci systemu nie
jest zabezpieczona przed randomizami na wejściu to jest to ODPIERDALANIE
i powie Ci to każdy programista embedded. Nie musisz mieć na to raportu
bo raporto nie służy do szukania przyczyn kolokwialnych a jedynie w
opisaniu przyczyn technicznych.

>> 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.

Jak widać trudniej nie znaczy że Heniek z Frankiem nie dali rady
odpierdniczyć byle jak, nawet język nie dał rady się obronić.

"The data conversion instructions (in Ada code) were not protected from
causing an Operand Error, although other conversions of comparable
variables in the same place in the code were protected."

"Ty, Heniek, to może tutaj nie będziemy robić tych ifów, na h. to komu a
rom się kończy...".

>> 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?

Nie było testu weryfikującego odczyt warości z poza zakresu. Czyli mniej
wiecej *PIERWSZY* test jaki robisz w celu znalezienia niepokrytych
stanów w jakimś fragmencie kodu.

>> A tutaj sobie jakiś misio wrzuca kod z jednego systemu do drugiego.
> 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.

Wiesz że może nawet się zgodzę. W systemach krytycznych 10x ważniejsze
jest testowanie kodu niż pisanie kodu. Może nawet 100x wazniejsze.
Dlatego rynek systemów krytycznych mniej wiecej w takiej proporcji
oferuje narzędzia weryfikacyjne vs narzędzia do pisania kodu.

> Przeczytaj ten raport.

Ale ja go czytałem. Kilka razy. Masz podejście religijne a ja
praktyczne. Ponadto ja tylko troluje. Najzwyczajniej w świecie spuszczam
powietrze z Ady, bo wiele więcej tam nie ma poza nudnym na wskroś
następnym językiem imperatywnym tyle że z dużą liczbą wyznawców.

Ada tak. Ale na rany koguta, z TESTOWANIEM.

do góry

On 04/10/2019 08:18, AK wrote:
>> To jest niestety dyskutowalne. Pascal nie ma absolutnie żadnych
>> narzędzi gotowych do pisania algorytmami wysokiego poziomu.
> Przepraszam, co Ty smolisz?

Znajdź w Paskalu mapę. Jakieś drzewo. Coś do grafów. Cokolwiek z kilku
pierwszych stron książki o algorytmach.

> Pisalem w Pascalu na Odrze na _naprawde_/wylacznie wysokim poziomie.

Nie wątpie. Wysoki poziom programowania zawsze uzyskuje się tylko w ASM.

do góry

On 04/10/2019 08:23, AK wrote:
>> 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.
> Zapewniam Ci ze w _kazdym_ jezyku biblioteki posiadaja wiele bugow
> (zwlaszcza w C/C++ - mam na to dowody - do Turbo C 2.0 musialem
> napisac - tak tak, w assemblerze, a jakze - _calą_ bibliotekę
> standardową, aby mozna bylo to C uzywac _w ogole_.

Zapewniam Cię że w każdym ręcznie wydziobdzianym algorytmie przez
domowego hackera znajdzie się ich o rzędy wielkości więcej błędów niż w
kodzie dostarczanym z kompilatorem (sprawdzić czy nie Borland i MS).

> To jednak nijak nie swiadczy o jezyku

Brak takowych gotowców świadczy o braku zastosowania języka do
czegokolwiek poważnego. No, może poza "edukacją" którą niektórzy
rozumieją jako naukę budowania domów poprzez kopanie rowów łopatą o
nazwie Pascal.

do góry