Room 303

Nie jest. Tytuł powinien brzmieć raczej:

• Dlaczego, kiedy mówię, że programuję w C/C++, ludzie czują respekt?
• Dlaczego, kiedy mówię, że programuję w Pythonie, podają mi rękę?
• Dlaczego, kiedy mówię, że programuję w PHP, ludzie śmieją się do rozpuku?

To trochę jak z Polakami za granicą. Ludność autochtoniczna ocenia ich nie po tym, kim naprawdę są, ale po tych jednostkach, które widać najbardziej. Po kiepsko ubranych, niedomytych pijusach spod marketów. Podobnie jest z programistami PHP.

Język zaczął jako mało popularny silnik do osadzania prostych, krótkich skryptów wewnątrz kodu HTML. Nie oferował wiele — programowanie proceduralne, zmienne bez reguł typowania, wektory zwykłe i tablice mieszające. Z czasem nabrał popularności i zrobiło się o nim w sieci głośno. Pojawiały się kolejne tutoriale, pisane tak przez doświadczonych ludzi, jak przez laików. Język był tak prosty, że nawet dziecko było w stanie wykonać w nim proste operacje i podzielić się swoją pracą z innymi.

Z czasem platforma ewoluowała i zyskiwała na funkcjonalności. Zyskała sobie poklask wśród firm hostingowych ze względu na łatwość utrzymania — wystarczyło dodać jeden moduł do serwera WWW i wszystko zaczynało magicznie działać. Lawina nabrała masy i zaczęła napędzać się sama. Już kilka lat temu można było bez trudu znaleźć strony jedenasto-/dwunastolatków zafascynowanych PHP. Kolejne wydawnictwa prześcigały się w publikacji tomów opiewających wspaniałość języka. Pozycje książkowe były lepsze lub gorsze, z przewagą tych pierwszych. Powtórzyła się sytuacja z językiem HTML.

Od kiedy PHP uzyskało etykietkę języka dla wszystkich, język zaczął gwałtownie tracić w oczach środowiska profesjonalistów. Zaczął być kojarzony ze wspomnianymi dziećmi i niedzielnymi hakerami, którzy wdrożenie aplikacji rozpoczynali od lektury dwóch, wątpliwej jakości, tutoriali w sieci, a następnie tytułowali się ekspertami w dziedzinie webaplikacji. Tak jest do dziś — PHP kojarzone jest z proceduralnym kodem, brakiem separacji warstw logiki i prezentacji, brakiem dokumentacji projektowej, konstrukcjami składniowymi na miarę niesławnego Visual Basica i aplikacjami, które raz napisane, nie nadają się ani do powtórnego użycia ani późniejszej modyfikacji.

Co z językiem jest nie tak? Jest bardzo elastyczny, momentami za bardzo. Język C, jako język kompilowany do postaci binarnej, posiada bardzo rygorystyczną kontrolę zgodności typów. Ostrzega nawet przed konwersją typów, które są właściwie identyczne w reprezentacji binarnej, ale posiadają różne nazwy, stąd nawet rzutowanie wskaźników wymaga jawnej konwersji w kodzie. Python posiada bardzo rygorystyczną składnię — wymusza poprawne (i czytelne) formatowanie kodu źródłowego, bo jego wygląd decyduje o przepływie sterowania. Co ma PHP? Burdel na kółkach.

Najbardziej boli w codziennej pracy jedno z jego początkowych założeń — brak typowania zmiennych. Uniemożliwia to kontrolę poprawności kodu jeszcze przed jego uruchomieniem i skutkuje godzinami ślęczenia nad kilkunastoma tysiącami linii w celu wyłapania literówki lub tak zwanego efektu kofeinowego deficytu.

Boli też domyślna konfiguracja serwerów deweloperskich, gdzie poziom raportowania błędów jest dostosowany do maszyny produkcyjnej i spory procent programistów nie ma nawet pojęcia, że język oprócz błędów krytycznych potrafi też raportować ostrzeżenia i powiadomienia (a od wersji piątej także błędy naruszenia rygoru składni).

Jeszcze bardziej boli domyślne aktywowanie na serwerach opcji register_globals i magic_quotes_gpc. Pozwala pisać niechlujny kod, a dodatkowo uniemożliwia jego uruchomienie na poprawnie skonfigurowanych maszynach.

Boli brak narzędzi interaktywnych i wbudowanej obsługi testów jednostkowych, co pozwoliłoby błyskawicznie wyłapywać regresje w kodzie bez potrzeby pisania specjalnych interfejsów do uruchamiania poszczególnych elementów silnika.

Boli brak zunifikowanej struktury dostępu do systemów bazodanowych. Brakuje też podobnej struktury dostępu do danych pochodzących ze źródeł zewnętrznych.

Na szczęście, przynajmniej część z tych problemów zostanie lub została już zniwelowana. Od PHP 5.1 dostępny jest szkielet dostępu do danych potencjalnie niebezpiecznych — input_filter. Pojawił się też uniwersalny silnik dostępu do baz danych - PDO. W wersji szóstej całkowicie usunięte zostanie wsparcie dla magic_quotes i register_globals. Nic jednak nie naprawi ludzi, którzy budują to, jak język jest postrzegany. Jeśli ktoś nie chce się uczyć, to najlepsze zmiany nic nie dadzą. Tak jak nic nie dadzą narzędzia, z których nie chce korzystać.

Zanim zacznie się flejm — jestem programistą i utrzymuję się głównie z tworzenia aplikacji we wspomnianym wyżej języku. Znam jego mocne i słabe strony. Tekst wyraża moje i tylko moje zdanie na ten temat.

Technorati Tags: php, code