Ten artykuł nic nie mówi o wyższości/niższości używania PHP czy Ruby/Rails. Mówi tylko o osobistych upodobaniach jakiegoś pehapowca. Jakiś lamer chcący na nowo wynaleźć koło. Zamiast użyć w miarę sprawdzonych pehapowych frameworków naśladujących RoR (takich jak np. cakePHP czy Symfony), postanowił napisać od zera kolejny, po swojemu. DHH też próbował. Nie dało się. W PHP nie da się uzyskać czystości i prostoty Railsów. Zawsze to będzie nieudolne naśladownictwo. Język PHP jest za mało obiektowy i za mało dynamiczny aby można w nim napisać tak elegancki framework jak Rails. Ale wracając do jego powodów przejścia.
- Bo w PHP da się zrobić to samo co w RoR.
Owszem, w Assemblerze również. Kwestia determinacji i czasu. Na pewno jednak w PHP nie da się uzyskać tak samo eleganckiego i czytelnego kodu. Nawet w Pythonie się nie da, a jest niezrównanie bardziej czytelny od PHP.
- Bo wszystko w naszej firmie jest zrobione w PHP.
To jest sensowny powód aby trzymać się tego co już jest, jeśli jest tego dużo (lub jeśli garniturowi są oporni na zmiany). Jednak utrzymanie czyjegoś kodu PHP to najczęściej na tyle traumatyczne przeżycie, że ja bym i tak naciskał, aby nowe projekty robić w Pythonie czy RoR i powoli migrować z PHP.
- Nie chcę tego, czego nie potrzebuję.
Autor dalej pisze, że uważa musi zrozumieć każdą linijkę kodu RoR. To jakiś bezsens. Aby używać RoR nie trzeba wcale znać jego wewętrznej implementacji. Powiem więcej, RoR to najprostszy ze znanych mi frameworków webowych. Jest bardzo intuicyjny i łatwy do nauki. Autor dalej napisał, że jego własny framework robi to, co chce. Owszem, ale co jego firma zrobi, jak zatrudnią drugiego programistę który będzie musiał zrozumieć to, “co autor miał na myśli”? Poza tym, RoR to tylko framework. Nikt nie musi używać wszystkich jego helperów i możliwości. Właśnie gdzie jak gdzie, ale w RoR bardzo łatwo używasz to co potrzebujesz.
- Bo jest mały i szybki.
Można autorowi wierzyć tylko na słowo, bo nie podał żadnych benchmarków. RoR się dobrze skaluje na mongrelach, poza tym wąskim gardłem aplikacji webowej jest zwykle baza danych, a nie kod po stronie serwera. Jeszcze szybszy od PHP i czytelniejszy jest Python. Właśnie - czytelność. Szybkość działania aplikacji nie ma takiego znaczenia jak czas tworzenia softu i jego utrzymanie. Jakie są szanse, że jakiś autorski kod gościa, co nawet nie potrafił nauczyć się RoR, będzie stabilny, łatwy do debugowania i utrzymania? A co z możliwościami? Autor zaimplementował tylko to, co mu jest potrzebne teraz. Co zrobi jak jutro będzie potrzeba czegoś więcej? Na ile modularny i łatwy do rozbudowy jest jego kod? Rozumiem, że go to niewiele obchodzi. Liczy się tylko “dziś” i “teraz”.
- Bo mój kod odpowiada moim upodobaniom.
To bardzo osobisty powód. Równie dobrze mógł ten swój wywód skrócić do: wolę PHP bo bardziej je lubię od Rubiego i Rails. Co prawda, o gustach się nie dyskutuje, ale moim zdaniem autor ma kiepski gust.
- Bo kocham SQL’a.
J.w. Dodam tylko, że powód dosyć debilny, bo RoR nie zmusza nikogo do używania ORM’a. Nie ma żadnych przeszkód aby całą aplikację napisać za pomocą kwerend SQL. Jednak po to używa się ORM’a aby uprościć tą pracę i lepiej zmodelować dane biznesowe. Same klucze obce są zbyt prymitywne do trzymania intergalności modelu bazy w porównaniu do tego, co potrafią walidatory Active Record. O wyższości używania ORM nad SQL każdy wie. Każdy ORM pozwala na używanie czystego SQL do pewnych, nietypowych sytuacji. Więc moim zdaniem, posługiwanie się wyjącznie czystym SQL nie daje żadnej przewagi.
- Bo znam PHP dużo lepiej i sprawniej nim się posłużę niż Ruby.
To jest jakiś argument dla osoby, która nie chce się niczego nowego uczyć (lub ma krótki deadline dla projektu i nie ma czasu aby wskoczyć w nową technologię). W każdym razie autor przyznaje się tu, że po prostu jest cienias. Nie zna Rubiego, nie chce się uczyć nowych rzeczy. I po prostu jest zakochany w PHP i czystym SQL.
Co ciekawsze, autor na końcu podsumowuje , że mimo wszystko i tak zamierza pewnego dnia zacząć używać Rails. Zapowiada, że zajmie się tym podczas tworzenia nowego projektu, od podstaw. Choć to, że przez dwa lata usiłował coś napisać w Rails i ostatecznie łatwiej wyszło mu przepisać na PHP raczej świadczy o jego niezbyt lotnych umiejętnościach jako programisty w ogóle.