🚀 go-pugleaf

Sebastian Kaliszewski powiada:

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

Tylko że taki kod może poprawnie obsługiwać błędy mimo braku 
w danym miejscu try/except. Można oczywiście się umówić, że
nie korzystamy z takiej możliwości i każdy call jest otoczony
sprawdzaniem wyjątków, ale wtedy stają się one zbędną koncepcją. 

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

Osłabienie możliwości przewidywania błędów to przykry efekt uboczny 
dynamizmu a nie jego cel. Chcę zjeść ciastko i nie nakruszyć.

>> kontrprzykłady są niewłaściwe z powodu wieku i minimalizmu? 
>
> To mam na myśli, że pełnią rolę konstrukcji podstawowej 

Nadal nie wyczajam argumentu, musiałbyś skonkretyzować 
tok rozumowania (są bez sensu - kontrprzykłady że z sensem
- ale tam są podstawowe - omgwtf).
 
>> Ł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. 

No właśnie nie - w przypadku obsługi błędów zwykłymi if-errcode
widać na pierwszy rzut oka czy kod był napisany już z obsługą
błędów czy jeszcze bez (i czy wszystkie są pokryte, w jaki sposób).
Przy continuation-passing-style kod z pominiętą obsługą błędów
się nawet nie skompiluje/nie wykona nawet w poprawnym przypadku.
A jak ktoś to spróbuje odbębnić, to przynajmniej od razu widać.

> Od kilku postów nie mogę się doprosić pokazania wartości dodanej.

Pisałem: w miejscu wywołania funkcji wiem co się stanie po powrocie.

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

Chyba rozumiem - myślałeś że chodzi mi o metodę javową sprawdzania
wyjątków automatycznie. No więc nie, o czytelność kodu.

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

Dowolny fragment kodu z licznymi wywołaniami procedur/funkcji.
Jeśli to jest napisane z wyjątkami to mam trzy możliwości:
1) sprawdzanie wyjątku jest przy każdym wywołaniu,
2) przy żadnym,
3) przy niektórych.
W 1) wyjątki są redundante z ifami; w 2) nie wiem czy obsługa
błędów była przewidziana czy nie, a w dodatku przebieg sterowania
robi się zupełnie nieoczywisty (bo każdy call jest potencjalnym
exit pointem); w 3) sprawdzenie poprawności jest pracochłonne
(trzeba rekursywnie sprawdzać kto ten kod wywołuje i które wyjątki 
łapie). Istotnie lepsze jest przelecenie kodu pagedownem i patrzenie
czy każdy call ma jawnie wpisaną obsługę błędów, mając pewność
że albo sterowanie przejdzie linijkę dalej, albo (w razie sytuacji
wyjątkowej) przesunie się do wskazanego miejsca - bo z wyjątkami
to nie bardzo wiadomo gdzie to przeskoczy, okaże się w runtimie.

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

No pliz, to jest tylko wstępna deklaracja jakie w ogóle wyjątki mogą 
zostać rzucone do góry przez cały hektar kodu z niejawnymi wyskokami.

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

,,Praktyczny'' to nie jest ficzer ani składni ani semantyki.
Po prostu przyczyny leżą poza językiem, choćby wsparcie
silnego koncernu - gdzie byłaby java bez suna.

> Jaka jest wspólnota rozwiazania z Javy z rozwiązaniem z C++? 

Chyba nie ma, przegapiłem 
(ale genericsy od początku odróżniałem od templates).
 
>>> 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 :)

E tam, to jest użycie biblioteki, co za różnica jak zaimplementowanej.

> Języki funkcyjne są mało kompatybilne z mózgami 
> sporej grupy programujących.

To prawda, ale właśnie dlatego w Ocamlu jest obiektowość, 
a w Haskellu można pisać prawie-jak-imperatywnie (co prawda
używając monad, ale można je traktować na zasadzie copy-paste
i nawet nie wiedzieć że mówi się prozą). Za to nie ma żadnej
gotowej dystrybucji całego środowiska, a dostępnych programistów 
jest za mało żeby ryzykować powodzenie projektu od ich dyspozycji.


Piotr Sawicki