Tind sa nu fiu de acord cu chestia asta. Pare a fi un fel de flower power post despre PHP. Eu sunt bun pe PHP si-mi place sa cred ca-l cunosc destul de bine. Nu am studiat in asa mult detaliu alte limbaje. Cu toate astea, vad ca are niste limitari. De exemplu, faptul ca ai nevoie de un server pentru a putea rula o aplicatie. (ma rog, exista php serve, dar cine o foloseste?).
Din ce inteleg, in Ruby sau in Python nu ai nevoie de un server, motiv pentru care aplicatia ta depinde doar de limitarile limbajului pe care-l folosesti si limitarile tale ca programator. Poate ca ma insel.
Ma tenteaza sa studiez Ruby sa-mi fac o idee mai buna.
Oricum, partea de OOP din PHP este la un nivel foarte bun in ziua de azi. Cine stie sa-l foloseasca, poate crea orice arhitectura de aplicatie. Dezavantajul e ca e doar server side. Tot trebuie sa inghiti Javascript. Si daca tot inghiti Javascript, de ce nu nodejs? Nu ca as avea prea mult habar de nodejs…
Pe de alta parte, in PHP, mai nou, avem Laravel 5. Am ajuns cumva la punctul la care civilizatia asta a programatorilor a descoperit in sfarsit canalizarea… viata poate sa fie mai curata si nu o sa mai puta asa de tare.
Ai nevoie de server doar dacă vrei să faci site-uri/aplicații web ( asta se aplică și pentru ruby sau python ), dar poți face scripturi pentru consolă unde nu îți trebuie decât interpretorul de php.
Da, frameworkurile sunt la un nivel destul de crescut, pentru unii laravel 5, alții symfony sau zend 2, sau poate mai low-level ca silex sau altele de acest fel, dar chiar și așa dacă nu pleci de la domeniu/arhitectură care să fie oop cu php și independentă de frameworkurile de mai sus, eventual folosind frameworkuri pentru cqrs gen broadway, predaddy, atunci mai devreme sau mai târziu o să avem parte de spaghetii cod.
Sau pentru unii, dintre programatori, care preferă doar funcțional, pentru că din experiența lor oop în php este un consumator prea mare de resurse pentru aplicații mari.
Dar dacă nu există comunicare intre echipă(programator, tester,ba) și client(po) pentru a identifica care este scopul pentru care se dorește construirea aplicației( vezi impact mapping), dacă nu există colaborare pentru a defini vocabularul comun(ubiquitous language) și exemple gen user stories cu criteriile de acceptare, eventul poate și un event storming pentru a identifica evenimentele și toate celelalte care fac parte dintr-o arhitectură cqrs corespunzătoare nevoilor acelui domeniu, atunci cred că indiferent de limbaj sau de framework, chiar dacă există unit-teste sau o metodologie gen scrum, se poate ajunge la un produs care nu este ceea ce a dorit clientul sau/și costul unor noi facilități să fie destul de ridicat sau riscant.
Iar referitor că este doar server-side, ideal pentru mine, ar fi că după ce am reușit să deslușesc domeniul, să fac un rest web service pentru usecasurile din aplicație, și această să poate fi consumat fie dintr-o altă aplicație php(guzzle) sau dacă nu pricep prea bine să las pe cineva priceput pe front-end ca să facă un o interfață pentru backend.