Son zamanlarda, vakit buldukça Scheme çalışıyorum. Hedefim Scheme tabanlı bir betik sistemi geliştirmek ve bunu büyük, çok kullanıcılı bir macera oyunu için kullanmak. Öyle bir oyun düşünün ki içinde çevre simülasyonundan (av/avcı çevrimleri,vs.), üç boyutlu modellere kadar (betiklerle birleştirilmiş geometrik algoritmalar, örn. enteresan doğa görüntüleri oluşturmak işin gelişigüzel sayı üreticilerini temel alarak büyüyen agaçların grafikleri) pek çok sey. Scheme ilgi çekici görünüyor çünkü basit, güçlü ve iş parçacıklı yorumlayıcı fikrine iyi uyuyor.

Scheme'i her yönüyle öğrenmek için "The Little Schemer" ve ayrıca "Structure and Interpretation of Computer Programs"ı okuyordum. Önerebileceğiniz başka iyi Scheme programlama metinleri var mı?

KMP: Kitapların bir listesini Schemers sitesinde bulabilirsiniz. Eğer bu çok sayıdaki ihtimalleri daraltmaya yardımcı olabilecek belirli bir gereksinim ya da tercih belirtebiliyorsanız, comp.lang.scheme haber grubuna daha detaylı bir bilgi isteği göndermenizi tavsiye ederim.

13) Lisp'in gözden kaçan pratik yönleri
hding

Sizce insanlar niçin çok sık Common Lisp'in çıkış koruması, bütün koşul sistemi (whole condition system) (ki siz elbette bununla yakından ilgilisiniz) gibi, günlük programlama için çok kullanışlı olan mükemmel özelliklerini gözardı ediyorlar ve sizin özellikle altını çizeceğiniz, var olan ya da tam tersine standart olmasını umduğunuz halde var olmayan özellikler nelerdir?

Bu arada, comp.lang.lisp'e büyük cömertlikle ve düzenli olarak kattığınız tüm bilgiler için teşşekkür ederim.

KMP: Açıkçası, insanlar bildikleri araçlarla programlama yaparlar. Birinin, ilk dil tercihi olmadığı sürece, Common Lisp'in alışık olmadığı özelliklerini gözardı etmesi kolay olur. Burada biraz çelişki var çünkü çoğu zaman, insanların bir dili kullanmaktan vazgeçmelerinin sebebi, bu dille yapabileceklerinin sınırına ulaşmış olmaları ve daha fazla güce ihtiyaç duymalarıdır. Bu yüzden insanların ısrarla yeni dilin, eskiden kullandıklarından farklı olan özelliklerini aramalarını beklersiniz. Tabii muhtemelen bazıları bunu yapar. Ama haklısınız, bazıları da eski dildeki operatörlerden buldukları güvenlik ve alışkanlıklara tutunurlar ve böylece yeni dilin onlara önereceklerini kaçırırlar.

İyi ki çıkış koruması sonunda (finally) Java'da da mevcut (kinaye için kusura bakmayın). Ve aynı zamanda Common Lisp koşul sisteminin ipuçları bunu Java'ya sevketti. Böylece Common Lisp'e Java'dan gelen insanlar, muhtemelen bu özellikleri aramaya eğilimli olacaklardır. Ama keşfedilecek çok daha fazla başka şey var ve umarım yeni kullanıcılar meraklarının peşine düşer ve araştırmak için zaman ayırırlar.

Dilde neye sahip olmamız gerektiğine gelince, en eksik detay; bir tür sistem tanımlama aracı (make'in Lisp içi benzeri). 1988'de ANSI Common Lisp'e özellik eklemeyi dondurmamız fakat 1994'e kadar standardı çıkartmamamız çok yazık oldu. Böyle bir aracı ekleme fikri de dondurma sonrasındaki bölüme kadar gelmedi. Tüm üreticiler böyle bir imkan sunuyorlar ama birörnek bir çözüm olsaydı, programlar daha kullanışlı olurdu.

Ayrıca Common Lisp hakkında, aynı veya benzer biçimde, neredeyse tüm uygulamalarda bulunan bir hayli şey var. Çoklu-görevlendirme, yuvalar, veritabanı erişimi, harici işlev çağırma, pencerelendirme Bunların herhangi birini içermiş olmak fena olmazdı ama gerçek şu ki bunlar 1988'deki standardizasyon için hazır değillerdi. Gerçi bu noktada ilerlemek için standartlar değil de, başka yöntemlerin doğru yol olduğunu düşünüyorum.

Lisp topluluğu, yeni bir yararlığın dağıtım yönteminin, yeni bir dil spesifikasyonu olmasını bekler. Ama bu, standart kurumlarının oybirliğinin sağlanmasını gerektirir. Problem, doğalarından dolayı, standart kurumlarının eşleme düzenekleri olmalarıdır. Oldukçe paralel bir dünyada, bu eşleme düzenekleriyle olan problem, işleri yavaşlatmalarıdır. Dünya bizim yavaşlamamızı beklemeyecektir, bu yüzden dışarıdan etkilenen belirli bir ilerleme hızıyla, daha iyi çalışan mekanizmalar geliştirmemiz gerektiğini düşünüyorum.

Bence bu, Lisp'in topluluk olarak cevap vermekte geç kaldığı bir alan. Topluluğumuzun üreticiliğinin faydalarını en iyi şekilde almayı sağlayacak, insanların Lisp'te yaratmakta olduğu mükemmel ticari ve şahsi paketleri paylaşmak için, topluluk mekanizmaları olması gerekiyor. Bunun değiştiğine dair belirtiler görüyorum. Common Lisp Open Code Collection (CLOCC) (Common Lisp Açık Kod Koleksiyonu), açık kaynak koda hitap eden bu mekanizmalardan biri. Özel mülk olan ürünlerin değişimi için de benzer mekanizmaları görmek isterdim.

comp.lang.lisp haber grubundaki gönderilerime gelince, teşekkür ederim. Hoşunuza gittiğine sevindim. Açıkçası, kimsenin kafasını ütülemediğimi duyduğum her anı, bir zafer sayıyorum. Arka planda, Lisp hakkındaki bazı kitapları bir araya toplamaya çalışıyorum ama bu işlerin bitip bitmeyeceği belli olmuyor. comp.lang.lisp'i bir çeşit sigorta poliçesi olarak görüyorum ve kariyerim boyunca gördüğüm ve yaptığım şeylerin en azından bir kısmının bireysel bellekten, küresel grup belleğine transfer olduğuna ikna oluyorum.

Bence tarih için, kişisel deneyimleri korumak epey önemlidir. Gelecekte, online işbirliği araçlarının tuttuğu günlükler sayesinde, bu doğal olarak gerçekleşecektir. Ama ben özellikle 1960 (programlama dillerinin doğuşu) ile 1994 (WWW'nin doğuşu) arasında olanların kayıtları hakkında endişeliyim. Bu zaman sürecindeki çoğu şey kağıda kayıtlı ve sonuç olarak kaybolacak. Gelecekten geriye bakınca, bilgi toplumunun nasıl doğduğunu anlamanın, teleskopla evrenin doğuşunu görmek kadar kafa karıştırıcı olacağını düşünüyorum. Çok yaklaşacaksınız ama sonunda hiçbir şey göremeyeceğiniz bir noktaya geleceksiniz. Büyük bilgisel patlama. Ben eski yazılı araştırmalarımın webde yayılması için çalışıyorum ve umarım bu alanda çalışan diğerleri de aynısını yapmayı üstlenirler.

14) Lisp - Scheme - ML
Tom7

CMU gibi birçok büyük akademik (eskiden) Lisp üreticisinin Lisp'ten, ML ve benzerlerine geçtiğini biliyorum. Bunun için öne sürülebilecek nedenlerden bazıları şunlar:

• Programınız çalışmadan hataları yakalayan, güvenliği sağlayan gelişmiş tür sistemleri.
• Tür kullanan derleme yöntemi sayesinde, daha fazla verimlilik. (http://www.bagley.org/~doug/shootout/craps.shtml).
• Arttırılmış modülerlik ve soyutlama.
• Örüntü eşleştirme, (bence) daha doğal sözdizim.

Aslında ben de bu insanlardan biriyim. Lisp kullanıcıları benle dalga geçiyorlardı ama çoğu daha önce hiç ML kullanmamışlardı. Ama ben açık fikirlyim, o yüzden çağdaş diller çerçevesinde Lisp ve Scheme ne faydalar sağlıyorlar? Bu faydaların, türü belirlenmiş diller ile gerçekten elde edilemeyeceğini düşünüyor musunuz?

KMP: Öncellikle belirlenmiş demek ile statik olarak belirlenmiş demek istediğinizi varsayıyorum. Ben Lisp'i dinamik olarak değişken türü belirtilen düşünüyorum ve çoğu makine dilini de değişken türü belirlenmemiş olarak görüyorum. Statik olarak değişken türü belirtilen dillere bazen sağlam olarak tür belirtilen diller dendiğini duyuyorum ve sıkça ister istemez ben de bu terimi kullanıyorum ama bunu sevmemeye başladım çünkü bence sağlamlık tür denetiminin yapılıp yapılmayacağı anlamına geliyor, ne zaman yapılacağı değil. Statik ve dinamik terimleri konuyu kalbinden vurmak için bana daha iyi geliyor.

Abraham Lincoln'ün dediği gibi, bu bağlamın biraz dışında kaldığını kabul ederek, "Bu tür bir şeyi seven insanlar, bunu sevdikleri türden bir şey olarak bulacaklardır." Lincoln'ün açıklamalarını kabaca çağdaş bağlamda, sonuca mecburen birazcık siyasi yön vererek, tekrar yorumlarsak: Fonksiyonel dillerin, onları seven kişileri çektiği gerçeği, bu dillerin genel amaç için çekici olduklarını kanıtlamaz.

Bence CMU'nun (ya da bağış destekli üniversitelerin) yönünü değiştirmesinin gerçek sebebi, "yeni ve farklı" araştırmalar için verilen iyi bağış kaynaklarıdır. Böyle bir kayma, geride kalanın "denenmiş ve doğru olmadığı" anlamına değil, sadece denenmiş ve doğru olanın araştırma için gereken dolarları getirmediği anlamına gelir. Araştırma sürekli bir hareketlenme yaratmak zorundadır ama bu önceden gelmiş olanın modasının geçtiği anlamına gelmez. Bu yüzden, bundan çok fazla şey çıkarmayın.

Bahsettiğiniz bütün konuları ayrıntılarıyla cevaplamak ayrı bir makale gerektirebilir ama kısaca her birine değineceğim:

• Programınız çalışmadan hataları yakalayan, güvenliği sağlayan gelişmiş tür sistemleri. Tür kullanan derleme yöntemi sayesinde, daha fazla verimlilik.
• Aslında, hem CMU projesinden bahsedip hem de bu yorumları yapmanız tuhaf. Common Lisp'ten uzaklaşmadan önce CMU kitlesi, Lisp topluluğunun kanaatine, Common Lisp dilinin tasarımıyla sunulan ve bugün uygulamalarda hala işlenmemiş olan tür çıkarsama açısından muazzam olanakları göstermede başarılıydı. Bu hakikaten bir pazarlama meselesi, dil tasarlama meselesi değil. Gerçek şu ki, diğer diller çok daha fazla tür çıkarsaması yapmalarına rağmen, satıcılar tür çıkarsamanın programcılar ile onların ürünlerinin ticari başarısı arasında olduğuna dair, öyle çok sayıda hata raporları almıyorlar. Zaman içerisinde, zannediyorum çok daha ilginç tür incelemelerinin yapıldığını göreceksiniz ama bu tip bir iş her zaman kullanıcıların diğer ihityaçları ile dengelenir; CORBA, COM, RMI ve KA (Kullanıcı Arayüzü) araç takımları ve ayıklama seçenekleri gibi web arayüzleri. Gözlemlediğim zaman, sık sık yaptığım gibi, dillerin siyasi parti olması derken bunu kasdediyorum. Her biri dünyanın değil, sadece kendi seçmenlerinin ihtiyaçlarına karşılık verirler. Ve Lisp seçmenleri, tür çıkarsaması konusunda ilgisiz olmasa da, bu konuyu bir numaralı öncelik olarak görmezler.


• Artırılmış modülerlik ve soyutlama.
• Bu bir hayli çok boyutlu bir alan. Bence Lisp modülerlik ve soyutlama için diğer dillerin sağlamadığı kadar mükemmel olanaklar sunuyor. Ve benim bazen hala istediğim gibi soyutlaştıramadığım şeyler var. Küçük bir eksiklik örneği: Common Lispin CLOS'u, Zetalisp'in New Flavors'ı gibi protokol soyutlaması yapmıyor; diğer şeylerin üstünde, kimse bazı gerçekleştirilmemiş yöntemlerin gerektiğini bildiremiyor. Ama büyük sistemlerin ve Meta-Object Protocol (MOP)ün (Üst Nesne Protokolü) kullanılması ile böyle bir şey eklenebilir. Dahası paket sistemi, benim sıkça arzuladığım kimi çeşit kalıt yeteneğinden yoksun ama ben yakınlarda oturup kendim kullanmak için defpackage'a, kendi araçlarımın kullanabileceği yetenekleri eklediğim sürümler yazdım ve hiç zorluk çekmedim. Genellikle, Common Lisp'in soyutlama yeteneklerinin sınırlarını derin değil, yüzeysel buldum ve sözdizimsel esneklik yeteneklerinin çok daha güçlü olduğunu gördüm.



• Örüntü eşleştirme.
• Lisp'in örüntü eşleştirme yapmadığı konusunda sanırım haklısınız ¹. Bunun iyi ya da kötü bir şey olup olmadığı özneldir. Sanırım örüntü eşleştirmeyi seven insanlar da var, sevmeyenler de. Tarafsız olmak gerekirse, aslında, kariyerimde örüntü eşleştirmeyi çok aradığım zamanlarda, bunu kendim kolayca gerçekleştirebiliyordum. Ve, önemli olarak, Lisp'in sözdizimsel esnekliği benim yazdığım programlarda, dil tarafından özgün olarak sağlanmış gibi doğal görünen, kişisel gerçekleştirme yapmamı sağladı; çoğu diğer diller bana dile uygun yeni yararlık eklememi sağlayan sözdizimsel denetimi vermiyor. Bu yüzden şahsen, bunu önemli bir eksi olarak görmüyorum; daha çok bunu sizin ve sizin gibi diğerlerinin ihtiyaçlarını karşılayacak bir katmanlı kitaplık yaratma olanağı olarak görüyorum.

• (Öznel olarak) daha doğal sözdizim.
• Ben herhangi bir dilin büyük bölümünün doğal sözdizimine sahip olduğunu örneklemenin mümkün olmadığını düşünüyorum. COBOL ve HyperTalk bunun üzerinde çok çalıştı ve onlarla herhangi doğal bir dil arasında büyük bir fark var. Ben şahsen sesli söyleyebileeğiniz simgeler üzerinde odaklanan, bunları gruplamayı belirtmek için en düşük şekilde imleyen Lisp sözdizimini dikkat çekecek derecede doğal buluyorum. Diğer diller epey seçici yollarla kullanılan virgüller, noktalı virgüller, yıldız imi ve parantez çeşitleri gibi özel amaçlı imleçler içeriyorlar. Tüm bunlar demek oluyor ki bu konuda haklısınız: bu konu özneldir. Umarım ben de bunu adilce berabere bitirmişimdir.

15) Matematik Programlamada Lisp
İsimsiz Korkak

Gregory Chaitin'in "The Limits of Mathematics" isimli bir kitabı var. Burada, matematikçilerin Lisp'i sevmesi gerektiğini çünkü Lisp'in temel olarak küme kuramı olduğunu ve tüm matematikçilerin de küme kuramını sevdiğini iddia ediyor. Ben tüm kalbimle bu konuda kendisiyle hemfikirim, şaşırtıcı eksiklik sonuçlarına ne kadar çabuk ve sade varıldığını anlamak için Chaitinin Lisp programlarına bakmak yeterli. Böylece Lisp'in bu tür şeyler için mükemmel olduğunu biliyoruz; matematiksel bir araştırma için. Lisp'in bu kuramları gösteren ve keşfeden yönde devam ettiğini mi düşünüyorsunuz yoksa endüstriye mi kayacak? Yoksa endüstriye kaydı da haberimiz mi yok? NASA ve JPL benzerleri, Lisp ve Scheme'i ciddi bir biçimde kullanıyorlar mı? Eminim öyledir.

KMP:Lisp, matematik (mantık, genel matematik, asal sayılar, vb.) gibi soyut başlıklara ve yapay zekaya hitap etmek için bir yol olarak çıkmış olabilir ama uzun zaman önce ticari uygulamalara geçiş yaptı. Hem Scheme hem de Common Lisp, sizi şaşırtabilecek günlük hayat işleri için kullanılmış ve halen kullanılmakta. Bunların arasında (ki bunlarla sınırlı değil) havayolu tarifelendirmesi, ticari veritabanı idaresi, bilgisayar işletim sistemleri, biyomühendislik, web hizmetleri, belge biçim çevrimi ve, evet, hatta uzay araştırmaları var.Franz, Inc.in Lisp başarı hikayelerinin, bana bu soru için ayrılan yerde benim yapabileceğimden daha iyi, geniş, epey güzel bir sayfası var. Ve NASA/JPLden bahsederken, Lisp'in Java ve C++ ile karşılaştırılması çalışmaları var, bazıları ilginç bulabilir.

16) Bilgisayar Bilimlerinde Scheme
İsimsiz Korkak

Dünyadaki çoğu popüler BB (Bilgisayar Bilimleri) programlarının, öğretim dili olarak Scheme kullandığı görülüyor. Çoğu zaman öğrenciler, C ya da piyasaya uygun bir dil öğrenmeyi tercih ettiklerini söyleyerek, bundan şikayet ediyorlar. Ben de böyleydim ama artık düşüncemin yanlışlığını anladım. Yeni programların Scheme ile belki yazılamayabileceğine fakat Scheme öğrenmenin bir öğrencinin zamanına değeceğine, diğerlerini nasıl ikna ettiniz? Çoğu, okul dışında kullanmayacaklarsa bunu öğrenmemeleri gerektiği konusunda takılıyor. Bunları, parazitler yerine bilgin vatandaşlar yapmak için nasıl ikna edebiliriz?

KMP: Bence bir öğrenciye açıklanması gereken şey dünyanın sürekli değiştiği ve her şeyin aynı anda riske atılamayacağıdır. Buna ilaveten, farklı dillerin ve sistemlerin birlikte çalıştığı modern ortamlar çoğu zaman hiç türdeş değillerdir. Özellikle, iş dünyasındaki bir insanda olmayan zaman lüksüne sahip bir BB öğrencisinin, mümkün olduğu kadar fazla farklı programlama dilleri öğrenmeye zaman ayırması gerektğini düşünüyorum. Bu hem öğrencilerin düşünmek için alternatif yollar açığa çıkarmalarını sağlar, hem de sonradan düşünce tarzlarını veya ifade dillerini hemen değiştirebilmelerine zemin hazırlar. İşe girilince, kullanmayı gerektirdiği zaman yeni bir dili öğrenmek için çoğu zaman vakit ayrılamıyor. Önceden bilmek ve sadece bilgiyi tazelemek daha iyi.

İçinde olup biteni hisseden insan alternatif yaklaşımlar aramaya daha yatkındır; bilinmeyenden, ne kadar yardımı olsa da, çok kolay korkulur. O yüzden hazır imkan varken olabildiğince fazla şey tanıyın. Common Lisp ve Scheme, bu arada ben bunları çok farklı iki dil olarak görüyorum, her öğrencinin çalışmasında mutlaka yer almalıdır. Ama bunlar insanın çalışmalarındaki tek şeyler olmamalıdır. Benzer ya da farklı, profesyonel bir programcının sadece yarın değil, tüm hayatı boyunca gerçekten başarılı olabilmesi için bilmesi gereken çok şey var.

Oliver Wendell Holmes çoğunlukla şu sözleriyle anılır: "Yeni bir fikre genişlemiş bir zeka, asla eski özgün boyutuna dönmez." Bir öğrencinin zekasını genişletmek için, dil çeşitlerinin bir listesini yapmalarını ve mümkün olduğunca farklı çeşitleri öğrenmelerini öneriyorum. Akla gelen bazıları, ki benden farklı deneyimleri olanlar da epey katkıda bulunacaklardır, şunlar:

• Blok yapılı bir dil; Algol, Pascal veya Scheme gibi.
• Satır temelli bir dil; Fortran veya BASIC gibi.
• Kural tabanlı bir mantık dili; Prolog veya EMYCIN gibi.
• İngilizcemsi bir dil; HyperTalk veya Cobol gibi.
• Bir yığın işleme dili; PostScript gibi.
• Bir satır parazit dili (tek harfli işleçlerin çok önemli olduğu); APL veya Teco gibi.
• Dinamik nesne yönelimli bir dil; Common Lisp veta Smalltalk gibi.
• Sağlam olarak tür belirlenmiş, statik olarak incelenmiş bir dil; ML veya Haskell gibi.
• Dinamik olarak tür belirtilen bir fonksiyonel programlama dili; Scheme gibi.
• Bir dizgi ya da makro işleme dili; Perl, m4, TeX veya Teco gibi.
• Bir veritabanı erişim dili; SQL gibi.
• Soyut üst düzey bir assembly dili; Java gibi.
• Somut üst düzey bir assembly dili; C gibi.
• Alt düzey, geleneksel bir çevirici dili.
• Bir betikleme dili; Javascript gibi.
• Bir arayüz tanımlama dili; Visual Basic, HyperTalk veya Javascript gibi.
• Bir belge yapılandırma dili; XSL veya TeX gibi.
• Çağdaş bir hata sistemli bir dil; Common Lisp veya Dylan gibi.
• Yansıtıcı/içgözlemli bir dil; Common Lisp veya Java gibi.
• Sembolik bir programlama dili; Common Lisp veya Scheme gibi.
• Güvenlik yönetimli bir dil; Java veya MOO gibi.
• Hem program hem de verinin tamamen kalıcı olduğu bir dil; MOO veya HyperTalk gibi.

İnanıyorum ki, eğer insanlar bu dillerin her çeşidinden öğrenmek için gerçekten uğraşırlarsa, Lisp topluluğu bundan payını alacaktır. Ama dahası ben, Lisp topluluğuna gelen insanların diğer topluluklardan fikirleri de beraberlerinde getirmelerini umarım; böylece devamlı ilerleyebilmek için gereken iyi fikirlerden kaçmak yerine onlarla birleşebiliriz.

17) Kent için bir soru
MarkusQ

Alabileceğim bir Maclisp el kitabınız var mı?

KMP Maclisp'e alışık olmayanlar için, Common Lispin tasarımını büyük oranda etkileyen şey ondan önce var olan Lisp'in artık ölü olan lehçesidir.

1980lerde yazılı olarak yayınladığım The Revised Maclisp Manualı webe aktarmaya çalışıyorum. Çıkmak için henüz hazır değil ama çok da uzak olmayan bir zamanda olacak. Muhtemelen bir ya da iki ay. Daha fazla bilgi için maclisp.info sitesini takip edin.

18) Açık Gerçekleştirmeler
Martin Pomije

Gregor Kiczalesin Açık Gerçekleştirmeler fikri hakkında ne düşünüyorsunuz? Sizce onun fikri Lisp'in daha çok kişi tarafından kullanılmasına yardımcı olabilir mi?

Onu bu fikrini anlatırken burada görebilirsiniz: microsoft.com Video bu sitede sadece Windows Media Player biçiminde.

KMP: Gregor Kiczales'in Açık Gerçekleştirmeler üzerine konuşması'nı daha önce görmemiştim, bu yüzden hoşuma gitti. Gösterdiğiniz için teşekkürler!

Bu konuşma bana, uzun zaman çevresinde tartışmalar yapılmış çeşitli benzer fikirleri hatırlattı. Bunların hatırladığım kadarıyla ilki, 1970'lerin sonu veya 1980lerin başında MIT'deki Richard Zippel'in "Capsules" diye bir şey (Sınıfların çoklu gerçekleştirmeleri olmasına izin veren nesne yönetimli bir sistem) üzerindeki kısa bildirisiydi. Çoğu zaman, özellikle bir üniversite ortamında, insanlar böyle bir fikir oluşturur, üzerinde biraz tartışır ve sonra da başka bir şeye geçerler. Çok ilginç fikirler var ve bunlarla, özellikle Gregor gibi itinalı ve yetenekli biri tarafından, ciddi olarak uğraşıldığını gördüğüm için mutluyum.

Somutlaşmış bir çalışma olarak bu "görünüm yönetimli programlama" (Aspect Oriented Programming) konusu bana yeni ². Bazı eski fikirleri yeni yollarla tekrar kullanıyor ve yenilerini üretiyor. Sadece yüzeysel olarak bu terime aşina oluyorum, bu yüzden açıkçası teorik açıdan konuşamam. Ama gelecek vaat ediyor gibi. Ayrıca uygulanabilirlik bakımından söyleyebilirim ki, The Software Smith'deki danışmanlık bağlantım kanalıyla, her gün iş üzerinde alıştırma yapıyorum. Görünüm yönetimli programlamanın presniplerine uygulamak için, Lisp'i bir araç olarak kullanıyorlar ve epey görülmeye değer sonuçlar alıyorlar.

19) Common Lisp'in döngü yapısı nasıl oluştu?
Jayson

Common Lisp'in döngü yapısı ile ilgili yapabileceğiniz bir şey var mıydı ya da yapabilecek birini biliyor muydunuz? Niçin aynen C dilindeki bir for döngüsü gibi görünüp, o hissi veriyor? (Graham kitabından):

Bu benim Common Lisp hakkında çokça söylendiğim bir şey ve komitenin ortak yönetiminde neler geçtiğini çok merak ediyorum. Bu sözdizimin en azından temizlenmesi için hiç kimse karşı çıkmadı mı?

KMP: Verdiğiniz örnek epey basite indirgenmiş ve eğer bu LOOP kullanmak için tek sebep olsaydı, bunu kullanmazdık. Lisp'in böyle basit döngüler için birkaç tane yineleme operatörü var. Halbuki, LOOP kullanmak için asıl neden, çok daha karmaşık yineleme yolları ve derleme teknikleri düzenlemelerinin ifade edilebilmesidir. LOOP'un ne kadar gayriLispimtrak göründüğü konusunda hep söylenirdim ama zaman içerisinde inandım ki yararlar maliyeti bastırıyor. Şöyle bir döngünün:

yazımı ve bakımı kolaydır ve daha Lispimsi olan şu eşdeğer koda göre çok daha anlaşılırdır:

Common Lisp topluluğu, okunabilirliği geliştirdiği yerlerde, geleneksel Lisp gösterimini önerirler ama gerektiğini öğrendiğimiz durumlarda başka gösterimleri de öneriyoruz. Hangi tarzı kullanacağı seçimini, programcının kişisel beğenisine bırakıyoruz. Common Lisp, bir şeyleri yapmak için tek bir yol öneren ya da insanları ısrarla tek bir programlama modeline zorlamaya çalışan, minimalist bir dil değildir.

Sırası gelmişken, bu ANSI Common Lisp'in tasarım felsefesi ile Scheme'in tasarım felsefesi arasındaki temel bir farktır. Scheme spesifikasyonunun girişinde şöyle denir:

Programlama dilleri özellik üzerine özellik yığarak değil, ilaveleri gerekli kılan zayıflık ve kısıtlamaları kaldırarak tasarlanmalıdır. Scheme gösteriyor ki, bugün kullanılan ana programlama paradigmalarının çoğunu destekleyecek kadar esnek, kullanışlı ve verimli bir programlama dili yaratmak için, ifadeleri oluşturmakta, bunların nasıl yaratıldıklarını kısıtlamadan, gereken çok az sayıda kural yeterli oluyor.

Tersine, ANSI Common Lispi tasarlayan X3J16'nın, X3J13 tüzüğünde şöyle denmiştir:

Varolan tatbikatı kurallaştıracak, kodun muhtelif gerçekleştirmelerde taşınırlığı sağlamak için yeni özellikler ekleyecek ve kuralcı Common Lisp programlama tatbikatı oluşturacaktır. Komite Common Lisp'te tanımlanan dilden başlayacaktır: Guy L. Steele Jr.ın (Digital Press, 1984), şu an Common Lisp'in geçerli olan dili. Standardın Common Lisp'ten farklı olması yolunda bir öneri olduğunda: komite bir değişikliğin kabul edilmesinin (ya da edilmemesinin) ilerideki maliyetini ve varolan kodun dönüştürülmesinin maliyetini tartacaktır. Estetik ölçüt ikincil konu olmalıdır.

Diğer bir deyişle, Scheme topluluğu, dil spesifikasyonunun mümkün olduğu kadar estetik ve boyutça az tutmaya yüksek derecede odaklanan, çok tutucu bir topluluktur. Tersine, Common Lisp topluluğu, uyumluluk, taşınırlık ve ticari ihtiyaç gibi daha karmaşık husuları göz önünde bulunduran bir endüstriyel standarttır. Common Lisp topluluğu estetik kaygı taşırken, estetiğin tasarım ölçütü olarak uygulanabilirliğe karşı baskın çıkmasına izin vermez.

Bununla alaksı şudur; Lisp dili ailesi temel fikirleri paylaşan daha küçük topluluklardan oluşmuştur ama gerçekten çok aykırı görüşleri vardır. Bunların her biri kendi hakkında çalışılmaya değerdir. Scheme'e bakıp da, Common Lisp için iyi bir sezgiye sahip olacağınızı (ya da tersini) düşünmemelisiniz.