Given enough time, all your code will get deleted.
Still, PHP is forever!
Lasand glumele la o parte, s-ar putea să fiu putin off-topic, dar mă aștept să avem nave spațiale care rulează pe PHP, chiar dacă nu multe, în viitor. Sigur, noi extensii și framework-uri ar putea fi folosite pentru asta, sau daca un update de PHP adauga functionalitatea necesara, dar tot cred că există șanse mari să vedem în cele din urmă o navă spațială rulând pe PHP.
După părerea mea, a avea actualizări majore, precum cele pe care le-a avut PHP în ultimii ani, duce la supraviețuirea limbajului de programare mult mai mult. Mai ales dacă aceste actualizări majore îmbunătățesc eficiența și adaugă funcții noi și populare. Cu cat sunt tinute limbajele mai up-to-date, cu atat cred ca le va creste durata a limbajului pentru proiecte noi.
1 Like
PHP in sine e technical debt 
Eu nu m-am detasat de PHP fiindca era rau sau nu puteai face ceva bun cu el, m-am detasat fiindca 80% din proiecte care te platesc sunt in asa hal incat nu te poti atinge de nimic fara sa strici altceva.
De multe ori problema majora e host-ul, nu codul tau ca nimeni nu foloseste AWS/servere virtuale cu PHP.
Securitatea e iarasi o problema cu tot felul de module compilate in PHP, ai Apache, ai Nginx, Lightspeed care fac un proxy sau sunt strans legate de serverul principal (Apache). Poti avea un modul openssl vulnerabil, un modul mysql vulnerabil. Cache-ul e o problema, iti trebuie servicii pe langa serviciile tale precum redis.
Dupa nici o aplicatie de PHP complexa nu e in sine statatoare, ai ioncube care trebuie sa fie versiunea corecta, ai posibil Zend, mai nou hhvm, ceva special pentru websockets, imagemagick/gd… Lucruri si mai complexe au module custom scrise in C++.
Daca paginile web mor, e.g. o sa fie inlocuite cu aplicatii compilate in assembly scrise de un AI, generate total de un model de AI in functie de ce vrea cineva sa vada din niste date sau documente strict statice atunci moare si php. Inca nu poti prevedea ce se va intampla.
Sunt sigur ca nu ai vazut comentariile alea cu
do not touch this code/class
Ai căutat toate combinațiile de cuvinte fără sens și te-ai oprit la asta 
Poți avea un modul openssl/mysql/etc vulnerabil și pentru java/node/whatever. Cum funcționează caching în alte limbaje? Este built in? Sau cumva trebuie să… instalezi… servicii… pe… lângă? 
Ai aruncat niște idei acolo care au zero sens. HHVM este un alt limbaj. Module custom scrise în alt limbaj ai și în node sau python (probabil și în alte limbaje).
Apoi închei apoteotic cu AI. Despre blockchain nimic? Sau nu mai e la modă săptămâna asta?
Cred că nici n-ați citit articolul și ați concluzionat că-i vorba de PHP. Iar singura referință la PHP este următoarea:
Another common problem is major programming language version changes. Be it Ruby, PHP, .NET, or others. They commonly require a bunch of code changes or even rewrites.
2 Likes
HHVM e un limbaj si *era si un VM pentru PHP. L-am folosit destul de mult inainte sa fie PHP 7 stabil.
Dar da, nu am raspuns la articol, am raspuns la primul raspuns
Fun fact: de când a fost HHVM lansat, PHP a trecut prin cel puțin cinci versiuni.
Dar e OK, vorbești în cunoștință de cauză.
1 Like
nimeni nu foloseste AWS/servere virtuale cu PHP
Cine e acest “nimeni”? E aici cu noi acum?
nici o aplicatie de PHP complexa nu e in sine statatoare
Ce aplicatie complexa e de sine statatoare si nu are dependinte externe.
ioncube […] Zend […] hhvm, ceva special pentru websockets, imagemagick/gd
Mere, caini, copaci.
Daca paginile web mor, e.g. o sa fie inlocuite cu aplicatii compilate in assembly scrise de un AI, generate total de un model de AI in functie de ce vrea cineva sa vada din niste date sau documente strict statice atunci moare si php
2 Likes
PHP-ul nu moare. A fost mainstream când ASP.NET era nașpa.
Apoi a venit JavaScript odată cu NodeJS, care a devenit mainstream.
Python e pe cale să devină mainstream, datorită AI.
Cam așa e si cu codul scris de noi.
Mai sunt si oameni care au lucrat până la pensie într-o tehnologie, ca la CFR.
Imaginați-vă să fii 20 de ani mecanic la CFR și să ți se ofere șansa de a lucra tot la CFR, dar pe poziția de analist in departamentul de achiziții.
2 Likes
Cand lucram eu cu PHP acum 10 ani incercand sa invat programare n-am vazut pe cineva sa foloseasca AWS pentru php, adica nici acum nu cred ca foloseste. N-am dat de AWS inainte sa vad go la munca sau Java. Abia au inceput sa apara serverele virtuale, composer nu exista… 99% din oameni foloseau cpanel intr-un mod sau altul, platforme precum drupal/phpbb/wordpress, ala era php. Rar mai dadeam de Symfony, CodeIgniter… Cateva platforme de ecommerce care erau oribil de navigat la un proiect mai serios, in special Magento.
Absolut tot ce am scris atunci a fost inlocuit, de rulat sigur ar mai rula, dar deprecated e putin spus. N-am ajuns sa vad oameni care scriau php profesional, majoritatea era ceva hit and run fara teste, nu se facea serializare/deserializare, numai template-uri. Era messy, path-uri rescrise din .htaccess, upload de fisiere direct pe server, server de email local, sesiuni local/in mysql, hosting absolut oribil cu cpanel/directAdmin…, upload de cod cu ftp.
Azi PHP arata mult mai bine, dar acum 10 ani era oribil ca si JS. Normal ca sunt si probabil mai multi care acum fac php cu k8s…
2 Likes
Cand lucram cu PHP azi dimineata era ok. La fel a fost ok in 2020 sau in 2017, in 2011 sau 2006.
Ce as zice eu ca e problema e ca fiecare bucata de software cand capata tractiune incepe sa devina un monstru. Un conglomerat care tinteste sa faca de toate.
Clientii mei au un site facut destul de ok. Au vazut si altii si au vrut si ei. Acuma sunt vreo 5 - 6 site-uri in acelasi repository fiecare cu ramura lui separata unde fiecare are CSS diferit si incep sa primeasca si functionalitati diferite. Ar trebui sa fie 5 aplicatii diferite cu vreo 2 - 3 oameni care sa lucreze la ele.
Asta se intampla si la framework-uri. Proiectele scrise in PHP pur merg bine si azi insa cele scrise in Laravel (4 la momentul respectiv) deja dupa cateva luni incepeau sa aiba probleme de dependinte. Cand am trecut de la CakePHP 2 la 3 de fapt am rescris toate aplicatiile de la zero. Iar acum cu Angular, nici un an nu are proiectul si deja se vorbeste de a treia migratie.
Eu unul raman la PHP pur pentru proiectele mele. Single Page Applications in Angular sunt cool dar nici un client nu mi-a zis vreodata “vreau asa, nu ma intereseaza cat costa sau cat de complicat e”.
4 Likes
imi lipseste drupal 7 (au fost ani de zile in care te puteai baza pe el).
si imi lipseste si frameworkul propriu in care scriam inainte de drupal 7 (pur si simplu ii stiam fiecare coltisor si functiona “as expected”, doar ca aplicatiile se complicau si fiecare chestie noua trebuia scrisa de la zero).
separat de cat de mult ne putem baza (sau nu) pe o chestie…
programarea e cam aceeasi indiferent de forma (limbaj de programare, framework, etc)
si faptul ca pus mana si pe un “hc” cu basic, pe un 486 cu turbo pascal, pe fox pro (fie el un 2.6 pt dos sau un visual cu ferestre de windows), pe asm (si pe programatoarele de “pic”-uri la care nu stiai daca problema e ca nu ai suficient curent de la pc sau daca ai calculul corect pt schema electronica) si tot asa…
nu are cum sa fie altfel decat un avantaj care ma face sa fiu mai “intelept” cand e nevoie de vr’un framework js la moda sau cine stie ce alta tehnologie “extrateresta”.
acum… daca mai am acelasi chef sa programez ca acum 20+ ani…
probabil ca nu.
dar nu ma sperie viata dupa php (daca o sa o prind).
1 Like
ai un pic de tunnel vision aici
1 Like
Aici cuvintele cheie sunt timpul si priceperea. Am vazut o multime de programatori de productie care au scris munti de cod de productie ce rezolva munti de probleme, codul fiind messy si absolut ne-mentenabil. Din pacate astea sunt conditiile de productie, graba ca trebuie sa rezolvi repede ceva in timp te face un programator dezorganizat si neglijent cu orice inseamna calitatea codului. Lucrurile stau diferit in zona celor care dezvolta platforme, SDKuri, frameworkuri, etc unde trebuie sa fi mai organizat. In rest si azi e la fel, s-au mai rotit doar limbajele…
1 Like
Oarecum,
PHP by default e sincron, devine asincron prin faptul ca fiecare request/render va avea propriul proces/worker efemer. (ca si nodejs) Dar diferenta majora e ca procesul nu e reutilizabil sau dedicat/user, ceea ce din start e o problema pe server. Daca trebuie sa faci un serviciu care asteapta raspunsul de la N servicii si returneaza utilizatorului raspunsul va face totul sincron.
Stiu ca exista solutii pentru PHP asincron (Swoole), dar nu e by default. In Node/Go/Java/C# ai futures/promises sau coroutines care iti permit sa faci 10 request-uri deodata, nu pe rand.
Daca trebuie sa combini PHP cu alte servicii scrise in alte limbaje (facute sa fie asincron) poate fi problematic. E.g. trimiti email-uri/notificari cu mai multe servere deodata in paralel ca sa nu atingi limitele serviciului dintr-un panou de admin.
Cât de des ai întâlnit scenariul ăsta fără ca serviciile alea externe să depindă de date primite de la unul „anterior”? Adică apelezi ceva endpoint de info despre client, după care iei facturile pentru el și cine știe ce alte date de la alte servicii.
Ți s-a întâmplat așa des să fie nevoie să iei date din X puncte fără ca ele să aibă legătură unul cu altul?
Laravel are un client HTTP care are support pentru concurent requests (este un wrapper peste Guzzle, care permite acelasi lucru). Nu trebuie sa faci 10 request-uri pe rand, le poti face in paralel.
Poate este mai ok daca incerci sa folosesti PHP + ecosistemul actual inainte sa spui lucruri care este posibil sa nu mai fie relevante/adevarate?
1 Like
Citesc raspunsuri pe aici si imi par ca sunt scrise cu chat gpt :))
cred ca o sa pun si tagul php vs the world
2 Likes