Merhabalar, Belki bazilariniz hatirlar: yakin zamanda, fazlamesai.net'te bir Lisp gerekliydi, gereksizdi tartismasi yapildi. Benim acimdan ilgincti, cunku Turkce bir listede bu tip bir tartismayi daha once okumamistim. Sosyal acidan ilgincti. fakat sadece o degil: tartisma sirasinda Bulent Bey bana Steele'nin "Evolution of Lisp" adli makalesini tavsiye etti. Benden okuyunca ne dusundugumu yazmami da talep etti. Soz verdim asagida o sozumu tutuyorum.
Fakat oncelikle belirteyim: yazi sadece isin egitici/pedagojik yonuyle ilgili, yeni bir tartisma baslatmak, kimseyi elestirmek, vs. icin degil. Sadece makale bana neler dusundurdu, hangi konularda bana ipuclari/bilgi sagladi, neyi buldum, neyi bulamadim; bunlarla ilgili. Makale 100 sayfa kadar (tam versiyonu: ben onu okudum) ve minimal bir Lisp bilgisi gerekiyor. "Bilgi sahibi olmadan fikir sahibi olmak" istemedigim icin yaziyi sverek okudum. Zaman icinde yeniden yaziya donup uzerinde dusunecegim, fakat ilk birkac izlenimimi asagida veriyorum. Basliyoruz... Yazidan Lisp'in tarihcesi (belli bir donemden sonra; makale dogus donemi ve tasarlanma amaci, ilk sekli nasildi, vs. hakkinda pek fazla birsey icermiyor. Baska bir yaziya atifta bulunuyor: onu henuz okumadim) hakkinda bilgi edindim. Yazinin basligindan da tahmin edilebilecegi gibi ;). Standardizasyon donemini de kapsiyor yazi. Burada Common Lisp'in baslica Lisp Machine Lisp (Mac Lisp temelli) ve Interlispi (ama aslinda kimi teknik, kimi politik gerekcelerle daha cok birincisini) buyuk olcude standartlastirdigi filan... Bu kismi ilgincti ve ayni zamanda propaganda degil, gercek anlamda bir tarihce sunuyor. Lisp hakkinda sadece kronolojik bilgi degil, tarihi ve teknik bir perspektif edinmek icin herkes mutlaka bir baksin derim. Yazi bir iki onemli Lispcinin, ama oldukca objektif diyebilecegim bir tutumla kaleme aldigi bir kaynak. Uslup yer yer eglendirici. Benim burada cok detaylara girmemin anlami da imkani da yok. Fakat su kadarini soyleyeyim: kesinlikle Paul Graham'in kiskitici yazilari (bkz. Java hakkinda yazdiklari), veya Erik Naggum'un "klasik" mesaji (su XML ile ilgili olan), vs. hicbir ilgisi yok. Hem uslup, hem icerik onlarla kiyas bile kabul etmeyek derecede ileri ve bilgi yuklu. Benim tum yaziya serpistirilen su "cachet" (albeni) tespitiyle ilgili cekincelerim var. Ne kadar yerinde o tespitler bilmiyorum. Mesela her zaman canim memleketimde gazetelerin secimleri nasil etkiledigi yazilir cizilir: ama bir kez Allah icin tutturduklarini gormedim ;). Sanirim yazarlar biraz sosyal renk katmak istemis yaziya. [Ben tam versiyonu okudum: belki bu paragraflar basilan kopyada yoktur]. Fakat her zaman, bu gibi konularda kesin karara varmadan once degisik fikirleri almakta, yazilari okumakta fayda var. Bir buyuk ve onemli gorulen ozellik olarak CLOS'tan bahsedilmis (albeni unsuru olarak da bahsediliyor): oncesinde ne vardi (Flavors, vs.) diye merak edenler bir liste bulabilir yazida. Yazida standartlastirilan bazi uygulamalarin neden bugun olduklari sekilde karara baglandigini gormek de mumkun. Mesela makro sisteminin gelisimi. Yazidan, Lisp tarihinde belirgin bir AI ve sembolik programlama etkisi ve damgasi (DOE Macsyma) oldugu anlsiliyor. Tabii bunun gercek resmin % ne kadarini yansittigini anlamak icin benim yeterli bilgim yok. Bu konuda uzmanlarimizin goruslerini bekliyoruz. Unutmadan eklemem gereken bir nokta, Lisp'in bizzat bir programlama dilleri ve modern programlama modelleri laboratuvari olarak oldukca etkin olarak kullanilmis oldugu. Scheme, Planner, vs. bu baglamda bir miktar anlatiliyor. Bunlar hep yazida bulunabilir. DUSUNCELER (kimi hiperbolik) Tabii ki bir yazidan kazandiklariniz sadece yazarin ne yazip ne yazmadigi degil, ayni zamanda anlatilanlarin size ne cagristirdigi biraz da. Eger yazi size bilmediginiz birseyler ogretiyorsa, bildikleriniz hakkinda yeniden dusunme ihtiyaci hissediyorsaniz, veya bildiginizi zannettiginiz konulardaki yanlislarinizi gormenize yardim ediyorsa; evet tum bu hallerde yazi sizin icin, bazen yazarinin da kasdetmedigi tarzda faydali olabilir. Ben kendi deneyimimden 3-5 noktayi paylasip, uzerime duseni yapayim. (sirali degil, karmakarisik yaziyorum. Kusura bakmayin artik). 1)CL'de neden "4" floating point precision var? Boyle islerin dogrusu yanlisi olmaz, bir tercih meselesi: fakat neden bu boyle tercih edilmis? Benim icin ilginc oldugu icin aktariyorum: ******************************************* The S-1 was initially intended to be a fast signal processor. One of the envisioned applications was detection of submarines, which seemed to require a mix of numerical signal processing and artificial intelligence techniques. The project received advice from W. Kahan in the design of its floating-point arithmetic, so it ended up being quite similar to the eventual IEEE standard. It seemed appropriate to refine the techniques of the MacLisp compiler to produce good numerical code in S-1 Lisp [Brooks, 1982b]. The S-1 offered four different floating-point formats (18, 36, 72, and 144 bits) [Correll, 1979]. Influenced by S-1 Lisp, Common Lisp provides an expanded system of floating-point data types to accommodate such architectural variation. ********************************************** esasen bu paragraf ve daha bircoklari Lisp'in teknik uygulanabilirlik alanlari hakkinda iyi bir fikir verecektir. En azindan, bu dille programlama yapan insanlarin dusuncelerini... Bu, yakin zamanda Fazlamesai.net'teki tartismada ortaya atilan bazi iddialari da bana hatirlatti dogal olarak. Neyse, ona girmeyelim :) Dedigim gibi, ben bu konuda dogru yanlis aramiyorum, sadece kararin arkasindaki "gelenek" onemli burada: bu karar da daha pekcok karar gibi, daha once ilgili alanda ve kullanici kitlesinde begenilmis ve gunun sartlarinda iyi gorulen cozumlerden kaynaklaniyor. Dilin tarihini bilmeyen biri bunu anlayamaz ve gereksiz itirazlara kolayca basvurabilir. Fakat su anlasilmali ki standartlar gokten inmiyor: bazi meselelerde oncu, ama cogu konuda gozlemci ve hakem olarak gecmisi gelecege tasiyor. Bu cok onemli bir rol: cesitlilige saygi duymali ve tahammul etmeliyiz. Aksi halde hem gecmisle hem mevcutla surekli cene yaristirma ve kavga modunda oluruz. Ustelik, bicak degil el keser: tabii ki bicaginiz keskinse bu daha kolay olur ;). Ben *yine de* bu konuda standardin gozden gecirilmesinden yanayim. Ama cok da onemli degil. Bu arada beni sahsen ilgilendiren bir nokta: Gerry Sussman'in belli bir donemde numerik programlar ve numerik program generatorleri hakkinda calistigindan bahsedilmis. Bu noktayi ben bir yere kaydettim. unutmadim, aklimda :) 2) Bir baska ilginc bolum Scheme ve Lisp makro sistemlerinin gelisim ve karsilastirilmasi ile ilgili. Bu iki sistem birbirlerinden oldukca farkli. Ben birini otekine tercih etme konumunda degilim: fakat Common Lisp'in arkasinda yillarin evrimsel gelismesi, Scheme sisteminin temelinde de ayri kanaldan bir akademik altyapinin ve farkli kaygilarin bulundugunu gorebilirsiniz. Yazida ayrica pekcok referans ve tarihi bir perspektif var: detayli bilgi ve inceleme isteyenlerin ilgili dillerin kaynaklarina bakmasi gerek. Bu arada CL makrolarindaki ,', notasyonu bana sembollerle dusunmekle pointerler uzerinden dusunmeyi karsilastirtti, aradaki farki dusundurttu. Ilgilenenlere siz de bir dusunun derim (exercise ;)). Belki dolambacli bir yol oldu, fark bir problemin en iyi cozumu, sizin icin en dogal olanidir :). Fark temel olarak sembolik programlama ile C-temelli programlama dilleri ile yaptiginiz tarz programlama. Benim altyapim nedeniyle ilk gordugu gun Lisp'i ilginc bulmamin altindaki (suuralti :) ana sebep buydu helhalde, ama pek de uzerinde dusunmemistim makaleyi okuyana dek. Lisp'deki makro sistemi, benim aylar once Lisp'i ciddi olarak gozden gecirme istegimi uyandiran bir konuydu. (C++ template'leri ile ugrasirken)... Sonrasinda ilgim daha farkli bir duzleme kaysa da, orijinal etken buydu. Bunu tetikleyen ise benim o zamanlar kendimi, Bjarne Stroustrup'un gozunden olaya bakip, C++'in beni bir turlu kendisine isindiramayan dizaynini ve o kulturun felsefesini anlamaya calismam, programlamayi yeniden sevmeye ve kendim icin anlamli kilmaya calismamdi. Onun yapamadigini Lisp yapti benim icin. Su anda ben sahsen C++'i cozumun degil, problemin bir parcasi olarak goruyorum. Fakat ozellikle "ne yapmamali?" konusunda cok iyi bir ornek. Bir iki konuda ilginc fikirler icerse de dil, tarihi bir kaza benim gozumde. Amerikalilarin dedigi gibi, YMMV :). 3)Tabii bu makaleyi gercekten okuyup da true / false, T v. NIL hakkinda (ikincisi ilginc olarak bir Lisp implementasyonunun da adi: bununla ilgili bir saka da var yazida. Kendiniz okuyun :)) dusunmemek olmaz. Ben kendi adima bu konuda bayagi dusundum ve kendimce bir sonuca da vardim. Tabii, if ve benzeri yapilar da buna dahil. Ama bu notun ana konusu benim vardigim sonuclar degil, yazinin size hangi yonlerde katki saglayabilecegi. Dolayisiyla ben kendi dusuncelerimi kendime sakliyorum. 4)CLOS hakkinda herkes ne dusunuyor bilmiyorum, ama ben bu sistemi henuz yeterince bilmiyorum. Tek talihsiz (bilmiyorum, belki o kadar talihsiz degildir) nokta, OO paradigmanin tam olarak insanlarca anlsilmamis oldugunu gormem. Bu bana, keske Lisp ve Scheme topluluklari bu konuya daha ciddi olarak egilip meseleye katkida bulunsalar dedirtiyor. Genc arkadaslarimin Paul Graham gibi zatlarin negatif yaklasimindan dolayi bu konu uzerinde dusunmeyi birakmasindan endise ediyorum. Bu gercekten buyuk, inanilmaz buyuk bir kayip bana sorarsaniz. Tekrar CLOS'a donersek, bir yerde sembolik yeteneklere sahip bir programlama dilini bir type sistemi ile tamamladigi icin, ve bu gercekten onemli oldugu icin beni ilgilendiriyor. C ve kardeslerindeki tip sistemleri insanlari yanlis yonlendiriyor: ozellikle benim gibi CS egitimi almamis insanlari. O tarz bir type sisteminin gercekci ve modern anlamda bir type sistemi ile yakindan uzaktan ilgisi olmadigini ben bile gorebiliyorum. C++ kotu bir saka gibi, Java dogru yolda pekcok adim iceriyor gibi. Uzman degilim, ama dikkatlice dusunmeye calisiyorum. CLOS bu resimde nerededir, onu henuz bilmiyorum: firsat buldukca ogrenmeye calisacagim. Fakat acikcasi, makalede bu konuyla ilgili pek doyurucu birsey yok. Sadece birazcik yuzeysel tarih, o kadar. 5) Bir baska olmayan veya benim dikkatimi pek cekmeyen, fonksiyonel programlama ile Lisp arasindaki iliski, bunun meyveleri. Buna yeterince deginilmeliydi. Ben sahsen bu paradigma ile OOP arasindaki ideal sentez nedir, bunu ne kadar biliyoruz; bunlari merak ediyorum. 6)Son zamanlarda yine Fazlamesai'de bir XML - Lisp karsilastirmasi olmustu. Bu temel olarak m-exp v. s-exp. meselesi hakkinda da makalede eglenceli bir bolum var sonlara dogru. Herkese okumalarini tavsiye ederim. Ben, sahsen bu konuda insanlarin birbirlerine toleransli olmalari gerektigini soyleyip geceyim. Gercekten onemli olan fikirlerinizi nasil ifade etmeyi en uygun buldugunuz. Her ikisi icin argumanlar ileri surulebilir. Sunu ekleyeyim: bu konuda da uzun uzun dusundum, hala da dusunuyorum. fakat su var: bir fallback sintakina ihtiyac var. Ve s-exp sintaksi burada rakipsiz. Ben bazi uygulama domainlerinde Algol sintaksinin inkar edilemez avantajlari oldugunu dusunuyorum. Bu konuyu desmeyecegim. fakat bu konuda dogru yaklasim AST - sozdizimi karsilastirmasi yapip o yonden dusunmek degil bence (bu temel olarak fazlamesai.netteki yazida yapilan seydi). Benim icin bunun cevabi, "neden Hilbert uzaylari uzerindeki fonksiyonelleri ikililer olarak, tipki skaler carpim gibi gosteriyoruz?!" sorusu ile ayni (yillar once sorup cevaplamistim kendim icin :). Alt yapisi ve aldiklari egitim farkli olan arkadaslar farkli ornekler versinler dilerlerse. Ama mesele derleyiciyi memnun etmek degil, o sadece bir yan sonuc. 7) Bir baska onemli konu "distributed computing". Bu konudaki cabalar cok kisa geciyor yazida, ama benim fazlasina ihtiyacim var. Bu konu onemli bence. Mesela bir actor model konusu geciyor. Temel olarak closure kavrami olsa da, bu kavramin disinda kalan yonleri de var. Konu dogrudan Lisp ile ilgili degil, ama ben bu actor model yaklasimini ilk bu makalede gordum. Ozellikle scientific computing - distributed computing iliskisinden dolayi beni meraklandirdi bu. Vaktim oldugunda biraz ogrenmek istiyorum. 8) Son olarak... Nasil Turkce deyince sadece grameri kasdetmiyorsak, Lisp deyince de sadece sintaksi kasdetmiyoruz. Lisp bir entellektuel bakisi yansitiyor. Belli bir tarihi, kulturu, iyi destekledigi ve desteklemeyi *secmedigi* paradigmalar var. Sizin belli aktivitelerde dostunuz ve oldukca onemli bir problem tipi ve kumesi sozkonusu oldugunda saygideger bir fikir ifade araci. Ama, bunu kendiniz icin kesfetmeniz gerekli. Lehte ve aleyhte fanatiklere kulak asmayalim. Gerry Sussman'dan bir alintida, "redundant architecture" konusunda bilgisayar dunyasinin radikal adimlar atmasi gerektigini soyluyordu. Ben bunu son derece onemli bir tespit olarak goruyorum (bu alinti makalede degil, yanlis anlama olmasin). Ben bu konuyla programlama kulturu ve paradigmalari arasinda derin bir ilgi goruyorum. Boyle bir yapida C gibi dillerin tum avantajlarini kaybedecegini gormek icin kahin olmaya gerek yok. Umarim bu cabuk olur, zira beyin gucunun boyle bosa harcanmasi gercekten yazik oluyor... Neyse, devirdigim camlar icin ozur diliyor ve goz attiginiz icin tesekkur ediyorum. Saygilar, Nusret __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ cs-lisp mailing list [email protected] http://church.cs.bilgi.edu.tr/lcg http://cs.bilgi.edu.tr/mailman/listinfo/cs-lisp
