PHP Weboldal készítés!? Miért pont OOP?
2010-07-01T11:41:50+02:00
2011-01-26T07:58:13+01:00
2022-06-29T08:00:34+02:00
  • Ez nem a nyelv dinamikus jellegéből adódik, vagy abból, hogy konkrétan a PHP-ről van szó, hanem abból, hogy a HTTP egyrészt állapotmentes protokoll, másrészt, hogy ezzel összefüggésben a standard kiszolgálási mód általában diszkrét futási meneteket indít. Így működik a CGI, de az ISAPI is.

    A megoldás erre a problémára a *nix alatt daemonnak, Windows alatt alkalmazásszervernek hívott modell alkalmazása, ami azonban azért nem terjedt el igazán, mert sokkal alaposabb tervezést és implementációt igényel (ti. mert magára az alkalmazásra bízza a kapcsolatok és a konkurenciahelyzetek kezelését, és mert nagyon érzékeny a memória- és erőforrás-leakekre.) De elvileg akár PHP-ben is lehet ilyen daemont/alkalmazásszervert csinálni, szóval alapvetően semmi köze nincs se a PHP-hez, se a dinamikus nyelvszerkezethez úgy általában.
    Mutasd a teljes hozzászólást!
  • Háááááááát... Tudja Virág elvtárs, én teljesen hülye vagyok...
    De valahogy úgy képzelem, hogy egy objektum létrejöttekor kicsit több dolga van az interpreternek, mint egy akármilyen lokális változóénál. Ha csak azt nézem, hogy öröklődések, konstruktorok futtatása, már az is soknak tűnik és ki tudja, még mi minden történik ilyenkor. No mind1, ebbe most nem akarok belemenni mélyebben, lényeg, hogy eszerint jól értem és tényleg úgy működik ez az egész, ahogy eddig gondoltam.
    Mutasd a teljes hozzászólást!
  • Miért, ha lokális változókat használsz az nem jön létre a folyamat elején, és szűnik meg a folyamat végén ? Az oop ehhez képest csak annyival több, hogy a program tudja hogy az adott objektum tagfüggvényei ehhez az adott objektum adataihoz férhetnek hozzá. De a kód csak egy példányban létezik, és nem annyiban ahány objektumod van. Pár pointerrel jön létre több. A dinamikus típuskezeléshez képest ez a plusz erőforrásigény elhanyagolható.
    Mutasd a teljes hozzászólást!
  • Van egy dolog, amit még mindig nem sikerült végérvényesen tisztázni magamban: jól értem, hogy normál körülmények közt, egy PHP objektum csak addig létezik, míg egy lapot megjelenít a szerver?
    Magyarán, ha bejön egy klienstől egy kérés, akkor az adott lapon megjelenő PHP objektumokhoz tartozó osztálydefiníciókat minden letöltésnél be kell olvasni, belőlük a szükséges objektumokat létrehozni, felhasználni, majd elfelejteni és a következő klienssel mindezt újra eljátszani?
    Valahogy egyre ide lyukadok ki, de ez valami iszonyatos erőforrás pazarlásnak tűnik.
    Mutasd a teljes hozzászólást!
  • A "túlbonyolítás" oka, hogy a java/c# inkább építőkockákat biztosít, aminek a lényege, hogy 'bármit' kirakhatsz a kockákból

    Ebből a php féle "egyszerű" fopen is kirakható, meg a csereszabatos 'kockák' cserélgetésével szinte bármi.

    Vagyis az egyszerűség/rugalmasság+alkalmazhatóság dilemmája ez.

    Mutasd a teljes hozzászólást!
  • javanal lehet, de PHP esetén erre a streames megközelítésre nem tudnék példát mondani.
    Mutasd a teljes hozzászólást!
  • A javában nem túlbonyolítva vannak a dolgok (elvégre maga a streames megközelítés _nagyon_ jó dolog) csak azok az osztályok hiányoznak amik az életedet megkönnyítenék ezeknek a streameknek a kezelésekor. Persze ezeket sem nagy ügy megírni, csak idegesítő hogy ez nem az alap java osztályok része.
    Mutasd a teljes hozzászólást!
  • Attól függ mi van a fájlban. Ha ez egy cache fájl, vagy egy lokális configfájl akkor rendben van. Adatbázist meg nem teszünk fájlba, és ennek még a legkisebb oka a lockolás.
    Mutasd a teljes hozzászólást!
  • Ha ilyen párhuzamos módosításból eredő konkurencia helyzetek kezelése fontos

    Ez általában egyértelmű, de láttam már itt a fórumon is olyat, aki ezt csinálta:
    fopen -> beolvas -> módosít -> visszaír -> close
    (mellesleg a file lock, az nem lock? Sorszintű lock meg sem fordult a fejemben ebben az esetben )
    Mutasd a teljes hozzászólást!
  • Lusta vagyok utánanézni, de a fopen nem lockol?

    Nem. Olyant tud, hogy kizárólagos írásra vagy olvasásra (vagy mindkettőre) nyittatod meg a fájlt vele.

    Mert lock nélkül elég érdekes dolgokat eredményezhet egy olyan húzás, hogy betöltesz egy file-t a memóriába, módosítod, majd visszaírod... Vagy nem?

    Ha ilyen párhuzamos módosításból eredő konkurencia helyzetek kezelése fontos, akkor az adatokat nem fájlokban kell tárolni, mert az azokhoz történő hozzáférést effektíven és hatékonyan nem lehet szinkronizálni, sorba állítani.
    Mutasd a teljes hozzászólást!
  • Azaz a dolog nem a típusosságon múlik.


    Egy szóval nem írtam, hogy a gyengén típusosságon múlik. Egyszerűen csak az erősen típusos nyelvekről beugrott a Java, és az, hogy azért nem szeretek benne dolgozni, mert szerintem bizonyos dolgok túl vannak bonyolítva benne.
    Mutasd a teljes hozzászólást!
  • Lusta vagyok utánanézni, de a fopen nem lockol?
    Mert lock nélkül elég érdekes dolgokat eredményezhet egy olyan húzás, hogy betöltesz egy file-t a memóriába, módosítod, majd visszaírod... Vagy nem?
    Mutasd a teljes hozzászólást!
  • PHPban meg erre a 2 esetre lehet szükség:

    array file('somefile.txt')
    string file_get_contents('somefile.txt')

    nem is tudom mikor írtam le utoljára az fopen parancsot.
    Mutasd a teljes hozzászólást!
  • $file = fopen("file.txt", "r");


    c#-ban:

    string fileContent = File.ReadAllText("file.txt")

    de akár olvashatod byte tömbbe is a file-t:

    byte[] fileContent = File.ReadAllBytes("file.txt");

    És azért csak jobb, hogy ha ránézel a kódra, akkor látod a típusát a változónak, nem? Vagy ha máshol használod az intelisense-ből is rögtön látod, mi a típusa, milyen metódusai vannak, stb.

    Nem mindegy, hogy egy byte tömb ToString()-ét írod ki, vagy simán a string-et. Nem ugyanaz...
    Mutasd a teljes hozzászólást!
  • Mondjuk C# alatt ez valamivel egyszerűbb:

    var lines = System.IO.File.ReadAllLines("file.txt"); foreach(var line in lines) Console.WriteLine(line);

    Vagy ha kicsit többet szeretnél írni:

    using (var sr = new StreamReader("TestFile.txt")) while ((var line = sr.ReadLine()) != null) Console.WriteLine(line);

    Azaz a dolog nem a típusosságon múlik.

    Hasonló dolgokat szvsz javához sem telik túl sokba csinálni, más kérdés hogy ennek gyárilag is a keretrendszerben lenne a helye.
    Mutasd a teljes hozzászólást!
  • Ez az egy dolog engem is idegesit jávában. (mindennek input/output stream meg buffer). Tényleg nagyon átháthatalanná teszi az amugy egyszerü dolgokat.
    Mutasd a teljes hozzászólást!
  • És mibe kerül a java-s pályád elején létrehozni egy saját osztályt, ami végrehajtja mindezt, hogy utána már csak meg kelljen hívni?
    Mutasd a teljes hozzászólást!
  • Én annyit szeretnék hozzátenni ehhez a vitához, hogy gyengén típusos nyelvekkel dolgozok (főként PHP). Szívesen dolgoznék erősen típusos nyelvekkel, viszont amíg egy fájl megnyitása pl. Java-ban ennyi (és az importokat még be sem másoltam, persze egy jó IDE megcsinálja helyettem):

    Path file = ...;
    InputStream in = null;
    in = file.newInputStream();
    BufferedReader reader = new BufferedReader(new InputStreamReader(in));

    Addig PHP-ban ennyi:
    $file = fopen("file.txt", "r");

    És nem azért részesítem előnyben az utóbbit mert lusta vagyok, hanem mert sokkal könnyebb átlátni, karbantartani, módosítani, nem kell egy egyszerű fájl megnyitásához 3 objektumot létrehoznom.
    Mutasd a teljes hozzászólást!
  • Szerintem nem értetted meg hogy mire gondoltunk. Ha van egy form, akkor miután átment a validáláson, nem vizsgálgatjuk, hogy az adatok milyen típusúak.

    Nem, te nem érted, hogy miután egy form adatai átmentek az ellenőrzésen, típusuk kötött és nem változik, hiszen elnyerték végleges, a program ill. a feldolgozás célja szempontjából értelmes natív belső alakjukat. Innentől kezdve a tény, hogy a típusuk ill. a tárolásukra használt változók típusa automatikusan átalakul egyik formáról a másikra semmi előnyt nem rejt, hiszen a típusátalakítást igénylő fázis már mögöttünk van - ugyanakkor, ha egy elírt utasítás vagy más programhiba folytán ez mégis szándékolatlanul megtörténik, az komoly kockázatot rejt magában az adatok biztonságát illetően. Szigorúan típusos programnyelvek esetében ez nem fordulhat elő - dinamikus nyelveknél viszont igen. Ergo, egy dinamikus nyelv esetében sokkal kevésbé garantálható az adatok biztonsága a rendszerben szándékolatlanul - pl. a programozó figyelmetlensége folytán - előforduló vagy szándékosan előidézett - pl. hackerek által kiváltott - hibák miatt és azokkal szemben.
    Mutasd a teljes hozzászólást!
  • Szerintem nem értetted meg hogy mire gondoltunk.

    Ha van egy form, akkor miután átment a validáláson, nem vizsgálgatjuk, hogy az adatok milyen típusúak. Nem érdekel hogy az email valóban egy sztring. Az sem érdekel hogy a születési dátum valóban dátum típus, hiszen a születési dátum több (tuti dátum, de nem 200 éves, és már megszületett, stb). Az sem érdekel hogy a jelszó valóban egy sztring, mert ha 666 a jelszava, akkor legyen az.

    Vegyünk mondjuk egy regisztrációs űrlapot. Például le akarom tárolni hogy a regisztráláskor hány éves a delikvens. Tudom a születési dátumát, validálom, hogy valóban egy lehetséges születési dátumot kaptam. Ekkor kiszámolom hogy a mai dátumhoz képest hány teljes év telt el. Nem számítok rá, hogy a 2 dátum közötti teljes évek száma egy a betű lesz. És vagyok olyan bátor, hogy nem is validálom ezt az információt, hanem fogom és berakom az adatbázisba mindenfajta vizsgálódás nélkül.
    Mutasd a teljes hozzászólást!
  • LC, Szaky: Ezt csúnyán bebuktam. Remélem, nincs harag.

    De ennyi erővel akár azt is fel lehet hozni hibának, hogy $a, $b, $c változókat is létre lehet hozni, és ha valaki ezt használja


    Hiba is, csak sajnos fordító szintjén javíthatatlan, mert néha az olvashatóságon javítanak az egybetűs paraméternevek. (Pl.: ciklusváltozó.)

    Az a szememben nagyobb hiba, hogy a PHP-változókat nem kötelező deklarálni használat előtt. Kit zavar egy var vmi?

    Az epic error pedig a Python osztálydefiníciója, de ez nagyon off-topik lenne...

    Az, hogy gyengén típusos egy nyelv, az egy dolog. De hogy miért nem kell a változókat előre deklarálni és miért kell órákig keresnem a félregépelésből fakadó hibákat, azt soha nem fogom megérteni.
    Mutasd a teljes hozzászólást!
  • engem pl halálra idegesített, amikor javaban irtam egy Springes házit, akkor 15 másodperc és másfél perc között mászkált a fordítási és webszerver indítási idő.


    JRebel?

    a Java - XML se valami nagyon típusos.


    Java - XML?
    Mutasd a teljes hozzászólást!
  • De hát épp ezt írta. Leellenőrzi, hogy az input email-e és nem nézi hogy szám-e. Mert minek?

    De bakker, nem is az emailnél kell nézni, hogy szám -e (az emailt épeszű ember soha nem is akarja számmá konvertálni) - hanem fordítva: a számnál kell nézni, hogy nem -e az email címét írta oda be a delikvens.

    Ezt pedig úgyis csak úgy tudod megcsinálni ha számmá alakítod - akkor viszont értelmét veszti az az "érvelés", hogy de hát azért jó a gyenge típusosság, mert "webes alkalmazásnál úgysem alakítasz semmit sehova az adattípusok között". Mert dehogynem alakítasz - csak éppen nem tudod azokat az előnyöket és biztonsági garanciákat kihasználni, amik abból erednek, hogy a program egy bizonyos pontján - ti. a szóban forgó átalakítások/ellenőrzések után - már minden adat abban a formában (típusban) áll rendelkezésedre, amely megfelel az értelmének, és nem alakulhat át valami misztikus körülmények között a feladat szempontjából értelmetlen típusúra. Amire dinamikus típusok esetében sajnos semmi garanciád nincs.
    Mutasd a teljes hozzászólást!
  • Két ok miatt gyorsabb, az egyik, hogy nem kell törődni KONKRÉTAN a típusokkal. Tehát senki nem fog belehalni, ha "345" jön int 345 helyett, ezáltal a sok user inputot nem kell parseolni meg castolni össze vissza. (Ugye ezek a nyelvek legfőképp ilyen helyeken elterjedtek: python, ruby, php )


    Azt hiszem, ez a gányolás legpontosabb definíciója.
    Mutasd a teljes hozzászólást!
  • Téves, pont én vagyok a Magányos Cowboy. Egy személyes céggel. Ennek több előnye is van:
    1. Igazán profikból marha drága összehozni egy csapatot.
    2. Nem igazán profikat meg tovább tart idomítani mint amíg magad megcsinálod a kódot. Ráadásul amit csinálnak az is gyakran kihívásoknak néz ki a megbízhatóság terén (tapasztalat).
    3. Így általában saját magam dönthetek az épp használt platformmal, technológiával kapcsolatban, ez a szakmai fejlődés szempontjából jobb.

    Ugyanakkor jó 20 éve vagyok a szakmában, jó pár évet lehúztam a PHP-hoz hasonló típus nélküli nyelvben fejlesztve (dBase/Clipper, Visual Basic, illetve maga a PHP) illetve különféle típusos nyelvekkel (C/C++, Object Pascal, C#, némi java). Mindkét oldalon leírtam már jó pár tízezer sort, azaz van összehasonlítási alapom hogy miben milyen kódolni és minek mi a következménye.

    Ugyanakkor egyszemélyes cégként vannak olyan dolgokkal kapcsolatban is tapasztalataim hogy milyen érzés az amikor supportálni kell egy programot, illetve ha esetleg vissza kell nyúlni egy 6 évvel ezelőtt írt kódba mert közben megváltozott valami, és csak pár órád van arra hogy átlásd mit kell csinálni mert közben más határidős dolgod is van. Ez esetben jobb ha minél több dolgot bízol a számítógépre, és minél kevesebbet saját magadra.
    Mutasd a teljes hozzászólást!
  • A bevitelt minden esetben validálni kell

    De hát épp ezt írta. Leellenőrzi, hogy az input email-e és nem nézi hogy szám-e. Mert minek?
    Mutasd a teljes hozzászólást!
  • Egy webes alkalmazásnál nem alakítasz semmit sehova az adattípusok között ( PHP ), egyszerűen csak elmented mondjuk a DB-be. Majd az átalakítja.

    Na, látod, ebből keletkeznek az SQL-injekciós sebezhetőségek, az inkonzisztens adatállapotok, a - felhasználó számára - kriptikus adatbázishibaüzenetek, az XSS sebezhetőségek, stb.

    A bevitelt minden esetben validálni kell, magában a programban, nem pedig az adatbáziskezelőre bízva azt. Utóbbiban esetlegesen meghatározott megszorítások (mind értéktartományra, mind referenciaintegritásra és hasonlóra értve) legfeljebb egy plusz védelmi vonalat jelenthetnek, de nem képezhetik az adatok érvényesítésének elsődleges módját. Nem csak azért, mert az azon a szinten definiálható ellenőrzések tipikusan igen korlátosak, de azért is, mert azok csak az egyes mezők szintjén érvényesülnek, és még egyes rekordok belső összefüggéseinek korlátozására sem alkalmasak (nem ám, hogy a teljes adatmodellre érvényes korlátok kikényszerítésére), ráadásul a legritkább esetben adnak módot a felhasználó számára is értelmes és valóban hasznos visszajelzés (hibaüzenetek) definiálására.

    Márpedig a programban történő validálás első, és legelemibb lépése, hogy ha már valamit eleve esetleg nyers sztringként tudok csak bekérni, akkor átkonvertálom a megfelelő típusra - de ennél sokkal tovább megy a dolog, hiszen minimum-maximum hosszt, értéket, stb. minimum kell ellenőrizni. Éppen ebből kifolyólag az, hogy a nyelv automatikusan konvertál a típusok között neked teljesen irreleváns, mert neked úgysem szabad erre hagyatkoznod, viszont ha ez jelen van, az szándékolatlanul is rengeteg programhibához és biztonsági réshez vezethet. Főleg, ha a nyelv mindezt még olyan hülyén is csinálja, mint a PHP, amelyikben a "1 kutya + 2 macska" sztring kifejezés integerré castolt értéke 1.
    Mutasd a teljes hozzászólást!
  • Az a baj, erre nem tudok mit válaszolni. Elfogadom amit írsz, sőt, lehet hogy igazad is van, én mégsem így látom.

    Egy webes alkalmazásnál nem alakítasz semmit sehova az adattípusok között ( PHP ), egyszerűen csak elmented mondjuk a DB-be. Majd az átalakítja. Persze ellenőrizni kell, hogy mondjuk, hogy szám ( is_numeric talán ), típusosan mondjuk így nézne ki: try - parse - catch, de általában ezek az ellenőrzések túlmtuatnak azok, hogy szám-e. Hanem mondjuk htmlt kell kiszedni, vagy emailcímnek kell validálni, és sokkal kényelmesebb, hogy a rendszer átkonvertálja neked stringbe-számba, mert a szám úgyis elbukik, mert nem emailcím, és html nélkül a szám szám(string) marad.

    Most már ott tartunk, hogy PHP-ban meg lehet jelölni az Object típusát a paraméterben (elég hülyén, ezt nem tagadom, pl null-t nem lehet átadni ), tehát a tévedési lehetőség megmaradt a számokra és stringekre, amik között a rendszer konvertál.

    nova76: valóban, symfonyból még csak a sandbox appot láttam, de ott ez a helyzet nem állt fent
    Mutasd a teljes hozzászólást!
  • Két ok miatt gyorsabb, az egyik, hogy nem kell törődni KONKRÉTAN a típusokkal. Tehát senki nem fog belehalni, ha "345" jön int 345 helyett, ezáltal a sok user inputot nem kell parseolni meg castolni össze vissza.

    Már bocs, de ez óriási zöldség. Egyrészt igenis törődni kell a típusokkal, hiszen a bemeneteket mindig ellenőrizni, érvényesíteni kell, ami többek között úgyis mindig magában foglalja a kvázi a céladattérbe/típusba történő átalakítást. Innentől kezdve az ellenőrzés kódolási szempontból sem jelent semmi pluszt. (Főleg, hogy típusos nyelvnél eleve tudsz egy adott típusban olvasni adatot, ill. legkésőbb az RTL, a vizuális osztálykönyvtár és hasonlók biztosítanak neked olyan metódusokat, amikkel eleve egy adott típusa kényszerítve/ellenőrizve tudod az egyébként megbízhatatlan és generikus felhasználói bevitel eredményét is lekérni, helyből).

    A másik irányba szintén igaz a dolog, mert az gyakorlatilag sosem fordul elő, hogy a felhasználónak közvetlenül, nyers valójában prezentáljuk az adatot. Tehát egy dinamikus nyelvben pl. hiába is tudom elméletileg helyből hozzáfűzn egy sztringbe az integer típusú kifejezést, változóértéket is (az automatikus típuskonverziónak köszönhetően), ezt ugyanis a gyakorlatban normális programokban sosem használjuk ki, hiszen a számot formázzuk, tízedesre kerekítjük, igazítjuk, paddingoljuk - innentől kezdve meg ott vagyunk, ahol egy szigorúan típusos nyelvben is lennénk (ti. hogy egy vagy több függvényt, metódust rá kell eresztenünk az adott kifejezésre, változóra, ráadásul típusa függvényében, a formázáshoz). Tehát itt sem spórolunk semmit a szigorú típusosság hiányával sem fejlesztési, sem futási időben.

    Ugyanakkor a másik oldalon a szigorú típusosság hiánya rengeteg hibalehetőség forrása, amelyek lekövetése ráadásul nehézkes, pont azért, mert a hibajelzést nem az úgymond a hiba tényleges keletkezésének helyén kapod (tehát ahol érvénytelen adattartalom kerül egy adott változóba), hanem csak sokkal később, ahol egy az adott tartalmon/-típuson már érvénytelen műveletet akarsz végrehajtani. Ebből adódóan, még ha plusz kódolási munkát jelentene a típuskonverzió, akkor se lehetne kijelenteni, hogy összességében lassítja a fejlesztést, hiszen nagyjából már az első a típusproblémákra visszavezethető bug lekövetése során elvesztenéd az első legalább 100 típuskonverzió lekódolására "elpazarolt" időd, és hosszú távon biztosan úgy járnál rosszabbul, ha kihagynád azokat. Tehát ezen a ponton sem spórols semmit a gyenge típusosság, sőt, komoly program esetében egészen biztosan a szigorú típusosság nyer.

    A harmadik dolog, hogy már maga a program kódjának megírása is sokkal gyorsabb egy szigorúan típusos nyelvben, azon egyszerű oknál fogva, hogy a dinamikus típusosokhoz nem lehet normális prediktív IDE-t írni, hiszen (kód)szerkesztési időben nem állapítható meg pontosan egy adott referencia, változó, azonosító típusa (sőt, még szkópja se ha a dinamikus típus ráadásul még a deklaráció kikényszerítésének hiányával is párosul). Tehát ebben a vonatkozásban is elmondható, hogy a gyenge típusosság az ami kinyújtja a fejlesztési időt és nehezíti a programozó dolgát, nem fordítva. (Persze ezt nehezen látja meg és be az, akinek valami fapados, maximum szintaxiskiemelést biztosító kvázi szövegszerkesztő volt a legkomolyabb fejlesztőeszköze valaha is - ugye ilyen a PHP-programozók legalább 90%-a.)

    Tehát valójában pont a szigorúan típusos nyelvek azok, amelyekben ugyanaz a (hello worldnél bonyolultabba) program egészen biztosan sokkal kevesebb idő alatt fejleszthető le ugyanarra a stabilitási és megbízhatósági szintre.

    A másik ok, hogy általában nem kell őket fordítani, így rögtön látható az eredmény, ami nagy előny

    Ez persze megint nem igaz, pontosan a fent már említett ok miatt. Ti. hogy ez az "előny" az első olyan hiba esetén elveszik, ami fordítási időben - ha fordított nyelv lett volna amit használsz - már észrevehető, megfogható lett volna. Mint pl. ismeretlen azonosító használata függvényhívásban, példányosításban, hivatkozás deklarálatlan és inicializálatlan változó értékére, ciklusváltozók újrafelhasználása egymásba ágyazott ciklusokban, stb. Az ilyen hibák miatti felesleges futási menetek szintén minimum annyi időt elrabolnak, mint amennyit a fordítással megspórolsz - de inkább többet.

    Ráadásul a nem fordított nyelveknél még az is előfordulhat, hogy ilyen hiba az úgymond production kódba is bekerül ill. benne marad, azaz ügyfélhez is kimegy egy egészen biztosan, deklaratív hibás program. Ami nem csak ciki, de - lévén éles rendszerről és adatokról beszélünk már itt - komoly veszélyt jelent adatbiztonsági szempontból is.

    Arról már ne is beszéljünk, hogy az, hogy meddig fordul valami, teljesen eszközfüggő. Nyilván vannak ilyen szempontból szutyok nyelvek és eszközök, mint pl. a C és a C++ amik irdatlan sok időt vesztegetnek (nagyrészt feleslegesen) a fordításra, meg vannak normálisabbak is, mint pl. a Delphi vagy a C# amik esetében villámgyors - és akár még a program pusztán startupjához képest is elenyésző időigényű, tehát nagyjából irreleváns faktort képező - tud lenni irdatlan mennyiségű kód fordítása is.

    Szóval ha valamit, azt nyugodtan leszögezhetjük, hogy nem igaz, hogy a dinamikus típusokkal dolgozó nyelvekben gyorsabban lehetne fejleszteni - sőt, egészen biztosan sokkal lassabban lehet ugyanazt a minőségű és mennyiségű kódot lefejleszteni. Ugyanakkor az ilyen nyelvek használata igen komoly - és a legrosszabb, hogy felesleges, erősen típusos, fordított nyelveknél már fejlesztés közben megszüntethető - veszélyt jelent az adatbiztonságra, és úgy mellesleg az egész rendszer rendelkezésreállására is. Ha van előnye a dinamikus nyelveknek, akkor nem az, hogy gyorsabban lehet fejleszteni velük.
    Mutasd a teljes hozzászólást!
  • A másik ok, hogy általában nem kell őket fordítani, így rögtön látható az eredmény, ami nagy előny, mert engem pl halálra idegesített, amikor javaban irtam egy Springes házit, akkor 15 másodperc és másfél perc között mászkált a fordítási és webszerver indítási idő.


    Ha viszont Symfonyban fejlesztenél, akkor nem is lenne olyan sok az a 15 másodperc. Egy cache ürítés után 1,5 perc is előfordul egy bonyolultabb oldalnál.
    Mutasd a teljes hozzászólást!
abcd