On 2014-04-09, g...@g...com <g...@g...com> wrote:
> W dniu wtorek, 8 kwietnia 2014 23:49:40 UTC+2 użytkownik Stachu 'Dozzie' K.
napisał:
>> On 2014-04-08, g...@g...com <g...@g...com> wrote:
>>
>> > W dniu wtorek, 8 kwietnia 2014 21:45:59 UTC+2 użytkownik g...@g...com
napisał:
>>
>> >> Czyli Twojego zarzutu nie mozna rozumiec jako zarzutu przeciwko PHP, tylko
>> >> przeciwko apache'owi i mod_php (jednak ten sam zarzut bedzie sie stosowal
>> >> rowniez do apache'a z mod_python, mod_perl czy mod_ruby)
>> >
>> > Jeszcze przyszlo mi do glowy, ze przeciez w PHP mozna korzystac z pamieci
>> > wspoldzielonej. Jesli do tego zaimplementuje sie odpowiednio interfejs
>> > ArrayAccess, to [...]
>>
>> Skończ już bronić PHP w tak niedorzeczny sposób. Twoje argumenty są tak
>> słabe, że aż trudno uwierzyć, że ktokolwiek mający cokolwiek wspólnego
>> z programowaniem mógł je zaproponować (piję tu w dużej części do twojej
>> propozycji oparcia się o nieudokumentowane wnętrzności interpretera;
>> tutaj proponujesz pisać samemu dzikie hacki, które pozwolą na stworzenie
>> bardzo kulawego serwera aplikacji, którego i tak nikt nie będzie
>> używać).
>
> 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)? 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?

Przyznam, że ciężko mi wyjaśnić dlaczego te dwa są bezsensowne. Podałbym
"zdrowy rozsądek" jako powód, ale trudno się dowodzi "zdrowy rozsądek".

> Bo na chwile obecna, jezeli nawet
> moje argumenty sa slabe, to Twoich nie ma wcale.

Misiu, przejrzyj może wątek jeszcze raz. Było parę argumentów *ode mnie*,
z niedorzecznymi, nieintuicyjnie (gwarancje złożoności anyone?)
działającymi tablicami i z kiepskim interpreterem na czele.

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

> bo ta sama
> dyskusja odnosilaby sie w rownym stopniu do Pythona, Ruby'ego, Javy i
> w zasadzie wszystkich jezykow programowania, w ktorych ktokolwiek chcialby
> cos podobnego wprowadzic.

Nie. W Pythonie są już gotowe serwery aplikacji (Twisted, Phusion
Passenger, Zope). W Rubym też. Java ma ich pewnie nawet więcej, niż
Python, Ruby i Perl razem wzięte. W PHP nie ma *żadnego*, tylko model
"żadanie-uruchom program-zakończ program".

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

> Albo skrypty CLI?

Wiesz ile się pisze narzędzi do wiersza poleceń w PHP? Prawie wcale.
W PHP skrypty do wiersza poleceń piszą tylko ci, którzy nie znają
żadnego innego języka.

#v+
[dozzie@uw000444 bin]$ pwd
/usr/bin
[dozzie@uw000444 bin]$ head -n 1 * | grep --binary-files=text --count php
3
[dozzie@uw000444 bin]$ head -n 1 *(.) | grep --binary-files=text php
==> php5 <==
==> php5-cgi <==
==> php_count <==
[dozzie@uw000444 bin]$ head -n 1 * | grep --binary-files=text --count python
102
[dozzie@uw000444 bin]$ head -n 1 * | grep --binary-files=text --count ruby
26
[dozzie@uw000444 bin]$ head -n 1 * | grep --binary-files=text --count perl
406
[dozzie@uw000444 bin]$ head -n 1 * | grep --binary-files=text --count -E
'/bin/(sh|bash)'
339
[dozzie@uw000444 bin]$ /bin/ls -1 | wc -l
2711
[dozzie@uw000444 bin]$
#v-

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

> Do tej pory, ilekroc pisalem o PHP, mialem na mysli jezyk wlasnie,
> a nie srodowisko uruchomieniowe (ktore mozna by bylo w tym kontekscie
> precyzyjniej okreslic jako mod_php, wiec nie ma potrzeby wprowadzania
> zamieszania). Podobnie, czym innym jest uzywanie mod_ruby, a czym innym
> korzystanie z Railsow.

Ale już nie da się oddzielić języka od zbioru interpreterów. Jak się
pisze o Pythonie, to ma się na myśli wszystkie trzy: składnię,
bibliotekę standardową i główną implementację interpretera (CPython).
To samo dotyczy Rubyego i czegokolwiek innego. Trudno prowadzić rzeczową
dyskusję o języku w oderwaniu od jego interpretera.

>> A że PHP jest zupełne w sensie Turinga, to i teoretycznie można zrobić
>> *dokładnie to samo*, co w Haskellu albo innym Pythonie. Tylko że *będzie
>> to niewygodne* (bo język niedostosowany) i *nikt* tego tak w PHP
>> *nigdy nie robił*, więc ktokolwiek będzie chciał go użyć inaczej zostaje
>> sam bez jakiejkolwiek pomocy.
>
> Brainfuck tez jest zupelny w sensie Turinga, a jednak mysle, ze sie
> zgodzisz, ze PHP jest mimo wszystko lepszy do pisania programow.

Głównie dlatego, że głównym założeniem Brainfucka było, żeby program
w nim napisany wyglądał jak najdziwniej. Argument niedorzeczny, bo PHP
miało być łatwe w użyciu, a nie dziwne.

> Zas co do rzeczy, ktore ktos juz kiedys robil, to coz -- one sa juz
> zrobione.

Tak? Pełnoprawny serwer aplikacji w PHP? Pokaż.

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

> Ze zamiast narzekac, ze cos jest marne, mozna to poprawic, albo przynajmniej
> zaproponowac autorowi, jak mozna by to poprawic?

Autorowi było proponowane wielokrotnie (poszukaj po bugtrackerze PHP).
Wynik widać.

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.

--
Secunia non olet.
Stanislaw Klekot

do góry

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. Wiekszosc uzytkownikow PHPa najwidoczniej
takiej potrzeby nie odczuwa -- pisza programy, ktore im dzialaja.
Ale OK -- jezeli masz owa potrzebe gwarancji, i inne jezyki Ci ja daja,
to korzystaj z tych innych jezykow.

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

> Przyznam, że ciężko mi wyjaśnić dlaczego te dwa są bezsensowne. Podałbym
> "zdrowy rozsądek" jako powód, ale trudno się dowodzi "zdrowy rozsądek".

Zdrowy rozsadek nakazywalby najpierw zrozumiec to, co sie chce
skrytykowac.

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

> > bo ta sama
> > dyskusja odnosilaby sie w rownym stopniu do Pythona, Ruby'ego, Javy i
> > w zasadzie wszystkich jezykow programowania, w ktorych ktokolwiek chcialby
> > cos podobnego wprowadzic.
>
> Nie. W Pythonie są już gotowe serwery aplikacji (Twisted, Phusion
> Passenger, Zope). W Rubym też. Java ma ich pewnie nawet więcej, niż
> Python, Ruby i Perl razem wzięte. W PHP nie ma *żadnego*, tylko model
> "żadanie-uruchom program-zakończ program".

Hola hola. Teraz mowisz nie o tych jezykach, tylko o aplikacjach napisanych
w tych jezykach.

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

> > Albo skrypty CLI?
>
> Wiesz ile się pisze narzędzi do wiersza poleceń w PHP? Prawie wcale.
> W PHP skrypty do wiersza poleceń piszą tylko ci, którzy nie znają
> żadnego innego języka.

Ja znam inne jezyki, a mimo to zdarza mi sie pisac skrypty w PHP

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

> > Do tej pory, ilekroc pisalem o PHP, mialem na mysli jezyk wlasnie,
> > a nie srodowisko uruchomieniowe (ktore mozna by bylo w tym kontekscie
> > precyzyjniej okreslic jako mod_php, wiec nie ma potrzeby wprowadzania
> > zamieszania). Podobnie, czym innym jest uzywanie mod_ruby, a czym innym
> > korzystanie z Railsow.
>
> Ale już nie da się oddzielić języka od zbioru interpreterów.

Da sie. Np.
http://eli-project.sourceforge.net/c_html/c.html
http://perl6.org/specification/
http://www.masswerk.at/algol60/report.htm
http://scheme-reports.org/
http://www.math.bas.bg/bantchev/place/iswim.html

> Jak się
> pisze o Pythonie, to ma się na myśli wszystkie trzy: składnię,
> bibliotekę standardową i główną implementację interpretera (CPython).

Jak sie pisze w pythonie, to sie ma na mysli rozne rzeczy.

> To samo dotyczy Rubyego i czegokolwiek innego. Trudno prowadzić rzeczową
> dyskusję o języku w oderwaniu od jego interpretera.

Owszem, trudno. Teoria modeli, semantyka denotacyjna, dziedziny Scotta,
projekcje Futamury -- to przyklady rzeczowych dyskusji o jezykach
w oderwaniu od ich interpreterow. Przyznam, ze to nie sa latwe
dyskusje, ale samym swoim jestestwem dowodza, ze sa mozliwe.

> >> A że PHP jest zupełne w sensie Turinga, to i teoretycznie można zrobić
> >> *dokładnie to samo*, co w Haskellu albo innym Pythonie. Tylko że *będzie
> >> to niewygodne* (bo język niedostosowany) i *nikt* tego tak w PHP
> >> *nigdy nie robił*, więc ktokolwiek będzie chciał go użyć inaczej zostaje
> >> sam bez jakiejkolwiek pomocy.
> >
> > Brainfuck tez jest zupelny w sensie Turinga, a jednak mysle, ze sie
> > zgodzisz, ze PHP jest mimo wszystko lepszy do pisania programow.
>
> Głównie dlatego, że głównym założeniem Brainfucka było, żeby program
> w nim napisany wyglądał jak najdziwniej. Argument niedorzeczny, bo PHP
> miało być łatwe w użyciu, a nie dziwne.

Nie wydaje mi sie, zeby takie bylo glowne zalozenie brainfucka.

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

?

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

> > Ze zamiast narzekac, ze cos jest marne, mozna to poprawic, albo przynajmniej
> > zaproponowac autorowi, jak mozna by to poprawic?
>
> Autorowi było proponowane wielokrotnie (poszukaj po bugtrackerze PHP).
> Wynik widać.

Jak sie porowna php 4 z php 5, to naprawde widac. Jezeli sie porowna
PHP 5.2 z 5.3, albo ktorekolwiek dwie kolejne wersje, to widac znaczaca
roznice i to, ze ten wplyw spolecznosci na jezyk jest czyms realnym

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

do góry

On 2014-04-09, g...@g...com <g...@g...com> wrote:
> ...a poniewaz mimo wczesniejszej sugestii zdecydowales sie kontynuowac
> dyskusje, to postanowilem odpisac rowniez na Twojego poprzedniego
> posta.
>
> W dniu czwartek, 27 marca 2014 15:44:10 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:
>>
>> >> > Historycznie. Wiele z tych niedostatkow zostalo juz poprawionych,
>> >>
>> >> ...w ciągu ostatnich czterech-sześciu lat, czyli już dawno po
>> >> terminie...
>> >
>> > A jaki byl termin?
>>
>> Tak z piętnaście lat temu, kiedy Python zaczął dobrze zdobywać
>> popularność.
>
> W takim razie dlaczego PHP wciaz sie cieszy tak duza popularnoscia?

Jest popularny, bo parę miesięcy wcześniej też był popularny. To dość
prosty mechanizm. Produkt z dużą liczbą użytkowników, nieważne jak
bardzo by był gówniany, nie znika nagle z rynku.

>> >> > Takich gwarancji nie daje nawet C.
>> >> > A PHP pod tym wzgledem nigdy mnie nie zaskoczyl, chociaz robilem
>> >> > z nim naprawde dziwne rzeczy.
>> >>
>> >> W C wiadomo, że dostęp do elementu w tablicy ma złożoność O(1). W PHP
>> >> nie wiadomo, bo przy tej mieszance nie-wiadomo-jakiej-mapy (hasz
>> >> z porządkiem to *nie jest* standardowa implementacja hasza) i tablicy
>> >> nie jestem w stanie powiedzieć, że złożoność jest O(F(n)).
>> >
>> > To mowimy o czasie, czy o zlozonosci?
>>
>> O złożoności czasowej? Ja nie chcę pisać systemu czasu rzeczywistego, ja
>> chcę wiedzieć że system nie klęknie przy wzroście ilości danych.
>
> To sie fachowo nazywa "zlozonosc obliczeniowa".

Misiu, fachowo i w pełni formalnie to to się nazywa "złożoność
obliczeniowa czasowa", w odróżnieniu od "złożoności obliczeniowej
pamięciowej" (a są jeszcze inne rodzaje). Za mały jesteś żeby mnie na
terminologię zaginać.

> A jezeli chcesz wiedziec, ze system nie kleknie przy wzroscie ilosci
> danych, to niezaleznie od uzytego jezyka powinienes napisac testy
> obciazeniowe.

ROTFL. Kolejny wyznawca testów.

Zdajesz sobie sprawę z tego, że pisanie testów jest a) drogie,
b) kłopotliwe, c) trudne, d) dalekie od rzeczywistego rozkładu
obciążenia, e) drogie? A zastosowanie struktury danych, która przy
większej ilości danych zachowa się przewidywalnie jest tanie i, cóż,
bardziej przewidywalne właśnie. Testy nie są remedium na wszystkie
niedostatki.

>> > Jezeli uruchamiasz cos na systemie ze stronicowaniem pamieci,
>> > to tracisz wszelkie gwarancje czasowe (chyba ze korzystasz z jakichs
>> > watkow czasu rzeczywistego). Na potrzeby praktyczne mozna uznac,
>> > ze w PHP czas dostepu do tablicy jest rzedu O(1)
>>
>> ...z dokładnością do tego, że nie można, bo to nie jest normalna
>> tablica, a nigdzie nie ma deklaracji, że tak to będzie się zachowywać.
>
> Ten sam zarzut mozna miec przeciwko stronicowaniu pamieci w komputerze.
> Nigdzie nie masz gwarancji, ze dane, do ktorych sie odnosisz, nie znajduja
> sie akurat w pliku wymiany.

A owszem, możesz mieć takie gwarancje. Wystarczy wyłączyć swap. Tylko że
to jest strojenie operacyjne, jedynie przyprawa do samego systemu.

Jeśli system jest źle napisany (używa niewłaściwych struktur i/lub ma
złą architekturę), to żadne strojenie nie pomoże.

> A jesli naprawde Cie to boli, to czasy dostepow do tablic mozesz sobie
> pomierzyc.

Nie mogę, bo nie są nigdzie udokumentowane i moje pomiary mogą wziąć
w łeb przy dowolnej aktualizacji między patchlevelami.

Czy ty pisałeś kiedyś cokolwiek innego niż programy na studia?

>> Jeszcze lepiej, każesz mi pilnie śleldzić wnętrzności! Może zakończmy tę
>> dyskusję, bo o ile jestem tylko sysadminem, to to, co mi właśnie radzisz
>> o PHP kłóci się straszliwe ze wszystkim, co wiem o pisaniu softu,
>> a nawet ze zwyczajnym zdrowym rozsądkiem.
>
> Ja Ci nic nie kaze. To Ty mowisz, ze chcesz miec jakies gwarancje.

Bo chcę mieć *gwarancje*. Gwarancją jest, jeśli twórca się *zobowiązał*.
A tu się nie zobowiązuje.

> Mozesz tez (jesli chcesz) napisac do tworcow PHP i zapytac, jak sie
> sprawy maja. Mozesz zatrudnic kogos, kto za Ciebie przeanalizuje
> kod PHP. Mozliwosci jest naprawde wiele.

...i wszystkie mają ten sam problem: twórca się nie zobowiązał, więc
nadal nie mam żadnych sensownych gwarancji na zachowanie w przyszłości.

> BTW skoro programowanie Cie tak interesuje, to dlaczego nie zatrudnisz
> sie jako programista?

Bo pisanie kolejnego systemu bankowego w PHP czy innego sklepu
internetowego w Railsach mnie nudzi. Co innego pisanie narzędzi do
zarządzania środowiskiem serwerowym -- ale to mogę wykonywać jako
sysadmin.

>> >> Nie. W haszu nie ma pojęcia pojęcia "połowa tablicy". W haszu nie ma
>> >> pojęcia "element 2*n+1", w każdym razie nie bez dziwnego, sztucznego
>> >> traktowania kontenera przez programistę ("umówmy się, że nie będę
>> >> robić X").
>> >
>> > Tablice PHP zachowuja porzadek wprowadzania, wiec jest w nich
>> > pojecie "polowa tablicy".
>>
>> Który z kluczy jest tym w "połowie tablicy"? I co to znaczy "zachowują
>> porządek wprowadzania"? Jak wprowadzę klucze 9, 8, 7, to będę miał
>> iterację w tej właśnie kolejności? (Co jest niedorzeczne, bo dla *tablicy*
>> powinna być rosnąca.) A może w kolejności 7, 8, 9? (Co jest
>> niedorzeczne, bo klucze-stringi są traktowane inaczej, zgodnie z tym co
>> mówisz.) W którą stronę się nie obrócić, sytuacja do dupy, bo
>> w pierwszym wyborze (mieszanie tablic z haszem) ktoś zj***ł sprawę.
>
> Ale mowisz tak, bo jestes doswiadczonym programista PHPa, ktoremu
> te kwestie zawsze sprawialy klopot, czy po prostu wynajdujesz powody
> zeby sie przyj***c?

Pokazuję dlaczego tablice w PHP są zepsute. Są *niekonsekwentną*
mieszanką kilku różnych, przypadkowo wybranych struktur.

>> > Jezeli nie masz potrzeby robic z tego
>> > uzytku, to mozesz ignorowac kwestie porzadku w haszach.
>>
>> Ale to już dawno nie jest standardowy hasz, skoro zapamiętuje kolejność
>> wprowadzania kluczy. Z samego tego tytułu nie mogę nic powiedzieć
>> o złożoności czasowej operacji.
>
> Jezeli taka duza kontrola jest Ci potrzebna, mozesz programowac w C albo C++.

Albo w Erlangu. Albo w Perlu, Pythonie czy innym Rubym. Oczywiście.
Powiem więcej: tak właśnie robię. Od PHP się trzymam z daleka z niemal
wszystkich powodów, jakie się pojawiły w tym wątku.

> Ale, jak sie okazuje, w praktyce tak duza kontrola jest potrzebna w niewielu
> procentach przypadkow.

...w niewielu procentach przypadków programistów PHP.

>> >> > Bystry kompilator moglby sam wpasc na to, kiedy uzyc jakiej struktury
>> >> > danych.
>> >>
>> >>
>> >> W PHP nie ma bystrego kompilatora (czy tam parsera). W PHP jest
>> >> interpreter, który jest tak głupi, że dla niego 0x0+2 = 4.
>> >> Interpreter PHP nawet nie konstruuje drzewa wyprowadzenia, tylko
>> >> uruchamia kod od razu w ramach akcji semantycznych.
>> >
>> > To prawda. Ale to kwestia implementacji, a nie semantyki.
>>
>> Sam wyciągnąłeś kwestie implementacyjne. Aktualnie sprawa wygląda tak,
>> że PHP ssie jak odkurzacz.
>
> To zalezy jak na to spojrzec. Pod wieloma wzgledami odkurzacz jest lepszy
> od miotly, a to jednak miotla wymiata.

Słabe analogie są słabe. Oryginalna implementacja PHP ssie, innymi
słowy, jest do dupy. Próba wyciągania jakiejś "miotły" z tego porównania
to pusta demagogiczna żonglerka słowami.

> Jezeli zas idzie o gadanie z sensem, to cofam to, co powiedzialem wczesniej.
> Facebook zrobil kompilator dla PHP, nazywa sie "HipHop", i jesli ktos chce,
> moze z niego korzystac.

Ja czekam aż HHVM przestanie kompilować PHP (hacklang.org anyone?).
Poza tym a) to żadna zasługa autorów PHP i b) nadal nie jest to
powszechna metoda uruchamiania kodu PHP.

>> >> > A z perspektywy uzytkownika nie musi miec znaczenia, czy uzywa
>> >> > drzewa, wektora czy haszmapy, i jezeli ktos moze tutaj cos pojeciowo
>> >> > namieszac, to tylko sam uzytkownik.
>> >>
>> >> Dlaczego chcesz *zmuszać* użytkownika do stałego uważania jeszcze w tym
>> >> miejscu? W PHP jest wystarczająco dużo miejsc gdzie można się potknąć.
>> >> Dlaczego dokładać jeszcze to jedno? Bo na pewno nie dla wygody (w innych
>> >> językach hasz i tablica są rozdzielone i *nikt* nie narzeka).
>> >
>> > W PHPie nie sa rozdzielone, i tez nikt nie narzeka.
>>
>> Jak to nikt? Dużo tych, którzy znają cokolwiek więcej niż sam PHP.
>> To nie jest "nikt".
>
> No ja w swojej karierze poznalem tylko jedna osobe, ktora na to narzekala,
> i jestes nia Ty.

http://me.veekun.com/blog/2012/04/09/php-a-fractal-o
f-bad-design/#arrays
http://www.beastwithin.org/users/wwwwolf/code/phpran
t.html

Naprawdę myślisz że jestem odosobnionym przypadkiem?

>> > Jezeli ktos wie, jak korzystac z haszow, poradzi osobie z tablicami PHP.
>> > Jezeli ktos wie, jak korzystac z tablic, tez sobie poradzi.
>>
>> Nie ma "sobie poradzić". Ma się nie potykać *niepotrzebnie* o głupoty.
>
> Jezeli idzie o te akurat kwestie (tzn. ujednolicenie interfejsu do tablicy
> i do hasza), to wyraznie mozna miec na nia rozne poglady. Tak samo
> jak na to, ze javascript utozsamia ze soba pojecie haszu i obiektu.

...co jest też uważane za głupie, o czym można poczytać w internetsach.
Obrona słabej konstrukcji przez pokazywanie innych konstrukcji, równie
słabych i równie mocno krytykowanych, nie jest dobrym argumentem.

> I wyraznie Ty i ja mamy na te kwestie odmienne poglady. Jezeli przedstawisz
> mi przekonujace argumenty za tym, ze to PHP-owe pomieszanie jest niedobre,
> to -- zgodnie z definicja slowa "przekonujacy" -- zostane przekonany.

Nie zostaniesz. Aktualnie zbyt jesteś oddany swojemu stanowisku, żeby
przyjąć mocne, rzeczowe argumenty. To samo dotyczy mnie.

Twierdzę, że w tej dyskusji żaden z nas dwóch nie przekona drugiego;
dopiero po paru tygodniach czy miesiącach może coś z argumentów
przesiąknie. Ale twoje argumenty opierają się o "no i co że jest
wymieszane? to nie problem, bo można zobaczyć w X i Y dla konkretnej
wersji, a poza tym i tak nikt tego nie potrzebuje". Mnie taka
argumentacja nie przekonuje.

> Jednak w ogolnosci zgodze sie, ze w PHP jest duzo niepotrzebnych glupot,
> o ktore latwo sie potknac (kiedys np. potknalem sie o idiotyczne zachowanie
> funkcji array_diff, gdy wywolac ja na tablicy tablic). Ja nie twierdze,
> ze PHP jest jezykiem doskonalym. Ale ciesze sie, ze jest na tyle ekspresyjny,
> ze z wieloma jego niedoskonalosciami mozna sobie poradzic -- i z tego
> powodu staram sie oddac mu sprawiedliwosc raczej, niz do niego przyj*****c.

Słaba ta ekspresywność. Naprawdę, mnóstwo języków ma lepszą. List
comprehensions, metaklasy, spójna i konsekwentna biblioteka standardowa
potrafiąca pracować z referencjami do funkcji (m.in. z closures),
standardowe sposoby rozmieszczania kodu po plikach...

--
Secunia non olet.
Stanislaw Klekot

do góry

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

do góry

W dniu środa, 9 kwietnia 2014 13:03:49 UTC+2 użytkownik Stachu 'Dozzie' K. napisał:
> > W takim razie dlaczego PHP wciaz sie cieszy tak duza popularnoscia?
>
> Jest popularny, bo parę miesięcy wcześniej też był popularny. To dość
> prosty mechanizm. Produkt z dużą liczbą użytkowników, nieważne jak
> bardzo by był gówniany, nie znika nagle z rynku.

Niemniej, jezeli jakies rozwiazanie mialoby dawac wyrazna przewage
nad konkurencja, to to by byl dobry powod, zeby wyprzec te konkurencje
z rynku. Tak sie przynajmniej zdaje.

> > To sie fachowo nazywa "zlozonosc obliczeniowa".
>
> Misiu, fachowo i w pełni formalnie to to się nazywa "złożoność
> obliczeniowa czasowa", w odróżnieniu od "złożoności obliczeniowej
> pamięciowej" (a są jeszcze inne rodzaje). Za mały jesteś żeby mnie na
> terminologię zaginać.

Punkt dla Ciebie.

> > A jezeli chcesz wiedziec, ze system nie kleknie przy wzroscie ilosci
> > danych, to niezaleznie od uzytego jezyka powinienes napisac testy
> > obciazeniowe.
>
> ROTFL. Kolejny wyznawca testów.

Wyznawca? Wydaje mi sie, ze podejscie "jezeli chcesz cos wiedziec,
to to sprawdz" jest calkiem zdroworosadkowe.

> Zdajesz sobie sprawę z tego, że pisanie testów jest a) drogie,
> b) kłopotliwe, c) trudne, d) dalekie od rzeczywistego rozkładu
> obciążenia, e) drogie? A zastosowanie struktury danych, która przy
> większej ilości danych zachowa się przewidywalnie jest tanie i, cóż,
> bardziej przewidywalne właśnie. Testy nie są remedium na wszystkie
> niedostatki.

Zgodze sie, ze pisanie dobrych testow nie jest banalna sprawa

> > Ten sam zarzut mozna miec przeciwko stronicowaniu pamieci w komputerze.
> > Nigdzie nie masz gwarancji, ze dane, do ktorych sie odnosisz, nie znajduja
> > sie akurat w pliku wymiany.
>
> A owszem, możesz mieć takie gwarancje. Wystarczy wyłączyć swap. Tylko że
> to jest strojenie operacyjne, jedynie przyprawa do samego systemu.

OK

> Jeśli system jest źle napisany (używa niewłaściwych struktur i/lub ma
> złą architekturę), to żadne strojenie nie pomoże.

Zgoda

> > A jesli naprawde Cie to boli, to czasy dostepow do tablic mozesz sobie
> > pomierzyc.
>
> Nie mogę, bo nie są nigdzie udokumentowane i moje pomiary mogą wziąć
> w łeb przy dowolnej aktualizacji między patchlevelami.

Jezeli raz opracujesz framework do pomiarow, to po aktualizacji mozesz
go uruchomic jeszcze raz.

> Czy ty pisałeś kiedyś cokolwiek innego niż programy na studia?

Owszem. A co mialoby to miec do rzeczy?

> >> Jeszcze lepiej, każesz mi pilnie śleldzić wnętrzności! Może zakończmy tę
> >> dyskusję, bo o ile jestem tylko sysadminem, to to, co mi właśnie radzisz
> >> o PHP kłóci się straszliwe ze wszystkim, co wiem o pisaniu softu,
> >> a nawet ze zwyczajnym zdrowym rozsądkiem.
> >
> > Ja Ci nic nie kaze. To Ty mowisz, ze chcesz miec jakies gwarancje.
>
> Bo chcę mieć *gwarancje*. Gwarancją jest, jeśli twórca się *zobowiązał*.
> A tu się nie zobowiązuje.

W porzadku. Przynajmniej wiadomo, jak sie sprawy maja

> > Mozesz tez (jesli chcesz) napisac do tworcow PHP i zapytac, jak sie
> > sprawy maja. Mozesz zatrudnic kogos, kto za Ciebie przeanalizuje
> > kod PHP. Mozliwosci jest naprawde wiele.
>
> ...i wszystkie mają ten sam problem: twórca się nie zobowiązał, więc
> nadal nie mam żadnych sensownych gwarancji na zachowanie w przyszłości.

Moze jak napiszesz do tworcow PHP, to sie zobowiaza.

> >> >> Nie. W haszu nie ma pojęcia pojęcia "połowa tablicy". W haszu nie ma
> >> >> pojęcia "element 2*n+1", w każdym razie nie bez dziwnego, sztucznego
> >> >> traktowania kontenera przez programistę ("umówmy się, że nie będę
> >> >> robić X").
> >> >
> >> > Tablice PHP zachowuja porzadek wprowadzania, wiec jest w nich
> >> > pojecie "polowa tablicy".
> >>
> >> Który z kluczy jest tym w "połowie tablicy"? I co to znaczy "zachowują
> >> porządek wprowadzania"? Jak wprowadzę klucze 9, 8, 7, to będę miał
> >> iterację w tej właśnie kolejności? (Co jest niedorzeczne, bo dla *tablicy*
> >> powinna być rosnąca.) A może w kolejności 7, 8, 9? (Co jest
> >> niedorzeczne, bo klucze-stringi są traktowane inaczej, zgodnie z tym co
> >> mówisz.) W którą stronę się nie obrócić, sytuacja do dupy, bo
> >> w pierwszym wyborze (mieszanie tablic z haszem) ktoś zj***ł sprawę.
> >
> > Ale mowisz tak, bo jestes doswiadczonym programista PHPa, ktoremu
> > te kwestie zawsze sprawialy klopot, czy po prostu wynajdujesz powody
> > zeby sie przyj***c?
>
> Pokazuję dlaczego tablice w PHP są zepsute. Są *niekonsekwentną*
> mieszanką kilku różnych, przypadkowo wybranych struktur.

No tak, tylko tutaj glowna kwestia jest taka, czy owo -- jak to nazywasz
-- zepsucie -- stanowi dla kogos jakis praktyczny problem. Mi osobiscie
podoba sie to, ze podobne koncepty znajduja wspolny wyraz.

> >> > Jezeli nie masz potrzeby robic z tego
> >> > uzytku, to mozesz ignorowac kwestie porzadku w haszach.
> >>
> >> Ale to już dawno nie jest standardowy hasz, skoro zapamiętuje kolejność
> >> wprowadzania kluczy. Z samego tego tytułu nie mogę nic powiedzieć
> >> o złożoności czasowej operacji.
> >
> > Jezeli taka duza kontrola jest Ci potrzebna, mozesz programowac w C albo C++.
>
> Albo w Erlangu. Albo w Perlu, Pythonie czy innym Rubym. Oczywiście.
> Powiem więcej: tak właśnie robię. Od PHP się trzymam z daleka z niemal
> wszystkich powodów, jakie się pojawiły w tym wątku.

Moim zdaniem robisz slusznie.

> > Ale, jak sie okazuje, w praktyce tak duza kontrola jest potrzebna w niewielu
> > procentach przypadkow.
>
> ...w niewielu procentach przypadków programistów PHP.

Tak.

> >> Sam wyciągnąłeś kwestie implementacyjne. Aktualnie sprawa wygląda tak,
> >> że PHP ssie jak odkurzacz.
> >
> > To zalezy jak na to spojrzec. Pod wieloma wzgledami odkurzacz jest lepszy
> > od miotly, a to jednak miotla wymiata.
>
> Słabe analogie są słabe. Oryginalna implementacja PHP ssie, innymi
> słowy, jest do dupy. Próba wyciągania jakiejś "miotły" z tego porównania
> to pusta demagogiczna żonglerka słowami.

Nawet nie demagogiczna, bo dokad mialaby ow demos zwiesc?
Ale w istocie, jest to najlepsze, co moglem odpowiedziec
w sytuacji, w ktorej sie znalazlem. Bo ze stwierdzenia, ze "PHP
ssie jak odkurzacz", wynika rownie niewiele. (A moja odpowiedz
jest o tyle lepsza, ze przynajmniej nikogo nie obraza)

> > Jezeli zas idzie o gadanie z sensem, to cofam to, co powiedzialem wczesniej.
> > Facebook zrobil kompilator dla PHP, nazywa sie "HipHop", i jesli ktos chce,
> > moze z niego korzystac.
>
> Ja czekam aż HHVM przestanie kompilować PHP (hacklang.org anyone?).
> Poza tym a) to żadna zasługa autorów PHP i b) nadal nie jest to
> powszechna metoda uruchamiania kodu PHP.

Jakie znaczenie ma to, czy to jest zasluga autorow PHP?

> > No ja w swojej karierze poznalem tylko jedna osobe, ktora na to narzekala,
> > i jestes nia Ty.
>
> http://me.veekun.com/blog/2012/04/09/php-a-fractal-o
f-bad-design/#arrays
> http://www.beastwithin.org/users/wwwwolf/code/phpran
t.html
>
> Naprawdę myślisz że jestem odosobnionym przypadkiem?

Nie. Ale gdybym mial zgadywac, to raczej niewielu jest uzytkownikow PHP,
ktorym owo wymieszanie by przeszkadzalo. Wiecej jest pewnie osob, ktore
narzekaja, chociaz wcale PHPa nie uzywaja.

> >> > Jezeli ktos wie, jak korzystac z haszow, poradzi osobie z tablicami PHP
> >> > Jezeli ktos wie, jak korzystac z tablic, tez sobie poradzi.
> >>
> >> Nie ma "sobie poradzić". Ma się nie potykać *niepotrzebnie* o głupoty.
> >
> > Jezeli idzie o te akurat kwestie (tzn. ujednolicenie interfejsu do tablicy
> > i do hasza), to wyraznie mozna miec na nia rozne poglady. Tak samo
> > jak na to, ze javascript utozsamia ze soba pojecie haszu i obiektu.
>
> ...co jest też uważane za głupie, o czym można poczytać w internetsach.
> Obrona słabej konstrukcji przez pokazywanie innych konstrukcji, równie
> słabych i równie mocno krytykowanych, nie jest dobrym argumentem.

To nie byla obrona. Moim celem bylo pokazanie, ze sa rozne stanowiska,
ktore maja swoich zwolennikow i przeciwnikow.

> > I wyraznie Ty i ja mamy na te kwestie odmienne poglady. Jezeli przedstawisz
> > mi przekonujace argumenty za tym, ze to PHP-owe pomieszanie jest niedobre
> > to -- zgodnie z definicja slowa "przekonujacy" -- zostane przekonany.
>
> Nie zostaniesz. Aktualnie zbyt jesteś oddany swojemu stanowisku, żeby
> przyjąć mocne, rzeczowe argumenty. To samo dotyczy mnie.

Moja edukacja oduczyla mnie przywiazywania sie do swoich stanowisk,
a nauczyla mnie bronienia stanowisk, ktorych na co dzien nie zajmuje.

Podoba mi sie to, ze Python oferuje rozdzielenie list, krotek i slownikow.
Podoba mi sie tez to, ze PHP wszystko to ze soba utozsamia. Rozwiazanie
Pythonowe jest czyste i pozwala nazywac rzeczy po imieniu. Rozwiazanie
PHP ma te wszystkie wady, ktore wymieniles, a poza tym czasem trzeba
pisac kod defensywnie, bo nie wiadomo, czy jakas funkcja zachowuje
klucze w tablicy, czy nie zachowuje (a niekiedy dzieje sie to w zaleznosci
od parametru). Tak, to sa wady.
Dla mnie idealem byloby, gdyby byl jeden interfejs, a interpreter/kompilator
sam by dobieral optymalna strukture danych na podstawie statycznej analizy
kodu.
Tak naprawde PHP obchodzi mnie niewiele, i ostatnio wiekszosc czasu
spedzam programujac w Schemie. I drazni mnie to, ze istnieje tyle
roznych sposobow na wyrazanie tej samej koncepcji (tj. asocjacji),
a nie ma zadnej notacji np. do wyrazenia haszow albo uporzadkowanych
haszow, albo zbiorow. Rowniez podzial na listy i wektory wydaje mi
sie niepotrzebny, i marzy mi sie, ze kiedys bede to w stanie wyrazac
tylko za pomoca list, i uda sie stworzyc na tyle sprytny interpreter,
ktory zapewni optymalny czas dostepu dla danego sposobu uzycia.

> Twierdzę, że w tej dyskusji żaden z nas dwóch nie przekona drugiego;
> dopiero po paru tygodniach czy miesiącach może coś z argumentów
> przesiąknie. Ale twoje argumenty opierają się o "no i co że jest
> wymieszane? to nie problem, bo można zobaczyć w X i Y dla konkretnej
> wersji, a poza tym i tak nikt tego nie potrzebuje". Mnie taka
> argumentacja nie przekonuje.

Moze tez warto miec na wzgledzie to, ze PHP to nie jest jedyny jezyk
programowania, sa inne i ta roznorodnosc jest czyms dobrym.

> > Jednak w ogolnosci zgodze sie, ze w PHP jest duzo niepotrzebnych glupot,
> > o ktore latwo sie potknac (kiedys np. potknalem sie o idiotyczne zachowanie
> > funkcji array_diff, gdy wywolac ja na tablicy tablic). Ja nie twierdze,
> > ze PHP jest jezykiem doskonalym. Ale ciesze sie, ze jest na tyle ekspresyjny,
> > ze z wieloma jego niedoskonalosciami mozna sobie poradzic -- i z tego
> > powodu staram sie oddac mu sprawiedliwosc raczej, niz do niego przyj*****c.
>
> Słaba ta ekspresywność. Naprawdę, mnóstwo języków ma lepszą. List
> comprehensions, metaklasy, spójna i konsekwentna biblioteka standardowa
> potrafiąca pracować z referencjami do funkcji (m.in. z closures),
> standardowe sposoby rozmieszczania kodu po plikach...

Zgoda. Ale dobre jest to, ze sa closures, jest niezla serializacja,
jest 'apply' (ktory PHPowi medrcy nazwali 'call_user_func_array').
A co do metaklas, to wcale nie wiem, czy to taki swietny pomysl jest.

do góry

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.

do góry

pozwole sobie na oderwaną poboczną uwage, dawno tu nie bylem i przypomnialy mi sie
stare lepsze czasy gdy bardziej zważałem na to co pisze (starajac sie lepiej dobierac
tematy), [te dawne dawne czasy przed faktem gdy ta grupa ogłupiła mnie zamieniajac
mnie w półzombie;/]

do góry

On 2014-04-09 11:08, g...@g...com wrote:
> Ja Ci nic nie kaze. To Ty mowisz, ze chcesz miec jakies gwarancje.
> Mozesz tez (jesli chcesz) napisac do tworcow PHP i zapytac, jak sie
> sprawy maja. Mozesz zatrudnic kogos, kto za Ciebie przeanalizuje
> kod PHP. Mozliwosci jest naprawde wiele.

"Dzień dobry, dzwonimy z NASA, mamy szybkie pytanko czy tablica w PHP to
ma w koncu 1 czy log N. Nie ma? A gdzie jest? Prosze powiedzieć synowi
że jak wróci z imprezy i wytrzeźwieje to żeby odpisał, mamy tu problem
na orbicie".

Jaki język takie gwarancje.

do góry

W dniu środa, 9 kwietnia 2014 17:44:12 UTC+2 użytkownik firr napisał:
> pozwole sobie na oderwaną poboczną uwage, dawno tu nie bylem i przypomnialy mi sie
stare lepsze czasy gdy bardziej zważałem na to co pisze (starajac sie lepiej dobierac
tematy), [te dawne dawne czasy przed faktem gdy ta grupa ogłupiła mnie zamieniajac
mnie w półzombie;/]

Ostatnio mialem zabawne doswiadczenie. Rozmawialem z kumplem
na gadu-gadu i doszlo do czegos takiego, ze wlasciwie bez wyraznego
powodu zaczelismy skakac sobie do gardel i sie smiertelnie na siebie
obrazac -- drobne nieporozumienia przerodzily sie w skrajnie negatywne
emocje. Jak potem spotkalismy sie twarza w twarz to momentalnie
o wszystkim zapomnielismy i juz gadalismy absolutnie normalnie i po
przyjacielsku, ale od tamtej pory zdarzylo sie nam to jeszcze
parokrotnie.

Jednak w samych slowach przenosi sie duzo mniej informacji niz
chociazby w tonie glosu czy wyrazie twarzy, i bardzo latwo zinterpretowac
komunikat jako atak i zrozumiec go niezgodnie z intencja nadawcy.
Chociaz troche mnie to dziwi, bo prowadze rozmowy w Internecie przez
pol zycia, a agresja zaczela sie w nich pojawiac dopiero od niedawna
-- konkretniej, mniej wiecej od czasu niedawnych rozmow z panem
Lewandowskim. Oczywiscie jako wolny podmiot nie moge winic ani jego,
ani grupy, jezeli zamieniam sie w polzombie. Minal juz prawie rok,
odkad skasowalem facebooka i bardzo sie z tego ciesze, bo tracilem
tam strasznie duzo czasu, ale widac sa we mnie jakies potrzeby spoleczne,
skoro zagladam tutaj. Czasem sie zastanawiam, czy nie staczam sie przez
to na dno :) i mysle sobie, ze generalnie fajnej by bylo, gdyby te
dyskusje, w ktorych uczestnicze, byly bardziej wartosciowe -- ale mimo
wszystko wierze (wbrew tym potknieciom, ktore zdarzaja sie rowniez mnie
samemu), ze praca nad poprawa kultury dyskusji moze przyniesc
jakies owoce.

do góry

W dniu środa, 9 kwietnia 2014 23:36:13 UTC+2 użytkownik g...@g...com napisał:
> W dniu środa, 9 kwietnia 2014 17:44:12 UTC+2 użytkownik firr napisał:
>
> > pozwole sobie na oderwaną poboczną uwage, dawno tu nie bylem i przypomnialy mi
sie stare lepsze czasy gdy bardziej zważałem na to co pisze (starajac sie lepiej
dobierac tematy), [te dawne dawne czasy przed faktem gdy ta grupa ogłupiła mnie
zamieniajac mnie w półzombie;/]
>
>
>
> Ostatnio mialem zabawne doswiadczenie. Rozmawialem z kumplem
>
> na gadu-gadu i doszlo do czegos takiego, ze wlasciwie bez wyraznego
>
> powodu zaczelismy skakac sobie do gardel i sie smiertelnie na siebie
>
> obrazac -- drobne nieporozumienia przerodzily sie w skrajnie negatywne
>
> emocje. Jak potem spotkalismy sie twarza w twarz to momentalnie
>
> o wszystkim zapomnielismy i juz gadalismy absolutnie normalnie i po
>
> przyjacielsku, ale od tamtej pory zdarzylo sie nam to jeszcze
>
> parokrotnie.
>
>
>
> Jednak w samych slowach przenosi sie duzo mniej informacji niz
>
> chociazby w tonie glosu czy wyrazie twarzy, i bardzo latwo zinterpretowac
>
> komunikat jako atak i zrozumiec go niezgodnie z intencja nadawcy.
>
> Chociaz troche mnie to dziwi, bo prowadze rozmowy w Internecie przez
>
> pol zycia, a agresja zaczela sie w nich pojawiac dopiero od niedawna
>
> -- konkretniej, mniej wiecej od czasu niedawnych rozmow z panem
>
> Lewandowskim. Oczywiscie jako wolny podmiot nie moge winic ani jego,
>
> ani grupy, jezeli zamieniam sie w polzombie. Minal juz prawie rok,
>
> odkad skasowalem facebooka i bardzo sie z tego ciesze, bo tracilem
>
> tam strasznie duzo czasu, ale widac sa we mnie jakies potrzeby spoleczne,
>
> skoro zagladam tutaj. Czasem sie zastanawiam, czy nie staczam sie przez
>
> to na dno :) i mysle sobie, ze generalnie fajnej by bylo, gdyby te
>
> dyskusje, w ktorych uczestnicze, byly bardziej wartosciowe -- ale mimo
>
> wszystko wierze (wbrew tym potknieciom, ktore zdarzaja sie rowniez mnie
>
> samemu), ze praca nad poprawa kultury dyskusji moze przyniesc
>
> jakies owoce.

ta grupa (tj dwie p.c.p p.c.l.c) ma swoje wady i zalety,

1) dla mnie do zalet nalezy to ze podchwytuje ona dobrze pewne powazniejsze watki (a
jak nie to przynajmniej mozn samemu do siebie popisac na temat ;o ), sporo innych
forów jest jednak zdaje sie plytsze (mniej ogolne/filozoficzne, te grupy zawsze
'dawaly rade')

do glownych wad bym zaliczyl

1) wlasnie tą ogolnosc, ostatnio czuje ze sie moze zmienilem (podejscie mi sie
zmienilo, trace chyba troche motywacje do teoretycznych ogolnych rozkminek
(jezyk w wiekszosci znam wiecmoze nie potrzebuje)
i wolalbym sie pewnie skupic na konkretnej robocie
[a nawet nie na robocie co na efekcie, nieststy to chyba tak nie działa, tracac
zainteresowanie teorią
odechciewa mi sie tej roboty wogóle (!), i teraz wogole mam kryzys ostatnio [musze
jakby coraz wiecej odpoczywac zeby coskolwiek zrobic]

2) rózna takie mega glupawe zacowania jak mowienie per misiu do rozmowcy i in (ktore
ja nazywam 'dresiarstwem') osobiscie jestem dosyc daleko
od takiego rodzaju glupoty niestety nawet jak sie od niej odcinasz to ona i tak cie
zaraza (a ja potrzebuje byc w miare mozliwosci madrzejszy a nie glupszy)

słowem obecnie jestem zagubiony i nie wiem zasadniczo 'za co sie brac'

do góry