LISP vs alkalmazásfejlesztés

Mesterséges Intelligencia: Prolog, Lisp

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/

( turul16 v | 2007. 11. 20., k – 12:08 )

LISP "interpreterek" futás közben állítanak -e elő nativ kódot ?

"jó eséllyel egy komplex interpretert kellett volna írni."
C -arcoknál gyakori megoldás, C kód generálása futás közben majd leforgátás futatás vagy. dinamikus betöltés (dlopen), a ti megoldásotok mennyivel másabb?

Klaszikus MPI megoldások hatékonysága és tietek között érdemes -e összehasonlítást végezni teljesítményre? Vagy ez esetleges teljesítmény vesztések bőven megtérülnek a gyors fejlesztési időkből ?

Nehéz titkolnom :) de,a native kód a kód számomra, ezért Ocaml tűnik számomra szimpatikus funkcionális paradigmát támogató nyelvnek/megoldásnak.
Ocaml vs. LISP , miért jobb a LISP ?

A LISP sajátosságából fakadóan nincs szükség DSL-re, ami jellemzően nem képes elérhetővé tenni az alkalmazás egyébként felépített eszköztárát. Folyamatos bővítésre lenne szükség, ahogy nő a felhasználó étvágya.

Esetünkben, ha osztályként ábrázolnám a települést, mint fogalmat és azon értelmezném a lakosság jellemző fogalmát, akkor csak (defclass settlement attributes: (population type: integer)) kelljen írnom, és evidensen használhassam a (population-of settlement) szavakat minden szinten, teszem azt a felhasználó kalkulációs szabály definiáló funkciójában.

Felhasználó írhatja, hogy: (let ((lakosság (lakosság-of önkormányzat))) (legalább (ha (< lakosság 500) 3000000 1500000) (* lakosság 1380)))

A sok zárjel ne zavarjon senkit, attól tagolt olvasható a kód.

--

Teljesítmény összehasonlításokat mi is végeztünk. Bizonyos esetekben jobb, jellemzően kicsit rosszabb. De a mi kezünkben van minden, azaz ahol szorít a cipő, azt feltárni is könnyű és optimalizálni is könnyű. Erre sor is kerül jópár esetben, ezért kellett jópár nem a skacok által fejlesztett libhez hozzányúlni.

És igen a fejlsztési idő mivel tizede/százada volt egyes komplexebb problémáknak, az bőven kárpótolja az esetleges plusz harver igényt.

--

Ocaml-ot nem ismerem... erről ennyit :)

szerk ->
elbeszéltem melletted, mást értettem funkcionális paradigmán :) én egy funkciónális igénnyel kapcsolatos problémakört, beidegződéseket, megoldásokat értettem, így utólag rájöttem te magával a funkcionális programozással kapcsolatosan használtad.
<-

Funkcionális paradigmából viszont álljon itt egy szép példa:

A fentebb említett lakosság időben változik. Hogyan ábrázolod azt?
(T-sítés lett a technikusz-terminusza a körünkben)

Egy objektum jellemzője időben változhat. Akkor amikor beállításnál és olvasásnál is időkontextust kell mondani.
kb így:
(with-validation "2007-01" (setf (lakosság-of önkormányzat) 100))
olvasáskor is mondhatsz:
(with-validation "2007-01" (let ((lakossag (lakosság-of önkormányzat)))))

Érdekesebb ha több időszak átfedi egymást
(with-validation "2007-01" (setf (lakosság-of önkormányzat) 100))
(with-validation "2007-02" (setf (lakosság-of önkormányzat) 200))
(with-validation-range "2007-01" "2007-02" (let ((lakossag (lakosság-of önkormányzat)))))
a lakosság értéke ez esetben ez lenne(("2007-01" 100) ("2007-02" 200))
ehhez igazábol a values-having-validities koncepciót kellene részletesen taglalni, de az nekem már sok lenne
(with-validation-range "2007-01" "2007-02" (let ((lakossag (avg-lakosság-of önkormányzat)))))
válasz 150 értelemszerűen

És még érdekesebb ha az időkvantálása jellemzőként más és más. A példában havi, de lehet bármilyen egyéb is.

Még egy kicsit érdekesebb ha nem pillanatnyi álapotot kell ábárzolni, hanem valamilyen teljesítményjellegű adatot. Pl népszaporulat. Akkor annak a sebessége érdekes és kiolvasáskor az intergrált mondja meg az adott időintervallumra eső népességgyarapodást.

A lényeg, hogy az ilyen koncepciók beépítése és felhasználása minimális ráfordítást igényel. A fenti kb 1000 sor kódból megoldható (részben meg is lett implementálva, de mivel nem priorizált funkció ráér majdha valamilyen konkrét alkalmazáshoz szükség lesz rá). Innét kezdve nem kell foglalkozni sem ennek a perzisztenciájával, sem a GUI részével, csak annyit kell tenni, hogy jellemző definiáláskor meg kell mondani mi a helyzet az időbeliségével.

Ez csak egy nagyon távlati bemutatása az egyik koncepciónak. Ennél jóval többet filóztunk rajta, hogy hogyan kellene működnie. Asszociációk, több dimenziós kontext, nem csak idő.

Nekem nem biztos, hogy elég a tudásom a válaszhoz, de megprobálom :)

A LISP VM-et teljes mélységben lehet futás közben elemezni. Tudom más nyelven is lehet elemezni - anno egy Java-s toolst láttam működés közben. Azonban a LISP esetén a programkód sokkal jobban tagolt egy imperatív nyelvű programhoz képest, és emiatt sokkal részletesebb, akár a rendszer legmélyéig lefúrni képes, statisztikákat lehet készítettni magával a rendszerrel.

Pl.: (+ 1 1) összeadás, meg lehet viszgálni mennyi időbe kerül a "+" függvény használata a rendszer egészét nézve.

Egy anekdóta: a cl serializere pont amiatt lett lecserélve, mert lassúnak tűnt egy alvó process felélesztése, és mint kiderült a continuation-ben játszott szerepe miatt az egyik okozó ő vala.

A Scheme, Lisp, Smalltalk, Factor, Haskell és egyéb dinamikus nyelvek már rég nem interpretáltan futnak. A compiler része a rendszernek, ami rendes assembly-re fordít és az fut. A type system habár dinamikus attól még compile time mindenféle ellenőrzéseket végez. Ha például a Haskell compiler type error-t jelez az igen nagy valószínűséggel egy program hiba, míg ugyanz C++/Java/C#-ban gyakran csak azt jelenti, hogy még nem magyaráztad meg rendesen a compilernek, hogy az a kód úgy jó ahogy van.

Compiler ügyben csak hogy egy optimalizációt említsek: az hogy valami egész típusú még nem jelenti azt, hogy be kell férjen 32 vagy 64 bitbe, de azt sem hogy folyton a heap-en kell foglalni. Ha a szám elég kicsi akkor benne van egy CPU regiszterben, ha nem akkor a heapre kerül. Ez transzparens, tehát írhatsz olyat, hogy:

(iterate (for i :from 0 :to 1000000000000000000)
(print i))

és amíg az i belefér addig másik kód path (gyorsabb) fut, amikortól nem onnan meg a heapen tolja.

Hogy melyik a legjobb implementáció arra nem tudok válaszolni, mivel nem ismerem mindegyiket nem beszélve egyéb peremfeltételekről (hardware/software platform support, ingyenes, nyelvi featurok, compiler, stb.)

Scheme: http://en.wikipedia.org/wiki/Scheme_%28programming_language%29
CL: http://en.wikipedia.org/wiki/Common_Lisp
Lásd az implementáció szekciókat.

DSL: eszembe jutott egy jó példa: hogyan szervezhetsz például ciklusokat egy Common Lisp-ben írt library! segítségével. http://common-lisp.net/project/iterate/doc/index.html

Természetesen ez is assemblyre fordul, annak ellenére hogy ez csak egy lib.

levy

( asch v | 2007. 11. 20., k – 12:43 )

Bevallom, nem ismerem a LISP-et.
Szerintem ha zsenik dolgoznak szinte bármilyen eszköz arannyá válik a kezükben :-).
Kicsit kalandor megldásnak tűnik: Egy projekt menedzser sem szívesen megy bele rövid határidővel nem kijárt úton történő fejlesztésbe.
A probléma az szokott lenni, hogy nem csal zsenik vannak és nem is feltétlenül egy személy által átlátható a problémák mérete.
Úgyhogy annyiban egyet tudok érteni, hogy ameddig kezelhető méretű a probléma, addig pár ügyes ember nem ipari szabvány módszerekkel rendkívül hatékonyan tud dolgozni. Nagyobb problémáknál sajnos abból kell dolgozni ami van, egy nagyobb csapatban nem nagyon van lehetőség csupa zsenit alkalmazni és "ügyes" megoldást adni a beváltak helyett.

Nem leszólni akarom, valószínűleg sokan álmodozunk arról, hogy ilyen módszertannal fejleszthessünk. Viszont általában a kockázat miatt ezt nem támogatja a vezetés... Amit valahol meg lehet érteni.

Számomra ez dogmatikus szemlélet :)
Amiatt, hogy abból indulsz ki, hogy egy nagy projekt 20-30 fő és azok között nagy a szakmai képességbeli szórás. Voltam jópár ilyen projekten.

Csakhogy a projekt mérete a megoldandó feladat és az alkalmazott technológia függvénye. Ha igaz az az állításom - erre fogadnék is ;) -, hogy a skacok által létrehozott frameworkben a munka kb 10x hatékonyabb, akkor a nagy projekt mindjárt 2-3 főre olvad. A koordinációs veszteség megszűnése miatt legyen 2 fő. Tehát 2 okos ember kell 20-30 átlagoshoz képest. Költségben is kisebb mégha dupla annyit is keresnek.

Másrészt ki mondta, hogy LISP-ben nehéz programozni. Annyira egyszerű, hogy esetünkben az alkalmazásra fordított munka több mint fele elmélkedésből állt. Az implementáció csupán bűvészkedés a zárójelekkel :)

szerk

Problémakör méretéről

Nem találkoztam még pályafutásom során olyan problémával, amit egy ember nem bírt volna áttekinteni. Az más kérdés, hogy konkrétan olyan emberrel sem találkoztam, aki adott esetben ténylegesen átlátta volna az adott - és tényleg nagy - projektet a legmélyéig. De ennek nem az adott illető képességeinek korlátja volt az oka, és nem is a rendszer komplexitása, hanem az, hogy szellemi kapacitásának nagy részét lekötötte a koordinációs tevékenység (mikor 100adjára kell elmagyarázni ugyanazt a dolgot mindenkinek, valakinek többször is, ahelyett, hogy a problémával tudna foglalkozni). Ezért nem akarok a saját szakterületemen projektvezető lenni soha. 2-3 embernél ha mindenki elég okos/önálló és nincs koordináció kényszer, akkor az eddigi projekteimet el tudom képzelni úgy, hogy a legapróbb részletekbe is bele tudjak látni.

Kockázatról

Igen ez nehéz kérdés. Informatikai vezetők rendszerint a hátukat/állásukat is védik egy beruházási döntés meghozásakor. Emiatt az iparági dogmákat nem nagyon merik megsérteni, hiszen a legfontosabb érv a döntésük hellyességének indoklásához az jelenleg, hogy ez volt a piacon a legjobb, mindenki így csinálja. Ettől függetlenül van létjogosultsága más technológiáknak, pláne ha töredékáron tudják ugyanazt nyújtani. Számomra ezért a legfontosabb hozadéka az említett projektnek a referencia volt.

Tökéletesen egyetértek veletek a módszerben :)

Az én tapasztalatom általában is az, hogy az emberek számával nagyon nem lineáris kapcsolatban van a fejlesztési idő csökkenése egy projecten. Általában az is elmondható, hogy a leggyengébbek irtózatosan le tudnak lassítani egy projectet.

A jövő valszeg az lesz, hogy egyre többen rájönnek majd, hogy sokkal jobban lehet haladni 2-3 kompetens fejlesztővel, mint egy regiment közepes programozóval.

A lényeg, hogy egyre hatékonyabb eszközök léteznek már (ilyen lehet a tiétek is, de van azért más is :) ) ahhoz, hogy néhány kompetens fejlesztő szinte kizárólag a problémára koncentrálva oldjon meg feladatokat. A programok elkészítése egyre kevesebb és kevesebb hagyományos értelemben vett kódolást igényel manapság.

Amúgy ahogy írsz a módszereitekről, úgy nézem, nagyrészt alkalmazzátok az extreme programming 12 legfontosabb elemét.

( ssikiss | 2007. 11. 20., k – 14:35 )

Szép szép. Amit olvastam és tudok a lisp-ről, az mind nagyon érdekes és vonzó. Néhány megjegyzés és kérdés.

(Dsl téma) Ma már gyakorlatilag minden un szkriptnyelv beépíthető, interfészelhető más programozási nyelven készített alkalmazásba (példák: lua, perl, tcl, többféle c, java vagy javascript közeli dolog). Ezek kevés munkával integrálhatók a fogadóközegbe és többnyire a teljes eszköztáruk használható. Sőt - van nem egy, amit kifejezetten beágyazásra terveztek.

(Keretrendszer) Jól értem, hogy a keretrendszeren, aminek a használatával megvalósult végül is a projekt - 2 éve kezdtetek el dolgozni? Azért ennek fényében kicsit máshogy kell értelmezni a 3 hónapos tervezés/fejlesztés/tesztelés időt. Nem tagadom, így is nagyon impresszív - ez mutatja a nyelv kifejezőerejét és a csapat éjszakázási skilljeit.

(Pénzügy) Miért kellett olcsón megcsinálni, az iparági árazás töredékéért? Azt értem, hogy a megrendelőnek miért jó :), de nektek miért? Az extra rövid határidő éppenséggel extra árazást feltételezne.

(Fejlesztési módszertan) Nyílván, ha egy adott nyelvre/nyelvi környezetre nem igazán húzható bevált/"menő" módszertan, akkor valami mást kell csinálni. A felhasználóval való gyakori kommunikáció meg az elvárásokhoz közelibb produktumot eredményezhet. Ez ok. Egy olyan csapatban, ahol mindenki programoz, kevesen fognak terveket írni meg diagrammokat rajzolni - ez tény. :) Ilyen kis csapatban ez tud működni. A nyelv és a résztvevő koponyák erejét mutatja, hogy sikerült valami használhatót összehozni.

DSL.
Azt nem kétlem, hogy a scriptnyelven belül maradva annak teljes eszköztára elérhető. A kérdés az, hogy a beépített/interfészelt scriptnyelvből eléred a fogadó nyelv összes szolgáltatását? Illetve mindenhol használhatod-e?

A LISP-ben egy nyelv "beágyazása" olyan szintű integrációt jelent, hogy attól az egész továbbra is egy nyelv marad. Esetünkben a JAVAScript (és html) a GUI miatt használt, és a kódban teljesen vegyesen lehet használni mindkét nyelv elemeit. Erre példát remélem majd betesz ide valami rendes kódoló a csapatból (én nem vagyok az), de valahogy így néz ki (html:b (lakosság-of önkormányzat)) azaz egy bodyba bele az lakosság száma.

Keretrendszer
A keretrendszert 2 éve - egy kivétellel félmunkaidőben - tolják elsősorban a többiek. Ez a munka azért volt, hogy legyen a jővőben egy olyan fejlesztői és alkalmazásfuttató környezet (esetünkben a kettő ugyanaz), amivel majdan lehet dolgozni. Ez a framework még fog bővülni - van egy csomó elnapolt ötlet - de elméletileg többet nem kellene vele foglalkozni. Mostantól indulhatnak az alkalmazásfejlesztések. És a 2 év előre befektetett munka megtérülhet akár 1 év alatt is, ha igaz a produktivítási előny.

A 3 hónap valós idő sem a projektspecifikus részek megoldására ment el. Egyrész itt is javarészt félmunkaidőben dolgoztunk rajta, illetve a befektetett munka fele a framework továbbfejlesztésére ment el, ami később kényelmesebbé teszi a következő projekteket.

A teljes alkalmazás kb. 10.000 sor kódot jelent (felfelé kerekítve és tartalmaz(hat) még olyan részeket, amiket később kiemelve a framework részét képezik majd, illetve olyanokat is amikkel kicsit megelőztük az ügyfél jelenlegi igényeit és jelenleg nem használt.)

A framework már most többet tud, mint az Oracle alkalmazásszerver architektúrája, illetve az Oracle új frameworkje (ezeket ismerem, többiek jópár egyebet) a 2 év munkát azok fejlesztésével kell összehasonlítani.

Pénzügy
Ha 10x (de legyen 8x) hatékonyabbak vagyunk, akkor van min osztozkodni az ügyféllel. Fele idő alatt, fele annyi pénzért, kétszer annyit lehet nyújtani. És mi még mindig dupla olyan jól járunk ahhoz képest mintha mással dolgoznánk. (Emberhónapban számolva 8 hónapnyi munkára mi 4-et fizettetünk meg, fele annyi idő alatt végzünk és dupla annyit csinálunk meg. Mindenki jól jár.)

Fejlesztés módszertan
Szerencsére az ügyfél részéről nagyon jó koponya volt vett részt a projektben. A módszertanunkat még alakítgatjuk.

Ezzel kapcsolatban irtam valamikor egy szösszenetet (egy nagyobb doksiból copyztam ide), ami nem biztos, hogy most is helytálló, de nagyjából tükrözi az állaspontunkat:

-------------------------

Minden jelenlegi szoftverfejlesztési módszertanban elkülönült lépésként jelen van a specifikáció és az implementálás. Aztán a módszertanok próbálnak megoldást adni ezen két termék - dokumentumok és a ténylegesen megvalósult programok - közötti konzisztencia biztosítására, ami sajnos szinte lehetetlen feladat.

Forward engineering - Reverse engineering. Ezen két kulcsszó köré épülnek különféle modellező, fejlesztést támogató eszközök a probléma kiküszöbölése érdekében. Azonban ezek alkalmazása jellemzően csak további ráfordításokat indukálnak, és a projekt korai szakaszát leszámítva nem is tudnak teljes körű megoldást nyújtani.

A CL-DWIM kihasználva az architektúra reflexív képességét, miszerint a nemcsak a forráskód, hanem a teljes LISP VM futás közben bejárható (megfigyelhető) és elemezhető, képes önmagát dokumentálni.

Ezzel nem a rendszertervezés, modellezés szükségességét kérdőjelezzük meg, csak azt állítjuk, hogy hatékonyabb:
• ha a specifikációképpen – egy erre a célra szolgáló probléma specifikus nyelven – egyből kvázi programkódot írunk,
• és ha dokumentációra van szükség, akkor azt készítse el az alkalmazás saját magáról.

Ehhez szükséges, hogy a programozási nyelv nagyon nagy kifejező erővel rendelkezzen. Szükséges, hogy implementációként közel azonos, de inkább kevesebb szóval/kóddal leírható legyen a probléma, vagy annak megoldása egy specifikáció írásához képest. Ugyanakkor az is szükséges, hogy az implementációt rugalmasan lehessen később változtatni.

Ezzel a megközelítéssel két dolgot is nyerünk. Egyrészt már a szoftverfejlesztés korai szakaszában is rendelkezésre áll működőképes prototípus, amit használva sokkal pontosabb igénylefedésre lesz lehetőség. Másrészt a termék teljes életciklusa alatt biztosított a teljes körű dokumentáltság.

Ezt kibővítjük azzal, hogy maga a fejlesztés egy az alkalmazással teljes körűen integrált projektvezetési rendszer keretében történik, amely a későbbiekben egyben a rendszer változáskövetésének az alapja is lesz. Maga a leendő alkalmazás már a projekt indulásától kezdve mindent tudhat önmagáról. Munkafolyamatokba szervezhetően nyomon követhető, hogy hogyan és mivé válik egy követelmény.

Tényleg erős volt. Oracle technológiával (adattárház is) foglalkozom, illetve magával az Oracle Alkalmazáscsomagjaival, mint tanácsadó/fejlesztő. Lehet vele szépen is dolgozni, de sok esetben olyan megkerülhetetlen korlátokba ütközik az ember, amitől többszörösére nő egy probléma megoldási ideje.

Nem titok, mivel maga a is keretrendszer nyílt forráskodú (mindenki hivő e téren).

Hevenyészett kedvenc fícsőr lista

Szabályalapú jogosultság (ez számomra a legfájobb pontja az Oraclének).
Nincs szerepkör, jogosultság (illetve ha akarod akkor ezek alapján építed fel), csak szabályok, amik alapján eldől mit láthatsz/tehetsz. Pl. Könyvelő a szervezetéhez tartozó számlákat manipulálhatja. Főköyvelő megtehet mindent, amit az alá tartozó könyvelők megtehetnek. Kódban kb 1-1 sor mindkét szabály.
A szabályokat fordítva felhasználva fel teheted a kérdést a rendszernek adott funkcióval ki élhet, ki férhet hozzá adott számlához.

Üzleti logika (szintén nagyon fájó)
Mindentől (GUI, interfész) függetlenül szintén szabály alapokon. Jelenleg before-comit módon (koncepció szintjén in-transaction módon is elgondolkodtunk) az adatbázisvéglegesítése elött ellenőrzi a rendszer. Lehetőség van egy új szabály kialakításakor, vagy meglévő módosításakor azonnal vizsgálni annak hatását, feltárni az abból következő új ellentmondásokat.

Auditálás, verziókövetés, T-sítés
Alapértelmezett osztály és slot viselkedés minták.

Képernyő
MetaGUI-nak hívjuk és amellyel bejárható a teljes alkalmazás modellje (jogosultságrendszer által ellenőrzött)
Ez fejlesztés nélkül egyben lehetővé teszi olyan lekérdezések bevitelét, amiket jellemzően nem szokás formokba. Pl. Ha valaki hozzáfér a számlákhoz, akkor néhány klikk előállítani azon Budapesti szállítók számláit akiknek van 1m-snál nagyobb számlája.
Még van egy csomó egyéb fícsör ezzel kapcsolatban (állapot, átadhatóság, wizard), de nem akarok hülyeséget írni.

Munkafolyamat (continuation)
100%-osan ki tudjuk elégíteni a WfMC szabványát, még az olyan nyalánkságokat, hogy a runtime derül ki milyen folyamatnak kell mennie, azaz a user viszi be a folyamat leírását, majd el is startoltatja.

Szerkesztés
Editing-context fedőnéven. Többszálon való adatmanipulálás, akár egyazon GUIn. Pl user számlát visz be, rossz a szállító neve, akkor azt a számlától függetlenül módosíthatja. Ehhez sem kell formfejlesztés, alapszolgáltatás.

Sok van még. Igaz jópár csak prototípus szintjén, bizonyítandó, hogy meg lehet csinálni (A próba kedvéért egyszer összedobtunk egy OLAP szerű lekérdezést). Ha majd egy konkrét esetben szükség lesz rá (vagy valaki hajlandó megfinanszírozni), akkor lesz megcsinálva.

Ha nem baj a bátyám nickjével szólnék hozzá, habár én nem ő vagyok... ;-) Kicsit itt-ott erősnek is érzem ezt a business/framework dumát, mert szerintem programozói szempontból nem ez a lényeg.

A zsenizést kéretik mellőzni, mert azért attól igencsak messze vagyunk! Az tény, hogy van némi tapasztalatunk különféle programozási nyelvekben többek között Lisp, Scheme, Prolog, Haskell, Smalltalk, Slate, C/C++, Java, C#, SQL, stb. Továbbá dolgoztunk egy bizonyos projekten, amiből sok tapasztalatott merítettünk ilyen témában. Csak hogy egyet említsek: az hogy a programok forrását még mindig text fileokban tároljuk és gyakorlatilag kicsit felokosított text editorokkal szerkesztjük elég gáz.

Jómagam jelen pillanatban is dolgozom például C++-ban és Java-ban, no és persze lisp-ben, így van rálátásom a dologra és az én megítélésem szerint oriási a különbség.

Ha van konkrét kérdés lispel kapcsolatosan szívesen válaszolok, ha tudok.

levy

Általános scripteléshez, alap problémák leprogramozására mennyire tartanád hatékonyabbnak egy Python vagy Ruby-val szemben? Apró feladatokra gondolok, mint sima text manipulációk, apróbb algoritmusok, illetve db matatás. A produktivitásra lennék kíváncsi, performanciától eltekintve.

( zoldnap | 2007. 11. 20., k – 17:24 )

Szia!

Vegigolvastam ezt a temat, de megvilagithatnad par peldaval, hogy megis honnan jon az az elony, ami segitsegevel sokkal gyorsabban lehetseges fejleszteni?!

- A DSL-el kapcsolatban elhiszem (nem ismerem a LISP-et), hogy sokkal konnyebben lehet irni benne mint mas mainstream nyelvben. Olvastam a peldat amit az egyik hozzaszolasban irtal. Nehany kutatasi kozponttol vagy hasonlotol eltekintve el se tudom kepzelni, hogy milyen megrendelo az, aki ilyen szinten akarja konfiguralni a rendszert sajat maga... Osszefoglalva, lehet hogy LISP-ben gyors a DSL keszites, de az esetek 99%-ban erre nincs szukseg. A megrendelonek klikkelgetos konfig felulet kell, es jo esellyel meg igy is a fejlesztot keri meg egy-egy komolyabb konfig valtoztatasra.

- Skalazhatosag: nem igazan vilagos, hogy mitol lesz az egesz skalazhato. Nyelvi szintu parhuzamositas? Gondolom nem, mert az meg eleg kiserleti stadiumban van. Akkor pedig gondolom kezzel kinezel feladatreszleteket, amiket lehet parhuzamosan vegezni (pl egy nagy listaban kell valamilyen valtoztatast csinalni) es akkor azt a regisztralt workereknek kiadod. Ilyen frameworkbol mar 1001 van, akkor hol jelentkezik a tobbihez kepest az elonye?

- Hatekonysag? Azt ertem, hogy gyorsan vegeztetek es ezert olcso, de mitol vegeztetek gyorsan?

Nem kotozkodni szeretnek, csak latom hogy irod hogy igy megy ugy jo, en pedig nem ertem, hogy hol az ujdonsag az egeszben, mitol jobb?

DSL

Jelen esetben nem volt alternatíva a klikkelgetéssel konfigurálható felület, mivel jogszabályokban szövegesen megfogalmazott szabályokat kellett tudni leírni, mint kalkulációs szabályt. És a egyrészt annak a szabad szövegnek szabadságfokát lehetetlen lefedni előre gyártott form funkcionalítással, másrészt a jogalkotót (parlament) elég nehéz lett volna rávenni, hogy a mi megoldásunk korlátaiban gondolkodjon csak. És ráadásul ez évről-évre változik és a rendszer szabály igazítását nem szerette volna beszállító cégfüggővé tenni.

Egy kereskedelmi példa mire lehet még jó:
Értékesítési rendszerben valamilyen árkedvezmény konstrukciók kialakíthatósága a követelmény. Formos megoldásban mondjuk klikkelhető, hogy rendelés összege alapján hány százalék a kedvezmény.
A DSL annyival több(jobb), hogy teszem az jön egy olyan későbbi igény: a Budapesti telephelyű szálítók akik az elmúlt évben 10milliónál nagyobb összegben rendeltek, vagy 5 éve folyamatosan évi 5millió felett rendelésük az kap kedvezményt. Ehhez nem kell semmilyen formmódosítás, fejlesztés, hanem rögtön írható be a szabály felhasználó által.

Nem értek azzal egyet azzal a feltételezéssel, hogy jellemzően kell szakértői segítség. Ha elegendő mintapélda áll rendelkezésre a felhasználónak, akkor copy-paste és kisebb módosításokra degradálódik a leprogramozása egy új szabálynak. Ehhez minden cégben található megfelelő képességű ember.

Fegyvertársam mondá vala: A nyelvet szabd a problémára, ne fordítva. Ez a DSL. Olyan szókincset adni a felhasználónak, amit ért és tud benne "programozni".

Skálázhatóság

Lényeg a terhelés szétoszthatósága, és az erőforrások rugalmas bővíthetősége.

Egyik része
Elején nem tudtuk megbecsülni sem, mekkora terhelést jelent ha 4000 user egyszerre nyomogatja a rendszert. Potenciálisan ennyi lehetett volna. Az a problémakör sajátosságából fakad, hogy előállhat olyan csúcsterhelés, amikor mindenki dolgozna, ráadásul kéne mennie a nagy ROLLUP-oknak is.
Skálázhatóság ez esetben: hogyha kell, akkor be tudunk állítani 1 nap alatt mégegyszer ekkora szerverparkot. (Zárójelben az egész alkalmazás környezet leáll és újraindul 1 percen belül - disktől függően.)

Másik része
Feladatok párhuzamosíthatósága.
Pl.:
valahol van x, y, z deklaráció
(progn (pararell (set x (+ 1 1)) (set y (+ 2 2)))
(setf z (+ x y))
Azaz két szálon, akár külön gépen kiértékelt az x, és y, majd ismét valahol a z. Ehhez ennyit kelljen írni és ne többet. Oké, nem mindenhol van rá szükség de ha x és y kalkulációja önmagában 1 óra, akkor már érdekes hogyan terheled az erőforrásokat.

Hatékonyság

Gyorsan végeztünk, mert produktív a technológia. Sajnos meg kell élni, tudom nehéz elhinni bemondásra.
Modellezés, GUI, kimutatás fejlesztés mind-mind nagyságrendekkel gyorsabb. Kisméretű a kód és nagyon jól olvasható (a végére az ügyfél is tudta már olvasni), a debugolás és úgy általában egy fejlesztési/javítási ciklus töredék a többi technológiához képest.

Nincs átírom, fordítom (néha az egész világot újra), felpatchelem a szervert, esetleg újra belépek, újra elgyaloglok a hibához és megnézem most mi van. Egyszerűen futás közben befordíthatsz akár pár soros módosításokat, refresh és ott a változtatás. Ez nem a mi érdemünk, hanem a LISP-nek és az SBCL-nek köszönhető.

De látni, méginkább kiprobálni kell

Kisebb helyesírási korrekcióval :) és absztraktabb példával

(progn (step1) (step2) (step3)) ;; soros végrehajtás
(progn (parallel (step1) (step2)) (step3)) ;; step1 és 2 párhuzamosan, utánuk a 3-ik.

Gyakorlatban ennél kicsit bonyolultabb azért a helyzet, de extra fícsöröket is kap az alkalmazás, pl step1 kész, de step2-nél lehal az azzal foglalkozó node, akkor idővel felkapja valaki más és befejezi.

- Ha jol latom, akkor manualisan kell megmondani neki, hogy miket lehet parhuzamosan vegrehajtani. Ilyen keretrendszer van mas nyelvekre is, bar nem ilyen szep tomor megfogalmazassal dolgozik, de ugyanugy kepes nagyobb kodreszleteket tobb node-n futtatni, failover, stb.

- Miben segit nekem a Lisp, hogyha a step1 es step2-hoz kulso adatok szuksegesek? Nyilvan egy 1-2 egyszeru bemeno parameteru fuggveny eseten ez nem gond, hiszen halozaton atkuldod, de mi van ha valami nagyobb adattabla van a memoriaban? Tehat maga az algoritmus parhuzamosithato, viszont sok, nagymeretu adat egymasrahatas van.
Hogyan fog nekem segiteni a Lisp megtalalni a problema optimalis parhuzamositasat?

Olyan még jóideig nem lesz, hogy a program önállóan kitalálja miket lehet/érdemes párhuzamosan végrehajtani. És természetesen van más nyelvekben is, sőt valószínűleg elöbb, mint LISP-ben. Nem találtunk ki semmit újat. Amit a LISP hozzátesz, az az hogy a kódnak ezen részét - ami mondjuk az alkalmazásszervernek a része jellemzően - is kézben tudod tartani. Esetünkben az egész "feldolgozás-írányító" kb. 1000 sor kód. Azt azért át lehet tekinteni. És ha valamit másképp szeretnél, esetleg egy teljesen új feladatvégrehajtás priorizálási koncepciót szeretnél beépíteni -teszem azt a NAGYFŐNŐK által indított folyamatoknak/processzek az adott clusteren kivágja a többi workert, hogy a cpu 100% az övé legyen - akkor ez meg tudod tenni egyszerűen.

Párhuzamosíthatóság határát mindig is az fogja jelenteni, hogy milyen egymásrahatással vannak a programrészek.

pl.:
(parallel
(progn (step11) (wait-for-step step21 (step12)))
(progn (step21) (wait-for-step step11 (step22)))
)

azaz párhuzamosan kétszálon fusson, de a szálak szinkronizálva vanak valamilyen szinten, mivel step11 és step21 hatást gyakorol (adatok módosít) mind step12-re, mind step22-re.
Erre továbbra is a programozónak kell figyelnie.

A nagyméretű adatmennyiség kezelése másik kérdés. Ez cachelési kérdés. Erre is vannak szép (fél)kész koncepciók/megoldások, de addig nem szándékozunk ezzel komolyan foglalkozni, amíg performancia gondokat nem okoz a hiánya.

Ezt ertem, de nekem az a segitseg, ha a nyelv (vagy keretrendszer, vagy fejlesztoeszkoz, stb) segit magat a problemat megoldani. Nalam az ido altalaban azzal telik, hogy gondolkozom, hogy hogy kell a problemat megoldani (elvi szinten), nem pedig az, hogy a megoldast lekodoljam valamiben.

Sejtem amit mondani akarsz, hogy Lisp-ben vegeredmenykeppen minden feladatot egy arra a celra kihegyezett DSL-ben oldasz meg, es igy gyakorlatilag a hibak egy reszetol maga a fordito ved meg, ebbol jon a hatekonysag egy resze. Ezen kivul jobb kod ujrafelhasznalas erheto el, szinten esetleges komplexebb nyelvi elemek segitsegevel.

Ezzel szemben egy hagyomanyos imperativ nyelvben sokkal egyszerubb kijelentesek vannak, amik kombinaciojabol lehet epitkezni, es az epitkezes soran tobb a hibalehetoseg, esetleg nem lesz annyira atlathato. Nyelvi nehezsegek miatt esetleg a kod ujrafelhasznalas se valosul meg 100%-ban.

Viszont a legtobb nagy rendszert mar OO paradigma szerint fejlesztik, szoval inkabb azzal kellene osszehasonlitani, mint tetszoleges imperativ nyelvvel. Azt sejtem, hogy a Lisp ereje eleg ahhoz, hogy Lisp-ben egy OO rendszert fel tudjak epiteni. Sot, akar teljesen mas, nem OO paradigmak szerint is lehessen fejleszteni.

Ezek utan ami nekem meg nem vilagos:

- A legtobb "egyszeru" informacios rendszer eleg jol elvan az OO paradigma keretein belul, mivel tudja kiboviteni az OO-t a Lisp, hogy erosebb legyen? Es az igy kibovitett OO nyelv mennyire lesz szabvanyos, konzisztens, mennyire tartja meg az altalunk szeretett OO tulajdonsagokat (egysegbe zaras, orokles, polimorfizmus, stb).

- Vannak olyan problemak, amiket az OO kevesbe hatekonyan tud kezelni, ilyenek peldaul a bonyolult matematikai problemak, algoritmusok. A Lisp mit tud kezdeni ezekkel? Epitek ra Lisp-ben egy DSL-t, ezaltal logikusabban, szebben tudom reprezentalni. De maga a feladat egyszerusitesen, a megoldas fele vezeto uton hol tud segiteni a Lisp?

Ahogy az egyik lentebbi hozzaszolasomban irtam, en nyitott vagyok a Lisp fele, de amig nem latok egy webes videoteka szintu alkalmazast benne, addig nem igazan tudom hova tegyem a dolgot. (PHP-ban egy ilyen feladatot egy harmadikos egyetemista megir egy feleves beadando hazi soran..)

Amit a CL és a cl-dwim is tud

- MOP (meta object protocol, lásd CLOS, pl: constraint based change propagation http://common-lisp.net/project/computed-class csak hogy az egyik libünket említsem)
- multiple dispatch (pl: CLOS - Common Lisp Object System) a hagyomanyos single dispatch helyett a meghivott fuggveny nem csak az egyik (azaz a this pointer) parameteren dispatchel
- reflection and introspection (megfigyelés és beavatkozás, pl: milyen member-ek vannak egy osztályban és adjunk hozzá egy újat miközben a program fut)

Többszörös leszármazás, runtime osztálykiterjesztés, mindezek automatikus perzisztenciája (nincs szükség JAVAs Hibernate osztály->tábla mapping leírásra)
itt nézz körül: http://common-lisp.net/project/cl-perec/

Ha kellene belátható munkával megoldható lenne
- prototype based object systems (pl: Slate)

Matematikai lib biztos van hozzá, hiszen jelenleg a LISP nyelv főcsapásiránya a matematikai, logikai problémák kezelése. Mi nem erre fókuszáltunk.

reflection and introspection (megfigyelés és beavatkozás, pl: milyen member-ek vannak egy osztályban és adjunk hozzá egy újat miközben a program fut)

Ilyenre mikor van szukseg peldaul? Hogy menet kozben tagvaltozokat/metodusokat vegyek fel egy mar letezo osztalyba?

Többszörös leszármazás, runtime osztálykiterjesztés, mindezek automatikus perzisztenciája (nincs szükség JAVAs Hibernate osztály->tábla mapping leírásra)

Egy runtime kiegeszitett osztalyt hogy perzisztal? Felveszek ket uj mezot es kiveszek egy regit, akkor azt hogy menti el az eredeti tablaba?

1. Hogy a rendszer leállítása és az érintett osztály újrafordítása nélkül is lehessen azt módosítani. Ez a képesség jellemzően nem business funkcióhoz kapcsolódik, hanem a rendszerfejlesztést könnyíti.

2. lásd cl-perec mintapélda: azaz táblamódosítás automatikusan (http://common-lisp.net/project/cl-perec/showcase.html), a destruktív változás esetén tovább kell lökni a rendszert (http://common-lisp.net/project/cl-perec/confirmation.html). Sajnos itt az RDBMS miatt van egy kis probléma, miszerint ezek a módosítások nem tranzakció izoláltan történnek. De nem rajtunk múlik :)

Hogy miért lehetséges gyorsabban fejleszteni azt nagyon nehéz hacsak nem lehetetlen így ripsz-ropsz elmondani. Kicsit olyan minha mondjuk én csak assembly-ben lennék otthon és anélkül, hogy ismerném a C++ nyelv elemeit és a fogalmak pontos jelentését, úgy kérdezném ugyanezt.

Hogy pár nyelvi dolgot említsek (bocs, de nem fordítom magyarra, mert nem nagyon lehet, de gondolom nem gond):
- lambda (anonymous function)
- functions as first class citizens (nem úgy mint a Java-ban) igazából minden legyen first class citizen, ami annyit jelent, hogy lehet változónak értékül adni, függvény paraméter, visszatérési érték, stb.
- closure (capturing lexical environment) nem keverendő össze az anonymous function-nel
- continuation (full mint pl a scheme-ben vagy delimited mint a CL-ben), CPS transformation
- higher order functions pl: (find x collection :key 'something :test 'egyenlo)
- __NO__ design patterns, ha design patterneket hasznalsz, akkor valami sulyosan hibadzik a programozasi nyelvben, amiben dolgozol. a design pattern az, amit a nyelved nem tud kifejezni, ezert neked kell repetitiv modon kovetned, ahelyett hogy a sziliciumra biznad, ami sokkal gyorsabban es pontosabban teszi ugyanezt
- multiple dispatch (pl: CLOS - Common Lisp Object System) a hagyomanyos single dispatch helyett a meghivott fuggveny nem csak az egyik (azaz a this pointer) parameteren dispatchel
- prototype based object systems (pl: Slate)
- MOP (meta object protocol, lásd CLOS, pl: constraint based change propagation http://common-lisp.net/project/computed-class csak hogy az egyik libünket említsem)
- kód=adat (ez a lispnél jobban sehol se teljesül)
- quoting and quasi quoting (pl: C++-ból C++ kódot generálni a legnagyobb halál (Java detto), nézd meg ugyanezt lisp-ben
- macro system (source code transformers) és itt nem a C++ macroira gondolok, mert az egy vicc
- runtime code evaluation and generation (compile és eval)
- embedding and mixing DSLs with the core language (regular expressions, pattern matching compiled to assembly)
- reflection and introspection (megfigyelés és beavatkozás, pl: milyen member-ek vannak egy osztályban és adjunk hozzá egy újat miközben a program fut)
- mixing programming paradigms in one language (functional, side effects, declarative, pl: egy lisp-ben irt prolog program compile time fordul CPS transzformációval assembly-re és nem interpretálva fut)
- REPL (read eval print loop) sokan nem is gondolnák, hogy ez milyen fontos, írod a kódot, aztán egyszer csak gondolsz egyet és meghívsz egy függvényt (amit éppen írsz mondjuk), hogy megnézd működik-e vagy esetleg az editorod folyamatosan mutatja, hogy a tesztjeid passolnak-e
- etc.

És még sok-sok apróság, némi angol nyelvtudással és a Google segítségével utána lehet olvasni a témának. Egy dolog fontos, amit nem ismerünk azzal nem is gondolkodunk, így könnyen lehet, hogy nem látjuk a lehetőségeket, másként fogalmazva az eszközök és a nyelvek amit használunk megvezetik a gondolkodásunkat.

Ez például egy Scheme bevezető. A Scheme az egy Lisp dialektus, vagyis nagyon rokon nyelvek: http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html

Ha kicsit programozni is akarsz schemeben, akkor a innen letölthető egy open source implementáció:
http://www.plt-scheme.org/

Vagy ha valami eclipse szerűbb IDE-re vágysz, akkor (bár ez elég alpha cucc, de jó irányba halad):
http://www.jazzscheme.org/

Vagy ott van például a Squeak ami egy Smalltalk nyelv aminek a virtuális gépét érdemes kipróbálni, hogy lásd mennyire másként is lehet gondolkodni (nem mondom, hogy jobban) Ahol a programok nem lefordított exe-k (hanem egymással kommunikáló objektumok) és ha egy mail-be belerajzolok egy vonalat, attól az még simán elküldhető úgy hogy az a levél törzsében van és nem pedig attachment.
http://www.squeak.org/

Egy másik tanulságos példa a Slate.
http://slate.tunes.org/

Vagy mondjuk __különösen__ ajánlom Paul Graham (aki szerintem ebben a témában egyszerűen zseniális) irásait:
http://www.paulgraham.com/avg.html
http://www.paulgraham.com/hp.html
szinte az összes többit.

Mi egyébként az SBCL, emacs, SLIME triót használjuk pár customizálással. Ízlések és pofonok, sokaknak nem tetszene azt hiszem. Én használtam már Visual Studio-t, Eclipse-t (forward/backward/roundtrip engineering-et, stb.) és sok egyéb IDE-t, de mégis határozottan egyelőre ez volt a legproduktívabb összeállítás. No nem mintha nem lehetne jobbat elképzelni...

Végezetül álljon itt egy idézet, amit megpróbálok pontosan idézni, a korábbi kollégától eltérően:

Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.
— Philip Greenspun, often called Greenspun's Tenth Rule of Programming[11]

levy

Kicsit olyan minha mondjuk én csak assembly-ben lennék otthon és anélkül, hogy ismerném a C++ nyelv elemeit és a fogalmak pontos jelentését, úgy kérdezném ugyanezt.

Ez ok, sot az altalad felsorolt featurekbol jo nehanyrol tudom is micsoda.. Engem az tudna meggyozni, ha peldaul lathatnam, hogy mondjuk egy 1-2 entitasos webes feluletu cucc, adatbazisba mentessel, input adat ellenorzessel, stb. hogy nez ki lisp-ben Mondjuk egy videoteka alkalmazas.. Ilyet talalok valahol?

"- Hatekonysag? Azt ertem, hogy gyorsan vegeztetek es ezert olcso, de mitol vegeztetek gyorsan?"

Én ugyan nem tudok LISP-ül, de más nyelvvel kapcsolatban van nagyon hasonló érzetem/tapasztalatom.

Szóval azért lehet gyorsan haladni, mert _jó_ a nyelv. Sajnos ezt a jóságot nem is igen lehet elmagyarázni (vak embernek mesélni a színekről), meg kell tapasztalni és meg kell világosodni :)

Tudom erre az a válasz, hogy minden nyelven lehet gyorsan haladni, ha okos/ügyes a fejlesztő. Persze lehet, csak bizonyos nyelveken _még_ sokkal/sokszor gyorsabban. A kolléga éppen erről az élményéről beszél és persze ügyesen promótálja a nyelvet. :)

Azért azt, hogy egy nyelv mennyire jó/hatékony, a megoldandó probléma is befolyásolja. Valamint, hogy mik azok a segédeszközök, kész komponensek, kódok amiket fel tudsz használni a munkához. Ha valaki vállalatirányítási szoftvereket készít akkor biztos könnyen készíti el az n+1-edik példányt, de egy játékprogrammal biztos meggyülne a baja, nem azért mert a nyelv nem alkalmas rá. A zseni programozókról meg annyit, egy közepes szintű programozó sokéves tapasztalattal biztosan hatékonyabb mint egy zseni kezdő (ha egyáltalán mérhető az, hogy ki mennyire jó a programozásban)

A szoftvert két részben vizsgálnám.

Az üzleti rétegben nem sok különbség van alapvetően - leszámítva az AI-t, ami vállalatirányítási rendszerben még nem jellemző. Ez nem lehet gond, hiszen a LISP-re rá is ragadt, hogy valamiféle AI kutatók játékszere. A szükséges alapeszköztárban sem hiszem, hogy sok különbség lenne. Érdemes megnézni azért egy-egy komplexebb stratégia, vagy RPG játék mögötti scriptnyelvet. Azokat LISPben talán még könnyebb is létrehozni.

A megjelenítésben ég-és-föld a különbség. Bár azt hiszem irtak már szoftveres 3D rendering programot LISP-ben és nem is rosszat.

Einstein zseni, meg a többiek akikről anno tanultunk az iskolában. Mi semmi újat nem találtunk ki. Maga a LISP 50 éves, a legtöbb alkalmazott módszer/technológia is évtizedes már. Csak mivel az szoftveriparág kicsit rossz irányba halad, a nagyok közül senki nem hajlandó egy jó megoldásban összefogni az évtizedek során felhalmozott tudást. Van azért jópár hasonló párhuzamos projekt, sőt van aki előrébb jár bizonyos területeken.

( ptury | 2007. 11. 29., cs – 19:13 )

Egy kicsit megkesve (emiatt a topic miatt regisztraltam :-)...

--> wallen, levy!

* Miert/mikor dontottetek (ti es a csapat tobbi tagja) a (Common) Lisp komolyan vetele mellett?

* Mibol/hogyan tanultatok? Mit ajanlanatok masoknak? Mennyi ideje foglalkoztok vele?

* Hasznaltatok-e Pythont nagyobb munkakhoz? Ha igen: most miert nem Python-t hasznaltok? Ha nem: merlegeltetek-e a hasznalatat? Stb.

--> Tobbiek!

Aki erdeklodik a Common Lisp irant, annak nagyon ajanlom Peter Seibel nagysikeru konyvet: http://gigamonkeys.com/book/ Innet .pdf-ben is elerheto: http://www.scribd.com/doc/4095/Practical-Common-Lisp
Ill. a google-nel tartott eloadasa:
http://video.google.com/videoplay?docid=448441135356213813

Hogy mikortol vettuk komolyan? Ha viccesen akarnek valaszolni azt mondanam, amikor megtudtuk, hogy az amit az egyetemen oktattak a lisprol koszono viszonyban sincs azzal ami valojaban. (ez sajnos eleg altalanos) Egyebkent kevesebb mint 2 eve, de kb. 2 honap mulva en mar nem "lattam" a zarojeleket.

Konyveket nem vettunk, helyette inkabb a netet hasznaltuk. Van jo par konyv, pl:

http://mitpress.mit.edu/sicp/
http://gigamonkeys.com/book/
ez megvolt mar az egyik sracnak konyvben: http://norvig.com/paip.html
stb.

hasznald a google-t. Tegyel fel fejlesztoi kornyezetet es irj programot, nezd meg masok hogy csinaljak, debuggold, teszteld, szokd meg a repl-t, stb.

Python: nem hasznaltuk projecthez es nem is valoszinu, hogy fogjuk mert nem hinnem hogy vannak olyan elonyei a CL/Scheme-mel szemben amiert ez megerne. (legalabbis amennyit tudok rola, amivel azert be kell ismerjem nem lennek bent az elso tizben)

Egyebkent merlegeltunk es tobb alternativa volt akkor a szemunk elott. Azt valasztottuk, amirol akkor azt gondoltuk, hogy hosszu tavon a legjobb megoldas. A Scheme volt a masodik befuto, de vegul a CL nyert.

levy

Ha mar tobb eves threadeket cibalsz elo...

If you chose A [ANSI CL], you like raw power in your language. You don’t mind if your language is a bit ugly, due to a lot of pragmatic compromises, as long as you can still write tight code. ANSI Common Lisp is the best language for you!

ANSI Common Lisp traces its ancestry most directly from the ancient Lisp dialects, built on top of millions of programmer hours, giving it incredibly rich functionality.

Sure, it has some baroque function names due to countless historical accidents, but this Lisp can really fly in the right hacker’s hands.

If you chose B [Scheme], you like languages that are clean and elegant. You are more interested in fundamental programming problems and are happy to while away on a beautiful meadow, contemplating the beauty of your code, occasionally writing a research paper on theoretical computing problems.

Scheme is the language for you! It was created in the mid-1970s by Guy L. Steele and Gerald Jay Sussman and involved some soul-searching about the ideal Lisp. Code in Scheme tends to be slightly more verbose, since Schemers care more about mathematical purity in their code than creating the shortest programs possible.

Forras: C. Barski: Land of Lisp

A masodik kerdesre nem tudok valaszolni, mert en nem vagyok a project tagja, csak egy Lisp fan... :) De azt szoktak mondani, hogy a Lisp akkor kifejezoerot ad a programozo kezebe, hogy ezzel szemben minden mas hatranya elenyeszo.

Egyebkent manapsag uj projectre en a Clojure-t ajanlanam, ami szinten egy (viszonylag uj) Lisp varians. Mostanaban nagyon fejlodik, es mivel a JVM-en fut, az egesz Java ecosystem a hata mogott van/lehet.