🚀 go-pugleaf

n Tue, 4 Nov 2003 12:13:41 +0100, "Bartek Wieczorkowski"
<wieczor@c-map.pl> wrote:

>Chyba za czesto nie uzywales PHP :) 

Oj, chyba więcej niż Ty. PHP zajmuję się od wielu lat, jeszcze  czasów
wersji 3.0 i phpLib'a.

>Porzadek jest tam jak w pudeleczku

Jak się ograniczasz do paru funkcji na krzyż, to być może. :) PHP
cechuje brak konsekwencji i zła organizacja jako całości. Pod
nieobecność przestrzeni nazw, PHP jakoś usiłuje ponazywać sobie
funkcje aby w tym chaosie dojść co do czego służy. I tak główna zasada
jaką się stosuje jest nazewnictwo typu: OBIEKT_AKCJA. Np. wszystkie
funkcje do MySQL zaczynają się od mysql_, wyszystkie do MSSQL od
mssql_ itd. Jednakże w tym wszystkim brak elementarnej logiki i
spójności. Np. funkcja strip_tags() ma underscore ale już funkcja
stripslashes() - nie. Ten brak logicznej przewidywalności powoduje, ze
uczenie się wbudowanych funkcji  PHP jest bardziej czasochłonne, i że
częściej trzeba zaglądać do manuala w poszukiwaniu funkcji.
Więc, chociaż wbudowane w PHP funkcje zapewniają dużą funkcjonalnośc,
to jest trudno intuicyjnie zlokalizować funkcję potrzebną do wykonania
konkretnego zadania. Funkcje PHP nie są podzielone na pakiety ani na
moduły.  PHP nie obsłuhuje też przetrzeni nazw. Panuje tu bałagan a
nie porządek. 

Albo kwestia kodowania UTF-8. Żałosne to jest. Z tego powodu musiałem
się męczyć i pisać własne funkcje, bo te w PHP są bezużyteczne. Po co
mi funkcja utf_encode() skoro ona nie potrafi przekodowywać znaków
między cp1250, iso-8859-2 i utf-8? Python to potrafi i także znacznie
więcej, bo obsługuje też polskie ogonki do MacOS czy DOS'a. Mogę tam
łatwo sobie przekształcać znaki z wszystkiego na wszystko. Czy to ma
znaczenie praktyczne? Owszem ma, jeśli masz aplikację heterogeniczną,
która działać ma na tym samym kodzie zarówno na Linuksie/MySQL gdzie
musi obsługiwać iso-8859-2 jak i na Win32/MSSQL2K gdzie baza chodzi w
cp1250. Pisanie takich wieloplatformowych aplikacji w PHP jest
męczarnią.

>a obiektowe rzecz jasna jest. 

Nie rozśmieszaj mnie. PHP ma szczątkową obiektowość, bo ten język nie
był w ogóle od początku zaprojektowany do obsługi obiektowości.
Najlepszym dowodem jest "cieżkość" kodu napisanego w sposób obiektowy.
PHP nie przekazuje wszystkiego tak jak Python przez referencję.
Kopiuje bez sensu całą zawartość obiektu zamiast przekazać referencję.
To samo gdy chcesz obiekt przekazać jako parametr do funkcji . To
pożera pamięć i powoduje trudne do wykrycia błędy, jak coś jest nie
tak. Trzeba robić różne łamańce z operatorem referencji, aby jakoś
sobie z tym radzić. PHP nie obsługuje też destruktorów i nie potrafi
przeciążać operatorów. Śmiechu warta ta jego niby obiektowość. Dopiero
wersja 5 ma tu coś zmienić, ale na razie jest tylko niestabilna beta.

Fatalnie w PHP jest zaimplementowana obsługa wyjątków. Na tle Pythona
z definiowanymi, dziedziczonymi wyjątkami, PHP wygląda żałośnie. Brak
porządnego wizualnego debuggera i IDE do PHP też jest dotkliwy.
Próbowałem różnych programów, żaden nie jest zadowalająca. Do Pythona
istnieje wiele b. intuicyjnych i wygodnych IDE.

> hociaz byc nie musi masz wybor - chcesz;
> programujesz obiektowo, nie chcesz- nie musisz

Do małych rzeczy, pewnie. Tu PHP sprawuje się znakomicie. Zaś do
większych to nie wyobrażam sobie, aby pisać bez obiektowości. A z tym
PHP w wersji do 4.x słabo i mało wydajnie sobie radzi. Zobaczymy, co
będzie w stabilnej wersji 5.

>> większych projektów to trzeba je wspierać dodatkowymi bibiotekami typu
>> ADOdb czy Smarty, bo korzystanie z natywnym funkcji bazodanowych w PHP
>> to masochizm.
>
>Kwestia gustu. Dla mnie masochizm to ADO - wymaga co najmniej dwa razy tyle
>klepaniny zeby osiagnac ten sam efekt. Pozatym ADODB korzysta z ODBC a co to
>znaczy dla wydajnosci - latwo sprawdzic

Ty chociaż wiesz z czym polemizujesz? Ja nie piszę o microsoftowym ADO
ale o bibbiotece ADOdb (http://php.weblogs.com/ADODB). ADOdb nie
korzysta z ODBC (choć może to czynić), więc nie pisz pierdoł.  Celem
ADOdb  nie zastąpienie bibliotek PHP do połączeń z bazami danych, ale
zapewnienie jednorodnego, spójnego interfejsu funkcji dla tych
połączeń Z RÓŻNYMI bazami.  Korzystanie z natywnych funkcji PHP do
obsługi baz jest masochizmem w czystej postaci, gdyż trzeba przerabiać
kupę kodu, przy zmianie bazy. (Inna sprawa, że niektóre z tych
bibliotek można tylko wyrzucić na śmietnik. Mam na myśli bibliotekę
mssql która zwraca idiotyzmy z serwera MSSQL2K dla pól varchar o
wartości większej niż 255 znaków.) 
Oczywiście ADOdb nie jest jedynym takim rozwiązaniem. Innym jest PEAR.
Ale ADOdb jest szybsze i lepiej zaprojektowane. A PEAR został pożarty
przez nadmierne ambicje pisania obiektowego kodu  w języku który nie
jest w pełni obiektowy. Kiedyś byłem zwolennikiem PEARdb ale do ADOdb
przekonały mnie jego osiągi i możliwości. M.in. ma wbudowany własny
mechanizm cachowania zapytań SQL. B. przydatna funkcja.

>> Musiałem przejść na ADO M$, aby to obejść. Tą bibliotekę PHP można
>> wyrzucić do kosza.
>
>Ale sa inne juz poprawione

Mało mnie to pociesza w obliczu faktu, że musiałem ponad 3 dni stracić
na przebudowę kupy starego kodu PHP tak, aby działał mi z MSSQL2K, a
nie tylko z MySQL. Wsadziłem tam teraz interfejs od ADOdb, gdyby
trzeba było z tym kodem podłączać się do jeszcze innej bazy. 

>> Python (podobnie jak Perl, Java czy C++ i w przeciwieństwie do PHP)
>> językiem ogólnego zastosowania, a nie tylko językiem skryptowym do
>> stron internetowych.
>
>Podobnie jak i PHP. 

Tak? A ile znasz w PHP aplikacji ogólnego zastosowania działających
bez serwera www? 

>Tez polecam manuala. Ja w PHP pisze skrypty pod shella
>do przetwarzania danych tekstowych i sa one co najmniej dwa razy krotsze i
>bardziej czytelne niz w perlu

Krótsze od Perla? Chyba sobie żartujesz. Krócej się już nie da. :) A
co do czytelności, to chyba nie widziałeś skryptów Pythona. 

>> Poza tym Python pozwala pisać natywne aplety i
>> kod Javy (Jython) za pomocą swej składni.  Python nadaje się zarówno
>> do www jak i tworzenia samodzielnych aplikacji. Widziałeś może serwer
>> aplikacyjny działający w PHP? Bo ja nie.
>
>Co nie znaczy ze go nie ma :) 

Nie ma, bo PHP się do tego nie nadaje. PHP to dobry język do prostych
stron. Do bardziej złożonych, jego brak solidnego debuggera,
przestrzeni nazw, prawdziwej obiektowości powoduje, że pisanie i
utrzymanie kodu w PHP jest po prostu droższe od kodu w Pythonie.

>zadna nie odnosi sie do skladni 

Odnosi się pośrednio. Ty chciałeś, żeby AS miał więcej z PHP a ja,
żeby miał więcej z Pythona. A tu dyskutowaliśmy o tym, który język
jest lepiej zaprojektowany i bardziej intuicyjny. Od wielu lat zajmuję
się PHP i wiem co porównuję. Python ma lepsze narzędzia IDE,
debuggery, jest czytelniejszy, ma większe możliwości, jest szybszy,
jest bardziej uniwersalny (jego bytecode jest multiplatformowy tak jak
bytecode Javy). Ale chyba nasza dyskusja faktycznie oddala się od
tematyki tej grupy. :)

-- 
JZ ICQ:6712522