Ed Post: Real Programmers Don't Use Pascal
A tegnapi fikázódás után evezzünk nyugodtabb vizekre. Azt minden esetre meg kell jegyeznem, hogy a tegnapi post kiváltó okáról végülis bebizonyosodott, hogy ártatlan - tehát dokumentálva volt - ellentétben több másik metódussal, mellyel aznap találkoztam.
Az idézet gyermekkorom egyik kedvenc írásából származik, amely segített abban, hogy később semmilyen körülmények között ne tanuljak meg Pascal esetleg Delphi programozási nyelveken. Amikor az egyetemre kerültem, akkor több esetben láttam bebizonyosodni, hogy aki egyszer rászokik a paszkálul programozásra, az úgy is marad.
Természetesen ez (akkori) rövidlátásomnak és előítéleteimnek volt betudható. Az más kérdés, hogy a Pascal programozási nyelv tekintetében továbbra is előítéleteim vannak. Amatőröknek - figyelem, nem pejoratív jelző - szánt nyelv, ami az amatőröket szopatja legjobban. :-)
A kitérő után térjek a lényegre. A mai nap belefutottam abba a problémába, hogy az általam használt, előre megírt függvénykönyvtár nem tud mindent, amire nekem lenne szükségem. Mielőtt megvádolna valaki azzal, hogy "persze, a segged alá toljanak mindent, aszt ha nem, akkor ugatol", felhívom a figyelmet, hogy nem hiányosságról beszélünk.
A használt osztályok mindegyike az adatrészeket publikusként tárolja. C++ esetén ezt igénytelennek is lehetne nevezni, de jelen esetben csak így hozzáférhető nagyon sok attribútum. Arról nem is beszélve, hogy a tipikus getAlma, meg setKörte metódusok egyáltalán nincsenek jelen.
Ezekkel a peremfeltételekkel kellett megoldani, hogy egy szép hosszú tömbbe egy másik tömbből másolgassak, persze mindig máshova, pointerek mindenhol. A megoldást a memcpy() és a sizeof() függvények adták, amelyekkel egy sorban le lehetett tudni az egészet. Természetesen mindez két osztály adatmezője között.
Semmi extra, viszont történt egy fontos dolog. A megszokott C++ megközelítés helyett teljesen C-be mentem át. (C++-hoz képest) Low-level megoldás, neki a memóriaterületeknek. És itt lép be a fontos dolog. A stanard C api ismerete nélkül lehetett volna különféle for ciklusokkal erőlködni, megfelelően nagy hibalehetőséggel. Így viszont minden supersmooth.
A fejlesztés harmadik ökölszabálya tehát így szól:
Tudni kell, mi történik egy absztrakciós szinttel alattunk és tudni kell megfelelő módon lenyúlni oda.
Az ilyen lenyúlkálás az esetek többségében nem szép, kellemes és egyszerű megoldás - föntről nézve -, de még mindig szebb, mint amit a meglévő szinten művelnénk a probléma megoldása érdekében.
Kicsit más, de kapcsolódik: Daniel Jalkut: C is the new Assembly.
