"We are happy to announce: our first Lisp production system went online"

Címkék

Még nyáron újságolta flash42, hogy helyi önkormányzatok, kistérségi települések költségvetési tervének előkészítését megtámogató rendszert kezdtek fejleszteni állami megrendelésre ex-BME-sek Common Lispben. A projekt érdekessége nem is elsősorban az, hogy állami szférában keresztül tudtak vinni egy Lisp kódbázisú fejlesztést (punk's not dead!), mindindkább, hogy a teljes rendszert nyíltforrású komponensekből építették fel.

Minap a comp.lang.lisp-re postázott közlemény szerint többek között Ubuntu Linux 6.10 (Edgy Eft), PostgreSQL 8.2, SBCL és Apache 2 képezi a szoftverkörnyezet magját (ez utóbbi várhatóan leváltásra kerül egy lispes terhelés elosztóra). A számításokat 10 darab dual core x86-64 CPU-val és 4 GB RAM-mal felszerelt node végzi, ezek közül jelenleg egy teljesít adatbázis kiszolgálóként.

Hozzászólások

Tényleg nagyon örülök ennek. De azért van egy kérdésem. Nem lehetett volna olyan nyelvet választani, amelynek a hozzáértőinek a száma nem konvergál a 0 felé? Tehát miért éppen a common lisp-re esett a választás?

segítek: ha más nem ért a lisphez, akkor csak ők tudják karbantartani pl. a kódot.

Aki jo programozo, annak teljesen mindegy hogy valamit miben irtak, zaros hataridon belul beletanul barmibe. Egy szinten tul mar (majdnem) teljesen mindegy, hogy valami miben van irva... (Miutan lattal mar hexaeditorban bugot fixelni valakit egy binarisban, majd miutan te is csinaltad, a vilag egesz mas nezopontba kerul. Meg a forraskod es a hasznalt nyelvek fogalma is. :)

Aki meg nincs ilyen szinten, az ne nyuljon egy ekkora rendszerhez, egyedul, sajat kutfobol. Szerintem. Lattam en mar evtizedes C tapasztalattal rendelkezo programozot kokany, lassu bloatware szart irni... C-ben. Szoval "az ellen nem ved".

Arrol nem is beszelve, hogy szokasos (elsore azt irtam, hogy "szopasos", Freud-i elszolasok rulez) jo HUP'erek modjara harom mondatbol kitalaljatok, hogy mennyire szar az az eszkoz, amit valoszinuleg a problemat jonehanyszor korbejaro szakember valasztott ki, majd hasznalt honapokig, ha nem evekig, mielott a hir eljutott idaig. De a hozzaszolok nyilvan jobban tudjak. :) Legjobban a "me' nem PHP-ben irjak"-on rohogok. Az elso ervem mindjart a sebesseg. Aztan ha ezt leszamitjuk, akkor nezzuk meg, hogy a PHP hanyszor lett inkompatibilis sajat magaval az elmult 10 evben. Aztan nezzuk meg ugyanezt LISP-re... Irjuk PHP-ben. Az. Szuklatokor rulez. Meg jo, hogy nem titeket kerdeztek meg. (Mondom a fentieket ugy, hogy ensem irnek semmit LISP-ben, de ez egy masik vita lenne. :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

már csak annyi a kérdésem: mondtam volna, hogy írják phpben?
segítettem a mögöttes tartalom megértésében kevésbé jártas kollégának a mondat értelmezésében, ennyi.
állást nem foglaltam, egyébként nagy ívben teszek arra, hogy ki mit haxol miben.
És amíg nem tudom részletesen, hogy mit csinál a rendszer, addig értelemszerűen nem is fogok. SZemély szerint ennek ellenére picit antipatikus lenne a php számomra ez esetben, annak ellenére, hogy az az egyetlen nyelv, amilyen nyelvben írt forrásba nyugodtan belenyúlok... (amikor a többibe nyúlok bele, mindig izgulok picit:P)

Lispről meg kb. ennyit tudok egyelőre:
WARNING: The following collection of closing parenthesis may cause disorientation in non-Lisp® programmers.)))))
ennek ellenére jó nyelvnek tartom, csak nem tudom, hogy most mire használnám:P

int getRandomNumber() {
return 4; //szabályos kockadobással választva. garantáltan véletlenszerű.
} //xkcd

Amellett, hogy a mondanivalo lenyegevel egyetertek, azert hozza kell tennem, hogy egy nagyobb projektre altalaban kell x db fent leirt uberprogramozo es 100x lelkes kezdo (akinek meg nincs meg a kello absztrakcios kepessege ahhoz, hogy elvonatkoztasson a nyelvtol, kenyelmesebben mozog a megtanultban). Egyreszt az programozoisten nem fog neked reportokat irni, meg szart lapatolni, arra ott vannak a juniorok. Tehat az uberkoder szempontjabol valoban kevesse irrelevans a nyelv, de a juniorok szamara nem. Megteheted egyebkent, hogy felveszel 50x uberkodert a munka elvegzesere, de akkor meg tobb penzbe fog kerulni a dolog.

Masfelol fogva meg a dolgot azert felmerul egy kerdes: azt mar hallottuk, hogy miert nem rosszabb a Lisp mas nyelveknel erre a celra, de azert azt nehezen fogjak elovezetni, hogy miert lesz jobb.

Szerintem:
1) LISP sokkal produktivabb tud lenni mint PHP, ez meg akkor is lemerheto ha az ember nem LISP-et hasznal csak a LISP-bol a tobbi nyelvbe atszivargott nyelvi elemeket, pl. anonymous fuggvenyek, computation on the language, listak.
2) Mindig (=meg jo par evig) lesz olyan ember aki ert LISP-hez.
3) Elobb-utobb minden nyelv a LISP-be konvergal. :)

Kedves DJ!

Igen, léteznek LISP-alapú projektek (bár nem feltétlenül nyílt kódúak), íme két példa:

1.) AutoCAD (AutoLISP-ben megvalósítva),
(Forrás:
http://www.autodesk.com
)
2.) emacs (Editor MACroS) emacs-lispben megvalósítva,
(Forrás:
http://www.gnu.org/software/emacs/
ill.
www.xemacs.org)

Elég lesz ennyi első közelítésben?

En azokat tartom valodi, onallo nyelveknek, amelyeknek letezik un. "self-hosted" forditoja, vagyis a nyelv forditoja kepes leforditani sajat magat, mert ugyanabban a nyelvben irtak. Ja es a fordito lehetoleg kepes legyen gepi kodot, vagy assembly-t generalni, ne csak egy frontend legyen a GCC-hez, vagy valamilyen VM-hez. :) Ezek a kepessegek azert fontosak, mert fuggetlenitik a nyelvet es a hozza keszulo eszkoztarat egy masik nyelvtol, es teljesen onallo eletet elhet, a fejlodese es terjedese csak a sajat implementaciojanak a fuggvenye.

Ettol fuggetlenul letezik rengeteg olyan - az en ertelmezesem szerint - nem onallo nyelv, ami remekul hasznalhato egy csomo feladatra. A kulcs az, hogy az eszkozt a feladathoz valasszuk meg. Ugye. Az asztalos sem furesszel akar megoldani mindent, meg akkor sem, ha lehet, hogy azt a szerszamot hasznalja a legtobbet.

Egyebkent ha mar itt tartunk, a mai mindenttudok OS-ek koraban mar gyakorlatilag majdnem minden csak C + "scripting". Hiszen az OS-eket altalaban C-ben irjak. :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Mind a kettőt ismerertem. Persze csak hallomásból. Ha jól értettem a leírásokból, akkor egyik sem lisp-ben készült, hanem csak keretet ad a lisp szkript futtatásához (lisp interpreter van bennük). Javítsatok ki ha nem így van. Azért ez nem ugyanaz, mint ha tisztán lisp-ben van írva egy önkormányzati rendszer.

3) Elobb-utobb minden nyelv a LISP-be konvergal. :)

Olvastam egyszer vmi összehasonlítást a Lisp és más nyelvek között, amelyikben szerpelt az az érv a Lisp mellett, hogy minden más nyelven írt SW projekt egy bizonyos méret fölött tartalmaz egy teljes értékű Lisp értelmezőt.
Ez így tetszetős állítás, de érvnek nem jó. Ugyanis algoritmikus dolgokat listákkal elég nehéz megcsinálni. És ha főleg algoritmikus feldolgozásból áll a projekt, akkor inkább írjuk Java-ban, maximum ha szükség lesz rá, akkor berántunk egy mások által már megírt parser-t.

De visszatérve az eredeti hírhez ...
2) Mindig (=meg jo par evig) lesz olyan ember aki ert LISP-hez.
És nagyon könnyű megtanulni.

Sajnos az összes általam ismert common lisp implementáció közös tulajdonsága, hogy a memóriában nem szeparálja el a futtatható és az írható területeket.
Nem úgy néz ki, mintha ez foglalkoztatná őket. Ilyen elven működik - mondják.
Az én gépemen sajnos addig nem fog lisp futni, amíg alapvető biztonságtechnikai elvek figyelmen kívül hagyása mellett epül fel.

Szóval szeintem választhattak volna egy normális nyelvet. A PHP az például pont célszerű is lehetne, ha a webre is gondolnának.

Végül is az ő dolguk, hogy mire pazarolják az idejüket. Vagy volt valami lisp-es házifeladat és nem volt más választásuk? Miért nem fortranban írták? Az is olyan tök menő lenne, mert nincs divatban. És végezetül: mi a baj a C-vel? Ja és ha igazán olyan nyelven akarják írni, amihez nem ért más (nem akar rá más időt pazarolni), akkor miért nem írtak maguknak egy saját nyelvet? Az aztán tényleg cool lett volna!

Igazából az interpreteres nyelvektől is irtózom.

Ja és punk helyett hardcore trance inkább... :)

Sok volt a nyavalygás. Azért respect a fiúknak.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

"Our technique allows for code execution on the stack and heap as long as it does not invoke a system call or
LIBC function. A benefit of this feature is that e-NeXSh does not break applications with a genuine need for an executable stack, e.g., LISP interpreters. However, by preventing system-call or LIBC function invocations from the stack or heap, e-NeXSh creates an “effectively” non-executable stack and heap. This is an improvement over true non-executable stack and heap techniques that either break legitimate applications, or require significant effort to allow such code to execute on the stack or heap." [pdf] [abstract]

Alternatív megoldása a problémának, ami védi a sztekket és futtatja a liszpet. A kernel régi, tehát az implementáció maga elavult, de messze nem lehetetlen egyszerre a kettő.

Ha az interpretert jol megirtak, akkor miert zavar teged a futtathato stack?
Ebben az esetben overflow nem lehet. Egy egyerubb interpreter kodja joval kisebb es erthetobb tud lenni, mint egy nagy rendszer tetszoleges nyelven (plane, hogy a LISP meg konnyen is parse-olhato).
Altalanossagban egy interpretalt nyelvet szerintem biztonsagosabbra meg lehet irni, mint egy forditottat.

A PHP-ban megirt oldalak meg nem pont a torhetetlensegukrol hiresek, rossz pelda volt. (Persze az sem a PHP hibaja, nem is a PHP-t torik meg..)
---------------------
AFPer: We've missed you, did you miss us?
Pratchett: Yes, but I think I have time to reload.

"Kicsit" sok itt a hardver.
Egyébként grat a megoldáshoz, kockák vagytok erősen.
Mifelénk ilyen fejlesztésbe biztosan nem ment volna bele senki (60 külső dep forráskód szintű olvasása, azok bugjavítása, részben újraimplementálása ahogy olvasom).