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