epsilon$ while read LINE; do echo \>"$LINE"; done < "Maciej Sobczak"
>> >Nie popadajmy w skrajność. Można być przyjaznym dla maszyny nie będąc
>> >jednocześnie aż tak niskopoziomowym.
>> Nie można. Każda forma niebędąca kodem maszynowym jest nieprzyjazna
>> i musi być tłumaczona na postać wynikową.
>Przyjazność dla maszyny to właśnie miara łatwości tego tłumaczenia.
>Niektóre języki są wysokopoziomowe zachowując jednocześnie prostotę i
>intuicyjność translacji. Zwłaszcza te imperatywne. Niestety o językach
>funkcjonalnych nie można tego powiedzieć.

OK. Każdy język jest nieprzyjazny. Jeden może bardziej, inny mniej, ale
to średnio dobry argument. Kwestia "dobroci" kompilatora.

>Kiedyś widziałem dość krótki artykuł, w którym autor zastanawiał się
>nad Haskellem. Była tam funkcja sortująca, bodajże quicksort w dwóch
>(!) linijkach. Zapis ścinał z nóg. Gorzej z wydajnością. Okazało się,
>że ten zajefajny zapis ma się nijak to tego, co się dzieje w pamięci i
>co robi CPU.

Trochę mi się przypomina argumentacja przeciwko programowaniu
obiektowemu podpierana tym, jak to pięknie można w asemblerze
przyoszczędzić kilkanaście bajtów.
W pewnych warunkach to faktycznie może mieć znaczenie. Ale w wielu
innych nie będzie miało takiego, jak to, że piszemy szybko i w miarę
bezbłędnie.

>> Nie róbmy na siłę kalki z angielskiego.
>Nie rób se jaj.

Nie robię sobie jaj. Lóknij przez łindoł na korner czy kar jeszcze stoi.

>Po pierwsze, w tej branży kalki to najlepsze co można
>zrobić, przynajmniej jest zgodnie ze wszystkimi innymi kalkami.

No właśnie niekoniecznie i nie zawsze.

>Po
>drugie, "funkcyjny", jak rozumiem, absolutnie żadną kalką nie jest,
>tak?

Owszem, nie jest.

>Niby w czym kalka "funkcyjny" jest lepsza od kalki
>"funkcjonalny"?

http://sjp.pwn.pl/slownik/2460400/funkcyjny_I
http://sjp.pwn.pl/slownik/2558726/funkcjonalny

>> >> Funkcjonalne języki, w przeciwieństwie do języków niefunkcjonalnych
>> >> (Brainf*ck anyone?) dają jednak jakieś możliwości.
>> >Jakie?
>> Skoro niektóre są funkcjonalne, to inne muszą być niefunkcjonalne.
>No sam widzisz, że nie bardzo jest co wymieniać.

Oczywiście, że jest. Choćby większość (wszystkie?) ezoteryczne są
niefunkcjonalne. Bo i nie po to były tworzone.

>> >Ponownie to samo pytanie: dlaczego nie wygrały tych zawodów o T1000?
>> >Może jednak nie dają tych możliwości, co wszyscy myślą, że dają?
>> Odpowiem pytaniem na pytanie - dlaczego w tym roku w F1 wygrał człowiek
>> z nazwiskiem zaczynającym się na "V"? Może jednak inne litery nie dają
>> takich możliwości?
>Słabe.

Owszem. Twoje pytanie było słabe. Nie dość, że usiłowałeś generalizować
z pojedynczego przypadku, to jeszcze usiłujesz przekształcić korelację
w implikację. Większe błędy logiczne ciężko byłoby popełnić.

>Powtórzę: języki funkcjonalne nie wnoszą niczego (w szczególności
>żadnego "paradygmatu"), co fundamentalnie przyczyniłoby się do
>efektywności w systemach współbieżnych, względem istniejących technik.

Ę? Jak nie, jak tak? Weźmy w szczególności ten haskell i quicksort
(i nie przypierniczaj mi się do wydajności konretnego kompilatora,
bo to rzecz wtórna).
#v+
quicksort [] = []
quicksort (s:xs) = quicksort [x|x <- xs,x < s] ++ [s] ++ quicksort [x|x <- xs,x >= s]

#v-
W sposób oczywisty widać, że kolejne wywołania rekurencyjne mają szansę w sposób
naturalny zostać zrównoleglone. Napisz to teraz w C pilnując ręcznie
wszystkiego, czego trzeba pilnować.

--
Kruk@ -\ |
}-> epsilon.eu.org |
http:// -/ |
|