LISP alkalmazásfejlsztésről
Előre leszögezem nem vagyok nagy LISP guru, így nem biztos meg tudok majd válaszolni minden kérdést. A csapat gerincét adó három ember tudása e téren nagyságrendekkel nagyobb, mint az enyém, azonban sajnálatos módon hiába unszolom őket nem nagyon foglalkoznak azzal, hogy a magyar informatikusokkal megismertessék az eddigi eredményeket. (Azért remélem majd ők is néha-néha válaszolnak az érdeksebb kérdésekre)
(ExBMEs-ek csak annyiban igaz, hogy a fele csapatt ott végzett elég régen, de semmi közünk nincs a NEPTUN-hoz.)
Alkalmas-e "hatékony" (olcsó, gyors és minőségi) alkalmazásfejlesztésre a LISP?
Első megközelítésben a válasz: igen. Mivel a nyelvi alapokat nézve az egyik legjobb programozási nyelv, várható, hogy bármely más programozási nyelvben megoldott feladatot hatékonyabban lehetne megoldani LISP-ben.
Kicsit mélyebben viszgálva a kérdést a válasz: nem.
Nincs olyan általánosan elterjedt/kiforrott fejlesztési framework, ami lehetővé tenné a hatékony munkát. Nincs elég képzett fejlesztő, aki ha lenne is ilyen framework, tudná azt használni. Van természetesen a piacon jópár LISP-es framework (példának okáért http://www.franz.com/products/allegrocl/) de ezek még nem elégítenek ki jópár egyéb követelményt ahhoz hogy igazán hatékony lehessen.
Az általános nem válasz azonban kisebb csoportok, konkrét esetekben mégis igen lehet.
2 éve, amikor a többiek belevágtak a munkába az első igen válasz alapján az volt a mondás (valami ilyesmi vezérgondolat volt, ha jól emlékszem): "Sokat láttunk, sok mindent ismerünk és azokhoz képest a LISP-pel való munka annyival jobb, hatékonyabb, szebb és szórakoztatóbb, hogy a továbbiakban mással nem szeretnénk foglalkozni. Mivel jó fejlesztők vagyunk feltesszük, hogy egy problémát, ha meg lehet oldani más eszközzel, akkor az LISP-ben is meg tudjuk; természetesen jobban, hatékonyabban, szebben és szórakoztatóbban."
A második nem válasz miatt azonban ehhez szükség van egy alkalmas eszközre, amit mivel nincs ilyen még létre kell hozni. Ennek eredménye a cl-dwim framework. Magáról a framework-ről, de méginkább a mögötte lévő koncepciókról oldalakon keresztül lehetne beszélgetni (jómagam 20 éve programozgatok, 10 éve komolyan vállalatirányítási rendszerfejlesztéssel foglalkozom, de ilyeneket még nem pipáltam!).
A harmadik igen válaszra bizonyíték az említett alkalmazás létrejötte, aminek köszönhetően mi magunk egyben az első igen válasz helyességét is bizonyítottnak látjuk már. Sajnos a második "nem" megszűn(tet)ése még váratni fog magára.
A projektről röviden:
A megoldással szemben támasztott három olyan felhasználói követelmény, ami miatt más technológiát "nem kicsit" fájdalmasabban lehetett volna csak alkalmazni:
1. felhasználó által szabadon definiálható számítási képlet alapján kalkulációkat végezni.
2. a megadott képletek alapján adattárház jellegű kalkulációt (ROLLUP) kell végezni emberileg kivárható időn belül
3. gyors, olcsó és minőségi megoldásra volt szükség :)
1. DSL
Magában a LISP-ben a DSL, mint fogalom közvetlenül meg sem jelenik, annyira evidencia, hogy LISP-ben való programozás egyben magának a programozási nyelv bővítését is jelenti.
Más nyelvekben a projekt ezen követelménynek való megfeleléshez jó eséllyel egy komplex interpretert kellett volna írni. Esetünkben a második megbeszélésen (1 hét múlva) mi egy működőképes prototípussal jelentünk meg, amiben olyan fícsörök is voltak már, hogy "ékes" magyarsággal kiírja a kalkulációs szabályt (fél nap volt összedobni az egészet - és nem interpretáltként fut, hanem compiledként, ami a többi követelménynél létfontosságú).
2. skálázhatóság
Igaz, hogy az elején csak halvány elképzelések voltak a konkrét megvalósítást illetően, de nem láttuk technológiai akadályát egy olyan architektúrának, ahol több gép párhuzamosan képes dolgozni a feladatokon (ez egyben a 3. pont olcsóságához is szükséges vala). Részben tehát a projekt alatt született meg a most már framework részét képező node/cluster/worker fogalomkör, aminek köszönhetően az említett hardver működik. Ha kell bővíteni, akkor az csak annyit jelent, hogy rá kell dugni a plussz gépet és már meg is :)
3. hatékonyság
3a gyorsan legyen meg. Volt cirka 3 hónap a tervezésre/fejlesztése/tesztelésre. Belefértek a skacok :), annak ellenére, hogy a munka során a fejlesztési erőfeszítések egy jelentős része a framework új fícsörökel való felruházására lett fordítva.
3b olcsó legyen. Open source szoftverekben (azaz járulékos szoftverköltségek nélkül), mainframe nélküli rendszerben (azaz nem ár/teljesítmény szempontjából rossz hardverben) kellett gondolkodni. Az alkalmazás teljes költsége a megoldott problémakör méretéhez/komplexitásához és az informatikai iparágban jellemző árszabásokhoz képest töredék.
3c minöségi legyen. A rövid fejlesztési idő ellenére azt hiszem minden kivánság ki lett elégítve. A technológia rugalmasságának köszönhetően olyan változáskéréseket is befogadtunk (pár héttel/nappal az indulás elött), amiket jellemzően nem szokás.
Úgy egyébként az alkalmazásfejlesztés menete felrugott minden iparági szabványt. Ennek oka nem az, hogy azokra nem volt idő, hanem az, hogy az alkalmazott technológia új utakat is megkövetel. Nem volt szükségünk különféle, inkább terhes, mint hasznos módszertanokra. Helyette olyan szinten közös csapatként dolgoztunk együtt a megrendelővel, beengedve őket a fejlesztés minden lépésébe, hogy egy ügyféloldali új igény, vagy változást olyannak tekintettünk mintha azt mi találtuk volna ki. Prototípusos fejlesztés netovábbja volt. Mivel dokumentációt maga a rendszer képes előállítani magáról (egyeddiagramokkal, szövegesen), nem volt szükség úgymond előzetes specifikációra (amit aztán költségesen karban is kell tartani). Helyette ha bármi változott, akkor lekérhető az aktuális állapotnak 100%-osan megfelelő.
CL-DWIM projektről:
http://common-lisp.net/project/cl-dwim/