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