This post comes from the first version of this blog.
Please send me an email if anything needs an update. Thanks!
Jakiś czas temu pojawił się w Internecie kolejny rant na PHP. Zdziwiony specjalnie nie jestem, ale jednostronne ujęcie tematu w tamtym artykule wydało mi się tak kruche, a rant tak słaby, że aż postanowiłem wstawić link na swój profil na Facebooku. Zacząłem pisać komentarz, rozszerzać go o kolejne wątki, aż powstało kilka akapitów tekstu. Stwierdziłem, że w takim wypadku, że lepiej będzie wstawić całość na fanpage Blogu::Programisty, gdzie po kilku drobnych zmianach trafia pośrednio za pomocą niniejszego wpisu.
Rant można przeczytać tutaj: http://sloblog.io/~zynisch/qI3DyGJd0yo/php-has-reached-its-limit , reszta mojego wpisu to odpowiedź wpisana w formularz FB. Zaznaczam, ta odpowiedź jest kierowana jedynie do sfrustrowanych ludzi, którzy z wypiekami na policzkach cieszyli się jak małe dzieci czytając np. http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ . Pokoleniu TL;DR wyjaśniam: jest to 20 ekranowy artykuł o wszystkich możliwych błędach w interpreterze / logice języka od PHP3 w górę, nawet, jeśli dawno zostały załatane. Po przeczytaniu całości masz wrażenie, że działanie Twoich skryptów to wyjątkowa anomalia w przyrodzie wywołana odpowiednim układem planet i / lub praktykami okultystycznymi. Jeśli Twój stosunek w tym przypadku do PHP, a ogólnie do wszystkiego co “inne” jest normalny, tj. rozumiesz, że każdy stosuje to, co dla niego jest wygodne i nie masz religijnego podejścia do danego stosu oprogramowania (no dobra, z małym wyjątkiem, jeśli ktoś używa IE6, to nie ma litości :)), a jeśli trzeba potrafisz wskazać faktyczne techniczne problemy nie wynikające z prywatnych upodobań, uprzejmie informuję, że nie jest on o Tobie.
Do rzeczy: programiści / sympatycy Rubiego (i innych języków też, ale im akurat wszystko związane z PHP wyjątkowo jest solą w oku - znam to z autopsji), zanotujcie sobie, żebym dwa razy nie powtarzał: napisać dobry rant na PHP naprawdę nie jest trudno. Trzeba się jednak trochę postarać, a nie tylko porównać snippety kodu i stwierdzić “moje lepsze”. Widziałem PHP4, zaczynałem w erze stosu require_once()‘ów na początku każdego pliku, napisałem własny framework, używałem kilku innych frameworków, Composera, PHPUnita, wielu bibliotek, różnych API, od prawie dwóch lat jestem szczęśliwy z Symfony2, nawet urodziło nam się przez ten czas kilka fajnych projektów, więc wiem co mówię, bo siedzę w PHP już solidne kilka lat i wiem, gdzie można się potknąć niezależnie od poziomu doświadczenia.
Jeśli naprawdę jedynym zyskiem z migracji do nowego języka / frameworka jest to, że mogę coś osiągnąć w 1-2 linijkach, zamiast 10, 20, czy nawet 50, to dziękuję, postoję. Ruby jest genialnym językiem, jeśli chodzi o tworzenie różnego rodzaju DSL-i, przyznaję. To, czy te DSL-e są naprawdę warte uwagi, to zupełnie inna sprawa (jak się łatwo domyślić nie jestem ich zwolennikiem). Wiecie, w PHP mamy takie rzeczy jak np. klasy, czy funkcje i naprawdę chętnie z nich korzystamy, nie pisząc nowych języków do rozwiązania każdego problemu. Możesz zrobić coś w jednej linijce? Genialnie! Ja mogę napisać sobie funkcję, która zamyka 50 linijkowy fragment kodu w… jednej linijce wywołania. Tak nawiasem mówiąc, wiesz, że ten Twój jednolinijkowiec to w większości przypadków dokładnie taka sama funkcja jak moja, tylko “logicznie” poziom niżej w hierarchii języka (tutorial dla niewierzących: http://jroller.com/rolsen/entry/building_a_dsl_in_ruby )?
Konkretne przykłady z artykułu:
- definicja i walidacja encji oraz relacji między nimi: używanie adnotacji (zwykłych komentarzy!) jako metadanych istotnych z punktu widzenia działania aplikacji podnosi mi ciśnienie, poza tym musimy wziąć poprawkę na brak nawiasów klamrowych do określania bloków w Rubym, w sumie wychodzi może ok. 2 linijki więcej na niekorzyść PHP, nic strasznego,
- pobieranie rekordów / zaawansowane wyszukiwanie / CRUD: Doctrine2 potrafi to wszystko zrobić w bardzo podobny sposób, ponadto ActiveRecord już od dawno jest passe. Repozytoria są o wiele lepszym rozwiązaniem zarówno ze względu na testowalność kodu, jak też separację odpowiedzialności (wybaczcie, nie wiem jaki jest dobry polski odpowiednik nazwy dla technik SoC, CQS, CQRS, itp.),
- przypisywanie zmiennych do widoku, szablony, funkcje szablonów: autor widział może Twiga? Wystarczy 1-2 proste rozszerzenia, żeby zrobić to lepiej, ale nawet standardowa wersja jest całkiem przyjemna,
- routing: taki sam jak w Silexie, dynamiczne ścieżki są akurat lepsze w Symfony2 ze względu na parametry zamknięte w {nawiasachKlamrowych}, składnia z :dwukropkiem była problematyczna w symfony 1.x, ograniczenia routingu takie same, jak w Sf2,
- AOP: własne reużywalne (nie lubię tego słowa, ale wolę je od bezpardonowego wstawiania angielskiego reusable) klasy eventów (to nie hipokryzja, zdarzenia są pojęciem w inżynierii oprogramowania, więc są też elementem żargonu) załatwiają sprawę, w Symfony2 można je definiować jako funkcje anonimowe bezpośrednio w kodzie.
Uff, mój pierwszy w życiu (counter-)rant! Jak mi poszło? :D
Jak skończyłem pisać, zauważyłem, że jest też inna odpowiedź utrzymana w tej samej konwencji co niniejszy wpis, ale z przykładami kodu (framework Yii), zapraszam do lektury: http://sloblog.io/~ujovlado/MIJExiD2mfE/php-hasn-t-reached-its-limit-yet .