W dniu środa, 9 kwietnia 2014 13:47:25 UTC+2 użytkownik Stachu 'Dozzie' K. napisał:

> > To byla odpowiedz na Twoja "potrzebe gwarancji". Jezeli potrzebujesz
> > gwarancji, to mozesz to zrobic.
>
> Muszę *sam*. W innych językach to *dostaję*.

No tak. I dlatego jesli potrzebujesz takich gwarancji, to lepiej
sie do PHPa nie zblizaj

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

Mozna tez dane rozwiazanie rozproszyc na wiecej serwerow. Chociaz
wsparcie dla wspolbieznosci w PHP jest fatalne, to klasyczny model
(tzn. PHP+MySQL) pozwala na stosunkowo latwe rozpraszanie.
(Ale zgoda: korzystajac z lepszego jezyka, mozna te rzeczy robic
taniej i lepiej)

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

Nie. Apache to nie jest czesc PHP.

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

Ja nie probuje sie od niczego odcinac. Zgadzam sie, ze ten model
uruchomieniowy jest dla wielu zastosowan niewystarczajacy.
Jedyne, na co nalegam, to zeby wypowiadac sie w sposob precyzyjny.
I to wcale nie jest zle ani niedorzeczne wymaganie.

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

"Skladnia", "semantyka" i ewentualnie "biblioteka standardowa" - owszem.
Inaczej pisze sie w C na mikrokontroler, a inaczej na system operacyjny.

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

Tzn. gdyby zastosowane rozwiazanie rodzilo jakies problemy, to mozna by bylo
te problemy wymienic. Jezeli nie rodzi problemow, to znaczy, ze jest dobre.

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

Moim zdaniem w zupelnosci pomaga.

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

Jak mialem potrzebe skorzystania z nich, to nie mialem problemow,
zeby ich uzyc -- wszystko zadzialalo praktycznie od razu, i nie bylo
zadnych niespodziewanych bledow. Moze Ty masz wieksze wymagania, ale
mi to wystarczylo w zupelnosci.

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

Presupozycja, ze twierdzilem, ze istnieje w PHP pelnoprawny
serwer aplikacji.

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

Jezeli poprowadziles dalej jakas linie argumentacji, to to na pewno
nie byla moja linia argumentacji. W ocenie jezyka programowania istotne
jest wlasnie to, jak latwo mozna w nim osiagac rozne cele. Niezaleznie
od tego, czy w jakims jezyku zostalo napisanych milion roznych programow
(takich jak serwery aplikacji), czy tylko jeden. W przeciwnym razie ocena
nie dotyczy porecznosci jezyka, tylko jego ekosystemu. I jezeli chcemy
oceniac pod tym wzgledem, to tak, Python i Perl maja o wiele lepsze
ekosystemy od PHP.

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

Wydaje mi sie, ze to lekko wyidealizowany obraz tego, jak zaczela sie
dyskusja ;]

W kazdym razie mam nadzieje, ze udalo sie temu nieszczesnemu PHPowi
jakas sprawiedliwosc oddac. I ja sie zgadzam z tym, ze to nie bylby
dobry pomysl, zeby pisac w PHP zaawansowane rzeczy, wiec i moim zdaniem
calkiem slusznie sie tego nie robi.