epsilon$ while read LINE; do echo \>"$LINE"; done < "Maciej Sobczak"
>BTW - Tak totalnie rozpieprzonych literek jeszcze nie widziałem. Czego
>używasz do pisania?

Hmm... U mnie jest iso, w nagłówkach jest iso. Znowu gógle sobie nie
radzą?

>> OK. Ka�dy j�zyk jest nieprzyjazny. Jeden mo�e bardziej, inny mniej, ale
>> to �rednio dobry argument. Kwestia "dobroci" kompilatora.
>Doświadczenia ostatnich 50 lat pokazują, że "dobroć kompilatora"
>łatwiej uzyskać przy językach imperatywnych.

Owszem. Najłatwiej przy asemblerze. Chyba tę argumentację już
przerabialiśmy.

>> >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.
>Tu nie chodziło o kilkanaście bajtów, tylko w ogóle o sens stosowania
>tego w praktyce. O kilkanaście bajtów nikt by się nie spinał.
>
>Komputery mają swoją fizyczność i idące z nią ograniczenia. Jeśli je
>zignorujesz, to ograniczysz się do eksploracyjnej niszy.

Oczywiście, że mają. Trick polega na tym, że często łatwiej
(w szczególności - taniej) dołożyć pamięci, czy nawet postawić obok
drugi serwer, niż inwestować w kolejnego programistę.

>> >> 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.
>Słabe.
>
>komputer, kompilator, programowanie, procedura, funkcja, ...
>
>Mamy jeszcze kalki z francuskiego, np. klawiatura.
>
>To są słowa, których używasz na codzień i które są stosowane w
>literaturze fachowej, czyli są powszechnie uznane w środowisku
>profesjonalnym.
>Twój przykład z karem na kornerze tu nie pasuje i pokazuje tylko, że
>nie masz się czego złapać.

Oczywiście, że pasuje. W przeciwieństwie do "komputera", dla którego nie
było żadnej sensownej alternatywy ("maszyna licząca"? nie żartuj), do
"języka funkcjonalnego" jest sensowny termin.
Podobnym przykładem niedbalstwa językowego jest strasznie ostatnio
często pojawiająca się "autentykacja".

>> >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.
>Ale masz problem z uzasadnieniem tej tezy.

Wiesz, czym innym jest zapożyczenie przy braku własnego słowa, a czym
innym jest bezmyślna kalka. (po raz kolejny przypomnę "technologię",
która się tak rozpleniła, że żal.pl).

>> >Po
>> >drugie, "funkcyjny", jak rozumiem, absolutnie �adn� kalk� nie jest,
>> >tak?
>> Owszem, nie jest.
>Bo jest to stare, rdzennie polskie słowo?

Wiesz, zaraz dojdziemy do wniosku, że żadne słowo nie jest rdzennie
polskie. Udajesz, czy naprawdę nie rozumiesz?

>> >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
>Słabe. To jest słownik PWN, któro to wydawnictwo równocześnie wydaje
>książki mające "analiza funkcjonalna" w tytule. Znaczy - PWN ma
>*niekompletny* słownik. Niekompletny do tego stopnia, że nawet
>własnych tytułów książek nie obejmują.

Niestety, "analiza funkcjonalna" się przyjęła. Chociaż tu akurat nie ma
dwuznaczności. Nie jestem sobie w stanie wyobrazić co miałby oznaczać
przymiot funkcjonalności w odniesieniu do analizy. Natomiast język jak
najbardziej może być funkcjonalny (np. C), lub niefunkcjonalny (np.
Brainf*ck).

>Znajdź coś lepszego.
>
>(hint: jak poszukasz na grupach, to zobaczysz, że tą dyskusję już
>przerabiałem z dokładnie tymi samymi słabymi argumentami (nawet
>argument o PWN był) - spróbuj znaleźć coś, czego jeszcze nie było, bo
>trochę szkoda wszystko powtarzać; w każdym razie poprzednie dyskusje
>nie doprowadziły do żadnego wniosku, więc ta też nie doprowadzi)

Oczywiście. Przecież jeżeli argument nie jest Twój, to jest słaby
z definicji. Znasz takie powiedzenie o trzech osobach mówiących, że
jesteś pijany?

>> >> >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�.
>Podałem jakiś data point. Możesz argumentować, że ten jeden data point
>jest statystycznie nieistotny, ale jak wtedy nazwać całkowity brak
>jakichkolwiek przykładów z Twojej strony?

Wiesz, ja tu na razie nie argumentowałem, tylko czepiałem się
nieistotności Twojego "argumentu".

>> #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.
>Tak. Ale jest jeszcze przekazywanie i składanie wyników. Co
>konkretnie, czyli na poziomie implementacyjnym, robi ten "++"?

Czyli przenosisz dyskusję na jakieś zupełne manowce. "Nie da się tego
zrobić, bo konkretna implementacja jest do dupy".

>To jest
>właśnie problem wynikający z zignorowania tego co się dzieje w pamięci
>i właśnie o tym był ten artykuł. Nie da się pisać wydajnych programów
>skupiając się wyłącznie na jednym aspekcie takim jak równoległość.

A królowa Bona wciąż nie żyje.

>Nie pokazuj mi teoretycznych dwulinijkowych przykładów, na których "w
>sposób oczywisty widać". Pokaż mi *realny* system, który dzięki temu
>był szybszy.
>
>Ja pokazałem *realny* system, który był szybszy w języku imperatywnym.

Pięknie usiłujesz przejść na zupełnie inne kryterium. Problem polega na
tym, że często "szybkość" nie jest najistotniejszym kryterium. Często
wystarczy, żeby rozwiązanie było "wystarczająco dobre". Wtedy istotnymi
kryteriami są takie, jak cena, czy łatwość utrzymania.
Po raz kolejny powtórzę - powtarzasz argumenty, jak miłośnicy C ze
wstawkami w asemblerze jakieś 10-15 lat temu.

--
\.\.\.\.\.\.\.\.\.\.\.\.\.\
.\....@e...eu.org.\.\.
\.http://epsilon.eu.org/\.\
.\.\.\.\.\.\.\.\.\.\.\.\.\.