🚀 go-pugleaf

Piotr Sawicki wrote:
[...]
>>>> I jaką nową jakość chcesz uzyskać za pomocą obsługi 
>>>> błędów przez kontynuacje? 
>>> Zysk na QA dzięki jawnemu specyfikowaniu przepływu sterowania. 
>> Popatrz na kontynuacje w Rubym -- parę globalnych zmiennych i jawnie 
>> wyspecyfikowany przepływ sterowania się schował :)
> 
> Sorry, nie piszę w Rubym i nie bardzo kojarzę co masz na myśli.

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.


>> W przypadku języków dynamicznych i tak nie bardzo widzę zaletę.
>>
>> To co ma sens w językach statycznie typowanych często nie ma 
>> już sensu w dynamicznie typowanych.
> 
> 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. Już w Javie w 
której dynamiczny jest tylko polimorfizm się to gryzie.

Lisp jest stary jak progtramowanie wysokopoziomowe. W Smalltalku -- 
kolejnym minimalistycznym języku -- kontynuacje służą do paru innych 
rzeczy, które w wielu innych językach są implementowane "tradycyjnie". W 
języku, w którym nawet ifa normalnego nie ma coś być musi :)

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

Po drugie nadal pytam o wartość dodaną kontynuacji pod tym względem?

> 
>> 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". 
I tyle samo daje użycie jakiejś exception monad do przesyłania 
wszystkich możliwych wyjątków (tyle że mniej wygodnie). Efekt końcowy 
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, czyuli jak zauważyłeś "Przecież to nie jest obsługa błędów".

>> Rozróżniłbym jednak teoretyczną możliwość doimplementowania od 
>> faktycznego zaimplementowania i to w standardowej bibliotece danego 
>> języka. Przyjmuję, że biblioteka standardowa języka jest jego 
>> (istotną) częścią.
> 
> Może dlatego różnimy się w ocenie, ja wolę rozróżniać te kategorie.
> 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).

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.

> 
>>>>> szablony są idiotyczne również przy typowaniu statycznym[...]
>>>> Nie koniecznie. Oczywiście nie mogą być tak obleśnie 
>>>> zrealizowane jak w C++. 
>>> A znasz jakąś inną?
>> D, poza tym genericsy z Javy które są i tak biedne i kiepskie (bo 
>> dziurawe -- statycznie typowana konstrukcja która nie jest), C#, 
>> rozwiązania z Ady, Free Pascala (biedne ale z lepszą składnią), Delphi 
>> (głupia składnia, w zasadzie kopia z C#) itd...
> 
> 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 sensem wyodrębnienia terminu template
>>> jest właśnie wskazanie tego konkretnego idiotycznego pomysłu, żeby
>>> wielokrotnie kopiować definicje przeklejając kolejne typy.
>> Ale to nie są już templaty z C++ od 15 co najmniej lat (i od 
>> najstarszego standardu ISO już takie nie były). 
> 
> Już nie ma instancjonowania oddzielnych typów w trakcie kompilacji?
> Bo nie był moim zarzutem brak oskryptowania.

Jest, ale to tylko wierzchołek. BTW polimorfizm statyczny w statycznym 
języku jako taki sens ma.

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

> 
>> 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ą. Choć wygląda to na urwanie z choinki w przypadku 
tego języka, ale robią 8-O. Ba, częściowo to trafiło (trafi, nowy 
standard będzie za ok. dwa lata) do biblioteki standardowej tegoż języka.

> 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 (zrobili sobie lambdę w języku który jej nie miał, 
jest na podobnym poziomie ograniczenia co ta w Pythonie) a zwłaszcza 
boost::mpl (okropne, ale ktoś się w to produkuje, ktoś używa, ba wiele 
pomysłów poleciało wprost do biblioteki standardowej).

Mimo paskudyzmu, ma zaletę taką, że wynikowy kod jest szybki -- wszystko 
się wylicza w trakcie kompilacji a potem już działa.

Ba, przez samą różnicę popularności obu języków podejrzewam, że w C++ 
metaprogramuje więcej ludzi niż w Lispie. Zwłaszcza, że to 
metaprogramowanie w Lispie też bywa nieco ten-tego.

Ba nr2, w swoim czasie na grupie dot. standardu C++ ktoś porównał 
stopień komplikacji różnych konstrukcji z C++ z konstrukcjami z Common 
Lispa -- też odpowiednio ciężko pokopanymi -- jako "wake-up call": 
"patrzcie co się stało z Lispem, kto tego dziś używa? Robicie to samo!".
(To była w CLispie jakaś wydawałoby się banalna operacja typu sięgnięcie 
do elementu w tupli czy coś w tym stylu, ale jej referencyjny, niejako 
kanoniczny zapis ujawniał ciężkie porąbanie, z uwagami typu to było w 
Mac Lispie w 1972, ale Common Lisp to przejął, komitet postanowił 
zachować zgodność semantyki, itd... więc ten przypadek obsługujemy 
właśnie tak -- i przypadków takich naście)

> 
>>> Genericsów, 
>>> typów polimorficznych czy type_classów już bym nie nazwał szablonem. 
>> Genericsów jakich? Javy? Te mają podobnie głupią składnię, 
>> połączoną z typowo Javową biedą rozwiązania.
> 
> Ady. W obronę Javy (jako języka a nie platformy) mnie nie wciągniesz :).

Platforma też jest kiepska :)

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