tifyty

pure Java, what else ?

Programozási marhanyelv pácban, és birkapásztorok

A lombok kapcsán merült fel a téma ezen a blogon, meg ma reggel, amikor a fiam, aki első éves villamosmérnök hallgató, kérdezte, hogy az egységbezárás kapcsán azért nem piszkálhatunk bele az objektumok belsejébe, mert nem lehet, vagy mert nem ajánlott, nem jó.

Nyelvfüggő. Két fő irányzat van, meg ezek tetszőleges keverékei és verziói, perverziói.

Az egyik irányzat nemes képviselője a kihalófélben levő nyelv: a Perl. Ő azt mondja, hogy semmi sincs védve, ha nagyon akarod, és belenyúlsz kívülről egy objektum belsejébe, akkor rajta. Te tudod mit csinálsz, kaptál fegyvert, lődd magad tökön, biztos arra van szükséged. Nem azért nem jössz be a hálószobámba mert gépfegyver van a kezemben, hanem azért, mert úriemberek vagyunk.

A másik irányzat azt mondja, hogy nem baj ha úriember vagy de azért én bezárom az ajtót. A Java is ilyen. Na jó, pont ezen a blogon megmutattam, hogy néha a virágcserép alatt az ajtó mellett el van rejtve a kulcs, de alapvetően a Java nem perl.

Melyik a jó irányzat? Van-e jó irányzat, és van-e üdvözítő megoldás, vagy mindegyik másra jó? Ragaszkodjunk-e a Java-hoz, vagy ipari környezetben is izzítsuk a Node.js motorokat, és hajrá JavaScript?

Szerintem van jó irányzat a kettő közül, és ez a Java (szerű megközelítés, nem csak ez a nyelv, mint egyedül üdvözítő). És ugyanakkor megvan a helye a perl-nek is. És ez nem ellentmondás, csak a világ bonyolult.

A kibogozás most is, mint az élet nagyon sok, de nem minden területén: maximalizáljuk a profitot. Közgazdaságtan.

Van egy feladat, meg kell oldani. A feladat megoldása ér valamennyit az ügyfél számára. A feladat elvégzése jár valamekkora költséggel. A kettő különbsége a profit. Ha ez negatív a projekt felejtős. Ha pozitív, vágjunk bele. Lehet haragudni a profitra, de lehet haragudni az esőre is: attól az még van, megszüntetni nem lehet. Ha a kialkudott ár pont az, ami a vevőnek megéri, akkor a szállítónál realizálódik a profit, ha ennél alacsonyabb az ár akkor osztoznak rajta, egészen addig, míg az ár meghaladja a költséget. Ha az ár pont a költséggel egyenlő, akkor a profit a vevőé. Tipikusan open source projekteknél a profit a vevő zsebét gazdagítja. Nem fizet, nem is hívjuk vevőnek, “csak” felhasználónak. A vevő az aki fizet. A költség meg valakit terhel. Szponzort, aki valamit, járulékos eredményeket visszakap, mondjuk marketing értéket, vagy olyan kutatási eredményeket, amelyek kiesnek az open source projektből. Vagy csak a fejlesztő érezte jól magát, amíg megalkotta élete programját, amelyikre büszke. Na másszunk ki a gondolati stack-ből, mielőtt még újabb és újabb frame-et nyitok, és egy kivétel kezelésével tudok csak kijutni belőle. Vissza a programozási nyelvekhez: RETURN.

Alkalmazzunk programozónak úriembereket, akik betartják a szabályokat és pontosan érzik, hogy a szabályokat hol lehet, szabad áthágni, úgy, hogy abból még ne legyen baj, és ne burjánozzon el a gaz a pasta kódban az alatt az idő alatt, amíg a kódot el nem felejtjük és olvashatatlanná válik az utolsó archive lyukkártya is. Vagy alkalmazzunk kóding junkie-kat, akik spagetti kódot gyártanak olyan kuszán, amilyen kuszán csak lehet, és inkább próbáljuk meg ezt a “lehet”-et szűkre venni. Junk programozóból több van, könnyebb találni és olcsóbb. Könnyebb lecserélni is, ami csökkenti a személy rizikóját (elüti a villamos, vagy megnyeri a lottót és elköltözik Bora Borára). A rizikó is költség. És a személy cserélhetősége és elérhetősége egyre fontosabb, ahogy halad az idő.

Ebből az következik, hogy rövid programoknál, amik nem élnek sokáig (prototype például) lehet használni úriembereket. És lehet használni olyan nyelveket, mint a perl vagy a php. Vagy hobbi projektnél, ahol elkövetik azt a közgazdasági nonszenszt az emberek, hogy nem gondolnak a profittal. No sebaj, ilyenek is kellenek, pro bono. De olyan programoknál, amelyek komoly értéket képviselnek, sokan használják, nagy költséggel állítják elő, nem jó ez a megközelítés. Ebben az esetben átlagos programozókat kell használni.

Persze az átlagos programozó nem kód junkie. Annál azért jobb. Aki kód junkie azt nem is szabad programozónak hívni. A kettőt az különbözteti meg, hogy bár mind a kettő vét a programozási paradigmák ellen, de a kód junkie-t ez nem is érdekli, mert nem érti meg, hogy ezt miért nem szabad. Ő az aki nem is akarja bekötni a biztonsági övet. Az átlag programozó csak időről időre elfelejti ezt megtenni. És ilyenkor kellenek a seniorok, akik segítenek, figyelmeztetnek, kontrollt adnak, tanítanak, terelgetnek, mint a nepáli birkapásztorok.

És ilyenkor kellenek azok a nyelvek, amelyek nem engedik meg, hogy bemenj a hálószobába, hanem már fordítási időben a lábadra lépnek, és azt mondják, hogy ezt nem! Ez a mező számodra nem elérhető! Ezt nem teheted meg. Ne kívánd felebarátod feleségét, se privát mezőit, se más egyéb jószágát! És ilyenkor elgondolkodik az átlag programozó, hogy hogyan kell elkészíteni a kódot jól. Úgy, hogy ne csak működjön, de olvasható is legyen.

Szóval a programozási nyelvnek olyannak kell lennie, hogy az átlag programozó se lője rendszeresen tökön vele magát. Amikor egy nyelvet megterveznek, akkor nem csak arra kell gondolni, hogy a nyelven hogyan lehet valamit jól megoldani, hanem arra is, hogy hogyan lehet jól elbaltázni, rosszul megoldani egy feladatot. A Java így lett megtervezve. Tiszta, világos, olvasható. Minden az, aminek látszik. Közben a közösség folyamatosan nyomja, hogy legyen flexibilisebb. Vegyen fel nyelvi elemként olyan dolgokat, amik a nyelv tervezése óta fejlődtek ki, mint programozási pattern-ek. Így került bele a nyelvbe a generikus típus. Ami nagyon jó és klassz, és az eredeti tervezési irányba mutat. És így nem került be a nyelvbe az extension method, amit a közösségből sokan kértek, de a józan többség leszavazta. Aztán lombokkal mégis meg lehet csinálni. De nem kell. Megint mászok lefelé a gondolati stackben.

Nah, mára elég belőlem.

System.exit(0);

12 responses to “Programozási marhanyelv pácban, és birkapásztorok

  1. ern0 december 5, 2012 2:21 du.

    Azért PHP-ban (replace to ízlés szerinti nyelv) is lehet úgy programozni, mintha Java lenne. Sőt, kell.

    • v december 5, 2012 2:23 du.

      replace to Prolog ? APL? Forth? 🙂

    • tamasrev december 5, 2012 11:12 du.

      Lehet php-ban fegyelmezetten programozni, de ha ugyanazt javaban csinálod, akkor kétszer annyit adnak érte 🙂

      Másérszt meg, php-ban sokkal könnyebb kivételt tenni valamelyik szabály alól, ha az akkor éppen úgy jobb megoldásnak tűnik. Aztán vagy tényleg jobb, vagy – majd később kiderül – pont lábon lőtted magad.

  2. gabor december 5, 2012 4:24 du.

    Tipikus menedzserfasz hozzaallas; megmondjak, hogy hasznaljanak a koderek Java-t, mert ez a valasztas leveszi a vallukrol a felelosseget. Szarul megy a projekt? Biztos nem a menedzserfasz valasztott rossz technologiat, hiszen minden mas cegnel Java EE-t nyomnak. Egyszeruen egy jo programozonak unalmas, verbose, rugalmatlan, funkciohianyos a Java. Soha nem fognak igazan jo Java kodereket talalni a cegek.

  3. SzaLaci december 5, 2012 4:38 du.

    A jó programozó bármilyen nyelven tud Fortran programot írni. (Vagy ez is változott az elmúlt 20+ évben?)

  4. riviera december 5, 2012 4:39 du.

    a perl-nek megvan a helye, egészen pontosan a kukában. az egyik leggusztustalanabb nyelv ami létezik (még a tcl-t tudnám említeni). a 90-es évek már régen voltak, ezt nem ártana észrevenni.

  5. mindwalker december 5, 2012 8:41 du.

    ha a webes világtól elszakadunk (oké, tudom manapság ez nem menő), akkor a fenti kritériumokat az ada messzemenően teljesíti by desgin.

  6. Mefi december 5, 2012 11:48 du.

    Azért annyiban védeném magam, mint PHP-fejlesztőt, hogy manapság a PHP már közel nem az a konyhanyelv, ami volt pár éve. Nyilván most is lehet használni az egyszerű pistikeWebshop2012 projektek összerakására, de lehet PHP nyelvben is masszív, jó teszt-lefedettségű, fenntartható és fejleszthető alkalmazásokat készíteni.

  7. Csiga december 7, 2012 9:11 de.

    Volt egy feladat, ahol canvasra kellett rajzolni, és az átlagos java programozók ezt a tankönyv szerinti módszerrel oldották meg, tízezressével állítva elő a Color objektumokat (minden pixelhez new), izzott a GC. Aztán jött egy hozzáértőbb és egy BufferedImage data-ba közvetlenül írva megoldotta emberi erőforrás-keretek között. És ezt már más problémák kapcsán is tapasztaltam: az átlagos programozók által készített java projekteknek van egy rejtett költsége, amit a vevő/megrendelő jellemzően hardveres erőforrásban fizet meg.

    Perl-ben ma már átlagos programozók nem programoznak (nekik a php a non plus ultra), így ilyen problémával egy ideje már nem találkoztam. Mondjuk a Perl 6-al a Perl úgy általában kinyírta magát, szóval nem is nagyon fogok…

  8. Attila Magyar (@zeroflag) december 9, 2012 3:06 du.

    Ez a problema szerintem sokkal tagabb mint ahogy altalaban bemutatjak, es tobbrol szol mint instance valtozok lathatosagarol.

    Altalaban csak azt hangsulyozzak, hogy azert nem szabad hozzaferni egy objektum belso tartalmahoz mert azzal elronthatjuk az allapotat, megsertve az invariansat. Ami nyilvan igaz, de ez alapjan meg siman hozzaferhetek egy final fieldhez es nyugtathatom magam azzal hogy ez nem fog elrontatni semmit. Vagy irhatok egy accessort a private fieldhez ami gondoskodik arrol hogy ne rontson el semmit.
    Es ezt meg is szoktak tenni, minden lelkiismeret furdalas nelkul, legeneraljak az accessorokat, mondvan hogy direktbe nem szabad hozzaferni a fieldekhez, de accessoron keresztul mar Ok. Viszont nem Ok, mert ha igy teszunk, azzal noveljuk a csatolast az objektum es a felhasznaloja kozott, megnehezitve a kesobbi lecsereleset, uj implementacio bevezeteset. Valamint ha valtoztatunk egy meglevo implementacion, az a valtozas tovabb fog terjedni a hivo oldalra, es magaval fogja vonni az osszes kliens kod valtozasat is.
    Es ez ellen nem ved a private fieldek lathatosaga, mert accessorokon keresztul is ugyanugy kart okozunk magunknak.

  9. tamasrev december 9, 2012 7:19 du.

    Azt hadd tegyem azért hozzá, hogyha a fieldhez van accessor, aztán az implementációt megváltoztatjuk, akkor elég gyakran meg lehet úgy hákolni az accessort, hogy megtartja a visszafelé kompatibilitást.
    Másrészt persze, minden szavad arany: csak azt publikáljuk ki, amire a klienseknek tényleg szüksége van.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: