🚀 go-pugleaf

Piotr Sawicki wrote:
> Sebastian Kaliszewski powiada:
> 
>> Zobacz jak wygląda standardowa callcc (uups, w 1.9 jest w pewnym sensie 
>> "deprecated", trzeba ją specjalnie aktywować, bo poważnie spowalnia 
>> interpreter). "Kultura języka" zachęca do zapisania kontynuacji w 
>> zmiennej globalnej.
> 
> Używanie zmiennych globalnych to nie jest problem nad wykryciem
> którego trzeba ślęczeć godzinami, widać od razu po kodzie.

W miejscu użycia (mówimy o typowych przedstawicielach języków 
dynamicznych -- w każdym z nich możesz sobie zmienną globalną łatwo 
utworzyć lokalnie). Brak try/except widać tak samo.

>>> W Lispie czy Smalltalku jakoś ma sens.
>> Mowa o wartości dodanej w postaci statycznej kontroli obsłużenia błędów. 
>> Po co naglke statyczna kontrola w języku dynamicznym. 
> 
> To akurat proste: żeby zapobiec problemom zanim wyjdą w praniu.

To po co w ogóle język dynamiczny?

Chcesz mieć ciastko i zjeść ciastko...


>> Lisp jest stary jak progtramowanie wysokopoziomowe. 
>> W Smalltalku -- kolejnym minimalistycznym języku -- 
>> kontynuacje służą do paru innych rzeczy, 
> 
> Służą m.in. do obsługi błędów właśnie.

Służą do wielu innych rzeczy, w tym paru pierwszorzędnych (jak 
podstawowe konstrukcje sterujące, błędy to idą "przy okazji")

> Nie bardzo rozumiem co masz
> na myśli - kontrprzykłady są niewłaściwe z powodu wieku i minimalizmu? 

To mam na myśli, że pełnią rolę konstrukcji podstawowej -- w jednych 
językach może ją pełnić if i goto, w innych wywołanie (rekurencyjne) 
funkcji oraz pattern matching, w innych while/if/for, w innych 
SLD-rezolucja, itd...

> 
>>>>> Stosowanie wyjątków, przy wszystkich zaletach, powoduje że nietrywialne 
>>>>> staje się statyczne sprawdzenie, czy obsłużono wszystkie rzucane błędy.
>>>> Eee.. jest tak samo trywialne/nietrywialne jak w przypadku monad / 
>>>> kontynuacji. 
>>> No właśnie nie - pod tym względem wyjątki nie są łatwiejsze w pilnowaniu 
>>> nawet od obsługi błędów przez zwracanie funkcją kodu błędu i sprawdzaniu
>>> tego ifami. Tzn. w najlepszym przypadku można każdy call obstawić własnym 
>>> try-catchem (co podpada już pod brzytwę Ockhama).
>> Po pierwsze właśnie są przez to, że nie trzeba każdego calla obstawiać 
>> własnym try-except (przypominam, że to grupa pythonowa a nie 
>> C-cokolwiek) jest łatwiej.
> 
> Łatwiej jest napisać badziewiasty kod, po którym kompletnie nie wiadomo
> czy obsługę sytuacji wyjątkowych już zaimplementowano i czy prawidłowo.

To samo masz w pozostałych przypadkach. Od kilku postów nie mogę się 
doprosić pokazania wartości dodanej.

> 
>> Po drugie nadal pytam o wartość dodaną kontynuacji pod tym względem?
> 
> Proste pilnowanie obsługi błędów.

Przecież ci pokazałem jak to (nie) działa. Tzn. rółnie łatwo jest to 
zrobić zupełnie do bani, choć formalnie poprawnie.

> 
>>>> try:
>>>>    whole_program()
>>>> except BaseException:
>>>>    wszystko_obsłużone()
>>>>
>>>> Mamy wszystko obsłużone ale do prawdy niewiele z tego 
>>>> "wszystko-obsłużenia" wynika.
>>> Przecież to nie jest obsługa błędów.
>> Przecież tyle samo daje zapisanie sobie kontynuacji "gdzieś globlanie". 
> 
> Podałeś przypadek w którym każdy wariant jest równie zły,
> to nie stanowi argumentu w żadną stronę.

To pokaż przypadek w którym jeden jest istotnie lepszy.

> 
>> nicym nie różni się od statycznej kontroli specyfikacji wyjątków 
>> (włączenia specyfikacji wyjątków do statycznie sprawdzanej sygnatury 
>> funkcji) w Javie. To co jest w Javie jest dość powszechnie krytykowane, 
>> bo poza wymuszaniem dodatkowego klepania sprowadza się do konstrukcji 
>> jak powyżej, 
> 
> Dlatego napisałem że korzyści widzę w zapewnianiu jakości (a Ty ich
> wypatrujesz w kodowaniu). Zawsze można źle zaprogramować, tylko że
> w przypadku niejawnego przepływu sterowania bardzo trudno to wychwycić 
> i jest masa roboty z poprawianiem, wymaga to analizy całego kodu.

W Javie masz jawny przepływ sterowania -- wyjątki są częścią sygnatur 
funkcji. I jak widać to marnie działa i sprowadzane jest bez 
najmniejszego trudu do przypadku try { whole_program(); } catch 
(everything).


>>> Widziałem np. narzekania na szkodliwy wpływ nauki Pythona i Haskella
>>> na wydajność pisania w C# - uzasadniany tym, że C# co prawda jest
>>> całkiem niezły i ma dużo zaawansowanych cech, ale sabotażują ich 
>>> wykorzystanie imperatywnie zaprojektowane biblioteki. 
>> To samo masz w światku popularnych języków dynamicznych. W Rubim 
>> wycofują się rakiem, do Pythona nie dodali (IMHO słusznie, bo ciągle nie 
>> mogę dojrzeć tej wartości dodanej).
> 
> To akurat było o funkcyjności i braku efektów ubocznych, a chodziło
> nie o wykorzystanie komercyjne tylko dydaktyczne (że pobawienie się
> dobrym językiem powinno uczyć dobrych nawyków w czym tam musisz klepać).
>  
>> Cóż, Haskell to taki język którego czasem ktoś sobie dla zabawy użyje, 
>> ale niezabawowe użycia praktycznie poza akademię nie wychodzą. Od lat.
> 
> Jeśli powodu upatrujesz w cechach języka, to jak w ramach tej 
> teorii wyjaśniasz niezabawowe praktyczne użycie Erlanga?

Erlang jest nieco bardziej "praktyczny" w użyciu. Choć i tak to użycie 
bardzo niszowe jest(było).


>>> D nie znam, Adę inaczej kwalifikuję, pozostałe są zrealizowane
>>> (AFAIK) właśnie metodą ceplusplusową, alias obleśną.
>> Co rozumiesz przez metodę Ceplusplusową? Składnię, semantykę?
> 
> Dla mnie to jest pełen bajzel na każdym poziomie (sorry, NTG żeby 
> się rozpisywać - Qrczak kiedyś wyliczył bzdury i wyszła cała epopeja).

Jaka jest wspólnota rozwiazania z Javy z rozwiązaniem z C++? To 
rozwiązanie z Javy to poza składnią ma niewiele wspólnego z tym z C++ -- 
jest też do bani, ale jest do banie w zupełnie inny sposób.

>  
>> polimorfizm statyczny w statycznym języku jako taki sens ma.
> 
> Zgoda, ale jakoś np. w OCamlu dało się to zrobić normalnie 
> w języku, a nie na poziomie niemal preprocesora.

Nnno, ten preprocesor to juz się taki prawie jak w Lispie zrobił (tam 
też są makra :) ). Tylko jeszcze trudniejszy w użyciu jest.


>>>> Teraz (czytaj od nastu lat) są Turing complete (modulo dopuszczane przez 
>>>> standard ograniczenia głębokości rekursji do baardzo płytkiego poziomu) 
>>>> z całkowicie porąbaną drogą uzyskania tego Turing completeness.
>>> Tak jakby nie wystarczył do tego system typów.
>> Przecież to jest część systemu typów :)
> 
> Mam inne zdanie, ale teoria typów jest na takim poziomie
> ezoteryki że nie ma się co spierać o etykietki. W każdym razie: 
> wolę język od początku dobrze zaprojektowany od sztucznie 
> połatanego metodą doktora Frankensteina.

Też wolę. C++ bronić nie zamierzam. Oprócz stwierdzenia faktu, że toto 
jest popularne (chyba głównie przez przewidywalną i bardzo przyzwoitą 
wydajność połączoną z dostępnością wszelakich bibliotek). I oprócz 
stwierdzenia faktu, że templaty to już za preprocesor daleko wyszły.


>>>> Innymi słowy -- teraz jest to bardzo silny mechanizm stricte statyczny, 
>>>> tylko składnię ma kompletnie, absolutnie do bani. Wynikło to z tego, że 
>>>> nikt go nie zaprojektował pod kątem tej siły -- ot wstawiono kilka cech 
>>>> które różnym ludziom gdzies tam były przydatne czy gdzie indziej 
>>>> wygodnie się implementowały, ale ich suma okazała się istotnie silniejsza.
>>> Fajnie, ale taka siła to jest potrzebna do metaprogramowania - a tego
>>> się w praktyce nie da zrobić w c++.
>> W praktyce to robią. 
> 
> Tzn. jaki konkretny software tak napisano, oprócz tej biblioteki
> protezującej ułomność języka?

A owszem. Całkiem dużo softu tych bibliotek używa.

Jeden gościu (całkiem rozsądny człowiek) opisywał jak użył tego w jakiś 
cudach z okolic klasyfikacji, dataminingu, itp. w bardzo poważnym sofcie 
(jakieś zarządzanie ruchem na autostradach czy coś), który to soft miał 
przy okazji ostre wymaganie real time.

Choć tego nie lubię, bo z uwagi na ciężkie porąbanie jest wredne w 
utrzymaniu, też w paru miejscach użyć musiałem (pisanie kodu na około 
byłoby jeszcze gorsze)

> 
>>> Całe to przerośnięte monstrum szablonowe jest używane głównie 
>>> do uzyskania polimorfizmu, a jak ktoś chce skorzystać 
>>> z metaprogramowania to pisze w czymś lispowatym z makrami.
>> No właśnie coraz więcej różnych kolesi metaprogramuje w C++. 
>> Zobacz sobie boost::lambda [...] a zwłaszcza boost::mpl 
> 
> Zaraz zaraz, używanie lambd czy foralli to nie jest metaprogramowanie.

Ale ich napisanie w języku w których ich nie ma już jest :)

Poza tym mpl to ma mało wspólnego z forallem (poza tym, że 
metaprogramowaego foralla implementuje).

> W innych językach masz takie cechy z buta, a tu do języka kulawego
> dodano łatki i tylko one są zametaprogramowane. Żeby nie było -
> przekonałeś mnie, że szablony do czegoś w ogóle się przydały. 

boost::mpl istotnie zawiera takie rzeczy jak metakonstrukcje sterujące, 
jakieś nawet biedne metafunkcje itp. Wszystko to brzydkie w użyciu, 
kompiluje się niezwykle wolno i pamięciożernie a jak poleci błąd 
kompilacji to nie wiadomo gdzie się chować. Ale jest i ma paru 
zagorzałych zwolenników (niedawno był na pl.comp.lang.c spory flejm na 
temat wspaniałości lub wręcz przeciwnie (jak twierdziłem, i nadal 
twierdzę, że wręcz przeciwnie :) ) boost::mpl).


>>> W obronę Javy (jako języka a nie platformy) mnie nie wciągniesz :).
>> Platforma też jest kiepska :)
> 
> Musisz przemyśleć swój argument z liczbą programistów :).

Cóż, ma jedną zaletę: programistyczną małpę można tego nauczyć. A jak 
jest zbyt głupia, to można dać jej jakiś super framework wktóry wyklika 
wszystko do jakiegoś zapisu XMLowego który to zapis XMLowy java wykona.
To że jak przyjdzie co do czego to soft z jakimś (skąd inąd) paskudnym 
perlu działa istotnie szybciej i mniej pamięci źre to inna sprawa :)

Innymi słowy -- łatwo w tym zrobić coś co jakoś działa (podkreślając 
"jakoś").

Tu też upatruję braku popularności języków funkcyjnych -- małpy tego nie 
nauczysz. Języki funkcyjne są mało kompatybilne z mózgami sporej grupy 
programujących. W tym wszystkim zadziwia mnie nieco popularność C++, 
choć z drugiej strony można tego użyć jako tzw. C z klasami i to jakoś 
tam się w mózgi imperatywnie mapuje.


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