Kent Pitman Lisp ve ötesi ile ilgili soruları yanıtladı - Bölüm 1

0
FZ

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...

1) (Bilmek istediğim tek bir şey var)?
Anonim

((
     Bu (
            (parantezler) (de)
          ) nedir ()?
)
     Hmmm?
)

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:

(+ 3 (* 2 5) 7)

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:

(defun sort-by-name (list)
  (sort list #'name<))

(defun name< (name1 name2)
  (or (string< (last-name name1) (last-name name2))
      (and (string= (last-name name1) (last-name name2))
           string< (first- name name1) (first-name name2)))))

bu durumda Lisp şunu yapmanıza izin verir:

 (defun sort-by-name (list)
   (sort list #'(lambda (name1 name2)
                  (or (string< (last-name name1) (last-name name2))
                      (and (string= (last-name name1) (last-name name2))
                           (string< (first-name name1) (first-name name2)))))))

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.


3) Etkileşimli olarak programlanabilen uygulamalar
divbyzero (divbyzero@hotmail.com)

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.

Lisp'in geçmişteki en büyük problemi belki de ticari arenanın tepesine zamanından önce çıkmış olmasıdır. 1980'lerde yani pek çok uygulamanın hedeflediği problemlerin Lisp'in sunduğu güçlü olanaklardan çok daha azını gerektirdiği bir dönemde. 80'li yıllar MacWrite'ın ve Lotus 1-2-3'ün popüler olduğu ve insanların bunlara hayranlıkla bakıp bunların güçlü uygulamalar olduğunu düşündüğü dönemlerdi. Tabii adı geçen uygulamaları geliştirmek için C ya da Lisp kullanmak pek bir fark yaratmıyordu. Ancak öyle ya da böyle etrafımızdaki dünya büyüdü günümüzdeki önemli problemler artık çok daha karmaşık ve zor. Lisp'in bugünün dünyasına sunabileceği çok daha fazla şey var diye düşünüyorum.

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.


Tabii standardın bir şartı olarak RAND (Reasonable and Non-Discriminatory) bedelleri ödenmesi de beni rahatsız ediyor. Bence konsensüse dayalı standartlarda sadece "royalty-free (RF)" teknolojileri olmalı. Standartlara uyum gerekli kodu oluşturma maliyetinin üstünde bir şey olmamalı ve böylece standarda uyum maliyeti sıfıra yaklaşır. Eğer o standardın bir uygulamasından kâr edilecekse bu uygulayana gitmelidir, bir patent sahibine değil. Her ne kadar yazılım için telif haklarını savunsam da yazılım patentlerine karşıyım. Bağımsız bir yaratım sadece bir fikrin patent bürosunun düşündüğünden daha açık bir fikir olduğunu göstermeye yarayan bir kanıt olarak algılanmalıdır. Telif hakkından ise rahatsız değilim çünkü birisinin geliştirdiği sistemin bir başkasının kopyası olmadığını göstermenin yöntemleri vardır ve bağımsız yaratım bir savunmadır.

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.

6) Dil özelliklerinin geniş kitlelere ulaşması
illWare

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.

7) Lisp'in tekrar moda olmasını sağlayacak şeyler nedir?
by kfogel

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.

Görüşler

0
bm
FZ eline saglik. Bircok kavramda belirtildigi gibi tercume zorlugu var. Dil bilen ve ayni zamanda konulara hakim arkadaslar lutfen gozlerine batan seyleri yazsinlar. Duz tercumeden cok kavrami anlasilir hale getiren karsiliklar icin FZ bayagi ugrasti [groups.google.com]. Ozellikle KMP'nin bahsettigi Common Lisp pek yeni ogrenenlere kolaylik olmasi gayesiyle duzenlenmis bir dil degil, dolayisiyla bir suru kavram var efektif kullanmak icin hakim olunmasi gereken. Bunlara duzgun karsiliklar bulunabilirse hevesli ve Ingilizcesi bazi kaynaklari okumaya yetmeyen arkadaslarin onunun acilmasinda cok faydali olur.
0
malkocoglu_2
Tercume icin kutlarim.

Yazarin dinamik diller hakkinda soylediklerine yasim ilerledikce daha cok katilmaya basliyorum. Guclu tipleme (strong typing)'in kodlamami yavaslattigini hissediyorum;Java'da bir kez daha UzunBirClassIsmi obj = new UzunBirClassIsmi () yazarsam patlayacagim. Ah evet evet, makrolar, vs.vs.. Tekrari uretebiliriz. Ama kod uretmek bir teknolojinin veya ozelligin bastan eksik oldugunu gostermez mi? Java, C++ gibi diller "ikili kayit" (double bookkeeping) yaparak hatalari derleme aninda cozmeye ugrasiyorlar. Fakat egeriyi testler yazmissam, bu ikili kontrole ihtiyacim var mi?
0
bm
;) buyurun efendim, sizi boyle alalim. Lisp kollarini acmis bekliyor. 40 senedir.
0
malkocoglu_2
Ben zate takimdayim merak etmeyin.. :) Asagidaki Yapay Zeka derslerinin kodlari LISP le yazilmistir. YZ dersini alirken mecburen aldigim LISP'ten cok memnun kalmistim, ve Emacs guclerimi arttirdigi icin bir baska yakinlik duymaktayim. Hafif tiplemeli dillere olan merakim, Ruby ile basladi, fakat ne yazik ki bu tur dilleri "her yerde" kullanma olanagimiz halen yok. O yuzden simdilik sadece yakinmak ile yetiniyorum..

http://www.bilgidata.com/yazi.jsp?dosya=a_yapay.xml

http://www.bilgidata.com/yazi.jsp?dosya=a_altust_algoritmasi.xml

http://www.bilgidata.com/yazi.jsp?dosya=a_zeki_arama.xml

http://www.bilgidata.com/yazi.jsp?dosya=a_id3.xml

0
FZ
Pitman'ın röportajdaki vurgusuna dikkat etmekte fayda var, evet Lisp yapay zekâ uygulamaları için çok güzel ve güçlü şekilde kullanılmıştır ancak tek kullanım alanı bu değildir. Söz gelimi Paul Graham'ın 90'lı yılların ilk yarısının sonuna doğru Lisp ile geliştirip Yahoo'ya 40 milyon dolara sattığı e-ticaret sistemi YZ dışı uygulamalara bir örnektir. Kaldı ki Lisp'in sadece YZ için uygun olup, başka türlü uygulamalarda işe yaramadığını düşünseydim, buna ikna olsaydım bazı belgelerin çevrilmesi için bu kadar emek harcamazdım.

Bir başka örnek, ITA Software, Lisp kullanarak dünyanın en gelişmiş uçak bileti/fiyatı ayarlama sistemlerinden birini geliştirdi. Genellikle ele aldıkları problemin çapını özetleyen güzel bir betimlemeleri var:

Boston ile Los Angeles arasında gidiş dönüş için (1 günlük aralık ile) için pratikte 25.000.000 kombinasyon vardır. Bunlardan herhangi biri için fiyat hesaplamasını gerçekleştirmek en az NP-zor problem olarak kabul edilmektedir. Hesaplamalarda kullanılacak veri 100 Hz frekansıyla değişmektedir. 10 saniye ya da daha kısa sürede en ucuz çözümü bulun...


Lisp her yerde kullanılmaz, bu doğru, hangi dil her yerde kullanılabilir ki? Sembolik matematik işlemleri yapacak bir sistem geliştirmek için C, yeni bir grafik kartının cihaz sürücüsü için Perl, veri tabanı sorgulaması için Assembly, mantık programlama için Java kullanmanın çok anlamlı olmaması gibi durumlar söz konusu elbette. (Yine de dil savaşları yapmanın zevkine doyum olmaz o ayrı :)

Umarım buraya deneyimli Lisp programcıları haricinde de geribesleme, öneri, eleştiri yazan olur, çünkü planladığımız başka şeyler de var. Süreç için de konu ile ilgili epey sağlam başka makaleleri, Lisp ile yeni uğraşmaya başlayan profesyonel programcıların günlüklerini, vs. Türkçe olarak yayınlamayı düşünüyoruz. Buna ek olarak uluslararası Lisp uzmanları ile FM kitlesini benzer şekilde buluşturmak, FM üzerinden röportaj yaptırmanın yanı sıra IRC üzerinden seminer gerçekleştirme planlarımız da var. Tabii bunca çabaya değip değmeyeceğini anlamak için biraz da genç, hevesli programcıların konu ile ne kadar ilgilendiğini görmemiz, tabiri caizse nabız tutmamız gerekiyor.
0
malkocoglu_2
||Lisp her yerde kullanılmaz, bu doğru, hangi dil
||her yerde kullanılabilir ki

Soylemeye ugrastigimi tam dillendiremedim: Soyle soyleyeyim:

LISP'in "pur dil" ozelliklerinin cok iyi oldugu asikar. Eger bu yeterli olsaydi, LISP'i her yerde kullanirdik. Fakat diller vakumda yasamazlar. Mesela LISP kullanarak bir web sayfasi yazmak istiyoruz. Ve "secenek" istiyoruz, birkac tane yontem, birkac tane uygulama servisi bunu desteklesin... Biraz etrafta konu hakkinda literatur olsun. Yani bir danisman programinin, teknoloji kullanicisinin istedigi turden seyler... Bunlar var mi? Yok. Olsaydi iyi olmaz miydi? Harika olurdu.

Peki niye yok?

Bir dilin o "API denizinde yuzmesi" icin ne gerekiyor? Bu olay bir kritik kutle (critical mass) konusu olabilir. Bir dil belli bir noktayi astiktan sonra, trend kendi kendini besler, yani mevcut destek urunler programci sayisini arttirir, programci sayisi urunleri arttirir. LISP, bilinmez sebeplerle o kritik kutleye hic ulasmadi. C diline benzemedigi icin mi? Olabilir. Sozdizim yapisi mi bazi faniler (!) icin itici. O da olabilir. Bilemiyoruz.

LISP'i ogrenmesini tavsiye ettiklerime, o dil degisik bir bakis acisi sagladigi icin bu dili tavsiye ediyorum. Ellerinde, Java tedavulden kalkinca ellerinde "bir sonraki iyi seyin" ne olacagini anlamalari icin bir gosterge olsun diye bunu soyluyorum. Fakat su anda yuzum kizarmadan LISP'i her sey icin kullanabilirsiniz demiyorum. Teoride bu KESINLIKLE mumkundur, ana pratikte bu dogru degildir.



0
bm
Aaa web mi dediniz? Google yemleri: aranedia, allegroserve, portable allegroserve, mod_lisp, htout, cl-https, lml, Paul Graham (bazi yazilarinin tercumesi yolda) ve digerleri. Cliki'nin kendisi de lisple yazilmis tabi. Bu arada bir de 'case study' vereyim, 300-500 MB veri icin SQL'e gidenlere bir de alternatif olsun: http://homepage.mac.com/svc/RebelWithACause/ [homepage.mac.com]
0
malkocoglu_2
Peki ,

Tablo Nesne esleme destegi
PDF indekslemek (ve aramak)
JSTL benzeri, yeni "etiket" yazabilmek
Dosya yuklemek
JSP benzeri sayfa ici etiketler

Yani, arka planda, izole halde calisan tabii ki cok cetrefil ALGORITMA AGIRLIKLI seylerden bahsetmiyorum. Bilgi islemcilere lazim olan turden, veriye erisim, presentasyon turunden tutkal kodlardan urunlerden ve bu alanda secenekten bahsediyorum.

0
bm
PDF endexleme kismini bilmiyorum. PDF yaratmak icin: http://www.fractalconcept.com/asp/html/cl-pdf.html [www.fractalconcept.com]

JSTl nedir ben bilmiyorum! Java birsey herhalde. Javayla pek bir alakam olmadi benim, bilemiyorum. Ne yapar?

nesne object->relational mapping mi demek? Bunun bir susru metodu var, bir kismi (Allegrostore mesela) hem pahali hem arkasinda object DB var, Oracle degil. Yanliz zaten bircok iste RDBMS luzumsuz kullaniliyor bence. Mesela cl-prevalence cuk oturan bir ornek bukonuda. (Bunu zaten mysql'in 3-5 sene evvelki ACID uyumlu omayan kullanimindan anlayabiliriz).

JSP icin, bir suru insan bunda da ne varmis deyip kendileri yaziyorlar. Mesela: http://lemonodor.com/archives/000128.html [lemonodor.com]

Su bakimdan haklisniz: "21 Gunde birsey" cinsi kitaplara dusmus seyler icin CL su anda uygun olmayabilir. En azindan is derinlesmediyse personele bagimlilik acisindan sokatan toplanan insana yaptirilabilecek isi, sokaktan poplanan insanin anlayamayacagi sekilde yapmak makul degil. Yanliz, isler basit baslayip sonra komplike hale gelebiliyor tabi. O zaman da personel sIkIsikligi oluyor ama artik teknoloji secmek icin zaten gec oldugundan ciidi bilgisi olan insanlar asil ozelligi 'populerlik' olan platformlardan ekmek yiyorlar. (Bunu FM cemiyeti icinde sizin gayet iyi bildiginizi tahmin ediyorum, 'evet lisp ama' tarzi buna isaret ediyor en azindan).
0
malkocoglu_2
||Su bakimdan haklisniz: "21 Gunde birsey"
||cinsi kitaplara dusmus seyler icin CL su
||anda uygun olmayabilir

Bilgi islem dunyasinda tum problem burada kilitleniyor zaten. Yığınlara yakin, "bildikleri bir seye" benzeyen teknoloji, vs.. bir sekilde uste cikiyor. Cunku, mesela eger bir danisman sirketi sahibi olsam ve programcilar ne kullansin gibi bir karari irdelemek zorunda olsam, isimi yapmak zorunda olacak elleri nereden bulacagim sorusuyla olaya yaklasirdim. Cunku B.I.'de sirket icin tek bir dil secimi yapmak en iyisi , egitimin yayilmasi (ozmosis ve diger yollarla), gelistirme ortami benzerligi (uniformity) gibi acilardan bunun yararlari var. O projede o dil, bu projede bu dil danisman sirketleri icin iyi olmuyor. Java'nin su anki yerine iste bu tur adamlara borclu oldugunu dusunuyorum, danisman sirketleri ve benzeri turden yazilimda "seri uretim" yapan adamlara. Bu adamlar, 1-5-10-100 programci ile de yetinmediikleri icin hep "ilerideki populer (buzz) teknolojiye" oynamak zorundalar, ve belkide fazla buyuk dusunerek ve hareket ederek bir teknolojiyi boyle buyutebiliyorlar. Java'nin su anki konumu, bir çığ buyumesidir, trend hakikaten muthis. Kotu yan etki olarak tum oksijeni icine cekiyor tabii.

object->relational mapping den bahseiyorum evet. Hibernate ozellikle iliskisel tabanlar ile yasamaya ozen gosteriyor, object DB'lerin zembille inmesini biz BI'cilar cok bekledik, ama artik beklemiyoruz. Zaten iliskisel tabanlarin performans olarak cok iyiler, ve teorik temelleri cok saglam. Tabii gene soyleyeyim, pur bilgi islem den bahseiyorum, sayilar ve string itekleyen (!) programlardan.

JSTL JSP'nin daha gelismis hali, yeni etiketler iceriyor. Java ile entegrasyonu bilahere cok iyi. Ayrica Java ile yeni JSP etiketleri yazmak mumkun.
0
FZ
Ne 300'ü 500'ü yahu, çok daha az MB'lik veri için bile veri tabanı kullanmaya gerek yok desek adamı döverler bu memlekette! :)

Öte yandan RebelWithACause'cu elemanlar demişler ki (evet utanmadan ve yüzsüzce demişler ki):

In most non-trivial projects, persistent data storage is needed. Often, an SQL database is used for this purpose. Although there is nothing wrong with this, mapping an object domain model to a relational database is complex, error prone and not very efficient. In most projects, setting up this translation layer takes a lot of developer time. The fact that the object domain model must eventually map to a relational database, limits the designer in using all powerful features that object technology can offer.

Object prevalence is a concept that was developed by Klaus Wuestefeld and some colleagues at Objective Solutions. It basically states the following: most database are small enough to keep them completely in RAM, so the object domain model effectively becomes the database. Querying is ultra fast and very natural: just use the API of the programming language. Modifications are done through transaction objects, serializeable objects that contain all the data they need to apply the change. When executing a transaction, the change is applied to the object model and written out to a transaction log file by serializing it. This operation is fast as well. When the system crashes, the previous state is restored by replaying the transaction log. Multi-threaded access to the system is serialized on a simple lock. Since transactions are fast this is no real problem. Furthermore, there are often more readers than writers, and only a small number of readers need exclusive system access. When the transaction log becomes to big, it is possible to make a snapshot, a serialization of all known objects in the system.

We used our own implementation of object prevalence for Common Lisp (see Common Lisp Prevalence). This particular implementation serializes to XML, which is relatively slow and bulky but robust and portable. In this project we added two extensions: blobs and generic transactions. Blobs are a mechanism to handle larger binary objects in prevalence, keeping the meta information as a normal Lisp object while storing the actual bytes in an automatically managed file. Today we save about 40 Mb worth of data by this mechanism. Generic transactions were introduced because basic object operations like create, change and delete are so common that we became tired of writing unique transactions for each class.


Şimdi tabii sorgulama işi ne kadar esnektir orasını bilemiyorum. Görebildiğim kadarı ile tek bir sorgu örneği var, normalde SQL ile kurulan karmaşık JOIN yapıları söz konusu olduğunda yukarıda tarif edilen sistemdeki olası sorgulama örneklerine bakıp karşılaştırmak lazım hangisi daha kolay anlaşılıyor diye (aslında programcı psikolojisi ve bilişsel bilim bağlamında bu başlı başına bir araştırma konusu, maalesef bunda kontrollü deney yapmak o kadar kolay değil!)

Dikkatimi çeken diğer bölüm:

The success of the Web gave rise to a new kind of application: Web Applications. These are applications that are accessed by their users through an ordinary web browser. The purest kind of web applications are those requiring no special plugins at all: just plain HTML (see The Web Standards Project). The project described above is an example, as are most shopping sites, like Amazon or the Apple Store. Actually, almost all advanced web sites are dynamic websites: they compute their pages from a database, allow searching, allow users to log in, manage preferences, offer mailing lists and forums. Dynamic, interactive web applications look simple at first sight, but are notoriously hard to build and difficult to adapt to changing requirements.

The internet is built on open standards that are platform and language neutral. This allows web applications to be build using almost any technology. And indeed, successful web applications have been build in C, C++, Java, Perl, Python, PHP, and many others on Unix, Linux, Windows and Macintosh using all sorts of frameworks. The great thing is, as a user you can hardly see the difference (apart from the fact that some site are obviously better than others).

As software developers we had the most experience building web applications using Java technology. In the Java world you find all the necessary tools, frameworks, libraries and servers to build almost anything. Java is very good at absorbing all the great abstractions like object technology, garbage collection, model-view-controller, layered systems. However, the Java world is becoming very large and complex. And all things touched by Java (especially the J2EE part) have a tendency to become overly verbose and cumbersome. This is partly because of limitations in the Java language itself (full static typing, no interactive or dynamic modifications at runtime, little room for data driven programming) and partly it is a community thing (standards reached by consensus and political motivations).

Because we had a past exposure to both Lisp and Smalltalk, we knew that there were very good alternatives to Java. Thanks to Java, a type-safe runtime with automatic memory management and garbage collection became accepted both on the client and server side. People now know that the small price in performance is dwarfed by the advantages in productivity. Lisp and Smalltalk easily match Java feature-wise, but add full dynamic typing, allow interactive and dynamic modifications at runtime and allow for much easier data driven programming. The best part is that current Lisp and Smalltalk implementations often consume less memory and run faster than Java.

0
bm
Ayrica bu XML serialization isinin yavas olmasi kusuru icin birsey ekleyeyim (baska dillar icin de bu gecerli). Copy-on-write kullanan POSIX uyumlu isletim sistemlerinde bu verilerin resmini cekme isinin yavas olmasinin kolayimsi caresi var: veri tabani tutarli durumdayken fork edersiniz, cocuk diske yazarken babasi isine devam eder. Verilere ellenecekse COW zaten kopyalar. (Bunu ben akil ettim zannediyordum, tabi basklari da yapiyormus. En azindan bir lispci biliyorum bunu yapan.).

0
malkocoglu_2
||Kaldı ki Lisp'in sadece YZ için uygun olup

Bir de:: YZ'de LISP kullaniliyor, evet. Fakat Yapay Ogrenim (machine learning) alaninda ilginctir ki MATLAB en onde, orada da LISP onde degil. Yani YZ ile YO, "alakali alanlar" olarak ayni dili kullanabileceklerini dusunurdunuz degil mi? Iste oyle olmuyor. YZ den sonra YO dersi sirasinda "aaah keske" demistim, fakat veri setlerini gorselleme, dogrusal cebir destegi ile Matlab pur dil seviyesinde daha kotu olsa bile, secenek olarak onde gelmistir. Dogrusal cebir destegi, iste daha once bahsettigim gibi "cevresel, APIsal" konulardan biridir, ve dil secimi cogu zaman bu cevresel konu etrafinda da donmektedir.

0
FZ
Güzel bir konuya, önemli bir noktaya değinilmiş! Bu konularda çalışan bir araştırmacı var yurt dışında, Tunç Şimşek [ http://robotics.eecs.berkeley.edu/~simsek/], belki bu adamın geliştirdiği Matlisp: a matrix package for Common Lisp konu ile ilgilenenlere yol gösterebilir. Şimşek neden böyle bir yaklaşım benimsediğini ve böyle bir sistemi neden Matlab, RLab, Octave gibi sistemlere tercih ettiğini şu sözlerle açıklamış:

What About Matlab, Rlab, Octave, etc?
While all of these are good at what they do, they all have a fundamental limitation: Everything is a matrix. You have no alternative. Either you make your problem fit into a matrix, or you can't use these languages.

MatLisp frees you from this limitation -- you have at your disposal, the complete functionality of Common Lisp, including structures, hash tables, lists, arrays, and the Common Lisp Object System (CLOS). MatLisp adds to this richness by giving you a matrix fast class based on BLAS and LAPACK.

Thus, you can think about your problem in the most natural way, without having to force everything into a matrix. In the natural way, you can then use a matrix, and achieve high performance.

Tabii bu konu ile ilgili varsa diğer arkadaşların da yorumlarını bekliyorum yani yoğun olarak lineer cebir vs. konularını bu bağlamda kullanmış olup kıyaslama yapabilecek arkadaşlar da katkıda bulunurlarsa eleştirileri ile güzel olur, daha detaylı bilgi sahibi olmuş oluruz.
0
malkocoglu_2
Matlab'in gorselleme ozelliklerini unutmayalim ... Hatta cok guclu plot'lama ozelliginin oldugunu soylemeliyim. Sinyal isleme, goruntu isleme kutuphaneleri de mevcut. Goruntu isleme ile biraz ugrastim, mesela

A = imread("ggg.jpg");

.. ile indeklenmis (array uzerinde matrisler) icinde R-G-B piksel degerlerini yuklemis oluyorsunuz. image(A) ile resim aninda gozukuyor. Muthis bir prototipleme platformu. Ve butun bunlar tek paketten cikiyor. Tabii ticari ortamda calisacak sonuc ortamindan (production) bahsediyorsak, bu degisik olabilir, ama o kisim C++'da da yazilabilir.

0
bm
(Hqk vermiyor degilim ama mendeburlugum ustumde):

http://matthieu.villeneuve.free.fr/dev/imago/examples.html [matthieu.villeneuve.free.fr]
0
malkocoglu_2
Bu goruntu islem kodlari, daha once verilen MathLisp ile ne kadar rahat entegre olur acaba... ? Matlab de Sembolik math var, istatistik var, quadratic sistem cozumu var, var da var. Ve bunlarin hepsinin matris etrafinda donuyorlar (bu bir ozellik, hata degil). Yani, Matlab'in ufak bir parcasinin benzerini bulursunuz da, tumu ne olacak? Ustelik bu goruntu islemenin Matlab ornegi kadar temiz oldugu biraz supheli.

Yani, final teziniz nedir? Bilgi islemden, YO'dan ve matematikten bu kadar ornekten sorna, hala LISP her yerde kullanilsin diyor musunuz? Yarin degil, bugun. Hoca olsaniz, dersinizde LISP + MathLisp + "toparlama bir takim kutuphaneleri kullanin iste" diyebilir misiniz?

0
bm
Final tezimiz yoktur! Ama dedigimiz sudur: cok kisitli insan gucuyle ortaya cikan seyler ortada. Ciddi olarak kullanlarin kolay vazgecmedikleri de ortada. 40 kusur senedir kiyamet kadar insan tarafindan veto edilip kotulenmesine ('yavas' 'derleyicisi yok' 'garip' 'sihirbazsiz program dili mi olurmus?' "kullananlarin bir kismi bilgisayar bilimine hakim' (!)filan gibi sacma sebepler cogu) ragmen gebermedigine gore, belki biraz bakilmasinda fayda vardir. Yoksa matlab kullanan Lisp kullansin demiyorum. Ozellikle TR baglaminda teorik bilgisayar bilimine filan bulasmadan da "iste karsina IDE cikar maymun gibi oynarsin, *SQL, dot-foo, Jfoo gibi en son teknolojiler kullanirsin" yavanligina bulasmadan makineye is yaptirmanin iyi yollarinin oldugu ve 'orada' esasinda bir harikulade bir umman oldugunu gostermenin iyi bir yolu Common Lisp'i tanitmak diyorum. Baskalari baska seyler de diyor tabi: http://alu.cliki.net/RtL%20Highlight%20Film [alu.cliki.net].

Ne matlispi ne imago'yu kullanmadim ben, bilmiyorum. (libmagick'i ve blas'i direkt kullandigim oldu lispten bu tip isler icin, ama pakete gerek kalmayacak kadar basitti o isler). O ornekler kutuphanelerin kit olmadigini gostermek icin verilmis ornekler sadece.
0
bm
Ne iyi! Ilgi olursa bunlari (kodu, yazilari degil) biraz daha lisp stiline cevirip ornek olarak gostermek iyi olur. Musadenizle bir iki ipucu vereyim (A*'a baktim) guncel Common Lisp kullanimina cevirme acisindan hem de arsivlenmis olsun (belki baskalari da merak edip bakar, gayemiz de bu zaten! Hatta bana oyle degildir deyin simdi daha cok konusalim).

(setq foo (incf foo))

gereksiz, cunku incf setf usteunden calisiyor zaten foo'yu degistiriyor. CLSH'de incf

"Extended loop" yahut "do" elle incf decf yapmak yerine tercih edilebilir. FZ bayildi extended loop'a gorunce, seveni var sevmeyeni var tabi. En iyi kaynak: http://www.gigamonkeys.com/book/loop-for-black-belts.html [www.gigamonkeys.com]


Bir de belki ilginc gelecek bir ornek vereyim: http://www.dynamiclearningcenter.com/samples/ray-tracing/index.html [www.dynamiclearningcenter.com]




0
FZ
Müsaade edin de bayılayım geliştirilmiş döngü yapısına. Yani yıllardır VBScript ve JScript ile sürünen biriyim. Perl hadi neyse diyorum ama misal Java camiasına bakınca "aa, bakın 1.5 sürümümüzde şöyle bir şey ekledik artık daha gelişmiş ve kolay anlaşılır döngü yapıları kurabileceksiniz" falan diyorlar, Common Lisp camiasına bakıyorum adamlar "allah allah, buna yenilik mi diyorsunuz biz bunu ve daha fazlasını zaten çoktan kullanıyorduk" diyorlar :) (Ve benzer cümleyi sarf ettikleri, benzer tavrı takındıkları tek konu da döngü konusu değil, dikkatinizi çekerim!)
0
bm
Evet, oyle 'biz bunu 20-30 senedir biliyoruz/yapiyoruz' denir. Cogunlukla da hakikaten biliniyordur. Herkesin hosuna gitmez bu ama: http://c2.com/cgi/wiki?SmugLispWeenie.
0
malkocoglu_2
Yorumlar icin tesekkurler. Eger (kod icindeki) birim testleri aynen gecen bu kodun daha temizini yazarsaniz, sitede yayinlarim.
0
bm
OK, bayramda ayrintili birsey yazayim. "iyi programcinin yazdigi lisp'ten 'lispcinin yazdigi lisp'e gecis ornegi olur harika olur. Tesekkurler.
0
FZ
İçimden bir ses epey sağlam bir "öğretici" (tutorial) belge çıkmak üzere olduğunu söylüyor ;-)
0
FZ
Lisp, Common Lisp, matematik ve programlama ile ilgili vikipedyaya giriş yaptım, bir göz atarsanız sevinirim:

http://tr.wikipedia.org/wiki/Matematik#Matematik_Yaz.C4.B1l.C4.B1mlar.C4.B1

http://tr.wikipedia.org/wiki/Macsyma

http://tr.wikipedia.org/wiki/Maxima
0
FZ
Konu ile ilgili yorumları, yazıları, bağlantıları tek bir yerde toplamak namına:


http://www.bilgidata.com/yorum_goster.jsp?id=002-00000t-001

http://www.bilgidata.com/yorum_goster.jsp?id=002-00000t-002

http://www.yapay-zeka.org/modules.php?name=News&file=article&sid=97
0
bm
Hmm acaba phoaks cinsi birsey yapilabilir mi? Yani linkeri bir yerde toplayip makalenin altinda "aha bu linkleri verdi yorumcular" demek? Bunu haber cesidi bazinda da yapmak makul olabilir mumkunse.

Görüş belirtmek için giriş yapın...

İlgili Yazılar

AçıkAkademi'den TCP/IP ve Ağ Güvenliği Kitabı

honal

Her geçen gün kalitesini artıran ve yayın yelpazesini genişleten yayınevimiz yeni kitabını siz okuyuculara sunmaktan büyük mutluluk duymaktadır.

"Teori ve Uygulamalar ile TCP/IP ve Ağ Güvenliği" ismini taşıyan kitabımızın yazarı Can Okan Dirican'dır. Yazarın üzerinde aylardır emek harcadığı ve alanında yetkin uluslararası tüm kaynakları referans olarak kullandığı kitap TCP/IP ile ilgili hemen her konuyu içermektedir.

Kabalcı Kapandı

butch

Beşiktaş ve aslında bütün İstanbul sakinleri için simge mekanlardan biri, Kabalcı Kitabevi kapandı.

Kabalcı'yı özellikle, yayınladığı pek çok “niş” nitelikteki kitap ve tabi belki bizim için en önemlisi Otostopçunun Galaksi Rehberi'ni tekrar basımıyla severek anıyoruz. Yaklaşık 30 yıldır kitap severlerin önemli bir durağı, İstanbul sakinlerinin buluşma yeriydi Kabalcı. Kapanışının...

Ve yine Kevin Mitnick, bu sefer basımdan önce kaldırılmış ilk bölüm

Phaedrus

Kevin Mitnick´in yazdığı Art of Deception adlı kitaptan Wiley yayınevi tarafından basımdan hemen önce çıkartılan ilk bölümü Bu adreste okuyabilirsiniz. Genel olarak bu bölüm Mitnick´in geçirdiği kaçak günleri, hapisteki zamanlarını ve medyada Mitnick´in adıyla ve düzenlediği asılsız, popülist haberlerle, ardından da yazdığı kitapla milyon dolarlar kazanan gazeteci John Markoff´u anlatıyor.

OpenBSD'de Basit Ağ Ayarları ve PF (Packet Filter) Kullanımı

honal

OpenBSD üzerinde PF(PacketFilter) kullanarak kendi "firewall" sistemlerini oluşturmak isteyenler için yol gösterici olabilecek bir dökümanı http://cc.kou.edu.tr/huzeyfe/openbsd/pf.pdf adresinden elde edebilirsiniz.

Bedava Linux34 El Kitabı

anonim

18 Sayfadan oluşan Linux34 El Kitabi isteyen Herkese Bedava olarak gönderilir.Konsol Komutları, mount işlemleri, kurtarma, kernel, network kartı tanımlaması konusunda bilgi içermektedir. Kargo ücreti alıcıya aittir.