W dniu środa, 9 kwietnia 2014 13:03:49 UTC+2 użytkownik Stachu 'Dozzie' K. napisał:
> > 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.

Niemniej, jezeli jakies rozwiazanie mialoby dawac wyrazna przewage
nad konkurencja, to to by byl dobry powod, zeby wyprzec te konkurencje
z rynku. Tak sie przynajmniej zdaje.

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

Punkt dla Ciebie.

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

Wyznawca? Wydaje mi sie, ze podejscie "jezeli chcesz cos wiedziec,
to to sprawdz" jest calkiem zdroworosadkowe.

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

Zgodze sie, ze pisanie dobrych testow nie jest banalna sprawa

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

OK

> Jeśli system jest źle napisany (używa niewłaściwych struktur i/lub ma
> złą architekturę), to żadne strojenie nie pomoże.

Zgoda

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

Jezeli raz opracujesz framework do pomiarow, to po aktualizacji mozesz
go uruchomic jeszcze raz.

> Czy ty pisałeś kiedyś cokolwiek innego niż programy na studia?

Owszem. A co mialoby to miec do rzeczy?

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

W porzadku. Przynajmniej wiadomo, jak sie sprawy maja

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

Moze jak napiszesz do tworcow PHP, to sie zobowiaza.

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

No tak, tylko tutaj glowna kwestia jest taka, czy owo -- jak to nazywasz
-- zepsucie -- stanowi dla kogos jakis praktyczny problem. Mi osobiscie
podoba sie to, ze podobne koncepty znajduja wspolny wyraz.

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

Moim zdaniem robisz slusznie.

> > Ale, jak sie okazuje, w praktyce tak duza kontrola jest potrzebna w niewielu
> > procentach przypadkow.
>
> ...w niewielu procentach przypadków programistów PHP.

Tak.

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

Nawet nie demagogiczna, bo dokad mialaby ow demos zwiesc?
Ale w istocie, jest to najlepsze, co moglem odpowiedziec
w sytuacji, w ktorej sie znalazlem. Bo ze stwierdzenia, ze "PHP
ssie jak odkurzacz", wynika rownie niewiele. (A moja odpowiedz
jest o tyle lepsza, ze przynajmniej nikogo nie obraza)

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

Jakie znaczenie ma to, czy to jest zasluga autorow PHP?

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

Nie. Ale gdybym mial zgadywac, to raczej niewielu jest uzytkownikow PHP,
ktorym owo wymieszanie by przeszkadzalo. Wiecej jest pewnie osob, ktore
narzekaja, chociaz wcale PHPa nie uzywaja.

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

To nie byla obrona. Moim celem bylo pokazanie, ze sa rozne stanowiska,
ktore maja swoich zwolennikow i przeciwnikow.

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

Moja edukacja oduczyla mnie przywiazywania sie do swoich stanowisk,
a nauczyla mnie bronienia stanowisk, ktorych na co dzien nie zajmuje.

Podoba mi sie to, ze Python oferuje rozdzielenie list, krotek i slownikow.
Podoba mi sie tez to, ze PHP wszystko to ze soba utozsamia. Rozwiazanie
Pythonowe jest czyste i pozwala nazywac rzeczy po imieniu. Rozwiazanie
PHP ma te wszystkie wady, ktore wymieniles, a poza tym czasem trzeba
pisac kod defensywnie, bo nie wiadomo, czy jakas funkcja zachowuje
klucze w tablicy, czy nie zachowuje (a niekiedy dzieje sie to w zaleznosci
od parametru). Tak, to sa wady.
Dla mnie idealem byloby, gdyby byl jeden interfejs, a interpreter/kompilator
sam by dobieral optymalna strukture danych na podstawie statycznej analizy
kodu.
Tak naprawde PHP obchodzi mnie niewiele, i ostatnio wiekszosc czasu
spedzam programujac w Schemie. I drazni mnie to, ze istnieje tyle
roznych sposobow na wyrazanie tej samej koncepcji (tj. asocjacji),
a nie ma zadnej notacji np. do wyrazenia haszow albo uporzadkowanych
haszow, albo zbiorow. Rowniez podzial na listy i wektory wydaje mi
sie niepotrzebny, i marzy mi sie, ze kiedys bede to w stanie wyrazac
tylko za pomoca list, i uda sie stworzyc na tyle sprytny interpreter,
ktory zapewni optymalny czas dostepu dla danego sposobu uzycia.

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

Moze tez warto miec na wzgledzie to, ze PHP to nie jest jedyny jezyk
programowania, sa inne i ta roznorodnosc jest czyms dobrym.

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

Zgoda. Ale dobre jest to, ze sa closures, jest niezla serializacja,
jest 'apply' (ktory PHPowi medrcy nazwali 'call_user_func_array').
A co do metaklas, to wcale nie wiem, czy to taki swietny pomysl jest.