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.
- A hozzászóláshoz be kell jelentkezni
- 2753 megtekintés
Hozzászólások
gratula a keszitoknek
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
Hát télleg nem egy divat nyelv, de nem értem miért kéne, hogy baj legyen, hogy nem php/java/ruby/.net-ben lett írva. :)
---
Ketchup elementál megidézése a sajt síkra
- A hozzászóláshoz be kell jelentkezni
Nem baj, csak kérdeztem, hogy miért ez. Mi van, ha ne adj isten, az ország 3 common lisp-ben értő embere eltávozik? Ki fogja átvenni ezt a projectet? php-s van több ezer, legfeljebb más csinálja, ha a fejlesztő megzakkan. De ebben a nyelvben nincs más, csak ők.
- A hozzászóláshoz be kell jelentkezni
De ebben a nyelvben nincs más, csak ők
Talán pont ezért.
- A hozzászóláshoz be kell jelentkezni
vendor lock-in?
ex bme-sek sok más rondaságot is csináltak már... (pl neptun)
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
vendor lock-in?
Mi van??? Mintha azt irtak volna hogy a rendszer minden eleme nyilt forraskodu.
Vagy legyszi magyarazd el nekem hogy szerinted mit jelent az hogy vendor lock-in.
- A hozzászóláshoz be kell jelentkezni
segítek: ha más nem ért a lisphez, akkor csak ők tudják karbantartani pl. a kódot.
int getRandomNumber() {
return 4; //szabályos kockadobással választva. garantáltan véletlenszerű.
} //xkcd
- A hozzászóláshoz be kell jelentkezni
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?" -=-
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
A PHP-vel kapcsolatban: nem neked celoztam, hanem ugy altalanosan a topicnak. Csak te voltal a szenvedo alany, akinek veletlenul replibe ment. :)
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Kosz. Szoval szerinted ha en keszitek egy rendszert aminek a teljes dokumentaciojat a forraskoddal egyutt atadom neked egy vaskos kotetben es CD-n, akkor az vendor lock-in mert nincs kedved megtanulni?
Tenyleg mast ertunk vendor lock-in alatt, vita lezarva.
- A hozzászóláshoz be kell jelentkezni
Szerinted egy random() helyről előkerített emberke át fogja látni a rendszert?
- A hozzászóláshoz be kell jelentkezni
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. :)
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Látom te értesz hozzá. Tudnál mutatni néhány projectet lisp-ben? Az sem árt ha ki tudnám próbálni.
- A hozzászóláshoz be kell jelentkezni
"Tudnál mutatni néhány projectet lisp-ben?"
Ignotus Mojojojo-ja. :))
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Erre gondoltál :)
http://en.wikipedia.org/wiki/Mojo_Jojo
- A hozzászóláshoz be kell jelentkezni
vagy erre :)
- A hozzászóláshoz be kell jelentkezni
Nyilván erre, de mindig vannak olyanok akik jobban tudják, hogy mire gondol az ember ;)
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Döbbenet. Igaz csak egy kicsit kellet volna kutakodnom. Azt hiszem van alapja, hogy lisp-ben írják.
- A hozzászóláshoz be kell jelentkezni
Sajna hanghordozas nem jon at a weben... ez ironia? Ha nem akkor valaszolok szivesen, ha igen akkor .....
- A hozzászóláshoz be kell jelentkezni
Nem irónia. Még véletlenül sem. Komolyan kérdeztem mindent eddig, mert szeretném megérteni, hogy miért ebben írták (írják).
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
"AutoCAD (AutoLISP-ben megvalósítva)"
Szerintem inkább C++.
Az AutoLISP az AutoCAD-ben használható script nyelv.
"emacs (Editor MACroS) emacs-lispben megvalósítva"
Ez pedig C, az elisp hasonló funkciót tölt be, mint az AutoLISP az AutoCAD-ben.
- A hozzászóláshoz be kell jelentkezni
Ácsi. Az Emacs amiből áll az egy C-ben írt elisp implementáció, ami csak a legszükségesebbeket valósítja meg, de minden más elispben van kódolva. Szerinted bármilyen nyelv, aminek az implementációja C-ben írt, az C + szkripting?
- A hozzászóláshoz be kell jelentkezni
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?" -=-
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
maxima
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
HF: (akit érdekel)
Mely algoritmusnak nincs / nem lehet recursive alakja ?
Turing kompatibilis -e Lisp, Ramgép(asm) ?
Turing kompatibilitás elégséges -e tetszőleges (algoritmikusan) megoldható probléma megoldásához egy kompatibilis eszközön ?
- A hozzászóláshoz be kell jelentkezni
HF kiegészítés:
- makefile-ban lehet-e programot írni ?
- miben egyszerűbb tömörítő algoritmust írni: makefile-ban, vagy mondjuk C-ben ?
- A hozzászóláshoz be kell jelentkezni
Hat mivel Makefile-ban lehetnek szimpla shell-parancsok (sőt!), az első pontra biztosan IGEN a válasz.
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
Szeretek a HUP-ra posztolni, jó, hogy mindig van, akinek fingja nincs a témáról, de lelkesen kommentel bolondságokat.
- A hozzászóláshoz be kell jelentkezni
*5-ös. :-)
- A hozzászóláshoz be kell jelentkezni
"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ő.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"Altalanossagban egy interpretalt nyelvet szerintem biztonsagosabbra meg lehet irni, mint egy forditottat."
Ez a mondat ertelmetlen.
- A hozzászóláshoz be kell jelentkezni
Én értem, mire gondolt.
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
nem tudom, en viszonylag sok lisp-es embert ismerek
--
Bow down and admit defeat. | Old, weak and obsolete.
- A hozzászóláshoz be kell jelentkezni
Viszonyítás kérdése csak. Van akinek a 2 is sok :)
- A hozzászóláshoz be kell jelentkezni
:)
--
Bow down and admit defeat. | Old, weak and obsolete.
- A hozzászóláshoz be kell jelentkezni
Hasonlo okosat kerdek:
OCaml ?
- A hozzászóláshoz be kell jelentkezni
http://paulgraham.com/avg.html
Gondolom ezért :)
- A hozzászóláshoz be kell jelentkezni
Nyitottam a LISP részen egy külön topikot, ha valakit érdekel még a téma ott lehet folytatni. http://hup.hu/node/47334
Az egyik "fejlesztgető"
- A hozzászóláshoz be kell jelentkezni
"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).
- A hozzászóláshoz be kell jelentkezni