Weblabor

Egy dolgot felejt ki a szerző: nem csak azért dolgozunk modern script nyelvekkel, mert az élvezetesebb, hanem azért is, mert ezekkel az eszközökkel gyorsabban tudunk fejleszteni, és egy ideje már a résztvevő emberek órabére a legdrágább tényező egy projektben. Vagyis jobban megéri több/gyorsabb szervert venni, és ezeken lassabb kódot futtatni, mint C-ben agyon optimalizált kódot gyártani tízszer annyi emberóra alatt.

Ez most ugye nem komoly? Az egy dolog, hogy fordítsuk le az alkalmazásokat, de a futtatókörnyezet legalább egy fajta védőréteget von a gép elé. Valószínűleg elég keményen meglepődnének a hostingcégek, ha egyszer csak egy forkbomb következtében némileg lerohadna pár dolog... (Tudom, PHPban is lehet csinálni, de legalább le lehet tiltani.) Szóval C-ben webalkalmazást írni... nem hatékony, nem hordoz annyi pluszt, hogy megérje és legfőképpen nincs az az Isten, hogy rendszergazdaként ilyet futtassak, hacsak a kód előtte át nem ment valami jobb fajta belső auditáláson.

(Persze, vannak esetek, de akkor is csak részeket írnék meg C-ben, pl keresőt vagy hasonlót, de nem az egészet. Egyébként meg tegye föl a kezét, aki úgy gondolja, hogy tudja, hogy kell C-ben biztonságosan programozni.)

A JAVA alkalmazások gyakorlatilag natív sebességgel futnak (köszönhetően a legtöbb platformra elérhető JIT fordítókra). Ezekívül a (szubjektív, de valamiért úgy érzem tizen-valahány nyelv után valamennyire kompetens vagyok) lehető legszebb, legkövetkezestesebb nyelvi eszköztárat és keretrendszert használják (soksok év tapasztalattal). Határozottan könynebben használható, mint a PHP - egy kezdőnek kevesebb "megmagyarázhatatlan" hibája lesz vele, mint a PHP esetén, arról nem is beszélve, hogy fordítási-időben kiderül ezek nagy százaléka.

Viszont... egy webapp sebességét általában az adatbázisműveletek határozzák meg. Ha okosakat akarunk írni, találjunk ki egy oylan rendszert ahol a webapp az adatbázis-szerver belsejében fut, vagyis (kölcsönvett metafórával élve) nem egy kulcslyukon át kell kitakarítanunk egy szobát.

Legtöbb eddigi webes projektam adatszükséglete símán beleférne egy szerver 4 gigás memóriájába, mégis megszoksából ragaszkodunk a mysql-hez...

Szerintem kicsit elfogult a cikk, illetve nem vesz figyelembe sok üzleti szempontot. A sebesség önmagában ritkán tud nagyon fontos lenni, és ha az, akkor mindig van lehetőség a kritikus részt valamilyen a célra megfelelő nyelven megírni.

Szvsz az OOP-t csak úgy eldobni, illetve valamilyen elitista dolognak tartani az elég komoly szűklátókörűség. Egyszerűbben karbantartható, áltlátható, befogadható, módosítható egy OOP alkalmazás, és ezek a szempntok általában fontosabbak, mint a teljesítmény.

Ehhez hozzávenném azt is, hogy egy nagy terhelésű site esetén az optimalizáció jelentés része nem az adott programozási nyelvben történik, hanem egyéb rétegekben. Elég komoly rész a DB skálázhatóság, frontend optimalizálás, cahce-elés, különböző egyéb eszközök bevonása (light webszerverek, reverse proxy, message queue stb.).

Az OOP nem csak abból áll, hogy leírhatom, hogy 2.days.ago, hanem egy biztonságosabb programozási környezetet ad, ahol egy csomó hiba lehetőség eleve ki van védve, a kódot készítő fejlesztő elég sok mindent elő tud írni a kódot használónak.

Sima C-t már csak olyan szempontból is érdekes, hogy azért ott hallottam már olyanról, hogy sok idő ment el egy-egy memória szivárgás megtalálására, nem véletlenül lett a C++-ba ezek egy része kivédve.

Manapság egyre fontosabb, hogy egy ötletből minél gyorsabban lehessen egy működő prototípust készíteni, nagyon gyorsan halnak el, születnek újak, nem éri meg sok időt beleölni a fejlesztésbe. Szintén egyre fontosabbak az úgynevezett situational aplication jellegű alkalmazások, amelyek viszonyleg egyszerűek, valamilyen konkrét üzleti igényét megvalósító alkalmazások, amelyeknél az a legfontosabb, hogy minél előbb elkészüljenek. Részben ezt a piacot támadja a Project Zero-ból kinőtt sMash is, amit enterprise felhasználásra szánnak, mégis a feladat jellegéből adódóan script nyelvet tartanak erre a célra alkalmasnak.

Kérdés, hogy lesznek-e ilyenek, illetve ahogy fentebb írtam az optimalizálás nagy része nem a nyelvben történik.

Nem tudok semmi részletet ezzel kapcsolatban, de nagyon meg lennék lepődve, hogy ha egy C-ben írt weblakalmazás előtt nem állhatna rendelkezésre ilyen védőréteg. Kb. nem lenne logikus számomra, hogy ne legyen ilyen.

Már tavaly is volt egy olyan post, hogy készül PHP-hoz kezdetleges JIT fordító, elvileg LLVM alapokon nem is annyira nehéz, és idén is a SoC-ban felmerült, de végül nem fogadták el, de előbb utóbb el tudom képzelni, hogy lesz ilyen.

Ilyen egyrészt nincs, plusz látok ebben egy logikai buktát is. A korai optimalizálás sok esetben fölösleges és veszélyes. Persze érdemes törekedni arra, hogy alapvetően figyeljen erre az ember, és sok elem az ember eszközkészletének része lesz, van amikor tudod, hogy adott megoldás biztosan nem lesz jó. A logikai bukfencet ott látom (nem hozzászólásodra gondolok főleg, hanem visszakanyarodva a cikkre), hogy attól, hogy C-ben állunk neki fejleszteni, attól még nem lesz optimális kódunk, ott is egy kezdő tud biztosan hülyeségetket csinálni.