On 2014-03-26, g...@g...com <g...@g...com> wrote:
>> > PHP powstal jako jezyk do tworzenia
>> > licznikow na stronach domowych, i trzeba mu przyznac, ze zaszedl daleko.
>> > Jednak wspolczesnie fakt, ze rzeczy zaawansowanych nie pisze sie w PHP,
>> > nie wynika juz z semantycznych niedostatkow tego jezyka, tylko z (w pelni
>> > zasluzonej) marnej reputacji PHP.
>>
>> ...która wynia w dużej części właśnie z semantycznych niedostatków.
>
> Historycznie. Wiele z tych niedostatkow zostalo juz poprawionych,

...w ciągu ostatnich czterech-sześciu lat, czyli już dawno po
terminie...

>> >> A coś, co potrafi podobne rzeczy do lispowych makr (manipulację drzewem
>> >> wyprowadzenia) występuje w całkiem sporej liczbie języków, od Pythona
>> >> zaczynając.
>> >
>> > Moglbys powiedziec cos wiecej na ten temat? Ew. rzucic jakims linkiem?
>> > (Jedyny jezyk z nielispowa skladnia, o jakim slyszalem, ze ma lispowe
>> > makra, to ruby-podobny jezyk o nazwie elixir)
>>
>> Uwaga: nie chodzi o makra w stylu Lispa, czyli coś, co się wywołuje jak
>> funkcję. Chodzi o manipulację drzewem wyprowadzenia danego języka
>> z możliwością wykonania takiego drzewa, ale nie musi to wyglądać jak
>> w Lispie.
>>
>> W Pythonie do tego służą moduły parser i ast. W Erlangu jest to zrobione
>> bardziej elegancko (parse_transform), bo tam proces kompilacji występuje
>> jawnie, więc można się w niego wpiąć.
>
> No to prawie jak w lispie :]

Dość blisko. Dokładnie lispowych nie będzie, bo prawie żadnego języka
się nie zapisuje jako drzewa wyprowadzenia, jak Lispa.

>> >> > Dlaczego glupio pomieszane? Jest jeden prosty interfejs i bardzo
>> >> > potezna struktura danych, ktora daje ci to, czego od niej oczekujesz.
>> >>
>> >> ...gwarancje czasowe?
>> >
>> > Jezeli piszesz "time-critical application", to zgadzam sie, ze PHP
>> > to zly wybor. Podobnie jak wybor wiekszosci innych jezykow dynamicznych
>> > oraz wszystkich jezykow z garbage collectorem.
>>
>> Ależ nie chodzi o aplikacje krytyczne czasowo. Chodzi o bardziej
>> elementarną rzecz: przewidywalne zachowanie w przypadku wzrostu ilości
>> danych. Nie chcę żeby nagle się okazało, że mój program *wyglądający*
>> jak mogący sobie poradzić z danymi osiem razy większymi w czasie jedynie
>> osiem razy dłuższym kończy pracę w czasie czterysta razy dłuższym.
>
> 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)).

>> >> A pomieszane głupio, bo nie potrzebuję indeksować tablicy stringami.
>> >> Potrzebuję mieć gwarancję dostępu w czasie O(1). Jak będę potrzebował
>> >> indeksowanie stringami, to sobie użyję hasza i będę wiedział, jakie on
>> >> daje gwarancje na operacje.
>> >
>> > Jezeli nie potrzebujesz indeksowac tablicy stringami, to nie musisz
>> > tego robic. Jezeli korzysasz ze spojnych kluczy numerycznych od 0, to
>> > bedziesz mial normalna tablice numeryczna z dostepem w czasie O(1)
>>
>> A gdzie są te gwarancje zapisane? W dokumentacji nie pamiętam żeby były.
>>
>> 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?

>> >> Tablice w PHP to jakby ktoś wymieszał B-drzewa z wyrażeniami
>> >> regularnymi. Można to trzymać razem, ale kto przy zdrowych zmysłach
>> >> potrzebuje takiej konstrukcji?
>> >
>> > Nie wiem, jaki jest zwiazek B-drzew z wyrazeniami regularnymi.
>> > Tablice php-owe opieraja sie na spostrzeniu, ze sekwencje rowniez
>> > stanowia forme asocjacji.
>>
>> Co nie znaczy, że to dobry pomysł mieszać haszmapy z tablicami, bo te
>> struktury mają różne zastosowanie, różną budowę i różnie się zachowują
>> przy większości operacji.
>
> Maja taki sam interfejs.

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

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

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

--
Secunia non olet.
Stanislaw Klekot