🚀 go-pugleaf

Przemek Pokrywka wrote (tak! stara dobra wrotka!):

> Jestem nowy w temacie języków funkcyjnych - w jakich zastosowaniach 
> spisują się one najlepiej?

Języki funkcyjne są obiektywnie najlepsze na świecie, tak więc nadają się
znakomicie do każego problemu. Niestety mają jedną wadę - są trudniejsze od
języków pokroju C czy C++ tak więc nie są super popularne.

-- 
Zbigniew Malec Ustronie:104 gg:2756100

Przemek Pokrywka <adres@zastrzezony.com> wrote:
> Witam,
> 
> Jestem nowy w temacie języków funkcyjnych - w jakich zastosowaniach 
> spisują się one najlepiej?
	... aktualnie najbardziej komercyjne dobrze sprzedaly się w:
DSSSL - przeksztalcenia XML/SGML, Autocad - jezyk skryptow czyli dodawanie
logiki do programu przez uzytkownikow, to samo w Gimp-ie (SIOD),
Franz CommonLisp dobrze się podobno sprawdza w pisaniu gier na komorofony,
cl-httpd za Clintona dzialal jako serwer publikacji Bialego Domu,
bez szans na wlam;-) Stosuje się to takze, (CL) jako platforme
do RAD i nie na zasadzie polaczenia oczojebnego GUI po raz kolejny z baza
SQL aby taka aplikazja zadzialala choc raz przed klientem, z cala masa
miotajacych się po pamieci blednych wskaznikow, ale dla stworzenia aplikacji
ktore musza dzialac jako aplikacje krytyczne - np. zmieniane w "locie"
aplikacje do zarzadzania misjami kosmicznymi (to z NASA) bo jak cos jest nie tak,
to elektronika, warta tyle co 100 ferrari, idzie w pizdu;-))) W ten sposob powstawaly
tez sklepy w Yahoo, teraz juz dzialajace przepiano je na cos innego i zoptymalizowano.
Bywa, ze stosuje sie lispa do AI, tak jak europejczycy preferuja Prologa,
tak amerykanie Lispa, choc czasami takie aplikacje migruja potem na inny jezyk,
przyklad: http://opensource.arc.nasa.gov/project.jsp?id=6 napsiany wstapnie w CL
wymigrowal na C++. Zerknij na strone franz.com tam powinno byc wiecej informacji.
Generalnie teraz niektore funkcje przejmuja jezyki troche prostsze, jak Python.
A z drugiej strony, postep w analizie kodu wlasciwie uczynil dla kompilatora
wlasciwie kazdy jezyk jezykiem deklaratywnym, czym wytacil glowna bron jezykom
funkcyjnym. Z powazaniem
								Adam Przybyla

Przemek Pokrywka wrote:
> Jestem nowy w temacie języków funkcyjnych - w jakich zastosowaniach 
> spisują się one najlepiej?

U mnie bardzo dobrze sprawdzaja sie w pracy (konkretnie: Haskell).
Zastosowania sa rozne, od serwerow sieciowych i skryptow CGI po analize
i przeksztalcanie wlasnych prostych jezykow.

Patrz sygnaturka.

Pozdrawiam
Tomek

-- 
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland

Zbyszek Malec wrote:
> Języki funkcyjne są obiektywnie najlepsze na świecie, tak więc nadają się
> znakomicie do każego problemu. Niestety mają jedną wadę - są trudniejsze od
> języków pokroju C czy C++ tak więc nie są super popularne.

Trudniejsze niz C++? To chyba tylko wtedy, kiedy juz znasz C++.

A tak wlasciwie, to kto zna C++? Sam programuje w C++ od dobrych
kilku lat, ale raczej nie znam C++ "na wylot", i nie mam zamiaru
go tak dobrze poznawac.

Best regards
Tomasz

-- 
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland

Przemek Pokrywka wrote:
> Witam,
> 
> Jestem nowy w temacie języków funkcyjnych - w jakich zastosowaniach 
> spisują się one najlepiej?
> 
> Pozdrawiam
> Przemek

Może lepiej będzie podać parę przykładów wdrożeń w językach funkcyjnych, 
oprócz tych wspomnianych przez poprzedników: darcs, frag, pugs, no i 
oczywiście... kompilatory jęz. funkc. To trochę idiosynkratyczne, ale 
nic tak się nie nadaję do implementacji kompilatora/interpretera (i w 
ogóle narzędzi językowych), jak jęz. funkcyjny.

Poza tym nie zapominajmy o największym na skalę komercyjno-reklamową 
wdrożeniu idei programowania funkcyjnego/deklaratywnego, jaką jest XSLT.

R.

Tomasz Zielonka wrote:
> Zbyszek Malec wrote:
> > Języki funkcyjne są obiektywnie najlepsze na świecie, tak więc nadają się
> > znakomicie do każego problemu. Niestety mają jedną wadę - są trudniejsze od
> > języków pokroju C czy C++ tak więc nie są super popularne.
>
> Trudniejsze niz C++? To chyba tylko wtedy, kiedy juz znasz C++.

Biorąc pod uwagę zakres współczesnych kursów programowania
zgodziłbym się z Z.M. Odnoszę wrażenie, że nie uczy się u nas
podstawowych zagadnień związanych z programowaniem funkcyjnym (a w
każdym razie nie znam takiego studenta ani absolwenta, który by tą
wiedzę tajemną posiadł ani też sam nie nauczyłem się tego na
żadnej uczelni). Podstaw C++ lub Javy uczą zaś wszędzie, więc
każdy te podstawy *teoretycznie* ma.

Dlatego zgodziłbym się, że C++ jest łatwiejsze do używania dla
przeciętnego współczesnego absolwenta.

Pozdrawiam,
PFM

Tomasz Zielonka wrote (tak! stara dobra wrotka!):

>> języków pokroju C czy C++ tak więc nie są super popularne.
> 
> Trudniejsze niz C++? To chyba tylko wtedy, kiedy juz znasz C++.

Pokroju C++, niekoniecznie samego C++. Chodzi mi o sposób pisania programów
a nie zawiłości i kruczki danego języka.

-- 
Zbigniew Malec Ustronie:104 gg:2756100

RobertSzefler wrote:
> Poza tym nie zapominajmy o największym na skalę komercyjno-reklamową 
> wdrożeniu idei programowania funkcyjnego/deklaratywnego, jaką jest XSLT.

Fuj! To najgorszy jezyk funkcyjny z jakim pracowalem. Chyba wolalbym
programowac w czystym rachunku lambda ;-)

Best regards
Tomasz

-- 
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland

Tomasz Zielonka wrote:
> RobertSzefler wrote:
> 
>>Poza tym nie zapominajmy o największym na skalę komercyjno-reklamową 
>>wdrożeniu idei programowania funkcyjnego/deklaratywnego, jaką jest XSLT.
> 
> Fuj! To najgorszy jezyk funkcyjny z jakim pracowalem. Chyba wolalbym
> programowac w czystym rachunku lambda ;-)

Rzecz gustu. Lepszy od pehapa ;) [chyba wszystko jest lepsze, hehe]

Tomasz Zielonka <tomasz.zielonka@gmail.com> wrote:
> RobertSzefler wrote:
>> Poza tym nie zapominajmy o największym na skalę komercyjno-reklamową 
>> wdrożeniu idei programowania funkcyjnego/deklaratywnego, jaką jest XSLT.
> 
> Fuj! To najgorszy jezyk funkcyjny z jakim pracowalem. Chyba wolalbym
> programowac w czystym rachunku lambda ;-)
	... hihi, a sa jakies fajne ksiazki na ten temat po polsku?
Z powazaniem
								Adam Przybyla

"Przemek Pokrywka" <adres@zastrzezony.com> wrote:

> Jestem nowy w temacie języków funkcyjnych - w jakich
> zastosowaniach spisują się one najlepiej?

Przy przetwarzniu "jezykow", na roznych poziomach - od konstrukcji
kompilatorow/interpreterow, przez pisanie theorem proverow, az po NLP. Styl
"niezmienniczy" dobrze wkomponowuje sie w programowanie wspolbiezne.
Pozatym, jezyki funkcyjne maja zwyczajowo matematycznie duzo przyjemniejsze
cechy semantyczne, niz jezyki obiektowe (ulatwia to np. wnioskowanie
nt./werfikacje programow).

Nadmienie tylko jeszcze dla formalnosci, ze:

a) jezyki funkcyjne sa po prostu trudne na poziomie _koncepcyjnym_, a to
jest zupelnie inna trudnosc niz w nauczeniu sie np. C++ (C++ to "naucz sie
Illiady na pamiec", Haskell to "zrozum Kan extensions", o ile pierwszego
jest sie ciezej nauczyc, o tyle drugiego nie kazdy jest w stanie),

b) jezyki funkcyjne nie sprawdzaja sie w "programming in the large".


mp

Michal Przybylek wrote:
> b) jezyki funkcyjne nie sprawdzaja sie w "programming in the large".

Moglbys to rozwinac? Nie bardzo mi sie to zgadza z moim doswiadczeniem.
Moze dlatego, ze myslimy o innych rzeczach.

Zatem kilka pytan kontrolnych:

- Co rozumiesz przez "programming in the large"?
- Komu sie nie sprawdzaja?
- A moze nie sprawdzaja sie w ogolnosci?
- Nigdy nie beda sie sprawdzac?
- Ile razy byly sprawdzane w "programming in the large"?
    Przez ile firm?
    osob?
    Kiedy to bylo?
    Czy "state of the art" zmienil sie od tego czasu?
- Czy masz jakies osobiste doswiadczenia z tym zwiazane?

Best regards
Tomasz

-- 
I am searching for programmers who are good at least in
(Haskell || ML) && (Linux || FreeBSD || math)
for work in Warsaw, Poland

Tomasz Zielonka wrote:
> Michal Przybylek wrote:
>> b) jezyki funkcyjne nie sprawdzaja sie w "programming in the large".
>
> Moglbys to rozwinac? Nie bardzo mi sie to zgadza z moim doswiadczeniem.
> Moze dlatego, ze myslimy o innych rzeczach.

Moze chodzi o to, ze ja po prostu uzywam Haskella jako narzedzia,
pisze czysto-funkcyjnie tam, gdzie warto, ale czasem uzywam tez
imperatywnosci. Czyli bez fanatyzmu, podejscie pragmatyczne.

Ale z drugiej strony program nad ktorym ostatnio pracuje i z ktorego
jestem bardzo zadowolony sklada sie w jakichs 95% z kodu czysto
funkcyjnego. Tez ze wzgledow praktycznych.

Best regards
Tomasz

-- 
I am searching for programmers who are good at least in
(Haskell || ML) && (Linux || FreeBSD || math)
for work in Warsaw, Poland

Tomasz Zielonka wrote:
> Tomasz Zielonka wrote:
>> Michal Przybylek wrote:
>>> b) jezyki funkcyjne nie sprawdzaja sie w "programming in the large".
>>
>> Moglbys to rozwinac? Nie bardzo mi sie to zgadza z moim doswiadczeniem.
>> Moze dlatego, ze myslimy o innych rzeczach.
>
> Moze chodzi o to, ze ja po prostu uzywam Haskella jako narzedzia,
> pisze czysto-funkcyjnie tam, gdzie warto, ale czasem uzywam tez
> imperatywnosci. Czyli bez fanatyzmu, podejscie pragmatyczne.

Przez imperatywnosc w Haskellu w tym przypadku rozumiem uzycie monady
IO. Technicznie kod nadal jest czysto-funkcyjny, ale sposob myslenia o
nim juz nie.

PS. Jak to fajnie jest podyskutowac z samym soba ;-)

Best regards
Tomasz

-- 
I am searching for programmers who are good at least in
(Haskell || ML) && (Linux || FreeBSD || math)
for work in Warsaw, Poland

Tomasz Zielonka wrote:
> Tomasz Zielonka wrote:
> 
>>Michal Przybylek wrote:
>>
>>>b) jezyki funkcyjne nie sprawdzaja sie w "programming in the large".
>>
>>Moglbys to rozwinac? Nie bardzo mi sie to zgadza z moim doswiadczeniem.
>>Moze dlatego, ze myslimy o innych rzeczach.
> 
> 
> Moze chodzi o to, ze ja po prostu uzywam Haskella jako narzedzia,
> pisze czysto-funkcyjnie tam, gdzie warto, ale czasem uzywam tez
> imperatywnosci. Czyli bez fanatyzmu, podejscie pragmatyczne.
> 
> Ale z drugiej strony program nad ktorym ostatnio pracuje i z ktorego
> jestem bardzo zadowolony sklada sie w jakichs 95% z kodu czysto
> funkcyjnego. Tez ze wzgledow praktycznych.

Zdradzisz, jaki to projekt? Duży? Haskell się sprawdza?

Tomasz Zielonka wrote:

> Przez imperatywnosc w Haskellu w tym przypadku rozumiem uzycie monady
> IO. Technicznie kod nadal jest czysto-funkcyjny, ale sposob myslenia o
> nim juz nie.

Aj! Monady! A fe!

> PS. Jak to fajnie jest podyskutowac z samym soba ;-)

Żebyś nie czuł schizofrenii napisałem ;)

BTW zdarza Ci się używać innych rzeczy monadycznych, np. kombinatorów do 
parsowania czy czegoś innego jeszcze?

Michal Przybylek wrote:
> "RobertSzefler" <NOSPAMrszeflerNOSPAM@murator.com.pl> wrote:
> 
>>BTW zdarza Ci się używać innych rzeczy monadycznych
> 
> Nagminnie, cala filozofia Haskell'u zbudowana jest w oparciu o pojecie
> monady.

Konkrety? (coś innego niż IO)

"Tomasz Zielonka" <tomasz.zielonka@gmail.com> wrote:

> Moze chodzi o to, ze ja po prostu uzywam Haskella jako narzedzia,
> pisze czysto-funkcyjnie tam, gdzie warto, ale czasem uzywam tez
> imperatywnosci. Czyli bez fanatyzmu, podejscie pragmatyczne.

Nie, nie chodzi o to. Chodzi o to, co juz bylo walkowane po sto razy:

- podejscie funkcyjne jest, bylo i zawsze bedzie zarezerwowane dla ludzi
duzo powyzej klasy sredniej ; to, ze Ty sie obracasz w srodowisku
uniwersyteckim (i to, zdaje sie, jednego z lepszych uniwersystetow w
Polsce), nie oznacza, ze reszta ludzi jest na podobnym poziomie, prosze nie
ekstrapoluj lokalnych obserwacji ; ogolny poziom w informatyce (w Polsce,
nie wiem jak jest gdzie indziej - slyszalem, ze o wiele gorzej...) jest po
prostu zenujacy ; co mam zrobic, kiedy potrzebuje 100 programistow Haskell'a
? - wyslac po kilka zaproszen na Antarktyde, a po kilka na Wyspy Dziewicze ?
; ile tacy programisci beda kosztowac ? - czy to sie oplaci ? ; co jezeli
jeden zlamie reke, a drugiego potraci tramwaj ? jak szybko bede w stanie
sprowadzic kogos na ich miejsce ?

- pardon, pracowanie w jezykach umozliwiajacych konstrukcje z wysokiego
poziomu abstrakcji, pomimo, ze akademicko bardzo podniecajace, niekonieczni
musi pozytywnie wplywac na jakosc, czytelnosc i latwosc pielegnaci kodu ;
abstrakcja jest po prostu trudna ; przy opracowywaniu dobrej abstrakcji
bardzo latwo jest opracowac zla abstrakcje, ktora innym bedzie ciezko
zrozumiec ; abstrakcja eliminuje "wzorce w kodzie", eliminuje cos co
sprawia, ze patrzac sie na kod znasz inetencje autora kodu i potrafisz
swobodnie przelozyc te intencje na wlasne myslenie,

- jezyki funkcyjnie nie mapuja tak naturalnie jak jezyki obiektowe projektu
obiektowego na kod programu, a badz co badz analiza i projektowanie
obiektowe sa najpopularniejsze,

- jak na razie jezykom funkcyjnym ogolnie brakuje odpowiedniego wsparcia
(przy czym to jest raczej konsekwencja pozostalych powodow - rzad USA
wpakowal w swoim czasie w Lisp miliony dolcow ; i jak sie skonczyla historia
maszyn lispowych ? skadinad architektonicznie calkiem nizlych... ; BTW:
troche podobnie bylo w Europie z transputerami i Occam'em...).

... itd ...

Zauwaz, ze dwa pierwsze aspekty w ogole nie stanowia problemu w hermetycznie
zamknietej grupie kilku hakerow, zas trzeci i czwarty stanowia w o wiele
mniejszym stopniu.


mp

"RobertSzefler" <NOSPAMrszeflerNOSPAM@murator.com.pl> wrote:

> BTW zdarza Ci się używać innych rzeczy monadycznych

Nagminnie, cala filozofia Haskell'u zbudowana jest w oparciu o pojecie
monady.


mp

RobertSzefler wrote:
> Tomasz Zielonka wrote:
>> Ale z drugiej strony program nad ktorym ostatnio pracuje i z ktorego
>> jestem bardzo zadowolony sklada sie w jakichs 95% z kodu czysto
>> funkcyjnego. Tez ze wzgledow praktycznych.
>
> Zdradzisz, jaki to projekt? Duży? Haskell się sprawdza?

Wiecej algorytmow niz programu ;-) Teraz to jakies 1.5 KLOC, ale bedzie
pewnie ze 4. Bede troche enigmatyczny - jedyny powod istnienia tego
programu to wydajnosc. Ogolnie chodzi o przetwarzanie duzych
ilosci danych. Jest tu troche technik takich jak czesciowa ewaluacja
(partial evaluation), ale w takim zabawkowym wydaniu. Reszta jest w C++
i to jest jakies 5 KLOC + 30 KLOC ogolnej biblioteki. 

Haskell sie sprawdza. Na pewno nie chcialbym tego implementowac w C++.

Akurat ten program robi cos, w czym jezyki funkcyjne sa dobre "by
design". Mam jednak inne zastosowania, w ktorych Haskell sprawdza
sie bardzo dobrze - np. sieciowe serwery proxy, aplikacje CGI.

Pozdrawiam
Tomasz

-- 
I am searching for programmers who are good at least in
(Haskell || ML) && (Linux || FreeBSD || math)
for work in Warsaw, Poland

RobertSzefler wrote:
>> PS. Jak to fajnie jest podyskutowac z samym soba ;-)
>
> Żebyś nie czuł schizofrenii napisałem ;)

Dzieki :-)

> BTW zdarza Ci się używać innych rzeczy monadycznych, np. kombinatorów do 
> parsowania czy czegoś innego jeszcze?

Oczywiscie. Zwlaszcza takich: Parsec, zlozenia transformatorow
monad, wlasne monady, STM.

Best regards
Tomasz

-- 
I am searching for programmers who are good at least in
(Haskell || ML) && (Linux || FreeBSD || math)
for work in Warsaw, Poland

Michal Przybylek wrote:
> "Tomasz Zielonka" <tomasz.zielonka@gmail.com> wrote:
>
>> Moze chodzi o to, ze ja po prostu uzywam Haskella jako narzedzia,
>> pisze czysto-funkcyjnie tam, gdzie warto, ale czasem uzywam tez
>> imperatywnosci. Czyli bez fanatyzmu, podejscie pragmatyczne.
>
> Nie, nie chodzi o to. Chodzi o to, co juz bylo walkowane po sto razy:
>
> - podejscie funkcyjne jest, bylo i zawsze bedzie zarezerwowane dla ludzi
> duzo powyzej klasy sredniej ; to, ze Ty sie obracasz w srodowisku
> uniwersyteckim (i to, zdaje sie, jednego z lepszych uniwersystetow w
> Polsce), nie oznacza, ze reszta ludzi jest na podobnym poziomie, prosze nie
> ekstrapoluj lokalnych obserwacji ;

W moim przypadku to obracanie skonczylo sie skresleniem z listy
studentow ;-)

I w ogole nie znam teorii kategorii ;-)

> ogolny poziom w informatyce (w Polsce, nie wiem jak jest gdzie indziej
> - slyszalem, ze o wiele gorzej...) jest po prostu zenujacy ; co mam
> zrobic, kiedy potrzebuje 100 programistow Haskell'a ? - wyslac po
> kilka zaproszen na Antarktyde, a po kilka na Wyspy Dziewicze ?  ; ile
> tacy programisci beda kosztowac ? - czy to sie oplaci ? ; co jezeli
> jeden zlamie reke, a drugiego potraci tramwaj ? jak szybko bede w
> stanie sprowadzic kogos na ich miejsce ?

Wlasnie to sprawdzam.

> - pardon, pracowanie w jezykach umozliwiajacych konstrukcje z wysokiego
> poziomu abstrakcji, pomimo, ze akademicko bardzo podniecajace, niekonieczni
> musi pozytywnie wplywac na jakosc, czytelnosc i latwosc pielegnaci kodu ;

Oczywiscie. Wiem to z wlasnego doswiadczenia.

> abstrakcja jest po prostu trudna ; przy opracowywaniu dobrej abstrakcji
> bardzo latwo jest opracowac zla abstrakcje, ktora innym bedzie ciezko
> zrozumiec ; abstrakcja eliminuje "wzorce w kodzie", eliminuje cos co
> sprawia, ze patrzac sie na kod znasz inetencje autora kodu i potrafisz
> swobodnie przelozyc te intencje na wlasne myslenie,

Wiecej o tym pozniej...

> - jezyki funkcyjnie nie mapuja tak naturalnie jak jezyki obiektowe projektu
> obiektowego na kod programu, a badz co badz analiza i projektowanie
> obiektowe sa najpopularniejsze,

Jakos to przeboleje.

> - jak na razie jezykom funkcyjnym ogolnie brakuje odpowiedniego wsparcia
> (przy czym to jest raczej konsekwencja pozostalych powodow - rzad USA
> wpakowal w swoim czasie w Lisp miliony dolcow ; i jak sie skonczyla historia
> maszyn lispowych ? skadinad architektonicznie calkiem nizlych... ; BTW:
> troche podobnie bylo w Europie z transputerami i Occam'em...).

W Haskella nie wpakowano takich srodkow, a jest calkiem, calkiem.
Zgadzam sie, ze wsparcie mogloby byc lepsze, ale np. jakosc kompilatorow
chyba i tak przebija to, co teraz mamy np. dla C++. No dobra, C++ to
zupelnie inna kategoria. Bjarne (prawie) wygral konkurs "Zaprojektuj
jezyk programowania, ktorego nikomu nie uda sie zaimplementowac".

> Zauwaz, ze dwa pierwsze aspekty w ogole nie stanowia problemu w hermetycznie
> zamknietej grupie kilku hakerow, zas trzeci i czwarty stanowia w o wiele
> mniejszym stopniu.

OK, dzieki za wyjasnienie.

Best regards
Tomasz

-- 
I am searching for programmers who are good at least in
(Haskell || ML) && (Linux || FreeBSD || math)
for work in Warsaw, Poland

Tomasz Zielonka wrote:

> W Haskella nie wpakowano takich srodkow, a jest calkiem, calkiem.
> Zgadzam sie, ze wsparcie mogloby byc lepsze, ale np. jakosc kompilatorow
> chyba i tak przebija to, co teraz mamy np. dla C++. No dobra, C++ to
> zupelnie inna kategoria. Bjarne (prawie) wygral konkurs "Zaprojektuj
> jezyk programowania, ktorego nikomu nie uda sie zaimplementowac".

Nie da się zaimplementować = w praktyce nie da się napisać dobrego 
parsera w rozsądnym czasie (ze względu na głęboko poj***** gramatykę). 
Jak to się przebrnie, to dalej konstrukcja kompilatora jest typowa dla 
języków imperatywnych - sprawdzanie typów (duużo prostsze bądź co bądź 
niż w Haskellu), dominatory, SSA, grafy przepływu, alokacja rejestrów, 
generowanie kodu plus milion heurystyk - to wszystko znane i 
dopieszczone w szczegółach od wielu, wielu lat. Co więcej, istnieje 
spora ilość prac teoretycznych świadcząca o tym, że implementacja 
kompilatorów jęz. funkc. to w istocie rzeczy to samo (np. odpowiedniość 
między SSA i CPS lub postacią A-normalną).

RobertSzefler wrote:
> Tomasz Zielonka wrote:
>
>> W Haskella nie wpakowano takich srodkow, a jest calkiem, calkiem.
>> Zgadzam sie, ze wsparcie mogloby byc lepsze, ale np. jakosc kompilatorow
>> chyba i tak przebija to, co teraz mamy np. dla C++. No dobra, C++ to
>> zupelnie inna kategoria. Bjarne (prawie) wygral konkurs "Zaprojektuj
>> jezyk programowania, ktorego nikomu nie uda sie zaimplementowac".
>
> Nie da się zaimplementować = w praktyce nie da się napisać dobrego 
> parsera w rozsądnym czasie (ze względu na głęboko poj***** gramatykę). 
> Jak to się przebrnie, to dalej konstrukcja kompilatora jest typowa dla 
> języków imperatywnych 

Nie do konca. Jest gorzej, bo gramatyka C++ (a nawet C) jest
niejednoznaczna i kompilator wlasciwie musi robic jednoczesnie analize
skladniowa i sprawdzanie typow. Wez chocby taki przyklad:

    ...

    void f(void)
    {
        ...
        x * y; // co to za konstrukcja?
    }

To C. W C++ jest jeszcze gorzej, chocby ze skladowymi klas, np.
czy to wartosc, typ czy szablon:
    T<41234>::member

Do "nie da sie" dodalbym jeszcze nieslychanie skomplikowane reguly
semantyczne jezyka (widocznosc nazw, konkretyzacja szablonow,
rozwiazywanie wolan przeciazonych funkcji, ...), rozdzielna kompilacja
dla szablonow, itp.

> - sprawdzanie typów (duużo prostsze bądź co bądź niż w Haskellu),

W Haskellu jest to przynajmniej dobrze sformalizowane.

> Co więcej, istnieje spora ilość prac teoretycznych świadcząca o tym,
> że implementacja kompilatorów jęz.  funkc. to w istocie rzeczy to samo
> (np. odpowiedniość między SSA i CPS lub postacią A-normalną).

Mowisz o jezyku funkcyjnym z ewaluacja "non-strict"?

Best regards
Tomasz

-- 
I am searching for programmers who are good at least in
(Haskell || ML) && (Linux || FreeBSD || math)
for work in Warsaw, Poland

Tomasz Zielonka wrote:

>>>W Haskella nie wpakowano takich srodkow, a jest calkiem, calkiem.
>>>Zgadzam sie, ze wsparcie mogloby byc lepsze, ale np. jakosc kompilatorow
>>>chyba i tak przebija to, co teraz mamy np. dla C++. No dobra, C++ to
>>>zupelnie inna kategoria. Bjarne (prawie) wygral konkurs "Zaprojektuj
>>>jezyk programowania, ktorego nikomu nie uda sie zaimplementowac".
>>
>>Nie da się zaimplementować = w praktyce nie da się napisać dobrego 
>>parsera w rozsądnym czasie (ze względu na głęboko poj***** gramatykę). 
>>Jak to się przebrnie, to dalej konstrukcja kompilatora jest typowa dla 
>>języków imperatywnych 
> 
> Nie do konca. Jest gorzej, bo gramatyka C++ (a nawet C) jest
> niejednoznaczna i kompilator wlasciwie musi robic jednoczesnie analize
> skladniowa i sprawdzanie typow. Wez chocby taki przyklad:

Właśnie o tym pisałem :)

>     ...
> 
>     void f(void)
>     {
>         ...
>         x * y; // co to za konstrukcja?

Eee... a tu jest jakaś niejednoznaczność? To jest po prostu mnożenie x 
przez y na moje oko. Dereferencja y nie jest problemem bo prowadzi 
natychmiast do błędu... jakiś kruczek tu jest?

>     }
> 
> To C. W C++ jest jeszcze gorzej, chocby ze skladowymi klas, np.

No to wiadomo. Bjarne should burn in hell. Żartowałem.

> czy to wartosc, typ czy szablon:
>     T<41234>::member
> 
> Do "nie da sie" dodalbym jeszcze nieslychanie skomplikowane reguly
> semantyczne jezyka (widocznosc nazw, konkretyzacja szablonow,
> rozwiazywanie wolan przeciazonych funkcji, ...), rozdzielna kompilacja
> dla szablonow, itp.

True, true... Ale mam wrażenie że np. współczesne dialekty FORTRANu 
(-a?) są też bardzo skomplikowane... Albo Java 5...

>>- sprawdzanie typów (duużo prostsze bądź co bądź niż w Haskellu),
> 
> W Haskellu jest to przynajmniej dobrze sformalizowane.

Co nie znaczy że prostsze, IMHO wręcz przeciwnie.

>>Co więcej, istnieje spora ilość prac teoretycznych świadcząca o tym,
>>że implementacja kompilatorów jęz.  funkc. to w istocie rzeczy to samo
>>(np. odpowiedniość między SSA i CPS lub postacią A-normalną).
> 
> Mowisz o jezyku funkcyjnym z ewaluacja "non-strict"?

Eee... dobre pytanie. Tak z głowy Ci nie powiem, ale mam wrażenie, że te 
analogie można wyabstrachować od kolejności ewaluacji przez analizę 
strictness (aargh! jak to jest po polsku?) i odpowiednie transformacje 
na CPS (czy jakiejś tam innej strukturze tego typu). Oczywiście 
strictness analysis jest tragicznie skomplikowana (eee... w ogólności 
chyba nawet nierozstrzygalna???), co wskazuje nota bene na to, że 
implementacja "mocnych" języków funkc. nie jest wcale taka prosta... 
Ogólnie zob. (jeśli nie czytałeś)

http://citeseer.ist.psu.edu/kelsey95correspondence.html
http://www.ccs.neu.edu/scheme/pubs/pldi-fsdf.pdf

Tomasz Zielonka <tomasz.zielonka@gmail.com> writes:

>> - sprawdzanie typów (duużo prostsze bądź co bądź niż w Haskellu),
>
> W Haskellu jest to przynajmniej dobrze sformalizowane.

Z punktu widzenia implementowania systemu typów Haskell 98 jest
o wiele prostszy niż C++.

Problem w tym, że GHC ma wiele eksperymentalnych rozszerzeń systemu
typów, zwłaszcza dotyczących klas, nad których implementacją panuje
chyba tylko Simon Peyton Jones.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Marcin 'Qrczak' Kowalczyk wrote:
> Tomasz Zielonka <tomasz.zielonka@gmail.com> writes:
> 
> 
>>>- sprawdzanie typów (duużo prostsze bądź co bądź niż w Haskellu),
>>
>>W Haskellu jest to przynajmniej dobrze sformalizowane.
> 
> Z punktu widzenia implementowania systemu typów Haskell 98 jest
> o wiele prostszy niż C++.
> 
> Problem w tym, że GHC ma wiele eksperymentalnych rozszerzeń systemu
> typów, zwłaszcza dotyczących klas, nad których implementacją panuje
> chyba tylko Simon Peyton Jones.

Hmm. Nie byłbym taki pewny. A co, jeśli by zaimplementować, dla 
sprawiedliwości, typecheckera do C++ w Haskellu i do Haskella w 
Haskellu? Robił ktoś kiedyś coś takiego?

RobertSzefler <NOSPAMrszeflerNOSPAM@murator.com.pl> writes:

>>         x * y; // co to za konstrukcja?
>
> Eee... a tu jest jakaś niejednoznaczność? To jest po prostu mnożenie x
> przez y na moje oko.

To może być też definicja zmiennej y typu wskaźnik do x.

Wiesz, do czego używa się słowa kluczowego typename?

Wiedziałbyś, że poniżej trzeba dodać w tym miejscu "template"?

          class X {
          public:
                  template<size_t> X* alloc();
          };
          void f(X* p)
          {
                  X* p1 = p->alloc<200>();
                          // ill-formed: < means less than

                  X* p2 = p->template alloc<200>();
                          // fine: < starts explicit qualification
          }

Oto moje ulubione kwiatki z gramatyki C++:

  6.8  Ambiguity resolution                                 [stmt.ambig]

1 There is an ambiguity in the grammar  involving  expression-statements
  and   declarations:  An  expression-statement  with  a  function-style
  explicit type conversion (_expr.type.conv_) as its leftmost subexpres-
  sion  can  be  indistinguishable  from  a  declaration where the first
  declarator starts with a (.  In those cases the statement is a  decla-
  ration.   [Note: To disambiguate, the whole statement might have to be
  examined to determine if it is an expression-statement or  a  declara-
  tion.   This  disambiguates  many examples.  [Example: assuming T is a
  simple-type-specifier (_dcl.type_),
          T(a)->m = 7;       // expression-statement
          T(a)++;            // expression-statement
          T(a,5)<<c;         // expression-statement
          T(*d)(int);        // declaration
          T(e)[5];           // declaration
          T(f) = { 1, 2 };   // declaration
          T(*g)(double(3));  // declaration
  In the last example above, g, which is a pointer to T, is  initialized
  to  double(3).  This is of course ill-formed for semantic reasons, but
  that does not affect the syntactic analysis.   --end example]

2 The remaining cases are declarations.  [Example:
          class T {
                  // ...
          public:
                  T();
                  T(int);
                  T(int, int);
          };
          T(a);         // declaration
          T(*b)();      // declaration
          T(c)=7;       // declaration
          T(d),e,f=3;   // declaration
          extern int h;
          T(g)(h,2);    // declaration
   --end example]  --end note]

3 The disambiguation is purely syntactic; that is, the  meaning  of  the
  names  occurring  in  such  a statement, beyond whether they are type-
  names or not, is not generally used in or changed by  the  disambigua-
  tion.  Class templates are instantiated as necessary to determine if a
  qualified name is a type-name.  Disambiguation precedes parsing, and a
  statement disambiguated as a declaration may be an ill-formed declara-
  tion.  If, during parsing, a name in a  template  parameter  is  bound
  differently  than  it would be bound during a trial parse, the program
  is ill-formed.  No diagnostic is required.  [Note: This can occur only
  when the name is declared earlier in the declaration.  ] [Example:

          struct T1 {
                  T1 operator()(int x) { return T1(x); }
                  int operator=(int x) { return x; }
                  T1(int) { }
          };
          struct T2 { T2(int){ } };
          int a, (*(*b)(T2))(int), c, d;
          void f() {
                  // dismabiguation requires this to be parsed
                  // as a declaration
                  T1(a) = 3,
                  T2(4),                  // T2 will be declared as
                  (*(*b)(T2(c)))(int(d)); // a variable of type T1
                                          // but this will not allow
                                          // the last part of the
                                          // declaration to parse
                                          // properly since it depends
                                          // on T2 being a type-name
          }
   --end example]

[...]

  8.2  Ambiguity resolution                              [dcl.ambig.res]

1 The ambiguity arising from the  similarity  between  a  function-style
  cast and a declaration mentioned in _stmt.ambig_ can also occur in the
  context of a declaration.  In that context, the choice  is  between  a
  function  declaration  with  a  redundant  set of parentheses around a
  parameter name and an object declaration with a function-style cast as
  the   initializer.    Just   as   for  the  ambiguities  mentioned  in
  _stmt.ambig_, the resolution is to consider any construct  that  could
  possibly  be a declaration a declaration.  [Note: a declaration can be
  explicitly disambiguated by a nonfunction-style cast, by a = to  indi-
  cate  initialization  or  by removing the redundant parentheses around
  the parameter name.  ] [Example:
          struct S {
              S(int);
          };
          void foo(double a)
          {
              S w(int(a));        // function declaration
              S x(int());         // function declaration
              S y((int)a);        // object declaration
              S z = int(a);       // object declaration
          }
   --end example]

2 The ambiguity arising from the  similarity  between  a  function-style
  cast  and  a  type-id  can occur in different contexts.  The ambiguity
  appears as a choice between a function-style  cast  expression  and  a
  declaration  of  a  type.   The  resolution is that any construct that
  could possibly be a type-id in its syntactic context shall be  consid-
  ered a type-id.

3 [Example:
          #include <cstddef>
          char *p;
          void *operator new(size_t, int);
          void foo()  {
                  const int x = 63;
                  new (int(*p)) int;      // new-placement expression
                  new (int(*[x]));        // new type-id
          }

4 For another example,

          template <class T>
          struct S {
          T *p;
          };
          S<int()> x;             // type-id
          S<int(1)> y;            // expression (ill-formed)

5 For another example,
          void foo()
          {
                  sizeof(int(1)); // expression
                  sizeof(int());  // type-id (ill-formed)
          }

6 For another example,
          void foo()
          {
                  (int(1));       // expression
                  (int())1;       // type-id (ill-formed)
          }
   --end example]

7 Another  ambiguity arises in a parameter-declaration-clause of a func-
  tion declaration, or in a type-id that is the operand of a  sizeof  or
  typeid  operator,  when a type-name is nested in parentheses.  In this
  case, the choice is between the declaration of  a  parameter  of  type
  pointer  to function and the declaration of a parameter with redundant
  parentheses around the declarator-id.  The resolution is  to  consider
  the  type-name as a simple-type-specifier rather than a declarator-id.
  [Example:
          class C { };
          void f(int(C)) { } // void f(int (*fp)(C c)) { }
                             // not: void f(int C);

          int g(C);

          void foo() {
                  f(1);    // error: cannot convert 1 to function ptr
                  f(g);    // OK
          }
  For another example,
          class C { };
          void h(int *(C[10]));  // void h(int *(*_fp)(C _parm[10]));
                                 // not: void h(int *C[10]);
   --end example]

Chyba tylko Perl jest trudniejszy do parsowania.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Marcin 'Qrczak' Kowalczyk wrote:
> RobertSzefler <NOSPAMrszeflerNOSPAM@murator.com.pl> writes:
> 
>>>        x * y; // co to za konstrukcja?
>>
>>Eee... a tu jest jakaś niejednoznaczność? To jest po prostu mnożenie x
>>przez y na moje oko.
> 
> To może być też definicja zmiennej y typu wskaźnik do x.

aaach! oczywiście ... to problem jak rozumiem pojawiający się dla ISO 
C99 (a dla jakich dialektów C++?)

> Wiesz, do czego używa się słowa kluczowego typename?

Oszczędź waść!

> Wiedziałbyś, że poniżej trzeba dodać w tym miejscu "template"?
> 
>           class X {
>           public:
>                   template<size_t> X* alloc();
>           };
>           void f(X* p)
>           {
>                   X* p1 = p->alloc<200>();
>                           // ill-formed: < means less than
> 
>                   X* p2 = p->template alloc<200>();
>                           // fine: < starts explicit qualification
>           }
> 
> Oto moje ulubione kwiatki z gramatyki C++:

No baaa....

>   6.8  Ambiguity resolution                                 [stmt.ambig]
> 
> 1 There is an ambiguity in the grammar  involving  expression-statements
>   and   declarations:  An  expression-statement  with  a  function-style
>   explicit type conversion (_expr.type.conv_) as its leftmost subexpres-
>   sion  can  be  indistinguishable  from  a  declaration where the first
>   declarator starts with a (.  In those cases the statement is a  decla-
>   ration.   [Note: To disambiguate, the whole statement might have to be
>   examined to determine if it is an expression-statement or  a  declara-
>   tion.   This  disambiguates  many examples.  [Example: assuming T is a
>   simple-type-specifier (_dcl.type_),
>           T(a)->m = 7;       // expression-statement
>           T(a)++;            // expression-statement
>           T(a,5)<<c;         // expression-statement
>           T(*d)(int);        // declaration
>           T(e)[5];           // declaration
>           T(f) = { 1, 2 };   // declaration
>           T(*g)(double(3));  // declaration
>   In the last example above, g, which is a pointer to T, is  initialized
>   to  double(3).  This is of course ill-formed for semantic reasons, but
>   that does not affect the syntactic analysis.   --end example]
> 
> 2 The remaining cases are declarations.  [Example:
>           class T {
>                   // ...
>           public:
>                   T();
>                   T(int);
>                   T(int, int);
>           };
>           T(a);         // declaration
>           T(*b)();      // declaration
>           T(c)=7;       // declaration
>           T(d),e,f=3;   // declaration
>           extern int h;
>           T(g)(h,2);    // declaration
>    --end example]  --end note]
> 
> 3 The disambiguation is purely syntactic; that is, the  meaning  of  the
>   names  occurring  in  such  a statement, beyond whether they are type-
>   names or not, is not generally used in or changed by  the  disambigua-
>   tion.  Class templates are instantiated as necessary to determine if a
>   qualified name is a type-name.  Disambiguation precedes parsing, and a
>   statement disambiguated as a declaration may be an ill-formed declara-
>   tion.  If, during parsing, a name in a  template  parameter  is  bound
>   differently  than  it would be bound during a trial parse, the program
>   is ill-formed.  No diagnostic is required.  [Note: This can occur only
>   when the name is declared earlier in the declaration.  ] [Example:
> 
>           struct T1 {
>                   T1 operator()(int x) { return T1(x); }
>                   int operator=(int x) { return x; }
>                   T1(int) { }
>           };
>           struct T2 { T2(int){ } };
>           int a, (*(*b)(T2))(int), c, d;
>           void f() {
>                   // dismabiguation requires this to be parsed
>                   // as a declaration
>                   T1(a) = 3,
>                   T2(4),                  // T2 will be declared as
>                   (*(*b)(T2(c)))(int(d)); // a variable of type T1
>                                           // but this will not allow
>                                           // the last part of the
>                                           // declaration to parse
>                                           // properly since it depends
>                                           // on T2 being a type-name
>           }
>    --end example]
> 
> [...]
> 
>   8.2  Ambiguity resolution                              [dcl.ambig.res]
> 
> 1 The ambiguity arising from the  similarity  between  a  function-style
>   cast and a declaration mentioned in _stmt.ambig_ can also occur in the
>   context of a declaration.  In that context, the choice  is  between  a
>   function  declaration  with  a  redundant  set of parentheses around a
>   parameter name and an object declaration with a function-style cast as
>   the   initializer.    Just   as   for  the  ambiguities  mentioned  in
>   _stmt.ambig_, the resolution is to consider any construct  that  could
>   possibly  be a declaration a declaration.  [Note: a declaration can be
>   explicitly disambiguated by a nonfunction-style cast, by a = to  indi-
>   cate  initialization  or  by removing the redundant parentheses around
>   the parameter name.  ] [Example:
>           struct S {
>               S(int);
>           };
>           void foo(double a)
>           {
>               S w(int(a));        // function declaration
>               S x(int());         // function declaration
>               S y((int)a);        // object declaration
>               S z = int(a);       // object declaration
>           }
>    --end example]
> 
> 2 The ambiguity arising from the  similarity  between  a  function-style
>   cast  and  a  type-id  can occur in different contexts.  The ambiguity
>   appears as a choice between a function-style  cast  expression  and  a
>   declaration  of  a  type.   The  resolution is that any construct that
>   could possibly be a type-id in its syntactic context shall be  consid-
>   ered a type-id.
> 
> 3 [Example:
>           #include <cstddef>
>           char *p;
>           void *operator new(size_t, int);
>           void foo()  {
>                   const int x = 63;
>                   new (int(*p)) int;      // new-placement expression
>                   new (int(*[x]));        // new type-id
>           }
> 
> 4 For another example,
> 
>           template <class T>
>           struct S {
>           T *p;
>           };
>           S<int()> x;             // type-id
>           S<int(1)> y;            // expression (ill-formed)
> 
> 5 For another example,
>           void foo()
>           {
>                   sizeof(int(1)); // expression
>                   sizeof(int());  // type-id (ill-formed)
>           }
> 
> 6 For another example,
>           void foo()
>           {
>                   (int(1));       // expression
>                   (int())1;       // type-id (ill-formed)
>           }
>    --end example]
> 
> 7 Another  ambiguity arises in a parameter-declaration-clause of a func-
>   tion declaration, or in a type-id that is the operand of a  sizeof  or
>   typeid  operator,  when a type-name is nested in parentheses.  In this
>   case, the choice is between the declaration of  a  parameter  of  type
>   pointer  to function and the declaration of a parameter with redundant
>   parentheses around the declarator-id.  The resolution is  to  consider
>   the  type-name as a simple-type-specifier rather than a declarator-id.
>   [Example:
>           class C { };
>           void f(int(C)) { } // void f(int (*fp)(C c)) { }
>                              // not: void f(int C);
> 
>           int g(C);
> 
>           void foo() {
>                   f(1);    // error: cannot convert 1 to function ptr
>                   f(g);    // OK
>           }
>   For another example,
>           class C { };
>           void h(int *(C[10]));  // void h(int *(*_fp)(C _parm[10]));
>                                  // not: void h(int *C[10]);
>    --end example]
> 
> Chyba tylko Perl jest trudniejszy do parsowania.
> 

A swoją drogą to ciekawe, że w praktyce ludzie uważają (do pewnego 
momentu) C++ za raczej prosty w nauce (szczególnie jeśli mają background 
np. w Pascalu czy Pythonie), zupełnie to się oczywiście kłuci z poziomem 
komplikacji tego piekielnego języka...

RobertSzefler <NOSPAMrszeflerNOSPAM@murator.com.pl> writes:

>>>>        x * y; // co to za konstrukcja?
>>>
>>>Eee... a tu jest jakaś niejednoznaczność? To jest po prostu mnożenie x
>>>przez y na moje oko.
>> To może być też definicja zmiennej y typu wskaźnik do x.
>
> aaach! oczywiście ... to problem jak rozumiem pojawiający się dla ISO
> C99 (a dla jakich dialektów C++?)

Problem pojawia się we wszystkich wersjach C, które miały już
konstrukcję typedef, i w C++.

W C niejednoznaczność może być zawsze rozstrzygnięta przez kompilator
na podstawie kontekstu: parser musi tylko wiedzieć, które identyfikatory
oznaczają typy, a które nie.

W C++ szablony nakładają nową trudność. "Identyfikator" nie musi
być globalny, może być kwalifikowany nazwą klasy, a klasa może być
ukonkretnieniem szablonu. Czyli żeby rozstrzygnąć, jak to parsować,
trzeba konkretyzować szablony. Co w ogólności może być niemożliwe,
jeśli kod jest umieszczony w innym szablonie i to, czym konkretyzuje
tamten szablon, zależy od jego parametru, czyli jeszcze nie jest znane.

Stąd typename, żeby ujednoznacznił to programista. A kompilator musi
to sobie tak zorganizować, że jedne ukonkretnienia szablonów są
wykonywane od razu, a inne są odraczane, aż będą znane parametry.

Podobnie ze sprawdzaniem typów: jeśli jesteśmy w szablonie, to jedne
wyrażenia mają typ obliczany od razu, a inne są odraczane, zależnie
od tego, czy ten typ może zależeć od parametrów szablonu. Określanie
tych typów, które się da, od razu, jest o tyle potrzebne, że semantyka
C++ uzależnia przestrzenie wyszukiwania identyfikatorów od typów
(m.in. tzw. Koenig lookup). Jeśli typy są znane w czasie przetwarzania
szablonu, to identyfikatory są wyszukiwane w przestrzeniach nazw
wyznaczonych przez te typy i zależnych tylko od miejsca definicji
szablonu, a jeśli nie są znane, to wszystko jest odraczane, a przy
konkretyzacji szablonu identyfikatory są wyszukiwane zarówno
w miejscach zależnych od kontekstu definicji szablonu, jak i od
kontekstu użycia.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

RobertSzefler wrote:
>> Z punktu widzenia implementowania systemu typów Haskell 98 jest
>> o wiele prostszy niż C++.
>> 
>> Problem w tym, że GHC ma wiele eksperymentalnych rozszerzeń systemu
>> typów, zwłaszcza dotyczących klas, nad których implementacją panuje
>> chyba tylko Simon Peyton Jones.
>
> Hmm. Nie byłbym taki pewny. A co, jeśli by zaimplementować, dla 
> sprawiedliwości, typecheckera do C++ w Haskellu i do Haskella w 
> Haskellu? Robił ktoś kiedyś coś takiego?

"Do Haskella w Haskellu" juz jest kilka, np. w GHC, na narzedziach
Programmatica, w pracy "Typing Haskell in Haskell" Marka P. Jonesa. Nie
chodzilo Ci przypadkiem o "do Haskella w C++"?

Jako jeden z przyszlych projektow przewiduje biblioteke do generowania
kodu C/C++ z Haskella (szablony i makra C++ nie do konca sie
sprawdzaja). Mozliwosci parsowania C++ tez by sie przydaly, chocby w
ograniczonym zakresie. Nie wykluczone, ze w przyszlosci dodane zostanie
tez sprawdzanie typow. Moze ktos jest chetny?

Pozdrawiam
Tomasz

-- 
I am searching for programmers who are good at least in
(Haskell || ML) && (Linux || FreeBSD || math)
for work in Warsaw, Poland

Michal Przybylek wrote:
> "RobertSzefler" <NOSPAMrszeflerNOSPAM@murator.com.pl> wrote:
>
>> BTW zdarza Ci się używać innych rzeczy monadycznych
>
> Nagminnie, cala filozofia Haskell'u zbudowana jest w oparciu o pojecie
> monady.

Jak sie chce, to mozna napisac duzy, ciekawy program w ogole nie
uzywajac monad. Oczywiscie zakres mozliwych zastosowan mocno sie
zmniejszy - to bedzie program typu "czytaj stdin, przetwarzaj, pisz na
stdout".

Mozna tez niektorych implementacji Haskella uzywac jako takiego
wypasionego kalkulatora.

Pozdrawiam
Tomasz

-- 
I am searching for programmers who are good at least in
(Haskell || ML) && (Linux || FreeBSD || math)
for work in Warsaw, Poland

poniedziałek, 02 sty, Przemek Pokrywka:
> Jestem nowy w temacie języków funkcyjnych - w jakich zastosowaniach 
> spisują się one najlepiej?

Właśnie uczestniczę w takim małym projekcie, którego celem jest stworzenie
symulatora pewnego modelu obliczeń mobilnych. Model jest zdefiniowany
matematycznie. Implementacja jądra symulatora została wykonana w Haskellu
(choć na początku Haskell miał służyć tylko do stworzenia prototypu).

Do takiego zastosowania język funkcyjny jest narzędziem doskonałym -- dlatego,
że specyfikacja tego, co mamy zrobić, jest opisana matematycznie, a
tłumaczenie definicji matematycznych na język funkcyjny jest proste. Można
wtedy spojrzeć na program jak na specyfikację, która przy okazji jest
wykonywalna.

Może trochę przesadzam z tą prostotą tłumaczenia, no i dobrze zmodularyzowany
program musi mieć inną strukturę, niż tekst specyfikacji matematycznej, ale
pisząc symulator często się zdarzało, że nie musiałem dokładnie rozumieć, o co
chodzi w niektórych definicjach, wystarczyło je dokładnie przetłumaczyć na
Haskella!

Artur Siekielski wrote:
> poniedziałek, 02 sty, Przemek Pokrywka:
>> Jestem nowy w temacie języków funkcyjnych - w jakich zastosowaniach 
>> spisują się one najlepiej?
>
> Właśnie uczestniczę w takim małym projekcie, którego celem jest stworzenie
> symulatora pewnego modelu obliczeń mobilnych. Model jest zdefiniowany
> matematycznie. Implementacja jądra symulatora została wykonana w Haskellu
> (choć na początku Haskell miał służyć tylko do stworzenia prototypu).

Mozna dowiedziec sie czegos wiecej, np. czy to projekt komercyjny czy
akademicki? opensource?

Pozdrawiam
Tomasz

-- 
I am searching for programmers who are good at least in
(Haskell || ML) && (Linux || FreeBSD || math)
for work in Warsaw, Poland

czwartek, 19 sty, Tomasz Zielonka:
>>> Jestem nowy w temacie języków funkcyjnych - w jakich zastosowaniach 
>>> spisują się one najlepiej?
>> Właśnie uczestniczę w takim małym projekcie, którego celem jest stworzenie
>> symulatora pewnego modelu obliczeń mobilnych. Model jest zdefiniowany
>> matematycznie. Implementacja jądra symulatora została wykonana w Haskellu
>> (choć na początku Haskell miał służyć tylko do stworzenia prototypu).
> Mozna dowiedziec sie czegos wiecej, np. czy to projekt komercyjny czy
> akademicki? opensource?

Jest to projekt akademicki, robiony w Instytucie Podstaw Informatyki PAN w
Sopocie. Kod źródłowy nie jest w tej chwili udostępniany, ale myślę, że nie
byłoby z tym problemu.

Sam model matematyczny to hipersieci Petriego. Ma on tę zaletę nad podobnymi
formalizmami, że można stosować model checking. Pierwsza wersja naiwnego model
checkera została stworzona w Haskellu, jednak w tym wypadku sprawa wydajności
okazała się kluczowa, a ciężko robić optymalizacje w leniwym Haskellu czy
choćby wnioskować, co się aktualnie oblicza. Sprawa jest dziwna, bo szacując
matematycznie ilość potrzebnych obliczeń w pewnym przykładzie nie wychodzi ich
dużo, a Haskell oblicza to długo. Problemem jest zapewne wielokrotne
wykonywanie tych samych obliczeń (dlaczego nie ma prostego sposobu na
"function memoization"?!), ale mimo użycia profilera nie udało mi się znaleźć
tych kluczowych miejsc...

Ostatecznie ma być użyty lepszy algorytm modelcheckujący (co nie jest
trywialne, bo logika modelu jest niestandardowa), a model checker ma być
przepisany na coś imperatywnego (Java...).

Symulator jest skonstruowany następująco: model jest zaimplementowany w
Haskellu, wyświetlanie modelu jest realizowane przez program uDrawGraph,
służący do wyświetlania i edytowania grafów, a połączenie pomiędzy Haskellem a
uDrawGraphem jest napisane w Javie. Niestety połączenie Haskella z Javą jest
robione przez stdout/stdin, ponieważ nie udało mi się znaleźć działającego
sposobu na wywoływanie Haskella z Javy (w drugą stronę o dziwo się da).

Gdybym dzisiaj miał decydować o języku implementacji, byłbym za jakimś MLem,
bo miałbym tę samą ekspresywność, a język jest bardziej praktyczny (i chyba
nawet są jakieś MLe kompilowane do bajtkodu JVM...). Aha, pisząc w Haskellu
dosięgła nas następująca zmora: okazało się, że żeby zrobić "coś", trzeba
wprowadzić monadę, co wymagałoby przepisania praktycznie całego programu
(oczywiście ze zmianą wszystkich typów funkcji włącznie)...

Artur Siekielski wrote:
> Jest to projekt akademicki, robiony w Instytucie Podstaw Informatyki PAN w
> Sopocie. Kod źródłowy nie jest w tej chwili udostępniany, ale myślę, że nie
> byłoby z tym problemu.

Chetnie bym sobie obejrzal.

> Sam model matematyczny to hipersieci Petriego. Ma on tę zaletę nad podobnymi
> formalizmami, że można stosować model checking.

Slyszalem termin "model checking" wczesniej, ale dopiero teraz
sprawdzilem, co to jest, i nie jestem pewien, czy rozumiem. Moglbys
napisac, dlaczego to jest fajne, np. w Waszym zastosowaniu? ;-) Ostatnio
w mojej pracy coraz czesciej przydaja mi sie takie "akademickie"
techniki jak np. "partial evaluation", czy "abstract interpretation"
(jesli dobrze zidentyfikowalem ;-) - moze warto byloby sie i z ta
zapoznac.

> Pierwsza wersja naiwnego model checkera została stworzona w Haskellu,
> jednak w tym wypadku sprawa wydajności okazała się kluczowa, a ciężko
> robić optymalizacje w leniwym Haskellu czy choćby wnioskować, co się
> aktualnie oblicza. Sprawa jest dziwna, bo szacując matematycznie ilość
> potrzebnych obliczeń w pewnym przykładzie nie wychodzi ich dużo, a
> Haskell oblicza to długo.

Moze mieliscie space-leak? Najczestsze objawy to duze zuzycie pamieci i
czas GC dominujacy w czasie dzialania programu.

> Problemem jest zapewne wielokrotne wykonywanie tych samych obliczeń
> (dlaczego nie ma prostego sposobu na "function memoization"?!), ale
> mimo użycia profilera nie udało mi się znaleźć tych kluczowych
> miejsc...

Moze poproscie o pomoc na haskell-cafe@haskell.org?

> Ostatecznie ma być użyty lepszy algorytm modelcheckujący (co nie jest
> trywialne, bo logika modelu jest niestandardowa), a model checker ma być
> przepisany na coś imperatywnego (Java...).

Au! Moze da sie temu jakos zapobiec? ;-)

> Symulator jest skonstruowany następująco: model jest zaimplementowany w
> Haskellu, wyświetlanie modelu jest realizowane przez program uDrawGraph,
> służący do wyświetlania i edytowania grafów, a połączenie pomiędzy Haskellem a
> uDrawGraphem jest napisane w Javie. Niestety połączenie Haskella z Javą jest
> robione przez stdout/stdin, ponieważ nie udało mi się znaleźć działającego
> sposobu na wywoływanie Haskella z Javy (w drugą stronę o dziwo się da).

stdin/stdout nie jest takie zle - moze zwiekszyc modularnosc, ale
kosztem wydajnosci.

> Gdybym dzisiaj miał decydować o języku implementacji, byłbym za jakimś MLem,
> bo miałbym tę samą ekspresywność, a język jest bardziej praktyczny (i chyba
> nawet są jakieś MLe kompilowane do bajtkodu JVM...). Aha, pisząc w Haskellu
> dosięgła nas następująca zmora: okazało się, że żeby zrobić "coś", trzeba
> wprowadzić monadę, co wymagałoby przepisania praktycznie całego programu
> (oczywiście ze zmianą wszystkich typów funkcji włącznie)...

No coz, zdaza sie. Nigdy nie mialem az tak bolesnego przypadku - moze
dlatego, ze dosyc szybko zaczynam uzywac monad, tzn. kiedy widze, ze to
moze ulatwic, a nie dopiero wtedy, kiedy jest juz konieczne.

PS. Duze masz/macie doswiadczenie w uzywaniu Haskella? Przyznaje,
    ze mi osiagniecie stanu pozwalajacego wygodnie rozwiazywac
    typowe praktyczne problemy zajelo chyba ze dwa lata, ale
    wiem, ze niektorym przychodzi to szybciej.

Pozdrawiam
Tomasz

-- 
I am searching for programmers who are good at least in
(Haskell || ML) && (Linux || FreeBSD || math)
for work in Warsaw, Poland

piątek, 20 sty, Tomasz Zielonka:
>> Jest to projekt akademicki, robiony w Instytucie Podstaw Informatyki PAN w
>> Sopocie. Kod źródłowy nie jest w tej chwili udostępniany, ale myślę, że nie
>> byłoby z tym problemu.
> Chetnie bym sobie obejrzal.

Postaram się udostępnić źródła w przyszłym tygodniu, dam znać.

>> Sam model matematyczny to hipersieci Petriego. Ma on tę zaletę nad podobnymi
>> formalizmami, że można stosować model checking.
> Slyszalem termin "model checking" wczesniej, ale dopiero teraz
> sprawdzilem, co to jest, i nie jestem pewien, czy rozumiem. Moglbys
> napisac, dlaczego to jest fajne, np. w Waszym zastosowaniu? ;-) Ostatnio
> w mojej pracy coraz czesciej przydaja mi sie takie "akademickie"
> techniki jak np. "partial evaluation", czy "abstract interpretation"
> (jesli dobrze zidentyfikowalem ;-) - moze warto byloby sie i z ta
> zapoznac.

Model checking to algorytm sprawdzania spełnialności formuły logicznej w
systemach ze skończoną liczbą stanów. Najprostszy przykład formuły to np. "w
każdym stanie s zachodzi: s(x) > 0". Naiwna implementacja sprawdzenia
spełnialności tej formuły polegałaby na przejrzeniu wszystkich stanów systemu
i sprawdzeniu, czy ta własność w każdym z nich zachodzi. Jednak istnieją różne
skomplikowane techniki model-checkowania które umożliwiają działanie na
ogromnych systemach, np. o liczbie stanów równej 10^100, co oczywiście nie
jest możliwe przy naiwnych algorytmach.

Inne formuły, które można modelcheckować, to np. "nie istnieje ścieżka
wykonania (ciąg stanów) prowadząca do dead-locku" albo "jeśli s(x) = 0, to w
którymś stanie s' następującym po s zajdzie s'(x) != 0".

Jeżeli chodzi o zastosowania, to model checking jest popularny w
zastosowaniach sprzętowych (bo hardware ma skończoną liczbę stanów i można w
miarę łatwo go opisać w sposób zrozumiały dla algorytmów modelcheckujących), a
nie nadaje się do zwykłych programów (nieskończona lub za duża liczba stanów).

Model checking jest podobny do testowania -- w testowaniu też badamy prawdziwość
jakiejś formuły w danym modelu (systemie), tyle, że dotyczy ona niewielkiego
podzbioru stanów. Model checking jest czymś innym niż specyfikacje formalne,
bo specyfikacja opisuje klasę modeli, a model checking wymaga podania jakiegoś
konkretnego modelu i zbioru formuł, które ten model musi spełniać.

W naszym projekcie model checking jest rzeczą wartościową, bo nasz model
obliczeń mobilnych jest stosunkowo wysokopoziomowy, strukturalny, a przy
takich własnościach niełatwo jest zachować skończoność systemu.

>> Pierwsza wersja naiwnego model checkera została stworzona w Haskellu,
>> jednak w tym wypadku sprawa wydajności okazała się kluczowa, a ciężko
>> robić optymalizacje w leniwym Haskellu czy choćby wnioskować, co się
>> aktualnie oblicza. Sprawa jest dziwna, bo szacując matematycznie ilość
>> potrzebnych obliczeń w pewnym przykładzie nie wychodzi ich dużo, a
>> Haskell oblicza to długo.
> Moze mieliscie space-leak? Najczestsze objawy to duze zuzycie pamieci i
> czas GC dominujacy w czasie dzialania programu.

Nie pamiętam, czy profiler pokazywał jakieś informacje o GC... A powinien?

>> Problemem jest zapewne wielokrotne wykonywanie tych samych obliczeń
>> (dlaczego nie ma prostego sposobu na "function memoization"?!), ale
>> mimo użycia profilera nie udało mi się znaleźć tych kluczowych
>> miejsc...
> Moze poproscie o pomoc na haskell-cafe@haskell.org?

Może powinniśmy. Choć teraz, gdy w planach jest porzucenie tej implementacji,
chyba szkoda na to czasu.

>> Ostatecznie ma być użyty lepszy algorytm modelcheckujący (co nie jest
>> trywialne, bo logika modelu jest niestandardowa), a model checker ma być
>> przepisany na coś imperatywnego (Java...).
> Au! Moze da sie temu jakos zapobiec? ;-)

Oj nie wiem :). Do Javy czy C są zaawansowane biblioteki używane w model
checkingu, do Haskella niby też można je podłączyć (przez jakiś "foreign
interface"), ale przeglądałem artykuł, w którym opisano takie rozwiązanie i
było ono bardzo wolne. A wydajność jest jednak sprawą kluczową... Poza tym
chciałbym mieć kontrolę nad czasem obliczania.

Za to część symulatorowa na pewno pozostanie w Haskellu (co ciekawe nie ma
problemu z wydajnością, mimo, że matematyczna złożoność obliczeń jest grubo
ponad wykładnicza :) ).

>> Gdybym dzisiaj miał decydować o języku implementacji, byłbym za jakimś MLem,
>> bo miałbym tę samą ekspresywność, a język jest bardziej praktyczny (i chyba
>> nawet są jakieś MLe kompilowane do bajtkodu JVM...). Aha, pisząc w Haskellu
>> dosięgła nas następująca zmora: okazało się, że żeby zrobić "coś", trzeba
>> wprowadzić monadę, co wymagałoby przepisania praktycznie całego programu
>> (oczywiście ze zmianą wszystkich typów funkcji włącznie)...
> No coz, zdaza sie. Nigdy nie mialem az tak bolesnego przypadku - moze
> dlatego, ze dosyc szybko zaczynam uzywac monad, tzn. kiedy widze, ze to
> moze ulatwic, a nie dopiero wtedy, kiedy jest juz konieczne.

Moze po prostu mamy za małe doświadczenie w Haskellu.

> PS. Duze masz/macie doswiadczenie w uzywaniu Haskella? Przyznaje,
>     ze mi osiagniecie stanu pozwalajacego wygodnie rozwiazywac
>     typowe praktyczne problemy zajelo chyba ze dwa lata, ale
>     wiem, ze niektorym przychodzi to szybciej.

Ja nie mam za dużego praktycznego doświadczenia. Ten projekt to największa
rzecz, jaką robiłem w języku funkcyjnym. Choć z językami funkcyjnymi zetknąłem
się jeszcze w liceum (dzięki grupom dyskusyjnym, a ściślej - Qrczakowi), a
przez okres studiów nie tracę z nimi kontaktu (nie ma to jak metody numeryczne
w Haskellu :) ). Myślę, że pomogła mi matematyka na studiach (podobny sposób
myślenia o problemie) i takie książki, jak "Struktura i interpretacja
programów komputerowych". Tak więc pisanie symulatora i model checkera było
całkiem przyjemne :).

Artur Siekielski <gruesome@REMOVEpoczta.onet.pl> writes:

[...]

> Aha, pisząc w Haskellu dosięgła nas następująca zmora: okazało się,
> że żeby zrobić "coś", trzeba wprowadzić monadę, co wymagałoby
> przepisania praktycznie całego programu (oczywiście ze zmianą
> wszystkich typów funkcji włącznie)...

O, o, o.  Czyli programy haskellowe są trudne w modyfikacji?
Pytam, bo nie wiem, a akurat próbuję 'siedzieć' w refaktoryzacji.

Artur Siekielski wrote:
> piątek, 20 sty, Tomasz Zielonka:
>> Chetnie bym sobie obejrzal.
>
> Postaram się udostępnić źródła w przyszłym tygodniu, dam znać.

To moze przy okazji przygotuj przyklad pokazujacy wspomniana
nieefektywnosc. Postaram sie temu przyjrzec.

> Model checking to algorytm sprawdzania spełnialności formuły logicznej w
> systemach ze skończoną liczbą stanów. Najprostszy przykład formuły to np. "w
> każdym stanie s zachodzi: s(x) > 0". Naiwna implementacja sprawdzenia
> spełnialności tej formuły polegałaby na przejrzeniu wszystkich stanów systemu
> i sprawdzeniu, czy ta własność w każdym z nich zachodzi. Jednak istnieją różne
> skomplikowane techniki model-checkowania które umożliwiają działanie na
> ogromnych systemach, np. o liczbie stanów równej 10^100, co oczywiście nie
> jest możliwe przy naiwnych algorytmach.
> 
> [..]

Dzieki za opis. Kolejna rzecz warta blizszego poznania :-)

>> Moze mieliscie space-leak? Najczestsze objawy to duze zuzycie pamieci i
>> czas GC dominujacy w czasie dzialania programu.
>
> Nie pamiętam, czy profiler pokazywał jakieś informacje o GC... A powinien?

W przypadku GHC podstawowe statystyki mozna uzyskac uruchamiajac z opcja
+RTS -sstderr -RTS. Z bardziej rozbudowanych rzeczy - w biograficznym
profilowaniu pamieci warto zwocic uwage na udzial obiektow ze stanem LAG
(ale nie pamietam szczegolow).

>> Moze poproscie o pomoc na haskell-cafe@haskell.org?
>
> Może powinniśmy. Choć teraz, gdy w planach jest porzucenie tej implementacji,
> chyba szkoda na to czasu.

Czy to aby dobry pomysl? Haskell jest teraz na drugim miejscu w
    http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
OK, OK, sam nie przywiazuje zbyt wielkiej wagi do takich benchmarkow.

> Oj nie wiem :). Do Javy czy C są zaawansowane biblioteki używane w model
> checkingu, do Haskella niby też można je podłączyć (przez jakiś "foreign
> interface"), ale przeglądałem artykuł, w którym opisano takie rozwiązanie i
> było ono bardzo wolne. A wydajność jest jednak sprawą kluczową... Poza tym
> chciałbym mieć kontrolę nad czasem obliczania.

No coz, Twoja decyzja ;-)

> Ja nie mam za dużego praktycznego doświadczenia. Ten projekt to największa
> rzecz, jaką robiłem w języku funkcyjnym. Choć z językami funkcyjnymi zetknąłem
> się jeszcze w liceum (dzięki grupom dyskusyjnym, a ściślej - Qrczakowi), a
> przez okres studiów nie tracę z nimi kontaktu (nie ma to jak metody numeryczne
> w Haskellu :) ).

Mieliscie metody numeryczne w Haskellu? Na jakiej uczelni?

Pozdrawiam
Tomasz

-- 
I am searching for programmers who are good at least in
(Haskell || ML) && (Linux || FreeBSD || math)
for work in Warsaw, Poland

sobota, 21 sty, Piotr Dembiński:
>> Aha, pisząc w Haskellu dosięgła nas następująca zmora: okazało się,
>> że żeby zrobić "coś", trzeba wprowadzić monadę, co wymagałoby
>> przepisania praktycznie całego programu (oczywiście ze zmianą
>> wszystkich typów funkcji włącznie)...
> O, o, o.  Czyli programy haskellowe są trudne w modyfikacji?
> Pytam, bo nie wiem, a akurat próbuję 'siedzieć' w refaktoryzacji.

To, o czym piszę, jest rzeczywistym problemem. Np. tutaj:
http://www.docs.uu.se/~leucker/Documents/Leucker/Truth_Haskell.ps.gz jest opis
innego systemu do model checkingu zrobiony w Haskellu, w punkcie 4.3 opisują
podobny problem: powstała konieczność wprowadzenia monady, ale nie chcieli
przepisywać całości, więc użyli funkcji 'unsafeperformIO' i piszą: "...we had
to add some hacks to ensure the evaluation of the unsafeperformIO function in
the presence of the lazy strategy".

sobota, 21 sty, Tomasz Zielonka:
>>> Chetnie bym sobie obejrzal.
>> Postaram się udostępnić źródła w przyszłym tygodniu, dam znać.
> To moze przy okazji przygotuj przyklad pokazujacy wspomniana
> nieefektywnosc. Postaram sie temu przyjrzec.

Tylko nie wiem, czy jest sens dużo czasu na to poświęcać, bo nawet, jeżeli uda
się przyspieszyć implementację, to i tak będzie ona nieużywalna, bo użyty
algorytm ma ogromną złożoność matematyczną. No chyba że po to, żeby nauczyć
się zachowania Haskella...

>>> Moze mieliscie space-leak? Najczestsze objawy to duze zuzycie pamieci i
>>> czas GC dominujacy w czasie dzialania programu.
>>
>> Nie pamiętam, czy profiler pokazywał jakieś informacje o GC... A powinien?
> W przypadku GHC podstawowe statystyki mozna uzyskac uruchamiajac z opcja
>+RTS -sstderr -RTS. Z bardziej rozbudowanych rzeczy - w biograficznym
> profilowaniu pamieci warto zwocic uwage na udzial obiektow ze stanem LAG
> (ale nie pamietam szczegolow).

Dzięki, postaram się to zapuścić.

>>> Moze poproscie o pomoc na haskell-cafe@haskell.org?
>>
>> Może powinniśmy. Choć teraz, gdy w planach jest porzucenie tej implementacji,
>> chyba szkoda na to czasu.
> Czy to aby dobry pomysl? Haskell jest teraz na drugim miejscu w
>     http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all

Tylko nie po to piszę w Haskellu, żeby pisać kod taki jak w tych
benchmarkowanych programach (mallocArray itd.)!

> OK, OK, sam nie przywiazuje zbyt wielkiej wagi do takich benchmarkow.

>> Oj nie wiem :). Do Javy czy C są zaawansowane biblioteki używane w model
>> checkingu, do Haskella niby też można je podłączyć (przez jakiś "foreign
>> interface"), ale przeglądałem artykuł, w którym opisano takie rozwiązanie i
>> było ono bardzo wolne. A wydajność jest jednak sprawą kluczową... Poza tym
>> chciałbym mieć kontrolę nad czasem obliczania.
> No coz, Twoja decyzja ;-)

Nie tylko moja... Ale może jeszcze zdecydujemy się na MLa.

>> Ja nie mam za dużego praktycznego doświadczenia. Ten projekt to największa
>> rzecz, jaką robiłem w języku funkcyjnym. Choć z językami funkcyjnymi zetknąłem
>> się jeszcze w liceum (dzięki grupom dyskusyjnym, a ściślej - Qrczakowi), a
>> przez okres studiów nie tracę z nimi kontaktu (nie ma to jak metody numeryczne
>> w Haskellu :) ).
> Mieliscie metody numeryczne w Haskellu? Na jakiej uczelni?

Zadania z metod numerycznych można było implementować w dowolnym języku. Ja to
robiłem w Haskellu, OCamlu i Pythonie :).

Piotr Dembiński wrote:
> Artur Siekielski <gruesome@REMOVEpoczta.onet.pl> writes:
>
> [...]
>
>> Aha, pisząc w Haskellu dosięgła nas następująca zmora: okazało się,
>> że żeby zrobić "coś", trzeba wprowadzić monadę, co wymagałoby
>> przepisania praktycznie całego programu (oczywiście ze zmianą
>> wszystkich typów funkcji włącznie)...
>
> O, o, o.  Czyli programy haskellowe są trudne w modyfikacji?
> Pytam, bo nie wiem, a akurat próbuję 'siedzieć' w refaktoryzacji.

To nie jest takie proste. Problem, o jakim pisze Artur, pojawia
sie, kiedy napiszesz duzo czysto-funkcyjnego kodu, bez uzycia
monad. To, ze napisales tak duzo kodu w tym stylu, moze byc zwiazane z
natura problemu - tym, ze latwo bylo go zapisac matematycznie. Byc moze
gdyby nie czysto-funkcyjny styl Haskella w ogole bys tak daleko nie
zaszedl (czasem sam mam takie wrazenie). Byc moze w innym jezyku nie
mialbys tego problemu, bo w ogole nie mialbys kodu... ;-)

Oczywiscie troche przesadzam. Jestem pewien, ze Artur jest w stanie
rozwiazac swoj problem w innym jezyku. Szczegolnie, ze w innym jezyku
moze byc latwiej wnioskowac o wydajnosci.

Przy dobrej modularyzacji programu jest szansa, ze jesli pojawi
sie potrzeba wprowadzenia monad, to zmiany beda dosyc ograniczone.
Ostatnio jak wprowadzalem taka zmiane w kodzie wczytujacym dane z bazy
(dla zwiekszenia wydajnosci) udalo mi sie to zrobic przez kilka
refaktoryzacji poprawiajacych modularyzacje - potem wlasciwa zmiana
sposobu dzialania dotyczyla kilku linijek w jednej funkcji.

No i taka potrzeba wcale nie musi zajsc - mi przydazylo sie pare
razy, i nigdy nie bylo to duzo pracy. Ale juz mowilem, ze lubie
monady i dosyc wczesnie je wprowadzam ;-)

Pozdrawiam
Tomasz

-- 
I am searching for programmers who are good at least in
(Haskell || ML) && (Linux || FreeBSD || math)
for work in Warsaw, Poland