On 2014-03-30 20:40, Wojciech Muła wrote:
> Sam zacząłeś od wymyślonego przykładu z jakimś grafikiem dla sprzątaczek.
> Podałem Ci, jaki napotkasz problem *alogrytmiczny*, nawet w tak pozornie
> prostym zastosowaniu.

No i dlatego dalej pytam: w zym PHP jest lepszy aby ten problem rozwiązać?

>> Własnie zauważyleś za złożone problemy nie mają uniwersalnych rozwiązń.
> To nie jest trudny problem, już sama klasa złożoności czasowej powinna
> sugerować, jakie jest rozwiązanie. Da się rozwiązać bez boosta,
> bez żadnej biblioteki, nawet w PHP-pie, czy javascripcie.

I znowu to samo: kazdy język programowania pozwala na rozwiązanie
dowolnego problemu rozwiązywalnego w innym. Thak You Captain Obvious.

>> A w wątku rzecz w tym że PHP nie ma żadnych rozwiązań w standardzie,
>> nawet uniwersalnych. NAWET.
> W tym wątku była mowa, że programista PHP nic nie musi umieć.

Ja nie rozmawiam o umiejętnościach programistów tylko zadaje proste
pytanie: co ma PHP co spowodowało że bank wybrał go do jakiegoś tam
zadania w środku które było skomplikowane albo obliczeniowo albo
algorytmicznie? Co ma PHP czego nie ma <cokolwiek>?

>> A czemu nie ma? I dlaczego powinienem workaroundowac problemy braku
>> czegoś w designie tandemu apache/php/mysql?
> Bo HTTP to protokół bezstanowy.

No właśnie, workaround z ciasteczkami to "załatwia" w typowy dla PHP sposób.

> Nie ma znaczenia, czy na końcu jest PHP,
> Python, skrypt shellowy CGI, itd. - będzie dokładnie ten sam problem.

Nie. Problemem PHP jest serializacja stanu (albo w ciasteczka albo w
db). Jeśli PHP miałby *żywy* kontekst po stronie serwera wiele rzeczy
nie wymagało by serializacji.

>> A kto tu twierdzi że C++ jest jakimś wzorcem?
> Jako język wieloparadygmatowy

Inne paradygmanty stosuje się za pomocą metaprogramowania albo
bibliotek. IMHO nie jest wieloparadygmatowy nawet przy bardzo
optymistycznym podejściu.

>, przemysłowy, z wieloletnią historią
> i ciągle rozwijający się -- to dobre odniesienie do innych języków.

A fuj. To pokraczny język, który na prostowanie jest za stary.

>>>> Oni też potrafili się wykłucać że uniwersalny kontener na wszystko
>>>> jest lepszy niż specjalizowane o znanych złożonościach "bo kto
>>>> obrabia więcej niż 200 wpisów".
>>> Akurat dość rozsądny argument. Przywołaj proszę jakiś mniej sensowny.
>> Powiedz że żartujesz... to idealnie pasuje do profesjonalnego systemu
>> zarządzania windykacjami w banku.
> No jeżeli rzeczywiście nie obrabia się więcej niż "200 wpisów"

Czyli jednak dyżury sprzataczek w tym banku zrobili?

, nie
> ma się specjalnych wymogów (czas, czy pamięć), to te uniwersalne są
> lepsze.

Bo programista nie wie czym się rózni lista od wektora? A no to są
lepsze, faktycznie.

> A nawet są lepsze w tym sensie, że już działają i ktoś je
> przetestował.

:D PHP i testowanie :)

> Ale oczywiście zgadzam się, że jeśli są szczególne
> potrzeby, to trwanie przy uniwersalnych rozwiązaniach nie jest dobre.

Ależ uniwersalne kontenery nie są *trywialne*. Nic zazwyczaj nie
gwarantują poza tym że hello world zadziała. Czyli masz śmieciowy język
ktory w poważnych zastosowaniach odpada na starcie bo ma tajemnicze
uniwersalne implementacje o których niewiele wiadomo poza tym że dają
radę dla 200 wpisów.

>> Ale jak ja mam mieć dłuższą przygode? Sugerujesz że mam się umartwiać
>> nad PHP i dopiero dostrzegać błedy po 10 latach? Miej że litość, życie
>> jest za krotkie na babranie się w g...
> Nic nie musisz, tylko wydawanie kategorycznych sądów o teraźniejszości
> na podstawie doświadczeń sprzed kilku lat jest trochę bez sensu.

Jesli w ciagu kilku lat PHP zmienil się nie do poznania to nie jest PHP
tylko coś innego. Zmienił się?

>> Ustawienia phpini w apache mają wpływ na runtime PHP. Jak chcesz różne
>> to ... no cóż ...
> To są ustawienia serwera, a nie przeglądarki. Pomieszałeś. :)

Nie pomieszałem.

>>> Sorry, ale nie dostaniesz dostępu do bankowego intranetu. Ja też już
>>> nie mam szans, więc nie zadowolę nikogo w tym wątku.
>> Znaczy że były tam te krzywe rownania
> Były.

I 200 wpisów w bazie danych?

>> czy nie było i mowisz o jeszcze jednym z miliona widoku na bazę danych?
> A to też było, nie przeczę.

Dalej nie wiem co kogo podkusiło że PHP nadaje się do obrabiania równań
nieliniowych w systemie bankowym. Tym bardziej że większe obliczenia
powodują że PHP umiera. Gdzieś kiedyś czytałem że PHP obok TCL to dwa
najgorsze języki do obliczeń - bo wolne.

Tam musi być drugie dno, w tym banku. Mam ciągle nadzieję że to nie jest
"student za tysiaka da radę" ani też "nie mam czsu, muszę jechać beemką
na myjnię, a ten projekt to napiszcie w byle czym".

do góry

On 30/03/2014 20:08, Sebastian Biały wrote:
> On 2014-03-30 20:40, Wojciech Muła wrote:
>
>>> A kto tu twierdzi że C++ jest jakimś wzorcem?
>> Jako język wieloparadygmatowy
>
> Inne paradygmanty stosuje się za pomocą metaprogramowania albo
> bibliotek. IMHO nie jest wieloparadygmatowy nawet przy bardzo
> optymistycznym podejściu.

Przy optymistycznym podejściu to wspiera przynajmniej programowanie
proceduralne i obiektowe w stylu Simuli.

Również, przynajmnije przy optymistycznym podejściu,
wieloparadygmatowość nie oznacza dobrego wsparcia do pisania w jednym z
kilku paradygmatów, tylko że idiomatyczny styl danego języka jest
mieszanką kilku paradygmatów.

>> , przemysłowy, z wieloletnią historią
>> i ciągle rozwijający się -- to dobre odniesienie do innych języków.
>
> A fuj. To pokraczny język, który na prostowanie jest za stary.

Tak i być może, ale nic lepszego nie ma.

do góry

On Sunday, March 30, 2014 9:08:08 PM UTC+2, Sebastian Biały wrote:
> On 2014-03-30 20:40, Wojciech Muła wrote:
> > Sam zacząłeś od wymyślonego przykładu z jakimś grafikiem dla sprzątaczek.
> > Podałem Ci, jaki napotkasz problem *alogrytmiczny*, nawet w tak pozornie
> > prostym zastosowaniu.
>
> No i dlatego dalej pytam: w zym PHP jest lepszy aby ten problem rozwiązać?

W niczym. Przecież dyskusja nie jest o tym, w czym PHP jest lepszy.

> > W tym wątku była mowa, że programista PHP nic nie musi umieć.
>
> Ja nie rozmawiam o umiejętnościach programistów tylko zadaje proste
> pytanie: co ma PHP co spowodowało że bank wybrał go do jakiegoś tam
> zadania w środku które było skomplikowane albo obliczeniowo albo
> algorytmicznie? Co ma PHP czego nie ma <cokolwiek>?

Nic nie ma nic wyjątkowego, po prostu jest i można z niego korzystać.

> > Bo HTTP to protokół bezstanowy.
>
> No właśnie, workaround z ciasteczkami to "załatwia" w typowy dla PHP sposób.

Ale tak załatwia się sesje *wszędzie*, w każdym języku.

> > Nie ma znaczenia, czy na końcu jest PHP,
>
> > Python, skrypt shellowy CGI, itd. - będzie dokładnie ten sam problem.
>
> Nie. Problemem PHP jest serializacja stanu (albo w ciasteczka albo w
> db).

Kompletna bzdura. W ciasteczkach zapisuje się id sesji. Po stronie serwera
zapisuje i odczytuje się dane wg id. A ten zapis może być w bazie danych,
w pliku, albo pamięci.

> Jeśli PHP miałby *żywy* kontekst po stronie serwera wiele rzeczy
> nie wymagało by serializacji.

To jest niemożliwe ze względu na to, jak działa *protokół* HTTP.

> > A nawet są lepsze w tym sensie, że już działają i ktoś je
> > przetestował.
>
> :D PHP i testowanie :)

"LOL, haha, testy", nudny jesteś. Tak, testy jednostkowe,
funkcjonalne, integracyjne. Oczywiście automatyczne, uściślę
żebyś się nie czepiał.

> Jesli w ciagu kilku lat PHP zmienil się nie do poznania to nie jest PHP
> tylko coś innego. Zmienił się?

A sprawdź sobie.

> Dalej nie wiem co kogo podkusiło że PHP nadaje się do obrabiania równań
> nieliniowych w systemie bankowym.

Fascynujące jest to, że wszyscy się tak podjarali obliczeniami, a nikt
nie zwrócił uwagi na cykle w grafach.

> Tym bardziej że większe obliczenia powodują że PHP umiera. Gdzieś kiedyś
> czytałem że PHP obok TCL to dwa najgorsze języki do obliczeń - bo wolne.

Fatalne w obliczeniach są też: python, javascript, awk i bash.

> Tam musi być drugie dno, w tym banku. Mam ciągle nadzieję że to nie jest
> "student za tysiaka da radę" ani też "nie mam czsu, muszę jechać beemką
> na myjnię, a ten projekt to napiszcie w byle czym".

Problemem tej dyskusji jest to, że często dyskutujesz z wymyślonymi przez
siebie faktami.

w.

do góry

Witam, dnia Sat, 5 Apr 2014 08:02:57 -0700 (PDT)
Wojciech Muła <w...@g...com> napisał:

> > Nie. Problemem PHP jest serializacja stanu (albo w ciasteczka albo
> > w db).
>
> Kompletna bzdura. W ciasteczkach zapisuje się id sesji. Po stronie
> serwera zapisuje i odczytuje się dane wg id. A ten zapis może być w
> bazie danych, w pliku, albo pamięci.

No to jak będzie w pamięci...

> > Jeśli PHP miałby *żywy* kontekst po stronie serwera wiele rzeczy
> > nie wymagało by serializacji.
>
> To jest niemożliwe ze względu na to, jak działa *protokół* HTTP.

...to gdzie widzisz serializację? Protokół HTTP nie ma tutaj znaczenia,
to jest ograniczenie PHPa.



--
Tomek

do góry

W dniu wtorek, 8 kwietnia 2014 19:25:18 UTC+2 użytkownik Tomasz Sowa napisał:
> > > Jeśli PHP miałby *żywy* kontekst po stronie serwera wiele rzeczy
> > > nie wymagało by serializacji.
> >
> > To jest niemożliwe ze względu na to, jak działa *protokół* HTTP.
>
> ...to gdzie widzisz serializację? Protokół HTTP nie ma tutaj znaczenia,
> to jest ograniczenie PHPa.

Chyba czegos tu nie rozumiem.
PHP to "normalny", pelny jezyk programowania, i nie ma zadnych ograniczen
w rodzaju tych, o ktorych piszesz. To, ze po stronie serwera nie ma "zywego"
kontekstu, nie wynika w zaden sposob z jezyka, tylko ze sposobu, w jaki
jezyk jest uzywany, tzn. w tym konkretnym przypadku jako plugin do apache'a,
ktory wywoluje skrypty dla poszczegolnych zapytan HTTP. Ale nic nie stoi
na przeszkodzie (moze z wyjatkiem marnej obslugi wielowatkowosci) zeby
napisac wlasny PHPowy serwer korzystajacy z gniazd BSD i przechowujacy
stan miedzy polaczeniami.

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)

Chyba ze cos zle zrozumialem

do góry

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 powinna byc mozliwosc uzyskania stosunkowo naturalnego
dostepu bez koniecznosci serializacji (chociaz zrobienie tego porzadnie,
tzn. tak, zeby dalo sie uzywac wspoldzielonych zmiennych PHPowych
w sposob naturalny, faktycznie wymagalaby zejscia na niski poziom i
wprowadzenia zmian do samego jezyka)

do góry

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

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

Naprawdę, to nie jest stanowisko, którego może bronić osoba pisząca
jakiekolwiek programy.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Tuesday, April 8, 2014 7:25:18 PM UTC+2, Tomasz Sowa wrote:
> Witam, dnia Sat, 5 Apr 2014 08:02:57 -0700 (PDT)
>
> Wojciech Muła <w...@g...com> napisał:
> No to jak będzie w pamięci...

APC i okolice, czyli pamięć dzielona.

> > To jest niemożliwe ze względu na to, jak działa *protokół* HTTP.
>
> ...to gdzie widzisz serializację? Protokół HTTP nie ma tutaj znaczenia,
> to jest ograniczenie PHPa.

To chyba się zgubiłem, bo mowa była o "żywym" kontekście.

w.

do góry

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. Bo na chwile obecna, jezeli nawet
moje argumenty sa slabe, to Twoich nie ma wcale.

Oczywiscie, mozna dyskutowac nad tym, czy korzystanie z pamieci wspoldzielonej
w ogole to dobry pomysl. Ale to juz nie jest kwestia dotyczaca PHPa, 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.

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

Albo skrypty CLI? (I tutaj ciekawostka: obsluga sygnalow uniksowych
w PHP jest zrobiona calkiem 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.

> 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.
Zas co do rzeczy, ktore ktos juz kiedys robil, to coz -- one sa juz
zrobione.

> 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?
Ze zamiast narzekac, ze cos jest marne, mozna to poprawic, albo przynajmniej
zaproponowac autorowi, jak mozna by to poprawic?

Rzeczywiscie, pewnie dla osob przyzwyczajonych do korzystania z narzedzi
microsoftu takie stanowisko musi tracic egzotyka. Ale cale oprogramowanie
open source rozwija sie wlasnie w taki sposob.

do góry

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

> >> > 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".
A jezeli chcesz wiedziec, ze system nie kleknie przy wzroscie ilosci
danych, to niezaleznie od uzytego jezyka powinienes napisac testy
obciazeniowe.

> > 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 jesli naprawde Cie to boli, to czasy dostepow do tablic mozesz sobie
pomierzyc.

> >> >> Czy tak tylko zmyślasz na temat gwarancji złożoności w PHP?
> >> >
> >> > Faktycznie w dokumentacji tego nie ma, i nie sadze, zeby PHP dawal
> >> > gwarancje. (Jak stanowi licencja, THIS SOFTWARE IS PROVIDED
> >> > BY THE PHP DEVELOPMENT TEAM ``AS IS'' AND ANY EXPRESSED OR
> >> > IMPLIED WARRANTIES). Ale z tego co czytalem, to w praktyce
> >> > tak wlasnie jest implementowane, co szybki risercz wydaje
> >> > sie potwierdzac:
> >>
> >> > http://stackoverflow.com/questions/2350361/how-is-th
e-php-array-implemented-on-the-c-level
> >>
> >> Czyli chcesz powiedzieć, że mam się oprzeć o nieudokumentowane
> >> zachowanie, które może się zmienić między patchlevelami? Naprawdę tak
> >> uważasz? W swoim własnym kodzie tak robisz?
> >
> > To zalezy, jaki problem chce rozwiazac. Ale jezeli tak niepokoi Cie kwestia
> > gwarancji, to:
> > 1) zrodla PHPa sa dostepne, mozna sobie poczytac
> > 2) nie musisz robic update'u do nowszej wersji, jezeli mialyby z tego
> > wynikac jakies problemy
>
> 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.
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.

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

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

> > 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++.
Ale, jak sie okazuje, w praktyce tak duza kontrola jest potrzebna w niewielu
procentach przypadkow.

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

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

> > 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.
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.
Ale na razie nasza dyskusja przypomina te o wyzszosci lodow waniliowych
nad czekoladowymi (albo na odwrot).

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.

do góry