🚀 go-pugleaf

Dnia 31-10-2009 o 19:54:08 pakalk <pakalk@gmail.com> napisał(a):

>> Prawda, jakie to wspaniałe, że w PHP trzeba sprawdzać wartość każdej  
>> zmiennej przed jej użyciem aby uniknąć kompletnego upadku całej  
>> aplikacji?
>
> Nie no, nie kazdej. Zreszta to chyba nie nowosc, ze jezeli cos Ci moze
> zwrocic rozne wartosci to sie to testuje.

Chyba sobie żartujesz. Właśnie w tym problem, że nie zawsze wszystko  
przewidzisz. Gdyby PHP generował wyjątek, to można by to standardowo  
przechwycić w wyższej warstwie i automatycznie obsłużyć. Po prostu do dupy  
ten pehapowy design.

>> To, że to wygląda jak kupa to jedno.
>
> Jak dla mnie to ify takie kupowate nie sa :P

Tylko kto pisze w tak paranoidalny sposób testując każdą zmienną? Wyjątki  
tu dużo uproszczają.

>> To, że nie można polegać na systemie wyjątków w PHP - to drugie.
>
> Czemu nie mozna?

Tego, że nie można w prosty i spójny sposób założyć pułapki na wszelkie,  
możliwe błędy. Ani nie wychwycisz tym fatal errorów ani nie jesteś w  
stanie wyłapać tą drogą błędów z funkcji wbudowanych, bo po prostu one nie  
generują wyjątków. Niby dodali obsługę wyjątków tylko że mały z tego  
pożytek.


>> Podobnie z modelem obiektowym. Za pierwszym razem (w wypadku PHP4)  
>> wyszło im to tak nieudacznie, że ten kod nie nadawał się do dalszych  
>> poprawek.
>
> Lepiej o tym nie mowic. To byla tylko proteza.

Ta proteza pokazuje kompetencje programistycze tworców PHP.

>> Stąd model obiektowy w PHP5 został napisany od podstaw!
>
> Podobnie jak caly Zend Engine. A to zle?

Dobrze, że nie zostano przy modelu z PHP4. Źle, że musiano to robić od  
zera po raz drugi wprowadzając zamieszanie do już istniejącego bajzlu w  
PHP. I źle, że to zrobiono znowu kiepsko.

>> Niestety, drugie podejście jest też niezbyt udane, bo twórcy pehapa  
>> zapatrzyli się trochę nie w tą stronę. Statycznie typowana, z silną  
>> typizacją Java to raczej kiepski wzorzec dla obiektowości w języku  
>> dynamicznym o słabej typizacji jakim jest PHP. Java nie jest językiem  
>> czystym obiektowo (poza tym model obiektowy Javy ma sporo wad).
>
> Jak dla mnie to ten model nie jest zly. Rzeklbym, ze uznany za
> swiatowy standard.

LOL!

>> Wprowadzono do PHP zupełnie bezsensownie nieobiektowe konstrukcje w  
>> postaci metod statycznych,
>
> A to w pythonie nie ma? I dlaczego bezsensowne? Metody statyczne
> (klasowe) to standard OOP.

W Pythonie to też jest bez sensu, zgoda (w Ruby i w Scali takich głupot  
nie ma). Ale w Pythonie przynajmniej klasy są obiektami i nie trzeba w  
ogóle używać tych metod statycznych bo do niczego nie są potrzebne.  
Pythonowe ma metody klasowe.

> Interfejsy sa nieobiektowymi konstrukcjami?

Oczywiście że nie są. Już ci ktoś o tym napisał. Dodam jeszcze że  
interfejsy są głupią konstrukcją. Znacznie lepsze są miksiny (jak w Ruby)  
lub traits (jak w Scali) ktore z grubsza działają jak interfejsy z tą  
różnicą że mogą posiadać częściową implementację. Interfejsy nie mogą mieć  
żadnej implementacji. To jest ich główna wada.

>> czy głupi podział na prymitywy i obiekty.
>
> No fakt, ze latwiej ogarnac jedne typ zmiennych.

Ani nie można robić chain methods na stringach czy liczbach. Po co w  
języku dynamicznym tak niskopoziomowe struktury? Bez sensu.

>> Gdyby "miszczowie" rzucili okiem na inne języki (z tej samej bajki,  
>> czyli dynamicznie typowane) to by może uniknęli głupich decyzji  
>> projektowych. No, ale jak to się mówi do trzech razy sztuka. Może  
>> trzecie podejście, jeśli do tego dorosną, w końcu im wyjdzie i PHP  
>> zbliży się trochę do nowocześniejszych języków programowania.
>
> Tzn. pythona bez podstawowego modyfikatora protected i __protezy dla
> private? :)

Ruby i Scala mają kwalifikatory dostępu :P Co do Pythona, to już ci  
odpowiadziano, że to kwestia bardziej konwencji, a nie zabezpieczeń.  
Kwalifikatory protected i private łatwo obejść w PHP:  
http://blog.zabiello.com/2009/06/21/zabezpieczenia-protected-private-java-scala-php5.

>> Jest coraz wolniejszy w stosunku do innych języków dynamicznie  
>> typowanych.
>
> To zalezy od implementacji, ale nie znam dobrych benchamarkow.

Jakie byś nie brał, PHP jest wolny. Szczególnie silnie to widać po  
webowych frameworkach. Wszystkie są wolniejsze od dowolnego frameworka  
napisanego w Ruby (Rails, Merb, Sinatra, Ramaze, etc.) czy Pythonie  
(Django, Pylons, Tornado itp). A wspomniany wcześniej Symfony to chodzi  
zupełnie jak żółw (Cake jest jeszcze wolniejszy!). Zresztą nic dziwnego.  
To wynika z pehapowej specyfiki pracy w stylu cgi. Żaden akcelerator nie  
zmieni tego, że PHP niszczy i tworzy na nowo obiekty przy każdym  
requeście, a to kosztuje. Możnaby spróbować pisać w PHP w stylu  
serwletowym, gdyby miał dobrą wielowątkowość i przede wszystkim wydajny  
garbage collector. Niestey, nie ma tego pierwszego, a to drugie jest  
kompletnie niedopracowane. Stąd im większy kod tym PHP bardziej odstaje  
wydajnościwo w stosunku do framworków pracujących serwletowo.

>> Poza tym, przy pehapie tkwi dużo osób którzy w ogromnej większości  
>> prezentują bardzo niski poziom wiedzy na temat sztuki programowania. A  
>> każdy kto trochę więcej się podszkoli, szybko zaczyna tracić pierwotny  
>> entuzjazm fanboja i kieruje się do Pythona lub Ruby.
>
> Ci, ktorzy sie podszkola wola jave.

Tylko skąd się bierze tyle konwertytów Javy do Ruby/JRuby? :) Java jest  
językiem przestarzałym i ograniczonym. Ale ma dobrego Hotspota i kupę  
ciekawszych języków zgodnych z JVM.

>> To prawda, że wciąż łatwiej znaleźć programistę PHP niż Ruby czy  
>> Pythona. Jednak w tym wypadku ilość nie oznacza jakości.
>>
>
> Co tez nie znaczy, ze dobrych programistow PHP jest mniej niz Pythona
> czy Ruby.

Myślę, że jest nawet mniej. Mało który dobry programista zostaje przy PHP.  
Zresztą, nowoczesny programista musi być poliglotą, znać więcej niż jeden  
język programowania. Takie czasy. A jak raz poznasz jakiś lepszy, to nie  
będziesz chciał używać gorszego. Proste i logiczne. Ja np. używam PHP  
tylko wtedy, kiedy muszę. Kiedy nie muszę, używam głównie JRuby. Prościej,  
szybciej i wygodniej.

-- 
JZ http://blog.zabiello.com