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

Ale może Haskell się nie nadaje.

>> > rzeczywistego świata, takie jak np. upływ czasu. 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.
>
> A watki realtime beda grzecznie czekaly, az ten "kosztowny" skonczy
> obliczenia? Wrog ktory usiluje zestrzelic Twoj samolot, tez grzecznie
> poczeka, az skonczysz obliczenia w watku nie-realtime?

A jak policzyć coś zajmującego potencjalnie 10s w 0,1s? W RTOS jest
jasny podział, nie przeskoczy się kwestii czasu natomiast wiadomo,
co ile zabiera i jakie ma inne właściwości.

>> 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" - jeżeli dwa dają te same wyniki, engage. Po
>> drugie, istnieje
>
> Przeciez nie przetestujesz wszystkich kombinacji inputow, jakei moga sie
> przytrafic podczas lotu rakiety kosmicznej.

Inputy mają często nieskończenie wiele możliwości, ale są zbiorem.
Matematycznie daje się stwierdzić, czy jakiś inwariant lub dzielenie
przez zero zajdzie czy nie - geometrycznie szukając przecięć wynikających
z reprezentacji kodu we wszystkich miejscach. Nawet mając nieskończony
zbiór często daje się przewidzieć, że naruszenie inwariantu nie nastąpi,
albo nastąpi w jasno określonym matematycznie przypadku. Przynajmniej
dzisiaj to wiadomo, w oparciu głównie o programowanie liniowe, na podobnej
zasadzie jak jedna z metod optymalizacji pętli w gcc, gdy nie da
się przewidzieć ilości pętli i podobnych zmiennych, ale zna się ich
zależności.

--
Edek