- Erős típusosság hiánya
Ez nem hiány/hiba ez feature! :) Na de tényleg, nem típusos, nem típusos, ennek megfelelően kell írni benne a kódot, van akinek ez jó és van akinek nem.
- PHP bugok közül nem egyszer több napos szívás
Ezt csak általában 1x kell végigcsinálnia minden PHP fejlesztőnek, utána köv. projektnél már tudja mit lehet mit nem és hogyan. Azért nem jönnek a bugok verzióváltásonként, hanem inkább mennek.
- Háttérfolyamatok esetén (amelyből nálunk nem kevés) multithreading hiánya.
Jó, hát többszálúságot nem tud, de nem is várhatjuk el egy szkriptnyelvtől, majd egyszer vagy bele teszik vagy nem.
Nyilván ilyen problémára más nyelv való, vagy más megoldás.
- Egyes feladatokra lassú. (Van kb. 4000 sor C++ és néhányezer sor .NET/mono kód mögötte.
Világos, itt is ugyanaz, nem ultimate programnyelv, mindent nem lehet, valamit valamiért. Ha lassú kell más ami gyorsabb, ez minden esetben így van, nem csak itt.
- SOAP támogatás a PHP-ben finoman szólva fos.
Ezt elismerem, de ez csak egy módja a kommunikációnak, nyilván elég elterjedt módja sok helyen, és biztos sokaknak hiányzik egy jó SOAP támogatás (nekem speciel nem), vagy lesz vagy nem, ha SOAP kell, akkor ott a Java erre.
- Régi időkben nem keveset kellett nagy excel táblákat feldolgozni (szerencsére ez az időszak elmúlt), erre a PHP alkalmatlan csak ordenálé trükkökkel. (Volt olyan folyamat, amely 10 percig futott, részekre kellett bontani és ajax poolinggal szívni.
Ez is problémafüggő, ráadásul excel tábla != CSV, nem tudom pontosan most mire gondoltál. Ha tényleg olyan méretűek azok a táblák akkor ahhoz megint valami nagyon alacsony szintű megoldás kell és csak aztán PHP, mert mindent a PHP sem tudhat.
Nem értem amúgy a problémát, szerveroldalról érkezett a nagy excel tábla adat a kliensoldalra és belökted HTML-ként a DOM-ba? Na de gondolom nem egy az egyben, hanem volt lapozás miegymás, akkor meg mi volt a lassú? Ajax mindenképpen kell, ha nem akarunk oldalfrissítést de ezen kívül semmi köze a PHP sebességéhez... vagy én értek félre valamit.
- Csomószor kell plusz kódot tenni olyan ellenőrzések miatt, amelyekre Java/C# esetén semmi szükség nem lenne, hiszen maga a fordító kiszűrné a felét.
Ez is olyan dolog, hogy használj egy framework-ot ami elvégez helyetted dolgokat, és ne írj natív kódot mert a végén felvágod az ereidet. Nem értem pontosan milyen ellenőrzések hiánya volt a gond, de majd elmeséled ha szeretnéd.
- Alkalmazásszerver hiánya. Van egy valag memóriánk szabadon, simán berántanék oda egy valagnyi adatot ahelyett, hogy adatbázisból húznám ki folyton.
Erre most mit mondjak? Biztos van ilyen problémakör az életben, én még ilyennel nem találkoztam, de elhiszem, hogy lehetne ezzel optimalizálni és nem DB kéréseket indítani.
Csak néhány nagyobb témakör. Természetesen a nagyját megoldottuk így vagy úgy de nem mondom, hogy minden megoldással elégedett vagyok.
Ezt csak te/ti tudod/tudjátok én nem nagyon szívtam még PHP-vel pedig voltak elég változatos problémakörök és alkalmazások amiket meg kellett valósítani.
Eleve FW-el indul minden projekt, anélkül nem dolgoztam csak nagyon régen.
Nativ PHP kódot nem írok, és DB-t sem buzerálok valamilyen ORM nélkül.
Na de ízlések és pofonok. :)
________________________________
blog: http://horvathjanos.wordpress.com