yanoo.pl

Zawsze mam problem, kiedy ktoś mnie pyta “dlaczego właściwie to php jest takie złe? argumenty proszę!”. Mój problem polega na tym, że niespecjalnie potrafię swoją intuicję ubrać w odpowiednie słowa, by odpowiedzieć na takie pytanie w zadowalający obie strony sposób.

Problem niejako rozwiązał się sam dzięki wpisowi Jarosława Zabiełło na forum polskiej społeczności php, pod którym podpisuję się ręcyma i nogyma. Jeśli chcesz zatem wiedzieć dlaczego php to zło – przeczytaj ten tekst.

Siedząc na blipie zauważyłem, że wciąż bardzo wiele osób zaczyna swoją przygodę z programowaniem od języka PHP. Przerażające przy tym, jak wielu z nich (jeśli nie wszyscy) nie lubi dokumentacji; zadają masę pytań, których rozwiązanie można znaleźć po jednym rzucie oka na definicję funkcji. Podobnie z googlem – przerażająca ilość przyszłych “developerów” zamiast spytać wielkiego brata, truje dupę innym tym samym pytaniem, które wcześniej zadano miliony razy i 10 razy tyle padło odpowiedzi.

Jeśli już jednak, drogi czytelniku, postanowiłeś zacząć naukę PHP, oto garść rad ode mnie:

1. Nie ucz się programowania w ogóle. Serio. Nie będzie z ciebie żaden programista, co najwyżej masę kwiatków światu po sobie zostawisz.
2. Sięgnij po Pythona, albo Ruby’ego. Są łatwiejsze (serio!), przyjemniejsze (o wiele!), doskonalsze (o co nietrudno), a co najważniejsze łatwiej się w nich nauczyć dobrych praktyk i ominąć te złe.
3. PHP ma chorą składnię, jest zacofany (nie ratują go nawet nowości w 5.3, którego jeszcze nikt nie używa), a swoją pobłażliwością zachęca początkujących do popełniania błędów. Znam odważnych, którzy uważają, że “warningi” to nic złego, wystarczy wyłączyć ich wyświetlanie. PHP jest też wolne. Straaasznie wolne.
4. Jeśli wciąż nie zrezygnowałeś to przedstawię zalety: gigantyczna ilość materiałów w sieci oraz dostępność na serwerach, która też działa w drugą stronę, tj. “serwer uruchamia php, więc nauczę się php.” Tylko po co się cofać? Dzisiaj naprawdę można znaleźć dość tanie serwery obsługujące Pythona i/lub Ruby’ego.
5. Wciąż chcesz się uczyć PHP? Zacznij więc z grubej rury – od Symfony. Przejdź adventa od deski do deski. Nauczysz się przy tym (jak szczęście dopomoże) jako-tako organizacji kodu, popełnisz tysiące błędów i napotkasz drugie tyle problemów, które i tak prędzej czy później byś spotkał. Jak ogarniesz tę lekcję i wciąż nie zmądrzejesz to naucz się Zend Frameworka. Zend wymusza od programisty by zrobił więcej i więcej wiedział.
6. Za dwa lata, kiedy świat w końcu zrozumie, że może żyć bez PHP, Ty drogi użytkowniku powinieneś być już całkiem sprawnym programistą tego języka, modlącym się o więcej zmian w wersji 6.0.
7. Czytaj mądrzejszych od siebie: Fabien Potencier, Burak, Akra, Matthew Weier, Jari Hartikainen.
8. A najlepiej przemyśl jeszcze raz, czy programowanie w PHP to aby na pewno dobry pomysł.

S(z)marty wyrobiły we mnie odrazę do systemu szablonów – po stokroć wolałem wbudowane we frameworki pseudo systemy, które polegają na wymieszaniu prościutkiego do bólu php¹ z htmlem. Niby mamy zupę, ale w zasadzie oddzielamy prezentację od treści – w szablonach jedynie wyświetlamy dynamiczne wartości, zero obróbki².

Wiedziałem jednak, że takie rozwiązanie ma swoje wady i są lepsze, ale jakoś nie potrafiłem się zmotywować, żeby w końcu wypróbować PHPTAL. W końcu jednak nadeszło nie ma zmiłuj się i wypróbowałem. Powiem krótko: mniam!!

• błyskawicznie można się tego nauczyć – trzy, cztery godzinki i trzaskasz szablony, jakbyś od małego tego używał
• banalna integracja
• kooooooooooooooooooooooooooooooooooooooooooooood!!!

Gotowe szablony można odpalić na lokalu w przeglądarce. Bez wykorzystania php (!!). Specyficzna konstrukcja tagów sprawia, że możemy wewnątrz szablonów przygotowywać od razu przykładowe dane, które wyświetlą się tylko i wyłącznie, gdy szablon nie zostanie przepuszczony przez interpreter PHPTALa. Sam kod jest tak samo czytelny jak czysty XHTML – zero spaghetti! Jedyne co mamy nadmiarowe w stosunku do czystego HTMLa to dodatkowe atrybuty tu i ówdzie. Polecam!

Wady? Przydałoby się coś w rodzaju frameworkowych action(‘akcja’, array(‘zmienna1′, ‘zmienna2′…)) – trzeba się nieco nagłowić, żeby się tak odwoływać. Dla Zenda najprostsze rozwiązanie jakie mi do tej pory przyszło na myśl to:

<div tal:content="structure php:
this.action('akcja',
               'kontroler',
               'moduł',
               array('zmienna1' => 'wartość1'))">
Tu będzie jakaś treść podmieniona przez naszą akcję
</div>

Chociaż oczywiście może istnieć jakieś ładniejsze rozwiązanie

1. echo, echo, echo, plus if else oraz foreach; no i helpery [↩]
2. w teorii, bo w praktyce to każdy robi co chce i uważa za najlepsze [↩]

Siłą każdego języka jest jego społeczność, a nie sam język. Taki php, choć u podstaw był niezwykle ubogim językiem (a wg wielu wciąż jest), to szybko zyskał sympatię tysięcy wannabe programistów, wśród których znalazło się paru twórców przyszłych aplikacji, na których oparła się spora część dzisiejszego internetu – żeby wymienić tylko phpBB, wordpress i niezliczone zastępy CMS-ów.

Przez długi okres czasu wydawało się wszystkim, że jak aplikacja webowa, to tylko php. Owszem – był perl (tylko weź w tym pisz…), asp.net, czy java – ale ludzie albo tych rozwiązań nie znali, albo jak już znali, to na przeszkodzie stawał problem z serwerem (a raczej jego brakiem), który by wspierał inną niż php technologię, czy też wspomniana społeczność – w tym przypadku mikra.

Nagle jakby znikąd pojawił się język Ruby ze swoim Ruby on Rails – fenomen, który odmienił dzisiejszy internet. Framework, który zapoczątkował wielki boom na wzorzec MVC i obiektowe tworzenie stron. Genialność tego rozwiązania, która pozwalała w ekspresowym tempie tworzyć nowe aplikacje, sprawiła, że ludzie masowo dopadli Railsy, Django, Pylonsy i inne podobne frameworki, które pokazały światu, że web to nie musi być tylko php, ale też inne języki – jak wspomniane Ruby, czy bardzo popularny na świecie Python.

A jak w tym całym zamieszaniu zachowuje się nasz główny bohater? Okazuje się, że tylko na tym skorzystał kopiując rozwiązania z wspomnianych produktów. Dziś mamy dostępne dwa główne projekty, które sprawiają, że php wciąż pozostaje atrakcyjnym językiem – mowa o Symfony oraz Zend Frameworku. Choć to oczywiście nie wszystkie rozwiązania, niemniej pozwolę sobie skupić jedynie uwagę na tych dwóch. Raz, że oprócz nich miałem do czynienia jedynie z Code Igniterem, który przypomina ubogiego brata ZF, dwa, że to chyba najlepsze dziś produkty tego typu.

Oba frameworki prezentują zupełnie inne podejście do tematu – ZF to zbiór niezależnych klas (w tym abstrakcyjnych oraz intrefejsów), przy pomocy których programista może w miarę łatwo i komfortowo zbudować gotową aplikację. Z których jednak skorzysta, a które zamieni na bardziej mu odpowiadające zamienniki leży już jednak w całości w jego woli. Ponadto praktycznie niemal nic nie ma narzuconego z góry – co oznacza też, że wciąż ma sporo kodu do napisania.

Symfony to zupełnie inne podejście – tutaj preferuje się, żeby programista pisał jak najmniej tylko możliwe. Po ściągnięciu symfony, ustawieniu kilku plików konfiguracyjnych, wklepanie poprzez CLI kilkunastu poleceń możemy uzyskać gotową aplikację, z dziesiątkami tabel w bazie i pełną ich obsługą. Do tego repozytorium symfony pełne jest gotowych pluginów, które są w zasadzie gotowymi cząstkami aplikacji – cms, forum, autoryzacja, wyszukiwarka, ajaxowe efekty itd.

Jedno i drugie rozwiązanie ma swoje wady i zalety, ale nie chcę się tu nad nimi rozwodzić. Ważniejsze jest, że oba produkty rozwijają się bardzo dynamicznie. Za ZF stoi Zend, firma współtworząca sam język, więc o jakość tego frameworka i jego “przyszłościowość” martwić się nie trzeba. Symfony natomiast po dość długim okresie stagnacji nabrało ostatnio sporego rozpędu i jest w ciągłym rozwoju (swoją drogą – trochę to przeszkadza, bo dokumentacja staje się mocno niekompletna). Najnowsze wersje w zasadzie nadrobiły większość wad w stosunku do ZF (z widgetami do tworzenia formularzy na czele), a to nie koniec rozwoju tego frameworka.

Taka sytuacja powinna ucieszyć tych z programistów, którzy z różnych względów chcą pozostać przy php (jak choćby dostępność serwerów). Wspomniane narzędzia niejako gwarantują, że pomimo rozwoju “konkurencyjnych” społeczności pehapowcy nie zostaną w tyle. A należałoby tu jeszcze wspomnieć choćby o ORM-ach, które również nie stoją w miejscu i ciągle dynamicznie się rozwijają (Doctrine, Propel).

Niektórzy twierdzą, że nie ma złych języków – są tylko źli programiści. Faktem jest, że php jest językiem z tego gatunku, gdzie łatwo o złe nawyki i “złe programowanie”. Niemniej dzisiejszy rozwój pozwala pokazać, że php nie jest taki zły jak go malują – i w tym języku naprawdę da się dobrze programować. Czy to oznacza, że nie warto przerzucić się na Pythona, albo Ruby’ego? Myślę, że powinno to pozostać w indywidualnej kwestii każdego z nas. Na pewno warto dla samego dokształcenia się poznać też inne rozwiązania niż te, z których korzysta się na co dzień; najważniejsze jednak, że niezależnie od dokonanego wyboru mamy dostępne dobre, rozwijające się narzędzia.