🚀 go-pugleaf

On 29.10.2009, pakalk <pakalk@gmail.com> wroted:

>> >> > ..i wtedy wyjdzie, ze jak ktos z glowa do PHP podejdzie, to
>> >> > nie jest taki zly ten pehap.
>>
>> >> Tu się zgadzam.
>>
>> >> Żeby napisać dużą i dobrą aplikację w PHP nie wystarczy
>> >> tutorial, var_dump i 1-2 lata klepania szablonów w php (nie
>> >> aplikacji).
>>
>> > Ano nie wystarczy. Dlatego mysle, ze to programisci PHP sa zli, a
>> > nie jezyk.
>>
>> Język niezależnie od wszystkiego innego też jest zdrowo skopany.
>
> To znaczy? Co konkretnie?

Lepiej zapytaj co nie zostało skopane. Tysiące wbudowanych funkcji 
w jednej przestrzeni nazw to po prostu chory sen wariata, niespójne
nazewnictwo i kolejność argumentów pogłębiają to wrażenie. Fatalna 
obsługa unikodu i ogólnie kodowań tekstu. Obsługa błędów po prostu
tragiczna, przy zagnieżdżonych inkludach błąd na kolejnym poziomie 
zagnieżdżenia produkuje biały ekran i tyle. Pierdyliard niespójności
i zagwozdek semantycznych, jak słynne '(string)"false" == (int)0 is true'.
Wymóżdżone typy danych, jak "lista i hasz w jednym", nie dająca 
w sumie ani dobrego hasza, ani dobrej listy (niespójność indeksów 
po usunięciu elementu ze środka listy to kuriozum), albo int, którego
rozmiaru nigdy nie możesz być pewien (32-bit na systemach 32-bit,
64-bit na 64-bitowych), tak samo jak tego, że zostanie zwrócony jako
unsigned. Pseudo-referencje. OOP jako afterthought, ledwo doprowadzone 
do używalności w PHP 5. Brak thread-safety. Tę listę naprawde można 
by jeszcze sporo przedłużyć.

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

On Oct 29, 10:03 pm, Grzegorz Staniak <gstan...@wp.pl> wrote:
> On 29.10.2009, pakalk <pak...@gmail.com> wroted:
>
> >> >> > ..i wtedy wyjdzie, ze jak ktos z glowa do PHP podejdzie, to
> >> >> > nie jest taki zly ten pehap.
>
> >> >> Tu się zgadzam.
>
> >> >> Żeby napisać dużą i dobrą aplikację w PHP nie wystarczy
> >> >> tutorial, var_dump i 1-2 lata klepania szablonów w php (nie
> >> >> aplikacji).
>
> >> > Ano nie wystarczy. Dlatego mysle, ze to programisci PHP sa zli, a
> >> > nie jezyk.
>
> >> Język niezależnie od wszystkiego innego też jest zdrowo skopany.
>
> > To znaczy? Co konkretnie?
>
> Lepiej zapytaj co nie zostało skopane. Tysiące wbudowanych funkcji
> w jednej przestrzeni nazw to po prostu chory sen wariata,

Bo nie było do tej pory przestrzeni.

> niespójne
> nazewnictwo i kolejność argumentów pogłębiają to wrażenie.
> Fatalna
> obsługa unikodu i ogólnie kodowań tekstu.
> Obsługa błędów po prostu
> tragiczna, przy zagnieżdżonych inkludach błąd na kolejnym poziomie
> zagnieżdżenia produkuje biały ekran i tyle. Pierdyliard niespójności
> i zagwozdek semantycznych, jak słynne '(string)"false" == (int)0 is true'.
> Wymóżdżone typy danych, jak "lista i hasz w jednym"

Co akurat wadą nie jest, bo niby czemu? Poza tym nie ma czegos takiego
jak lista w typach wbudowanych w PHP. Uznaje, ze chodzilo Ci o
tablice.

> , nie dająca
> w sumie ani dobrego hasza, ani dobrej listy (niespójność indeksów
> po usunięciu elementu ze środka listy to kuriozum),

Eeee... Tablice asocjacyjne z PHP sa powszechnie chwalone, a jesli
chodzi o struktury danych...

http://www.php.net/manual/en/spl.datastructures.php

> albo int, którego
> rozmiaru nigdy nie możesz być pewien (32-bit na systemach 32-bit,
> 64-bit na 64-bitowych),

No to mozesz byc pewien: 32 na 32, 64 na 64 :>

> tak samo jak tego, że zostanie zwrócony jako
> unsigned.

> Pseudo-referencje.

Tak? Gdzie? Jak dla mnie to one dzialaja, jak pelnoprawne referencje.

> OOP jako afterthought, ledwo doprowadzone
> do używalności w PHP 5.

Prosze Cie..

> Brak thread-safety. Tę listę naprawde można
> by jeszcze sporo przedłużyć.
>

Moze i mozna, ale polowa tej listy to wymysly bez pokrycia w faktach.
Czesciowo to tez wina implementacji - nie jezyka.

On 29.10.2009, pakalk <pakalk@gmail.com> wroted:

>> >> Język niezależnie od wszystkiego innego też jest zdrowo
>> >> skopany.
>>
>> > To znaczy? Co konkretnie?
>>
>> Lepiej zapytaj co nie zostało skopane. Tysiące wbudowanych
>> funkcji w jednej przestrzeni nazw to po prostu chory sen wariata,
>
> Bo nie było do tej pory przestrzeni.

Ale ja nie mówię o tym co obecni autorzy wiedzą że powinno być
i co planują, czy powoli wprowadzają, ale o tym co było i co 
jest -- i jeszcze będzie, ze względu na zgodność w dół. 

>> niespójne nazewnictwo i kolejność argumentów pogłębiają to
>> wrażenie. Fatalna obsługa unikodu i ogólnie kodowań tekstu.
>> Obsługa błędów po prostu tragiczna, przy zagnieżdżonych
>> inkludach błąd na kolejnym poziomie zagnieżdżenia produkuje
>> biały ekran i tyle. Pierdyliard niespójności i zagwozdek
>> semantycznych, jak słynne '(string)"false" == (int)0 is true'.
>> Wymóżdżone typy danych, jak "lista i hasz w jednym"
>
> Co akurat wadą nie jest, bo niby czemu? 

Zapytaj kogoś, kto miał na studiach zajęcia ze struktur danych.
Podpowiedź: wydajność.

>> , nie dająca w sumie ani dobrego hasza, ani dobrej listy
>> (niespójność indeksów po usunięciu elementu ze środka listy
>> to kuriozum),
>
> Eeee... Tablice asocjacyjne z PHP sa powszechnie chwalone

Przez kogo konkretnie? Decyzja o zrobieniu listy-i-hasza jako 
mapującej struktury danych jest po prostu debilna. Poza PHP
robi to chyba tylko AWK. Dzięki temu masz strukturę powolną 
jak diabli, ale za to pozbawioną zalet listy: jeśli po usunięciu
indeksu muszę używać funkcji żeby indeksy zachowały ciągłość:

$array = array_values($array);

to coś jest grubo nie tak. Kto konkretnie chwali te tablice 
i za co, jeśli można wiedzieć?

> a jesli chodzi o struktury danych...
>
> http://www.php.net/manual/en/spl.datastructures.php

To, że musisz sobie z czasem sztukować funkcjonalność rozszerzeniami 
(np. bcmath, żeby można było polegać na integerach) potwierdza tylko
tezę o błędach w projekcie języka. Nie jest żadną wielką chwałą, że
po latach PHP dorobiło się struktur znanych dawno z innych języków.

>> albo int, którego rozmiaru nigdy nie możesz być pewien (32-bit
>> na systemach 32-bit, 64-bit na 64-bitowych),
>
> No to mozesz byc pewien: 32 na 32, 64 na 64 :>

Mało śmieszne, kiedy żeby być pewnym działania aplikacji musisz 
używać rozszerzeń naprawiających te błędne decyzje projektowe, 
albo pisać własne wrappery sprawdzające, czy na pewno nie strzelasz
sobie w stopę. I pamiętać, żeby użyć ich wszędzie tam, gdzie może
pojawić się kłopot. 

>> tak samo jak tego, że zostanie zwrócony jako unsigned.
>
>> Pseudo-referencje.
>
> Tak? Gdzie? Jak dla mnie to one dzialaja, jak pelnoprawne
> referencje.

To są aliasy, nie referencje (w PHP poniżej 5).

>> OOP jako afterthought, ledwo doprowadzone do używalności w PHP 5.
>
> Prosze Cie..

O co?

>> Brak thread-safety. Tę listę naprawde można by jeszcze sporo
>> przedłużyć.
>
> Moze i mozna, ale polowa tej listy to wymysly bez pokrycia w
> faktach. 

Sorki, ale nie masz pojęcia o czym mówisz. Używam PHP od wersji 
0.8, koło 15 lat, i zdążył mi już przejść zachwyt nad tym jakie
to wspaniałe środowisko. 

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

On Oct 30, 12:10 am, Grzegorz Staniak <gstan...@wp.pl> wrote:
> Zapytaj kogoś, kto miał na studiach zajęcia ze struktur danych.
> Podpowiedź: wydajność.

Tylko, ze PHP nie ma wcale polaczonych list i hashy (map) w jednej
strukturze. Posiada tablice asocjacyjne.

>
> > Eeee... Tablice asocjacyjne z PHP sa powszechnie chwalone
>
> Przez kogo konkretnie?

Przez wiele osob.

> Decyzja o zrobieniu listy-i-hasza jako
> mapującej struktury danych jest po prostu debilna.

Nic takiego nie ma miejsca. Nie wiem, ale moze nie bez powodu to sie
nazywa array a nie list? Nie uwazasz?

> Poza PHP
> robi to chyba tylko AWK. Dzięki temu masz strukturę powolną
> jak diabli, ale za to pozbawioną zalet listy: jeśli po usunięciu
> indeksu muszę używać funkcji żeby indeksy zachowały ciągłość:
>
> $array = array_values($array);

Pewnie dlatego, ze to nie jest tablica indeksowana 0..n tylko tablica
asocjacyjna klucz=>wartosc - to, ze jest to lista, to juz Twoj wymysl.
Dziwne by bylo tez, gdyby zachowywalo sie to inaczej dla roznych typow
indeksow.

>
> to coś jest grubo nie tak. Kto konkretnie chwali te tablice
> i za co, jeśli można wiedzieć?
>
> > a jesli chodzi o struktury danych...
>
> >http://www.php.net/manual/en/spl.datastructures.php
>
> To, że musisz sobie z czasem sztukować funkcjonalność rozszerzeniami

Jakie rozszwrzenie? Standard PHP Library - to sie tak nazywa.
Krytykujesz array_*(), ktore sa tak samo w dystrybucji jak SPL. W
Javie na przyklad tez nie widze, aby chocby tablice asocjacyjne byly
wbudowane i co z tego?

>
> >> Pseudo-referencje.
>
> > Tak? Gdzie? Jak dla mnie to one dzialaja, jak pelnoprawne
> > referencje.
>
> To są aliasy, nie referencje (w PHP poniżej 5).

Czemu mamy rozmawiac o czyms, co juz nie jest nawet przez Zenda
wspierane?! Moze pogadajmy o 'classic-style classes', albo pythonie
1.0? Taki doskonaly byl?

I tak - w PHP sa 'aliasy', ktore sa wybitnie przydatne jak pointery w C
++. Ale obok tez funkcjonuja (tak, od PHP5, ale PHP5 wprowadzono juz
dawno temu) referencje, ktore dzialaja jak te javowe - nie widze
powodu do narzekania!

>
> >> OOP jako afterthought, ledwo doprowadzone do używalności w PHP 5.
>
> > Prosze Cie..
>
> O co?

Nie rozumiem krytyki OOP - moze konkrety?

On 30 Paź, 08:56, Marek Wywiał <onj...@gmail.com> wrote:
> On 30 Paź, 08:24, pakalk <pak...@gmail.com> wrote:
>
> > On Oct 30, 12:10 am, Grzegorz Staniak <gstan...@wp.pl> wrote:
>
> > > Zapytaj kogoś, kto miał na studiach zajęcia ze struktur danych.
> > > Podpowiedź: wydajność.
>
> > Tylko, ze PHP nie ma wcale polaczonych list i hashy (map) w jednej
> > strukturze. Posiada tablice asocjacyjne.
>
> > > > Eeee... Tablice asocjacyjne z PHP sa powszechnie chwalone
>
> > > Przez kogo konkretnie?
>
> > Przez wiele osob.
>
> Dość enigmatyczne stwierdzenie.

Mam po nazwiskach jechac? :P

> Osobiście słyszałem 2 razy, by ktoś chwalił mix list/hash z php. Raz
> na grupie goldenline (nie pamiętam kto, ale argumenty nie były silne)
> i teraz Ty.

Ja pierwszy raz slysze, zeby ktos na nia narzekal, wiec 2-1 dla mnie.

>
> PHP jest sprytniejszy od przeciętnego programisty i sam ci
> przenumeruje twoje klucze na indexy, lub odwrotnie.
> Zbierz sobie w array dane cena produktu => ilość wystąpień np
> <?php
>
> $a = array(
>     1 => 13,
>     2 => 16,
>     2.29 => 17,
>     3 => 20,
>     3.14 => 23,
> );
>
> var_dump($a);
>
> + zalety słabego typowania:
>
> $a = array('bolek','lolek',0,'tola');
> var_dump(in_array('reksio', $a));
>
> i reksio ożywa
>

Sprawdze sobie. Moze i sa bugi, ale przypadki nieco wymyslone. W Javie
tez sie znajda kwiatki.

> czy inny przypadek literówki + słabe typowanie:
>
> <?php
>
> error_reporting(E_ALL);
>
> $ciag = "";
>
> $ciag[] .= 'Jezu';
> $ciag[] .= 'Chryste';

A co to za konstrukcja?

>
> var_dump($ciag);
>
> 'obsługa' dat jest cudowna, wystawmy sobie fakturkę
> <?php
>   $t = '2003/02/30';
>   var_dump(strtotime($t));
>
> radość księgowej - bezcenna

a co wychodzi? Moze format nie taki jak obslugiwany? Co sie wtedy
dziwic?
>
> i czym jest naprawdę static method
> <?php
> class B
> {
>     public function rzyc()
>     {
>         $this->Atam();
>     }
>
> }
>
> class A
> {
>     public function test()
>     {
>         B::rzyc();
>     }
>
>     public function Atam()
>     {
>         var_dump('A TAM');
>     }
>
> }
>
> $a = new A;
> $a->test();

W PHP5 takie wywolania generuja bledy. Wiem, ze to jest do dupy, ale
to spadek z PHP4.

On 30.10.2009, pakalk <pakalk@gmail.com> wroted:

>> >> Wszystko w porzadku jak piszesz program dla siebie, ktory wrasta
>> >> sobie w twoj serwer i nigdy nie bedzie na niczym innym instalowany.
>> >> Nieco gorzej jest kiedy piszesz program, ktory chcesz dac ludziom
>> >> do sciagniecia i zainstalowania -- musisz dolaczyc instrukcje
>> >> jak skonfigurowac do niego interpreter. Kompletna klapa jesli
>> >> chcesz napisac program na zasadzie "rozpakuj i dziala" -- albo
>> >> przewidujesz i obslugujesz wszystkie mozliwe konfiguracje, albo
>> >> po prostu wybierasz jedna najpopularniejsza i olewasz wszystkich
>> >> innych uzytkownikow.
>>
>> > Dranie z tych producentrow gier - na kazdym pudelku jest napisana
>> > konfiguracja minimalna do odpalenia gry. A co jakbym chcial na swoim
>> > 486 - nie zaziala... kurde!
>>
>> > Serio: wymagania aplikacji chyba jakies sa - nie dziala w prozni.
>>
>> To nie są wymagania aplikacji, tylko posrane założenia projektu
>
> To sa wymagania aplikacji.

Bzdura. To są ustawienia środowiska wykonania programu. 

[...]
>> > Jak ktos nie umie sobie skonfigurowac, to nie umie.
>>
>> Jak ktoś nie umie napisać języka programowania, to nie powinien
>> tego robić. Nie jest wcale dziwne, że pehap jest rekordzistą jeśli
>> chodzi o dziury bezpieczeństwa, skoro żeby ich uniknąć musisz
>> zignorować manuale i zamist pisać:
>>
>>     mysql_query("UPDATE users SET age='$age' WHERE id = '$id'");
>>
>> zabezpieczać się np. tak:
>>
>>     if (get_magic_quotes_gpc()) {
>>         $age = stripslashes($age);
>>     }
>>     mysql_query("UPDATE users SET age='".mysql_real_quote_string($age)."' WHERE id = '".mysql_real_quote_string($id)."'");
>
> Widze, ze nie potrafisz uzywac PDO.

Ale oczywiście odróżniasz język od bibliotek, prawda? Jak już
poprzednio zdołałeś udowodnić? 

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

On Oct 30, 9:16 am, pakalk <pak...@gmail.com> wrote:
> On 30 Paź, 08:56, Marek Wywiał <onj...@gmail.com> wrote:

> > 'obsługa' dat jest cudowna, wystawmy sobie fakturkę
> > <?php
> >   $t = '2003/02/30';
> >   var_dump(strtotime($t));
>
> > radość księgowej - bezcenna
>
> a co wychodzi? Moze format nie taki jak obslugiwany? Co sie wtedy
> dziwic?

po prostu nie ma 30 lutego. z ciekawosci sprawdz wynik.

marcin

On Mon, 02 Nov 2009 23:56:11 -0000, Marcin Nowak  
<marcin.j.nowak@gmail.com> wrote:

> On Oct 30, 9:16 am, pakalk <pak...@gmail.com> wrote:
>> On 30 Paź, 08:56, Marek Wywiał <onj...@gmail.com> wrote:
>
>> > 'obsługa' dat jest cudowna, wystawmy sobie fakturkę
>> > <?php
>> >   $t = '2003/02/30';
>> >   var_dump(strtotime($t));
>>
>> > radość księgowej - bezcenna
>>
>> a co wychodzi? Moze format nie taki jak obslugiwany? Co sie wtedy
>> dziwic?
>
> po prostu nie ma 30 lutego. z ciekawosci sprawdz wynik.

var_dump(strtotime('2003/02/32')); # => false
echo strftime("%Y/%m/%d", (strtotime('2003/02/32'))); # 1970/01/01

Nieprzewidywalność i zero intuicyjności to najwidocznie integralna cecha  
pehapa. W tym wypadku bezmyślnie zakłada że każdy miesiąc może mieć do 31  
dni. Z drugiej strony rozpoznaje lata przestępne. Rok 2003 luty miał 29  
dni. PHP po swojemu sobie to interpretuje, więc 2003-02-30 to dla niego to  
samo co 2003-03-01. Raczej mało kto wpadnie na to, że coś takiego się może  
stać. Więc trudno taki błąd wyłapać. Ani wyjątku ani warninga, ani notice,  
kompletnie nic. Faktycznie księgowa się może zdziwić. Nie tylko jak  
uważam, że PHP nie nadaje się do poważnych zastosowań. W nim roi się od  
takiego szeregu nonsensów.

Dla odmiany, jak do problemu podchodzi Ruby:

require 'date'
Date.strptime('2003/02/29', '%Y/%m/%d') # => wyjątek ArgumentError:  
invalid date
Date.strptime('2003/02/28', '%Y/%m/%d') # => => #<Date:  
4905397/2,0,2299161>

Zła data jest złą datą i już. Proste i logiczne. Wyrzuca wyjątek więc  
można to gdzieś wyłapać w wyższej warstwie. Nic się nie prześliźnie. W PHP  
bardzo łatwo przeoczyć mnostwo błędów. Nawet kopanie w logach nie  
gwarantuje (w powyższyzm przypadku nie ma żadnego warninga). To język dla  
masochisty.

-- 
JZ http://blog.zabiello.com

On 3 Lis, 16:40, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> On Mon, 02 Nov 2009 23:56:11 -0000, Marcin Nowak  
>
> <marcin.j.no...@gmail.com> wrote:
> > On Oct 30, 9:16 am, pakalk <pak...@gmail.com> wrote:
> >> On 30 Paź, 08:56, Marek Wywiał <onj...@gmail.com> wrote:
>
> >> > 'obsługa' dat jest cudowna, wystawmy sobie fakturkę
> >> > <?php
> >> >   $t = '2003/02/30';
> >> >   var_dump(strtotime($t));
>
> >> > radość księgowej - bezcenna
>
> >> a co wychodzi? Moze format nie taki jak obslugiwany? Co sie wtedy
> >> dziwic?
>
> > po prostu nie ma 30 lutego. z ciekawosci sprawdz wynik.
>
> var_dump(strtotime('2003/02/32')); # => false
> echo strftime("%Y/%m/%d", (strtotime('2003/02/32'))); # 1970/01/01
>
> Nieprzewidywalność i zero intuicyjności to najwidocznie integralna cecha  
> pehapa. W tym wypadku bezmyślnie zakłada że każdy miesiąc może mieć do 31  
> dni.

Widac wykonuje tylko podstawowe sprawdzenia, bo..

"The function expects to be given a string containing a US English
date format "

Ale przeciez nie warto stosowac funkcji zgodnie z ich przeznaczeniem,
tylko wymagac od nich urojonych wlasciwosci. Jak z tymi tablicami,
ktore nie chca domyslnie zachowywac sie jak lista.

> Więc trudno taki błąd wyłapać. Ani wyjątku ani warninga, ani notice,  
> kompletnie nic. Faktycznie księgowa się może zdziwić. Nie tylko jak  
> uważam, że PHP nie nadaje się do poważnych zastosowań. W nim roi się od  
> takiego szeregu nonsensów.

Nonsensem jest uzywanie tej funkcji jako walidatora daty. Dobrze, by
bylo, gdyby dokonywala sprawdzen poprawnosci daty, ale wymagac od niej
czegos, czego nie oferuje i nigdzie sie tym nie chwali jest smieszne.

On Wed, 04 Nov 2009 13:18:02 -0000, pakalk <pakalk@gmail.com> wrote:

> Ale przeciez nie warto stosowac funkcji zgodnie z ich przeznaczeniem,
> tylko wymagac od nich urojonych wlasciwosci.

Urojonych? Nie przekonuje mnie takie fanbojowskie wyjaśnienie. Skoro się  
wysilili na tyle aby dodać obsługę roku przestępnego, to mogliby dodać też  
zwracanie null'a dla bezsensownych dat. Ty bardziej, że to częściowo  
działa! Słowem - to zachowanie jest niespójne i głupie. Co zresztą nie  
jest niczym nowym w pehapie.

> Jak z tymi tablicami,
> ktore nie chca domyslnie zachowywac sie jak lista.

Bo pehap nie ma list, ma tylko tablice asocjacyjne, lub inaczej nazywając:  
sorted hashmaps.

>> Więc trudno taki błąd wyłapać. Ani wyjątku ani warninga, ani notice,  
>> kompletnie nic. Faktycznie księgowa się może zdziwić. Nie tylko jak  
>> uważam, że PHP nie nadaje się do poważnych zastosowań. W nim roi się od  
>> takiego szeregu nonsensów.
>
> Nonsensem jest uzywanie tej funkcji jako walidatora daty. Dobrze, by
> bylo, gdyby dokonywala sprawdzen poprawnosci date, ale wymagac od niej
> czegos, czego nie oferuje i nigdzie sie tym nie chwali jest smieszne.

Gdyby nikt nic nie wymagał to byś do dziś pisał w PHP3, lub wcześniejszej  
wersji. Po co komu funkcja, która akceptuje jedne bezsensowne daty, a inne  
- nie?  Przecież to nie ma sensu. Zero spójności i konsekwencji.

W sumie, ten i inne przykłady, pokazują, że pehap jest z pewnością  
językiem w którym łatwiej popełnić błąd i trudniej aplikację uczynić  
odporną na różne błędy. To jest bardzo poważna słabość tego języka. Bez  
wzgledu, na ilość miłości jaką byś miał do PHP, trudno ci nie zgodzić się  
przynajmniej z tym wnioskiem.

-- 
JZ http://blog.zabiello.com

On Nov 4, 2:31 pm, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> On Wed, 04 Nov 2009 13:18:02 -0000, pakalk <pak...@gmail.com> wrote:
> > Ale przeciez nie warto stosowac funkcji zgodnie z ich przeznaczeniem,
> > tylko wymagac od nich urojonych wlasciwosci.
>
> Urojonych? Nie przekonuje mnie takie fanbojowskie wyjaśnienie.

Nie nazywaj mnie zadnym fanbojem, ani moich wyjasnien fanbojowskimi.
Czy to Ci sie podoba czy nie, jesli ktos czegos nie obiecuje, to nie
mozna miec pretensji, ze tego nie robi.

> Skoro się  
> wysilili na tyle aby dodać obsługę roku przestępnego, to mogliby dodać też  
> zwracanie null'a dla bezsensownych dat. Ty bardziej, że to częściowo  
> działa! Słowem - to zachowanie jest niespójne i głupie. Co zresztą nie  
> jest niczym nowym w pehapie.

W funkcjach do PHP-a dolaczonych. Kto mi wypominal, ze nie rozrozniam
jezyka od biblioteki standardowej?

>
> > Jak z tymi tablicami,
> > ktore nie chca domyslnie zachowywac sie jak lista.
>
> Bo pehap nie ma list, ma tylko tablice asocjacyjne, lub inaczej nazywając:  
> sorted hashmaps.

O wlasnie! No to wytlumacz to koledze, ktory sie upiera, ze to sa
listy, a przynajmniej oszukuja, ze sa.

>
> Gdyby nikt nic nie wymagał to byś do dziś pisał w PHP3, lub wcześniejszej  
> wersji. Po co komu funkcja, która akceptuje jedne bezsensowne daty, a inne  
> - nie?  Przecież to nie ma sensu. Zero spójności i konsekwencji.

Czy ja mowie, ze nie wymagam? W PHP3 nigdy nie pisalem, nie pisalbym,
bo sie to nadawalo do tego samego co MySQL 3. Niech sie rozwija, ale
nie mozna wymagac od funkcji, ze ma robic cos czego nie miala w
zalozeniach. Jak brakuje funkcjonalnosci, to trzeba ja dopisac.

>
> W sumie, ten i inne przykłady, pokazują, że pehap jest z pewnością  
> językiem w którym łatwiej popełnić błąd i trudniej aplikację uczynić  
> odporną na różne błędy. To jest bardzo poważna słabość tego języka. Bez  
> wzgledu, na ilość miłości jaką byś miał do PHP, trudno ci nie zgodzić się  
> przynajmniej z tym wnioskiem.

Zgadza sie, ze debugowanie, szczegolnie smieciowego kodu, jest
ciezkie, a w PHP nietrudno o smieci pozostawione przez innych (chocby
"mixiny" PHP + HTML). Jedyne co moge stwierdzic, to to, ze jesli
zamienic bledy na wyjatki (no pozostaje FATAL ERROR), to mozna z tym
zyc. Zagladanie do logow tez nie jest takie straszne - szczegolnie,
jak sie nie testuje samemu aplikacji to pozadane.

On 06.11.2009, pakalk <pakalk@gmail.com> wroted:

>> > Jak z tymi tablicami, ktore nie chca domyslnie zachowywac sie jak
>> > lista.
>>
>> Bo pehap nie ma list, ma tylko tablice asocjacyjne, lub inaczej
>> nazywając:   sorted hashmaps.
>
> O wlasnie! No to wytlumacz to koledze, ktory sie upiera, ze to sa
> listy, a przynajmniej oszukuja, ze sa.

Po raz kolejny bezczelnie kłamiesz. Po prostu to lubisz, czy może
naprawdę liczysz na to, że nikt nie sprawdzi?

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

On Nov 6, 7:57 pm, Grzegorz Staniak <gstan...@wp.pl> wrote:
> On 06.11.2009, pakalk <pak...@gmail.com> wroted:
>
> >> > Jak z tymi tablicami, ktore nie chca domyslnie zachowywac sie jak
> >> > lista.
>
> >> Bo pehap nie ma list, ma tylko tablice asocjacyjne, lub inaczej
> >> nazywając:   sorted hashmaps.
>
> > O wlasnie! No to wytlumacz to koledze, ktory sie upiera, ze to sa
> > listy, a przynajmniej oszukuja, ze sa.
>
> Po raz kolejny bezczelnie kłamiesz. Po prostu to lubisz, czy może
> naprawdę liczysz na to, że nikt nie sprawdzi?
>

Skoro kłamię, to skąd wiesz, że chodzi o Ciebie?

On 06.11.2009, pakalk <pakalk@gmail.com> wroted:

>> >> > Jak z tymi tablicami, ktore nie chca domyslnie zachowywac sie
>> >> > jak lista.
>>
>> >> Bo pehap nie ma list, ma tylko tablice asocjacyjne, lub inaczej
>> >> nazywając: sorted hashmaps.
>>
>> > O wlasnie! No to wytlumacz to koledze, ktory sie upiera, ze to sa
>> > listy, a przynajmniej oszukuja, ze sa.
>>
>> Po raz kolejny bezczelnie kłamiesz. Po prostu to lubisz, czy może
>> naprawdę liczysz na to, że nikt nie sprawdzi?
>
> Skoro kłamię, to skąd wiesz, że chodzi o Ciebie?

Bo ze mną o tym rozmawiałeś. Oczekuję odszczekania.

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

On Nov 6, 8:25 pm, Grzegorz Staniak <gstan...@wp.pl> wrote:
> Bo ze mną o tym rozmawiałeś. Oczekuję odszczekania.

Co mam odszczekac? Przeciez narzekales na tablice w PHP, ze udaja
listy, a nie przeindeksowuja sie po wywaleniu srodkowych elementow.

On 06.11.2009, pakalk <pakalk@gmail.com> wroted:

>> Bo ze mną o tym rozmawiałeś. Oczekuję odszczekania.
>
> Co mam odszczekac? Przeciez narzekales na tablice w PHP, ze udaja
> listy, a nie przeindeksowuja sie po wywaleniu srodkowych elementow.

O tym "koledze, ktory sie upiera, ze to sa listy" masz odszczekać.

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

On Nov 6, 11:15 pm, Grzegorz Staniak <gstan...@wp.pl> wrote:
> On 06.11.2009, pakalk <pak...@gmail.com> wroted:
>
> >> Bo ze mną o tym rozmawiałeś. Oczekuję odszczekania.
>
> > Co mam odszczekac? Przeciez narzekales na tablice w PHP, ze udaja
> > listy, a nie przeindeksowuja sie po wywaleniu srodkowych elementow.
>
> O tym "koledze, ktory sie upiera, ze to sa listy" masz odszczekać.

Ty masz jakies problemy z psychika?

"Wymóżdżone typy danych, jak "lista i hasz w jednym", nie dająca
w sumie ani dobrego hasza, ani dobrej listy, (niespójność indeksów
po usunięciu elementu ze środka listy to kuriozum)"

"Decyzja o zrobieniu listy-i-hasza jako
mapującej struktury danych jest po prostu debilna."

"[Ja]: Tylko, ze PHP nie ma wcale polaczonych list i hashy (map) w
jednej  strukturze. Posiada tablice asocjacyjne.
[Ty] Sprawdź sobie, jak działa 'array'. Ze szczególnym uwzględnieniem
składni udającej listy."

Zapisz się do PZPR - oni tam dziś też pierdzielą, że mówili, byli i
zachowywali sie inaczej niz sie zachowywali. I ze kochali Polske i
Polakow. Tak bardzo, ze az na ulicach mozna bylo spotkac ich bijace
serce partii.

On 07.11.2009, pakalk <pakalk@gmail.com> wroted:

>> >> Bo ze mną o tym rozmawiałeś. Oczekuję odszczekania.
>>
>> > Co mam odszczekac? Przeciez narzekales na tablice w PHP, ze
>> > udaja listy, a nie przeindeksowuja sie po wywaleniu srodkowych
>> > elementow.
>>
>> O tym "koledze, ktory sie upiera, ze to sa listy" masz odszczekać.
>
> Ty masz jakies problemy z psychika?
>
> "Wymóżdżone typy danych, jak "lista i hasz w jednym", nie dająca
> w sumie ani dobrego hasza, ani dobrej listy, (niespójność
> indeksów po usunięciu elementu ze środka listy to kuriozum)"
>
> "Decyzja o zrobieniu listy-i-hasza jako mapującej struktury danych
> jest po prostu debilna."
>
> "[Ja]: Tylko, ze PHP nie ma wcale polaczonych list i hashy (map)
> w jednej strukturze. Posiada tablice asocjacyjne. [Ty] Sprawdź
> sobie, jak działa 'array'. Ze szczególnym uwzględnieniem składni
> udającej listy."

Wskaż w powyższym twierdzenie, że hasze to listy, albo odszczekaj.

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

"(niespójność indeksów po usunięciu elementu ze środka LISTY to
kuriozum)" "

Idź się poucz.. geografii może.. czy czego tam was teraz w gimnazjum
uczą...

On 07.11.2009, pakalk <pakalk@gmail.com> wroted:

> "(niespójność indeksów po usunięciu elementu ze środka LISTY to
> kuriozum)" "

Wyrywać z kontekstu też trzeba umieć, kłamliwy bucu.

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

On Nov 7, 2:12 pm, Grzegorz Staniak <gstan...@wp.pl> wrote:
> On 07.11.2009, pakalk <pak...@gmail.com> wroted:
>
> > "(niespójność indeksów po usunięciu elementu ze środka LISTY to
> > kuriozum)" "
>
> Wyrywać z kontekstu też trzeba umieć, kłamliwy bucu.

No kur*a, co tu jest z kontekstu wyrwane? Mowisz o tablicach PHP
zarzucajac im, ze sa listami, jak napisales, a po usunieciu srodkowego
elementu musisz zrobic array_values(), zeby przeindeksowac tablice. No
co tu jest do rozumienia i jak to ja niby przeklamalem. To moze
zamiast rzucac wyzwiskami wytlumacz wszem i wobec co miales na mysli
piszac te slowa, skoro nie to co z nich wynika.

On 07.11.2009, pakalk <pakalk@gmail.com> wroted:

>> > "(niespójność indeksów po usunięciu elementu ze środka LISTY to
>> > kuriozum)" "
>>
>> Wyrywać z kontekstu też trzeba umieć, kłamliwy bucu.
>
> No kur*a, co tu jest z kontekstu wyrwane?

Powyższe zdanie. Kontekst wyglądał tak:

    >> Wymóżdżone typy danych, jak "lista i hasz w jednym",
    >> nie dająca w sumie ani dobrego hasza, ani dobrej listy
    >> (niespójność indeksów po usunięciu elementu ze środka listy
    >> to kuriozum)

Używam PHP od czasów, kiedy jeszcze było paroma skryptami w Perlu, 
Rasmus ma jeszcze gdzieś moją pocztówkę, jeśli je wszystkie zachował.
Autorzy nigdy nie ukrywali, że ich intencją było stworzenie jednego
typu danych który miał działać dokładnie w stylu "dwa (lub więcej) 
w jednym", potwierdza to dokumentacja oraz składnia typowa dla
list (np. inicjowanie bez kluczy). Mam prawo krytykować taką decyzję
jako słabo przemyślaną, ty natomiast kłamiesz jak ostatni buc 
wmawiając mi wypowiedzi typu "arrays to listy". Nie mam pojęcia 
po co brniesz w oczywiste kłamstwa, które jak widać wyżej bardzo
łatwo zdemaskować.

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

On Nov 9, 5:48 pm, Piotr Dembiński <pd...@gazeta.pl> wrote:
> liczbami całkowitymi, cykliczną liczbami naturalnymi w arytmetyce modulo
> (następnik/poprzednik <=> dodawanie i odejmowanie).
>

Masz tarcz, bez liczb, z 12 punktami jednakowej wielkosci. Okresl,
ktory z nich jest zerowy.

On Nov 9, 6:39 pm, pakalk <pak...@gmail.com> wrote:
> On Nov 9, 5:48 pm, Piotr Dembiński <pd...@gazeta.pl> wrote:
>
> > liczbami całkowitymi, cykliczną liczbami naturalnymi w arytmetyce modulo
> > (następnik/poprzednik <=> dodawanie i odejmowanie).
>
> Masz tarcz, bez liczb, z 12 punktami jednakowej wielkosci. Okresl,
> ktory z nich jest zerowy.

Dowolny. Ustalenie 0 i kierunku w którym się przesuwasz daje ci
jednoznaczną numerację. Oczywiście grup cyklicznych na zbiorze 12
elementowym jest dokładnie 12!, ale wszystkie są izomorficzne.

On Fri, 06 Nov 2009 18:09:46 -0000, pakalk <pakalk@gmail.com> wrote:

> Jedyne co moge stwierdzic, to to, ze jesli
> zamienic bledy na wyjatki

... to wtedy to już nie byłby PHP. Taka zmiana to poważna robota, bo  
trzeba by poprawić wszystkie funkcje wbudowane, gdyż one nie rzucają  
wyjątków. W sumie musiałbyś napisać nową implementację pehapa. Nie ma  
zmiłuj. To już lepiej z tym gównem się nie męczyć, ale użyć porządniej  
zaprojektowanego języka. No bo poza ewentualną koniecznością utrzymania  
jakiegoś wcześniej napisanego, dużego kodu, czy korzystania z gotowego  
rozwiązania (np. do obsługi forum) to jaki sens pisać coś w PHP? Ani to  
szybkie, ani spójne i łatwiejsze w utrzymaniu. Django, Rails czy Merb  
deklasują pehapowe frameworki. Zarówno wydajnościowo jak i funkcjonalnie.  
Poza tym Python i Ruby to języki ogólnego zastosowania, można je więc użyć  
w miejsce skryptóĻw bashowych, perlowych jak i do nawet tworzenia  
aplikacji desktopowych.


> (no pozostaje FATAL ERROR),

Ano pozostaje. Samoobsługowego serwera nie napiszesz w pehapie. Jeden  
przypadkowy fatal error i wszystko leży.

> Zagladanie do logow tez nie jest takie straszne - szczegolnie,

W wypadku pehapa nie masz innego wyjścia jak grzebać w logach i szukać  
miejsc które spowodowały kompletne załamanie się całej aplikacji.  
Oczywiście, wszystko po faktach. Najlepiej jak fatal error padnie podczas  
operacji finansowej, zakupu czegoś w sklepie internetowym. Jak ktoś lubi  
ryzyko to niech używa pehapa i potem kłóci się z klientami że serwis  
działa jak kupa.

-- 
JZ http://blog.zabiello.com

On Nov 10, 2:39 pm, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> On Fri, 06 Nov 2009 18:09:46 -0000, pakalk <pak...@gmail.com> wrote:
> > Jedyne co moge stwierdzic, to to, ze jesli
> > zamienic bledy na wyjatki
>
> ... to wtedy to już nie byłby PHP. Taka zmiana to poważna robota, bo  
> trzeba by poprawić wszystkie funkcje wbudowane, gdyż one nie rzucają  
> wyjątków.

To się realizuje przez error handler, więc mogę działać z tymi
funkcjami co są. Gorzej z fatal errorami, ale te też się da czasem
wyłapać (user_error ostatnio musialem, bo debilne smarty nie ma czegos
jak validateTemplate())

> W sumie musiałbyś napisać nową implementację pehapa. Nie ma  
> zmiłuj. To już lepiej z tym gównem się nie męczyć, ale użyć porządniej  
> zaprojektowanego języka.

Porządnej biblioteki. Można skopać każdy język zlymi bibliotekami ;)

> No bo poza ewentualną koniecznością utrzymania  
> jakiegoś wcześniej napisanego, dużego kodu, czy korzystania z gotowego  
> rozwiązania (np. do obsługi forum) to jaki sens pisać coś w PHP?

Szybko sie pisze, stosunkowo latwo rozprowadza.

> Ani to  
> szybkie, ani spójne i łatwiejsze w utrzymaniu.

Zend Framework mnie zabil

> Django, Rails czy Merb  
> deklasują pehapowe frameworki.

Railsow, czy Merba nie widzialem. Django jest bardzo fajne. Pod
wzgledem funkcjonalnym Symfony tez jest niezle.

> Zarówno wydajnościowo jak i funkcjonalnie.  
> Poza tym Python i Ruby to języki ogólnego zastosowania, można je więc użyć  
> w miejsce skryptóĻw bashowych, perlowych jak i do nawet tworzenia  
> aplikacji desktopowych.

Jako skryptow mozna uzyc tez PHP, do desktopowych raczej Java by sie
nadawala (oczywiscie nie z superwolnym swingiem). Jest jednak szybsza
kilka razy.

>
> > (no pozostaje FATAL ERROR),
>
> Ano pozostaje. Samoobsługowego serwera nie napiszesz w pehapie. Jeden  
> przypadkowy fatal error i wszystko leży.

Mozna to obejsc niby handlerem bufora wyjscia, ale to troche
naciagane.

>
> > Zagladanie do logow tez nie jest takie straszne - szczegolnie,
>
> W wypadku pehapa nie masz innego wyjścia jak grzebać w logach i szukać  
> miejsc które spowodowały kompletne załamanie się całej aplikacji.  

Z tym sie wciaz nie bede zgadzal, bo wg mnie w logach powinny byc dane
o bledzie. Podczas developerki natomiast, mamy Firebuga. Wszystko co
sie wylapie, mozna wyslac na konsole.

> Oczywiście, wszystko po faktach. Najlepiej jak fatal error padnie podczas  
> operacji finansowej, zakupu czegoś w sklepie internetowym.

No to znaczy, ze na produkcji byla niestabilna wersja, co nie powinno
miec miejsca.

> Jak ktoś lubi  
> ryzyko to niech używa pehapa i potem kłóci się z klientami że serwis  
> działa jak kupa.

Ale jak blad sie zdarzy w pythonie po operacji finansowej, to co? W
magiczny sposob sie przywroci stan sprzed bledu? Raczej nie..

Poza tym, operacje (wew) zazwyczaj opieraja sie na danych, a te
zabezpieczac powinny bazy danych. Zewnetrzne uslugi posiadaja
natomiast system transakcji, co tez zabezpieczyc powinno przed
bledami.

Zepsuc mozna wszedzie i wszystko. To, ze w PHP jest jak jest z bledami
to "zasluga" liczby programistow - szczegolnie nieudolnych. I tego, ze
jak ktos napisze takie mambo-jambo-joomle, to potem wszyscy korzystaja
i nie zwazaja na lepsze rozwiazania, bo "po co mi to jak mam to". W
pythonie jest inaczej, bo jak ktos cos pisze, to sie zastanawia. Choc
jak widze niektore modele zdarzen zaimplementowane w pythonie, to sie
zastanawiam, czy ktos za dlugo nie myslal ;)

Dnia 13-11-2009 o 22:22:58 pakalk <pakalk@gmail.com> napisał(a):

>>> Jedyne co moge stwierdzic, to to, ze jesli
>>> zamienic bledy na wyjatki
>>
>> ... to wtedy to już nie byłby PHP. Taka zmiana to poważna robota, bo  
>> trzeba by poprawić wszystkie funkcje wbudowane, gdyż one nie rzucają  
>> wyjątków.
>
> To się realizuje przez error handler

Chyba śnisz. Jak sobie wyobrażasz i poprawną czytelną obsługę setek  
różnych funkcji w jednym miejcu? Co z tymi, które nie zwracają nawet  
errora?

> Zend Framework mnie zabil

tymi_Długimi_i_kretyńsko_NazwanymiNazwami? ;)

>> Django, Rails czy Merb  deklasują pehapowe frameworki.
>
> Railsow, czy Merba nie widzialem.

hehe, ty tak poważnie? No, może Merb nie jest aż tak popularny, ale że by  
Railsa nawet nie widzieć??

> Pod wzgledem funkcjonalnym Symfony tez jest niezle.

Symfony to żałosna (i wolna jak żółw) próba zaimplementowania Rails w PHP.  
To samo Cake.


> Jako skryptow mozna uzyc tez PHP

LOL. A dlaczego od razu nie Assemblera? Przecież PHP się do tego niewiele  
lepiej nadaje. Jak np. napiszesz skrypt który działa wielowątkowo skoro  
PHP nie ma wątków? :)

>> Ano pozostaje. Samoobsługowego serwera nie napiszesz w pehapie. Jeden  
>> przypadkowy fatal error i wszystko leży.
>
> Mozna to obejsc niby handlerem bufora wyjscia, ale to troche
> naciagane.

No to pokaż jak byś to obszedł i obsłużył.

>> > Zagladanie do logow tez nie jest takie straszne - szczegolnie,
>>
>> W wypadku pehapa nie masz innego wyjścia jak grzebać w logach i szukać  
>> miejsc które spowodowały kompletne załamanie się całej aplikacji.
>
> Z tym sie wciaz nie bede zgadzal, bo wg mnie w logach powinny byc dane
> o bledzie.

Czy także dane o błędzie który został poprawnie obsłużony przez kod? A  
trzymaj sobie w logach nawet wyniki losowań totolotka. Problem w tym, że w  
pehapie nie masz wyboru - grzebanie po faktach w logach to jedyna pewna  
metoda wyłapania błędów, o czywiście *po faktach*.

>> Oczywiście, wszystko po faktach. Najlepiej jak fatal error padnie  
>> podczas operacji finansowej, zakupu czegoś w sklepie internetowym.
>
> No to znaczy, ze na produkcji byla niestabilna wersja, co nie powinno
> miec miejsca.

Tyle teorii, a praktyka? Błędy w kodzie to codzienność, zwłaszcza w  
większym kodzie.

>> Jak ktoś lubi  ryzyko to niech używa pehapa i potem kłóci się z  
>> klientami że serwis działa jak kupa.
>
> Ale jak blad sie zdarzy w pythonie po operacji finansowej, to co? W
> magiczny sposob sie przywroci stan sprzed bledu? Raczej nie..

Nie mówie o błędzie w algorytmie, ale o błędzie który spowoduje załamanie  
się aplikacji. Błędzie, który pehap nie jest w stanie obsłużyć, a klient  
dostanie.. pustą stronę. Nie ma możliwości aby w pełni zabezpieczyć pehapa  
przed czymś takim.

> Zepsuc mozna wszedzie i wszystko. To, ze w PHP jest jak jest z bledami
> to "zasluga" liczby programistow - szczegolnie nieudolnych.

Jeśli masz na myśli to, że większość programistów pehapa jest nieudolna,  
to zgoda. Jeśli masz na myśli tych, co stworzyli pehapa, to też zgoda (to  
w końcu ich "zasługa" że stworzyli taki językowy potworek). Bo faktycznie  
trzeba być idiotą aby dodać do języka nieobsługiwalne błędy.

-- 
JZ http://blog.zabiello.com

On Nov 15, 7:10 am, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> > > To się realizuje przez error handler
>
> Chyba śnisz. Jak sobie wyobrażasz i poprawną czytelną obsługę setek  
> różnych funkcji w jednym miejcu? Co z tymi, które nie zwracają nawet  
> errora?

Mowilem o zastepowaniu bledow wyjatkami. Jak nie ma bledu to ciezko go
zastapic.

>
> > Zend Framework mnie zabil
>
> tymi_Długimi_i_kretyńsko_NazwanymiNazwami? ;)

TO moge przezyc. Ale chocby konfiguracja jest wzieta z ... nie bede
przeklinal. Polapac sie nie mozna o co biega, Jak siadlem do Django,
to po 2 godzinach wiedzialem generalnie wszystko. Oczywiscie nie na
pamiec, ale koncepcje lapalem w locie. W Zendzie - k jego mac...
ciezko jest, bo to nie jest obiektowo napisane. Wszystko ma jakies
stringowe aliasy, ktorych trzeba sie naumiec. Nazwy to nawet nie sa
takie glupie, jak sie stosuje np. adaptery.

>
> >> Django, Rails czy Merb  deklasują pehapowe frameworki.
>
> > Railsow, czy Merba nie widzialem.
>
> hehe, ty tak poważnie? No, może Merb nie jest aż tak popularny, ale że by  
> Railsa nawet nie widzieć??

Tzn. nie uzywalem. Widziec, widzialem.

> > Mozna to obejsc niby handlerem bufora wyjscia, ale to troche
> > naciagane.
>
> No to pokaż jak byś to obszedł i obsłużył.

W manualu sa przyklady, niektore frameworki to realizuja. Ja nie mam
czasu sie tym teraz bawic.

>
> > Z tym sie wciaz nie bede zgadzal, bo wg mnie w logach powinny byc dane
> > o bledzie.
>
> Czy także dane o błędzie który został poprawnie obsłużony przez kod? A  
> trzymaj sobie w logach nawet wyniki losowań totolotka. Problem w tym, że w  
> pehapie nie masz wyboru - grzebanie po faktach w logach to jedyna pewna  
> metoda wyłapania błędów, o czywiście *po faktach*.

Jak juz mowilem. Bledy powinny byc w logach i to jest najpewniejsza
metoda ich wylapania.

On 15.11.2009, pakalk <pakalk@gmail.com> wroted:

>> Czy także dane o błędzie który został poprawnie obsłużony
>> przez kod? A   trzymaj sobie w logach nawet wyniki losowań
>> totolotka. Problem w tym, że w   pehapie nie masz wyboru -
>> grzebanie po faktach w logach to jedyna pewna   metoda wyłapania
>> błędów, o czywiście *po faktach*.
>
> Jak juz mowilem. Bledy powinny byc w logach i to jest najpewniejsza
> metoda ich wylapania.

Nadal nie rozumiesz? Jest całkiem sporo sytuacji, w których nie 
jest istotne czy i co zostanie zapisane do logów -- ważne jest,
żeby można było wykryć sytuację wyjatkową i ją obsłużyć. Pisząc 
sobie informację do logu albo nie, jeśli nie jest potrzebna. 
Mechanizm wyjątków to zapewnia, mechanizm "a teraz się wyłożę 
wywalając fatal error" tego nie zapewnia i w tym momencie zupełnie
nie jest istotne czy coś zostało zapisane w logu czy też nie.

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

Użytkownik "pakalk" <pakalk@gmail.com> napisał w wiadomości 
news:929230b3-8c01-4aa0-ba4d-af46cf4196f1@m16g2000yqc.googlegroups.com...
>
>Ale jak blad sie zdarzy w pythonie po operacji finansowej, to co? W
>magiczny sposob sie przywroci stan sprzed bledu? Raczej nie..
>Poza tym, operacje (wew) zazwyczaj opieraja sie na danych, a te
>zabezpieczac powinny bazy danych. Zewnetrzne uslugi posiadaja

Może wyobraźmy sobie banalny wzorzec w front kontrolerze:

def handler( req ):
    """ Front controller """
    conn = db.connection(...)
    try:
        res = targetMethod( req, conn )
    except:
        conn.rolback()
        raise
    else:
        conn.commit()
        return res


Czy takie coś jest do zaimplementowania w PHP ? By KAŻDY możliwy 
niewychwycony błąd w funkcji docelowej spowodował wyfofanie na bazie a 
poprawne zakończenie - zatwierdzenie? I żeby mieć pewność, że "targetMethod" 
nie zakończy się nagle a my się o tym nijak nie dowiemy i nie nastąpi 
rollback ?

On Nov 16, 8:08 am, "William Bonawentura" <n...@ipartners.pl> wrote:
> Użytkownik "pakalk" <pak...@gmail.com> napisał w wiadomościnews:929230b3-8c01-4aa0-ba4d-af46cf4196f1@m16g2000yqc.googlegroups.com...
>
>
>
> >Ale jak blad sie zdarzy w pythonie po operacji finansowej, to co? W
> >magiczny sposob sie przywroci stan sprzed bledu? Raczej nie..
> >Poza tym, operacje (wew) zazwyczaj opieraja sie na danych, a te
> >zabezpieczac powinny bazy danych. Zewnetrzne uslugi posiadaja
>
> Może wyobraźmy sobie banalny wzorzec w front kontrolerze:
>
> def handler( req ):
>     """ Front controller """
>     conn = db.connection(...)
>     try:
>         res = targetMethod( req, conn )
>     except:
>         conn.rolback()
>         raise
>     else:
>         conn.commit()
>         return res
>
> Czy takie coś jest do zaimplementowania w PHP ? By KAŻDY możliwy
> niewychwycony błąd w funkcji docelowej spowodował wyfofanie na bazie a
> poprawne zakończenie - zatwierdzenie? I żeby mieć pewność, że "targetMethod"
> nie zakończy się nagle a my się o tym nijak nie dowiemy i nie nastąpi
> rollback ?

Oczywiscie, ze tak. A nie? Poza tym, transakcja bez commita sie
autokomituje?

Podobno jezyki dziela sie na takie, na ktore wszyscy narzekaja i na
takie, w ktorych nikt nie programuje ;> Moze zamiast narzekac na php i
zarzucac mu rozne dziwne rzeczy, ktorych nie ma, to po prstu dobrze by
bylo napisac przykladowa aplikacje, czy snippet robiacy to samo w obu
jezykach i na tej podstawie wykazac zalety pythona i jego przewage nad
php?

On 16.11.2009, pakalk <pakalk@gmail.com> wroted:

> Podobno jezyki dziela sie na takie, na ktore wszyscy narzekaja i na
> takie, w ktorych nikt nie programuje ;> Moze zamiast narzekac na
> php i zarzucac mu rozne dziwne rzeczy, ktorych nie ma, to po prstu
> dobrze by bylo napisac przykladowa aplikacje, czy snippet robiacy to
> samo w obu jezykach i na tej podstawie wykazac zalety pythona i jego
> przewage nad php?

I po takim konkursiku pehapowe funkcje zaczną rzucać wyjątki?

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

Grzegorz Staniak powiada:
> On 16.11.2009, pakalk <pakalk@gmail.com> wroted:
>
>> Podobno jezyki dziela sie na takie, na ktore wszyscy narzekaja i na
>> takie, w ktorych nikt nie programuje ;> Moze zamiast narzekac na
>> php i zarzucac mu rozne dziwne rzeczy, ktorych nie ma, to po prstu
>> dobrze by bylo napisac przykladowa aplikacje, czy snippet robiacy to
>> samo w obu jezykach i na tej podstawie wykazac zalety pythona i jego
>> przewage nad php?

Może kopsnij (pakalku) jakiś pokazujący przewagę php jeśli używasz 
obu - bo obawiam się, że w odwrotną stronę może być problem. 
Ja po przeczytaniu paru kodów źródłowych w php już tego
języka nie tykam nawet kijem (no ale może jestem uprzedzony).

> I po takim konkursiku pehapowe funkcje zaczną rzucać wyjątki?

A jest taki wymóg? Fakt, że dodali ten dziurawy mechanizm
wyjątków niepotrzebnie, no ale błędy można obsługiwać inaczej.
W szczególności w php-ie jest obecna pradawna koncepcja error 
handlerów. Co prawda nie może taki handler przejąć fatal errora,
ale tu już widzę problem w implementacji interpretera a nie
w języku jako takim: to normalne że nie da się opanować błędu
jak się maszyna rozsypie, po prostu funkcje nie powinny panikować
gdy stanie się coś może niestandardowego ale jednak niekrytycznego.


Piotr Sawicki

On 16.11.2009, Piotr Sawicki <ps171721@students.mimuw.edu.pl> wroted:

>> I po takim konkursiku pehapowe funkcje zaczną rzucać wyjątki?
>
> A jest taki wymóg? 

O tym była rozmowa. 

> Fakt, że dodali ten dziurawy mechanizm wyjątków niepotrzebnie, no
> ale błędy można obsługiwać inaczej. W szczególności w php-ie
> jest obecna pradawna koncepcja error handlerów. Co prawda nie może
> taki handler przejąć fatal errora, ale tu już widzę problem w
> implementacji interpretera a nie w języku jako takim: to normalne
> że nie da się opanować błędu jak się maszyna rozsypie, po
> prostu funkcje nie powinny panikować gdy stanie się coś może
> niestandardowego ale jednak niekrytycznego.

Przecież o tym cały czas mowa. Co komu po ślicznym komunikacie 
w logach, skoro _nie można_ polegać na mechanizmach obsługi 
wyjątków, bo zawsze możesz trafić na fatal error.

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

Grzegorz Staniak powiada:

>>> I po takim konkursiku pehapowe funkcje zaczną rzucać wyjątki?
>>
>> A jest taki wymóg? 
>
> O tym była rozmowa. 

Ale wystarczy możliwość obsłużenia błędu czy koniecznie poprzez wyjątki?

>> Fakt, że dodali ten dziurawy mechanizm wyjątków niepotrzebnie, no
>> ale błędy można obsługiwać inaczej. W szczególności w php-ie
>> jest obecna pradawna koncepcja error handlerów. Co prawda nie może
>> taki handler przejąć fatal errora, ale tu już widzę problem w
>> implementacji interpretera a nie w języku jako takim: to normalne
>> że nie da się opanować błędu jak się maszyna rozsypie, po
>> prostu funkcje nie powinny panikować gdy stanie się coś może
>> niestandardowego ale jednak niekrytycznego.
>
> Przecież o tym cały czas mowa. Co komu po ślicznym komunikacie 
> w logach, 

Jeśli ten error jest rzeczywiście fatal (tzn. coś się całkiem
posypało wewnątrz interpretera do tego stopnia, że on sam nie 
potrafi sobie poradzić) to przerzucanie kontroli w inny punkt
interpretowanego programu nic nie pomoże, a tylko zaszkodzi.
Wtedy sensowne jest zaglądanie z crona do logów i administracyjne
rozwiązywanie problemu (np. restartowanie demona, przenoszenie
loadu czy alertowanie operatora). Oczywiście powyższy wywód
jest nie na temat, jeśli interpreter wylatuje z fatalem tylko
dlatego, że jakiś builtin się zdziwił nietypowym zachowaniem
środowiska (jak niemożność nawiązania zdalnego połączenia).

> skoro _nie można_ polegać na mechanizmach obsługi wyjątków, 

Nie używać wyjątków, i tak są IMHO szkodliwe (ten flejm już był).


Piotr Sawicki

On 16.11.2009, Piotr Sawicki <ps171721@students.mimuw.edu.pl> wroted:

>> Przecież o tym cały czas mowa. Co komu po ślicznym komunikacie  
>> w logach,                                                          
>
> Jeśli ten error jest rzeczywiście fatal (tzn. coś się całkiem
> posypało wewnątrz interpretera do tego stopnia, że on sam nie
> potrafi sobie poradzić) to przerzucanie kontroli w inny punkt
> interpretowanego programu nic nie pomoże, a tylko zaszkodzi. 
> Wtedy sensowne jest zaglądanie z crona do logów i administracyjne
> rozwiązywanie problemu (np. restartowanie demona, przenoszenie
> loadu czy alertowanie operatora). Oczywiście powyższy wywód jest
> nie na temat, jeśli interpreter wylatuje z fatalem tylko dlatego,
> że jakiś builtin się zdziwił nietypowym zachowaniem środowiska
> (jak niemożność nawiązania zdalnego połączenia).

A pehapowi tak się też zdarzało.

>> skoro _nie można_ polegać na mechanizmach obsługi wyjątków,
>
> Nie używać wyjątków, i tak są IMHO szkodliwe (ten flejm już
> był).

Tak to sobie można filozofować kiedy już jest ta obsługa wyjątków.
Najpierw jednak trzeba ją mieć, żeby się mogły ścierać racje 
zwolenników i przeciwników, bo bez tego to jak rozmowa dwóch 
posiadaczy maluchów czy warto montować automat do beemki, czy
też zostać przy skrzyni obsługiwanej ręcznie.

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

Grzegorz Staniak powiada:
>> Oczywiście powyższy wywód jest nie na temat, jeśli interpreter 
>> wylatuje z fatalem tylko dlatego, że jakiś builtin się zdziwił 
>> nietypowym zachowaniem środowiska (jak niemożność nawiązania 
>> zdalnego połączenia).
>
> A pehapowi tak się też zdarzało.

Stąd zastrzeżenie - ale nawet jeśli tak było, to problem leży 
po stronie implementacji interpretera, nie jest to wada języka. 
W tym sensie, że wystarczy zapatchować kod pehapa, żeby wszystkie 
dotychczasowe programy .php zaczęły działać zgodnie z intuicją.

> Tak to sobie można filozofować kiedy już jest ta obsługa wyjątków.

W ten sposób sporo dobrych języków (świetnie sobie radzących
bez koncepcji exceptions) przegrywa z byle ceplusplusem.

> Najpierw jednak trzeba ją mieć, żeby się mogły ścierać racje 
> zwolenników i przeciwników, bo bez tego to jak rozmowa dwóch 
> posiadaczy maluchów czy warto montować automat do beemki, czy
> też zostać przy skrzyni obsługiwanej ręcznie.

Taki tok rozumowania uważam za niemądry - równie dobrze można 
twierdzić, że python jest do bani bo nie ma templates. A jak ktoś 
uważa, że szablony są fatalne i lepiej ten sam efekt osiągnąć w inny 
sposób, to jeździ kaszlakiem do warzywniaka po kalarepę i niech sobie
najpierw rozbuduje język o jakiś idiotyczny koncept to dopiero możemy
pogadać jak prawdziwi dresiarze z beemkami odwiniętymi ze słupa.


Piotr Sawicki

Piotr Sawicki wrote:
> Grzegorz Staniak powiada:
>>> Oczywiście powyższy wywód jest nie na temat, jeśli interpreter 
>>> wylatuje z fatalem tylko dlatego, że jakiś builtin się zdziwił 
>>> nietypowym zachowaniem środowiska (jak niemożność nawiązania 
>>> zdalnego połączenia).
>> A pehapowi tak się też zdarzało.
> 
> Stąd zastrzeżenie - ale nawet jeśli tak było, to problem leży 
> po stronie implementacji interpretera, nie jest to wada języka. 
> W tym sensie, że wystarczy zapatchować kod pehapa, żeby wszystkie 
> dotychczasowe programy .php zaczęły działać zgodnie z intuicją.

Nie da się. Te błędy które były "fatalami" muszą zostać obsłużone w inny 
sposób.

> 
>> Tak to sobie można filozofować kiedy już jest ta obsługa wyjątków.
> 
> W ten sposób sporo dobrych języków (świetnie sobie radzących
> bez koncepcji exceptions) przegrywa z byle ceplusplusem.

A nie przegrywa?

Policz ile z języków do czegoś używanych w stopniu "wystającym ponad 
szum" (czyli nie do teoretycznych zabaw których szczytem jest napisanie 
translatora języka w nim samym) nie ma wyjątków.

> 
>> Najpierw jednak trzeba ją mieć, żeby się mogły ścierać racje 
>> zwolenników i przeciwników, bo bez tego to jak rozmowa dwóch 
>> posiadaczy maluchów czy warto montować automat do beemki, czy
>> też zostać przy skrzyni obsługiwanej ręcznie.
> 
> Taki tok rozumowania uważam za niemądry - równie dobrze można 
> twierdzić, że python jest do bani bo nie ma templates.

Nie równie dobrze. Szablony w języku dynamicznym mają marny sens. Można 
oczywiście sprowadzić dyskusję do tego czy lepiej mieć język dynamicznie 
czy statycznie typowany...

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

Sebastian Kaliszewski powiada:

>> Stąd zastrzeżenie - ale nawet jeśli tak było, to problem leży 
>> po stronie implementacji interpretera, nie jest to wada języka. 
>> W tym sensie, że wystarczy zapatchować kod pehapa, żeby wszystkie 
>> dotychczasowe programy .php zaczęły działać zgodnie z intuicją.
>
> Nie da się. Te błędy które były "fatalami" muszą zostać
> obsłużone w inny sposób.

Jasne, intuicyjnie nie znaczy automagicznie. Zarzut był taki,
że w aktualnej implementacji nawet jak się napisze kod obsługi
błędów, to interpreter się wywala zamiast go zrealizować.

>>> Tak to sobie można filozofować kiedy już jest ta obsługa wyjątków.
>> 
>> W ten sposób sporo dobrych języków (świetnie sobie radzących
>> bez koncepcji exceptions) przegrywa z byle ceplusplusem.
>
> A nie przegrywa?

Przy obsłudze błędów poprzez kontynuacje? Not rili. Poprzez zwracanie 
błędów wynikiem funkcji - dyskusyjne, są argumenty i za i przeciw.
W ogóle rzadko który język przegrywa z c++ imho, ale degustibus.

> Policz ile z języków do czegoś używanych w stopniu 
> "wystającym ponad szum" (czyli nie do teoretycznych zabaw 

To dodatkowy warunek - ja się zgadzam, że stosowanie wyjątków
jest powszechne (z drugiej strony kiedyś powszechne było 
stosowanie goto). Odróżnijmy jednak języki w których wyjątki
są elementarną konstrukcją semantyczną od takich, gdzie dodano
je jako rozszerzenie albo wręcz umożliwiono korzystanie z nich
poprzez biblioteczną implementację normalnymi środkami (Haskell).

> nie ma wyjątków.

Jak weźmiemy wersje języków przed wprowadzeniem wyjątków (wówczas
z powodzeniem stosowane ponad poziomem szumu), to Algol, Fortran 
[^Wwróć, miały być dobre;)], Smalltalk, ML, Lisp - w sumie kluczowe 
języki w historii programowania, ze wszystkich paradygmatów. Już nie 
mówiąc o językach do konkretnych zastosowań, jak R, Prolog czy make.

>>> Najpierw jednak trzeba ją mieć, żeby się mogły ścierać racje 
>>> zwolenników i przeciwników, bo bez tego to jak rozmowa dwóch 
>>> posiadaczy maluchów czy warto montować automat do beemki, czy
>>> też zostać przy skrzyni obsługiwanej ręcznie.
>> 
>> Taki tok rozumowania uważam za niemądry - równie dobrze można 
>> twierdzić, że python jest do bani bo nie ma templates.
>
> Nie równie dobrze. Szablony w języku dynamicznym mają marny sens. 

A wyjątki (jako specjalny element semantyki) mają marny sens 
w języku z kontynuacjami. Za to szablony są idiotyczne również 
przy typowaniu statycznym, ale z kwantyfikatorami lub funktorami.


Piotr Sawicki

Piotr Sawicki wrote:
> Sebastian Kaliszewski powiada:
> 
>>> Stąd zastrzeżenie - ale nawet jeśli tak było, to problem leży 
>>> po stronie implementacji interpretera, nie jest to wada języka. 
>>> W tym sensie, że wystarczy zapatchować kod pehapa, żeby wszystkie 
>>> dotychczasowe programy .php zaczęły działać zgodnie z intuicją.
>> Nie da się. Te błędy które były "fatalami" muszą zostać
>> obsłużone w inny sposób.
> 
> Jasne, intuicyjnie nie znaczy automagicznie. Zarzut był taki,
> że w aktualnej implementacji nawet jak się napisze kod obsługi
> błędów, to interpreter się wywala zamiast go zrealizować.
> 
>>>> Tak to sobie można filozofować kiedy już jest ta obsługa wyjątków.
>>> W ten sposób sporo dobrych języków (świetnie sobie radzących
>>> bez koncepcji exceptions) przegrywa z byle ceplusplusem.
>> A nie przegrywa?
> 
> Przy obsłudze błędów poprzez kontynuacje? Not rili.

Można przez kontynuacje czy insze monady (jedno daje się wyrazić przez 
drugie). Ale bez odpowiedniego lukru syntaktycznego (albo makr) to 
zaczyna to słabo wyglądać.

I jaką nową jakość chcesz uzyskać za pomocą obsługi błędów przez 
kontynuacje?

> Poprzez zwracanie 
> błędów wynikiem funkcji - dyskusyjne, są argumenty i za i przeciw.
> W ogóle rzadko który język przegrywa z c++ imho, ale degustibus.

Rzeczywistość jednak jest taka, że to C, Java, C++ i PHP to 
najpopularniejsze języki :) Na szczęście Python nie jest daleko (koło C# 
i Perla).

> 
>> Policz ile z języków do czegoś używanych w stopniu 
>> "wystającym ponad szum" (czyli nie do teoretycznych zabaw 
> 
> To dodatkowy warunek - ja się zgadzam, że stosowanie wyjątków
> jest powszechne (z drugiej strony kiedyś powszechne było 
> stosowanie goto). Odróżnijmy jednak języki w których wyjątki
> są elementarną konstrukcją semantyczną od takich, gdzie dodano
> je jako rozszerzenie albo wręcz umożliwiono korzystanie z nich
> poprzez biblioteczną implementację normalnymi środkami (Haskell).

Normalnymi czyli za pomocą monad i lukru syntaktycznego.

Na tej samej zasadzie można się zastanawiać, czy obiektowość należy 
udostępniać jako cechę języka czy też wystarczy dać odpowiednie makra i 
obiektowość zaimplementować w bibliotece (patrz CLOS :) )

> 
>> nie ma wyjątków.
> 
> Jak weźmiemy wersje języków przed wprowadzeniem wyjątków (wówczas
> z powodzeniem stosowane ponad poziomem szumu), to Algol, Fortran 
> [^Wwróć, miały być dobre;)], Smalltalk, ML, Lisp - w sumie kluczowe 
> języki w historii programowania, ze wszystkich paradygmatów.

Przy czym współczesne wersje paru tych języków wyjątki ma.

BTW jesteś pewien, że Smalltalk nie miał od początku?

> Już nie 
> mówiąc o językach do konkretnych zastosowań, jak R, Prolog czy make.
> 
>>>> Najpierw jednak trzeba ją mieć, żeby się mogły ścierać racje 
>>>> zwolenników i przeciwników, bo bez tego to jak rozmowa dwóch 
>>>> posiadaczy maluchów czy warto montować automat do beemki, czy
>>>> też zostać przy skrzyni obsługiwanej ręcznie.
>>> Taki tok rozumowania uważam za niemądry - równie dobrze można 
>>> twierdzić, że python jest do bani bo nie ma templates.
>> Nie równie dobrze. Szablony w języku dynamicznym mają marny sens. 
> 
> A wyjątki (jako specjalny element semantyki) mają marny sens 
> w języku z kontynuacjami. Za to szablony są idiotyczne również 
> przy typowaniu statycznym, ale z kwantyfikatorami lub funktorami.

Nie koniecznie. Oczywiście nie mogą być tak obleśnie zrealizowane jak w C++.

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

Sebastian Kaliszewski powiada:

>> Przy obsłudze błędów poprzez kontynuacje? Not rili.
>
>Można przez kontynuacje czy insze monady (jedno daje się 
>wyrazić przez drugie). Ale bez odpowiedniego lukru syntaktycznego 
>(albo makr) to zaczyna to słabo wyglądać.

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.  

>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. 
Stosowanie wyjątków, przy wszystkich zaletach, powoduje że nietrywialne 
staje się statyczne sprawdzenie, czy obsłużono wszystkie rzucane błędy.

> Rzeczywistość jednak jest taka, że to C, Java, C++ i PHP to
> najpopularniejsze języki :)

To empiria, ale możliwych powodów popularności języka jest 
tyle, że sama w sobie nie przesądza ona o jego jakości.

>> Odróżnijmy jednak języki w których wyjątki
>> są elementarną konstrukcją semantyczną od takich, gdzie dodano
>> je jako rozszerzenie albo wręcz umożliwiono korzystanie z nich
>> poprzez biblioteczną implementację normalnymi środkami (Haskell).
>
>Normalnymi czyli za pomocą monad i lukru syntaktycznego.

Jak programujesz w Haskellu bez użycia monad, to wyjątki są na plaster.
Z monadami już jest sens korzystania z wyjątków, ale wtedy są one AFAIK
zaimplementowane zwyczajnymi strukturami z funkcjami wyższych rzędów 
- samemu sobie można taką bibliotekę napisać, to nie element języka.

>Na tej samej zasadzie można się zastanawiać, czy obiektowość należy
>udostępniać jako cechę języka czy też wystarczy dać odpowiednie makra i
>obiektowość zaimplementować w bibliotece (patrz CLOS :) ) 

Zależy od ekspresywności języka oczywiście - ale to Ty chciałeś
oceniać cechę języka na podstawie tego, w ilu językach występuje.
Jeśli ma się liczyć również możliwość bibliotecznego doimplementowania
takiej cechy w elastycznych językach wysokopoziomowych, to tą drogą
rozumowania można uzasadniać dowolnie sensowne konstrukty.

>Przy czym współczesne wersje paru tych języków wyjątki ma.

No i spoko, nie mam nic przeciw wolności wyboru - ale to że dodano
jakiś bajer nie oznacza że bez niego wcześniej nie dało się programować
czegokolwiek poza teoretycznymi zabawami w stylu własnego translatora.

>BTW jesteś pewien, że Smalltalk nie miał od początku? 

Nie rzucę linkiem do pierwotnej definicji, ale w opisach historii
projektowania Smalltalka nie widziałem żadnej wzmianki. Zresztą
do tej pory jest to realizowane zwykłymi obiektami i komunikatami.
Które są tytułowane exception, ale są trochę czym innym (sygnały
z możliwością zrobienia resume albo retry). Nie wymaga to specjalnego
wsparcia języka dla wyjątków, wystarczy że pozwala on na domknięcia.

>> w języku z kontynuacjami. Za to szablony są idiotyczne również
>> przy typowaniu statycznym, ale z kwantyfikatorami lub funktorami.
>
>Nie koniecznie. Oczywiście nie mogą być tak obleśnie 
>zrealizowane jak w C++. 

A znasz jakąś inną? 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. Genericsów, 
typów polimorficznych czy type_classów już bym nie nazwał szablonem. 

Piotr Sawicki

Piotr Sawicki wrote:
>>> Przy obsłudze błędów poprzez kontynuacje? Not rili.
>> Można przez kontynuacje czy insze monady (jedno daje się 
>> wyrazić przez drugie). Ale bez odpowiedniego lukru syntaktycznego 
>> (albo makr) to zaczyna to słabo wyglądać.
> 
> 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++)

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

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.

> 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. Zakładając wsparcie składniowe (o którym już było) to to 
jak najbardziej można zrobić. Ba, nawet w Javie zrobili. Tyle, że to 
działa jak działa -- ale formalnie wszystko jest obsłużone.

Zapisując w Pythonie 3k:

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.

> 
>> Rzeczywistość jednak jest taka, że to C, Java, C++ i PHP to
>> najpopularniejsze języki :)
> 
> To empiria, ale możliwych powodów popularności języka jest 
> tyle, że sama w sobie nie przesądza ona o jego jakości.

Ale z jakością języka który kolejnie i kolejni programiści poznają po to 
by go odrzucić musi być coś nie tak.


[...]
>> Na tej samej zasadzie można się zastanawiać, czy obiektowość należy
>> udostępniać jako cechę języka czy też wystarczy dać odpowiednie makra i
>> obiektowość zaimplementować w bibliotece (patrz CLOS :) ) 
> 
> Zależy od ekspresywności języka oczywiście - ale to Ty chciałeś
> oceniać cechę języka na podstawie tego, w ilu językach występuje.

Możesz wliczyć występowanie biblioteczne -- i tak w pierwszej 20 
używanych języków proporcji to nie zmieni ;)


> Jeśli ma się liczyć również możliwość bibliotecznego doimplementowania
> takiej cechy w elastycznych językach wysokopoziomowych, to tą drogą
> rozumowania można uzasadniać dowolnie sensowne konstrukty.

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


[...]
>>> w języku z kontynuacjami. Za to szablony są idiotyczne również
>>> przy typowaniu statycznym, ale z kwantyfikatorami lub funktorami.
>> 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...

> 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). Zresztą kiedy były tylko 
takie to były proste i łatwe i w zasadzie nieszkodliwe (choć ubogie).

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.

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.

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


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

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

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)

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

> 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. Nie bardzo rozumiem co masz
na myśli - kontrprzykłady są niewłaściwe z powodu wieku i minimalizmu? 

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

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

Proste pilnowanie obsługi błędów.

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

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

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

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

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

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

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


Piotr Sawicki

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)

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

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)

Sebastian Kaliszewski powiada:

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

Przyznam że kompletnie nie chwytam o co Ci chodzi. Jakiś przykład kodu?

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

No ale są tam stosowane również przy obsłudze sytuacji wyjątkowych. 
Bezsensownie?

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

To czy wszystkie (kwantyfikatorowo) to bez znajomości: errcode<>success.

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

Nie tak samo, bo jest napisane czarno na białym jaka to strona.
A z exceptionami hgw gdzie poleci, trzeba sprawdzać cały program.

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

A to akurat jest najmniejszy problem, żeby to sprawdzić 
wystarczy zajrzeć w jeden wskazany nazwą procedury fragment
kodu - to można mieć w ide pod klikiem. Żeby sprawdzić jaka
będzie obsługa wyjątku trzeba przeczytać zylion miejsc
kodu które mogą wywoływać aktualnie czytany kawałek.

> BTW. zrobiono w swoim czasie badania co wpływa na liczbę 
> błędów w kodzie programów pisanych w różnych językach. 

Jak znam życie to nie robili eksperymentów tylko pomiary.
W szczególności niewykrycie innych korelacji mogło wynikać 
nie z ich braku, a z przyjęcia złych hipotez badawczych.

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

Niezupełnie, bo wiem że może skoczyć i gdzie. I to każdy 
poszczególny call, a nie cały obleczony try-catchem blok.

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

To akurat nie jest złe - ale to słabsza cecha (w sensie matematycznym).

> W przypadku kontynuacji albo masz ogólny skok 
> do miejsca gdzieś w ciele funkcji z której wołasz, 
> albo kontynuacja była parametrem 

Albo wskazujesz inny fragment kodu - continuation passing style da się
stosować nawet przy użyciu zwykłych procedur (tyle że to mało wygodne).

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

Nie wiem jak wygląda implementacja kontynuacji w Rubym, 
więc mogę się zgodzić że ją spartaczono skoro tak twierdzisz.

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

Ale nie kto je łapie.

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

Jeśli sygnatura mówi o przerzucaniu wyjątku wyżej to nadal 
nie wiem, czy to właściwa obsługa błędów, czy wpisana na odwal 
się, aby skompilowało - trzeba sprawdzać gdzie indziej.
Całe to rozwiązanie zachęca do robienia stubów które zbiorczo
łapią wszystko jak popadnie, kontynuacji nie ma sensu tak 
odbębniać (bo trzeba je wpisać w każdym miejscu).
 
> 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). 

Zgoda, programowanie to nie smażenie hamburgerów 
- zawsze można spartaczyć i nie ma co szukać silver bullet.
Za to różnica jest w łatwości wykrycia takiego partactwa:
jak trzeba je jawnie wpisywać to widać, a jak nie trzeba 
(i dobry kod może wyglądać tak samo jak zły) to nie.

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

Tego się nie da nie zauważyć - bo jest jawne.
 
>>> 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.

No właśnie musi pasować do wszystkich razem a nie każdego oddzielnie.

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

I które to są te kluczowe różnice w składni i semantyce między 
Erlangiem a innymi funkcyjnymi? Bo dla mnie jest przede wszystkim mniej
czytelny, a plusy widzę głównie w maszynie wirtualnej (czy jak to zwać).

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

To właśnie mój punkt (przyczyny powodzenia są pozalingwistyczne).

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

Lambdy, funkcje wyższych rzędów, częściowa ewaluacja i leniwość 
to cechy w dobrych językach dostępne out of the box, bez żadnego 
metaprogramowania. Po prostu C++ jest tak biedne, że inaczej niż 
metaprogramowaniem nie dało się tego doimplementować. Co jeszcze 
nie znaczy, że używając lambdy pisze się program tworzący programy 
(fakt że to kwestia definicji MP, ja wysoko stawiam poprzeczkę).

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

Zamyka efekty uboczne w piaskownicy, niezły wynik.

> Usiłowanie (niby) czysto funkcyjnej realizacji zadań które 
> nie dają się sprowadzić do podania argumentów przy wywołaniu 
> i poczekania na wynik 

Wszystkie się dają, kwestia czytelności i łatwości napisania.

> Funcyjność nie jest interaktywna, może być 
> interaktywnie użyta niejako z zewnątrz.

Nie mam pojęcia, co masz na myśli.

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

Batteries included; learning curve.


Piotr Sawicki

Piotr Sawicki wrote:
> Sebastian Kaliszewski powiada:
> 
>>> 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. 
> 
> Przyznam że kompletnie nie chwytam o co Ci chodzi. Jakiś przykład kodu?

Użyję pseudopythona (czyli jakby zapewne wyglądały kontynuacje 
zrealizowane w Pythonie gdyby je ktoś zrealizwoał:


def z_bledem(err_cont, a, b):
   if not a:
     err_cont.call(ErrorA())
   elif not b:
     err_cont.call(ErrorB())


def wolanie(err_cont):
   callcc cont:
     for i in range(10):
       z_bledem(random.choice(True, False), random.choice(True, False))
   continue error:
     if error.type is ErrorA():
       obsługa_na_miejscu()
     else:
        # pozostałe błędy ma obsłużyć wolajacy wolanie
        err_cont.call(error)


VS


def z_bledem(a, b):
   if not a:
     raise ErrorA()
   elif not b:
     raise ErrorB()

def wolanie()
   try:
     for i in range(10):
       z_bledem(random.choice(True, False), random.choice(True, False))
   except ErrorA as error:
     obsługa_na_miejscu()
   # pozostałe błędy ma obsłużyć wolajacy wolanie


Co zabawne w powyższym w wersji kontynuacyjnej jeśli pominiemy ostatnie 
else to błąd zostanie po cichu zignorowany.


>>> 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.
> 
> No ale są tam stosowane również przy obsłudze sytuacji wyjątkowych. 
> Bezsensownie?

Kluczowe jest *również*.

> 
>>> 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.
> 
> To czy wszystkie (kwantyfikatorowo) to bez znajomości: errcode<>success.

Tyle samo mi daje catch(...) -- w obu wypadkach niewiele.


>>> 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.
> 
> Nie tak samo, bo jest napisane czarno na białym jaka to strona.

Jeśli mamy cokolwiek więcej niż jeden ogólny błąd to dokładnie tak samo 
nie wiadomo. W dodatku łatwiej zrobić źle i niezauważyć (niezłapany 
wyjątek wyleci w sposób zwykle widoczny, dziurawa obsługa błędu w 
kontynuacji poprostu błąd zgubi).

> A z exceptionami hgw gdzie poleci, trzeba sprawdzać cały program.

I tak trzeba sprawdzać cały program. I tu i tu.


>>> 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
> 
> A to akurat jest najmniejszy problem, żeby to sprawdzić 
> wystarczy zajrzeć w jeden wskazany nazwą procedury fragment
> kodu - to można mieć w ide pod klikiem. Żeby sprawdzić jaka
> będzie obsługa wyjątku trzeba przeczytać zylion miejsc
> kodu które mogą wywoływać aktualnie czytany kawałek.

To samo przecież, w oczywisty sposób dotyczy użycie kontynuacji. Nawet 
jal kontynuację dostaniesz jako parametr, przy każdym wołaniu może to 
być kontynuacjia utworzona zupełnie gdzie indziej więc gdzie indziej 
prowadząca. Bez sprawdzenia wszysktkuch miejsc wołania i tak nie wiesz.


>> BTW. zrobiono w swoim czasie badania co wpływa na liczbę 
>> błędów w kodzie programów pisanych w różnych językach. 
> 
> Jak znam życie to nie robili eksperymentów tylko pomiary.

Robili eksperyment. Ludzie dostali do napisania programy (w języku który 
znali), potem te programy starannie sprawdzono patrząc ile jest błędów.

> W szczególności niewykrycie innych korelacji mogło wynikać 
> nie z ich braku, a z przyjęcia złych hipotez badawczych.

Hipotezą było, że są języki mniej i bardziej błędogenne. Sprawdziĸła się 
tylko w takim stopniu w jakim dany język pozwalał na napisanie kodu 
składającego się z mniejszej liczby konstrukcji. Koerlacja była 
zachowana również pomiędzy różnymi programami w tym samym języku -- 
programy dłuższe miały proporcjonalnie więcej błędów.


>>> 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. 
> 
> Niezupełnie, bo wiem że może skoczyć i gdzie.

Nie wiesz jeśli tylko gdziekolwiek przekazujesz dalej kontynuację 
otrzymaną "z zewnątrz" (w parametrach aktyualnie wykonywanej funkcji, 
lub co gorsza globalnie).

> I to każdy 
> poszczególny call, a nie cały obleczony try-catchem blok.

Jak ci bardzo na tej wiedzy zależy, to na końcu możesz mieć catch(...) 
-- wtedy wiesz, że tędy przeleci.


>> 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. 
> 
> To akurat nie jest złe - ale to słabsza cecha (w sensie matematycznym).

No właśnie nie widzę tej "słabszości".


>> W przypadku kontynuacji albo masz ogólny skok 
>> do miejsca gdzieś w ciele funkcji z której wołasz, 
>> albo kontynuacja była parametrem 
> 
> Albo wskazujesz inny fragment kodu - continuation passing style da się
> stosować nawet przy użyciu zwykłych procedur (tyle że to mało wygodne).

Ale ten fragment kodu jest skądś dany -- albo zrobiłem go sobie lokalnie 
(czyli tak jak catch / except) albo przyszedł z zewnątrz (czyli lokalnei 
nie wiem gdzie to dalej poleci).

> 
>> 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.
> 
> Nie wiem jak wygląda implementacja kontynuacji w Rubym, 
> więc mogę się zgodzić że ją spartaczono skoro tak twierdzisz.

To nie jest kwestia spartaczenia kontynuacji tylko istnienia globalnych 
zmiennych. I (złego) nauczenia ludzi by ich (nad)używali do trzymania 
kontynuacji.


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

Tak samo jest z kontynuacjami. Skaczesz do podanej z zewnątrz 
kontynuacji, ale bez obejrzenia całego kodu nie wiesz skąd się ona 
(kontynuacja) wzięła.


>>> 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.
> 
> Jeśli sygnatura mówi o przerzucaniu wyjątku wyżej to nadal 
> nie wiem, czy to właściwa obsługa błędów, czy wpisana na odwal 
> się, aby skompilowało - trzeba sprawdzać gdzie indziej.
> Całe to rozwiązanie zachęca do robienia stubów które zbiorczo
> łapią wszystko jak popadnie, kontynuacji nie ma sensu tak 
> odbębniać (bo trzeba je wpisać w każdym miejscu).

To tylko jeden parametr. Co gorsza kontynuacje zachęcają by je stworzyć, 
przekazać gdzie są wymagane a następnie po cichu wyrzucić.


>> 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). 
> 
> Zgoda, programowanie to nie smażenie hamburgerów 
> - zawsze można spartaczyć i nie ma co szukać silver bullet.
> Za to różnica jest w łatwości wykrycia takiego partactwa:
> jak trzeba je jawnie wpisywać to widać, a jak nie trzeba 
> (i dobry kod może wyglądać tak samo jak zły) to nie.

Przy specyfikowaniu wyjątków jest nie gorzej niż przy kontynuacjach -- 
czy dodam do funkcji dodatkowy parametr czy dospecyfikuję rzucane 
wyjątki to widać/ nie widać partactwo tak 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. 
> 
> Tego się nie da nie zauważyć - bo jest jawne.

Za to nie widać, że jakiś błąd został po cichu zgubiony.

>  
>>>> 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.
> 
> No właśnie musi pasować do wszystkich razem a nie każdego oddzielnie.

A otrzymana z zewnątrz kontynuacja tak samo będzie pasować do wszystkich 
razem.


>>>> 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. 
> 
> I które to są te kluczowe różnice w składni i semantyce między 
> Erlangiem a innymi funkcyjnymi? Bo dla mnie jest przede wszystkim mniej
> czytelny, a plusy widzę głównie w maszynie wirtualnej (czy jak to zwać).

Ta wiele rzeczy co ta maszyna wirtualna daje to część semantyki.
Głównie w całej zabawie w przesyłanie komunikatów w około którego 
wszystko się kręci. I w tym, że mamy "wbitą w semantykę" współbieżność.


>>>>>> 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.
> 
> Lambdy, funkcje wyższych rzędów, częściowa ewaluacja i leniwość 
> to cechy w dobrych językach dostępne out of the box, bez żadnego 
> metaprogramowania.

Ale ja nie mówię o tym. boost::lambda to co innego niż boost::mpl. 
boost::mpl daje metefunkcje (biedne i niewygodne ale są).

> Po prostu C++ jest tak biedne, że inaczej niż 
> metaprogramowaniem nie dało się tego doimplementować. Co jeszcze 
> nie znaczy, że używając lambdy pisze się program tworzący programy 
> (fakt że to kwestia definicji MP, ja wysoko stawiam poprzeczkę).

W mpl pisze się programy piszące programy.


>> 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.
> 
> Zamyka efekty uboczne w piaskownicy, niezły wynik.

Stawiając płot dookoła sebie zamykam świat za płotem? Intelektualny hack 
i tyle :)

W szczególności stan świata jest niezdefiniowany (bo i nie ma jak), jest 
ukrywany w pseudowartości która wartością nie jest. Nie bardzo więc 
można mówić o zbiorze wartości (skoro nie ma wartości), więc i nie 
bardzo można mówić o funkcji.

> 
>> Usiłowanie (niby) czysto funkcyjnej realizacji zadań które 
>> nie dają się sprowadzić do podania argumentów przy wywołaniu 
>> i poczekania na wynik 
> 
> Wszystkie się dają, kwestia czytelności i łatwości napisania.

Nie dają się. Istnieją zadanie w których całe clue polega na tym, że są 
w nich zależności czasowe.


>> Funcyjność nie jest interaktywna, może być 
>> interaktywnie użyta niejako z zewnątrz.
> 
> Nie mam pojęcia, co masz na myśli.

To, że wykonanie funkcji to przygotowanie argumentów i poczekanie na 
wynik. Możesz taką funkcję sobie w różnych miejscach i z różnymi 
argumentami wołać i za każdym razem czekać na wynik. Ale robienie z 
funkcji czegoś co realizuje złożone zależności czasowe to co najwyżej 
intelektualny hack.

pzdr

\SK

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