ugrás a tartalomhoz

PHP: a fractal of bad design

Joó Ádám · 2012. Ápr. 12. (Cs), 00.05
Hosszú kifakadás a PHP tervezési hibái ellen
 ■
1

Az élet nem habostorta

Hidvégi Gábor · 2012. Ápr. 12. (Cs), 10.32
Azért elég jól el lehet a felsorolt hibák mellett is lavírozni a PHP-val; engem igazából csak az zavar, hogy nem konzisztens a függvényparaméterek sorrendje.

A szerzőnek üzenem, hogy ha nem tetszik, át lehet térni más nyelvre, szabad világban élünk, valamint "azokra a napokra", amikor a cikk keletkezett, kitűnő orvosság egy jó barátnő : )
2

+1

mdesign · 2012. Ápr. 12. (Cs), 11.07
:D
3

pffff

Trudy · 2012. Ápr. 12. (Cs), 11.40
Bocs de ez a komment ritka szánalmasra sikerült.
4

Energiapazarlás

kow · 2012. Ápr. 12. (Cs), 12.37
Érdekes, amennyi energiát ráfordított, hogy leírja mennyire fos a PHP ugyanennyi energiával írhatott volna arról is, hogy miként lehetne jobbá tenni.
5

A kérdés az, hogy mennyire

Hidvégi Gábor · 2012. Ápr. 12. (Cs), 13.49
A kérdés az, hogy mennyire lehet jobbá tenni? Nagyon sok ember számára fontos, hogy ne változzon például az API.
6

Új koncepció, teljesen új kódbázis

Max Logan · 2012. Ápr. 12. (Cs), 14.07
Az én meglátásom az, hogy a PHP legnagyobb hibája, hogy a gyökereire épít. El kell dönteni, hogy mit akarunk és ennek megfelelően újraírni teljesen az alapoktól.

1. Vagy lesz az, amire annó kitalálták: dinamikusan lehet vele előállítani HTML dokumentumokat.

2. Vagy lesz az, amire egyre inkább akarják használni az emberek: online alkalmazások backend platformja.

A kettő megközelítést vegyíteni puszta hülyeség és jól látszik a helyzeten a számítástechnika és egy-két testvér iparág legnagyobb buktája: a visszafelé kompatibilitás.

Egy ponton azt kellene mondani, hogy nincsen visszafelé kompatibilitás, a név marad a koncepció változik. Lásd evolúciós elágazások...
7

nem lehetne együtt?

zzrek · 2012. Ápr. 12. (Cs), 14.53
Pl lehetne új kódbázis egy új jelölővel, mondjuk: <?php7 ?>, vagy egyszerűen a fájlkiterjesztés szerint szeparálni (.php7)
Nyugodtan üzemelhetne két fordító/interpreter is egy kiadásban.
(Bele lehetne vonni egyéb nyelveket is, pl. a javascriptet, mondjuk így: <?js ?>. Lehetne valamilyen szabványos átjárás is köztük akár, valamilyen extraglobális névtérrel, vagy valamilyen egyéb értékátadási eljárással, pl. $alma=<??js jsalma ?>, persze ilyenkor nem sztringszerűen, hanem egy belső mechanizmussal vándorolnának az értékek és/vagy a mutatók, ez egy nyelvi elem lehetne)
A lényeg az az, hogy csatlakozva az előttem szólóhoz, nem csak a problémákat kellene gyűjtögetni, hanem a megoldásokra is lehetne javaslatokat adni és elindítani a PHP-t egy más irányú modernizálás felé, és nem feltétlenül lehetetlen mindezt úgy megtenni, hogy ne maradjon kompatibilis az előző kódbázissal.
8

Problémafelvetés = problémamegoldás előkészítése

Max Logan · 2012. Ápr. 12. (Cs), 15.34
Meglátásom szerint a problémák felsorolása, összegyűjtése, részletezése éppen konstruktív kritika, mely szükségszerű a megoldás kidolgozásához. Aki a problémákat felveti, nem biztos, hogy tud és/vagy akar azzal foglalkozni, hogy azok hogyan lesznek megoldva...

A visszafelé kompatibilitás elképzelése érthető, de egyszerűen visszafogja a fejlődést, mert mindig visszafelé is kell nézni, nem lehet csak előre. Egy ponton túl már sokkal inkább átok, mint áldás...

A PHP modernizálásáról addig szerintem felesleges gondolkodni, míg nincsen eldöntve a fentebb is megnevezet kérdés: dinamikussá akarjuk tenni a HTML dokumentumok létrehozását, vagy alkalmazásfejlesztői környezetet akarunk létrehozni?

Lehet mindkettő, de akkor legyen egy PHPdoc és egy PHPapp verzió. Egyik egy lightweight megoldás, másik pedig komoly alkalmazások fejlesztéséhez tud segítséget nyújtani.

Az én megítélésem szerint egy blog már alkalmazás...

Így a light verzió éppen az egyszerűbb, inkább honlap, mint alkalmazás kategóriájú dolgok kiszolgálója lehetne. Ezzel jelentősen lehetne csökkenteni az ilyen site-ok erőforrásigényét, amivel pedig végső soron mindenki nyer (látogató, fejlesztő, üzemeltető; ez utóbbi több ügyfelet tud kiszolgálni egy adott vason, mint korábban).

A light verzióból pl. ki kellene venni a GD és hasonló, inkább komplexebb, alkalmazáslogika jellegű megoldásokat és arra koncentrálni, hogy a tartalom dinamikus előállítása legyen egyszerű, rugalmas és gyors.

A másik verzióba meg mehet minden finomság, ami ahhoz kell, hogy komplex online rendszereket lehessen fejleszteni. Desktop fejlesztési „élmény” megjelentetése az online világ számára.
9

egyetértek

zzrek · 2012. Ápr. 12. (Cs), 15.42
Arra próbáltam rávilágítani, hogy a visszafelé kompatibilitás lehetőségének meghagyása nem feltétlenül jelenti azt, hogy nem lehet paradigmát váltani. Ha a PHP hosszú távon életben akar maradni, akkor szerintem van rá egy olyan lehetősége is, hogy egy kiadásban több rétegben jelenik meg, akár egy teljesen új nyelvet kidolgozva a meglévő mellé (és akkor esetleg csak egy interface-t kell adni az új és a régi alapon megírt kódbázis mellé, hogy támogassuk a fejlesztőket az áttérés moduláris/lépcsőzetes megvalósítási lehetőségével)
16

Szerintem csak a szakaszos

inf · 2012. Ápr. 17. (K), 01.40
Szerintem csak a szakaszos megoldás működhetne. A srác is leírta, hogy a PHP szinte csak kivételekből áll, ezért szerintem túl nagy erőfeszítés lenne egy jól kidolgozott új nyelvhez írni egy olyan interface-t, amivel az összes régi dolog is működik.

Már sokszor leírtam, de azért megteszem itt is, hogy szerintem PHP-ből az egyetlen dolog, ami hiányzik, az a koncepció. Úgy néz ki, hogy a fejlesztők képtelenek voltak eldönteni, hogy mit is akarnak, ezért minden létező nyelvből szakítottak egy darabot, aztán összetákolták, az eredmény meg hasonló lett Frankenstein szörnyéhez. Mozog, tehát működik, de szerintem senki sem merné állítani, hogy jól működik...
10

Hiteltelen

Hidvégi Gábor · 2012. Ápr. 12. (Cs), 15.46
Most olvastam el a cikk végét, és beigazolódott az erős sejtésem: tanulj meg másban programozni. Nem vesződik a szerző azzal, hogy bemutassa a PHP előnyeit vagy az általa felsorolt alternatívák hátrányait, így szerintem semmilyen konstruktivizmus nincs az írásában. Abban igaza van, hogy érdemes és kell is újat tanulni, de arról sem tesz említést, mibe kerül az áttérés.

Nem állhatok oda a megrendelő elé: ezentúl használjuk az X programozási nyelvet, mert bár a PHP-nak van pár hibája/hiányossága, de a legtöbb problémát meg lehet oldani vele, azt persze nem tudom, hogy az új nyelv mennyire támogatott, később milyen könnyen találunk hozzá programozót stb.
11

+1

zzrek · 2012. Ápr. 12. (Cs), 20.49
+1
17

Azzal egyetértek, hogy

inf · 2012. Ápr. 17. (K), 01.47
Azzal egyetértek, hogy hiányzik a konstruktivitás hiánya, viszont szerintem ez nem is volt célja a bejegyzésnek, mint ahogy azt a cím is mutatja...

Nem állhatok oda a megrendelő elé: ezentúl használjuk az X programozási nyelvet, mert bár a PHP-nak van pár hibája/hiányossága, de a legtöbb problémát meg lehet oldani vele, azt persze nem tudom, hogy az új nyelv mennyire támogatott, később milyen könnyen találunk hozzá programozót stb.

Nem hiszem, hogy PHP-hoz sokkal könnyebb lenne jó programozót találni, mint bármelyik más nyelv esetében.
13

ugyanennyi energiával

Joó Ádám · 2012. Ápr. 13. (P), 00.14
ugyanennyi energiával írhatott volna arról is, hogy miként lehetne jobbá tenni.


Umm, mit szólsz a leírtak kijavításához? ;)
15

A mentalitás

kow · 2012. Ápr. 13. (P), 10.36
Nekem csak a mentalitás nem tetszik. Olyan, mint leírni egy népautóról, hogy 200-al nem tud kanyart bevenni, 2 év után szétesik és a Ferrari amúgy is jobb. Az oké, hogy ír egy szép probléma listát, de az egészet úgy tálalja, hogy inkább megütnéd, mint sem leülnél vele értelmesen átbeszélni, hogy min lehetne javítani. A fenti kommentekben sokkal több értelmes gondolat elhangzott, mint a cikkben összesen, pedig csak annyit írtam, hogy mit lehetne javítani.
12

Érdemes "a választ" is

bugadani · 2012. Ápr. 12. (Cs), 21.01
Érdemes "a választ" is elolvasni hozzá.
14

Szűklátókörű cikk. Az emberek

tgr · 2012. Ápr. 13. (P), 09.41
Szűklátókörű cikk. Az emberek nagy része nem az alapján választ nyelvet, hogy tranzitív-e az egyenlőség meg hogy konzisztens-e az strpos és az str_replace elnevezése, hanem hogy működik-e a $_GET['debug']==1 anélkül, hogy típuskonverziókon kéne gondolkodnia, és hogy mennyire hasznos információt kap az strpos-ról 10 másodperc guglizással. A PHP egyszerűen sokkal könnyebben tanulható a kezdő programozó számára (és különösen a kezdő nem túl jó progamozó számára), ebből kifolyólag sokkal többen használják, ebből kifolyólag sokkal nagyobb a közösség, jobb a support, ebből kifolyólag ebben készült a népszerű opensource webalkalmazások java, illetve a cégek jelentős része ebben készíti a maga webalkalmazásait, mert PHP programozót sokkal könnyebb találni, mint mondjuk Ruby programozót. Azon sírni, hogy a Ruby szebb nyelv, mint a PHP, ugyanolyan értelmetlen, mint azon, hogy a Betamax jobb formátum volt, mint a VHS. Az volt. És? A piac nem szépségverseny, a megrendelőt az érdekli, hogy mennyiből lehet kihozni azt az alkalmazást, amire szüksége van, nem az, hogy a closure rálát-e a szülő scope-ra. A PHP arra van optimalizálva, hogy könnyen tanulható és következésképpen olcsó legyen, és ebben le is nyomja a legtöbb vetélytársát.
18

+1, ez így igaz.

inf · 2012. Ápr. 17. (K), 03.56
+1, ez így igaz.