Kent Pitman, 2001 yılının sonuna doğru Slashdot camiasının Lisp/Scheme, standartlar, yazılım geliştirme ve diğer konulardaki sorularını cevapladı, merakları nı giderdi. Bir hayli detaylı olan bu soru cevap seansı uzunluğundan ötürü iki bölümde yayınlandı. Birinci bölüm huzurlarınızda...

Kent M. Pitman: Aslında bu soru -1 puan almış ve gereksiz, olta sorulardan biri olarak (troll) olarak kategorize edilmişti ama ben özel olarak bunu arayıp buldum ve cevaplamak istedim çünkü herkes soruyor ve en iyisi buna doğrudan cevap vermek.

İronik olan şudur ki gerekli gereksiz ()'leri kullanmanıza izin veren diller Lisp dışı dillerdir. Sanki o parantez gruplarının hiçbir anlamı yokmuş gibi.

3+(2*5)+7 ile 3+2*5+7 cebirsel dillerde aynı şeye karşılık gelir. Lisp'te biz şöyle yazarız:

Bu size eldeki ifadenin yapısını göstermekle kalmaz aynı zamanda sizi gereksiz öncelik kurallarını öğrenmekten de kurtarır. Söz gelimi -3! kafa karıştırıcıdır çünkü kast edilen (-3)! midir yoksa -(3!) midir bunu anlamanız gerekir. Lisp'te ise parantez yapısı size bunu bakar bakmaz gösterecek şekilde tasarlanmıştır, (factorial -3) ya da (- (factorial 3)) ifadelerini karıştırmanız mümkün değildir.

(+ (* 2 y) x) sözdizimini 2*y+x sözdizimine tercih etmemin asıl sebeplerinden biri ise program yazarken işimi çok kolaylaştırıyor olmasıdır. Program yazarken fare kullanmam ve ifadeler üzerinde ileri geri gitmek, yerlerini değiş tokuş etmek, silmek, vs. için Emacs komutlarından yoğun şekilde faydalanmaktayım. Tüm bu işleri sık sık yaparken fareye hiç ihtiyaç duymuyorum çünkü bu karmaşık gibi görünen sembolik ifadeler parantezlerle sınırları çizilmiş şeyler. Eğer imleci 2*y+x ifadesinin başına getirip bir ifade ilerle dersem acaba bu durumda editör ne yapmalı, 2'ye mi gitmeli, 2*y'ye mi yoksa 2*y+x? Toplam, çarpım, vb. için farklı farklı editör komutlarının bulunması biraz garip kaçardı. Ancak böyle bir şey olmadan editör neyi kast ettiğinizi nasıl anlayacaktı? Lisp söz konusu olduğunda ise birden fazla kafa karıştırıcı anlam yoktur çün her alt-ifadenin kendi başlangıç karakteri mevcuttur ve bu sayede "imlecin önündeki ifade" veya "imlecin bulunduğu yerin hemen ardından gelen ifade" gibi bir tanım yeterli olmaktadır.

Yukarıdaki cevap aynı zamanda neden foo(x) yerine (foo x) yazdığımızı da açıklıyor. Lisp notasyonunda, foo bir ifadedir (expression). (foo x) ise bir alt-ifadedir dolayısı ile onun içindedir. Eğer dışarıda olsa idi kullandığınız metin editörü foo(x) tek bir ifade mi (bir fonksiyon çağrısı) yoksa iki ifade mi (foo sembolü ve onu takip eden bir liste: (x)) anlayamazdı. Bu da imleç foo(x) başında iken 'bir ifade ilerle' talebimizin farklı farklı yorumlanabileceği anlamına gelirdi. İmleç foo'nun sonuna mı gitmeli yoksa (x)'nin sonuna mı? Diğer bir deyişle parantezlerin doğal amacı sınır çizmektir, Lisp parantezleri bunun için kullanır. Çok anlamlılığı engellemek Emacs içinde "klavye makroları" yazarken çok önemlidir ve ben etkileşimli şekilde program yazarken kod dönüşümlerini çok hızlı şekilde gerçekleştirmek için bu tür makroları sık sık kullanırım. Cebirsel notasyonu benimseyen dillerde bu tür klavye makrolarını problemsiz şekilde kodlamak çok daha zor olurdu.

2) Sadece ben değilim değil mi?
demo9orgon

1980'lerde kendi kendime Lisp öğrenmeye çalıştıktan sonra ne zaman "lambda"... ifadesini görsem sırtımdan aşağı soğuk terler boşanıyor, hayalarım karıncalanıyor... Kendime gelmek için C dilinde ve birkaç başka dilde daha "hello world"ün mekanizmasını düşünüp rahatlamaya çalışıyorum.

Lisp ya tam öğreneceğiniz ya da kesinlikle uzak duracağınız dillerden biri. Ben her gün pratik anlamda iş güç yapan programlar yazıyorum ve LISP'teki garip şeyleri gerektirecek şeylerle hiç karşılaşmadım.

KMP: Aslında "hello world"'ü Lisp'te şu şekilde yazabilirsiniz:

(defun hello-world ()
(write-line "Hello, World!"))

Sizi bilmem ama ben yukarıdaki ifadeyi epey sakinleştirici buluyorum.

Ve LAMBDA meselesine gelince, bunu sadece gerekli olduğunu düşündüğünüzde kullanırsınız. Mesela, bir süre sonra insan sadece tek yerde kullanacağı bir fonksiyon için gidip uzun uzun fonksiyon tanımı yazmaktan ve sonra geri dönüp onu çağırmaktan sıkılabilir, şu örneğe bir bakalım:

bu durumda Lisp şunu yapmanıza izin verir:

Bir programcının bunu yapıp yapmayacağı tamamen kişisel tercihine kalmıştır. Bazı insanlar ne olursa olsun ayrı bir yerde, ismi belli olan fonksiyonların bulunmasını tercih eder, bazıları da etmez. Bazen ismini verdiğiniz fonksiyonun saçma bir ismi de olabilir ve böyle bir durumda tek bir kullanımlık fonksiyon için isim uydurma zorunluluğundan kurtulmuş olursunuz.

Gelelim neden FUNCTION değil de LAMBDA dendiğine, bu aslında tamamen tarihi bir sebebe dayanıyor. Buna alışır ve bu şekilde kullanırsanız bir süre sonra size doğal gelir. Şimdi size bir hikaye anlatayım, böylece bunu belli bir bağlama oturtabilirsiniz:

Eskiden, henüz bir bilgisayar bilimcisi olarak kariyerime başlamamışken yani lisede iken Panama Kanalı bölgesinde yaşıyordum. O sırada bilgisayarlar pek yaygın değildi. Aslında, tamamen ABD hükümeti tarafından yönetilen bölgede garip bir kanun vardı, buna göre kimse kişisel olarak bir bilgisayara sahip olamazdı ve bilgisayarların hepsi merkezi olaran Yönetici Muhasebeci Ofisinde bulunmak zorundaydı, böylece bölgedeki ofislere dağılmayacaklardı, kaynak israfı engellenecekti. Bizim okulumuz bu kanunu biraz esneterek üzerinde çalışmamız için bir bilgisayar temin edebilmişti. İşte bu durumdan ötürü bilgisayarlara dair bir şeyler öğrenmek istediğimde şehre iner (Kanal Bölgesinin dışına çıkıp Panama Cumhuriyeti'ne bağlı Panama City'ye doğru) ve orada bilgisayar işi yapan bir şirkete uğrardım. Tabii oradaki insanlar İspanyolca konuşurdu, neyse ki ben de İspanyolca biliyordum. Bana geliştirdikleri programlarını kodunu gösterdiklerinde şok geçirmiştim, kullandıkları dildeki ahantar sözcüklerin hepsi İngilizce idi.

"Bu sizi rahatsız etmiyor mu?" diye sormuştum. Ancak konuştuğum kişi bir hayli bilge bir insandı ve hemen cevabı yapıştırmıştı: "Müzik okuyabilir misin?". "Biraz" diye cevap verdim. "Müzik notalarının üzerindeki forte, sotto voce, vs. türü şeyleri bilir ve anlar mısın?". Başımı sallayarak onayladım. "Peki o sözcüklerin İtalyanca olması seni rahatsız etti mi bugüne dek?" diye sordu. "Hayır" deyip durumu kabul ettim. Bana göstermeye çalıştığı notasyonun tarihselliği ve çok da bir sorun olmadığı idi. Belki de fazlasıyla hoşgörülü idi. Tabii bu olay 1970'lerde geçiyordu, bilgisayara erişebilen insanlar o kadar heyecanlıydılar ki dünya çapında etkili olan bir fenomenin tasarımında kimin dilinden sözcüklerin kullanıldığını pek dert etmiyorlardı.

Bu yüzden günümüzde LAMBDA, CAR ve CDR gibi hala modern Lisp tasarımında yerini koruyan çok gizemli sözcüklere bakınca o müzik notasyonlarını hatırlıyorum. Bilgisayar kültürü her şeyi homojenize etmek için telaşlı bir şekilde hareket ederken ve bunu büyük ölçüde başarmışken bazı şeylerin tarihselliğini bana hatırlatan bu bağlantıları seviyorum.

Scheme ya da Lisp'in beni ilgilendirmesinin asıl sebeplerinden biri çalışma esnasında uygulamaya müdahale edebilmeme izin vermeleri (özellikle de küçük boyundan ötürü Scheme söz konusu olduğunda). Bu özellik sadece önceden derlenmiş ve ağır plug-in'ler aracılığı ile genişletilen uygulamalara kıyasla çok daha büyük bir avantaj. Slashdot okurlarının programlanabilir arayüzleri tercih ettiklerini düşünecek olursak (genel bilgisayar kullanıcı kitlesinden farklı olarak) neden bu tür uygulamalar daha popüler olmuyor?

KMP: Sanırım bu bir eğitim (resmi ya da kendi kendine) meselesi. Özel olarak kendilerine yol gösterilmediği takdirde bazı insanlar bir işi gerçekleştirmek için her yolu dener ya da eğer bir özellik yoksa onu icat ederler. Ancak pek çok insan alternatifleri araştırmaktan uzak durup sadece kendilerine öğretilenleri kabul edip hep onları uygular.

Geçmişte hız her şey demekti. Her komut değerliydi. Herkes mikro verimliliğe odaklanmıştı. İnsanlar mikroişlemcinin kaç çevrimde ne yapacağını hesaplardı ve eğer çevrim kaybı varsa bu oyunun sonu demekti. Günümüzde ise donanım önbellekleri (cache) ve işlem tahmin (prefetch) mimarileri bu tür mikro verimlilik maliyetlerini gideriyor ve programcıdan saklıyor ancak bunu yapamasa bile işlemciler artık o kadar hızlı çalışıyor ki bir programcı mikro verimliliğin yanı sıra makro verimliliğietkinliği de düşünecek zamana sahip. Yani sadece "ne kadar hızlı çalıştığı" değil aynı zamanda "ne kadar akıllıca" çalıştığı ki bu da toplam verimlilik açısından çok önemli.

Pek çok insan Lisp'i "sadece Yapay Zekâ (YZ) için iyi bir dil" olarak tanımlıyor. Evet, Lisp YZ için iyi bir dil. Ancak bu dilin sadece YZ için iyi olduğunu söylemek bu dili bilmemek demektir. Lisp kendi başına YZ yapmaz. Lisp bir programlama dilidir ve YZ araştırmacıları YZ programları yazar ve bu insanlar geçmişte olduğu gibi günümüzde ağrılıklı olarak Lisp'i tercih etmektedirler. Ancak burada işin püf noktası YZ araştırmacılarının çok uzun bir süredir Lisp programlama ortamı geliştiren ekiplerin, şirketlerin başlarının etini yemeleri ve YZ için ihtiyaç duydukları karmaşık, sofistike işleri halledecek yapıları talep etmiş olmalarıdır. Lisp'in bundan ötürü basit bir YZ araç kutusu olmakla kalmamıştır. Bu sayede Lisp dünyanın en karmaşık ve zorlayıcı problemlerini çözmek için kullanılan çok sağlam bir araç olarak yıllar boyunca sürekli gelişmiştir. Lisp camiası "zeki programlama" kavramını destekleme konusunda çok uzun zamana yayılan bir deneyime sahiptir ve bunu etkin olarak yapmaktadır.

4) Standart süreci
by VP

Lisp'in standardizasyonu sürecine katılmış birisiniz, programlama dillerindeki standardizasyon ile ilgili düşünceleriniz nedir? Bu süreçte değişmesini istediğiniz nedir? RAND lisanslama meselesi ve W3C hakkında ne düşünüyorsunuz?

KMP: Sanırım standartlar insanların üzerine geliştirme yapabilecekleri sağlam bir temel sundular ancak modern çalışma ortamında iş dünyasının hızlı değişimlerine cevap veremeyecek kadar yavaş işliyorlar. Common Lisp standardını oluşturmak epey vakit aldı. 1986'da başladık ve 1994 yılında bitirdik, basılması ise 1995'in sonunu buldu. Bir konuda tüm camianın anlaşması uzun sürüyor ve ben bu deneyimin faydalı olduğunu düşünüyorum çünkü ortaya sağlam bir temel çıktı ancak dilin gelecekteki evrimi için konuşmak gerekirse daha az bürokrasi içeren bir süreci benimsemekte fayda olabilir.

Standartların iki bileşeni olduğunu görüyorum: Birincisi bir ismi sabitleştirmek ve böylece o ismin hep aynı anlama sabip olacağını garantilemek. ANSI Common Lisp kalıcı olarak kaydedilmiştir. İsteyen Lisp üreticisi bu standardı kullanabilir ve diğerleri de neyin kast edildiğini anlamak için resmi bir kılavuza sahiptir. İkinci bileşen ise bir işi yapmanın doğru yönteminin camia tarafından benimsenmiş olduğunu iddia etmektir. Bu durum dilin temelleri için faydalı olabilir ancak dil kitaplığı geliştirmek için ne kadar uygundur orası tartışılır.

Dilin temeli için eğer camianın %60'ı bir işi bir şekilde yapmak istediyse ve %40'ı da başka şekilde yapmak istediyse, %60'lık kitle %40'lık kitlenin üzerine çıkar ve camianın %100'ünün kazanan yöntemle iş yapması beklenirdi. Ancak kitaplık seviyesinde %60'lık bir kitle şu kitaplığı, %40'lık kitle ise bu kitaplığı isterse o zaman camia her iki seçeneğe de erişebilmelidir diye düşünüyorum. Lisam camiası geleneksel olarak bu yöntemi izlemedi, hep konsensüs aradı. Scheme camiası ise Common Lisp camiasından çok daha tutucu idi ve sonuç olarak Scheme'deki standardize edilmiş yöntemler Common Lisp'e kıyasla çok daha azdır.

Scheme camiası dilin çekirdeğini tasarlayan komitenin konsensüs sürecinin getirdiği tasarım çıkmazını aşmak için daha gevşek bir yaklaşım benimsemiş ve Scheme Requests for Implementation (SRFI) sürecini kullanmaya başlamıştır. Common Lisp camiasında henüz bu kadar organize bir süreç yoktur ancak benzer bir yapının kısa sürede geleceğini düşünüyorum.

W3C sorusuna gelince, o kurumun büyük bir hayranı olduğumu söyleyemem. Daha önce çalıştığım bir şirketle W3C'ye üye olmuştuk ama bize imzalatılan sözleşmeye göre üyelerin oyları sadece tavsiye niteliğinde idi W3C bu oylamanın aksi yönde karar alabilirdi. Bence bu bir konsensüs sistemi değildir. Her ne kadar ANSI gibi organizasyonların yavaş ilerlediğini düşünsem de sadece hız faktörünü kullanarak bazı şeylerin çözülebileceğini düşünmüyorum. Gerçek anlamda ulusal ve uluslararası konsensüs zaman alan bir şeydir. Mevcut HTML, CSS, XML, XSL ve diğer W3C kılavuzlarını kullanıyorum ancak düzgün bir mutabakat süreci sonunda ortaya çıktıkları hissiyatında değilim. Bence aceleye getirilmiş bir sürecin ürünleri.

5) Heveslilere Tavsiyeler
Anonim

Kent, Common Lisp ile profesyonel programlama yapan şanslı yazılım geliştiricilerdenim. Seni ve ANSI standardını geliştiren herkesi takdir ediyorum. Yıllarca birikmiş bilgileri derli toplu şekilde bir araya getirdiniz.

Lisp'i bana tanıtmana gerek yok ama pek çok insanın bu dildeki güçlü özelliklerin farkında olmadığını biliyorum. Bunun sebebi ise bazı önemli yanlış anlamalar. 'Kültürel yanlış anlama' diye niteleyebileceğim yanlış anlamalar olduğunu düşünüyorum. Pek çok insan etkileşimli bir ortamda, aşamalı derleme, dil seviyesinde içe bakış (introspection) ve gerçek kod/veri denkliği gibi özelliklerle çalışmadığı için (CLOS - Common Lisp Object System ile dünyanın geriye kalanının Tanrı-tarafından-bahşedilmiş nesneye dayalı programlama tanımı inancı arasındaki farklardan bahsetmiyorum bile) Lisp'i güçlü ve özel kılan şeyleri anlamıyorlar. Buna ek olarak bir uygulamayı geliştirme ve sunma sürecindeki lojistik Lisp'te c/c++/perl/java geliştiricilerinden çok farklı bu yüzden de Lisp'i gerçek bir seçenek, bir alternatif olarak görmek çok büyük bir çoğunluk için imkânsız gibi duruyor.

Biraz da bundan bahsedebilir misin, yani Lisp'in karmaşık problemleri çözmede yardımcı olabileceğini düşünenlere ilk başlangıcı nasıl yapmalarını önerirsin? İlk denemeler için mantıklı ve yeterli bir araç seti olarak mesela? Ayrıca Lisp'in sanılanın aksine pratik şeyler yapmak için kullanılabildiğini gösteren birkaç problem ve uygulama örneği verebilir misin?

KMP: Açıkçası ilk söyleyeceğim şey şu: Bir Lisp geliştirme ortamı çekip içine dalmak günümüzde gayet kolay. Xanalys ve Franz gibi büyük şirketlerin önerdiği yüksek kaliteli ve deneme sürümleri ücretsiz olan Lisp geliştirme ortamlarının yanısıra kalite olarak onlardan aşağı kalır yanı olmayan özgür ve açık kodlu Lisp geliştirme ortamları da mevcut. Bunlarla ilgili bilgi Association of Lisp Users (ALU) web sitesinde bulunabilir. Ayrıca kısa bir süre önce satın aldığım common-lisp.info sitesini de bir tür Common Lisp bilgi deposu olarak kullanmayı düşünüyorum. Site şu anda çok fazla şey barındırmıyor ancak Lisp kullanarak çözüm getirilebilecek önemli problem alanlarını listeliyor.

ANSI Common Lisp standardı web belgesi olarak Common Lisp HyperSpec olarak erişilebilir durumda, epey büyük bir belge (yaklaşık 16MB ve 108 kilohyperlink içeriyor buradan çekilebilir). Sanırım standartlar açısından bakılacak olursa okunabilirliği epey yüksek bir belge. Ancak biraz vakit alabilir ve tabii bir öğretici olarak tasarlanmadı.

ALU web sitesinde de kitaplara ve Internet tabanlı Lisp öğretici sitelere bağlantılar var. Paul Graham ve Peter Norvig'in Lisp ile ilgili yazdığı kitaplar Lisp camiasında epey saygı gören eserlerdendir. Elbette başka kitapların da yazılması gerekiyor ve zaten ben de bir süre sonra çıkacak bir tanesi üzerinde çalışıyorum. Geribeslemeler ve öneriler benim için çok faydalı olacaktır.

Yazılımcıların faydalı bulacağı bir başka kaynak da Accelerating Hindsight: Lisp as a Vehicle for Rapid Prototyping başlıklı makalem olabilir. Bu makale bir Lisp programcı kitlesine hitaben yazılmıştır. Senin ikna etmeye çalıştığın kitleyi ne kadar ikna eder bilemem çünkü doğrudan Lisp tarzı notasyona göndermede bulunuyor ancak yine de hevesli programcılar tarafından okunabilir.

Uğraştığınız proje yavaş yavaş bir oyuncak projeden ticari ve büyük bir ürüne dönüşmeye başladıkça bir uzmandan yardım almak sizin yararınıza olacaktır. Şirketim Lisp'e geçmeye çalışan şirketlere danışmanlık hizmeti vermektedir. Büyük müşterilerimden biri The Software Smith benimle tam da yukarıda bahsettiğim sebepten ötürü temas kurdu ve ortaya ikimiz için de heyecan verici bir sonuç çıktı. Benim açımdan onlara yardım edebilmiş olmak, onlar açısından da Lisp'in hangi durumlarda ne kadar işe yarayabileceğini görmek güzeldi. Bu röportajı reklam kampanyasına dönüştürmek istemem ama daha çok bilgi almak isteyenler benimle temas kurabilir ve daha detaylı bilgi alabilir. Eğer danıştığınız konuda yeterince bilgi sahibi değilsem ya da çok meşgulsem çok büyük ihtimalle sizi size yardımcı olabilecek bir uzmana yönlendirebilirim.

Beş altı yıl önce büyük bir Scheme/Lisp hayranı idim ama şimdi Lisp-benzeri pek çok güzel özelliğin Python'da mevcut olduğunu görüyorum. Python bu günlerde epey sağlam destek alıyor. Python'daki Lispimsi özelliklerden birkaçını söylemem gerekirse fonksiyonların nesne olarak yorumlanabilmesi, "kuşatmalar" ("closure"lar), hafıza temizleme (garbage collection), dinamik-ama-güçlü tip tanımlama ve hızlı yazılım geliştirme.

Yine de Lisp'e özgü olan ve Lisp'ten pek çok güzel özelliği bünyesine katan son dönem dillerinde bulunmayan şeyler görülebilir. Ancak bu özgünlüğün tam olarak ne olduğunu telaffuz etmek zor gibi. Lisp'in hala özgünlüğünü koruduğunu düşünüyor musun ve eğer düşünüyorsan hala devam eden bu özgünlük, bu avantaj nedir? Bu kolayca anlatılabilen bir şey midir?

Eğer bir avantaj varsa ancak bu kolay kolay açıklanabilen bir şey değilse ve karar gücüne sahip yöneticilere anlatılamıyorsa o zaman Franz, Harlequin, vs. gibi şirketlerin neden güçlük çektiğini anlamak zor değil. Lisp/Scheme camiası bunu bir problem olarak görüyor mu? (comp.lang.lisp grubundaki bazılarının bunu hiç dert etmediklerini biliyorum ama belki de onlar bir azınlıktır.)

KMP: Sanırım ben de Lisp'in eşsiz olduğunu düşünüyorum ancak böyle olup olmaması onun bir araç olarak faydasını azaltmaz. Lisp ile ilgili en çok beğendiğim birkaç şeyi sayayım ancak sakın bir yanlış anlama olmasın, bu özellikler tabii ki Lisp'in tekelinde değil. Başka diller de bu özelliklere sahip olabilir ancak beni sık sık şunu söylerken duyabilirsiniz: Diller birer ekolojidir. Dil özellikleri a priori (önceden belirlenmiş şekilde) olarak iyi ya da kötü değildir. Bundan ziyade dil özellikleri belli bir bağlamda iyi ya da kötü olabilir. Lisp'i Lisp yapan özelliklerin bir kısmı sahip oldukları özelliklerdir, öte yandan yine Lisp'i Lisp yapan bir başka faktör de bu özelliklerin tutarlı ve sağlam bir bütün oluşturabilmesidir. Bu özelliklerin bir kısmını bağlamı dışına çıkarmak bazen işe yarayabilir bazen de yaramayabilir. Lisp ya da başka bir dile dair gerçekçi deneyim sahibi olmanın asıl yolu onu kullanmaktır.

Ayrıca 1994 yılında yazdığım Lambda, the Ultimate Political Party başlıklı makalede dillerin sadece standartlarda belirtilen semantik yapılarca değil aynı zamanda dili kullanan camia tarafından da tanımlandığı hipotezini öne sürdüm. Bu da şu anlama gelir: Diller sürekli bir değişim, bir akış (flux) içindedir, resmi bir dil tanımında okuyacağınız şey size o çok boyutlu uzaydaki mevcut noktayı gösterir ancak o uzaydaki hız vektörünü göstermez. Bunun için camiayı takip etmeniz gerekir. İki dil tasarım uzayında aynı noktayı işgal etseler bile yani başlangıçta tamamen aynı anlamları taşıyor olsalar bile acaba süreç içinde de böyle mi devam ederler? Sanmıyorum.

Kendi adıma ANSI Common Lisp ile ilgili olarak gerçekten beğendiğim birkaç özellik:

• Lisp dinamiktir. Dünya sürekli değişir ve programların da dünya ile beraber değişmesine izin vermek gerekir. Yeni veya değiştirilmiş fonksiyonları, sınıfları, metod tanımlarını çalışmakta olan ve hatalarını ayıkladığım ya da halihazırda üretimde olan bir programa yükleyebilirim. Bunu yaptığımda çalışmakta olan kod yeni tanımları kullanmaya başlar. Sınıflar yeni "slot"lara (üyelere) sahip olsalar bile yeniden tanımlanabilirler ve eğer istersem o sınıflardan oluşturulmuş örneklerin (instance) bu yeni özellikleri nasıl alacaklarını, nasıl bir geçiş olacağını hassas olarak belirleyebilirim. Bu tür bir olanak sürekli çalışan ama aynı zamanda değişikliklere ve hatta hata düzeltmelerine bile anında tepki vermesi gereken programları geliştirmeye destek verir.

• Lisp içebakış özelliğine sahiptir (introspective). Fonksiyonların, paketlerin, sınıfların, metodların dinamik olarak eklenmesi, yeniden tanımlanması, çıkarılması desteğine ek olarak programların kendi çalışma ortamlarına dair çalışma esnasında bilgi alması (fonksiyonlar, paketler, sınıflar, vs. tanımlı mı), bu nesneleri veri olarak manipüle etmesi, bunları kaydetmesi, dönüştürmesi, vs. de mümkündür. Ayrıca Lisp derleyicisi dilin standart bir parçasıdır ve çalışma esnasında programlar tarafından kendi kendilerini değiştirmek için çağrılabilir. Yeni programlar anında yaratılabilir ve akabinde derlenip, yüklenip çalıştırılabilir ve tüm bunlar o anda çalışmakta olan programın çalıştığı ortam içinde, onun dışına çıkmadan yapılabilir (dosya G/Ç işlemi bile yapmaya gerek kalmadan). Bu da otomatik programlamayı ve katmanlı dillerin geliştirilmesini destekler.

• Lisp'in söz dizimi kolayca yeniden biçimlendirilebilir. Uzunca bir süre kullanacağınız dilin sözdizimine mahkum olmaktan daha kötü bir şey olmasa gerek. Lisp, programcıların sözdizimini yeniden tanımlamalarına izin verir ve buna ek olarak sunduğu makro teknolojisi ile de bir programı başka bir programa çok etkin şekilde çevirmek mümkündür. Ayrıca program çalışması ve hata ayıklaması esnasında verinin nasıl gösterileceğini de kontrol etmenize izin verir. Bunların ötesinde bir programcının özelleştirmeleri diğer programcıyı kötü olarak etkilemeyecek şekilde gerçekleştirilebilir. Bu da Lisp ile girilen etkileşimi daha güzel kılar ve hata ayıklama seanslarının çok daha verimli geçmesini sağlar.

• Lisp, programcıları bir programı çalışır hale getirmek için değişken tipi tanımlamaya zorlamaz. Lisp'in birincil odak noktası programın çalışır hale gelmesidir. Eğer isterseniz sonrada tip tanımlamalarını ekleyebilirsiniz ve böylece derleyici optimizasyonlarından faydalanabilirsiniz. Bu da hızlı prototip üretimini sağlar ve sonra uygulamanın optimize edilmesine izin verir.

• Lisp'in güçlü bir sınıf sistemi vardır ve bununla da yetinilmeyip çok esnek bir meta-sınıf sistemi geliştirilmiştir. Sınıf sistemi çok güçlü ve esnek şekilde "slot" ve metod tanımlamaya, metod birleştirmeye ve başka pek çok şeye destek verir. Meta-sınıf sistemi ise programcıların nesne sistemini programlanabilir veri olarak kullanabilmelerini ve böylece yeni tür sınıfları dinamik olarak yaratmalarını sağlar.

• Lisp, hata bildirimi ve hata ele alma için güçlü araçlar sunar. Bu da demektir ki bir problem çıktığında programları durdurmak ya da "coredump" oluşturmaktan başka seçenekler de vardır. Ayrıca nesneye yönelik hata ele alma garip hata durumlarını temsil etmeyi, hata durumunda olası seçenekleri değerlendirmeyi ve uygun seçeneği gerçekleştirmeyi kolaylaştırır.

• Lisp otomatik hafıza yönetimi kullanır. Bu da bir programcının bir nesne ile işi bittiğinde artık onunla ilgilenmeyeceği ve çöp toplayıcının o nesneye ayrılmış hafızayı tekrar sisteme geri kazandıracağı anlamına gelir. Bu sayede Lisp programları hafıza sızıntılarından muzdarip olmaz.

Benim ve bir grup arkadaşım için Lisp/Scheme programlama bir mistik cennet bahçesi konumunda uzunca bir süredir ve hafızalarımızdan yavaş yavaş siliniyor. İş hayatımızda bu tür şeylerle uğraşmamız için olanak yok. Ancak tüm bunlara rağmen yine de istediğimiz her şekle girebilen bir dille çalışabilmenin güzelliğini hala hatırlıyoruz: o güzel günlerde kod yazmak hem daha eğlenceli hem de daha güzel bir kendini ifade etme aracı idi. Süreç içinde bize geri dönüş değeri de çok yüksekti çünkü hassas ve sürekli soyutlama dilin doğasında vardı. Hayat o zamanlar çok daha eğlenceliydi, samimiyim bu konuda.

Ama ne yapabiliriz! İşlerimizde ve hatta kişisel projelerimizde C, C++, Java, Perl veya Python kullanmak zorunda kalıyoruz. Özel olarak bu dilleri tercih ettiğimizden değil çok daha az tatmin edici iki sebepten ötürü: öncelikle herkes bu dillerden anlıyor ve böylece daha geniş teknik destek ağı söz konusu. İkincisi de Lisp/Scheme ile yazılmış programları çalıştıracak kişilerin doğru çalıştırma ortamına sahip olup olmadıklarını bilemiyoruz bu taşınabilirlik sorununu gündeme getiriyor.

Acaba Lisp/Scheme'in tekrar "mainstream" olabileceğini düşünüyor musun? Yani yeni bir projeye başlamayı düşünen biri için Lisp veya Scheme en azından Perl kadar güçlü bir alternatif olabilir mi ve yazılımcılar geliştirici ve testçi sıkınıtısı kaygısından uzak durabilir mi? Böyle bir duruma gelmek için ne gerekiyor?

KMP: Öncelikle yukarıdaki ilk paragrafta yazdığın şiirsel betimlemeyi takdir ettiğimi belirtmeme izin ver lütfen. Senin betimlemen benim ve pek çok kişinin Lisp kullanma deneyimine dair hissiyatını özetliyor.

Lisp'in geleceğine gelince sanırım Lisp'in durumu yavaş yavaş iyiye gidiyor popülarite anlamında. Bu böyle olmalı ki benim yeni işim Lisp ile araçlar geliştiriyor ve bunları satıyor, sattığımız ürünlerin geliştirilmesi için kullanıyor, vs.

Hem ticari olarak geliştirilen hem de özgür yazılım ruhu ile sürekli özellik eklenen pek çok ürün mevcut. Bu Lisp geliştirme ve çalıştırma ortamlarından CORBA, COM gibi arayüz desteklerinin yanısıra soket arayüzleri de var ve pek çok Lisp tabanlı web sunucu da mevcut. Lisp programları dinamik olarak DLL yükleyebilir ve kendileri de DLL olarak sunulabilir. Başka dillerden "yabancı fonksiyon çağrısı" yapabilirler ve veritabanları ile konuşabilirler.

Dünyada yüksek hızlı Internet bağlantısı yaygınlaştıkça bir uygulamanın sunulma ortamının problem olmaktan çıkacağını düşünüyorum. İnsanlar uzun süredir e-Servis tabanlı bir toplumun gelişmesini bekliyorlar ve bu hala tam olarak gerçekleşmedi ancak buna her gün yaklaşıyoruz. Gittikçe artan sayıda web uygulaması ortaya çıkıyor, insanlar istedikleri bir sunucuyu istedikleri gibi ayarlayıp uygulamalarını kullanıcılara sunuyorlar ve kullanıcılar için uygulamanın hangi dilde yazıldığı, hangi sunucuda çalıştığı önemini yitiriyor. Bu biraz basitleştirme gibi görünebilir ama bu yönde ilerlediğimize iddiaya girerim.

8) Lisp öğrenirken aklıma gelen sorular
by Jon Howard

Kısa süre önce (Nisan ayında) ticari bir Lisp geliştiricisi olan Franz'ta (franz.com) webmaster olarak çalışmaya başladım ve oradaki insanlar bana yoğun şekilde Lisp öğretmeye çalıştılar. Benim de rızamla beni bilgi bombardımanına tuttular çünkü bilgisayar donanımı ilerledikçe daha soyut ve yüksek düzeyde programlamanın insanlara çok daha fazla yaratıcılık imkanı sunacağını düşünüyorum. Elbette assembler iler süper-müper- petaflop mikroişlemci programlamak mümkün olacak fakat kim birkaç milyar ya da trilyonluk bir işlemden birkaç bin işlem tasarruf etmek için milyonlarca satır assembly kodu yazmak ister ve sonucunda da birkaç nanosaniye kazanmak. Kendi adıma süper hızlı programlar yazmaktan ziyade yaratıcılığımı gösteren ve süper işlevsel olan programlar geliştirmek taraftarıyım.

Franz şirketinin resmi görüşlerini ifade etmiyorum tabii. Şirkette çalışan herkesin kendi görüşleri var güzel ve etkin programlama üstüne ve tam da bu yüzden bu ortamı tatmin edici buluyorum. Son zamanlarda çok farklı Lisp kodlama teknikleri ile karşılaştım ve aynı dilde bu kadar farklı stillerin bir arada yaşayabilmesi ilgimi çekti.

Hala acemi çaylak sayılırım ve geçmişte de ciddi bir profesyonel programlama deneyimim olmadı ama soru sormaya alşıkınım ve işte sorularım:

• Eğer önceden başka bir dil öğrendiysen o dilin şekilsel yapılarını başlangıçta anlamayı engelleyici buldun mu? Bu durum lisp için de geçerli miydi?
• Lisp harici dillerde yazılmış kodlarda hata ayıklamak için ne kadar vakit harcıyorsun? Lisp ile yazılan kodlarda hata ayıklamaya ayırdığın süre nedir?
• Hangi dili öğrenmesi en uzun sürdü - bu ilk öğrendiğin dil miydi?
• Soyut seviyede bir dilin etkin olarak desteklemesi gereken en önemli özellik nedir? Lisp ortamlarında en zayıf bulduğun özellikler nedir?

Lisp ile ilgili problemleri, eliştirilmeye muhtaç ya da geliştirilemeyecek şeyleri öğrenmek istiyorum, şimdiye dek şikayet edebileceğim bir şeyle göremedim ben. Tek sorunum 50 yıldır geliştirilen bir dilin kapsamlı dokümantasyonu ile başa çıkabilmek. Lisp ile çalışmak hoşuma gitmeye başladı ancak etrafımda bu konuda bilgili ve tutkulu çok insan var, bu yüzden de taraf tutuyor olabilirim, eğer bundan ötürü göremediğim ya da atladığım bir şey varsa sağlam bir argüman ile bana hatalarımı göster. ;)

KMP: Lisp öğrenmeden önce FORTRAN ve BASIC biliyordum. Lisp öğrendikten sonra ise pek çok başka programlama dili ile de uğraştım. Bu dillerle ilgili sorun genellikle sözdizimlerinden (syntax) kaynaklanmıyordu. Bazı dillerin sözdizimi diğerlerininkinden daha iyi olabilir ancak insan beyni şaşılacak derecede yeteneklidir ve bunlarla başa çıkabilir. Şimdiye dek öğrendiğim tüm dilleri ve sözdizimlerini düşünecek olursam belki de başa çıkmakta beni gerçekten zorlayan şey C dilinde işaretçi (pointer) programlamak için kullanılan "*"lar oldu. İşaretçi konudunda detaylı bilgi sahibiyim, "bir diziyi gösteren işaretçi" ile "işaretçilerden oluşan bir dizi" arasındaki farkı da gayet iyi açıklayabilirim ama öyle ya da böyle o korkunç notasyonu kullanırken, yazıp okurken güçlük çekiyorum. Her halükârda Teco ya da Perl'i tercih ederim.

Genellikle sözdiziminin dil öğreniminde çıkarabileceği sorunların abartıldığını düşünüyorum. İnsanların beyinleri çok acayip sözdizimleri ile başa çıkabilmiştir bugüne dek. Asıl mesele insanların sahip oldukları bilgiyi programlara aktarabilmeleridir. İnsanlar karar vermede iyidir, programlar tekrarlamada. Ancak zaman geçtikçe karar verme görevleri tekrarlanmaya başlar ve bu durumda artık bu iş programlara devredilmelidir. Pek çok şeyi paketlemek için makro yazıyorum ve bu işin anahtarı da dilin sözdizimi ile program yapısı arasında güvenilir bir tasvir (mapping) kurabilmek. En son isteyeceğimi şey karakter tabanlı bir makro dilidir çünkü bu tür bir sözdizimi çok tahmin edilemezdir. Lisp ise program yapısına dayanan makrolar sunar ve böylece makro yazarken oluşabilecek programcı hatalarını minimum seviyede tutar.

Hata ayıklamak söz konusu olduğunda Lisp harici kodlardan olabildiğince uzak durmaya çalışıyorum çünkü hata ayıklama zor. Pek çok başka dilde veri görsel olarak güzel şekilde sunulmuyor ve bu yüzden de hata ayıklıcıda çalışırken karşıma gelen sorunlu veri düşük seviyeli ve zor okunur şekilde temsil ediliyor. Vaktimin büyük ve sorunlu kısmı bu veri temsilinden yola çıkıp yapıyı tekrar kurmakla geçiyor. Lisp ile program yazarken veri nesnelerinin çok daha kolay okunabilir görsel temsilleri var ve bu sayede nerede sorun olduğunu görmek çok daha kolay oluyor.

En çok hangi dili öğrenmek için vakit harcadım? Sanırım Teco. Öğrenecek bir sürü detay vardı. Öğrenmek için en az zaman harcadığım diller: FORTRAN, BASIC, Lisp, HyperTalk ve MOO. FORTRAN çünkü küçük bir dil. Diğerleri çünkü yüksek oranda etkileşime izin veriyorlar ve bu da öğrenen biri için çok büyük avantaj.

Aslında PostScript'i de çok hızlı öğrendim. Bununla ilgili çok güzel reçeteler var. Fakat PostScript'te hata ayıklamayı bir türlü öğrenemedim. Programımda hata olduğunda sıfırdan başlıyordum ve çalışmasını umuyordum çünkü hata ayıklama süreci çok acı vericiydi.

Soyut seviyeli bir dilin etkin olarak desteklemesi gereken en önemli özelliğin ne olduğunu düşünüyorum? Benim zamanımı . Zaman tek gerçek ve yenilemeyen kaynaktır. C gibi dilleri geçiyorum çünkü bunlar geliştirme ve hata ayıklama için çok fazla zaman alıyor ve bu kötü durumu kabul ettirmek için de hızdaki mikro farkları öne sürüyorlar ki o tür optimizasyonlar benim çalışma alanımda pek önemli olmadı. Bir assembly dili olarak C kullanımını uygun buluyorum fakat benim için yeterli miktarda üst seviyeli servis sunmuyor. Saçlarım kırlaştığında ve geriye dönüp baktığımda pek çok ilginç şey yapmış olmak istemiyorum, sadece birkaç ilginç şey yapmış olmak ve "ama yani gerçekten de çok hızlıydılar!" demek istemiyorum.

Bence bir dil seçerken mevcut implementasyonların bugünkü hızlarına değil yapmak istediklerinizin ne kadarına destek verdiğine bakmanız gerekir. Lisp haksız olarak yavaş olduğu ithamları ile karşılaşıyor sık sık ve bunun da sebebi bence şu: Başlangıçta nasıl optimize edileceği bilinmeyen şeyleri çok hızlı yapması bekleniyor ondan, hafıza temizleme (garbage collection) gibi. Ancak Lisp kullanıldıkça insanlar yavaş olan şeylere dair şikayetlerini belirttiler ve bu sorunlar giderildi. Yani Lisp sürekli ilerledi. Eğer Lisp sadece nasıl yapılacağı teknik olarak çok iyi bilinen özellikler haricinde özellik barındırmadan yola çıksaydı o zaman pek çok şeyi dışlamış ve ilerlemeyi engellemiş olacaktı. Ben fikirlerimin teknolojiye ve araçlara yön vermesini isterim, mevcut teknolojinin ve araçların fikirlerime yön vermesini değil.

9) Temel programlama dilleri?
by PseudonymousCoward

Bir Scheme ve Common Lisp programcısı olarak Java Sanal Makine (VM) mimarisinin otomatik hafıza ayırma ve hafıza temizleme (garbage collection) özelliklerine sahip olacağını duyduğumda heyecanlanmıştım. JVM üzerinde Lisp tarzı diller geliştirilebileceğini düşünmüştüm. JVM üzerinde Scheme'e yakın bir ortam sunmak için geliştirilen Kawa'nın geliştirme hızı beni hayal kırıklığına uğrattı. Bunu kısmen JVM içinde Scheme'de "devam ediş" ("continuation") olarak tabir edilen yapının olmamasına bağlıyorum. Acaba programlama dilleri için bir "temel set" oluşturmak ve böylece bunların üzerine her türlü programlama dilini kurmak ve C, Scheme, vs. arasındaki farkları tamamen sözdizimsel farklara indirgemek mümkün müdür? Eğer öyle ise lütfen bu temel kümeye girebilecek adayları say.

KMP: "Devam ediş"ler ("continuation"lar) sadece fonksiyondur. Bunu gerçekleştirmek için gerçekten eksik olan şey ise ise iyi bir "arkadan çağırma" (tail call) desteğidir, eğer bu olursa devam edişler yığıta (stack) ekleme yapmadan çağrılabilir.

JVM'yi doğrudan kullanma konusunda bir deneyimim yok ancak MOO programlama dilinden edindiğim izlenime dayanarak söyleyebilirim ki arkadan çağırma (tail calling) ile güvenlik kavramını bağdaştırmak güç olabilir çünkü bazen güvenlik "beni kim çağırdı?" sorusu ile bağlantılıdır ve arkadan çağrılar görünen çağıranın gerçek çağıran olmadığı anlamına gelebilir. Bundan ötürü Sun'daki casuslarıma sordum.

Bana söylenenlere göre Java'nın orjinal güvenlik modeli beklediğim gibi çalışıyordu (çağrı zincirini inceleyerek) ve güvenlik konusundaki hassasiyet de ilk sürümlerde kuyruk çağrı desteğinin bulunmamasına yok açtı. Ancak bu desteğin öyle ya da böyle bir gün eklenmesi gerektiğine karar verdiler uzun zaman önce, tek mesele henüz o günün gelmemiş olması. Bu yüzden belki de hala ümit var.

Bununla birlikte ne kadar uğraşırsanız uğraşın diller arasındaki tek farkın sözdizim farkı olacağı bir duruma varmanız zor gibi görünüyor. Elbette belli bir makina için tüm diller derlenebilir hale gelebilir ancak bu durum bir dildeki programların bir başka dildeki programlar kadar etkin olacağı veya bir dildeki veri yapılarının başka bir dildeki kadar doğal şekilde temsil edileceği anlamına gelmez. Örneğin hem Lisp hem de Scheme küçük tamsayıların (makinanın doğal depolama birimine sığabilenleri) tamsayı olduğunu kabul eder; bu dillerde Java'daki gibi bir int/Integer ayrımı yoktur. Bir Lisp-to-JVM derleyicisi muhtemelen bu ayrımı gizler ancak buradan yola çıkıp Java ile Lisp arasındaki yegâne farkın sözdizimi farkı olduğunu iddia etmek yanlış olur. Gerçekten de iki dil arasında maddi felsefi temel ayrılıklar olduğu görülebilir.

10) Bir XML dönüştürme dili olarak olarak Scheme
Evangelion

Son zamanlarda boş vakitlerimde Scheme (mzscheme) ve SXML paketini kullanarak gelişigüzel XML dönüşümleri yapmak ilgileniyorum.

Görünen o ki keyfi bir XML belgesi ile yorumlanabilir bir programlama dili arasında birebir eşleştirme yapabilme fikri ihmal edilemeyecek kadar güçlü bir fikir.

Acaba gelecekte Scheme/Lisp'in önemli rollerinden biri de XML belgelerinin manipülasyonu olabilir mi yoksa bu akademik bir araştırma alanı olarak kalacak mı ve insanlar Java ile XML çözümlemek için uğraşıp duracak mı?

KMP: Bu ikisi dışında seçme hakkım yok mu? İkinci seçenek epey kasvetli görünüyor bu yüzden de birinciyi seçsem iyi olacak.

Yakın gelecekte XML'yi Lisp ya da Scheme'in resmi bir parçası olarak görebilecek miyiz bilmiyorum ancak bunun temel sebebi stadandartları geliştiren kurumların bu aralar çok aktif olmamaları. Bu dillerin öldüğü değil sağlam bir temele oturduğu anlamına geliyor. Mevcut çalışmalar daha ziyade kitaplıklar geliştirme çerçevesinde yoğunlaşıyor ve bu tür kitaplıklar da dilin temel işlevselliğini kullanarak ve bu işlevselliğe müdahale etmeden gerçekleştirilebilir.

XML ve HTML'nin Lisp tarafından manipülasyonu insanların uzun süredir üzerinde çalıştıkları bir konu. Örneğin Document Style Semantics and Specification Language (DSSSL) diye tabir edilen şey tamamen fonksiyonel, yan etkisi olmayan bir Scheme çeşidiydi. DSSSL'nin yerini alan XSL bile benzer bir işlevsellik sunmaktadır. Sadece biraz daha CSS tarzı bir sayfa modeli ve XML sözdizimi ile çalışmakta ancak kavramsal olarak özüne bakarsak, temelde Scheme.

Profesyonel hayatımın son dönemlerinde kişisel olarak pek çok XML ayrıştırıcı (parser) yazdım, hepsi de Lisp ile yazılmıştı, bir kısmı işverenler bir kısmı da kendim ve şirketim için. Şirketimin uygulaması henüz piyasaya çıkmadı ancak çıktığında da asıl rekabet bu tür kütüphanelerin "varlıkları" üzerinden olmayacak. Zaten halihazırda XML, XSL ve SAX için pek çok kitaplık var ve daha pek çok da olacak. Asıl rekabet verimlilik, sağlamlık, temsil ve opsiyonel ve ek özellikler üzerinden olacak.

11) Lisp dünyaya karşı
hjs

Lisp'in kendine özgü güçlü yanları ve zayıflıkları nedir?

ML gibi diğer fonksiyonel dillere, C, Algol, vs. gibi yapısal dillere, C++, Smalltalk, Simula gibi nesneye yönelik dillere ve Tcl/Tk, Perl, vs. gibi hızlı geliştirmeye yönelik betik dillerine kıyasla avantajları nedir? Bu diller söz konusu güçlü özellikleri bünyelerine katabilecek şekilde geliştirilebilir mi? Eğer evetse nasıl, eğer hayırsa neden?

Zayıflıklar hakkındaki görüşlerin nedir? Genel olarak ve yukarıdaki dillerle kıyaslandığında zayıflıkları nedir? Bu zayıflıklar giderilebilir mi? Eğer evetse nasıl eğer hayırsa neden?

Güç ve zayıflık terimlerini öyle soyut, bilgisayar bilimleri anlamında, formel bağlamda kullanmıyorum aynı zamanda günümüz dünyasında kullanılabilirlik ve pratik olarak uygulanabilirlik bağlamında kullanıyorum. Örneğin doğrudan çalışabilir program sunamamak ya da sistem kitaplıklarına erişememek o dil için bir zayıflık kabul edilir.

KMP: Lisp ile ilgili sevdiğim çok şey var ancak bunların çoğunun "doğru sırada yapılması gerekenler" başlığı altında toplanabilir.

Söz gelimi tip tanımlamaları pek çok dilde zorunludur fakat Lisp'te opsiyoneldir. Beni ilgilendiren önce programı çalışır hale getirmektir ve ancak ondan sonra tip tanımlamaları ekleyerek programı daha etkin hale getirmeyi düşünürüm. Eğer sonucu depolayıp depolamayacağınızdan dahi emin değilseniz onca tanımlamanın manası ne olabilir ki? "Şöyle olursa nasıl olur" (what if) tarzı pek çok program geliştiriyorum. Aynı zamanda basit bir sonuç hesaplaması için pek çok küçük program yazıp bunları atıyorum. Bu tür programların 10 mikrosaniye yerine 5 mikrosaniyede çalışmalarına ihtiyacım yok.

Ayrıca programlama sürecini belli "zaman" bölümleri olarak görüyorum ve her bölümde bazı kararlar verilir: "Kodlama zamanı", "ayrıştırma zamanı" (Lisp buna "okuma zamanı" der), "makro açma zamanı", "derleme zamanı", "yükleme zamanı" ve "çalıştırma zamanı". Lisp bana her kod parçasının ne zaman çalışmasını belirleyebilmek için esneklik sağlıyor böylece ilgili kod parçası ancak ihtiyaç duyduğu veri hazır olduğunda çalışıyor. Diğer diller ise, özellikle statik tanımlamayı mecburi kılanlar beni önceden bilgi tanımlamaya zorluyor, cevapları henüz bilmediğim zaman, bu da cevabı bilmek yerine cevabı uydurmak anlamına geliyor. Bazen bu zorlama programların daha hızlı çalışmasını sağlıyor. Bazen de programların yanlış çalışmasına yol açıyor.

Ve tabii bir de Lisp'in kendini temsil etme isteğini seviyiyorum. İnsanlar genellikle bunu kendini temsil etme kabiliyeti olarak söyler ama bence bu yanlış. Programlama dillerinin çoğu kendi kendilerini temsil etme yeteneğine sahiptir ancak bunu yapma arzusuna, isteğine sahip değildir. Lisp programları listelerle temsil edilir ve programcılar bunun farkındadır. Eğer dizilerle yapılsaydı yine de pek fark etmezdi. Önemli olan temsil edilen şeyin programın yapısı olmasıdır karakter sözdizimi değil ama bunun ötesindeki seçim tamamen keyfidir. Temsilin Doğru® seçim olması çok önemli değildir. Yaygın ve üzerinde anlaşılmış bir çözüm olması önemlidir, böylece programları manipüle eden pek çok program geliştirilebilir ve bu ortak temsil kullanılabilir.

Pek çok makro yazıyorum çünkü bir programcı makroları kullanarak Lisp'te çok ilginç şeyler yapabilir. Diğer dillerde makro yazımı, girdi sözdizimini barındıran karakter dizilerini manipüle etmek demektir. Bu da hiç güvenilir bir yöntem değildir ve ben bundan hiç hoşlanmadım. Lisp'in kendi kodunu bilinen veri yapıları ile temsil etmesi makro yazma işini çok daha güvenilir hale getirir. Lisp'teki makroların varlığı kod yazma işinin en sıkıcı bölümlerinin sorun olmaktan çıkması anlamına gelir çünkü sık sık tekrarlanan kodlar için için hemen bir makro yazılır göz önünde durmaktan çıkar, geliştiricinin "ilginç kısımlar"a odaklanmasına izin verir ve programlama etkinliğini hem daha eğlenceli hem de daha etkili kılar.

Diğer diller Lisp'in güçlü özelliklerinden faydalanabilir mi? Elbette, ve bunu yapıyorlar zaten. Java, Dylan ve C++ gibi diller Lisp'ten pek çok fikir almıştır. Ancak bunda kötü olan bir şey yok. Daha da fazlasını yapacağız. Hem zaten bu sıfır toplamlı bir oyun değil ki. Bu tür çapraz geçişler oldukça herkes faydalanır ister Lisp bir başka dili etkilesin ister başka bir dilden etkilensin.

Dilin zayıflıkları? Sanırım bunu söylemek daha zor. Bence temel tasarım bir hayli sağlam. Bazen bir geliştirme ortamının bir özelliği daha çok vurguladığını görebilirsniz ama genellikle bu durum başka bir geliştirici için pazar fırsatı anlamına gelir ve böylece her şey kapsanmış olur.

Örneğin bazı Lisp derleyicilerinin üreteceği "hello world" çalışabilir programı diğer dillerdeki derleyicilere kıyasla büyük olabilir. Lisp camiasının bir kısmı bunu bir sorun olarak görmez çünkü disk ve RAM fiyatları sürekli düşer. "Gerçek" uygulamalar (yani "hello world" gibi olmayanlar, çok daha kapsamlı olanlar) günümüzde artık 5-10 MB civarı yer kaplıyor ve insanlar bunu doğal karşılıyor. Yıllar önce Lisp büyük görünürdü ancak kendisine gelen eleştirilerden ötürü son on yılda daha fazla büyümemek için elinden geleni yaptı, bu süre içinde diğer programla dillerinin ortamları ise çok hızlı şekilde büyüdü ve daha çok yer kaplamaya başladı. Günümüzde bir kıyaslama yaparsanız aslında Lisp'in çok küçük kaldığını görebilirsiniz. Ve eğer mevcut Lisp derleyicinizden memnun değilseniz her zaman için daha küçük yere sığma konusunda rekabet edenlerin ürünlerini bulabilirsiniz. Söz gelimi ticari bir ürün olan Corman Common Lisp ve açık kodlu özgür yazılım olan CLISP özellikle bu konuda hassastır. Her ne kadar günlük programlama işlerimde asıl araç Common Lisp olsa da madem programların az yer kaplaması konusu açıldı o zaman Scheme dilinin camiasına da göndermede bulunmamak olmaz, onlar da çıktı boyu konusunda pek çok iyileştirme yapmıştır.

Bazıları Lisp'in dinamik olduğunu ve bu yüzden de statik tip bilgisinden faydalanmadığını duymuş olabilir. Bu doğru değildir. Aslında durum şöyledir, dil sizi buna zorlamaz, sizin bunu yapmanıza izin verir. Bu da her uygulamanın duruma göre hazırlanmasında esneklik sağlar. Mesela CMU Common Lisp isimli Lisp geliştirme ortamı bu tip analizi konusunu ele almıştır ve tip tanımlamaları kullanılarak Common Lisp ile heyecan verici şeyler yapılabileceğini göstermiştir.

Peki neden tüm Lisp derleyicileri her bakımdan optimizasyon için kendilerini zorlamıyorlar: çıktı boyu, statik tip analizi, vs.? Common Lisp kavramsal olarak bir hayli büyüktür ve doğru, etkin derleme sistemi oluşturmak epey zaman ve zekâ gerektirir. Sık sık "E öyleyse neden dili küçültüp uygulanmasını, derleyici geliştirilmesini daha kolay hale getirmiyorsunuz ki" sorusunu sık sık duyarsınız, gerek Lisp dışı camiadan gerek Scheme camiasından. Common Lisp camiasının buna yanıtı şöyle özetlenebilir: Programlar her gün yazılır ama bir dilin uygulaması, derleyicisi çok daha ender yazılır. Derleyicinin yapmadığı kullanıcıya bırakılmıştır. Dil ne kadar çok iş yaparsa programlar ve programcı o kadar az iş yapar. Yani pratikte Common Lisp'in tezine göre dilin tanımının büyük olması kuracağınız cümlelerin boyunu kısaltır (ne demek istediğimi sezgisel olarak kavramak için Gone With the Wind ya da başka bir büyük roman düşünün sonra da eserin İngiliz dilinde ne kadar yer kapladığı ile mesela Esperanto dilinde yeniden ifade edilse ne kadar yer kaplayacağını karşılaştırın).

Eğer bir dil, programcının bir gecede derleyicisini yazabileceği kadar küçükse bu durumda onu uygulama geliştirmek için kullanacak programcılara çok bir şey sunulmuş olmaz. Scheme camiasındaki pek çok insan bir Scheme derleyicisi yazmakla övünür ancak benzer bir durum Common Lisp camiasında pek söz konusu değildir. Common Lisp derleyicisi yazmak elbette daha zordur ama zaten Common Lisp camiası pek çok farklı Lisp ortamı geliştiren insan varlığı ile övünmeyi hiçbir zaman düşünmez. Common Lisp camiası kendisine hedef olarak büyük kapsamlı, belli bir detayın üzerinde, ticari programlar geliştirmeyi seçmiştir ve dili tasarlayanlar da programcılara geniş bir temel ve güçlü bir yapı sunmak istemiştir. Böylece eğer programcılar dil standardına bağlı kalarak program yazarlarsa programları sadece yazıldıkları anda, günümüzde iyi çalışmakla kalmaz aynı zamanda Lisp ortamları, derleyicileri geliştirme ortamları teknik olarak ilerledikçe aynı programlar gelecekte çok daha iyi çalışır.

[devam edecek...]

Çevirenin Notları: Lisp ile ilgili çok detaylı ve wiki tabanlı bir sistem de http://www.cliki.net. Burada Common Lisp kullanılarak yapılmış değişik kategorilerde programlar ve belgeler bulabilirsiniz: Veritabanı programlama, şifreleme, oyunlar, matematik, müzik, yapay zekâ, web programlama, geliştirme ortamları, IRC kanalları, önemli fonksiyon kitaplıkları, vs.

Özgün makale sahibi: © 2001 Kent M. Pitman. Tüm hakları saklıdır.

Çeviri: © 2004 Emre Sevinç. Özgün yazarın izni ile çevrilmiş ve aşağıdaki kurallar dahilinde kamuya sunulmuştur:

Bu belgeyi taramaya (yani bu belgenin geçici bir kopyasının bir insan tarafından bir web tarayıcısının sunduğu olanak çerçevesinde okunması) açık olarak izin verilmiştir ancak geçici kopyanın kalıcı olarak kopyalanıp yeniden dağıtılması, yeniden başka yerde gösterilmesi ya da başka yerlere aktarılmasına izin verilmemiştir.

Bu belgenin adresinin depolanması, favoriler kısmına kaydedilmesine (yani içeriğinin değil sadece belge başlığının ve URL bilgisinin daha sonra hatırlama ve başlıkla URL arasında bağlantı kurma amacı ile kaydedilmesi) açık olarak izin verilmiştir.

Özgün makalenin ve çevirisinin belirtilenlerden başka amaçlar doğrultusunda kullanımı yazılı izin gerektirir.

Makalenin özgün adresi burasıdır. Lütfen son güncellemeler için özgün adresi kontrol etmeyi ihmal etmeyin.