( lgb | 2013. 11. 16., szo – 22:46 )

Nem lattam :) Csak arra reagaltam, hogy szerinted a software-ek komplexitasa akkor kisebb volt, ezert mindenkeppen joval egyszerubb volt anno a dolog, mint manapsag. En epp a forditottjat velem sokszor felfedezni, ma mar minden r=1 user is programozonak nevezi magat, aki PHP-ben leirt egy kacsacsort valaha is, anno azert ennel komolyabb hozzaallas volt szukseges :) Meg ha egy kepzett pl Java/akarki programozot nezel, sokszor neki sincs fogalma, mit csinal a processzor, mekkora lesz a kod, es hogy ezt akar ezredannyi eroforrassal is meg lehetne irni, csak ma mar nem erdemes (lasd; RAD, mai hw-k kepessegei stb). Anno meg 2 hetig azon ment a gondolkodas, hogy lehet X byte-al csokkenteni a kod meretet, vagy par orajelciklust megsporolni. A mai programozok tobbsege kegyetlenul elverezne ezeken a dolgokon erzesem szerint :)

Mindenestre hiaba latszik - most raneztem kozben - rovidnek a mellekelt forras (okulva barmi hasonlo anyag assembly forraskod/listing szintu meretbol), hidd el, hogy nem olyan trivialis ez. Azt hogy akar te is tudnal ilyet: OK, lassuk. Tenyleg erdekelne, mert azert irtam ezt-azt 6502 assemblyben, neha meg most is elofordul. Sot mintha maga Woz is ugy nyilatkozna, hogy minden elismerese, pedig megsaccolom, hogy nalad es nalam is jobban programozik/-ott 65xx assemblyben ...

Azt fontos azert latni, hogy pont az a szep ebben, hogy akar par byte-nyi gepi kodban is lehet akar tobb het (!) munka is extrem optimalizacios stb kitetelekben, lasd pl 256 byte introkat erdemes megnezni neha C64-re, de nyilvan 1K is erdekes. A mellekelt egyik pdf-t nezve ez kb 10K-nyi kod lehet leforditva (ok, adattal egyutt ami benne van) - ez ebben a mufajban mar nagyon komolynak szamit! -, szoval en siman elismerem hogy ezt nem lehetett egyszeru ennyi ido alatt megoldani.

Viszont, ha szerveznenk ujabb meetinget mint a "multkor" Aprinal, akkor errol is elbeszelgethetnenk ujra szemelyesen is, a stringkezelesi modszerekrol nem is szolva! :-)