W dniu środa, 26 marca 2014 13:19:12 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
> On 2014-03-25, g...@g...com <g...@g...com> wrote:
> >> Owszem, trudno znaleźć język bardziej popularny od PHP. Ale znowu: ile
> >> się pisze rzeczy *zaawansowanych* w PHP? Mimo jego popularności, prawie
> >> nic.
> >
> > Znaj proporcje, mocium panie. 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,
chociaz wyglada na to, ze wlasnie z powodu historycznych nalecialosci
PHP nigdy nie zostanie naprawde porzadnym jezykiem (chociaz kto wie)

> >> 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 :]

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

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

> >> 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.
Bystry kompilator moglby sam wpasc na to, kiedy uzyc jakiej struktury
danych. 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.