🚀 go-pugleaf

Piotr Sawicki wrote:
>>> 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.

Tak samo kontynuacja zapisana gdzieś globalnie może być poprawną obsługą 
błędu, mimo braku w danym miejscu jej jawnego przekazania. A nawet przy 
jej jawnym przekazaniu wcale nie musi być jasne gdzie w końcu konkretne 
błedy obsłużone zostaną (więcej w dalszej części postu).

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

One mają sens gdy stosowane są do uzyskania rzeczy które w pozostałych 
językach są kluczowe, tj podstawowe konstrukcje sterujące. Gdy język te 
podstawowe konstrukcje implementuje inaczej to stają się one 
(kontynuacje) dodatkiem.

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

Tego ostatniego nie widać bez znajomości semantyki wołanej funkcji.

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

Jw. -- nie tak od razu.

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

Tzn albo pójdzie normalnie, albo poleci w stornę sprawdzenia błedu -- 
tak samo jest przy wyjątkach.

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

Co do czytelności kodu, to i tak nie widzisz lokalnie, jakie błędy dana 
funkcja rzuca tylko jakie są obsługiwane -- jedno nie musi pasować (i 
często nie pasuje) do drugiego.

BTW. zrobiono w swoim czasie badania co wpływa na liczbę błędów w kodzie 
programów pisanych w różnych językach. I czy jakieś języki są bardziej 
czy mniej błędogenne. Znaleziono tylko jedną korelację -- liczba błędów 
zależała od długości programu, najmniej błędogennymi (w danych 
zadaniach) okazały się tę języki w których dane zadanie dawało się 
zapisać najbardziej zwięźle.

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

Zupełnie jak przy kontynuacjach. Jeśli masz statyczne specyfikacje 
wyjątków, to albo obsługa jest na końcu funkcji (w catch / except czy 
jak tam autorzy języka nazwali) albo w sygnaturze funkcji jest jawnie 
napisane, że leci dalej. W przypadku kontynuacji albo masz ogólny skok 
do miejsca gdzieś w ciele funkcji z której wołasz, albo kontynuacja była 
parametrem tej funkcji i wiesz tyle że leci dalej. W Rumym i podobnych 
masz jeszcze opcję, że kontynuacja była zapisana gdzieś i jawnie do 
wołanej funkcji nigdy przekazywana nie była a funkcja sobie i tak 
wyskoczyła.

W przypadku wyjątków Każda wołana funkcja też ma swoją sygnaturę -- 
wystarczy znać tę sygnaturę by wiedzieć jakie wyjątki wypuszcza.

> w 3) sprawdzenie poprawności jest pracochłonne
> (trzeba rekursywnie sprawdzać kto ten kod wywołuje i które wyjątki 
> łapie).

Przy statycznej kontroli jak w Javie nie trzeba, bo jak nie jest 
obsłużone to się nie skompiluje. Podobnie jak z jawnie przekazywanymi 
kontynuacjami.

Tzn. tyle mówi teoria -- i tu i tu można zrobić obsługę wszystkiego w 
jednym punkcie. W przypadku wyjątkiem jedno catch / except w "programie 
głównym" w przypadku kontynuacji -- jedna kontynuacja wzięta też z 
programu głównego. I jak mówi praktyka tak się dzieje dużo dużo częściej 
niż byłoby to uzasadnione (dopuszczam przypadki, że to jest 
uzasadnione). To, że coś takiego w kółko widać w kodzie napisanym w 
Javie a nie widać w napisanym w językach z kontynuacjami wynika, wg 
mnie, tylko z tego, że przeciętna programistyczna małpa nie używa tych 
drugich. Gdyby używała to robiłaby to samo.

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

A we wskazanym miejscu będzie dispatch do kolejnej kontynuacji 
przekazanej z wyższego wołania. Efekt ten sam -- i tak lokalnie nie 
wiesz, gdzie program w końcu wyląduje -- okaże się w runtime.

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

Hektar? Jak ktoś napisał funkcję na 1000 wierszy to sam sobie jest 
winien. Ta wstępna deklaracja musi pasować do wszystkich wywołań w 
połączeniu z obsługą wyjątków w kodzie tą wstępną deklaracją objętym.


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

Nie porównujmy Javy z Erlangiem.

Właśnie uważam że istotne znaczenie ma tu semantyka, w połączeniu z 
występowaniem w skłądni i w standardowej bibliotece tego, co potrzeba. 
Cały ten język zaprojektowano do określonego całkiem konkretnego 
praktycznego celu i ten cel realizuje dobrze (nawet bardzo dobrze). Ale 
poza tą wąską dość dziedziną jego użycie pozostało znikome.

Zaś Java to miał być język do programowania "inteligentnmych" kuchenek 
mikrofalowych. Do zadań do których został zaprzęgnięty przez Suna 
nadawał się słabo. Na tyle słabo że się kiepsko przyjął -- postawiono mu 
więc, po konkretnej rozbudowie (głównie) bibliotek inne zadania, w 
których wreszcie się przyjął, częściowo, zresztą, wracając do 
oryginalnego pomysłu (J2ME). Bez potężnego popychania przez Suna to by 
wszystko się rozlazło.

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

Poza składnią faktycznie nie ma.


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

No ale użycie mpl już jest -- bo to w zasadzie jedyne zadanie tej 
biblioteki.

BTW. Jest jeszcze jedna istotna cecha C++ (zresztą wspólna z Adą i D, 
wprowadzająca najpoważniejszą różnicę względem C). W przypadku C++, jak 
zwykle idiotycznie, nazwano to RAII (Resource Acquisition Is 
Initialization) co w ogóle nie odzwierciedla o co chodzi. Chodzi po 
prostu o automatyczną i synchroniczną destruckcję.

W połączeniu z niezbyt skomplikowanym użyciem szablonów można w ten 
sposób było np. zaimplementować GC (nie nie zliczanie referencji, choć 
to też zaimplementowano, i to dość trywialnie ale GC, żrące cykle). 
Implementuje się tym też takie rzeczy, jak muteksy powiązane z blokami 
kodu, tranakcje które zawsze się zakończą, itd...

Ma też wady -- np. źre się z domknięciami.

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

Prawie robi wielką różnicę.

BTW. nigdy nie podobało mi się użycie monad (plus dziwacznych typów 
reprezentujących stan świata) do uzyskiwania prawie-imperatywizmu. Dla 
mnie to jest intelektualny hack.

Usiłowanie (niby) czysto funkcyjnej realizacji zadań które nie dają się 
sprowadzić do podania argumentów przy wywołaniu i poczekania na wynik 
budzi u mnie pewien rodzaj intelektualnego obrzydzenia.

W moim odczuciu (częściowo estetycznym), trzeba się pogodzić z faktem, 
że interaktywność nie wpisuje się wewnątrz funkcyjności, choć w drugą 
stronę to idzie -- funkcyjność można wpisać (użyć, wywołać) z 
interaktywnego otoczenia. Funcyjność nie jest interaktywna, może być 
interaktywnie użyta niejako z zewnątrz.

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

Niby tak. Ale wiele innych języków też zaczynało od zera i nie miało 
wsparcia wielkiej korporacji. A mimo to trafiło do pierwszej 10. 
najczęściej używanych i znanych przez prgramistów języku -- wśród nich 
jest zarówno język którego dotyczy ta grupa jak i język którego dotyczy 
spora część pyskówki w niniejszym wątku. Przy czym o ile PHP rozwiązywał 
bardzo konkretne zadanie (każda małpa zrobi interaktywną stronę WWW), to 
w przypadku Pythona nie jest to takie jasne. Moim zdaniem zadecydowała 
właśnie "wysoka kompatybilność z mózgami".

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