On 2012-09-29 11:22, Marek Borowski wrote:
>> On 2012-09-28 22:39, Maciej Sobczak wrote:
> Wiesz co, wszytkie te twoje "argmumenty" przeciwko Adzie da sie
> zastosowac w dyskusji C vs. C++ przeciwko C++, gdzie przedstawiasz
> zupelnie odmienne stanowisko.

Przecież juz napisalem że troluje. Tylko że to trolowanie niestety nie
jest pozbawione podstaw. Z Adą jest jak ze wszystkimi idiotycznymi
religiami w programowaniu:

a) Ada jest bezpieczna
b) C jest szybszy od C++
c) Nie można napisać kernela w C++
d) C++ jest wydajniejszy od Javy
e) Objective-C jest objawieniem
f) Programowanie funkcyjne jest lepsze niż cała reszta
g) Programowanie obiektowe jest lepsze niż cała reszta
h) Pascal jest najlepszy do dydaktyki
i) Lisp jest jedynym rozwiązaniem każdego problemu
j) Kiedyś wszystko będzie w Prologu
k) Ucz się COBOLa bo warto
l) Na 8051 da się zrobić wszystko
m) Makra są lepsze od szablonów
n) Erlang jest najlepszy przy przetwarzaniu rownoległym

I cala masa innych kościołów za którymi, jak w każdej religii, nie ma
żadnych argumentów poza nadętymi hasłami z ktorych uchodzi powietrze
przy byle nakłuciu. Jak jakąs widzę - to zwalczam prywatną krucjatą.

> A jezyk uniwersalny musi udostepniac niskopoziomowe operacje.

Uniwersalny != bezpieczny.

do góry

Użytkownik "Marek Borowski" <m...@...borowski.com> napisał:

> A jezyk uniwersalny musi udostepniac niskopoziomowe operacje.

NIE !

AK

do góry

On 2012-09-29 11:45, Sebastian Biały wrote:
> On 2012-09-29 11:22, Marek Borowski wrote:
>>> On 2012-09-28 22:39, Maciej Sobczak wrote:
>> Wiesz co, wszytkie te twoje "argmumenty" przeciwko Adzie da sie
>> zastosowac w dyskusji C vs. C++ przeciwko C++, gdzie przedstawiasz
>> zupelnie odmienne stanowisko.
>
> Przecież juz napisalem że troluje. Tylko że to trolowanie niestety nie
> jest pozbawione podstaw. Z Adą jest jak ze wszystkimi idiotycznymi
> religiami w programowaniu:
>
> a) Ada jest bezpieczna
> b) C jest szybszy od C++
> c) Nie można napisać kernela w C++
> d) C++ jest wydajniejszy od Javy
> e) Objective-C jest objawieniem
> f) Programowanie funkcyjne jest lepsze niż cała reszta
> g) Programowanie obiektowe jest lepsze niż cała reszta
> h) Pascal jest najlepszy do dydaktyki
> i) Lisp jest jedynym rozwiązaniem każdego problemu
> j) Kiedyś wszystko będzie w Prologu
> k) Ucz się COBOLa bo warto
> l) Na 8051 da się zrobić wszystko
> m) Makra są lepsze od szablonów
> n) Erlang jest najlepszy przy przetwarzaniu rownoległym
>
> I cala masa innych kościołów za którymi, jak w każdej religii, nie ma
> żadnych argumentów poza nadętymi hasłami z ktorych uchodzi powietrze
> przy byle nakłuciu. Jak jakąs widzę - to zwalczam prywatną krucjatą.
>
Religie to chyba za duzo powiedziane. Jak dla mnie przedstawiles
stereotypy, ktore da sie obalic jednym kontrprzykladem (z uwagi na
kwantyfikator ogolny) ale te stereotypy nie wziely sie z powietrza.
I to jest temat na dluzsza dyskusje.

> > A jezyk uniwersalny musi udostepniac niskopoziomowe operacje.
>
> Uniwersalny != bezpieczny.
Oczywiscie. Tylko ze jak na razie programy same sie nie pisza i jezyk
IMO nie jest tu kluczowa sprawa.


Pozdrawiam

Marek

do góry

W dniu piątek, 28 września 2012 23:32:49 UTC+1 użytkownik Edek Pienkowski napisał:
> Dnia Fri, 28 Sep 2012 07:57:31 -0700, Roman W napisal:
>
> > W dniu piątek, 28 września 2012 13:03:41 UTC+1 użytkownik Edek
> > Pienkowski napisał:
> >> Z tego punktu widzenia nie tylko rozwiązania związane z zarządzaniem
> >> projektem, ale też techniczne mają wielki wpływ na powodzenie lub nie
> >> całości - tylko dlatego moim zdaniem warto dyskutować nad wyborem
> >> języka programowania.
>
> >> W idealnym świecie sferycznych programistów nie miałoby to większego
> >> znaczenia.
> >
> > Ale wybor jezyka jest zawsze konsekwencja panujacej kultury i podejscia
> > do kwestii bezpieczenstwa. W typowym banku "wybor jezyka" oznacza wybor
> > pomiedzy Java, C# i C++. Nikt nie bedzie sie wyglupial z propozycjami
> > typu Ada i uzasadnial ich wzgledami bezpieczenstwa, bo uslyszy, ze
> > marnuje czas grupy.
>
>
> Ze wszystkich osób nie podejrzewałem z tej strony wypowiedzi typu
> "wsyzscy znamy X, Y jest niepopularne, więc używamy X". Technologia
> nie jest konkursem popularności. To też jest częścią kultury, albo
> nie jest.

Wybierajac technologie, nie mozesz uciec od odpowiedzi na pytanie "a co sie stanie,
jezeli obecny zespol sie rozleci i bedziemy musieli znalezc nowych ludzi na ich
miejsce". Jezeli projekt jest robiony w C++ albo Javie, problemu raczej nie ma.
Jezeli jest robiony w Adzie albo Haskellu, to problem moze byc, i to spory. Przeciez
w sumie takie bylo uzasadnienie wyboru C++ jako jezyka programowania do F-35 przez
Lockheed-Martin. Wychodzac poza kwestie kadr, jezeli firma korzysta juz z jezyka X,
to latwiej jest kolejny projekt zrobic rowniez w X, zamiast laczyc pozniej dwa
jezyki. Taki mix&match czesto niesie ze soba spore, trudne do przewidzenia problemy.

Nie mowiac juz o tym, ze sami deweloperzy czasami niechetnie uczestnicza w projektach
korzystajacych z niepopularnych technologii, bo (slusznie lub nie) uwazaja, ze
oslabiaja swoja pozycje na rynku pracy.

No i na koncu: argumenty ktore przemawiaja do programisty nie musza przemawiac do
jego szefa, ktory moze nie miec bladego pojecia o roznicach pomiedzy C++ a Ada, poza
tym, ze "wszyscy na rynku uzywaja C++ a Ady prawie nikt", i to moze byc argument
decydujacy.

RW

do góry

W dniu sobota, 29 września 2012 09:29:10 UTC+1 użytkownik Edek Pienkowski napisał:
> Dnia Fri, 28 Sep 2012 15:19:19 -0700, Roman W napisal:
> > W dniu piątek, 28 września 2012 22:28:11 UTC+1 użytkownik Edek
> >> Dnia Fri, 28 Sep 2012 13:39:39 -0700, Maciej Sobczak napisal:
> >> > W dniu piątek, 28 września 2012 19:35:26 UTC+2 użytkownik Sebastian
> >> > Biały napisał:
> >> >
> >> >> > Zastanów się najpierw *po co* istnieją bezpieczne języki.
> >> >>
> >> >> Po to aby przeciwdziałać błedom programisty badź specyfikacji w jak
> >> >> nalepszym stopniu.
> >> >
> >> > No właśnie. Ze znanych mi języków Ada robi to lepiej, niż inni.
> >> Heh. Haskell?
> >
> > Haskell nie nadaje sie do zastosowan praktycznych, to jezyk akademicki.
> > Lazy evaluation powoduje, ze bardzo ciezko jest przewidziec, jak szybko
> > sie wykona i ile pamieci bedzie potrzebowal niewinnie wygladajacy
> > kawalek kodu.
>
>
> Są praktyczne zastosowania Haskella.

Wiem, sa, ale sa dosyc niszowe (patrz np. raport z zastosowania Haskella w Barclays
Capital, http://arbitrary.name/papers/fpf.pdf). NB w tym raporcie autorzy opisuja,
jak walczyli z duzymi problemami wydajnosciowymi w wydawaloby sie prostym kodzie.

> Co ciekawe, "niewinnie wyglądający
> kawałek kodu" to wrażenie subiektywne, jednym z pierwszych języków
> których się nauczyłem był Scheme - polecam każdemu programiście
> przejście choć jednego języka funkcyjnego i dowolny kod wygląda
> po tym inaczej.

Mialem na mysli to, ze wlasnie bardzo idiomatyczny kod funkcyjny w Haskellu potrafi
miec koszmarne charakterystyki wydajnosciowe, a kiedy go sie przepisze tak zeby mial
rozsadna wydajnosc, ta slynna prostota i klarownosc Haskella ida w cholere (zamiast
nich pojawiaja sie "bang patterns", operatory "seq" i inne takie cuda). Dodatkowo,
poniewaz Haskell jest tak wysokopoziomowy, ciezko jest patrzac na kod zrozumiec,
czemu sie dlugo wykonuje. Profiler jest wlasciwie niezbedny.

RW

do góry

W dniu piątek, 28 września 2012 23:28:11 UTC+2 użytkownik Edek Pienkowski napisał:

> Czy da się zasymulować w Google zawijanie linii do usenotwego 70
> char perline? Ja tak tylko pytam.

Chyba musisz zapytać w Googlu. Ja nie wiem, ale skoro w tym interfejsie nie da się
zrobić nawet cross-posta (da się? jak?), to nie wymagaj zbyt wiele.

> > No właśnie. Ze znanych mi języków Ada robi to lepiej, niż inni.
>
> Heh. Haskell?

Ada robi to lepiej również przez to, że da się napisać (i bywa, że tak się robi)
program z tzw. zero-runtime. Taki zerowy runtime ma tą zaletę, że ma mało bugów,
dosyć szybko się też wykonuje.

Wydaje mi się, że Haskell gra w innej lidze.

> > Czy hasło "system czasu
>
> > rzeczywistego" coś Ci mówi?
>
> Mi mówi, i polega na czym innym. Na nie wykonywaniu potencjalnie
> kosztownych operacji w wątkach realtime, tylko w wątkach nie-realtime.

Decyzje dotyczące sterowania są na ścieżce krytycznej. Wywalenie ich do innego wątku
nic nie da.

> Przewidywanie czasy wykonania nie jest magią. Przynajmniej od 1 roku
> studiów.

Znam firmę, która robi biznes na tzw. on-target time analysis, czyli badaniem czasu
wykonania przez... pomiar. Bo jednak nie wszystko było na 1 roku.

Poza tym - z tego co rozumiem, to ci goście po 1 roku przewidzieli i uznali, że
trzeba wyłączyć bezpiecznik.

> Mało wiesz o statycznej analizie. I o projektach typu Arianne. Po
> pierwsze, stosuje się rozwiązania typu "mamy 3 implementacje i porównujemy
> wyniki"

Doczytaj. Nie było tego w Ariane 5.

> Chyba nigdy nie pracowałeś w zorganizowanym projekcie o dużych wymaganiach
> niezawodności.

Pudło.

[...]
[o możliwości napisania klasy w C++, która zrobi to lepiej:]

> Prosto jak to tylko możliwe: powyższe daje się zapewnić
> mając jednego świadomego reviewera na 20 wytresowanych małp tudzież
> specjalistów od innych rzeczy niż programowanie. Czyli jest trywialne.

Przeanalizujmy:

W Ariane 5 świadomy reviewer:

1. nie było go - więc Twoje rozważania o ewentualnej trywialności jego pracy się nie
stosują

2. był, i:

2.a. nie wiedział o wyłączeniu bezpiecznika, więc o obejściu "bezpiecznej" klasy w
C++ też by nie wiedział

2.b. wiedział o wyłączeniu bezpiecznika, i:

2.b.I. nie zgodził się, ale został olany - został by tak samo olany w przypadku
niezgody na obejście klasy w C++, więc nie masz racji

2.b.II. zgodził się - zgodziłby się też na obejście "bezpiecznej" klasy w C++, więc
nie masz racji.


W skrócie: reviewer nie pomógł w przypadku Ariane 5, więc nie pomógłby też gdyby to
napisano w C++ - z tych samych powodów. Czyli to nie jest trywialne.


> J.w., automatyka na poziomie przemysłowym jest dobrze przećwiczona.

Nawet dzisiaj nie jest. A mówimy o projekcie sprzed ok. 20 lat i to takim, gdzie
przez dodatkowe wyśrubowane wymagania (np. dotyczące odporności na promieniowanie,
drgania, zakres temperatur, itd.) odpada nam z rozważań większość dostępnej oferty
rynkowej. Najwyraźniej był jakiś powód, dla którego ten program napisano.


> Nie rozumiem ironii, ale nikt nie odrzuca Ady. Problem jest zupełnie
>
> gdzie indziej: Ada nic więcej nie daje.

Daje, bo pozwala łatwiej wykryć pewne klasy błędów, które w C lub C++ wykrywa się
trudniej.

> a po drugie ci goście nie
> są "aż tak głupi" jak zakładasz.

Przecież to nie ja nazywam tu ludzi idiotami.

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

do góry

W dniu sobota, 29 września 2012 07:52:23 UTC+2 użytkownik Sebastian Biały napisał:

> > Czy hasło "system czasu rzeczywistego" coś Ci mówi?
>
> Więcej niż myslisz.

Ja nic nie myślę, trzymam się tylko tego, co piszesz.

> I musze przyznać, że gdyby software ariane był
> "wyżyłowany co do cykla" to programiści nie powinni się zajmowac więcej
> programowaniem.

Jakieś podstawy do tego swierdzenia? Bo ja wiem, że systemy latające bywają
specyfikowane blisko kreski. To jest kompromis pomiędzy tym, co ma być a tym, co jest
dostępne i w danych ograniczeniach możliwe do zrealizowania. Analizę WCET robi się z
jakiegoś konkretnego powodu a nie dla zabawy.

> Jeśli więc wymagana jest szybkośc to musisz pozegnać bezpieczeństwo.

Albo nie. Najgorzej, jeśli mamy złą specyfikację - wtedy możemy napisać system, o
którym "wiemy", że będzie działał dobrze i będzie też działał szybko, ale przez jego
użycie niezgodnie z założeniami wychodzi dupa. 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.

> > Drugorzędny? Duperelek? I w czym ten duperelek jest napisany, co?
>
> W czymś *prostym* co pozwoli na formalną weryfikacje.

Np. w Adzie? Ten język powstał z myślą o ułatwieniu formalnej weryfikacji, chociażby
przez minimalizację aliasingu, którego w C jest po sufit.

> > Natomiast chamskie sztuczki w C++ *zawsze* są możliwe, bo do dyzpozycji
> > są wskaźniki i reinterpret_cast (oraz memcpy, itd.).
>
> Zupełnie jak w Adzie? Czekaj czekaj czy Ada jest nadzbiorem C++ w sensie
> niskopoziomowego gówna? OMG!

Nadzbiorem nie, bo się nie da. memcpy na dowolnych argumentach to już jest nadzbiór,
bo każdy shit można tym zrealizować. W Adzie też to jest dostępne, ale trudno to
nazwać nadzbiorem.

Lepszość Ady polega na tym, że o ten shit trzeba prosić, natomiast w C trzeba prosić,
żeby shitu nie było.

> > W obu przypadkach ominięcie bezpiecznika można uznać za chamskie.
>
> I możliwe. Game over.

Ja też myślę, że powinniśmy zmierzać do końca tej dyskusji.


> To oznacza że Ada pozwala na to samo co ASM.

Tak. Ten język powstał również po to, żeby dało się w nim pisać systemy operacyjne.

> Niczego nie odrzucam.

Przepraszam, musiałem Cię z kimś pomylić.

> Prawda jest taka że nie posiadamy *żadnego*
> bezpiecznego języka

Jeżeli to pojęcie traktujesz tak jak np. "bezpieczny samochód", to nie posiadamy i
nie będziemy posiadać. Niemniej, języki i samochody można porównywać względem ich
poziomu bezpieczeństwa i tak, przykładowo, Volvo jest bezpieczniejsze od Fiata.
Podobnie, przykładowo, Ada jest bezpieczniejsza od C++. Nie ma w tym żadnej religii,
to są zupełnie racjonalne obserwacje.

Możesz sobie prowadzić swoją krucjatę, ale poza trollowaniem, do którego się
przyznałeś, nie bardzo rozumiem, jaki jest jej cel.

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

do góry

Dnia Sun, 30 Sep 2012 14:32:48 -0700, Maciej Sobczak napisal:

> W dniu piątek, 28 września 2012 23:28:11 UTC+2 użytkownik Edek Pienkowski napisał:


>> > Czy hasło "system czasu
>>
>> > rzeczywistego" coś Ci mówi?
>>
>> Mi mówi, i polega na czym innym. Na nie wykonywaniu potencjalnie
>> kosztownych operacji w wątkach realtime, tylko w wątkach nie-realtime.
>
> Decyzje dotyczące sterowania są na ścieżce krytycznej. Wywalenie ich do
> innego wątku nic nie da.

Udawanie, że są realtime podczas gdy nie są też nic nie da.

>> Chyba nigdy nie pracowałeś w zorganizowanym projekcie o dużych
>> wymaganiach niezawodności.
>
> Pudło.
>
> [...]
> [o możliwości napisania klasy w C++, która zrobi to lepiej:]
>
>> Prosto jak to tylko możliwe: powyższe daje się zapewnić mając jednego
>> świadomego reviewera na 20 wytresowanych małp tudzież specjalistów od
>> innych rzeczy niż programowanie. Czyli jest trywialne.
>
> Przeanalizujmy:
>
> W Ariane 5 świadomy reviewer:
>
> 1. nie było go - więc Twoje rozważania o ewentualnej trywialności jego
> pracy się nie stosują
>
> 2. był, i:
>
> 2.a. nie wiedział o wyłączeniu bezpiecznika, więc o obejściu
> "bezpiecznej" klasy w C++ też by nie wiedział
>
> 2.b. wiedział o wyłączeniu bezpiecznika, i:
>
> 2.b.I. nie zgodził się, ale został olany - został by tak samo olany w
> przypadku niezgody na obejście klasy w C++, więc nie masz racji
>
> 2.b.II. zgodził się - zgodziłby się też na obejście "bezpiecznej" klasy
> w C++, więc nie masz racji.
>
>
> W skrócie: reviewer nie pomógł w przypadku Ariane 5, więc nie pomógłby
> też gdyby to napisano w C++ - z tych samych powodów. Czyli to nie jest
> trywialne.

Kwestia kultury organizacyjnej. Z mojego doświadczenia polega to na tym,
że jeżeli są pisane lub niepisane reguły, że jakiegoś _cast się nie używa,
a ktoś użyje, to reviewer to zauważy. Próba olania reviewera skończyłaby
się dyskusją angażującą kilkanaście osób w tym architektów, autorów
reguły i menago stopień lub dwa poniżej CTO i te osoby trzeba by przekonać,
że ten _cast jest konieczny, więc nikt bez dobrego uzasadnienia nie
będzie "olewał" reviewera. Skutkiem czego nikt takich rzeczy nie robi.

Choć faktem jest, że zdarzyło mi się pracować w projekcie o strukturze
organizacyjnej typu Kononowicz czyli przypominała amorficzny blob,
ale nikt takiej firmie nie da nic poważnego do wykonania i dyskusję
na temat języka oczywiście można zawsze przeprowadzić, ale przy
filozofii "i nie będzie nic" skutków i tak to nie zmieni.

>> J.w., automatyka na poziomie przemysłowym jest dobrze przećwiczona.
>
> Nawet dzisiaj nie jest. A mówimy o projekcie sprzed ok. 20 lat i to
> takim, gdzie przez dodatkowe wyśrubowane wymagania (np. dotyczące
> odporności na promieniowanie, drgania, zakres temperatur, itd.) odpada
> nam z rozważań większość dostępnej oferty rynkowej. Najwyraźniej był
> jakiś powód, dla którego ten program napisano.

Nie oceniaj projektu kosmicznego 20 lat temu stosując wiedzę z naszego
kochanego postkomunistycznego kraju z 2012. Jesteśmy wciąż 10-20 lat
do tyłu w tym porównaniu, chociaż potrafimy użyć smartfona do znalezienia
bankomatu. Z mojej wiedzy dzisiaj robimy czasami elementy satelitów,
ale albo są to prototypy albo produkty finalne o dość prostych funkcjach.
Z pierwszej ręki informacje.

>> Nie rozumiem ironii, ale nikt nie odrzuca Ady. Problem jest zupełnie
>>
>> gdzie indziej: Ada nic więcej nie daje.
>
> Daje, bo pozwala łatwiej wykryć pewne klasy błędów, które w C lub C++
> wykrywa się trudniej.

Daje, ale tylko porównując język do języka, a nie porównując, co
w tych językach można zrobić.

>> a po drugie ci goście nie są "aż tak głupi" jak zakładasz.
>
> Przecież to nie ja nazywam tu ludzi idiotami.

Przyzwyczaiłem się że ten zwrot "aż tak głupi" oznacza tyle,
że ktoś zadaje proste pytania z prostymi odpowiedziami, podczas
gdy dyskusja jest o problemach bardziej złożonych. Nic ponad to,
nie wiem kto kogo tutaj wyzywa od idiotów.

--
Edek

do góry

Dnia Mon, 01 Oct 2012 08:04:51 +0000, Edek Pienkowski napisal:

> Dnia Sun, 30 Sep 2012 14:32:48 -0700, Maciej Sobczak napisal:
>
>> W dniu piątek, 28 września 2012 23:28:11 UTC+2 użytkownik Edek Pienkowski napisał:

>> Nawet dzisiaj nie jest. A mówimy o projekcie sprzed ok. 20 lat i to
>> takim, gdzie przez dodatkowe wyśrubowane wymagania (np. dotyczące
>> odporności na promieniowanie, drgania, zakres temperatur, itd.) odpada
>> nam z rozważań większość dostępnej oferty rynkowej. Najwyraźniej był
>> jakiś powód, dla którego ten program napisano.
>
> Nie oceniaj projektu kosmicznego 20 lat temu stosując wiedzę z naszego
> kochanego postkomunistycznego kraju z 2012. Jesteśmy wciąż 10-20 lat
> do tyłu w tym porównaniu, chociaż potrafimy użyć smartfona do znalezienia
> bankomatu. Z mojej wiedzy dzisiaj robimy czasami elementy satelitów,
> ale albo są to prototypy albo produkty finalne o dość prostych funkcjach.
> Z pierwszej ręki informacje.

Rozwinę...

Jesteśmy do tyłu:

1. Organizacyjnie przede wszystkim. Ja mam swoje życiowe doświadczenie
z różnych projektów w różnych krajach, i jak słyszę określenia typu
"reviewera można olać" wiem że jestem w Polsce. Nie dlatego, że
w innych krajach nie istnieją kretyni [2], ale tam oni żyją wśród sobie podobnych
i rozsądne projekty są rozsądne. Ocenianie projektu kosmicznego
miarami do których na własnym podwórku jesteśmy przyzwyczajeni
mija się z celem.

2. Pod względem wykształcenia. Wbrew obiegowej opinii, że zachodnie
szkoły nie są na naszym poziomie - co bierze się stąd, że część
naszego curriculum tam się pomija jako zbędne - one są na wyższym
poziomie (WMSO [1]). Dyskusje typu "elementy sprzętu kosmicznego
wymagają odporności na promieniowanie" zdarzają się może na poziomie
liceum, ale tego typu odkrywanie ameryki w konserwie dzieci mają
za sobą dość wcześnie.

3. Pod względem doświadczenia. Mamy bagaż postkomunistyczny,
nie nasza wina, ale trzeba być tego świadomym. Możemy mieć genialną
myśl techniczną, ale jesteśmy lamerami pod względem wykonania,
ze względów organizacyjnych, kultury technicznej, wykształcenia,
braku sprzętu dzisiaj i w przeszłości, opieraniu się na pomysłach,
które realizuje kto inny itd. itp.

4. Pod względem kultury, mam na myśli techniczną, pracy w organizacji,
kulturę dyskusji. Nie chcę za bardzo się rozwijać, bo to moje
subiektywne wrażenie - nie wiem co zaobserwowałem "bo jestem
Polakiem", a które są moimi osobistymi przypadłościami. Powiem
tyle: są kraje, które mają nie 20 lat historii rozwoju przemysłu,
demokracji i wolnego społeczeństwa, a setki lat podczas których
następował rozwój. Sad but true.

Ostatecznie, z 15 lat temu miałem szybszy internet niż mam dzisiaj,
tylko dlatego, że byłem w innym miejscu a nie tylko w innym czasie.
Globalna wioska globalną wioską, ale siedząc we własnym grajdołku
nie widzi się reszty świata tak, jak uczestnicząc w nim.

[1] W Mojej Sprawdzonej Opinii ;)
[2] Nikogo nie wyzywam. W niektórych kulturach to, co u
nas jest na porządku dziennym jest kretyństwem. U nas niekoniecznie,
różnice kulturowe i takie tam...

PS. Nie chcę rozwalać dyskusji na tematy kosmiczne, dzielę
się tylko spostrzeżeniami.
--
Edek

do góry

On 2012-09-30 23:52, Maciej Sobczak wrote:
>> I musze przyznać, że gdyby software ariane był
>> "wyżyłowany co do cykla" to programiści nie powinni się zajmowac więcej
>> programowaniem.
> Jakieś podstawy do tego swierdzenia?

Doświadczenie. W systemie który "akurat" zmieścił się w 64kB ROM albo
*akurat* zmieścił się w 100% czasu przerwania są jakieś kompromisy.
Najczęściej dotyczące bezpieczeństwa własnie ("a, nie sprawdzaj tego
indeksu, na pewno nie będzie > 10 a 7 cykli do przodu").

> Bo ja wiem, że systemy latające bywają specyfikowane blisko kreski.

Blisko kreski (a w zasadzie za) był np. Apollo z AGC. Tylko dzięki temu
że ktoś znał na pamięc cały kod dali radę.

> To jest kompromis pomiędzy tym, co ma być a tym, co jest dostępne

To jest prawda w projektach budżetowych typu chiński sterownik do pieca.
W projektach takich jak rocket-science nie ma racji bytu, zawsze możesz
wziąść wiekszy, wziąść dwa itd. Nie ma większego? To masz zły hardware.

> i w danych ograniczeniach możliwe do zrealizowania.
> Analizę WCET robi się z jakiegoś konkretnego powodu a nie dla zabawy.

"
- Proszę pana, proszę pana, bo mi się tu napisało 17us kodu, to co robimy?
- Rżniemy bezpieczeństwo, przecież analitycy wyliczyli że wejdzie do
16us a hardware gotowy i nie można zmieniać!
"

>> Jeśli więc wymagana jest szybkośc to musisz pozegnać bezpieczeństwo.
> Albo nie. Najgorzej, jeśli mamy złą specyfikację
> - wtedy możemy napisać system, o którym "wiemy"
>, że będzie działał dobrze i będzie też działał szybko
>, ale przez jego użycie niezgodnie z założeniami wychodzi dupa.

> 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ę. Ten kawalek kodu nie miał prawa wejść w jakikolwiek
komputer sterujący rowerem bo jest niebezpieczny. Bajanie o tym że jakiś
tam parametr jakimś cudem mieścił się zazwyczaj w granicy jest
niebezpieczne i charakterystyczne dla "optymalizatorów w asm".

>>> Drugorzędny? Duperelek? I w czym ten duperelek jest napisany, co?
>> W czymś *prostym* co pozwoli na formalną weryfikacje.
> Np. w Adzie? Ten język powstał z myślą o ułatwieniu formalnej weryfikacji
>, chociażby przez minimalizację aliasingu, którego w C jest po sufit.

I ta formalna weryfikacja i jej myśl zmaterializowała się?

>>> Natomiast chamskie sztuczki w C++ *zawsze* są możliwe, bo do dyzpozycji
>>> są wskaźniki i reinterpret_cast (oraz memcpy, itd.).
>> Zupełnie jak w Adzie? Czekaj czekaj czy Ada jest nadzbiorem C++ w sensie
>> niskopoziomowego gówna? OMG!
> Nadzbiorem nie, bo się nie da.
> memcpy na dowolnych argumentach to już jest nadzbiór
>, bo każdy shit można tym zrealizować.
> W Adzie też to jest dostępne, ale trudno to nazwać nadzbiorem.

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.

> Lepszość Ady polega na tym, że o ten shit trzeba prosić
>, natomiast w C trzeba prosić, żeby shitu nie było.

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

>>> W obu przypadkach ominięcie bezpiecznika można uznać za chamskie.
>> I możliwe. Game over.
> Ja też myślę, że powinniśmy zmierzać do końca tej dyskusji.

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

>> To oznacza że Ada pozwala na to samo co ASM.
> Tak. Ten język powstał również po to, żeby dało się w nim pisać systemy operacyjne.

A po co ? Nie można zrobić bezpiecznego języka do systemów nawigacji w
ktorym 2+2 nie musisz implementować na bitach i recznym testowaniem
overflow?

do góry