🚀 go-pugleaf

Sebastian Kaliszewski powiada:
>> Do każdego mechanizmu języka powinna być przewidziana składnia
>> (sprawdzić czy nie ksiądz^W Lisp), bez niej słabo zaczyna wyglądać 
>> nawet deklaracja procedury. A parser to akurat najbardziej banalna 
>> część kompilatora, niemalże generowana automatycznie z opisu gramatyki. 
>
> Zależy którego ;) W przypadku C++ wcale nie traka trywialna (goście z 
> bodaj Open++ chyba parę lat pracowali nad zrobieniem takowego, i jest to 
> jedyna free-standaing implementacja parsera C++)

No to zatoczyliśmy koło - od początku twierdziłem, że c++ to syf.

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

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

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

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

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

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

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

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

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

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


Piotr Sawicki