On 2014-04-09, g...@g...com <g...@g...com> wrote:
> W dniu środa, 9 kwietnia 2014 11:38:15 UTC+2 użytkownik Stachu 'Dozzie' K. napisał:
>>
>> > Schlebia mi, ze masz swoja opinie na temat mocy moich argumentow, ale jezeli
>> > chcesz ja prezentowac publicznie, to bylbym wdzieczny, gdybys oprocz
>> > samej oceny podal rowniez uzasadnienie.
>>
>> Uzasadnienie oceny? Pytasz dlaczego jest bezsensownym twoje twierdzenie,
>> że język jest przyzwoity, bo można oprzeć się o detale implementacyjne,
>> czyli wnętrzności jego runtime'u (o którym podobno w ogóle nie mówisz,
>> bo analizujesz tylko język)?
>
> To byla odpowiedz na Twoja "potrzebe gwarancji". Jezeli potrzebujesz
> gwarancji, to mozesz to zrobic.

Muszę *sam*. W innych językach to *dostaję*.

> Wiekszosc uzytkownikow PHPa najwidoczniej
> takiej potrzeby nie odczuwa -- pisza programy, ktore im dzialaja.

Właśnie. *Im* działają, przy *ich* obciążeniach. A gdy przychodzi do
czegoś większego, zostaje tylko przepisać od nowa pod inny runtime, bo
się człowiek potyka o kwiatki w interpreterze.

>> Albo że język jest przyzwoity, bo
>> teoretycznie można (wkładając dopiero mnóstwo wysiłku) zmusić go do
>> pracy w modelu, w którym praktycznie nikt go nie używa?
>
> Moze przeczytaj jeszcze raz to, co napisalem. Tomasz Sowa napisal, ze
> problemem pehapa jest to, ze nie utrzymuje stanu pomiedzy zapytaniami.
> Ja doprecyzowalem, ze to nie jest problem pehapa, tylko modelu
> uruchomieniowego.

Aha, czyli interpreter PHP to nie jest część PHP? Fajnie. Ale wiesz, my
tu o konkretnych problemach mówimy, nie o oderwanych od rzeczywistości
potencjalnych możliwościach.

>> > Oczywiscie, mozna dyskutowac nad tym, czy korzystanie z pamieci wspoldzielonej
>>
>> > w ogole to dobry pomysl. Ale to juz nie jest kwestia dotyczaca PHPa,
>>
>> Chwila, stop. Najpierw *sam* wyciągasz pamięć współdzieloną, bo "można
>> w ten sposób zmusić PHP do pracy jako serwer aplikacji", a teraz mówisz,
>> że to nie jest kwestia dotycząca PHP?
>
> Tak. Ze to nie jest kwestia dotyczaca jezyka.

Ale my razem z językiem krytykujemy też interpreter i jego główny
(niemal wyłączny) model pracy. To tylko ty próbujesz się odciąć od
konkretnych problemów w zastosowaniach inżynierskich.

> I ze zarzut, ze PHP to kiepski
> jezyk, bo "nie utrzymuje stanu pomiedzy wywolaniami" jest nietrafiony, bo
> inne jezyki tez tego nie robia, i ze ten zarzut nie odnosi sie do PHP jako
> do jezyka, tylko do popularnej konfiguracji srodowiska uruchomieniowego
> z wykorzystaniem tego jezyka.

Zarzut jest całkiem dobry, tylko nieszczęśliwie zastosowano
uproszczenie, polegające na utożsamieniu pojęcia "język" z kompletem
"składnia", "biblioteka standardowa" i "środowisko uruchomieniowe".
Które, nawiasem mówiąc, dokładnie tak jest rozumiane przez resztę
świata (przynajmniej tego inżynierskiego, piszącego pracujące
aplikacje).

>> >> PHP to nie tylko *sam język*, ale również *biblioteka standardowa*
>> >> (która jest obrzydliwa) i *środowisko uruchomienia* (które potrafi
>> >> pracować sensownie jedynie w modelu "jedno żądanie = jedno uruchomienie
>> >> i zakończenie programu"). Zupełnie nie ma znaczenia, co można osiągnąć
>> >> z tym runtimem mając do dyspozycji kompetentny zespół specjalistów
>> >> i kilka lat pracy. Istotne jest co PHP daje *aktualnie*.
>> >
>> > A jak pisze sie w PHP wtyczki do Renoise'a (program muzyczny), to to nadal
>> > jest "*srodowisko uruchomienia* (ktore potrafi pracowac sensownie jedynie
>> > w modelu "jedno zadanie = jedno uruchomienie i zakonczenie programu")"?
>>
>> Jeden odstający program. I autorzy Renoise są zostawieni samym sobie,
>> nikt im nie pomoże przy problemach z integracją PHP.
>
> Ale znalezli jezyk, ktory nadaje sie do ich potrzeb. Dziala. Nie narzekaja.

Są ludzie, którzy nie narzekają na konieczność grzebania w śmietnikach
dla przeżycia. Słaby argument. Spróbuj czegoś bardziej technicznego.

>> > (I tutaj ciekawostka: obsluga sygnalow uniksowych
>> > w PHP jest zrobiona calkiem przyzwoicie)
>>
>> Że co? W PHP obsługa uniksowych sygnałów jest zrobiona dokładnie jak
>> w C. Alternatywnie, obsługa uniksowych sygnałów jest zrzucona na libev.
>>
>> Nie można zwykłego przekazywania wszystkiego jak leci niżej nazywać
>> "zrobionym całkiem przyzwoicie".
>
> Dlaczego nie mozna? Jezeli daje sie latwo uzywac i nie sprawia problemow,
> to mozna. Chyba ze masz jakies konkretne zarzuty, to wowczas z checia
> ich wyslucham i sie ustosunkuje.

"Obsługa sygnałów dobrze zrobiona" to jest w Perlu, tam można ustawiać
funkcje obsługi bez martwienia się o detale znane z C, jak który to był
numer SIGUSR1: 30, 10 czy 16? Garść predefiniowanych stałych nie pomaga
na to.

A zarzuty? Praca z numerami sygnałów zamiast uczciwie z ich nazwami
(callback dostaje numerek zamiast nazwy; weź to potem zamieniaj na nazwę
czytelną dla człowieka) oraz ticks, które są detalem implementacyjnym,
a mimo to użytkownik *musi* je ustawić, bo inaczej handlery nie
działają.

Sygnały są bardzo prostym mechanizmem, a mimo to w PHP udało się je
opakować źle.

>> > Zas co do rzeczy, ktore ktos juz kiedys robil, to coz -- one sa juz
>> > zrobione.
>>
>> Tak? Pełnoprawny serwer aplikacji w PHP? Pokaż.
>
> ?

Która część jest niezrozumiała?

>> >> Naprawdę, to nie jest stanowisko, którego może bronić osoba pisząca
>> >> jakiekolwiek programy.
>> >
>> > Jakie stanowisko? Ze jesli chce sie cos miec, to mozna to samemu zrobic?
>>
>> I dlatego język jest przyzwoity? Bo można zrobić samemu? Bo tak do tej
>> pory wynika z twoich wypowiedzi. W Brainfucku też można napisać serwer
>> aplikacji. To przyzwoity język!!!
>
> Jezeli nie widzisz, jakie przewagi PHP ma nad brainfuckiem, to moze
> faktycznie lepiej powrocmy do tego stanu zawieszenia dyskusji.

Jeśli nie widzisz jakie problemy ma PHP z sobą samym (znowu tablice!),
to może faktycznie lepiej powróćmy do tego stanu zawieszenia dyskusji.

I nie twierdzę, że Brainfuck jest lepszym od PHP językiem do tworzenia
aplikacji. Właściwie to wręcz przeciwnie. Poprowadziłem tylko twoją
linię argumentacji trochę dalej niż ty sam się zatrzymałeś -- i sam
widzisz jaka niedorzeczność wyszła.

>> A poprawianie tak, żeby to miało sens, w tym przypadku powinno polegać
>> na stworzeniu zupełnie nowego języka, o wygodniejszej składni, bogatszej
>> semantyce i lepszemu runtime'owi. I wiesz co? Takie rzeczy są robione.
>> Naprawdę. Możesz poszukać jak nie wierzysz.
>
> Alez wierze. Powtorze: PHP to jezyk, ktoremu daleko jest do doskonalosci
> i niewatpliwie istnieja lepsze jezyki. Od poczatku tak mowilem. Ale
> twierdzenie, ze PHP to dno den, nie oddaje sprawiedliwosci jego tworcom.

Ale tutaj nikt nie twierdzi, że PHP to dno den. Są języki znacznie
gorsze. Tu się tylko twierdzi (od tego zaczęła się dyskusja), że w PHP
rzadko się pisze cokolwiek bardziej zaawansowanego -- a potem było
pokazywane, co odstrasza dobrych programistów od PHP.

--
Secunia non olet.
Stanislaw Klekot