🚀 go-pugleaf

In the darkest hour on Mon, 16 Nov 2009 10:34:51 -0800 (PST),
pakalk <pakalk@gmail.com> screamed:
>> 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?
>

Przecież pokazano, że w określonych wypadkach php rzuci fatal errorem
i będzie po ptokach.

-- 
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:225B ]
[ 21:40:59 user up 12258 days,  9:35,  1 user, load average: 0.36, 0.01, 0.64 ]

               Logic:  The art of being wrong with confidence...

On Nov 16, 9:41 pm, "Artur M. Piwko" <milusi.pysiac...@buziaczek.pl>
wrote:
> In the darkest hour on Mon, 16 Nov 2009 10:34:51 -0800 (PST),
> pakalk <pak...@gmail.com> screamed:
>
> >> 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?
>
> Przecież pokazano, że w określonych wypadkach php rzuci fatal errorem
> i będzie po ptokach.
>

I co? Commit idzie z fatal errorem, tak?

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

>> >> 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?
>>
>> Przecież pokazano, że w określonych wypadkach php rzuci fatal
>> errorem i będzie po ptokach.
>
> I co? Commit idzie z fatal errorem, tak?

A co to za pociecha że baza zadba o siebie kiedy aplikacja leży?

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

On Nov 16, 11:50 pm, Piotr Sawicki <ps171...@students.mimuw.edu.pl>
wrote:
> Grzegorz Staniak powiada:
> 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).

PHP nie musi nic udowadniac, bo Python chce go sciagnac w dol i wejsc
na jego miejsce. Ja tez nie musze, ale o tem potem ;)

> A pehapowi tak się też zdarzało.

Podasz przyklad fatala po nieudanym polaczeniu? Jesli ktos robi

$conn = polacz();

a potem

$conn->doSth();

i dostaje fatala, bo polacz() zwrocilo null to juz sprawa glupiego
programisty, a nie PHP.

W artykule <e6daa029-43aa-4b00-9441-e0f6f36a09d5@z41g2000yqz.googlegroups.com> pakalk napisal(a):

> On Nov 16, 11:50 pm, Piotr Sawicki <ps171...@students.mimuw.edu.pl>
> wrote:
>> Grzegorz Staniak powiada:
>> 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).
>
> PHP nie musi nic udowadniac, bo Python chce go sciagnac w dol i wejsc
> na jego miejsce. Ja tez nie musze, ale o tem potem ;)
>
>> A pehapowi tak się też zdarzało.
>
> Podasz przyklad fatala po nieudanym polaczeniu? Jesli ktos robi
>
> $conn = polacz();
>
> a potem
>
> $conn->doSth();
>
> i dostaje fatala, bo polacz() zwrocilo null to juz sprawa glupiego
> programisty, a nie PHP.

Bierzesz pod uwagę, że koparka może zerwać światłowód w czasie 
pomiędzy "$conn = polacz();" a "$conn->doSth();", co wtedy? :)



-- 
Pozdrawiam,                           Piotr.Kuc-(szympans)-kuciak.net
Piotr Kuć

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

>> 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).
>
> PHP nie musi nic udowadniac, bo Python chce go sciagnac w dol
> i wejsc na jego miejsce.

Python mieszka w tej wieży sto pięter nad pehapem. Gdyby mierzyć 
_jakość_ języków popularnością, to VB byłby królem królów, prawda?

>> A pehapowi tak się też zdarzało.
>
> Podasz przyklad fatala po nieudanym polaczeniu?

A kto mówi o nieudanym połączeniu? Mowa ogólnie o built-inach. Możesz 
sobie sprawdzić, co wynika z wykonania np. poniższego kodu?

<?php
function return_empty_string() {
    return '';
}

empty(return_empty_string());
?>

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

pakalk powiada:

> PHP nie musi nic udowadniac, bo Python chce go sciagnac w dol i wejsc
> na jego miejsce. Ja tez nie musze, ale o tem potem ;)

A to sorry, myślałem że chcesz kogoś przekonać tym snippetem - bo jeśli
chodzi o mnie to nie daję latającego, możesz sobie pisać w pehapie.

> Podasz przyklad fatala po nieudanym polaczeniu? Jesli ktos robi
>
> $conn = polacz();
>
> a potem
>
> $conn->doSth();
>
> i dostaje fatala, bo polacz() zwrocilo null to juz sprawa glupiego
> programisty, a nie PHP.

To akurat jest sprawa głupich programistów interpretera php, którzy 
taki trywialny błąd kwalifikują jako fatal - to powinno być coś 
w stylu E_RECOVERABLE_ERROR, do przechwycenia error_handlerem
(chyba że jest, nie używam php więc nie wiem). 


Piotr Sawicki

Użytkownik "pakalk" <pakalk@gmail.com> napisał w wiadomości 
news:167b0c5c-d7c4-4a21-ad35-b8a2d5a5c2bf@b15g2000yqd.googlegroups.com...
>
> I co? Commit idzie z fatal errorem, tak?
>

Jeśli połączenie jest współdzielone to w kolejnym requeście może nastąpić na 
nim commit. Rollback musi być pewny jeśli chcemy mieć w miarę poważną 
aplikację transakcyjną. 

On Mon, 16 Nov 2009 18:34:51 -0000, pakalk <pakalk@gmail.com> wrote:

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

Ty tak na poważnie? :) Snippet? Tylko tyle widzisz? LOL!

Napisz w PHP jakiś serwer aplikacji (Zope) czy bazę obiektową (ZODB) lub w  
ogóle jakikolwiek skrypt wykonywany wielowątkowo... Powodzenia.

Albo może coś z unikodem?


#-*-* coding: utf-8 -*-
x = u"zażółć gęślą jaźń"
print x.upper() # ZAŻÓŁĆ GĘŚLĄ JAŹŃ

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

On Nov 17, 10:47 am, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> On Mon, 16 Nov 2009 18:34:51 -0000, pakalk <pak...@gmail.com> wrote:
> > 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?
>
> Ty tak na poważnie? :) Snippet? Tylko tyle widzisz? LOL!
>
> Napisz w PHP jakiś serwer aplikacji (Zope) czy bazę obiektową (ZODB) lub w  
> ogóle jakikolwiek skrypt wykonywany wielowątkowo... Powodzenia.
>
> Albo może coś z unikodem?
>
> #-*-* coding: utf-8 -*-
> x = u"zażółć gęślą jaźń"
> print x.upper() # ZAŻÓŁĆ GĘŚLĄ JAŹŃ
>

Chcesz napisac dwa blizniacze projekty serwerow aplikacyjnych, jeden w
pythonie, drugi w php? To pisz. Jak nie zrozumiales co ja napisalem i
o co mi chodzilo, to z laski swojej sie nie odzywaj.

On Nov 17, 8:55 am, Piotr M Kuć <kuc...@nospam.invalid> wrote:
> W artykule <e6daa029-43aa-4b00-9441-e0f6f36a0...@z41g2000yqz.googlegroups.com> pakalk napisal(a):
>
>
>
>
>
> > On Nov 16, 11:50 pm, Piotr Sawicki <ps171...@students.mimuw.edu.pl>
> > wrote:
> >> Grzegorz Staniak powiada:
> >> 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).
>
> > PHP nie musi nic udowadniac, bo Python chce go sciagnac w dol i wejsc
> > na jego miejsce. Ja tez nie musze, ale o tem potem ;)
>
> >> A pehapowi tak się też zdarzało.
>
> > Podasz przyklad fatala po nieudanym polaczeniu? Jesli ktos robi
>
> > $conn = polacz();
>
> > a potem
>
> > $conn->doSth();
>
> > i dostaje fatala, bo polacz() zwrocilo null to juz sprawa glupiego
> > programisty, a nie PHP.
>
> Bierzesz pod uwagę, że koparka może zerwać światłowód w czasie
> pomiędzy "$conn = polacz();" a "$conn->doSth();", co wtedy? :)
>

Na przyklad wyrzuci wyjatek podczas proby doSth(). Nie rozumiem w czym
problem, naprawde. Tak jakby python zabezpieczal swiatlowody na czas
operacji.

> Python mieszka w tej wieży sto pięter nad pehapem. Gdyby mierzyć
> _jakość_ języków popularnością, to VB byłby królem królów, prawda?

Nie, nieprawda. Wystarczy spojrzec na rynek pracy i to jest to o czym
mowilem.

> <?php
> function return_empty_string() {
>    return '';
> }
>
> empty(return_empty_string());
> ?>

Empty() to konstrukcja jezykowa - co sie dziwisz, ze dostajesz fatala,
jak masz blad w skladni?

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

>> Python mieszka w tej wieży sto pięter nad pehapem. Gdyby mierzyć
>> _jakość_ języków popularnością, to VB byłby królem królów, prawda?
>
> Nie, nieprawda. Wystarczy spojrzec na rynek pracy i to jest to o czym
> mowilem.

Innymi słowy, Visual Basic to wspaniały język.

>> <?php
>> function return_empty_string() {
>>    return '';
>> }
>>
>> empty(return_empty_string());
>> ?>
>
> Empty() to konstrukcja jezykowa - co sie dziwisz, ze dostajesz fatala,
> jak masz blad w skladni?

W składni? Naprawdę?

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

On Nov 17, 7:27 pm, Grzegorz Staniak <gstan...@wp.pl> wrote:
>
> >> <?php
> >> function return_empty_string() {
> >>    return '';
> >> }
>
> >> empty(return_empty_string());
> >> ?>
>
> > Empty() to konstrukcja jezykowa - co sie dziwisz, ze dostajesz fatala,
> > jak masz blad w skladni?
>
> W składni? Naprawdę?
>

Tak. Blad przy wykorzystaniu konstrukcji jezykowej jest bledem w
skladni.

On Tue, 17 Nov 2009 17:06:32 -0000, pakalk <pakalk@gmail.com> wrote:

> Chcesz napisac dwa blizniacze projekty serwerow aplikacyjnych, jeden w
> pythonie, drugi w php?

Przecież w pehapie to jest nie do wykonania. Tak jak i pisanie  
jakichkolwiek aplikacji pracujących wielowątkowo.

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

On 18 Lis, 13:05, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> On Tue, 17 Nov 2009 17:06:32 -0000, pakalk <pak...@gmail.com> wrote:
> > Chcesz napisac dwa blizniacze projekty serwerow aplikacyjnych, jeden w
> > pythonie, drugi w php?
>
> Przecież w pehapie to jest nie do wykonania. Tak jak i pisanie  
> jakichkolwiek aplikacji pracujących wielowątkowo.
>

forki masz - nie mowie, ze jest latwiej, ale jak chcesz wykazac
roznice i wyzszosc jednego nad drugim, to pokaz przyklad, zamiast
wypisywac LOL, czy inne dziwne skrotowce. Snippet Ci nie odpowiada
(czyli wg Ciebie nie da sie wykazac wyzszosci pythona na przykladzie
krotkiego kawalka kodu), to napisz cala aplikacje.

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

> forki masz

Ale nie masz wątków. Nie jesteś w stanie napisać żadnej aplikacji webowej  
pracującej w trybie serwletowym. Nie jesteś też w stanie użyć pehapa do  
zautomatyzowania wielowątkowych zadań odpalanych z konsoli (a utrzymywałeś  
że php nadaje się też do pisnia skryptów shellowych, dosyć kiepsko się  
nadaje) . Po prostu pehap stworzony od początku jako język szablonów  
ZAWSZE zagnieżdżonych w jakimś pliku tekstowym czy HTML'u. To pokazuje  
przecież sama jego składnia.

> - nie mowie, ze jest latwiej, ale jak chcesz wykazac
> roznice i wyzszosc jednego nad drugim, to pokaz przyklad, zamiast
> wypisywac LOL, czy inne dziwne skrotowce.

Nie wiesz co to jest LOL? LOL! ;)

Co ja poradzę że swoimi żenującymi wypowiedziami doprowadzasz czytelników  
do śmiechu? :)

> Snippet Ci nie odpowiada
> (czyli wg Ciebie nie da sie wykazac wyzszosci pythona na przykladzie
> krotkiego kawalka kodu), to napisz cala aplikacje.

Przecież podałem ci jaskrawe przykłady. Czytać nie umiesz?

Python: ZODB, transakcyjna, baza obiektowa
PHP: nic, i bez szans na napisanie

Python: Zope, serwer aplikacyjny
PHP: nic, i bez szans na napisanie

Python: SPE - aplikacja desktopowa, edytor IDE z obsługą debugera i  
różnych bajerów
PHP: ?

Python: garbage collector, możliwość pisania wielowątkowych lub  
pracujących asynchronicznych serwerów aplikacyjnych
PHP: bardzo kiepski garbage collector, brak wątków, mnie nadaje się do  
tworzenia żadnych serwerów

Ale byś się nie naindyczył i mnie źle nie zrozumiał...

Nie jest aż tak źle, że PHP się w ogóle do niczego nie nadaje. Jest sporo  
gotowych aplikacji które spełniają swoją rolę. Są różne aplikacje do  
obsługi forum dyskusyjnego, są różne CMS'y (choć żaden nie jest tak dobry  
jak Plone). Ale tworzenie czegoś większego od podstaw w... PHP? Chyba  
tylko dla masochisty.


Więc podsumowując: PHP jako język jest fatalnie zaprojektowany i pełen  
wad, ale to go jeszcze całkiem nie przekreśla. Właśnie ze względu na  
niektóre, gotowe rozwiązania. Podobnie, jak nie muszę wszystkiego pisać w  
C, aby używać gotowych aplikacji w nim napisanych.

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

On 19 Lis, 11:04, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> On Wed, 18 Nov 2009 13:00:11 -0000, pakalk <pak...@gmail.com> wrote:
> > forki masz
>
> Ale nie masz wątków. Nie jesteś w stanie napisać żadnej aplikacji webowej  
> pracującej w trybie serwletowym.

Zabawne, że gdy mowa o GIL, to pythonowcy mówią, że wątki to przeżytek
- lepiej stosować procesy...

> Nie jesteś też w stanie użyć pehapa do  
> zautomatyzowania wielowątkowych zadań odpalanych z konsoli (a utrzymywałeś  
> że php nadaje się też do pisnia skryptów shellowych, dosyć kiepsko się  
> nadaje)

Nawet jeśli (wg Ciebie) kiepsko, to się nadaje.

>. Po prostu pehap stworzony od początku jako język szablonów  
> ZAWSZE zagnieżdżonych w jakimś pliku tekstowym czy HTML'u. To pokazuje  
> przecież sama jego składnia.

To po co się kłocisz? Python chce być królem tej klasy języków, czy
jak?

>
> > - nie mowie, ze jest latwiej, ale jak chcesz wykazac
> > roznice i wyzszosc jednego nad drugim, to pokaz przyklad, zamiast
> > wypisywac LOL, czy inne dziwne skrotowce.
>
> Nie wiesz co to jest LOL? LOL! ;)

Ty też jesteś idiotą.

>
> Co ja poradzę że swoimi żenującymi wypowiedziami doprowadzasz czytelników  
> do śmiechu? :)

Nie moje wypowiedzi są żenujące, ale to, że ich nie rozumiesz, choć są
proste jak budowa cepa. Poczytaj sobie, gdzie używasz tych lolów, a
potem przemyśl, czy słusznie.

>
> > Snippet Ci nie odpowiada
> > (czyli wg Ciebie nie da sie wykazac wyzszosci pythona na przykladzie
> > krotkiego kawalka kodu), to napisz cala aplikacje.
>
> Przecież podałem ci jaskrawe przykłady. Czytać nie umiesz?

Jakie jaskrawe przykłady? Wiesz w ogóle co to jest konkretny przykład,
albo na czym polega napisanie dwu kawałków kodu w różnych językach
spełniających te same zadania?

>
> Python: ZODB, transakcyjna, baza obiektowa
> PHP: nic, i bez szans na napisanie
>
> Python: Zope, serwer aplikacyjny
> PHP: nic, i bez szans na napisanie

Cieszę się, że wymieniłeś dwa razy de facto ten sam projekt

>
> Python: SPE - aplikacja desktopowa, edytor IDE z obsługą debugera i  
> różnych bajerów
> PHP: ?
>
> Python: garbage collector, możliwość pisania wielowątkowych lub  
> pracujących asynchronicznych serwerów aplikacyjnych
> PHP: bardzo kiepski garbage collector, brak wątków, mnie nadaje się do  
> tworzenia żadnych serwerów
>
> Ale byś się nie naindyczył i mnie źle nie zrozumiał...
>
> Nie jest aż tak źle, że PHP się w ogóle do niczego nie nadaje. Jest sporo  
> gotowych aplikacji które spełniają swoją rolę. Są różne aplikacje do  
> obsługi forum dyskusyjnego, są różne CMS'y (choć żaden nie jest tak dobry  
> jak Plone).

Coś Ty?!.. a ja o czym pisałem? Czyli po parunastu postach
idiotycznego lolowania przyznajesz mi rację.

> Ale tworzenie czegoś większego od podstaw w... PHP? Chyba  
> tylko dla masochisty.
>
> Więc podsumowując: PHP jako język jest fatalnie zaprojektowany i pełen  
> wad, ale to go jeszcze całkiem nie przekreśla. Właśnie ze względu na  
> niektóre, gotowe rozwiązania. Podobnie, jak nie muszę wszystkiego pisać w  
> C, aby używać gotowych aplikacji w nim napisanych.

Porównanie do C to jak wyróżnienie

On Thu, 19 Nov 2009 14:14:59 -0000, pakalk <pakalk@gmail.com> wrote:

>> Ale nie masz wątków. Nie jesteś w stanie napisać żadnej aplikacji  
>> webowej pracującej w trybie serwletowym.
>
> Zabawne, że gdy mowa o GIL, to pythonowcy mówią, że wątki to przeżytek

A co to ma do rzeczy? GIL nie ma znaczenia jeśli odpalasz jeden proces na  
rdzeń. Poza tym Python ma wersję javową, gdzie może skorzystać z wątków  
systemowych. PHP ma tylko anemicznego Xercusa na którym ledwo co chodzi.

To co jednak ma duże znaczenie to wydajny garbage collector. pehap ma  
gówno a nie gc. dlatego nie napiszesz w nim żadnego serwera, bo to się  
będzie mijać z celem i wszystkie pehapowe aplikacje muszę z konieczności  
pracować w stylu ala' cgi. Kazdy request wszystko niszczy i tworzy od nowa  
za kazdym razem. To dramatycznie spowalnia kazda wieksza aplikacje.  
Dlatego pehap jest tak wolny w wiekszych projektach.

> - lepiej stosować procesy...

Procesy w skryptach shellowych? A jak będziesz wymieniał dane między nimi?  
Serializował obiekty? Bez sensu.

>> Nie jesteś też w stanie użyć pehapa do zautomatyzowania wielowątkowych  
>> zadań odpalanych z konsoli (a utrzymywałeś

>> że php nadaje się też do pisnia skryptów shellowych, dosyć kiepsko się  
>> nadaje)
>
> Nawet jeśli (wg Ciebie) kiepsko, to się nadaje.

Nie tylko wg mnie. Poza pehapowymi fanbojami mającymi mikre pojęcie o  
innych językach, nikt chyba nie twierdzi że pehap nadaje się dobrze do  
pisania skryptów shellowych.

>> . Po prostu pehap stworzony od początku jako język szablonów ZAWSZE  
>> zagnieżdżonych w jakimś pliku tekstowym czy HTML'u. To pokazuje  
>> przecież sama jego składnia.
>
> To po co się kłocisz? Python chce być królem tej klasy języków, czy
> jak?

Ja się nie kłócę. Ja tylko stwierdzam fakt, że pehap został stworzony jako  
język do szablonów i tak mu zostało. W przeciwieństwie do tego, Python  
jest językiem ogólnego zastosowania. Pehap - nie.

>>> - nie mowie, ze jest latwiej, ale jak chcesz wykazac
>>> roznice i wyzszosc jednego nad drugim, to pokaz przyklad, zamiast
>>> wypisywac LOL, czy inne dziwne skrotowce.
>>
>> Nie wiesz co to jest LOL? LOL! ;)
>
> Ty też jesteś idiotą.

A ty debilem. LOL = dziwny skrótowiec" weź dziecko się do nauki. Na  
początek zapoznaj się z panem Google.

> Jakie jaskrawe przykłady? Wiesz w ogóle co to jest konkretny przykład,
> albo na czym polega napisanie dwu kawałków kodu w różnych językach
> spełniających te same zadania?

Nie chodzi o to aby napisać to samo co potrafi też i PHP, ale o to, że w  
pehapie nie da się w ogóle napisać takich rzeczy jak w Pythonie.  
Przeszkodą są ograniczenia języka,.

> Cieszę się, że wymieniłeś dwa razy de facto ten sam projekt

Od kiedy ZODB to Zope? ZODB można używać zupełnie niezależnie.

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

On Nov 19, 5:10 pm, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> On Thu, 19 Nov 2009 14:14:59 -0000, pakalk <pak...@gmail.com> wrote:
> >> Ale nie masz wątków. Nie jesteś w stanie napisać żadnej aplikacji  
> >> webowej pracującej w trybie serwletowym.
>
> > Zabawne, że gdy mowa o GIL, to pythonowcy mówią, że wątki to przeżytek
>
> A co to ma do rzeczy? GIL nie ma znaczenia jeśli odpalasz jeden proces na  
> rdzeń. Poza tym Python ma wersję javową, gdzie może skorzystać z wątków  
> systemowych. PHP ma tylko anemicznego Xercusa na którym ledwo co chodzi.

To ma do rzeczy, ze jak ktos porownuje Pythona z PHP, to od razu rzuca
watkami, a jak porownuje sie Jave z Pythonem to opowiada sie, ze jest
kilka innych sposobow, bo wiadome, ze CPython z nimi sobie nie radzi.
Nie, nie mowie tutaj o tym, ze lepiej nie miec niz miec. Jasne, ze
lepiej miec obsluge. Tylko, ze tutaj jest tez pomylenie z poplataniem
- forki sa dostepne jako modul pod *iksa. W zendowskim PHP. W
http://quercus.caucho.com/ mozna zapewne uzyc bez problemu jawowych
watkow. Wiekszosc zarzutow do PHP jako jezyka odnosi sie do jego
zendowej implementacji. W Quercusie tez wystepuja takie bledy?

>
> To co jednak ma duże znaczenie to wydajny garbage collector. pehap ma  
> gówno a nie gc. dlatego nie napiszesz w nim żadnego serwera, bo to się  
> będzie mijać z celem i wszystkie pehapowe aplikacje muszę z konieczności  
> pracować w stylu ala' cgi. Kazdy request wszystko niszczy i tworzy od nowa  
> za kazdym razem. To dramatycznie spowalnia kazda wieksza aplikacje.  
> Dlatego pehap jest tak wolny w wiekszych projektach.



>
> > - lepiej stosować procesy...
>
> Procesy w skryptach shellowych? A jak będziesz wymieniał dane między nimi?  
> Serializował obiekty? Bez sensu.

Piekna manipulacja. Pisalem o tym, jakie obejscie proponuje sie w
zastepstwie za watki w CPythonie. I wtedy to nie jest bez sensu, a jak
ja pisze, to jest? Ciekawe swoja droga...

Natomiast jesli nie wiesz jak wymieniac dane miedzy procesami to... no
coz....

>
> > Nawet jeśli (wg Ciebie) kiepsko, to się nadaje.
>
> Nie tylko wg mnie. Poza pehapowymi fanbojami mającymi mikre pojęcie o  
> innych językach,

Nazywasz mnie fanbojem?

> nikt chyba nie twierdzi że pehap nadaje się dobrze do  
> pisania skryptów shellowych.

Skrypty da sie pisac we wszystkim co sie nazywa jezykiem skryptowym.
Jesli mam aplikacje w PHP, to normalne, ze lepiej napisac skrypt
shellowy w PHP niz np w Perlu.

>
> > To po co się kłocisz? Python chce być królem tej klasy języków, czy
> > jak?
>
> Ja się nie kłócę.

A to dobre...

> Ja tylko stwierdzam fakt, że pehap został stworzony jako  
> język do szablonów i tak mu zostało. W przeciwieństwie do tego, Python  
> jest językiem ogólnego zastosowania. Pehap - nie.

No to po co wypominanie PHP-owi brakow w dziedzinach do ktorych nie
byl powolany?

>
> > Ty też jesteś idiotą.
>
> A ty debilem.

Przynajmniej nie kreacjonista.

> LOL = dziwny skrótowiec" weź dziecko się do nauki. Na  
> początek zapoznaj się z panem Google.

LOL i Google.. pokolenie inteligentow.

>
> Nie chodzi o to aby napisać to samo co potrafi też i PHP, ale o to, że w  
> pehapie nie da się w ogóle napisać takich rzeczy jak w Pythonie.  
> Przeszkodą są ograniczenia języka,.

Wiec porownuj jezyki w zakresie w jakim da sie porownac. Co z tego, ze
sie nie da napisac serwera aplikacji w PHP, kiedy on tego nie
potrzebuje? Napisz program w pythonie i php w zakresie, w ktorym oba
jezyki maja zadanie sie sprawdzac.

>
> > Cieszę się, że wymieniłeś dwa razy de facto ten sam projekt
>
> Od kiedy ZODB to Zope? ZODB można używać zupełnie niezależnie.
>

XSLT, XSL, XPath, XML i mase innych tez sa niezalezne.

On Thu, 19 Nov 2009 16:29:59 -0000, pakalk <pakalk@gmail.com> wrote:

> To ma do rzeczy, ze jak ktos porownuje Pythona z PHP, to od razu rzuca
> watkami

Najbardziej rzucająca się rzecz to burdel i chaos panujący w pehapie. Oraz  
kiepska funkcjonalność. Mało?

> a jak porownuje sie Jave z Pythonem

A po co porównywać Pythona z Javą? Przecież jest Jython. Poza tym nie  
można mylić Javy jako języka z Javą jako platformą.

> W Quercusie tez wystepuja takie bledy?

Nie sprawdzałem. Ale kolega w pracy testował. Ogólnie, Xercus jest  
niedojrzały. I nie implementuje jeszcze wszystkiego z PHP5.

Osobiście życzę jednak temu projektowi jak najlepiej. Dla firm które  
wdepnęły w pehapa byłaby to jakaś furtka aby powoli przenieść się na  
bardziej produktywne i wydajne rozwiązania.

> Pisalem o tym, jakie obejscie proponuje sie w
> zastepstwie za watki w CPythonie.

Zwykle to dotyczy aplikacji webowych. Zresztą, czy ja coś takiego mówiłem?  
Polemizujesz sobie z sam ze sobą? Mówiłem raczej o skryptach shellowych  
który wielowątkowo wykonują kilka powiązanych zadań.

Poza tym GIL nie jest problemem. Można odpalić taki Pylons, który pracuje  
wielowątkowo, na tylu procesach ile jest dostępnych rdzeni w procesorze.  
Będzie mniejsze zużycie pamięci i pełne wykorzystanie środowiska.

> Natomiast jesli nie wiesz jak wymieniac dane miedzy procesami to... no
> coz....

Wiem, ale to jest wolne i niewygodne. Przynajmniej nie tak wygodne jak  
actors w Erlangu czy Scali.

>> nikt chyba nie twierdzi że pehap nadaje się dobrze do pisania skryptów  
>> shellowych.
>
> Skrypty da sie pisac we wszystkim co sie nazywa jezykiem skryptowym.

A co to jest "język skryptowy"? Potrafić podać jakąś precyzyjną definicję?  
:)

Poza tym nie było mowy o to "czy się da" ale czy się da *dobrze* czy  
*kiepsko*. Pehap jest kiepski do takich spraw, nie do tego został  
stworzony.


> Jesli mam aplikacje w PHP, to normalne, ze lepiej napisac skrypt
> shellowy w PHP niz np w Perlu.

Bzdura. Mogę podać na przykładzie znanej mi dużej amerykańskiej firmy  
pehapowej, że pehap do skryptów shellowych to margines. Cały system  
synchronizacji danych między serwerami zrobiony jest w Ruby (z  
wykorzystaniem Rake'a i Capistrano).

>> Ja tylko stwierdzam fakt, że pehap został stworzony jako język do  
>> szablonów i tak mu zostało. W przeciwieństwie do tego, Python jest  
>> językiem ogólnego zastosowania. Pehap - nie.
>
> No to po co wypominanie PHP-owi brakow w dziedzinach do ktorych nie
> byl powolany?

Bo ty się upierasz że pehap nadaje się równie dobrze także w tych  
dziedzinach. Vide skrypty shellowe.

> Przynajmniej nie kreacjonista.

A to ma być niby jakaś potwarz?? Założę się, że nawet nie wiesz co to  
słowo znaczy.

>> Nie chodzi o to aby napisać to samo co potrafi też i PHP, ale o to, że  
>> w  pehapie nie da się w ogóle napisać takich rzeczy jak w Pythonie.  
>> Przeszkodą są ograniczenia języka,.
>
> Wiec porownuj jezyki w zakresie w jakim da sie porownac.

Czyli co? Mam ograniczać się tylko do tego co potrafi PHP? Hehe, tak to  
można porownywać Pythona z Brainfuckiem...

Właśnie o to chodzi w tym wątku, aby porownać oba języki. A jak je  
porównać jeśli nie poprzez wyeksponowanie mocnych i słabych strony obu  
języków? Zamiast wyzywać tu wszystkich od idiotów, pokaż mocne strony  
pehapa i słabe Pythona, co byłoby odpowiedzią na pierwszy post w tym  
wątku? Za słabo znamy Pythona, co? ;)

> Co z tego, ze sie nie da napisac serwera aplikacji w PHP, kiedy on tego  
> nie
> potrzebuje?

Właśnie że potrzebuje, bo pehap, z powodu swojego stylu pracy cgi, przy  
większym kodzie, zwalnia jak cholera. Gdyby miał chociaż wydajny GC to  
można by pokusić się o odpalanie aplikacji pehapowych w trybie  
serwletowym. Ale słaba wydajność pehapa to nie największy problem, bo  
można go rozwiązać za pomocą dołożenia hardware'u. Znacznie gorszy jest  
chaos w języku i bibliotekach, czy nieobsługiwalne błędy fatalne.

> Napisz program w pythonie i php w zakresie, w ktorym oba
> jezyki maja zadanie sie sprawdzac.

Tylko po co? To nic nie pokaże. Znacznie lepiej wykazać wyższość jednego  
języka nad drugim poprzez pokazanie ich mocnych i słabych stron,  
wypunktowanie ograniczeń, niespójności. Wtedy, osoba, która chce się  
pakować w jedno, lub w drugie, nie będzie potem mogła powiedzieć, że nie  
wiedziała w co się pakuje. Każda technologia ma jakieś swoje mocne i słabe  
strony.

>> > Cieszę się, że wymieniłeś dwa razy de facto ten sam projekt
>>
>> Od kiedy ZODB to Zope? ZODB można używać zupełnie niezależnie.
>>
>
> XSLT, XSL, XPath, XML i mase innych tez sa niezalezne.

...zapomniałeś do tej listy dodać też HTML'a, CSS i JavaScript. :-D

Zope to konkretna aplikacja, a wymienione przez ciebie rzeczy to tylko  
technologie, standardy.

Rachunek całkowy i tabliczka mnożenia też są "niezależne" od programu  
Mathematica.

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

On Nov 19, 6:36 pm, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
>
> > a jak porownuje sie Jave z Pythonem
>
> A po co porównywać Pythona z Javą? Przecież jest Jython.

Co z tego, ze jest? Jython to implementacja Pythona na JVM - nie
rozumiem czemu mamy nie porownywac Javy i Pythona.

>
> Osobiście życzę jednak temu projektowi jak najlepiej. Dla firm które  
> wdepnęły w pehapa byłaby to jakaś furtka aby powoli przenieść się na  
> bardziej produktywne i wydajne rozwiązania.

Ten projekt moze rozwiazac wiele rzeczy, ktore sa zle zrobione w
zendowskim PHP.

>
> > Pisalem o tym, jakie obejscie proponuje sie w
> > zastepstwie za watki w CPythonie.
>
> Zwykle to dotyczy aplikacji webowych. Zresztą, czy ja coś takiego mówiłem?  
> Polemizujesz sobie z sam ze sobą? Mówiłem raczej o skryptach shellowych  
> który wielowątkowo wykonują kilka powiązanych zadań.

Nie polemizuje ze soba. Mowie tylko, ze albo sie chwali watki, albo
nie. Nie mozna chwalic watkow w Pythonie, deprecjonujac forki w PHP, a
potem deprecjonowac watki ogolnie, chwalac procesy, bo CPython
przegrywa na tym polu z Java. To hipokryzja.

>
> Poza tym GIL nie jest problemem. Można odpalić taki Pylons, który pracuje  
> wielowątkowo, na tylu procesach ile jest dostępnych rdzeni w procesorze.  

Procesy, nie watki. Otoz to co mowilem. Nie jest problemem, bo nie
uzywa sie watkow.

> Będzie mniejsze zużycie pamięci i pełne wykorzystanie środowiska.

I szafa gra.


>
> >> nikt chyba nie twierdzi że pehap nadaje się dobrze do pisania skryptów  
> >> shellowych.
>
> > Skrypty da sie pisac we wszystkim co sie nazywa jezykiem skryptowym.
>
> A co to jest "język skryptowy"? Potrafić podać jakąś precyzyjną definicję?  
> :)

W zalozeniach wymyslony do pisania skryptow.

>
> Poza tym nie było mowy o to "czy się da" ale czy się da *dobrze* czy  
> *kiepsko*. Pehap jest kiepski do takich spraw, nie do tego został  
> stworzony.

Ale mozna.

>
> > Jesli mam aplikacje w PHP, to normalne, ze lepiej napisac skrypt
> > shellowy w PHP niz np w Perlu.
>
> Bzdura. Mogę podać na przykładzie znanej mi dużej amerykańskiej firmy  
> pehapowej, że pehap do skryptów shellowych to margines. Cały system  
> synchronizacji danych między serwerami zrobiony jest w Ruby (z  
> wykorzystaniem Rake'a i Capistrano).

Mnie raczej chodzi o wykorzystanie gotowego kodu, np. klas.

>
> > No to po co wypominanie PHP-owi brakow w dziedzinach do ktorych nie
> > byl powolany?
>
> Bo ty się upierasz że pehap nadaje się równie dobrze także w tych  
> dziedzinach. Vide skrypty shellowe.

Mozna go uzywac, swiat sie nie zawali, bedzie dzialac. Nie pisalem, ze
jest najlepszy.

>
> > Przynajmniej nie kreacjonista.
>
> A to ma być niby jakaś potwarz?? Założę się, że nawet nie wiesz co to  
> słowo znaczy.

Zaklad przyjety.

Ok.. LOL -> idiota -> debil -> kreacjonista... that's enough.
Szczegolnie, ze jak ktos mowi (tak jak ja) The Lead Programmer na
Niego, to chyba zwolennik ID... whatever.

>
> > Wiec porownuj jezyki w zakresie w jakim da sie porownac.
>
> Czyli co? Mam ograniczać się tylko do tego co potrafi PHP? Hehe, tak to  
> można porownywać Pythona z Brainfuckiem...

Ale tak sie porownuje jezyki. Technologie dobiera sie do problemu, a
nie problem do technologii.

>
> Właśnie o to chodzi w tym wątku, aby porownać oba języki. A jak je  
> porównać jeśli nie poprzez wyeksponowanie mocnych i słabych strony obu  
> języków? Zamiast wyzywać tu wszystkich od idiotów, pokaż mocne strony  
> pehapa i słabe Pythona, co byłoby odpowiedzią na pierwszy post w tym  
> wątku? Za słabo znamy Pythona, co? ;)

Nie wszystkich, tylko tych, ktorzy zamiast dokladnie przeczytac co
napisalem probuja na sile przepchnac swoje racje, albo upieraja sie,
ze nie napisali tego co napisali.

Czemu mialbym wypisywac slabe strony Pythona?

>
> > Napisz program w pythonie i php w zakresie, w ktorym oba
> > jezyki maja zadanie sie sprawdzac.
>
> Tylko po co? To nic nie pokaże.

Pokaze przewage jednego nad drugim na konkretnym przypadku, a nie w
prozni.

> Znacznie lepiej wykazać wyższość jednego  
> języka nad drugim poprzez pokazanie ich mocnych i słabych stron,  

Ktore pozostaja wirtualnymi zaletami i wadami dopoki sie ich nie
przetestuje łeb w łeb.

> wypunktowanie ograniczeń, niespójności. Wtedy, osoba, która chce się  
> pakować w jedno, lub w drugie, nie będzie potem mogła powiedzieć, że nie  
> wiedziała w co się pakuje. Każda technologia ma jakieś swoje mocne i słabe  
> strony.

Ale to trzeba wykazac, a nie deklarowac.

>
> > XSLT, XSL, XPath, XML i mase innych tez sa niezalezne.
>
> ...zapomniałeś do tej listy dodać też HTML'a, CSS i JavaScript. :-D

Nie zapomnialem. Wymienione technologie zazebiaja sie - powstaly w
ramach jednego projekt de facto.

>
> Zope to konkretna aplikacja, a wymienione przez ciebie rzeczy to tylko  
> technologie, standardy.
>
> Rachunek całkowy i tabliczka mnożenia też są "niezależne" od programu  
> Mathematica.

To ktory Zope jest prawdziwy? 1, 2 czy 3? To tez technologia - moge ja
przepisac na dowolny inny sposob - byleby zachowac funkcjonalnosci i
jakze nieobiektowy interfejs calego tego systemu.

Dnia 19-11-2009 o 21:43:53 pakalk <pakalk@gmail.com> napisał(a):

> Co z tego, ze jest? Jython to implementacja Pythona na JVM - nie
> rozumiem czemu mamy nie porownywac Javy i Pythona.

Można, ale po co? Język Java nie jest istotny, to co się liczy, to  
platforma - czyli JVM i biblioteki.

> Ten projekt moze rozwiazac wiele rzeczy, ktore sa zle zrobione w
> zendowskim PHP.

Nic nie rozwiąże, jedynie da możliwość dostępu do platformy JVM.

> Mowie tylko, ze albo sie chwali watki, albo nie.

Mają swoje wady i zalety. Świat nie jest czarno-biały. Np. Python pozwoli  
napisać aplikację wielowątkową w systemie który nie posiada w ogóle  
możliwości pracy wątkowej ani forkowej. Hehe, MS-DOS? ;)

> Nie mozna chwalic watkow w Pythonie, deprecjonujac forki w PHP

PHP nie ma ani wątków ani forków. Forki masz w systemie POSIX. A w Windows  
masz procesy. Tak to można odpalać i Pythona.

Poza tym nie wiem dlaczego nie chcesz zrozumieć, że nie piszę o aplikacji  
webowej paralelizowanej przez serwer HTTP, ale o skryptach shellowych.

> CPython przegrywa na tym polu z Java.

Eee tam. CPython to nie jedyna implementacja Pythona. Jest też Jython i  
IronPython.

>> A co to jest "język skryptowy"? Potrafić podać jakąś precyzyjną  
>> definicję?
>
> W zalozeniach wymyslony do pisania skryptow.

A co to jest "skrypt"?

>> Poza tym nie było mowy o to "czy się da" ale czy się da *dobrze* czy  
>> *kiepsko*. Pehap jest kiepski do takich spraw, nie do tego został  
>> stworzony.
>
> Ale mozna.

Ale kiepsko. Coś tam można pewnie i w Brainfucku.

>> A to ma być niby jakaś potwarz?? Założę się, że nawet nie wiesz co to  
>> słowo znaczy.
>
> Zaklad przyjety.
>
> Ok.. LOL -> idiota -> debil -> kreacjonista... that's enough.

To jakiś sylogizm idioty? No toś się "popisał". To wszystko na co cię stać?

> Czemu mialbym wypisywac slabe strony Pythona?

Skoro uważasz że ma same mocne, to nie masz żadnych kwalifikacji aby się  
wypowiadać w tym wątku. Zobacz tytuł.

> Pokaze przewage jednego nad drugim na konkretnym przypadku, a nie w
> prozni.

Jaką przewagę? Że użyje się innej składni? Bez sensu. Przyjąłeś jaką  
błazeńską metodę porównywania. Hehe, też mi porównywanie przez  
przyglądanie się składni dla "Hello World!".

>> Znacznie lepiej wykazać wyższość jednego języka nad drugim poprzez  
>> pokazanie ich mocnych i słabych stron,
>
> Ktore pozostaja wirtualnymi zaletami i wadami dopoki sie ich nie
> przetestuje łeb w łeb.

Właśnie w tym rzecz, że nie można "łeb w łeb" bo pehap jest za cienki aby  
dało się w nim napisać to, co w Pythonie. Czyli zawęża pole zastosowań  
pehapa. Czyli można potem bić głową w mur. Czyli lepiej się dobrze  
zastanowić, zanim się w niego wlezie.

>> Każda technologia ma jakieś swoje mocne i  słabe  strony.
>
> Ale to trzeba wykazac, a nie deklarowac.

No to zrób to w końcu. Ja nic nie poradzę, że nie umiesz czytać ze  
zrozumieniem.

>> > XSLT, XSL, XPath, XML i mase innych tez sa niezalezne.
>>
>> ...zapomniałeś do tej listy dodać też HTML'a, CSS i JavaScript. :-D
>
> Nie zapomnialem. Wymienione technologie zazebiaja sie - powstaly w
> ramach jednego projekt de facto.

De facto toś przywalił teraz ciężką głupotą. JavaScript i XML powstały "w  
ramach jednego projektu"? Ciekawe jakiego. Podasz nazwę i źródła, czy  
tylko konfabulujesz?

>> Zope to konkretna aplikacja, a wymienione przez ciebie rzeczy to tylko  
>> technologie, standardy.
>>
>> Rachunek całkowy i tabliczka mnożenia też są "niezależne" od programu  
>> Mathematica.
>
> To ktory Zope jest prawdziwy? 1, 2 czy 3?

A jakie to ma znaczenie? Czy ktoś używa gdzieś Zope 1??

> To tez technologia - moge ja przepisac na dowolny inny sposob - byleby  
> zachowacfunkcjonalnosci

No to napisz w pehapie jakikolwiek serwer aplikacyjny zbliżony do Zope.  
Śnij dalej.

Trzeba być faktycznie idiotą aby porównywać XML z Zope. A może  
rzeczywiście ty masz problem ze zrozumieniem słów które używasz? Jak boisz  
się pana Google to kup sobie jakąś książkę. Może coś z serii "Dla  
opornych"? Będzie w sam raz.

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

On Nov 20, 10:02 am, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> Dnia 19-11-2009 o 21:43:53 pakalk <pak...@gmail.com> napisał(a):
>
> > Co z tego, ze jest? Jython to implementacja Pythona na JVM - nie
> > rozumiem czemu mamy nie porownywac Javy i Pythona.
>
> Można, ale po co? Język Java nie jest istotny, to co się liczy, to  
> platforma - czyli JVM i biblioteki.

Ok
>
> > Ten projekt moze rozwiazac wiele rzeczy, ktore sa zle zrobione w
> > zendowskim PHP.
>
> Nic nie rozwiąże, jedynie da możliwość dostępu do platformy JVM.

Wiec patrz wyzej.

Wiekszosc (wszystkie?) zarzuty PHP dotycza standardowej biblioteki.

>
> > Nie mozna chwalic watkow w Pythonie, deprecjonujac forki w PHP
>
> PHP nie ma ani wątków ani forków. Forki masz w systemie POSIX. A w Windows  
> masz procesy. Tak to można odpalać i Pythona.

Ale co z tego? Twierdzisz, ze w PHP sie nie da, a teraz ze sie jednak
da, ale Pythona tez. A czy ja mowilem, ze sie Pythona nie da? Gubisz
sie w zeznaniach.

> Poza tym nie wiem dlaczego nie chcesz zrozumieć, że nie piszę o aplikacji  
> webowej paralelizowanej przez serwer HTTP, ale o skryptach shellowych.

A co to z kolei ma do rzeczy? Co? Tylko jak input idzie z sieci, to
mozna forka uzyc? Nie kumam raczej.

> > CPython przegrywa na tym polu z Java.
>
> Eee tam. CPython to nie jedyna implementacja Pythona. Jest też Jython i  
> IronPython.

I teraz powiedz - co to ma do rzeczy, ze jest Jython, Iron Python i
jeszcze x innych implementacji, gdy ja pisze o CPythonie?

>
> A co to jest "skrypt"?

Nie chce mi sie w takie rzeczy bawic

>
> >> Poza tym nie było mowy o to "czy się da" ale czy się da *dobrze* czy  
> >> *kiepsko*. Pehap jest kiepski do takich spraw, nie do tego został  
> >> stworzony.
>
> > Ale mozna.
>
> Ale kiepsko. Coś tam można pewnie i w Brainfucku.

Widzisz roznice mieszy "nie mozna" a "mozna, ale gorzej niz w XXX"?
Taka subtelna roznica, jak miedzy 0 zl na koncie, a 100 zl na koncie,
gdy ktos inny ma 300.

>
> > Zaklad przyjety.
>
> > Ok.. LOL -> idiota -> debil -> kreacjonista... that's enough.
>
> To jakiś sylogizm idioty? No toś się "popisał". To wszystko na co cię stać?

Ty jednak nie myslisz logicznie.

>
> > Czemu mialbym wypisywac slabe strony Pythona?
>
> Skoro uważasz że ma same mocne, to nie masz żadnych kwalifikacji aby się  
> wypowiadać w tym wątku. Zobacz tytuł.

"Python vs PHP - potrzebne argumenty"

Ty naprawde myslisz inaczej.

Poza tym co ma tytul jakiegokolwiek watku do moich kwalifikacji?!

>
> > Pokaze przewage jednego nad drugim na konkretnym przypadku, a nie w
> > prozni.
>
> Jaką przewagę?

Ponoc jakas Python ma. To wlasnie tę.

> Że użyje się innej składni? Bez sensu.

Dla myslacych logicznie nie jest to bez sensu.

> Przyjąłeś jaką  
> błazeńską metodę porównywania. Hehe, też mi porównywanie przez  
> przyglądanie się składni dla "Hello World!".

Ty naprawde myslisz inaczej!

>
> >> Znacznie lepiej wykazać wyższość jednego języka nad drugim poprzez  
> >> pokazanie ich mocnych i słabych stron,
>
> > Ktore pozostaja wirtualnymi zaletami i wadami dopoki sie ich nie
> > przetestuje łeb w łeb.
>
> Właśnie w tym rzecz, że nie można "łeb w łeb" bo pehap jest za cienki aby  
> dało się w nim napisać to, co w Pythonie. Czyli zawęża pole zastosowań  
> pehapa. Czyli można potem bić głową w mur. Czyli lepiej się dobrze  
> zastanowić, zanim się w niego wlezie.

Juz pisalem o tym, ze technologie dobiera sie do problemu, a nie na
odwrot. Twoje myslenie jest do bani. Samochod tez sobie taki kupujesz,
co moze jezdzic szybko po aurtostradach i jest super w terenie, a do
tego amfibia? Naprawde nie rozumiesz oczywistosci.

>
> >> Każda technologia ma jakieś swoje mocne i  słabe  strony.
>
> > Ale to trzeba wykazac, a nie deklarowac.
>
> No to zrób to w końcu. Ja nic nie poradzę, że nie umiesz czytać ze  
> zrozumieniem.

Ja nie umiem?! To Ty wykaz! Czemu ja mam wykazywac? Stek bzdur
wypisujecie o PHP, bez zadnych przykladow i ja mam udowadniac, ze cos
nie istnieje?! To Python chce zajac miejsce PHP na stanowisku
naczelnego jezyka webdeveloperki, wiec niech sie wykaze. Nic nikomu
sie nie nalezy za same piekne deklaracje, nawet jesli maja pokrycie w
rzeczywistosci.

>
> >> > XSLT, XSL, XPath, XML i mase innych tez sa niezalezne.
>
> >> ...zapomniałeś do tej listy dodać też HTML'a, CSS i JavaScript. :-D
>
> > Nie zapomnialem. Wymienione technologie zazebiaja sie - powstaly w
> > ramach jednego projekt de facto.
>
> De facto toś przywalił teraz ciężką głupotą. JavaScript i XML powstały "w  
> ramach jednego projektu"?

JavaScript wymieniles Ty! Nie rozmawiam z Toba juz, to nie ma sensu.
Piszesz cos, potem wmawiasz, ze ja to napisalem.. i mnie krytykujesz
za cos, co nie ma zwiazku z tym co pisze. Nie chce Ci sie czytac tego
co ja pisze, wybiorczo bierzesz moje wypowiedzi (np. wyjales
"snippeta", a pominales "aplikacje"), dopowiadasz sobie (ze niby ta
aplikacja, czy snippet to ma byc "hello world"), opowiadasz jakies
glupoty w stylu, ze porownanie nie ma sensu, bo python jest lepszy i
juz... mialem gdzies linka do benchmarkow, teraz nie mam. Guzik te
Wasze dyrdymaly kogokolwiek obchodza. opowiadanie, ze np. PHP nie
radzi sobie z UTF-8 (bezedura) itp. 100x lepiej przemawiaja benchmarki
w ktorych Symfony ma (nie pamietam, m/w) 100 hitow na sekunde, a
Django 1000. To jest prawdziwe podejscie do tematu scislej dziedziny
jaka jest informatyka. A nie opowiadanie bzdur ("bo mię się nie chce
zrobic ifa"). Pomijam juz braki w ogolnej wiedzy o OOP, o ktorym
trzeba miec pojecie, aby nie stworzyc potworka w Pythonie ("interfejsy
nie sa obiektowe"). Czasem wydaje mi sie, to ogolna uwaga, ze
niektorzy obiektowosc pojmuja za pomoca kropki, ktora moga sobie
wstawic po nazwie zmiennej. Jak jest -> to juz jest "spaczony model
obiektowy". Tymczasem programowac obiektowo to mozna i w asemblerze,
tylko trzeba umiec.

>  Ciekawe jakiego. Podasz nazwę i źródła, czy  
> tylko konfabulujesz?

I jeszcze oskarzenia. Ale pewnie o te js, o ktorym nie ja pisalem.

>
> > To ktory Zope jest prawdziwy? 1, 2 czy 3?
>
> A jakie to ma znaczenie? Czy ktoś używa gdzieś Zope 1??

1. No ma.
2. Pewnie uzywa.

>
> > To tez technologia - moge ja przepisac na dowolny inny sposob - byleby  
> > zachowacfunkcjonalnosci
>
> No to napisz w pehapie jakikolwiek serwer aplikacyjny zbliżony do Zope.  
> Śnij dalej.

Naucz sie czytac, dobrze Ci radze.

>
> Trzeba być faktycznie idiotą aby porównywać XML z Zope.

Trzeba byc idiota, zeby nie zrozumiec co napisalem.

> A może  
> rzeczywiście ty masz problem ze zrozumieniem słów które używasz?

Obawiam sie, ze to Twoja domena.

> Jak boisz  
> się pana Google to kup sobie jakąś książkę.

Wydaje mi sie, ze mamy odmienne spojrzenie na slowa, ktorych uzywamy
wlasnie dlatego, ze ja wiedze czerpie z ksiazek, a Ty z googli.

> Może coś z serii "Dla  opornych"? Będzie w sam raz.

Rozumiem, ze to Twoje zyczenie gwaizdkowe. Zapisalem.

Trochę faktów, gdy już poopowiadalismy sobie bajki...


Niekończąca się opowieść, dla porownania wydajności języków:
http://shootout.alioth.debian.org/
Django vs Symfony, proste porównanie: http://www.mellowmorning.com/2008/08/27/django-vs-symfony/
Porównanie 6 wiodących frameworków:
http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/
(tak, wiem że sprzed 3 lat, ale nie ma wiele takich zestawień).

Dane, które chcę naświetlić:

http://static.alrond.com/ab_table.gif
http://static.alrond.com/siege.gif


..ale to oczywiście ja muszę wstawić, bo "strażnicy dobrego kodu i
standardów wszelakich" wolą się wydzierać na innych, opowiadać
niestworzone historie, adorować się nawzajem, a jak ktoś wytknie im
glupotę/pomyłkę/brak jakichkolwiek konkretnych argumentów, to
wtedy.... "jakże śmiesz! python wielkim językiem jest!"... szczególnie
wg. owych "strażników" się nadaje do nauki programowanie obiektowego..
ale tylko takiego bez interfejsów i chronionych członków klasy....

Ktoś dobrze napisał, że fajnie by było, jakby programiści Pythona
przestali krytykować inne języki i w końcu coś zaprogramowali.

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

> Trochę faktów, gdy już poopowiadalismy sobie bajki...

A mógłbyś sobie po prostu pójść na jakieś .advocacy czy inne .php
i tam ewangelizować ludzi, którzy będą tym zainteresowani?
Przeszkadzasz w lurkowaniu. Nie czytam tej grupy dla czyichś 
zachwytów nad językiem, który dawno zostawiłem za sobą i trauma
już prawie przeszła.

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

On Nov 21, 1:48 am, Grzegorz Staniak <gstan...@wp.pl> wrote:
> On 21.11.2009, pakalk <pak...@gmail.com> wroted:
>
> > Trochę faktów, gdy już poopowiadalismy sobie bajki...
>
> A mógłbyś sobie po prostu pójść na jakieś .advocacy czy inne .php
> i tam ewangelizować ludzi, którzy będą tym zainteresowani?
> Przeszkadzasz w lurkowaniu. Nie czytam tej grupy dla czyichś
> zachwytów nad językiem, który dawno zostawiłem za sobą i trauma
> już prawie przeszła.
>

Mowilem juz, ze jestes idiota?

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

>> > Trochę faktów, gdy już poopowiadalismy sobie bajki...
>>
>> A mógłbyś sobie po prostu pójść na jakieś .advocacy czy inne
>> .php i tam ewangelizować ludzi, którzy będą tym zainteresowani?
>> Przeszkadzasz w lurkowaniu. Nie czytam tej grupy dla czyichś
>> zachwytów nad językiem, który dawno zostawiłem za sobą i
>> trauma już prawie przeszła.
>
> Mowilem juz, ze jestes idiota?

Różne głupie rzeczy mówiłeś. Pójdziesz? Może gdzieś cię docenią.

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

On Nov 21, 2:13 am, Grzegorz Staniak <gstan...@wp.pl> wrote:
>
> Różne głupie rzeczy mówiłeś. Pójdziesz? Może gdzieś cię docenią.
>

To nie ja tutaj mowie "glupie rzeczy". Chocby o tablicach, co to przez
9 lat mnie oszukuja i "udaja listy". Ale nie bede ciagnal tej rozmowy
z Toba, bo to strata czasu. Mojego czasu.

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

>> Różne głupie rzeczy mówiłeś. Pójdziesz? Może gdzieś cię
>> docenią.
>
> To nie ja tutaj mowie "glupie rzeczy". 

Wystarczy, że mówisz nie na temat -- to nie jest grupa poświęcona 
ewangelizacji PHP, ani nawet w ogóle PHP. Znajdź sobie inną.

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

On Nov 21, 3:21 am, Grzegorz Staniak <gstan...@wp.pl> wrote:
> On 21.11.2009, pakalk <pak...@gmail.com> wroted:
>
> >> Różne głupie rzeczy mówiłeś. Pójdziesz? Może gdzieś cię
> >> docenią.
>
> > To nie ja tutaj mowie "glupie rzeczy".
>
> Wystarczy, że mówisz nie na temat -- to nie jest grupa poświęcona
> ewangelizacji PHP, ani nawet w ogóle PHP. Znajdź sobie inną.
>

Czyli przyznajesz, ze mowie madre rzeczy, tylko nie na temat. Bo
oczywiscie w temacie "python vs php" trzeba tylko chwalic pythona i
jechac po php. A jak ktos stanie w obronie przed nieslusznymi
zarzutami, to... dziecko sie pogniewa i "idz sobie do innej
piaskownicy, ta jeśt moja"... Zresztą...

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

>> Wystarczy, że mówisz nie na temat -- to nie jest grupa
>> poświęcona ewangelizacji PHP, ani nawet w ogóle PHP. Znajdź
>> sobie inną.
>
> Czyli przyznajesz, ze mowie madre rzeczy, tylko nie na temat.

Jeśli hurtowo za jednym zamachem przyznam ci wszystko co zechcesz,
pójdziesz sobie?

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

On Nov 21, 3:36 am, Grzegorz Staniak <gstan...@wp.pl> wrote:
> On 21.11.2009, pakalk <pak...@gmail.com> wroted:
>
> >> Wystarczy, że mówisz nie na temat -- to nie jest grupa
> >> poświęcona ewangelizacji PHP, ani nawet w ogóle PHP. Znajdź
> >> sobie inną.
>
> > Czyli przyznajesz, ze mowie madre rzeczy, tylko nie na temat.
>
> Jeśli hurtowo za jednym zamachem przyznam ci wszystko co zechcesz,
> pójdziesz sobie?

Nie, ale przyznać możesz. Jedyna dobra rzecz, ktorą napiszesz w tym
wątku.

On Nov 21, 2:06 am, pakalk <pak...@gmail.com> wrote:

> Mowilem juz, ze jestes idiota?

Na takim poziomie nie ma co dyskutowac.

Moje uwagi. (dla duzego projektu, kilka lat intensywnej developerki)

1. PHP 5.2 - brak przestrzeni nazw, styl cgi.
  - ryzyko class redeclaration jest wysokie
  - obciazenie autoloadera znaczne
  - brak namespaces czesto uniemozliwia uzywanie modulow (?) czy klas
przygotowanych przez innych,
wiec trzeba klepac wlasne implementacje kolejek priorytetowych, albo
forkowac istniejace rozwiazania i zmieniac nazwy klas/implementacje,
aby sie nie gryzlo
  - tryb CGI przewrotnie utrzymuje caly system w dzialaniu - powielone
nazwy klas to codziennosc, na szczescie requesty/skrypty shell pracuja
w troche odmiennych srodowiskach i sytuacja konfliktu nie nastepuje
  - tryb CGI to fatalna wydajnosc

2. Przestrzenie nazw PHP 5.3
  - do wsparcia namespaces z 5.3 przy tak zlozonym projekcie to daleka
droga. nie mozna ot tak zmienic wersji php (samo podniesienie php o
jakas revision jest w stanie wykrzaczyc system - np. bylo tak, gdy glob
() zaczala zwracac null zamiast pustych tablic, pierwszy warning przy
array_merge rozwalil cala procedure, soft sie uruchamial, ale dzialal
nieprawidlowo)


3. SPL
  - szczytna inicjatywa; spl jest przez nas stosowany
  - szkoda, ze nie uzywany jest przez funkcje/klasy wbudowane w php
(lub jego moduly), co za tym idzie wiekszosc funkcji zwraca array
zamiast listy/iteratora
  - nie ma zbytnio sensu istnienia w rozbudowanej formie bez
namespaces

4. Programowanie z PHP
  - pisanie skryptow shell jest mozliwe
  - zrobienie duzego softu jest mozliwe (warto wesprzec sie porzadna
baza danych)
  - jest uciazliwe, czesto zabawne, czesto wkurzajace
  - kazdy, kto panuje nad wadami/bledami/niescislosciami php oraz
lapie sie w zrodlach wielkiego projektu, jest swego rodzaju mistrzem
  - debug - najczesciej przez dupczenie (var_dup ;)


Jesli chodzi o Python:

1. pakiety i moduly, fcgi/wsgi
  - brak problemow z redeklaracja klas
  - uzycie zewn. bibliotek jest proste, brak kolizji
  - wysoka wydajnosc

2. n/d

3. stdlib
  - rozbudowana, lepiej przygotowana niz stdlib php (uzywa sie o wiele
latwiej)
  - oczywiscie podzielony na pakiety/moduly

4. programowanie z python:
  - pisanie skryptow shell mozliwe (tu: prostsze, krotsze,
przyjemniejsze)
  - zrobienie duzego softu nie przysparza takich technicznych
problemow, jak z php
  - jest przyjemne, czesto zabawne, rzadko wkurzajace
  - utrzymanie kodu jest prostsze
  - debug - dobre narzedzia


Da sie uzywac PHP? Do wielu zastosowan tak, tylko po co sie meczyc.
Gorzej, jak nie ma odwrotu ;)
Juz ktos powiedzial w tym wątku - technologie dobieramy do potrzeb. Ja
osobiscie PHP nie wybieram juz nawet do prostych stronek, ale pewnie
istnieja dziedziny, w ktorych PHP sprawdzi sie doskonale (chocby
patrzac przez pryzmat kosztow pracownika)

marcin

On 23 Lis, 08:25, Marcin Nowak <marcin.j.no...@gmail.com> wrote:
> On Nov 21, 2:06 am, pakalk <pak...@gmail.com> wrote:
>
> > Mowilem juz, ze jestes idiota?
>
> Na takim poziomie nie ma co dyskutowac.
>
> (...)
>
> Da sie uzywac PHP? Do wielu zastosowan tak, tylko po co sie meczyc.
> Gorzej, jak nie ma odwrotu ;)
> Juz ktos powiedzial w tym wątku - technologie dobieramy do potrzeb. Ja
> osobiscie PHP nie wybieram juz nawet do prostych stronek, ale pewnie
> istnieja dziedziny, w ktorych PHP sprawdzi sie doskonale (chocby
> patrzac przez pryzmat kosztow pracownika)

W końcu treściwa wypowiedź.

Tak, to ja mowilem o idiotach, ale brakowalo mi slow na to co
czytalem. Mea culpa.

On Nov 23, 8:25 am, Marcin Nowak <marcin.j.no...@gmail.com> wrote:
> Moje uwagi. (dla duzego projektu, kilka lat intensywnej developerki)
>
> 1. PHP 5.2 - brak przestrzeni nazw, styl cgi.
[...]
>   - tryb CGI przewrotnie utrzymuje caly system w dzialaniu - powielone
> nazwy klas to codziennosc, na szczescie requesty/skrypty shell pracuja
> w troche odmiennych srodowiskach i sytuacja konfliktu nie nastepuje
>   - tryb CGI to fatalna wydajnosc

Jest PHP-FPM. Owszem, A.D. 2009, to powinno być OotB, a nie 3rd party.

> 2. Przestrzenie nazw PHP 5.3
>   - do wsparcia namespaces z 5.3 przy tak zlozonym projekcie to daleka
> droga. nie mozna ot tak zmienic wersji php (samo podniesienie php o
> jakas revision jest w stanie wykrzaczyc system - np. bylo tak, gdy glob
> () zaczala zwracac null zamiast pustych tablic, pierwszy warning przy
> array_merge rozwalil cala procedure, soft sie uruchamial, ale dzialal
> nieprawidlowo)

Jeśli chodzi o samą składnie przestrzeni nazwa, to było parę
propozycji, z których wybrali MSZ najgorszą.

> Jesli chodzi o Python:
>
> 1. pakiety i moduly, fcgi/wsgi
>   - brak problemow z redeklaracja klas
>   - uzycie zewn. bibliotek jest proste, brak kolizji
>   - wysoka wydajnosc

Co do ostatniego, to bez przesady. Bardzo słabo w porównaniu do
statycznych języków. Póki Python nie będzie miał JIT, póty nie ma co
mówić o wydajności.

Co do PHP: http://www.codinghorror.com/blog/archives/001119.html

On 23 Lis, 15:25, Bart Ogryczak <b.ogryc...@gmail.com> wrote:
> On Nov 23, 8:25 am, Marcin Nowak <marcin.j.no...@gmail.com> wrote:

> > Jesli chodzi o Python:
> >   - wysoka wydajnosc

> Co do ostatniego, to bez przesady. Bardzo słabo w porównaniu do
> statycznych języków. Póki Python nie będzie miał JIT, póty nie ma co
> mówić o wydajności.

do tego co robie mi wystarcza. znam ludzi, ktorzy do prototypowania
prostego projektu web chca uzywac J2EE. to ich sprawa.

> Co do PHP:http://www.codinghorror.com/blog/archives/001119.html

na temat php mozna wylac wiadro pomyj. z reszta to juz w tym watku
zrobilismy wszyscy.

marcin

On Nov 23, 4:59 pm, Marcin Nowak <marcin.j.no...@gmail.com> wrote:
> On 23 Lis, 15:25, Bart Ogryczak <b.ogryc...@gmail.com> wrote:
>
> > On Nov 23, 8:25 am, Marcin Nowak <marcin.j.no...@gmail.com> wrote:
> > > Jesli chodzi o Python:
> > >   - wysoka wydajnosc
> > Co do ostatniego, to bez przesady. Bardzo słabo w porównaniu do
> > statycznych języków. Póki Python nie będzie miał JIT, póty nie ma co
> > mówić o wydajności.
>
> do tego co robie mi wystarcza. znam ludzi, ktorzy do prototypowania
> prostego projektu web chca uzywac J2EE. to ich sprawa.

Niewątpliwie. Tyle, że są dziesiątki *prawdziwych* powodów, żeby
wybrać Pythona zamiast PHP, nie trzeba wymyślać mocno wątpliwych,
takich jak "wydajność". Akurat Python 2.6 i PHP 5.3 mają wydajność na
tym samym poziomie.

ATSD, jeśli chodzi o wydajny dynamiczny języki, to Lua jest
kilkukrotnie szybsza, niż oba wyżej wymienione.

> > Co do PHP:http://www.codinghorror.com/blog/archives/001119.html
>
> na temat php mozna wylac wiadro pomyj. z reszta to juz w tym watku
> zrobilismy wszyscy.

Niemniej Jeff ma tu bardzo słuszny argument -- największe serwisy mają
frontendy (czasem nie tylko) napisane w PHP:
- Facebook
- Yahoo
- Wikipedia
- Nasza-klasa
itd.

Ja PHP nie lubię, ja bym PHP nie wybrał, ale nigdy nie będę wbrew
faktom twierdził, że się nie da dużego projektu zrobić dobrze w PHP.
Bo jak widać da się. Choć wg mnie w Pythonie szybciej, łatwiej i
bezpieczniej.

Innymi słowy, nie mieszajmy osobistych opinii z faktami.

On Nov 23, 5:27 pm, Bart Ogryczak <b.ogryc...@gmail.com> wrote:
> On Nov 23, 4:59 pm, Marcin Nowak <marcin.j.no...@gmail.com> wrote:
>
> > On 23 Lis, 15:25, Bart Ogryczak <b.ogryc...@gmail.com> wrote:
>
> > > On Nov 23, 8:25 am, Marcin Nowak <marcin.j.no...@gmail.com> wrote:
> > > > Jesli chodzi o Python:
> > > >   - wysoka wydajnosc
> > > Co do ostatniego, to bez przesady. Bardzo słabo w porównaniu do
> > > statycznych języków. Póki Python nie będzie miał JIT, póty nie ma co
> > > mówić o wydajności.

Alternatywne implementacje:
 * Jython - kilka razy szybszy od CPython, tylko trochę wolniejszy od
zwykłej Javy
 * IronPython - python dla platformy .NET - podobnie jak wyżej
 * Unladen Swallow - nieoficjalny zastępnik CPython'a dla wersji 3.x,
na razie tylko trochę szybszy w porównaniu z 2.6

JIT-y:
 * Psycho
 * PyPy (robi też dużo więcej, np. funkcjonalności ze stackless
pythona)

Ciekawy benchmark na ten temat (świeży):
http://morepypy.blogspot.com/2009/11/some-benchmarking.html

Aha. I oczywiście, to czy język jest typowany statycznie, czy
dynamicznie, nie ma dużego wpływu na wydajność. Np. Common Lisp po
kompilacji ma wydajność jak C.

On Nov 24, 2:17 am, Łukasz Rekucki <lreku...@gmail.com> wrote:
> On Nov 23, 5:27 pm, Bart Ogryczak <b.ogryc...@gmail.com> wrote:
>
> > On Nov 23, 4:59 pm, Marcin Nowak <marcin.j.no...@gmail.com> wrote:
>
> > > On 23 Lis, 15:25, Bart Ogryczak <b.ogryc...@gmail.com> wrote:
>
> > > > On Nov 23, 8:25 am, Marcin Nowak <marcin.j.no...@gmail.com> wrote:
> > > > > Jesli chodzi o Python:
> > > > >   - wysoka wydajnosc
> > > > Co do ostatniego, to bez przesady. Bardzo słabo w porównaniu do
> > > > statycznych języków. Póki Python nie będzie miał JIT, póty nie ma co
> > > > mówić o wydajności.
>
> Alternatywne implementacje:
>  * Jython - kilka razy szybszy od CPython, tylko trochę wolniejszy od
> zwykłej Javy

Żeby był istotnie szybszy, to trzeba poczekać na kolejną wersję JVM.

>  * Unladen Swallow - nieoficjalny zastępnik CPython'a dla wersji 3.x,
> na razie tylko trochę szybszy w porównaniu z 2.6

Po pierwsze, to 2.6, z 3.0 jeszcze w ogóle nie zaczeli. Po drugie póki
co jest to mocno eksperymentalne, jak na razie uzyskali przyspieszenie
kosztem koszmarnej pamięciożerności. Niemniej, jest to chyba
najbardziej obieciujący z projektów optymalizacji Pythona.

> JIT-y:
>  * Psycho

Umarło i nie żyje. PyPy miało być kolejnym krokiem.

>  * PyPy (robi też dużo więcej, np. funkcjonalności ze stackless
> pythona)

Ale niestety też nie widać, żeby wiele się w temacie działo.

Bart Ogryczak wrote:
> On Nov 24, 2:17 am, Łukasz Rekucki <lreku...@gmail.com> wrote:
>> On Nov 23, 5:27 pm, Bart Ogryczak <b.ogryc...@gmail.com> wrote:
>>
>>> On Nov 23, 4:59 pm, Marcin Nowak <marcin.j.no...@gmail.com> wrote:
>>>> On 23 Lis, 15:25, Bart Ogryczak <b.ogryc...@gmail.com> wrote:
>>>>> On Nov 23, 8:25 am, Marcin Nowak <marcin.j.no...@gmail.com> wrote:
>>>>>> Jesli chodzi o Python:
>>>>>>   - wysoka wydajnosc
>>>>> Co do ostatniego, to bez przesady. Bardzo słabo w porównaniu do
>>>>> statycznych języków. Póki Python nie będzie miał JIT, póty nie ma co
>>>>> mówić o wydajności.
>> Alternatywne implementacje:
>>  * Jython - kilka razy szybszy od CPython, tylko trochę wolniejszy od
>> zwykłej Javy
> 
> Żeby był istotnie szybszy, to trzeba poczekać na kolejną wersję JVM.
> 
>>  * Unladen Swallow - nieoficjalny zastępnik CPython'a dla wersji 3.x,
>> na razie tylko trochę szybszy w porównaniu z 2.6
> 
> Po pierwsze, to 2.6, z 3.0 jeszcze w ogóle nie zaczeli. Po drugie póki
> co jest to mocno eksperymentalne, jak na razie uzyskali przyspieszenie
> kosztem koszmarnej pamięciożerności. Niemniej, jest to chyba
> najbardziej obieciujący z projektów optymalizacji Pythona.
> 
>> JIT-y:
>>  * Psycho
> 
> Umarło i nie żyje. PyPy miało być kolejnym krokiem.
> 
>>  * PyPy (robi też dużo więcej, np. funkcjonalności ze stackless
>> pythona)
> 
> Ale niestety też nie widać, żeby wiele się w temacie działo.
> 

W bieżącym miesiącu (podczas ostatniego sprintu) cośtam ruszyli. Do 
Psyco jeszcze trochę brakuje, ale pare kawałków (w końcu) przyspieszyło.

pzdr
\SK

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

Sebastian Kaliszewski wrote:

Poprawka...

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

         z_bledem(cont, 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)
> 

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

Sebastian Kaliszewski powiada:

> 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(cont, 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)
>

Tak to dziwacznie wymyśliłeś, żeby było kalką wyjątków.
No i nadal nie wiem, gdzie jest ta niejawna globalna kontynuacja.

> 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

VS np.

def z_bledem(a,b, contA, contB):
  if not a: continue to contA()
  elif not b: continue to contB()

def wolanie():
  for i in range(10):
    z_bledem(true/false, true/false, errorAhandler, errorBhandler)
  
>>> 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ż*.

Kilka postingów temu postawiłeś tezę, że używanie kontynuacji 
nie ma sensu w językach typowanych dynamicznie. Jeśli teraz 
doprecyzowujesz, że tylko w tych z nich, w których kontynuacje 
nie są częścią języka, to wychodzi banalna tautologia
(i nie wiadomo po co w to w ogóle mieszać dynamizm).

>> To czy wszystkie (kwantyfikatorowo) to bez znajomości: errcode<>success.
>
> Tyle samo mi daje catch(...) -- w obu wypadkach niewiele.

Da, jeśli obstawimy nim każde wołanie. No to po co w ogóle wyjątki.

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

Jeśli podasz za mało argumentów do funkcji (tzn. pominiesz którąś 
z wyjątkowych kontynuacji), to da się to wyłapać statycznie, 
a błąd wykonania pojawi się nawet w prawidłowym przypadku.

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

W jednym przypadku wystarczy sprawdzić liniowo, jednoprzebiegowo 
(czy każdy call uwzględnia błędy) - i to wystarczy do pewności,
że obsługę błędów przewidziano w stu procentach. W drugim przypadku 
konieczne jest błądzenie po całym kodzie i analiza wszystkim możliwych 
tras i przeplotów wywołań. Czas rzetelnego sprawdzenia poleciałby
w kosmos, więc w rzeczywistości robi się to na oko zostawiając dziury.

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

Jak ktoś się uprze, to zawsze może napisać program nieczytelnie
(ale to widać i można poprawić). W przypadku wyjątków nieczytelność 
rozwiązania jest nieodłączną cechą ich głównej zalety, jaką jest 
możliwość przeniesienia obsługi błędu poza miejsce wystąpienia. 

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

No sorry, ale to nie spełnia wymogów naukowego eksperymentu.
Chociażby nie ma mowy o podwójnie ślepej próbie.

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

To nie jest nawet poprawnie zdefiniowane, nie wspominając 
w ogóle o falsyfikowalności. Można sobie policzyć jakieś 
korelacje na nielosowej próbce algorytmów, i w zasadzie tyle.
Nie wiadomo jakich korelacji nie stwierdzono, bo ich nie badano.

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

Dlatego pisałem, że wyjątki w najlepszym przypadku dadzą taki sam 
efekt jak inne metody (po rezygnacji z ich kluczowego ficzeru 
przerzucenia obsługi błędów wzwyż), ale wtedy są zbędną konstrukcją.

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

Nie wiesz konkretnie które z wywołań zadeklarowanych blokowo 
do łapania/przerzucania wyjątków rzuca które z nich,
trudniej sprawdzić poprawność takiej obsługi błędów.

>>> 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 [...]
>
> Ale ten fragment kodu jest skądś dany

Normalnie palcem można pokazać, nie ma musu 
stosować na upartego metodę exceptionową w innej składni.

> albo zrobiłem  go sobie lokalnie (czyli tak jak catch / except) 
> albo przyszedł z zewnątrz (czyli lokalnei 
> nie wiem gdzie to dalej poleci).

Tylko że jak ktoś ma problem z tym, że w programowaniu używa się 
zmiennych, to lepiej niech zmieni profil. Przecież nie będziesz 
zarzucał instrukcji print, że nie wiesz co zostanie wydrukowane 
przez ,,print variableA''. Problem byłby dopiero gdyby bezparametrowy
secretprint drukował nieoczywistą wartość wyciągniętą gdzieś z szafy
(dla mnie tak wygląda perl i jego m@giczne #argumenty domy$lne).

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

No dobra, ale to kwestia używania zmiennych globalnych 
w ogóle, a nie szczególnego przypadku.

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

Nie tak samo, bo od razu wiem że błąd jest obsłużony, już w tym 
miejscu. Samo info o rzucaniu wyżej wyjątku mi jeszcze nie mówi,
czy jest zawsze sensownie złapany, czy ktoś walnął wielki catch
na wszystko żeby zapuścić daily build i w końcu odebrać dziecko
z przedszkola. Wiem że odbębnić zawsze się da, ale możliwość
otoczenia całego kawałka kodu klamrą catch-everything to ułatwia.

> kontynuacje zachęcają by je stworzyć, przekazać 
> gdzie są wymagane a następnie po cichu wyrzucić.

Jak na zachęcanie to strasznie dużo roboty na takie obejście. 
A sprawdza się je prosto i tylko raz - w definicji wołanej procedury
(sprawdzenie jej jest i tak nie do uniknięcia, więc ta sama robota).

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

Nie zgadzam się, po dopisku throws cośtam jeszcze nie wiadomo czy 
tak powinno być czy nie, i gdzie tkwi problem. W drugim przypadku 
wszystko co potrzebne do wypatrzenia partactwa jest na miejscu.

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

Taką bzdurę, że każdy błąd ma ten sam handler, to od razu widać.

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

Spawnowanie ~procesów~ i przesyłanie komunikatów jest też gdzie 
indziej bibliotecznie, tylko bez zapewnienia wszystkich
bajeranckich cech produkcyjnych erlangowego vm-u. Tychże pozbawiony
interpreter erlanga napisany samemu byłby już mocno taki sobie.

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

To co mpl nazywa metafunkcjami to przecież po prostu funkcje
wyższych rzędów - gdzie indziej nie robi się takiego rozróżnienia,
po prostu typ->typ jest równie dobrym typem jak struktura czy unia.

> W mpl pisze się programy piszące programy.

Hello world. 

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

Ja tam lubię sandboksy.

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

Chyba tego nie przemyślałeś na poziomie epistemologicznym,
niepoznawalność to jeszcze nie jest niezdefiniowanie 
(że już o kryteriach bycia prawdziwą wartością nie wspomnę).

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

Nie bardzo chwytam, masz na myśli zadania real-time?

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

Prawdę powiedziawszy nie wiem na ile poważnie piszesz o różnej sile 
języków turing-kompletnych. Z zastosowań interaktywnych masz przecież 
funkcyjnie napisany filesystem, serwery sieciowe czy windowmanager.


Piotr Sawicki

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

>>>> 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.
>
> No sorry, ale to nie spełnia wymogów naukowego eksperymentu.
> Chociażby nie ma mowy o podwójnie ślepej próbie.

Jak sobie wyobrażasz podwójnie ślepą próbę w tym kontekście?
Programiści, którzy nie wiedzą w jakim języku piszą?

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

Grzegorz Staniak powiada:

>>> 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.
>>
>> No sorry, ale to nie spełnia wymogów naukowego eksperymentu.
>> Chociażby nie ma mowy o podwójnie ślepej próbie.
>
> Jak sobie wyobrażasz podwójnie ślepą próbę w tym kontekście?

No przecież napisałem że nie ma mowy. W psychologii się chyba
robi jakieś wstawianie ściemy na temat celu eksperymentu, 
a prawdziwe wyniki zbiera mimochodem. Zauważ, że nie ma też
oślepienia w drugą stronę - eksperymenty fizyczne na cząstkach
w akceleratorze nie obędą się bez blindness boxu odcinającego 
bias obserwatora, a tu za pozory naukowości ma służyć ,,staranne 
sprawdzanie'' nie wiadomo jak zdefiniowanej liczby błędów.
Nie wiadomo też, czy takie wyniki są powtarzalne, czy w ogóle
były przeprowadzane innymi metodami i poddane metaanalizie.

> Programiści, którzy nie wiedzą w jakim języku piszą?

Tu akurat ponoć pisali w ~swoim~ języku, bo to nie bardzo da się 
oddzielić. Słusznie, ale potem wyniki można zinterpretować zupełnie 
inaczej. Tzn. to nie są naukowe fakty na temat języków, tylko np. 
najlepsi programiści wybierają język X i takiej szukają pracy, 
albo firmy zsyłają największych matołów do rzeźbienia w języku Y.


Piotr Sawicki

Piotr Sawicki wrote:
> Sebastian Kaliszewski powiada:
> 
>> 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(cont, 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)
>>
> 
> Tak to dziwacznie wymyśliłeś, żeby było kalką wyjątków.
> No i nadal nie wiem, gdzie jest ta niejawna globalna kontynuacja.

Nie piszę tu o globalnej kontynuacji. Przy globalnej byłoby jeszcze gorzej:

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

itd...
  err_cont nie wiadomo skąd pochodzi, bo nie jest parametrem

> 
>> 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
> 
> VS np.
> 
> def z_bledem(a,b, contA, contB):
>   if not a: continue to contA()
>   elif not b: continue to contB()
> 
> def wolanie():
>   for i in range(10):
>     z_bledem(true/false, true/false, errorAhandler, errorBhandler)


Zapisz cały odpowiadający kod a nie kawałek. skąd pochodzą errorAhandler 
i errorBhandler? Przecież nie z powietrza?


>>>> 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ż*.
> 
> Kilka postingów temu postawiłeś tezę, że używanie kontynuacji 
> nie ma sensu w językach typowanych dynamicznie.

Nie prawda. Nie postawiłem takiej tezy.

Postawiłem tezę, że w językach dynamicznych w których wszelkie 
podstawowe konstrukcje (wykonanie warunkowe, powtarzanie) są 
zaimplementowane bez opierania się o kontynuacje, kontynuacje nie mają 
sensu do obsługi sytuacji wyjątkowych.

> Jeśli teraz 
> doprecyzowujesz, że tylko w tych z nich, w których kontynuacje 
> nie są częścią języka,

Wcale tak nie doprecyzowuję. Czytasz to co chcesz przeczytać a nie to co 
jest napisane. Piszę, że mają sens jeśli są częścią języka niezbędną dla 
zaimplementowania w nim konstrukcji podstawowych takich jak wykonanie 
warunkowe.

> to wychodzi banalna tautologia
> (i nie wiadomo po co w to w ogóle mieszać dynamizm).

Wychodzi tylko z tego co Ty chciałeś przeczytać a nie z tego co było 
napisane.

> 
>>> To czy wszystkie (kwantyfikatorowo) to bez znajomości: errcode<>success.
>> Tyle samo mi daje catch(...) -- w obu wypadkach niewiele.
> 
> Da, jeśli obstawimy nim każde wołanie. No to po co w ogóle wyjątki.

Mowa o wiedzy czy coś wypadło z błędem. catch(...) daje równie dobrą 
(raczej równie nędzną) wiedzę. Nie widzę specjalnego sensu rozwarzania 
przypadków zdegenerowanych.

>>>>> 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ć 
> 
> Jeśli podasz za mało argumentów do funkcji (tzn. pominiesz którąś 
> z wyjątkowych kontynuacji), to da się to wyłapać statycznie, 
> a błąd wykonania pojawi się nawet w prawidłowym przypadku.

Praktycznie to samo masz ze specyfikacjami wyjątków z głupiej Javy. Nie 
skompiluje się, jeśli nie ma statycznie zapewnionej (a raczej 
zamarkowanej) obsługi wszystkich błędów.

> 
>>> A z exceptionami hgw gdzie poleci, trzeba sprawdzać cały program.
>> I tak trzeba sprawdzać cały program. I tu i tu.
> 
> W jednym przypadku wystarczy sprawdzić liniowo, jednoprzebiegowo 
> (czy każdy call uwzględnia błędy) - i to wystarczy do pewności,
> że obsługę błędów przewidziano w stu procentach.

Po pierwsze nie wystarczy, co zostało pokazane wyżej. Można sprawdzić 
czy jest tylko (zamarkowana) intencja sprawdzenia błędu (tzn, czy jest 
podpięta jakakolwiek akcja, jakakolwiek to również zupełnie beznsesnowna 
lub w ogóle dziurawa. To samo dają zwykłe statyczne specyfikacje 
wyjątków rodem z Javy.

Po drugie zaś, to to taki kod niby porządny-kontynuacyjny, się fatalnie 
rozwija (do momentu kiedy nie ulegnie degeneracji). Każda zmiana 
dodająca w jednej głupiej funkcji wymaga dodania nowego parametru w 
każdym miejscu wołania i albo dodania go również do funkcji wołającej (i 
zabawę powtarzamy dla każdej funkcji wołającej w której tak zrobimy) 
albo w każdym z takich miejsc trzeba tworzyć nową kontynuację. Efekt 
dąży (degeneruje się) to analogu tego co się spotyka w kodzie Javowym -- 
globalnego catch.

> W drugim przypadku 
> konieczne jest błądzenie po całym kodzie i analiza wszystkim możliwych 
> tras i przeplotów wywołań. Czas rzetelnego sprawdzenia poleciałby
> w kosmos, więc w rzeczywistości robi się to na oko zostawiając dziury.

Jest tak samo jak ze statycznymi specyfikacjami wyjątków. Albo czas 
rzetelnego sprawdzenia leci w kosmos albo i tak jest na oko.

> 
>>> Ż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.
> 
> Jak ktoś się uprze, to zawsze może napisać program nieczytelnie
> (ale to widać i można poprawić). W przypadku wyjątków nieczytelność 
> rozwiązania jest nieodłączną cechą ich głównej zalety, jaką jest 
> możliwość przeniesienia obsługi błędu poza miejsce wystąpienia. 

Taka sama nieczytelność jest przy kontynuacjach. Lokalnie nie wiesz skąd 
kontynuację dostałeś. Tu tak samo masz "nieodłączną cechę ich głównej 
zalety, jaką jest możliwość przeniesienia obsługi błędu poza miejsce 
wystąpienia."


>>>> 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.
> 
> No sorry, ale to nie spełnia wymogów naukowego eksperymentu.

Bo?

> Chociażby nie ma mowy o podwójnie ślepej próbie.

LOL! Idź powiedz to jakiemukolwiek socjologowi :)

Podwójnie ślepa próba *nie jest* jedyną metodą naukowego eksperymentu.

Poza tym jak chcesz na powójnie ślepo testować języki?


>>> 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.
> 
> To nie jest nawet poprawnie zdefiniowane, nie wspominając 
> w ogóle o falsyfikowalności. Można sobie policzyć jakieś 
> korelacje na nielosowej próbce algorytmów, i w zasadzie tyle.
> Nie wiadomo jakich korelacji nie stwierdzono, bo ich nie badano.

Ach tak, ty nie czytałeś ale wiesz...


>>> 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.
> 
> Dlatego pisałem, że wyjątki w najlepszym przypadku dadzą taki sam 
> efekt jak inne metody (po rezygnacji z ich kluczowego ficzeru 
> przerzucenia obsługi błędów wzwyż), ale wtedy są zbędną konstrukcją.

Co ma to co tu napisałeś do tego co ja napisałem?

Poza tym, tak samo kluczowym ficzerem obsługi błędów przez kontynuację 
jest przerzucanie obsługi błędów wzwyż.

>>>> 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".
> 
> Nie wiesz konkretnie które z wywołań zadeklarowanych blokowo 
> do łapania/przerzucania wyjątków rzuca które z nich,

??? Podkręć jasność.

except WyjątekA łapie obiekty klasy WyjątekA a except WyjątekB łapie 
obikety klasy WyjątekB.

> trudniej sprawdzić poprawność takiej obsługi błędów.

Tzn?


>>>> 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 [...]
>> Ale ten fragment kodu jest skądś dany
> 
> Normalnie palcem można pokazać, nie ma musu 
> stosować na upartego metodę exceptionową w innej składni.

Co można palcem pokazać? To, że nawet przekażesz osobno kontynuację dla 
każdego rodzaju błędu (co samo w sobie w szybkim tempie prowadzi do 
zaciemnienia wywołań) to i tak albo utworzyłeś ją sobie w bloku z 
którego wołasz (czyli jest to samo co except czy C++owe catch tylko 
inaczej zapisane) albo dostałeś z zewnątrz (znów to samo co z wyjątkami).


>> albo zrobiłem  go sobie lokalnie (czyli tak jak catch / except) 
>> albo przyszedł z zewnątrz (czyli lokalnei 
>> nie wiem gdzie to dalej poleci).
> 
> Tylko że jak ktoś ma problem z tym, że w programowaniu używa się 
> zmiennych, to lepiej niech zmieni profil. Przecież nie będziesz 
> zarzucał instrukcji print, że nie wiesz co zostanie wydrukowane 
> przez ,,print variableA''. Problem byłby dopiero gdyby bezparametrowy
> secretprint drukował nieoczywistą wartość wyciągniętą gdzieś z szafy
> (dla mnie tak wygląda perl i jego m@giczne #argumenty domy$lne).

Zatem gdzie widzisz różnicę między napisaniem:

funkcja(x, y, z, on_a, on_b)

a funkcja(x, y, z) throws a, b


Pota oczywiście tym, że od razu widać że a, b to błędy powodowane przez 
funkcję a w on_a on_b trzeba szukać w dokumentacji (albo oprzeć się na 
obyczaju nazewniczym).


>> To nie jest kwestia spartaczenia kontynuacji tylko istnienia 
>> globalnych zmiennych. I (złego) nauczenia ludzi by ich 
>> (nad)używali do trzymania kontynuacji.
> 
> No dobra, ale to kwestia używania zmiennych globalnych 
> w ogóle, a nie szczególnego przypadku.

W tym przypadku "kultura języka" promowała takie rozwiązanie. Ale to już 
problem "kultury języka".


>>>> 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. 
> 
> Nie tak samo, bo od razu wiem że błąd jest obsłużony,

Jak?

> już w tym 
> miejscu. Samo info o rzucaniu wyżej wyjątku mi jeszcze nie mówi,
> czy jest zawsze sensownie złapany, czy ktoś walnął wielki catch
> na wszystko żeby zapuścić daily build i w końcu odebrać dziecko
> z przedszkola. Wiem że odbębnić zawsze się da, ale możliwość
> otoczenia całego kawałka kodu klamrą catch-everything to ułatwia.

W celu odbębnienia wystarczy raz sobie utworzyć kontynuację 
on_general_failure i sobie ją przekazać gdzie jej potrzeba.

W języku dynamicznym jest jeszcze gorzej, bo możesz zamiast kontynuacji 
przekazać jakikolwiek śmieć (choćby None) i statycznie nic nie wiesz. A 
jakiś tam parametr przekazany jako None nie wygląda od razu alarmująco.

M.in. dlatego piszę że obsługa błędów przez kontynuacje w językach 
dynamicznych ma sens mocno wątpliwy. I dlatego odpowiednio ograniczona 
(choć wystarczająca) forma kontynuacji jaką są wyjątki jest w takiej 
sytuacji lepsza, bo trudniej wszystko cwaniacko rozwalić. Podobnie ja 
programowanie strukturalne -- if, while, for z break i continue jest 
krokiem naprzód wobec łysego goto -- choć za pomocą goto daje się 
wyrzebić więcej niż za pomocą powyższych (które są formą ograniczenia 
goto i opakowania go w ramy).

>> kontynuacje zachęcają by je stworzyć, przekazać 
>> gdzie są wymagane a następnie po cichu wyrzucić.
> 
> Jak na zachęcanie to strasznie dużo roboty na takie obejście. 
> A sprawdza się je prosto i tylko raz - w definicji wołanej procedury
> (sprawdzenie jej jest i tak nie do uniknięcia, więc ta sama robota).

W językach dynamicznych sprawdzenie jest przy użyciu.

>> 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.
> 
> Nie zgadzam się, po dopisku throws cośtam jeszcze nie wiadomo czy 
> tak powinno być czy nie, i gdzie tkwi problem. W drugim przypadku 
> wszystko co potrzebne do wypatrzenia partactwa jest na miejscu.

No właśnie nie widzę tego na miejscu.

To, że w różnych rzadko używanych językach zwykle nie widzisz takiego 
kodu wynika moim zdaniem *tylko i wyłącznie* z faktu że są właśnie 
rzadko używane, a więc nie są używane przez przeciętną programistyczną 
małpę (małpy, zależnie od prowieniencji, swoją wiedzę kończą na (Visul) 
Basicu, Javie, PHP, Deplhi (oni nie znają Objective Pascala, oni znają 
Delphi), C lub Fortranie).

> 
>> otrzymana z zewnątrz kontynuacja tak samo będzie pasować 
>> do wszystkich razem.
> 
> Taką bzdurę, że każdy błąd ma ten sam handler, to od razu widać.

Tak samo jak brak catchy w kodzie tylko jeden w main.

Jestem praktycznie pewien, że gdyby Haskell zyskał popularność jak C++ 
(popularności Javy nie zyska po za trudny, porównujmy więc z językiem 
też trudnym) to takie kwiatki widywałoby się w kodzie haskellowym na 
każdym kroku.

> 
>>> 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ść.
> 
> Spawnowanie ~procesów~ i przesyłanie komunikatów jest też gdzie 
> indziej bibliotecznie, tylko bez zapewnienia wszystkich
> bajeranckich cech produkcyjnych erlangowego vm-u. Tychże pozbawiony
> interpreter erlanga napisany samemu byłby już mocno taki sobie.

I owszem i nikt by go nie użył. Ale conajmniej część tych cech 
produkcyjnych łapie się w semantykę. No i w ogóle częścią Erlanga są 
określone np. założenia wydajnościowe (choć można dyskutoweać czy to 
semantyka czy nie -- w każdym razie są języki gdzie np. specyfikuje się 
koszt asymptotyczny określonych operacji).
Podobnie określone założenia (choć zupełnie inne) są niejako częścią np. 
C (bliskość sprzętu, w wielu dziedzinach warunek konieczny).


>>> 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ą).
> 
> To co mpl nazywa metafunkcjami to przecież po prostu funkcje
> wyższych rzędów - gdzie indziej nie robi się takiego rozróżnienia,
> po prostu typ->typ jest równie dobrym typem jak struktura czy unia.

Nnno, pod warunkiem, że typ jest obiektem języka. Metafunkcje też tym 
się też wyróżniają, że są wykonywane w czasie kompilacji i semantyka 
języka to wymusza.


>> W mpl pisze się programy piszące programy.
> 
> Hello world. 

Generalnie tak, ale jak już pisałem, spotykam takich którzy w tym piszą 
zdecudowanie więcej. A przez samą liczbę piszących w C++ może się okazać 
że oni i tak stanowią większość metaprogramujących w ogóle.


>>>> 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 :)
> 
> Ja tam lubię sandboksy.

Dla mnie to to jest sandbox wywrócony na lewą stronę :)


>> 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.
> 
> Chyba tego nie przemyślałeś na poziomie epistemologicznym,
> niepoznawalność to jeszcze nie jest niezdefiniowanie 
> (że już o kryteriach bycia prawdziwą wartością nie wspomnę).

Niepoznawalność to oczywiście nie niezdefiniowanie. Ale tu wg mnie mamy 
właśnie niezdefiniowanie. Wartość niepoznawalna przede wszytskim jest i 
jest niezmienna. Można się nią normalnie posługiwać poza samym 
poznaniem. Świat (stan zewnętrzny) to nie jest wartość w normalnym 
rozumieniu tego słowa, jest np. jednorazowy (nie dziwne nie daje się 
cofnąć ani zatrzymać), itd...

Tzn. typ w którym reprezentuję niepoznawalną stałą Chatina jest dla mnie 
  jak najbardziej normalnym typem, jego wartości mogę przypisywać, 
przekazywać do wywołań, brać jako wyniki, itd. A tu guzik.

> 
>>>> 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.
> 
> Nie bardzo chwytam, masz na myśli zadania real-time?

Nie tylko, ale też. Ogólnie zadania w których pewne akcje zależą od 
wcześniej wykonanych, od wyników (i błędów) występujących wcześniej. W 
dodatku mogą też zależeć od pory dnia/tygodnia/miesiąca/roku. Ot, 
przeciętny program użytkowy typu Word się tu łapie.

> 
>>>> 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. 
> 
> Prawdę powiedziawszy nie wiem na ile poważnie piszesz o różnej sile 
> języków turing-kompletnych. Z zastosowań interaktywnych masz przecież 
> funkcyjnie napisany filesystem, serwery sieciowe czy windowmanager.

Pamiętaj, że maszyna Turinga to tylko model. Pewnych rzeczy nie modeluje 
i tyle -- po prostu go nie dotyczą. Funkcyjnie możesz zapisać stan 
wewnętrzny, ale ze stanem zewnętrznym (czas systemowy, zewnętrzne źródło 
danych losowych, etc.) jest gorzej. Albo zamiata się pod dywan tworząc 
pseudowartości których się nie daje traktować jak wartości i udaje że 
wszystko ok, albo po prostu przyznaje się jasno, że coś tam wykracza 
poza model i już. Wolę ten drugi wariant, wolę języki gdzie jest 
napisane: ten kawałek nie jest funkcyjny i już, używamy tak i tak. Ale 
to moja osobista, głównie estetyczna preferencja.

pzdr

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

Piotr Sawicki wrote:
> Grzegorz Staniak powiada:
> 
>>>> 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.
>>> No sorry, ale to nie spełnia wymogów naukowego eksperymentu.
>>> Chociażby nie ma mowy o podwójnie ślepej próbie.
>> Jak sobie wyobrażasz podwójnie ślepą próbę w tym kontekście?
> 
> No przecież napisałem że nie ma mowy.

Co absolutnie nie wpływa na "naukowość". Ślepa próba jest tylko jedną z 
metod (tu nie mającą żadnego sensu).

BTW. naukowe to jest wtedy kiedy zostało opublikowane jako publikacja 
naukowa z podlegająca recenzji. Kropka.

> W psychologii się chyba
> robi jakieś wstawianie ściemy na temat celu eksperymentu, 
> a prawdziwe wyniki zbiera mimochodem.
> Zauważ, że nie ma też oślepienia w drugą stronę - eksperymenty fizyczne
 > na cząstkach w akceleratorze nie obędą się bez blindness boxu 
odcinającego
> bias obserwatora, a tu za pozory naukowości ma służyć ,,staranne 
> sprawdzanie'' nie wiadomo jak zdefiniowanej liczby błędów.

Nie wiesz co to jest błąd?
Liczba owych błędów w pojedynczym programie jest również dobrze określona.

AFAIR udostęponio również napisane w ramach eksperymentu programy, każdy 
mógł sobie sprawdzić czy błędy policzono poprawnie.

> Nie wiadomo też, czy takie wyniki są powtarzalne, czy w ogóle
> były przeprowadzane innymi metodami i poddane metaanalizie.

Eksperyment przeprowadzono dwoma metodami, wynik wyszedł tak samo.

>> Programiści, którzy nie wiedzą w jakim języku piszą?
> 
> Tu akurat ponoć pisali w ~swoim~ języku, bo to nie bardzo da się 
> oddzielić. Słusznie, ale potem wyniki można zinterpretować zupełnie 
> inaczej. Tzn. to nie są naukowe fakty na temat języków, tylko np. 
> najlepsi programiści wybierają język X i takiej szukają pracy, 
> albo firmy zsyłają największych matołów do rzeźbienia w języku Y.

Bardzo "ciekawe" wnioski "wyciągasz" w ogóle nie znając tych badań. 
Jedno jest pewne, te wnioski są "zupełnie nie naukowe" :)

Nie chcesz - nie wierz, to Twój nie mój problem.

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

Sebastian Kaliszewski powiada:

[ciach zmienne globalne - nie używać i tyle]

> Zapisz cały odpowiadający kod a nie kawałek. skąd pochodzą 
> errorAhandler i errorBhandler? Przecież nie z powietrza?

Nazwy procedur. Nie muszą być albo-albo (argumentowane z góry
albo lokalnie zdefiniowane w tym miejscu) tak samo jak wyjątki.
Można np. użyć biblioteki do obsługi błędów.

>> Kilka postingów temu postawiłeś tezę, że używanie kontynuacji 
>> nie ma sensu w językach typowanych dynamicznie.
>
> Nie prawda. Nie postawiłem takiej tezy.

OK, po prostu wyczytałem to z ,,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 wdynamicznie typowanych.'' 
i stąd polemika - ale skoro doprecyzowujesz to no problemo.

> w językach dynamicznych w których wszelkie podstawowe 
> konstrukcje (wykonanie warunkowe, powtarzanie) są 
> zaimplementowane bez opierania się o kontynuacje, 
> kontynuacje nie mają sensu do obsługi sytuacji wyjątkowych.

Ja widzę taką korzyść: funkcje to podstawowa cegiełka programowania,
z którą można prosto i łatwo zrobić mnóstwo rzeczy gotowymi narzędziami 
(dowolnie je przekazywać, komponować, transformować, agregować, wrzucać
w mapę itd) - choćby wspominanymi przez ciebie metafunkcjami. 
Z tym samym blokiem kodu, ale wrzuconym w specjalną statyczną 
składnię tylko-dla-wyjątków da się bez zamotanego mambodżambo już 
zrobić bardzo niewiele (pominąć albo skleić tylko w jednej możliwej 
kolejności). Dla mnie to jak różnica między programem posługującym
się na stdin i stdout czytelnym formatem tekstowym możliwym do 
obróbki narzędziami shellowymi, a takim który dłubie w pliku z blobem
binarnym, z którym da się zrobić tylko to co z góry przewidziano. 

> Mowa o wiedzy czy coś wypadło z błędem. 

Nie, ja piszę o innym aspekcie - wiedzy czy w danym fragmencie
kodu przewidziano obsługę wszystkich potencjalnych błędów.

> Praktycznie to samo masz ze specyfikacjami wyjątków z głupiej Javy. 
> Nie skompiluje się, jeśli nie ma statycznie zapewnionej (a raczej 
> zamarkowanej) obsługi wszystkich błędów.

Kompilator sprawdzi tylko poprawność formalną.

> kod niby porządny-kontynuacyjny się fatalnie rozwija 
> (do momentu kiedy nie ulegnie degeneracji). Każda zmiana 
> dodająca w jednej głupiej funkcji wymaga dodania nowego 
> parametru w każdym miejscu wołania 

W razie zmiany interfejsu, a nie implementacji. No i bardzo dobrze, 
po takiej zmianie naprawdę trzeba skorygować wszystkie przypadki
użycia - przynajmniej widać czarno na białym, które już poprawiono 
a które jeszcze nie. Jeśli zmienił się kontrakt, a stare wywołania 
są nieodróżnialne od nowych to dopiero jest problem logistyczny 
z przeprowadzeniem całości kodu do nowej wersji.

> Jest tak samo jak ze statycznymi specyfikacjami wyjątków. Albo czas 
> rzetelnego sprawdzenia leci w kosmos albo i tak jest na oko.

Tu jest różnica z brakiem jawnej specyfikacji czegokolwiek
- pewien rodzaj enkapsulacji, uniezależniający od siebie poprawność
odrębnych kawałków programu. Dzięki temu czas sprawdzania właśnie
nie rośnie wykładniczo, bo można to zrobić dla każdej funkcji 
oddzielnie. Więc doceniam wrzucanie wyjątków w sygnaturę (ale to 
jest tylko w javie AFAIK), tylko nie wiem po co wprowadzać wtórny
system [quasi]typów dla argumentów ukrytych składniowo (wyjątków).

> kluczowym ficzerem obsługi błędów przez kontynuację 
> jest przerzucanie obsługi błędów wzwyż.

Mam wrażenie (na podstawie przykładowego kodu), że masz zafiksowany 
w głowie sposób obsługi błędów poprzez wyjątki i każdą alternatywną 
metodę wyobrażasz sobie przez takie jej naginanie żeby innymi środkami 
programować nadal na modłę wyjątków. Nie jest kluczowym ficzerem, 
bo tak się da ale to jednak niekonieczne, można też zupełnie inaczej.

>> Nie wiesz konkretnie które z wywołań zadeklarowanych blokowo 
>> do łapania/przerzucania wyjątków rzuca które z nich,
>
> ??? Podkręć jasność.
>
> except WyjątekA łapie obiekty klasy WyjątekA 
> a except WyjątekB łapie obikety klasy WyjątekB.

Nie wiadomo z którego calla ten wyjątek wyleciał, nie zawsze
wynika to z klasy wyjątku. Przy czym nie chodzi mi o moment łapania 
błędu w runtimie, tylko o czytelność przy uprzednim go sprawdzaniu.

> Zatem gdzie widzisz różnicę między napisaniem:
>
> funkcja(x, y, z, on_a, on_b)
>
> a funkcja(x, y, z) throws a, b

W tym że jedno wywołanie wygląda funkcja(x,y,z,on_a,on_b), a drugie 
funkcja(x,y,z) - chyba oczywiste. W pierwszym wypadku czytając 
takie wywołanie od razu wiem że obsługę błędów przewidziano. 
I ona oczywiście może być niepoprawna, ale to kwestia sprawdzenia 
tamtego kodu, tu na razie jest ok. W drugim nie mogę odfajkować
poprawności właśnie oglądanego kodu dopóki nie sprawdzę w wielu
innych miejscach - w szczególności punktach wołających aktualny
kawałek kodu. Które w trakcie rozwoju programu mogą się jeszcze
pojawiać albo zmieniać, więc tak czy siak zostawiam tykającą bombę. 

>>> Tak samo jest z kontynuacjami. 
>> 
>> Nie tak samo, bo od razu wiem że błąd jest obsłużony,
>
> Jak?

Tak że podano kontynuację dla wyjątkowego przypadku (i jeśli jest 
to onGeneralFailure albo None to od razu to widzę). Z wyjątkami
mogę to wiedzieć na podstawie tego, że wpisano łapanie wyjątku.
Ale. To jest zupełnie gdzie indziej w kodzie. W wielu miejscach.

[wpisywanie śmieci]
> I dlatego odpowiednio ograniczona (choć wystarczająca) 
> forma kontynuacji jaką są wyjątki jest w takiej 
> sytuacji lepsza, bo trudniej wszystko cwaniacko rozwalić. 

Na tej zasadzie to równie dobrze można dla każdego catcha wpisać 
pass. Przecież pisałem od początku o QA, a nie magicznym wzroście 
poprawności jednoosobowo pisanego programu dzięki używaniu silverbullet.
Tak naprawdę to największym zagrożeniem nie jest to, że programista
przewidzi wszystkie błędy i do ich obsługi perfidnie wpisze śmieci.
Tylko że normalny programista z definicji (niezależnej od znajomości
języków programowania) uważa że wszystko pójdzie dobrze, i koncentruje
się na przebiegu algorytmu w poprawnych sytuacjach. A przetykanie kodu 
możliwościami niepowodzeń na każdym kroku jest dla niego upierdliwe.

>> Jak na zachęcanie to strasznie dużo roboty na takie obejście. 
>> A sprawdza się je prosto i tylko raz - w definicji wołanej procedury
>> (sprawdzenie jej jest i tak nie do uniknięcia, więc ta sama robota).
>
> W językach dynamicznych sprawdzenie jest przy użyciu.

Nie piszę o działaniu programu, tylko czytelności.

>> po dopisku throws cośtam jeszcze nie wiadomo czy 
>> tak powinno być czy nie, i gdzie tkwi problem. W drugim przypadku 
>> wszystko co potrzebne do wypatrzenia partactwa jest na miejscu.
>
> No właśnie nie widzę tego na miejscu.

call funkcja(x,y,z, None, onGeneralFailure) //- ja widzę jak na dłoni.

> To, że w różnych rzadko używanych językach zwykle nie widzisz takiego 
> kodu wynika moim zdaniem *tylko i wyłącznie* z faktu że są właśnie 
> rzadko używane, a więc nie są używane przez przeciętną programistyczną 

Kiedy właśnie o to chodzi że widzę. Błędy są zawsze, tylko w języku
czytelnym je o wiele łatwiej dostrzec niż w kryptycznym. A jeszcze 
trudniej z przeoczeniami. Rzeczy opisywane jawnie przy czytaniu widać, 
niejawnych trzeba się domyślać i robić reverse-enginnering.

-----

> conajmniej część tych cech produkcyjnych łapie się w semantykę. 
> No i w ogóle częścią Erlanga są określone np. założenia wydajnościowe 
> (choć można dyskutoweać czy to semantyka czy nie -- w każdym razie 
> są języki gdzie np. specyfikuje się koszt asymptotyczny określonych 
> operacji). 

Dla mnie to raczej kwestia implementacyjna - ale skoro się
zgadzamy co do meritum to nie ma sensu spór o nazewnictwo.

>>>> Zamyka efekty uboczne w piaskownicy, niezły wynik.
[...]
> Dla mnie to to jest sandbox wywrócony na lewą stronę :)

Na prawą: możesz narobić efektów ubocznych, ale tylko wewnątrz
monady, bez zaśmiecenia nimi całego środowiska.

> Wartość niepoznawalna przede wszytskim jest i jest niezmienna. 
> Można się nią normalnie posługiwać poza samym poznaniem. 

Zmienność się modeluje funkcjami.

> Świat (stan zewnętrzny) to nie jest wartość w normalnym 
> rozumieniu tego słowa, jest np. jednorazowy (nie dziwne nie daje się 
> cofnąć ani zatrzymać), itd...

Bo masz rozumienie wartości z ubogich języków. Wartością pierwszego
rzędu może być nie tylko stała, ale również bez problemu funkcja 
(nawet z funkcji w funkcje) - więc świat może być np. ciągiem 
statycznych stopklatek, a ciąg już się bardzo ładnie modeluje.

> Tzn. typ w którym reprezentuję niepoznawalną stałą Chatina jest dla mnie 
> jak najbardziej normalnym typem, jego wartości mogę przypisywać, 
> przekazywać do wywołań, brać jako wyniki, itd. A tu guzik.

Też możesz, od tego m.in. są monady stanowe. Nawet w zapisie
to wygląda podobnie jak używanie zmiennych w komputacji imperatywnej.

> Ogólnie zadania w których pewne akcje zależą od wcześniej 
> wykonanych, od wyników (i błędów) występujących wcześniej. 

No to niech zależą, funkcjami się opisuje właśnie zależności
- wystarczy je wpisać w parametr funkcji. Naprawdę takich nie
widziałeś, np. szkolnego przykładu generatorów kolejnych liczb 
pierwszych, zależnie od tego jaka była ostatnia policzona? 

> Funkcyjnie możesz zapisać stan wewnętrzny, ale ze stanem zewnętrznym 
> (czas systemowy, zewnętrzne źródło danych losowych, etc.) jest gorzej. 
> Albo zamiata się pod dywan tworząc pseudowartości których się nie daje 
> traktować jak wartości i udaje że wszystko ok, 

To jest wewnętrznie sprzeczne - właśnie się da tak traktować, i dlatego
marudzisz że to udawanie, bo jednak działa. Wymyśliłeś jakąś ezoteryczną
kategorię pseudowartości (?), ale tam nie ma żadnego zaszytego w środku
kompilatora hacku - to jest w bibliotece, zamodelowane normalnymi 
mechanizmami języka, dało się zrobić jak wszystkie inne funkcje.


Piotr Sawicki

Sebastian Kaliszewski powiada: [skleiłem]
 
>>>>> 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.
>>>> No sorry, ale to nie spełnia wymogów naukowego eksperymentu.
> Bo?

Bo zawiera błędy metodologiczne, jak observer bias. To naprawdę
nie jest urojony problem - wychodzi nawet przy twardych ściślackich
eksperymentach z fizyki. Np. chcąc potwierdzić wyrozumowaną regułę
zachowania powłok elektronowych przez zgodność danych obserwacyjnych
z liczbami przewidzianymi wzorem, eksperymentatorzy tak starannie
zliczali rozbłyski w komorze scyntylacyjnej, że sprawdziło im się
kompletnie fałszywe (jak się później okazało dzięki odpowiedniej
metodologii) prawo fizyki. Poleciłbym książkę A.K. Wróblewskiego
o historii nauki, ale wykłady (wolnodostępne) są lepsze.

>>>> Chociażby nie ma mowy o podwójnie ślepej próbie.
>LOL! Idź powiedz to jakiemukolwiek socjologowi :)

Każdy socjolog zna problem styku ankietera z ankietowanym, np. 
eksperyment wykazujący, że wynik zwykłego testu czy dla badanych
lepszy smak ma coca-cola czy pepsi zależy od gustu badacza.

>>> Jak sobie wyobrażasz podwójnie ślepą próbę w tym kontekście?
>> 
>> No przecież napisałem że nie ma mowy.
>
> Co absolutnie nie wpływa na "naukowość". Ślepa próba 
> jest tylko jedną z metod (tu nie mającą żadnego sensu).

Próba nieślepa nie jest alternatywą dającą równie uprawnione wnioski.

> BTW. naukowe to jest wtedy kiedy zostało opublikowane jako 
> publikacja naukowa z podlegająca recenzji. Kropka.

Piękna teoria, ale nauka jest teraz tak poszufladkowana, 
że za trudno już o niezależnego recenzenta z dokładnie tej
samej dziedziny - nawet było kilka afer z opublikowaniem
w renomowanych czasopismach zupełnych bzdur (nawet artykuł
wygenerowany losowo ze słownika domenowej terminologii)
bez realnej weryfikacji. Uczestnictwo w dyskursie naukowym
opiera się na zgodzie na nieustanne podleganie krytyce, 
sprawdzaniu wyników czy reinterpretacji, ogólnie: obalalności.
A nie uzyskaniu imprimatur od namaszczonych autorytetów. 
 
>> nie wiadomo jak zdefiniowanej liczby błędów.
>
> Nie wiesz co to jest błąd?

Nie znam jakiejś jedynie słusznej ścisłej definicji. Są różne
rodzaje błędów różnej skali, o odmiennych konsekwencjach, diametralnie
innym czasie znajdywania czy poprawiania itd. Plus cała szara strefa
między już błędem a jeszcze tylko złą praktyką programistyczną,
której się nie powinno stosować bo albo do błędu w końcu doprowadzi 
albo np. znacznie podroży koszt dalszego rozwoju aplikacji.

> Liczba owych błędów w pojedynczym programie jest również dobrze określona.

W ogóle nie jest określona, dopóki się nie zdefiniuje sposobu ich liczenia.

>> Nie wiadomo też, czy takie wyniki są powtarzalne, czy w ogóle
>> były przeprowadzane innymi metodami i poddane metaanalizie.
>
> Eksperyment przeprowadzono dwoma metodami, wynik wyszedł tak samo.

To napisz albo podaj linka.

>>> Hipotezą było, że są języki mniej i bardziej błędogenne.
>> To nie jest nawet poprawnie zdefiniowane, nie wspominając
>> w ogóle o falsyfikowalności. Można sobie policzyć jakieś
>> korelacje na nielosowej próbce algorytmów, i w zasadzie tyle.
>> Nie wiadomo jakich korelacji nie stwierdzono, bo ich nie badano.
>
> Ach tak, ty nie czytałeś ale wiesz...

Wiem co napisałeś. Od siebie dodaję tylko założenie, że rzetelnie 
zrelacjonowałeś te badania. Oraz wiem, że jeśli jakiejś hipotezy
nie postawiono, to i jej nie obalono, to akurat stwierdzenie ogólne.

> Bardzo "ciekawe" wnioski "wyciągasz" w ogóle nie znając tych badań. 
> Jedno jest pewne, te wnioski są "zupełnie nie naukowe" :)

Właśnie są to równie dobre interpretacje tej samej korelacji
(która przecież nie jest zależnością przyczynowo-skutkową).

> Nie chcesz - nie wierz, to Twój nie mój problem.

No właśnie problem w tym, że trzeba to przyjąć na wiarę, bo nie
widać dowodu z prawdziwego zdarzenia. Więc wybacz, ale dygresję
o tym eksperymencie potraktuję jako anegdotkę a nie twardy argument
w dyskusji o przyczynach powstawania błędów w oprogramowaniu.


Piotr Sawicki

Piotr Sawicki wrote:
>> Zapisz cały odpowiadający kod a nie kawałek. skąd pochodzą 
>> errorAhandler i errorBhandler? Przecież nie z powietrza?
> 
> Nazwy procedur.

Czyżby. Jak chcesz kontynuować do li tylko nazwanej procedury bez 
podania jej gdzie dla odmiany ona ma kontynuować. Gdzieś w końcu te 
kontynuacje tworzysz -- więc to pokaż, przynjamniej dla tej jednej, 
którą w przykłądzie z wyjątkami załatwiam lokalnie.

> Nie muszą być albo-albo (argumentowane z góry
> albo lokalnie zdefiniowane w tym miejscu) tak samo jak wyjątki.
> Można np. użyć biblioteki do obsługi błędów.

Ale ta biblioteka musi wiedzieć gdzie kontynuować, albo błąd oznacza 
koniec programu.

W podanym przeze mnie przykładzie jeden błąd jest obsługiwany lokalnie 
(w wolanie) po czym program jest kontynuowany, zatem i w przykładzie 
kontynuacyjnym oczekuję, że będzie jego obsługa pokazana (wraz z 
kontynuowaniem działania programu).


[...]
>> w językach dynamicznych w których wszelkie podstawowe 
>> konstrukcje (wykonanie warunkowe, powtarzanie) są 
>> zaimplementowane bez opierania się o kontynuacje, 
>> kontynuacje nie mają sensu do obsługi sytuacji wyjątkowych.
> 
> Ja widzę taką korzyść: funkcje to podstawowa cegiełka programowania,
> z którą można prosto i łatwo zrobić mnóstwo rzeczy gotowymi narzędziami 
> (dowolnie je przekazywać, komponować, transformować, agregować, wrzucać
> w mapę itd) - choćby wspominanymi przez ciebie metafunkcjami. 
> Z tym samym blokiem kodu, ale wrzuconym w specjalną statyczną 
> składnię tylko-dla-wyjątków da się bez zamotanego mambodżambo już 
> zrobić bardzo niewiele (pominąć albo skleić tylko w jednej możliwej 
> kolejności). Dla mnie to jak różnica między programem posługującym
> się na stdin i stdout czytelnym formatem tekstowym możliwym do 
> obróbki narzędziami shellowymi, a takim który dłubie w pliku z blobem
> binarnym, z którym da się zrobić tylko to co z góry przewidziano. 

Ale kontynuacje to nie są takie zupełnie zwykłe funkcje -- to w końcu 
forma goto -- można je także określić jako metodę dynamicznego składania 
funkcji.


[...]
>> Praktycznie to samo masz ze specyfikacjami wyjątków z głupiej Javy. 
>> Nie skompiluje się, jeśli nie ma statycznie zapewnionej (a raczej 
>> zamarkowanej) obsługi wszystkich błędów.
> 
> Kompilator sprawdzi tylko poprawność formalną.
> 
>> kod niby porządny-kontynuacyjny się fatalnie rozwija 
>> (do momentu kiedy nie ulegnie degeneracji). Każda zmiana 
>> dodająca w jednej głupiej funkcji wymaga dodania nowego 
>> parametru w każdym miejscu wołania 
> 
> W razie zmiany interfejsu, a nie implementacji.

Problem taki, że zmiana implementacji zbyt często wymusza zmianę interfejsu.

> No i bardzo dobrze, 
> po takiej zmianie naprawdę trzeba skorygować wszystkie przypadki
> użycia - przynajmniej widać czarno na białym, które już poprawiono 
> a które jeszcze nie. Jeśli zmienił się kontrakt, a stare wywołania 
> są nieodróżnialne od nowych to dopiero jest problem logistyczny 
> z przeprowadzeniem całości kodu do nowej wersji.

Problem taki, że kontrakt z punktu widzenia klasycznej poprawności 
aplikacji się nie zmienił. Zmieniły się "peryferia".

> 
>> Jest tak samo jak ze statycznymi specyfikacjami wyjątków. Albo czas 
>> rzetelnego sprawdzenia leci w kosmos albo i tak jest na oko.
> 
> Tu jest różnica z brakiem jawnej specyfikacji czegokolwiek
> - pewien rodzaj enkapsulacji, uniezależniający od siebie poprawność
> odrębnych kawałków programu.

No właśnie on uzależnia. I to często niepotrzebnie.

> Dzięki temu czas sprawdzania właśnie
> nie rośnie wykładniczo, bo można to zrobić dla każdej funkcji 
> oddzielnie. Więc doceniam wrzucanie wyjątków w sygnaturę (ale to 
> jest tylko w javie AFAIK),

Jest nie tylko w Javie. Ale w Javie to jeden z bardziej krytykowanych 
ficzerów -- okazał się bardziej "plątać pod nogami" zamiast pomagać.

Powód jest prosty -- w typowym przypadku, wystarczająca obsługa 
większości błędów to jeden catch / except gdzieś blisko korzenia 
hierarchii wywołań. Tylko niektóre błędy wymagają bardziej 
specjalizowanej obsługi. W dodatku ta konieczność specjalnej (a nie 
ogólne) obsługi jest wcale często oczywista.

Inną inkarnacją tego samego metasporu jest dyskusja o tym czy GC jest 
dobre czy złe -- przeciwnicy GC twierdzą, że kiedy mają synchroniczne 
zwolnienie zasobów i destruktor (czyli jak w Adzie czy C++) to nie ma 
problemu np. z automatycznym zamknięciem pliku. Zapominają tylko o tym, 
że 95% zwalnianych zasobów to pamięć, która zwykle jest wystarczająco 
liczna by nie potrzebować jej zwolnienia natychmiast po zaprzestaniu 
używania. I zapominają że destruktory tylko plączą się w tych 95% 
przypadków. I że lepiej te 5% przypadków rozwiązać inaczej (choćby 
Pythonowe with, using z C#, różne rozwiązanie "beansowe" z Javy, itd).

Podobnie argument o konieczności jawnej obsługi każdego błędu ignoruje 
fakt, że zdecydowaną większość błędów można obsłużyć ogólnie. Ba, 
nietóre nawet należy (poza wyjątkowymi przypadkami typu odpalanie 
podaplikacji w sandboksie), np. wyjątgki informujące o błędach w 
programie, brak możliwości kontynuacji z powodu braku niezbędnych i 
najbardziej podstawowych zasobów (out of stack, out of memory, out of time).

> tylko nie wiem po co wprowadzać wtórny
> system [quasi]typów dla argumentów ukrytych składniowo (wyjątków).
> 
>> kluczowym ficzerem obsługi błędów przez kontynuację 
>> jest przerzucanie obsługi błędów wzwyż.
> 
> Mam wrażenie (na podstawie przykładowego kodu), że masz zafiksowany 
> w głowie sposób obsługi błędów poprzez wyjątki i każdą alternatywną 
> metodę wyobrażasz sobie przez takie jej naginanie żeby innymi środkami 
> programować nadal na modłę wyjątków. Nie jest kluczowym ficzerem, 
> bo tak się da ale to jednak niekonieczne, można też zupełnie inaczej.

Błąd albo możesz obsłużyć lokalnie albo "podać dalej" (obsługa "wyżej" 
lub inaczej mówiąc "na zewnątrz"). Obsługa na zewnątrz może być jeszcze 
podzielona na bez powrotu (kończącą program -- wszelkie funkcje znane z 
różnych języków typu sys.exit, abort, terminate) i powracającą do programu.

Nie ma to nic wspólnego z zafiksowaniem czy niezafiksowaniem w głowie 
sposobu obsługi błędów.

> 
>>> Nie wiesz konkretnie które z wywołań zadeklarowanych blokowo 
>>> do łapania/przerzucania wyjątków rzuca które z nich,
>> ??? Podkręć jasność.
>>
>> except WyjątekA łapie obiekty klasy WyjątekA 
>> a except WyjątekB łapie obikety klasy WyjątekB.
> 
> Nie wiadomo z którego calla ten wyjątek wyleciał, nie zawsze
> wynika to z klasy wyjątku. Przy czym nie chodzi mi o moment łapania 
> błędu w runtimie, tylko o czytelność przy uprzednim go sprawdzaniu.

Ale ta wiedza albo jest niepotrzebna (mógł wylecieć z dowolnego, bez 
znaczenia) albo jest potrzebna łączenie z weryfikacją semantyki obsługi 
tego błędu oraz semantyki zawołanej funkcji. Ale jeśli znasz semantykę 
to wiesz czy błąd może polecieć -- i kółko się zamyka.

> 
>> Zatem gdzie widzisz różnicę między napisaniem:
>>
>> funkcja(x, y, z, on_a, on_b)
>>
>> a funkcja(x, y, z) throws a, b
> 
> W tym że jedno wywołanie wygląda funkcja(x,y,z,on_a,on_b), a drugie 
> funkcja(x,y,z) - chyba oczywiste. W pierwszym wypadku czytając 
> takie wywołanie od razu wiem że obsługę błędów przewidziano. 
> I ona oczywiście może być niepoprawna, ale to kwestia sprawdzenia 
> tamtego kodu, tu na razie jest ok. W drugim nie mogę odfajkować
> poprawności właśnie oglądanego kodu dopóki nie sprawdzę w wielu
> innych miejscach - w szczególności punktach wołających aktualny
> kawałek kodu.

Nie. W obu wypadkach lokalnie nie wiesz nic o kodzie wołającym. Nie 
wiesz też o jego poprawności.

> Które w trakcie rozwoju programu mogą się jeszcze
> pojawiać albo zmieniać, więc tak czy siak zostawiam tykającą bombę. 

Zatem zostawiasz ją (skoro uważasz, że zowstawiasz) i tu i tu.


>>>> Tak samo jest z kontynuacjami. 
>>> Nie tak samo, bo od razu wiem że błąd jest obsłużony,
>> Jak?
> 
> Tak że podano kontynuację dla wyjątkowego przypadku (i jeśli jest 
> to onGeneralFailure albo None to od razu to widzę).


Parametr None w wywołaniu rzadko wygląda podejrzanie.


Choć np wywołanie
  funkcja(13, "ala ma kota", None, on_unable)
jest złe a
  funkcja(None, "kot nie ma ali", on_io_fail, on_impossible)
dobre - to oba wywołnia rozpatrywane osobno (widziane w różnych 
fragmentach kodu) wyglądają same w sobie dobrze.


> Z wyjątkami
> mogę to wiedzieć na podstawie tego, że wpisano łapanie wyjątku.
> Ale. To jest zupełnie gdzie indziej w kodzie. W wielu miejscach.

Jeśli masz specyfikacje wyjątków to nie zupełnie gdzie indziej tylko w 
najbliższej okolicy.

> [wpisywanie śmieci]
>> I dlatego odpowiednio ograniczona (choć wystarczająca) 
>> forma kontynuacji jaką są wyjątki jest w takiej 
>> sytuacji lepsza, bo trudniej wszystko cwaniacko rozwalić. 
> 
> Na tej zasadzie to równie dobrze można dla każdego catcha wpisać 
> pass. Przecież pisałem od początku o QA, a nie magicznym wzroście 
> poprawności jednoosobowo pisanego programu dzięki używaniu silverbullet.
> Tak naprawdę to największym zagrożeniem nie jest to, że programista
> przewidzi wszystkie błędy i do ich obsługi perfidnie wpisze śmieci.
> Tylko że normalny programista z definicji (niezależnej od znajomości
> języków programowania) uważa że wszystko pójdzie dobrze, i koncentruje
> się na przebiegu algorytmu w poprawnych sytuacjach. A przetykanie kodu 
> możliwościami niepowodzeń na każdym kroku jest dla niego upierdliwe.

No właśnie. I nie tylko upierdliwe ale zaciemnia kod (jest upierdliwe w 
czytaniu). A jak Wielcy Ojcowie Pythona ;) zauważyli kod się przede 
wszystkim czyta. Dlatego  wychodzi na to że wyjątki są dobre.


>>> Jak na zachęcanie to strasznie dużo roboty na takie obejście. 
>>> A sprawdza się je prosto i tylko raz - w definicji wołanej procedury
>>> (sprawdzenie jej jest i tak nie do uniknięcia, więc ta sama robota).
>> W językach dynamicznych sprawdzenie jest przy użyciu.
> 
> Nie piszę o działaniu programu, tylko czytelności.
> 
>>> po dopisku throws cośtam jeszcze nie wiadomo czy 
>>> tak powinno być czy nie, i gdzie tkwi problem. W drugim przypadku 
>>> wszystko co potrzebne do wypatrzenia partactwa jest na miejscu.
>> No właśnie nie widzę tego na miejscu.
> 
> call funkcja(x,y,z, None, onGeneralFailure) //- ja widzę jak na dłoni.

Co widzisz? Że któryś z parametrów jest None. I co z tego? Parametr None 
jest nagminny. BTW onGeneralFailure też może być (i w większym projekcie 
po prostu byłby) zaakceptowanym rozwiązaniem.

> 
>> To, że w różnych rzadko używanych językach zwykle nie widzisz takiego 
>> kodu wynika moim zdaniem *tylko i wyłącznie* z faktu że są właśnie 
>> rzadko używane, a więc nie są używane przez przeciętną programistyczną 
> 
> Kiedy właśnie o to chodzi że widzę. Błędy są zawsze, tylko w języku
> czytelnym je o wiele łatwiej dostrzec niż w kryptycznym. A jeszcze 
> trudniej z przeoczeniami. Rzeczy opisywane jawnie przy czytaniu widać, 
> niejawnych trzeba się domyślać i robić reverse-enginnering.

Całe programowanie wysokopoziomowe opiera się na tym, że gross rzeczy 
nie opisuje się jawnie. Wszystko jawnie to masz w assemblerze.

[...]
>>>>> Zamyka efekty uboczne w piaskownicy, niezły wynik.
> [...]
>> Dla mnie to to jest sandbox wywrócony na lewą stronę :)
> 
> Na prawą: możesz narobić efektów ubocznych, ale tylko wewnątrz
> monady, bez zaśmiecenia nimi całego środowiska.

To nie ja robię efekty uboczne, to świat ma efekty :)

> 
>> Wartość niepoznawalna przede wszytskim jest i jest niezmienna. 
>> Można się nią normalnie posługiwać poza samym poznaniem. 
> 
> Zmienność się modeluje funkcjami.
> 
>> Świat (stan zewnętrzny) to nie jest wartość w normalnym 
>> rozumieniu tego słowa, jest np. jednorazowy (nie dziwne nie daje się 
>> cofnąć ani zatrzymać), itd...
> 
> Bo masz rozumienie wartości z ubogich języków.

Ależ skąd.

> Wartością pierwszego
> rzędu może być nie tylko stała, ale również bez problemu funkcja 
> (nawet z funkcji w funkcje)

Oczywiście. Każda z nich jest niezmienna i nie ma "początku" ani "końca" 
istnienia jak każdy przyzwoity obiekt matematyczny.

> - więc świat może być np. ciągiem 
> statycznych stopklatek, a ciąg już się bardzo ładnie modeluje.

Problem w tym, że nie moższ wrócić do poprzedniej.


>> Tzn. typ w którym reprezentuję niepoznawalną stałą Chatina jest dla mnie 
>> jak najbardziej normalnym typem, jego wartości mogę przypisywać, 
>> przekazywać do wywołań, brać jako wyniki, itd. A tu guzik.
> 
> Też możesz, od tego m.in. są monady stanowe. Nawet w zapisie
> to wygląda podobnie jak używanie zmiennych w komputacji imperatywnej.

Wiem jak działają monady stanowe wraz z lukrowym zapisem tego co robią. 
Problem taki, że jeśli reprezentują stan zewnętrzny to nie ma możliwości 
powrotu, cofnięcia się.

Dla monady np. reprezentującej dodawanie do listy mogę sobie z jej 
pośrednimi wartościami różne rzeczy robić. Z monadami reprezentującymi 
stan zewnętrzny już nie jest tak pięknie.

Nie da się świata cofnąć i "sforkować".

> 
>> Ogólnie zadania w których pewne akcje zależą od wcześniej 
>> wykonanych, od wyników (i błędów) występujących wcześniej. 
> 
> No to niech zależą, funkcjami się opisuje właśnie zależności
> - wystarczy je wpisać w parametr funkcji. Naprawdę takich nie
> widziałeś, np. szkolnego przykładu generatorów kolejnych liczb 
> pierwszych, zależnie od tego jaka była ostatnia policzona? 

Oczywiście że widziałem. Wszystkie te szkolne przykłądy reprezentują 
stan wewnętrzny. Tak na marginesie: to, że funkcjami się opisuje 
zależności to rzecz oczywista, każda funkcja jest relacją. Ale nie każdą 
zależność da się opisać funkcjami -- nie każda relacja jest funkcją.

Ze stanem zewnętrznym kłopot taki, że zależności nie koniecznie są 
znane, często też nie nawet jak są znane nie są funkcyjne (nie ma 
jednoznacznego przejścia stan wcześniejszy (argument) -> stan późniejszy 
(wynik)).


>> Funkcyjnie możesz zapisać stan wewnętrzny, ale ze stanem zewnętrznym 
>> (czas systemowy, zewnętrzne źródło danych losowych, etc.) jest gorzej. 
>> Albo zamiata się pod dywan tworząc pseudowartości których się nie daje 
>> traktować jak wartości i udaje że wszystko ok, 
> 
> To jest wewnętrznie sprzeczne - właśnie się da tak traktować, i dlatego
> marudzisz że to udawanie, bo jednak działa. Wymyśliłeś jakąś ezoteryczną
> kategorię pseudowartości (?), ale tam nie ma żadnego zaszytego w środku
> kompilatora hacku

Jest hack, jeśli nie wprost w kompilatorze, to w ściśle z nim związanym 
runtime języka. Mamy specjalny "magiczny" typ, którego "wartości" nie 
zachowują się jak by od wartości należało oczekiwać.

> - to jest w bibliotece, zamodelowane normalnymi 
> mechanizmami języka, dało się zrobić jak wszystkie inne funkcje.

Dopiero po zastosowaniu ww. kompilatorowo-rantajmowej "magii".

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

Piotr Sawicki wrote:
> Sebastian Kaliszewski powiada: [skleiłem]
>  
>>>>>> 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.
>>>>> No sorry, ale to nie spełnia wymogów naukowego eksperymentu.
>> Bo?
> 
> Bo zawiera błędy metodologiczne, jak observer bias.

Skąd wiesz? Żeby to stwierdzić musiałbyś wiedzieć jak sprawdzano poprawność.

[...]
>> BTW. naukowe to jest wtedy kiedy zostało opublikowane jako 
>> publikacja naukowa z podlegająca recenzji. Kropka.
[...]
> Uczestnictwo w dyskursie naukowym
> opiera się na zgodzie na nieustanne podleganie krytyce, 
> sprawdzaniu wyników czy reinterpretacji, ogólnie: obalalności.

Falsyfikowalność dotyczy teorii a nie jej eksperymantalnego wyjaśnienia. 
Oczywiście źle przeprowadzone badanie można obalić. Ale tego nikt jakoś 
nie obalił.

[...]
>>> nie wiadomo jak zdefiniowanej liczby błędów.
>> Nie wiesz co to jest błąd?
> 
> Nie znam jakiejś jedynie słusznej ścisłej definicji. Są różne
> rodzaje błędów różnej skali, o odmiennych konsekwencjach, diametralnie
> innym czasie znajdywania czy poprawiania itd. Plus cała szara strefa
> między już błędem a jeszcze tylko złą praktyką programistyczną,
> której się nie powinno stosować bo albo do błędu w końcu doprowadzi 
> albo np. znacznie podroży koszt dalszego rozwoju aplikacji.

Tu błąd można rozumieć prosto: jest to albo nie spełnienie wymagań 
(specyfikacji problemu, w tym niekompletność rozwiązania) albo 
wyprowadzenie systemu w stan niedopuszczalny (czyli przekroczenie 
specyfikacji systemu).

[...]
>>> Nie wiadomo też, czy takie wyniki są powtarzalne, czy w ogóle
>>> były przeprowadzane innymi metodami i poddane metaanalizie.
>> Eksperyment przeprowadzono dwoma metodami, wynik wyszedł tak samo.
> 
> To napisz albo podaj linka.

Czytałem to wiele lat temu (i wiele "komputerów temu") -- podałem to 
jako wynik o którym wiem, stwierdzający pewną prawidłowość.

> 
>>>> Hipotezą było, że są języki mniej i bardziej błędogenne.
>>> To nie jest nawet poprawnie zdefiniowane, nie wspominając
>>> w ogóle o falsyfikowalności. Można sobie policzyć jakieś
>>> korelacje na nielosowej próbce algorytmów, i w zasadzie tyle.
>>> Nie wiadomo jakich korelacji nie stwierdzono, bo ich nie badano.
>> Ach tak, ty nie czytałeś ale wiesz...
> 
> Wiem co napisałeś. Od siebie dodaję tylko założenie, że rzetelnie 
> zrelacjonowałeś te badania. Oraz wiem, że jeśli jakiejś hipotezy
> nie postawiono, to i jej nie obalono, to akurat stwierdzenie ogólne.

Usiłujesz przemycić fałszywą alternatywę.

> 
>> Bardzo "ciekawe" wnioski "wyciągasz" w ogóle nie znając tych badań. 
>> Jedno jest pewne, te wnioski są "zupełnie nie naukowe" :)
> 
> Właśnie są to równie dobre interpretacje tej samej korelacji
> (która przecież nie jest zależnością przyczynowo-skutkową).

Nie jest, ale co z tego? Jak napisałem nie pośród różnych poszukiwanych 
korelacji (język - liczba błędów, długość kodu - liczba błędów, zadanie 
  do rozwiązania - liczba błędów) stwierdzono korelację długość kodu - 
liczba błędów są wprost proporcjonalne oraz korelację język - długość 
kodu -- jak pamiętam C dawało średnio ok 2x dłuższy kod (i 2x więcej 
błędów), Java ok 1.3x dłuższy kod, różnice długości kodu w pozostałych 
testowanych języki (był w tym Perl i Python i perę innych - nie pamiętam 
co jeszcze) nie były statystycznie istotne.

> 
>> Nie chcesz - nie wierz, to Twój nie mój problem.
> 
> No właśnie problem w tym, że trzeba to przyjąć na wiarę, bo nie
> widać dowodu z prawdziwego zdarzenia.

To nie jest sympozjum naukowe tylko dyskusja na grupie newsowej.

> Więc wybacz, ale dygresję
> o tym eksperymencie potraktuję jako anegdotkę a nie twardy argument
> w dyskusji o przyczynach powstawania błędów w oprogramowaniu.

Proszę bardzo.

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