epsilon$ while read LINE; do echo \>"$LINE"; done < "Wojciech Jaczewski"
>> Czy ja gdzieś pisałem, że nigdy nie należy optymalizować? Owszem, jeśli
>> ktoś wszystko sortuje bąbelkowo, bo inaczej nie umie i nie jest w stanie
>> zrozumieć, że można inaczej, zapewnie w życiu nie napisze kawałka
>> dobrego kodu. Tego oczywiście nie neguję. Ale już zastanawianie się nad
>> kolejnością porównań żeby zyskać kilka procent szybkości przy sortowaniu
>> kosztem zaciemnienia kodu będzie miało sens tylko w pewnych konkretnych
>> przypadkach.
>Akurat sortowanie nie jest chyba dobrym przykładem, bo mało kto rezygnuje ze
>skorzystania z funkcji bibliotecznej. Zwykle te niewydajne rozwiązania
>powstają dla mniej książkowych problemów.

To był tylko przykład mający pokazać jak faktycznie można coś spaprać.

>>>To że często nie opłaca się walczyć o 20% wydajności to się zgadzam.
>> Ano właśnie.
>I tu jest właśnie ciekawostka... Rzeczywistość pokazuje nam oprócz programów
>szybkich, oraz niezłych ale nie optymalizowanych intensywnie (czyli
>wolniejszych o np. kilkadziesiąt procent), także wiele programów
>beznadziejnie powolnych. Natomiast przy okazji prawie każdej dyskusji na
>temat praktyki robienia powolnych programów ich obrońcy mówią o 1-5-10-15% o
>które nie warto walczyć.
>Jakby podyskutować na temat wydajności takiej np. Javy z jakimś jej
>miłośnikiem, też zazwyczaj zacznie wywody o tanim sprzęcie i o tym że nie
>opłaca się walczyć o każdy procent wydajności - gdy tymczasem każdy nie-
>zaślepiony miłością do tego języka widzi, że w rzeczywistych programach
>różnice wydajności są kilkukrotne, a nie rzędu pojedynczych procentów.
>
>Ja staram się po prostu uzupełnić dyskusję na temat wydajności o przypadki o
>których zazwyczaj się przy takiej okazji nie wspomina.

Ba. Ale czasem nawet kilkukrotna różnica jest nieistotna. Zwłaszcza, jak
program i tak większość czasu spędza na I/O, na ten przykład.
Albo, jak już pisałem, jak jest to program uruchamiany raz na rzadko
i istotniejsze jest żeby było dobrze widać co się w nim dzieje.

--
d'`'`'`'`'`'`'`'`'`'`'`'`'Yb
`b K...@e...eu.org d'
d' http://epsilon.eu.org/ Yb
`b,-,.,-,.,-,.,-,.,-,.,-,.d'

do góry

On Tue, 21 Dec 2010 20:04:53 +0100, Wojciech Jaczewski
<w...@o...pl> wrote:

>Mariusz Kruk wrote:
>
>> Czy ja gdzieś pisałem, że nigdy nie należy optymalizować? Owszem, jeśli
>> ktoś wszystko sortuje bąbelkowo, bo inaczej nie umie i nie jest w stanie
>> zrozumieć, że można inaczej, zapewnie w życiu nie napisze kawałka
>> dobrego kodu. Tego oczywiście nie neguję. Ale już zastanawianie się nad
>> kolejnością porównań żeby zyskać kilka procent szybkości przy sortowaniu
>> kosztem zaciemnienia kodu będzie miało sens tylko w pewnych konkretnych
>> przypadkach.
>
>Akurat sortowanie nie jest chyba dobrym przykładem, bo mało kto rezygnuje ze
>skorzystania z funkcji bibliotecznej. Zwykle te niewydajne rozwiązania
>powstają dla mniej książkowych problemów.
>
>>>To że często nie opłaca się walczyć o 20% wydajności to się zgadzam.
>>
>> Ano właśnie.
>
>I tu jest właśnie ciekawostka... Rzeczywistość pokazuje nam oprócz programów
>szybkich, oraz niezłych ale nie optymalizowanych intensywnie (czyli
>wolniejszych o np. kilkadziesiąt procent), także wiele programów
>beznadziejnie powolnych. Natomiast przy okazji prawie każdej dyskusji na
>temat praktyki robienia powolnych programów ich obrońcy mówią o 1-5-10-15% o
>które nie warto walczyć.
>Jakby podyskutować na temat wydajności takiej np. Javy z jakimś jej
>miłośnikiem, też zazwyczaj zacznie wywody o tanim sprzęcie i o tym że nie
>opłaca się walczyć o każdy procent wydajności - gdy tymczasem każdy nie-
>zaślepiony miłością do tego języka widzi, że w rzeczywistych programach
>różnice wydajności są kilkukrotne, a nie rzędu pojedynczych procentów.

Roznice miedzy czym a czym?... I dlaczego?

kazdy program powinien byc optymalizowany, bo nei ma powodow zby byl
wolny gdy moze byc szybki. Ale przypomneic nelazy stare prawa
Kernighana:

1. Make it working, make it nice later. Czyli ze nie nalezy zbyt wiele
uwagi posiecac optymalizacji na samym poczatku pracy - z wyjatkiem
pzremyslanych decyzji na temat wlasciwych algorytmow i struktur
danych. Liniowe ppzreszukiwania w tablicy zawierajacej milion liczb
jest OK jezeli sie to robi tylko raz, nei jest OK jezeli sie robi
tysiace razy

2. 20% kodu pochlaniania 80% czasu. Trzeba tylko te 20% znalezc,
zoptymalizowac i znalezc nastepne 20% (prawo 80/20). I tak w kolko.
Knuth nawet twierdzi (twierdzil) ze to jest 5/95

Innymi slowy, optymalizacja musi sie odbywac wedle pewnej strategii.

Moje obserwacja mlodych "pistoletow" programistycznych oraz
przesluchiwanie ic hna interview pokazuja ze nei maja oni pojecia o
zlozonosci obliczeniowej algorytmow, sprawnosci i optymalizacji
programow. Nei spotkalem jeszcze faceta z dyplomem M. Sc. ktory by
wiedzial jak "w srodku" dziala Javova HashTable, po co jest "load
factor" i po co jest mozliwosc definiowania poczatkowego rozmiaru
hashtable, i jak owe czynniki wplywaja na sprawnosc. W ogole nikt nei
widzial (jak do dzis) jaka jest zlozonosc operracji wyszukiwania w
hashtable i od czego ona zalezy. Jak rowniez jaki jest koszt
zdefiniowania HashTable z domyslnymi wartosciami. Zeby wymienic tylko
jeden problem.

Takich rzeczy sie na studiach nei uczy.

Robi sie wiec bez zastanowienia rozne idiotyzmy dzieki ktorym programy
sa szybkie jak mucha w miodzie. No, ale zawsze mozna wziac szybszy
procesor.

Bylo tu pare slow o "code review". Code review jest miedzy innymi po
to zeby zobaczyc idiotyzmy ktore "pistolety" robia w sensie
sprawnosci.

A.L.

do góry

On Tue, 21 Dec 2010 13:52:24 -0600, A.L. <l...@a...com> wrote:

>Moje obserwacja mlodych "pistoletow" programistycznych oraz
>przesluchiwanie ic hna interview pokazuja ze nei maja oni pojecia o
>zlozonosci obliczeniowej algorytmow, sprawnosci i optymalizacji
>programow. Nei spotkalem jeszcze faceta z dyplomem M. Sc. ktory by
>wiedzial jak "w srodku" dziala Javova HashTable, po co jest "load
>factor" i po co jest mozliwosc definiowania poczatkowego rozmiaru
>hashtable, i jak owe czynniki wplywaja na sprawnosc. W ogole nikt nei
>widzial (jak do dzis) jaka jest zlozonosc operracji wyszukiwania w
>hashtable i od czego ona zalezy. Jak rowniez jaki jest koszt
>zdefiniowania HashTable z domyslnymi wartosciami. Zeby wymienic tylko
>jeden problem.

Oczywiscie, mialem na mysli Javowa HashMap

A.L.

do góry

Dnia 21-12-2010 o 20:52:24 A.L. <l...@a...com> napisa?(a):

> Moje obserwacja mlodych "pistoletow" programistycznych oraz
> przesluchiwanie ic hna interview pokazuja ze nei maja oni pojecia o
> zlozonosci obliczeniowej algorytmow, sprawnosci i optymalizacji
> programow. Nei spotkalem jeszcze faceta z dyplomem M. Sc. ktory by
> wiedzial jak "w srodku" dziala Javova HashTable, po co jest "load
> factor" i po co jest mozliwosc definiowania poczatkowego rozmiaru
> hashtable, i jak owe czynniki wplywaja na sprawnosc. W ogole nikt nei
> widzial (jak do dzis) jaka jest zlozonosc operracji wyszukiwania w
> hashtable i od czego ona zalezy. Jak rowniez jaki jest koszt
> zdefiniowania HashTable z domyslnymi wartosciami. Zeby wymienic tylko
> jeden problem.

Bez problemu.

> Takich rzeczy sie na studiach nei uczy.

Uczy się, tylko większość studentów uważa tą wiedzę za zupełnie
niepotrzebną, a woleliby żeby ich nauczyć jakiegoś super-hiper frameworku.

> Robi sie wiec bez zastanowienia rozne idiotyzmy dzieki ktorym programy
> sa szybkie jak mucha w miodzie. No, ale zawsze mozna wziac szybszy
> procesor.

True

--
Boguś

do góry

On Tue, 21 Dec 2010 21:26:27 +0100, Bogu? <n...@i...net> wrote:

>Dnia 21-12-2010 o 20:52:24 A.L. <l...@a...com> napisa?(a):
>
>> Moje obserwacja mlodych "pistoletow" programistycznych oraz
>> przesluchiwanie ic hna interview pokazuja ze nei maja oni pojecia o
>> zlozonosci obliczeniowej algorytmow, sprawnosci i optymalizacji
>> programow. Nei spotkalem jeszcze faceta z dyplomem M. Sc. ktory by
>> wiedzial jak "w srodku" dziala Javova HashTable, po co jest "load
>> factor" i po co jest mozliwosc definiowania poczatkowego rozmiaru
>> hashtable, i jak owe czynniki wplywaja na sprawnosc. W ogole nikt nei
>> widzial (jak do dzis) jaka jest zlozonosc operracji wyszukiwania w
>> hashtable i od czego ona zalezy. Jak rowniez jaki jest koszt
>> zdefiniowania HashTable z domyslnymi wartosciami. Zeby wymienic tylko
>> jeden problem.
>
>Bez problemu.

Jedna jaskolka wiosny nie czyni :)

A.L.

do góry

Maciej Sobczak wrote:
> On Dec 17, 8:28 am, Mariusz Kruk <M...@e...eu.org> wrote:
>
> BTW - Tak totalnie rozpieprzonych literek jeszcze nie widziałem. Czego
> używasz do pisania?

On pisze dobrze, to Google jak zwykle nie rozumie nagłówków które nawet
MS Utłuk-Ekspres rozumie. Ot, wieczne beta Googla. :)

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

Zwłaszcza na przykładzie takiego Erlanga ;)

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

Jaka była ta strata wydajności? Było wolniej od bubble sort?

> Komputery mają swoją fizyczność i idące z nią ograniczenia. Jeśli je
> zignorujesz, to ograniczysz się do eksploracyjnej niszy.
>
>>>> 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ć.

Ależ jest się czego złapać. Bo po pierwsze masz już istniejącą
terminologię. Przyjętą dawno temu.

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

Po pierwsze nie jest zgodne z innymi kalkami. Poza tym, to jest kalka
najgorszego rodzaju bo przez dobranie słowa o podobnym brzmieniu,
zamiast użycia słowa o pasującym znaczeniu. W angielskim 'functional' ma
znaczenia zarówno jako przymiotnik od słowa funkcja jak i jako
funkcjonalny czyli wygodny w użyciu, zoptymalizowany dla użwania, itp.

Czy Ty może jesteś z tych, którzy tłumaczą angielskie 'eventually' na
ewentualnie? Albo może tłumaczmy 'billion' na bilion a nie miliard, bo
przecież tak brzmi?

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

Jest to pierwotnie przyjęta terminologia. To co ty propagujesz to
tłumaczenie 'eventually' na ewentualnie.

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

Ach, słownik języka polskiego jest "za słaby".

>
> Znajdź coś lepszego.

Nie, to Ty znajdź lepszy argument na twoją miłość do psucia języka.

Znałem jedną panią profesor w której wykładach w kółko powtarzało się
słowo klucz "relewantne", nagminnie mamy dziś "technologię" czy
"autentykację". Znalazła się też grupa ludzi, która ignorując istniejącą
już w języku *fachową* terminologię (zastosowaną przez tych, którzy
kilkadziesiąt lat temu zajmowali się tym w naszym kraju jako pierwsi)
używa bezmyślnej kalki funkcjonalny.

Kalka ta jest bezmyślna, bo w angielskim mamy przymiotnik (o znaczeniu
jako rzeczownik nie mówię) 'functional', a w polskim mamy dwa wyrazy o
*różnych* znaczeniach: funkcjonalny i funkcyjny. Jedno i drugie jest
tłumaczeniem różnych znaczeń słowa 'functional'. I dawno temu (chyba
jeszcze przed Twoim urodzeniem) przyjęto w języku fachowym że akurat to
znaczenie tłumaczy się jako funkcyjny a nie funkcjonalny. I przyjęto
sensownie bo słowotówórczo przymiotnikiem od funkcja jest funkcyjny a
nie funkcjonalny.

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

Doprowadziły do wniosku, że uparłeś się by psuć język na zasadzie "bo
tak". Nikt cię nie zabije za to, że funkcjonalnie autentykujesz
relewantną technologię, ale to nie zmienia faktu, że to potworek.
Przeżyliśmy już modę na "dokładnie", "łał", czy starsze "w miesiącu
maju", "funcjonalną autentykację w technologii" też przeżyjemy.
W tym miejscu faktycznie najlepszy jest argument o "3 osobie mówiącej,
że jesteś pijany" albo dowcip "o blondynce na autrostradzie".

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

Nadal nie odpowiedziałeś na pytaniem, czy w ogóle ktokolwiek przysłał
implementację funkcyjną.

pzdr
\SK

--
"Never underestimate the power of human stupidity" -- L. Lang
--
http://www.tajga.org -- (some photos from my travels)

do góry

On Thu, 23 Dec 2010 12:30:51 +0100, Sebastian Kaliszewski
<s...@r...this.informa.and.that.pl> wrote:

>Maciej Sobczak wrote:
>> On Dec 17, 8:28 am, Mariusz Kruk <M...@e...eu.org> wrote:
>>
>> BTW - Tak totalnie rozpieprzonych literek jeszcze nie widziałem. Czego
>> używasz do pisania?
>
>On pisze dobrze, to Google jak zwykle nie rozumie nagłówków które nawet
>MS Utłuk-Ekspres rozumie. Ot, wieczne beta Googla. :)
>
>>
>>> 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.
>
>Zwłaszcza na przykładzie takiego Erlanga ;)
>
>

Co ciekawe, pierwszy, dosyc sprawny kompilator Erlanga napisany byl w
Prologu. Erlang zreszta sporo od Prologu sciagnal

A.L.

do góry

On Dec 23, 12:30 pm, Sebastian Kaliszewski
<s...@r...this.informa.and.that.pl> wrote:

> Ale jest si czego z apa . Bo po pierwsze masz ju istniej c
> terminologi . Przyj t dawno temu.

Ależ obie są przyjęte. Dawno temu.

> Jest to pierwotnie przyj ta terminologia.

Pierwotnie? Nie wiem, widziałem użycie "programowanie funkcjonalne" i
nie chce mi się sprawdzać, co było pierwsze.

> To co ty propagujesz to
> t umaczenie 'eventually' na ewentualnie.

Słabe. Ten przykład prowadzi do nieporozumień i nie jest przyjęty,
podczas gdy "programowanie funkcjonalne" nie prowadzi i jest przyjęte.
Słaba analogia.

> > Znajd co lepszego.
>
> Nie, to Ty znajd lepszy argument na twoj mi o do psucia j zyka.

> Doprowadzi y do wniosku, e upar e si by psu j zyk na zasadzie "bo
> tak".

Nie.

Po pierwsze primo, użycie "programowanie funkcjonalne" jest przyjęte i
używane przez ludzi, którzy się tym zajmują. To też już podawałem.

Po drugie primo, ja sądzę, że "programowanie funkcjonalne" to nie jest
kalka, tylko ma... polskie korzenie (!), więc nie może być kalką,
tylko właśnie nawiązaniem do pierwotnego terminu. I, uwaga uwaga, ten
argument też już kiedyś podawałem (i nikt nie znalazł kontrargumentu)
i właśnie teraz pokazałeś, że Tobie też nie chciało się tej dyskusji z
przeszłości poszukać.

No i dlaczego miałbym znowu to wszystko powtarzać? Bo uparłeś się na
"programowanie funkcyjne" na zasadzie "bo tak"?

> Nikt ci nie zabije za to, e funkcjonalnie autentykujesz
> relewantn technologi , ale to nie zmienia faktu, e to potworek.

Owszem. Ale co ten potworek ma do "programowania funkcjonalnego",
który jest przyjętym terminem? Chodzi o to, że Ty też nie masz
rzeczowych argumentów i wymyślasz niepowiązane analogie? Spoko, nikt
Cię za to nie zabije...

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

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Maciej Sobczak"
>> Ale jest si czego z apa . Bo po pierwsze masz ju istniej c
>> terminologi . Przyj t dawno temu.

Ech, góglowe cytowanie.

>Ależ obie są przyjęte. Dawno temu.

Oczywiście. Podobnie jak "autentykacja".

>> To co ty propagujesz to
>> t umaczenie 'eventually' na ewentualnie.
>Słabe. Ten przykład prowadzi do nieporozumień i nie jest przyjęty,
>podczas gdy "programowanie funkcjonalne" nie prowadzi

Oczywiście. Przecież określenie "funkcjonalny język programowania" jest
takie jednoznaczne.

>i jest przyjęte.
>Słaba analogia.

Słaby argument.

>> > Znajd co lepszego.
>> Nie, to Ty znajd lepszy argument na twoj mi o do psucia j zyka.
>
>> Doprowadzi y do wniosku, e upar e si by psu j zyk na zasadzie "bo
>> tak".
>Nie.

Tupnij jeszcze.

>Po pierwsze primo, użycie "programowanie funkcjonalne" jest przyjęte i
>używane przez ludzi, którzy się tym zajmują. To też już podawałem.

Oczywiście. "Autentykacja" też niestety jest często używana przez ludzi.
I to, niestety, także przez tych, którzy się tym zawodowo zajmują.
Nie musisz przekonywać nas, że ludzie są niedbali.

>Po drugie primo, ja sądzę, że "programowanie funkcjonalne" to nie jest
>kalka, tylko ma... polskie korzenie (!), więc nie może być kalką,

Ach, bo "Ty sądzisz". Faktycznie mocny argument.

>tylko właśnie nawiązaniem do pierwotnego terminu. I, uwaga uwaga, ten
>argument też już kiedyś podawałem (i nikt nie znalazł kontrargumentu)

Wiesz, ciężko znaleźć argument do "sądzenia".
Innemi słowy "ja sądzę, że jesteś głupi" (nie, to nie moja opinia, to
tylko przykład użycia; nie obrażaj mi się od razu). Podaj kontrargument.

>No i dlaczego miałbym znowu to wszystko powtarzać? Bo uparłeś się na
>"programowanie funkcyjne" na zasadzie "bo tak"?

Nie "bo tak", tylo "bo jest to prawidłowe zarówno treściowo, jak
i językowo". I nie jest jakąś koszmarną kalką typu "armia jest
ordynarna" (chałupnicze tłumaczenie "the army is ordinary" z gry
Centurion z czasów Amigi 500).

>> Nikt ci nie zabije za to, e funkcjonalnie autentykujesz
>> relewantn technologi , ale to nie zmienia faktu, e to potworek.
>Owszem. Ale co ten potworek ma do "programowania funkcjonalnego",

Mechanizm.

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

do góry

On Thu, 23 Dec 2010 12:30:51 +0100, Sebastian Kaliszewski
<s...@r...this.informa.and.that.pl> wrote:


>
>Kalka ta jest bezmyślna, bo w angielskim mamy przymiotnik (o znaczeniu
>jako rzeczownik nie mówię) 'functional', a w polskim mamy dwa wyrazy o
>*różnych* znaczeniach: funkcjonalny i funkcyjny. Jedno i drugie jest
>tłumaczeniem różnych znaczeń słowa 'functional'. I dawno temu (chyba
>jeszcze przed Twoim urodzeniem) przyjęto w języku fachowym że akurat to
>znaczenie tłumaczy się jako funkcyjny a nie funkcjonalny. I przyjęto
>sensownie bo słowotówórczo przymiotnikiem od funkcja jest funkcyjny a
>nie funkcjonalny.

Popieram. Wedle definicji, "functional languages" to jezyki operujace
na funkcjach wiec powinny sie nazywac "jezyki funkcyjne".

A.L.

do góry