"Paul Graham'ın 2001 tarihli bu makalesi, iyi bir programlama dilinin özelliklerini ve popüler olma sebeplerini tartışıyor. Graham, bir dilin popüler olabilmesi için kullanıcı dostu, özlü ve yeniden tasarlanabilir olması gerektiğini vurguluyor. Ayrıca, güçlü kütüphanelere ve hızlı başlatılabilen etkileşimli bir üst düzeye sahip olmanın önemini belirtiyor. Graham, bir dilin zaman içinde gelişmesi ve kullanıcıların ihtiyaçlarını karşılaması gerektiğini, bunun da genellikle kullanıcıların geri bildirimleri ve deneyimleriyle mümkün olabileceğini ifade ediyor. Aynı zamanda, dilin sadece bir araç olduğunu, ancak kullanıcıların ihtiyaçlarına göre şekillenebileceğini belirtiyor.

---

# Hackers için İdeal Programlama Dili Nasıl Olmalı? (Being Popular)

Mayıs 2001

Bugün sizlere, programlama dillerinin popülerlik mekanizmasını ve bu popülerliğin ne kadar önemli olduğunu anlatmak istiyorum. _(Bu makale, yeni bir dil için bir tür iş planı gibi yazıldı. Bu yüzden, iyi bir programlama dilinin en önemli özelliği olan güçlü soyutlamaları varsayıyor ve bu yüzden bu konuyu işlemiyor.)_

Bir arkadaşım bir gün, tanınmış bir işletim sistemleri uzmanına gerçekten iyi bir programlama dili tasarlamak istediğini söylemişti. Uzman, bunun boşa zaman harcamak olacağını söylemişti. Çünkü programlama dillerinin popüler olup olmaması genellikle onların ne kadar iyi ya da kötü olduğuyla ilgili değildi. Yani, arkadaşımın tasarlayacağı dil ne kadar iyi olursa olsun, kimse onu kullanmayacaktı. En azından, bu durum, uzmanın kendi tasarladığı dilin başına gelmişti.

Bir dilin popüler olmasını neyin sağladığını hiç düşündünüz mü? Popüler diller acaba bu popülerliği hak ediyor mu? İyi bir programlama dilini tanımlamak gerekli mi sizce? Eğer gerekliyse, bunu nasıl yapardınız?

Bu soruların yanıtlarını hackerlara bakarak ve onların ne istediklerini öğrenerek bulabiliriz. Programlama dilleri aslında hackerlar için var ve bir programlama dili, hackerlar tarafından sevildiği sürece, örneğin denotasyonel semantik ya da derleyici tasarımı değil, bir programlama dili olarak iyi kabul edilir.

**1 Popülerliğin Mekaniği**

Kuşkusuz ki, insanların çoğu programlama dillerini sadece kendi değerleri üzerinden seçmiyorlar. Genellikle hangi dili kullanacaklarına başkaları karar veriyor. Ancak, bu tür dış faktörlerin programlama dillerinin popülerliği üzerinde düşünüldüğü kadar büyük bir etkisi olduğunu düşünmüyorum. Bence daha büyük problem, bir hacker'ın 'iyi bir programlama dili' algısının, çoğu dil tasarımcısınınkinin aksine farklı olması.

İki durum arasında, hacker'ın görüşü daha çok önemlidir. Programlama dilleri teorem değildir, insanlar için tasarlanmış araçlardır. Ayakkabıların insan ayağına uygun olması gerektiği gibi, programlama dilleri de insanların güçlü ve zayıf yönlerine uymalıdır. Bir ayakkabı giydiğinizde sıkıyorsa, ne kadar zarif bir heykel gibi görünürse görünsün, o kötü bir ayakkabıdır.

Programcıların büyük çoğunluğu iyi bir dil ile kötü bir dili birbirinden ayırt edemeyebilir. Ancak bu durum, diğer tüm araçlar için de geçerli. Bu demek değil ki, iyi bir dil tasarlamak zaman kaybıdır. Uzman hackerlar, iyi bir dil görünce bunu hemen anlarlar ve kullanırlar. Evet, kabul etmeliyiz ki uzman hackerlar bir azınlık olabilir, ancak bu küçük azınlık tüm iyi yazılımları yazar ve etkileri öyle büyüktür ki, geri kalan tüm programcılar genellikle onların kullandığı dili kullanmaya başlar. Hatta çoğu zaman, bu etki sadece öneri değil, bir emir olarak algılanır: çünkü genellikle bu uzman hackerlar, patronları veya öğretmenleri olarak diğer programcılara hangi dili kullanmaları gerektiğini söylerler.

Uzman hackerların fikirleri, programlama dillerinin görece popülerliğini belirleyen tek kuvvet değil. Miras yazılımlar (Cobol gibi) ve popüler geçici trendler (Ada, Java gibi) de bu konuda belirleyici olabiliyor. Ancak bence, uzun vadede en güçlü kuvvet, hala hackerların görüşleri oluyor. Başlangıçta belirli bir kitlenin olması ve yeterince zaman verildiğinde, bir programlama dilinin hak ettiği popülerliği yakalaması oldukça muhtemel. Dahası, popülerlik iyi dilleri kötülerden daha da öne çıkarır. Çünkü gerçek kullanıcılardan gelen dönütler daima iyileştirmelere yol açar. Şimdiye kadar popüler olan herhangi bir dilin yaşamı boyunca ne kadar değiştiğine bir bakın. Perl ve Fortran aşırı örnekler olabilir, ama hatta Lisp bile hayli değişti. Örneğin, Lisp 1.5'in makro özelliği yoktu; bu özellik, MIT'deki hackerlar birkaç yıl boyunca Lisp ile gerçek programlar yazmaya başladıktan sonra evrimleşti. [1]

Bir dilin popüler olabilmesi için iyi olup olmaması gerekip gerekmediğine bakmaksızın, benim görüşüme göre bir dilin iyi olabilmesi için popüler olması gerekiyor. Ve iyi kalabilmesi için popülerliğini koruması gerekiyor. Programlama dilleri dünyasında son trendler asla yerinde saymıyor.Bugün, Lisp dillerinin hala 1980'lerin ortalarındaki halleriyle neredeyse aynı olduğunu düşünmek oldukça ilginç, değil mi? Bunun nedeni, o dönemlerde Lisp'in son kez büyük ve talepkar bir kullanıcı kitlesine sahip olduğu zamandı. 

Bir programlama dilini öğrenmek isteyen bir hacker için, öncelikle dilin kendisini tanıması gerekiyor. Peki, bunu nasıl yapıyorlar? Diğer hackerlardan öğreniyorlar. Ancak, başkalarının bu dili duyabilmesi için, öncelikle bu dili kullanan bir grup hackerın olması gerekiyor. İlk kullanıcı grubunun ne kadar büyük olması gerektiğini hiç düşündünüz mü? Yani, kritik kitleyi oluşturmak için kaç kullanıcıya ihtiyaç var? Bence, bu sayı yirmi. Eğer bir dilin, kendi kararlarıyla, yirmi ayrı kullanıcısı varsa, onu gerçek bir dil olarak kabul ederim.

Ancak, bu noktaya gelmek hiç de kolay değil. Sıfırdan yirmiye ulaşmanın, yirmiden bine ulaşmaktan daha zor olduğunu duysam hiç şaşırmam. İlk yirmi kullanıcıyı elde etmenin en iyi yolu, muhtemelen Truva atı taktiği uygulamak: Yani insanlara, yeni dilde yazılmış olan, onların istediği bir uygulamayı vermek.

**2 Dış Faktörler**

Bir programlama dilinin popülerliğini etkileyen dış faktörlerden biri, dilin popüler bir sistemin betik dili olmasıdır. Fortran ve Cobol, eski IBM ana bilgisayarlarının betik dilleriydi. C, Unix'in betik diliydi ve daha sonra Perl de oldu. Tcl, Tk'nın betik dilidir. Java ve JavaScript, web tarayıcılarının betik dilleri olmak üzere tasarlandılar.

Lisp, geniş kitlelerce popüler bir dil olmadı çünkü büyük çapta popüler bir sistemin betik dili değildi. Bugünkü popülerliğini 1960'lar ve 1970'lerde, MIT'in betik dili olduğu zamanlara borçlu. O dönemin birçok ünlü programcısı, bir şekilde MIT ile ilişkiliydi. 1970'lerin başında, 'C' dili henüz ortaya çıkmadan önce, MIT'in Lisp lehçesi 'MacLisp', bir hacker'ın kullanmayı düşüneceği birkaç dil arasındaydı.

Bugün Lisp, Emacs ve Autocad gibi orta popülerlikteki iki sistemin betik dili olarak kullanılıyor. Bundan dolayı, bugünkü Lisp programlamasının büyük bir bölümünün Emacs Lisp ya da AutoLisp ile yapıldığını düşünüyorum.

Programlama dilleri asla yalnız başına var olmaz. Hackleme eylemi bir hedef gerektirir - hackerlar genellikle bir şeyi hedef alırlar - ve gerçekte diller, üzerinde çalıştıkları şeye göre değerlendirilir. Bu yüzden, popüler bir dil tasarlamak istiyorsanız, ya bir dilin ötesinde bir şey sunmalı ya da dilinizi, var olan bir sistemin betik dilini yerine geçecek şekilde tasarlamalısınız.

Common Lisp'in popüler olmamasının bir sebebi, bir nevi 'öksüz' olmasıdır. Başlangıçta, üzerinde geliştirmeler yapabileceğiniz bir sistemle birlikte gelirdi: Lisp Makinesi. Ancak, 1980'lerde genel amaçlı işlemcilerin artan gücü karşısında Lisp Makineleri ezildi. Eğer Unix için iyi bir betik dili olsaydı, Common Lisp belki de popülerliğini koruyabilirdi. Ne yazık ki, Unix için son derece kötü bir betik dili.

Bu durumu şöyle anlatabiliriz: Bir dil kendi değerine göre değil, başka bir özelliğine göre yargılanır. Diğer bir görüş ise, bir programlama dilinin gerçekten bir programlama dili olabilmesi için aynı zamanda bir şeyin script dilinin de olması gerektiğidir. Bu, ancak beklenmedik bir durum olduğunda haksız gibi görünebilir. Bence, bir programlama dilinden bir uygulamasının olmasını beklemek kadar adil. Bu sadece bir programlama dilinin ne olduğunu belirleyen özelliklerden biri.

Elbette, bir programlama dilinin iyi bir uygulamaya ihtiyacı vardır ve bu uygulamanın ücretsiz olması gerekir. Şirketler yazılım için para ödeyebilir, ama tek başına çalışan yazılımcılar genellikle para ödemezler ve asıl hedefinizin bu yazılımcılar olduğunu unutmamalısınız.

Bir dil hakkında yazılmış bir kitabı da olmalı. Bu kitap ince, güzel yazılmış ve bol bol iyi örneklerle dolu olmalı. Burada ideal olan K&R. Şu an hemen hemen diyebilirim ki bir dilin, O'Reilly tarafından yayınlanmış bir kitabı olması gerekiyor. Bu, yazılımcılar açısından bir dilin önemli olup olmadığının bir ölçütü haline gelmeye başladı.

Elbette, çevrimiçi belgelendirmeler de olmalı. Bu, bir dilin öğrenilmesi ve kullanılması için vazgeçilmez bir kaynaktır. Ancak, bir dilin belgelerinin sadece çevrimiçi olması yeterli değildir. İyi bir belge, çevrimiçi veya çevrimdışı olsun, bir dilin kullanımını öğrenmek için en iyi kaynaklardan biridir.Bu hikaye, bir dilin ihtiyaç duyduğu üç şeyi - ücretsiz bir uygulama, bir kitap ve hacklenecek bir şey - sağlayabildiğinizde, hacker'ların bayılacağı bir dil nasıl yaratılır sorusundan doğdu. Hacker'ların sevdiği bir şey varsa, o da kısalıktır. Matematikçiler ve modernist mimarlar gibi, hacker'lar da gereksiz her şeyden nefret ederler. Bir hacker bir program yazmaya karar verdiğinde, hangi dilde yazacağını genellikle toplam karakter sayısına dayanarak karar verir. Eğer hacker'ların düşünceleri tam olarak böyle değilse bile, bir dil tasarımcısı, hacker'ların böyle düşündüğünü varsayarak hareket etmekte fayda var.

İngilizce'ye benzeyecek şekilde uzun ve karmaşık ifadelerle kullanıcıyı yormak yanlıştır. Cobol, bu konuda kötü bir üne sahiptir. Bir hacker, böyle ifadeler yazması istendiğinde bunu hata olarak algılar.

""**x'i y'ye ekleyerek z'yi verir**"" 

yerine

""**z = x+y**""

demek, bir hacker için zekasına bir hakaret ve Tanrı'ya karşı işlenen bir günah arası bir şey olarak görülür.

Bazıları zaman zaman Lisp dilinde 'car' ve 'cdr' yerine 'first' ve 'rest' kullanmanın programları daha okunabilir kılacağını dile getirirler. Belki ilk birkaç saat içinde bu doğru olabilir. Fakat bir yazılımcı, 'car'ın bir listenin ilk öğesini temsil ettiğini ve 'cdr'nin de listenin kalan kısmını anlattığını oldukça hızlı bir şekilde öğrenebilir. 'First' ve 'rest' kullanmak, %50 daha fazla yazma çabası gerektirir. Üstelik, bu ifadelerin uzunlukları farklı olduğu için, sıkça olduğu gibi birbirini takip eden satırlarda 'car' ve 'cdr' çağrıldığında argümanlar düzgün bir şekilde hizalanmaz. Kodun sayfada nasıl hizalandığı benim için çok önemli. Değişken genişlikli bir fontta yazılmış Lisp kodunu neredeyse okuyamam ve arkadaşlarım da diğer diller için de aynı durumun geçerli olduğunu söylüyorlar.

Güçlü tip dilleri, kısaltma konusunda geri kalır. Diğer her şey eşitken, kimse bir programa bir dizi deklarasyonla başlamak istemez. Mümkün olan her şeyin belirsiz olması gerekir.

Tekil kod parçalarının da kısa olması gerektiğini unutmayın. Perl ve Common Lisp bu konuda tamamen farklı uçlarda yer alıyor. Perl programları neredeyse şifreli gibi yoğunken, Common Lisp'in dahili operatör isimleri adeta komedi. Common Lisp'in tasarımcıları, kullanıcıların bu uzun isimleri yazması gereken metin düzenleyicilere sahip olacağını düşünmüş olabilirler. Ancak uzun bir ismin maliyeti sadece yazılırken değil, okurken ve ekranınızda ne kadar yer kapladığında da ortaya çıkar.

**Hacklenebilirlik**

Bir hacker için kısalıktan daha önemli olan bir şey var: istediğini yapabilmek. Programlama dillerinin tarihine baktığımızda, programcıların 'uygun olmayan' kabul edilen şeyleri yapmasını önlemek için şaşırtıcı derecede çok çaba harcandığını görürüz. Bu, oldukça riskli ve iddialı bir yaklaşımdır. Dilin tasarımcısı, programcının ne yapması gerektiğini nasıl bilebilir ki? Bence dil tasarımcıları, hedef kullanıcılarını, kendisini korumaya muhtaç bir acemi yerine, hiç tahmin edemeyecekleri şeyleri yapmak zorunda kalacak bir dahiyi hedef almalılar. Acemi zaten kendi ayağına kurşun sıkar. Onu başka bir paketteki değişkenlere atıfta bulunmaktan kurtarabilirsiniz ama yanlış bir problemi çözmek için kötü tasarlanmış bir program yazmasını ve bunu yaparken de sonsuz bir zaman harcamasını engelleyemezsiniz.

İyi programcılar genellikle tehlikeli ve biraz tatsız işler yapmayı severler. Tatsız derken, dilin sunmaya çalıştığı semantik yüzeyin arkasına geçip daha derinlere inme eğiliminden bahsediyorum. Yani örneğin, bir üst düzey soyutlamanın iç yapısını ele geçirme gibi.Hacker'lar, hacklemeyi seviyor. Çünkü hacklemek, bir şeylerin iç yüzüne geçip orijinal tasarımcının düşüncelerini anlamaya çalışmak demek. Bu, bir nevi zihin okuma sanatıdır. 

> ""Kendinizi ikinci kez sorgulamaya açın."" 

Herhangi bir araç yaptığınızda, insanlar bunu tahmin etmediğiniz yollarla kullanır. Bu durum, özellikle programlama dili gibi detaylı bir araç için daha da geçerli. Birçok hacker, semantik modelinizi hiç düşünmediğiniz bir şekilde değiştirmek isteyecektir. Ben diyorum ki, onlara izin verin. Çöp toplayıcı gibi çalışma zamanı sistemlerini riske atmadan, programcıya mümkün olduğunca çok iç bilgiye erişim hakkı verin.

Common Lisp'te genellikle bir struct'ın alanları arasında dolaşmayı isterdim. Örneğin, silinmiş bir objeye olan referansları temizlemek veya başlatılmamış alanları bulmak için. Struct'ların aslında sadece vektörler olduğunu biliyorum. Ancak yine de herhangi bir struct üzerinde genel bir amaç için çalışabilecek bir fonksiyon yazamıyorum. Çünkü alanlara sadece isimleriyle erişebiliyorum, çünkü bir struct'ın tanımı bu şekilde.

Bir hacker, geniş çaplı bir programda belki bir ya da iki kez şeylerin öngörülen düzenini altüst etmek isteyebilir. Fakat bunu yapabilme yeteneği ne büyük bir fark yaratır, bir düşünün. Ve belki de burada sadece bir problemi çözme meselesi de yok. Ayrıca bambaşka bir tatmin duygusu da söz konusu. Hackerlar, cerrahların karmaşık iç organlarda dolaşmanın, gençlerin sivilcelerini patlatmanın gizli keyfini paylaşıyorlar. En azından erkekler için, belirli türden korkutucu durumlar büyüleyici olabiliyor. Maxim dergisi, pin-up kızlar ve dehşete düşüren kazaların karışımını içeren yıllık bir fotoğraf albümü yayınlıyor. Okuyucularını çok iyi tanıyorlar.

Tarihsel olarak, Lisp her zaman hackerların özgürce hareket etmelerine olanak sağlamıştır. Common Lisp'in 'siyasi doğruluk' prensibi, biraz garip bir durum. İlk Lisp sürümleri, her şeye rahatça müdahale etme imkanı sunardı. Neyse ki, bu özgür ruh, makrolar sayesinde hala canlılığını koruyor. Kaynak kod üzerinde istediğiniz gibi oynayabilmek, gerçekten de harika bir şey!

Klasik makrolar, bir hacker'ın gerçekten kullanacağı bir araçtır — basittir, güçlüdür ve tehlikeli olabilir. Ne yaptıklarını anlamak son derece kolaydır: makronun argümanları üzerinde bir işlem yaparsınız ve bu işlemin sonucu, makronun çağrıldığı yerde belirir. Hijyenik makrolar ise tam tersi bir ilkeyi benimser. Sizi, ne yaptıklarını anlamaktan korumaya çalışırlar. Hijyenik makroların ne olduğunu tek bir cümlede açıklayan bir açıklama duymadım. Ve bu, programcıların ne isteyip istemeyeceğine karar vermenin tehlikelerine tipik bir örnektir. Hijyenik makrolar, beni değişken yakalamadan korumayı amaçlar, ancak bazı makrolarda tam da istediğim şey 'değişken yakalama' işlemidir.

Gerçekten iyi bir dil, hem temiz hem de kirli olmalı: Temiz bir tasarımı ve iyi anlaşılan, birbirine dik olarak çalışabilen bir işlemci çekirdeği olmalı. Ancak aynı zamanda biraz 'kirli' de olmalı; yani hackerların onu istedikleri gibi kullanabilmelerine izin vermelidir. C dili tam da böyledir. İlk Lisp dilleri de öyledir. Gerçek bir hacker'ın dili her zaman biraz asi bir karaktere sahip olacaktır.

İyi bir programlama dili, ""yazılım mühendisliği"" tabirini kullananların bile başını sallamasına neden olacak özelliklere sahip olmalı. Spektrumun diğer ucunda ise Ada ve Pascal gibi diller bulunuyor. Bu diller, öğretme amaçlı oldukça uygun olmalarına rağmen, başka bir işe yaramıyorlar.

**5 Atılabilir Program**

Bir dilin yazılımcılar için çekici olabilmesi için, onların ilgi duydukları türde programları yazmak için uygun olması gerekir. Bu, belki de şaşırtıcı bir şekilde, tek kullanımlık, çabuk yazılıp atılacak programları yazmak için de iyi olması gerektiği anlamına geliyor.

Bir atıl program, sınırlı bir görev için hızlıca yazdığınız bir programdır: sistem yönetim görevini otomatikleştirmek, bir simülasyon için test verisi oluşturmak veya verileri bir formattan diğerine dönüştürmek gibi. Şaşırtıcı olan şu ki, bu atıl programlar, II. Dünya Savaşı'nda kullanılan Colossus gibi devasa makinelerin modern versiyonlarıdır. Bu programlar, birçok insanın hayatını kolaylaştırırken, aynı zamanda hacker'ların yeteneklerini geliştirmelerine de yardımcı oluyor. Bu yüzden, bir atıl program yazarken, sadece bir görevi yerine getirmekle kalmaz, aynı zamanda bir hacker'ın yeteneklerini de geliştirirsiniz.Dünya Savaşı'nda inşa edilen ""geçici"" binalar gibi, bazen en başta küçük görünen projeler, zamanla büyüyüp gelişebilir. Bu, yazılım dünyasında da geçerli bir durum. Bazı programlar, sadece geçici bir çözüm olarak başlar, ancak zamanla gerçek bir program haline dönüşebilir. İşte bu yüzden, bazen küçük bir projeye başlamak, aslında büyük bir başlangıç yapmaktır.

Büyük bir projeye başlamak, sanki sıfırdan bir şey inşa etmek gibi bir şeydir. İnsanlar genellikle bu durumda bunalmış hissederler. Proje ya aksamaya başlar ya da sonuç, beklenenin aksine, steril ve ifadesiz olur. Bu nedenle, bazen büyük bir program yapmanın en iyi yolu, önce basit bir program yazmak ve onu sürekli geliştirmektir. Bu yaklaşım, daha az korkutucu olabilir ve programın tasarımı, evrimsel bir süreçle şekillenebilir.

Biraz araştırma yaptığınızda, büyük programların genellikle bu şekilde geliştiğini görürsünüz. Ve bu şekilde evrimleşen programlar, genellikle ilk yazıldıkları dilde kalırlar. Çünkü bir programın başka bir dile çevrilmesi, politik sebepler dışında pek nadiren gerçekleşir. Bu durumda bir paradoks ortaya çıkıyor: Eğer büyük sistemler için bir dil oluşturmak istiyorsanız, bu dili ilk etapta basit programları yazmak için de uygun hale getirmeniz gerekiyor. Çünkü genellikle büyük sistemler, bu basit programların üzerine eklemeler yaparak oluşur.

Perl, bu fikrin belirgin bir örneğidir. Sadece geçici programlar yazmak için değil, aynı zamanda kendisi de bir geçici program olarak tasarlandı. Perl, raporlar oluşturmak için kullanılan bir dizi araç olarak hayata başladı ve insanların Perl'de yazdığı geçici programlar büyüdükçe bir programlama diline dönüştü. Ancak, Perl 5 sürümüne gelene kadar (belki de daha da sonrasına kadar) dil, ciddi programlar yazmak için uygun hale gelmedi. Ancak bu zamana kadar Perl, zaten çok popüler hale gelmişti.

Peki, bir dili tek seferlik programlar için uygun kılan şey nedir? İlk olarak, dilin kolayca ulaşılabilir olması gerekiyor. Tek seferlik bir program genellikle bir saat içinde yazmayı hedeflediğiniz bir şeydir. Dolayısıyla bu dilin, kullandığınız bilgisayarda zaten kurulu olması gerekiyor. Kullanmadan önce yüklemeniz gereken bir dil olmamalı. Orada, hemen elinizin altında olmalı. C dili oradaydı çünkü işletim sistemiyle geliyordu. Perl de oradaydı çünkü başlangıçta sistem yöneticileri için bir araçtı ve sistem yöneticiniz zaten onu yüklemişti.

Sadece kurulu olmak, kullanışlı olmak için yeterli değildir. Komut satırı arayüzüne sahip etkileşimli bir dil, ayrı ayrı derlenip çalıştırılması gereken bir dilden daha kullanışlıdır. Popüler bir programlama dili, etkileşimli olmalı ve hızlı başlamalıdır.

Bir deneme programında isteyeceğiniz bir diğer özellik de kısa olması. Kısa ve öz olmak, hackerlar için her zaman cazip bir özelliktir, özellikle bir saat içinde tamamlamayı bekledikleri bir programda daha da önem kazanır.

**6 Kütüphaneler**

Tabii ki, en kısa yol, programın zaten sizin için yazılmış olması ve onu çalıştırmanızdır. Bu da bizi programlama dillerinin giderek daha önemli bir özelliğine, kütüphane fonksiyonlarına getiriyor. Perl, büyük bir string manipülasyonu kütüphanesine sahip olduğu için bir adım önde. Bu tür kütüphane fonksiyonları, genellikle veri dönüştürme veya çıkarma işlemleri için yazılan tek seferlik programlar için özellikle önemlidir. Birçok Perl programı muhtemelen sadece birkaç kütüphane çağrısının birleştirilmesiyle ortaya çıkar.

Bence önümüzdeki 50 yılda programlama dillerindeki ilerlemelerin çoğu kütüphane fonksiyonlarıyla alakalı olacak. Geleceğin programlama dilleri, ana dil kadar özenle tasarlanmış kütüphanelere sahip olacak. Programlama dili tasarımı sadece dilinizi güçlü veya zayıf şekilde mi, nesneye yönelik mi, fonksiyonel mi olacağına karar vermekle ilgili olmayacak, aynı zamanda harika kütüphaneler nasıl tasarlanır sorusu üzerine yoğunlaşacak. Tip sistemlerini nasıl tasarlamak gerektiği hakkında düşünmeye bayılan dil tasarımcıları bu düşünceden pek hoşlanmayabilir. Bu, neredeyse bir uygulama yazmak gibi!Ancak üzgünüm, diller programcılar için vardır ve programcıların ihtiyaç duyduğu şey kütüphanelerdir.

İyi kütüphaneler tasarlamak kolay bir iş değil. Sadece çok kod yazmakla iş bitmiyor. Kütüphaneler çok büyüdükçe, bazen ihtiyaç duyduğunuz fonksiyonu bulmaktan ziyade, kodu kendi başınıza yazmak daha hızlı olabilir. Kütüphaneler, tıpkı bir dilin temel yapısı gibi, birbirine dik duran bir dizi operatör kullanılarak tasarlanmalı. Programcının, hangi kütüphane çağrısının ne işe yaradığını tahmin edebilmesi gerekir.

Kütüphaneler, Common Lisp'in açıkçası pek de başarılı olamadığı bir alan. Metinlerle ilgilenmek için sadece temel seviyede kütüphaneler var ve işletim sistemine doğrudan erişim hemen hemen hiç yok. Tarihsel nedenlerden dolayı, Common Lisp sanki işletim sistemi diye bir şey yokmuş gibi davranıyor. Ve işletim sistemine erişemiyorsanız, yalnızca Common Lisp'in dahili işlevlerini kullanarak ciddi bir program yazma şansınız düşük. Üstelik çoğu zaman özgül bazı hileleri de kullanmanız gerekiyor ve genellikle bu hileler tam da istediklerinizi elde etmek için yeterli olmuyor. Eğer Common Lisp'in kapsamlı metin kütüphaneleri ve sağlam bir işletim sistemi desteği olsaydı, hackerlar Lisp'e çok daha fazla değer verirlerdi.

**7 Sözdizimi**

Lisp'in sözdizimine, ya da daha doğru bir ifadeyle, sözdizimsizliğine sahip bir dilin popüler olma ihtimali var mı? Bunu ben de bilmiyorum. Ancak Lisp'in şu anda popüler olmamasının ana nedeninin sözdizimi olmadığını düşünüyorum. Common Lisp'in, alışılmadık sözdiziminden daha büyük sorunları var. Kendi çevremde bile, önek sözdizimine aşina olmasına rağmen Perl'i tercih eden birkaç yazılımcı tanıyorum. Çünkü Perl, güçlü bir dizi kütüphanesine sahip ve işletim sistemiyle kolaylıkla iletişim kurabiliyor.

Önek gösterimiyle ilgili iki olası sorun var: programcılara yabancı gelmesi ve yoğunluğunun yetersiz olması. Lisp dünyasında genel kanı, asıl sorunun programcılara yabancı gelmesi olduğu yönünde. Ancak ben bu konuda tam olarak emin değilim. Evet, önek gösterim, sıradan programcıları telaşa sürükleyebilir. Ancak bence sıradan programcıların görüşlerinin çok da önemi yok. Bir dilin popüler ya da popüler olmayan olması, uzman hackerların o dile ne düşündüğüne bağlıdır ve ben uzman hackerların önek gösterimiyle baş edebileceğini düşünüyorum. Perl dilinin sözdizimi oldukça anlaşılmaz olabilir, ancak bu, Perl'in popülerliğine engel olmadı. Hatta bu durum, Perl'e özgü bir 'kült' oluşmasını teşvik etmiş olabilir.

Daha ciddi bir sorun ise önek gösteriminin ne kadar dağınık olması. Bu, uzman hackerlar için gerçekten büyük bir problem. İnsanlar a[x,y] yazabilecekken neden (aref a x y) yazmayı tercih etsin ki?

Bu özel durumda, problemi aşmanın bir yolu var. Veri yapılarını, indekslere işlevmiş gibi davranırsak, bunu (a x y) şeklinde yazabiliriz, ki bu da Perl formatından daha kısa. Benzer hileler, başka türden ifadeleri de kısaltabilir.

Girintiyi önemli bir unsur olarak kabul ederek, birçok parantezi atabilir veya onları isteğe bağlı hale getirebiliriz. Zaten programcılar kodları bu şekilde okurlar: girinti ve ayrımcılar farklı şeyler söylediğinde, genellikle girintinin dediğini takip ederiz. Girintiyi önemli bir faktör olarak kabul etmek, bu tür hataların önüne geçerken aynı zamanda kodları da daha kısa ve öz hale getirir.

Bazen infix sözdizimi okuması daha kolay oluyor. Bu durum, özellikle matematiksel ifadeler için geçerli. Ben tüm programlama hayatım boyunca Lisp kullandım ve hala prefix matematik ifadelerini doğal bulmuyorum. Ancak, kod oluştururken, herhangi bir sayıda argüman alabilen operatörlere sahip olmak oldukça işlevsel oluyor. Yani eğer infix sözdizimine geçersek, bunu belki de bir tür okuma makrosu olarak uygulamamız gerekecek.

Lisp diline sözdizimi eklemeye kesinlikle karşı olmamamız gerektiğini düşünüyorum, tabii ki bunu yaparken de altta yatan s-expressions’a doğru ve anlaşılır bir şekilde çevirebildiğimiz sürece. Lisp dilinde zaten belirli bir miktarda sözdizimi bulunuyor.Sözdizimi... Dilin kalbi, beyni, ruhu... Evet, bazen karmaşık olabilir, ama aslında bu karmaşıklık, dilin esnekliğini ve gücünü de yansıtır. Common Lisp dilinde de durum böyle. Bazı ayraçlar dil için ayrılmış durumda ve bu, dilin tasarımcılarının gelecekte daha fazla sözdizimi eklemeyi planladığını gösteriyor. 

Common Lisp dilindeki en ilginç sözdizimi parçalarından biri, format dizelerinde kendini gösterir. Format, kendi başına bir dil gibidir ve bu dil, Lisp ile pek de örtüşmez. Eğer Lisp'e daha fazla sözdizimi katmayı düşünüyorsanız, format belirleyicileri bu plana dahil edebilirsiniz. Makroların, diğer kod türleri gibi format belirleyicileri de üretebilmesi güzel bir gelişme olurdu.

Bir Lisp hackerı bana, CLTL kitabının 'format' bölümünü açtığını söyledi. Benimki de aynı şekilde açılıyor. Bu, belki de o bölümde iyileştirme yapılması gerektiğini gösteriyor olabilir. Aynı zamanda, programların çok fazla giriş/çıkış işlemi yaptığını da ifade ediyor olabilir.

**8 Verimlilik**

Herkesin bildiği gibi, iyi bir dil hızlı kod üretmelidir. Ama pratikte, hızlı kodun çoğunlukla dilin tasarımında yaptığınız şeylerden kaynaklanmadığını düşünüyorum. Knuth'un uzun zaman önce belirttiği gibi, hız sadece belirli kritik darboğazlarda önemli hale gelir. Ve birçok programcının da belirttiği gibi, bu darboğazların nerede olduğunu tahmin etmek çoğu zaman yanıltıcı olabiliyor.

Pratikte hızlı kod elde etmenin yolu, dilin tip güvenliğini sağlamaktan ziyade, çok iyi bir profil oluşturucuya sahip olmaktır. Programdaki her çağrının türünü bilmeye ihtiyacınız yok. Ancak darboğaz oluşturan yerlerdeki argümanların türlerini belirleyebilmeniz lazım. Hatta daha da önemlisi, bu darboğazların nerede olduğunu bulabilmek gerekiyor.

Lisp hakkında insanların genellikle dile getirdiği bir sorun, neyin pahalıya mal olacağını kestirmenin zor olması. Bu kısmen doğru olabilir. Eğer çok soyut bir dil istiyorsanız, bu kaçınılmaz bile olabilir. Ancak her durumda, iyi bir profil oluşturmak, bu sorunu büyük oranda çözecektir: neyin maliyetli olduğunu hızla öğrenirsiniz.

Sorunun bir kısmı sosyal. Dil tasarımcıları hızlı derleyiciler yazmayı sever. Bu, onların yeteneklerini ölçtükleri yer. En iyi ihtimalle, profil oluşturucuyu bir eklenti olarak görürler. Ancak pratikte, iyi bir profil oluşturucu, dilde yazılan gerçek programların hızını, hızlı kod üreten bir derleyiciden daha çok artırabilir. Yine burada, dil tasarımcıları kullanıcılarıyla biraz uyumsuzluk yaşıyor. Neredeyse doğru sorunu çözmekte çok iyiler ama aslında biraz yanlış sorunu çözüyorlar.

Bir programın performans verilerini programcının talep etmesini beklemek yerine, bir ""aktif profil oluşturucu"" kullanmak iyi bir fikir olabilir. Örneğin, programcı kaynak kodu düzenlerken, editör performans darboğazlarını kırmızıyla işaretleyebilir. Başka bir yöntem, çalışan programlardaki işlemleri bir şekilde görselleştirmek olabilir. Bu özellikle çok sayıda programın çalıştığı sunucu tabanlı uygulamalarda büyük bir kazanım sağlar. Aktif bir profil oluşturucu, bir program çalışırken bellekte ne olduğunu görsel olarak gösterebilir hatta ne olduğunu anlatan sesler bile çıkarabilir.

Ses, problemlere dair iyi bir ipucudur. Bir zamanlar çalıştığım bir yerde, web sunucularımızın durumunu gösteren büyük bir gösterge panelimiz vardı. İşaretçiler, döndüklerinde hafif bir ses çıkaran minik servomotorlar tarafından hareket ettirilirdi. Paneli masamdan göremezdim, ama bir sunucuda bir problem olduğunda, hemen sesinden anlardım.

Etkisiz algoritmaları otomatik olarak tespit eden bir profil oluşturmanın mümkün olabileceğini düşünüyorum. Belirli hafıza erişim kalıplarının, kötü algoritmaların açık işaretleri olduğu ortaya çıksa hiç şaşırmam. Bilgisayarımızın içinde, programlarımızı uygulayan küçük bir adam olsa, işindeki zorlukları anlatan bir hikayesi, belki de bir devlet memurununki kadar uzun ve sitemkâr olabilir.Bazen kendimi, işlemciyi gereksiz yere koşturup dururken buluyorum. Ama ne yaptığını anlamak için bir yol bulamadım. Bu durumda, **Lisp**'in byte koduna dönüştürülmesi ve bir yorumlayıcı tarafından çalıştırılması gibi bazı dil özelliklerini düşünüyorum. Bu, uygulamanın farklı platformlara kolayca taşınabilmesi için yapılan bir optimizasyon. Ama belki de byte kodunu dilin resmi bir parçası yapmak, hatta programcılara karmaşık bölümlerin hızlandırılması için satır içi byte kodu kullanma imkanı vermek iyi bir fikir olabilir. Böylece, bu tür optimizasyonlar da taşınabilir hale gelir.

Son kullanıcıların hız algısının değişmekte olduğunu düşünüyorum. Sunucu tabanlı uygulamaların yükselişiyle birlikte, birçok programın giriş/çıkış işlemlerine bağlı olduğunu görüyoruz. Giriş/çıkış işlemlerini hızlandırmak önemli hale geliyor. Programlama dilinin, basit ve hızlı formatlı çıktı işlevleri gibi net önlemlerle ve daha derin yapısal değişikliklerle, örneğin önbellek ve kalıcı objeler ile bu konuda yardımcı olması gerekiyor.

Kullanıcılar genellikle yanıt süreleriyle ilgilenirler. Ancak, bir diğer önemli verimlilik türü de işlemci başına kaç kullanıcıyı aynı anda destekleyebileceğinizdir. Yakın gelecekte yazılacak olan birçok ilginç uygulama, sunucu tabanlı olacak. Yani, sunucu başına kaç kullanıcı düştüğü, bu tür uygulamaları barındıran herkes için kilit bir sorun olacak. Bir sunucu tabanlı uygulama sağlayan bir işletmenin sermaye maliyetini hesaplarken, bu sayı bölümde yer alır.

Yıllarca, son kullanıcı uygulamalarında verimlilik pek ön planda değildi. Yazılım geliştiriciler, her kullanıcının masasında sürekli güçlenen bir bilgisayar olacağını düşünmüştü. Ve Parkinson Yasası gereği, yazılımlar kullanabileceği kaynakları en iyi şekilde kullanmak için genişledi. Ancak sunucu tabanlı uygulamalarla bu durum değişecek. Bu yeni dünyada, donanım ve yazılım birlikte sağlanacak. Sunucu tabanlı uygulamalar sunan şirketler için, tek bir sunucuda ne kadar çok kullanıcıyı destekleyebildikleri, kar marjları üzerinde büyük bir etkiye sahip olacak.

Bazı durumlarda, işlemci belirleyici olabilir ve bu durumda en çok üzerinde durmanız gereken şey işlem hızını optimize etmektir. Ancak çoğu zaman bellek sınırlayıcıdır; aynı anda kaç kullanıcının sistemi kullanabileceği, her kullanıcının verisi için ne kadar bellek gerektiğine bağlıdır. Programlama dilinizin özellikleri burada da size yardımcı olabilir. İyi bir paralellik (thread) desteği, tüm kullanıcıların aynı bellek alanını paylaşmasını sağlar. Ayrıca, kalıcı nesnelere sahip olmak ve/veya dil düzeyinde tembel yükleme desteği de oldukça işinize yarayabilir.

**9 Zaman**

Popüler bir dilin son gereksinimi zamandır. Hiç kimse, birçok programlama dili gibi bir gün yok olabilecek bir dilde program yazmak istemez. Bu yüzden, çoğu hacker, bir dili kullanmayı düşünmeden önce birkaç yıl boyunca var olduğunu görür.

Yeni ve harika şeylerin mucitleri genellikle bu duruma şaşırır, ama bir mesajı insanlara geçirmek için zamana ihtiyacınız vardır. Bir arkadaşım, birisi ondan bir şeyler istediğinde genellikle hemen harekete geçmez. İnsanların bazen aslında gerçekten istemedikleri şeyleri talep ettiklerini bilir. Zamanını boşa harcamamak için, genellikle bir şeyleri yapması için üçüncü veya dördüncü kez talep gelene kadar bekler. O zamana kadar, talepte bulunan kişi belki biraz sinirli olmuştur, ama en azından istedikleri şeyi gerçekten istediklerinden emindir.

Çoğu insan, duydukları yeni bilgilere benzer bir filtreleme yapmayı öğrenmiştir. Bir şeyi on kez duyuncaya kadar genellikle dikkate almazlar. Bu durum tamamen normal çünkü genellikle 'son moda' olan şeyler zaman kaybından başka bir şey değil ve sonunda yok oluyorlar. VRML öğrenmeyi erteleyerek, sonunda hiç öğrenmemiş oldum.

Yani yeni bir şey icat eden herkesin, insanların onu tamamen kavrayabilmesi için mesajını yıllarca tekrar etmek zorunda olduğunu anlaması lazım.Bir hikaye anlatmak, bazen biraz sabır ve ısrar gerektirebilir. İlk web sunucusu tabanlı uygulamayı geliştirdiğimizde, insanlara bu uygulamanın indirilmesine gerek olmadığını anlatmak için yıllar harcadık. Bu, onların aptal olduğu anlamına gelmezdi. Sadece, bizim ne demek istediğimizi tam olarak anlamıyorlardı.

Ama merak etmeyin, hikayenizi tekrar tekrar anlatmak, sonunda insanların dikkatini çekmenin en iyi yoludur. Tek yapmanız gereken, hikayenizi anlatmaya devam etmek ve sonunda insanların size odaklandığını görmek. Asıl önemli olan, insanların sizi ilk fark ettikleri an değil; hala orada olduğunuzu fark ettikleri andır.

Aslında, momentum kazanmanın genellikle biraz zaman alması iyi bir şeydir. Çoğu teknoloji, ilk başlatıldıktan sonra bile belirgin bir şekilde evrimleşir - özellikle programlama dilleri. Birkaç yıl boyunca sadece az sayıda 'erken kullanıcı' tarafından benimsenen bir teknoloji için daha iyi bir şey olamaz. Bu erken kullanıcılar oldukça sofistike ve talepkar olurlar, bu da teknolojinizdeki kalan hataların hızla ortaya çıkmasını sağlar. Sadece birkaç kullanıcınız varsa, tümüyle yakından iletişim kurabilirsiniz. Ve sistemlerinizi geliştirdiğinizde, bu bazı aksaklıklara neden olsa bile, erken kullanıcılar anlayışlı olur ve affederler.

Yeni teknoloji genellikle iki yolla hayatımıza girer: organik büyüme yolu ya da büyük patlama yolu. Organik büyüme yolu, klasik, yetersiz finanse edilmiş ve garajda kurulan startuplar tarafından temsil edilir. Birkaç kişi, gözlerden uzakta, yeni bir teknoloji geliştirirler. Bu teknolojiyi hiçbir pazarlama stratejisi olmadan piyasaya sürerler ve başlangıçta sadece birkaç (ama son derece sadık) kullanıcıları olur. Teknolojiyi geliştirmeye devam ederler ve bu arada kullanıcı tabanları da söylentilerle büyür. Bir bakmışlar ki, kendileri de büyümüşler.

Diğer bir yaklaşım ise, 'büyük patlama' metodudur. Bu genellikle risk sermayesi desteğiyle çalışan ve yoğun bir pazarlama bombardımanına girişen startuplar tarafından benimsenir. Hızla bir ürün yaratırlar, büyük bir medya çılgınlığıyla piyasaya sürerler ve (temenni ettikleri gibi) hemen büyük bir kullanıcı tabanına sahip olurlar.

Genellikle, garaj tipi startuplar, büyük bütçeli girişimlerin sahiplerine özenir. Bu büyük bütçeli girişimciler genellikle kendilerine güvenen, etkileyici ve yatırımcılar tarafından saygı gören kişilerdir. Onların her zaman en iyisi olabilir ve ürünlerini piyasaya sürerken yürüttükleri PR kampanyası onları adeta birer ünlü yapar. Öte yandan, garajlarında oturup çalışan girişimciler genellikle kendilerini yoksul ve sevilmemiş hissederler. Ama bence, genellikle bu duygularına kapılmaları bir yanılgıdır. Çünkü organik büyüme, genellikle büyük patlama yönteminden daha iyi teknoloji ve daha zengin girişimcileri ortaya çıkarıyor. Bugünün öne çıkan teknolojilerine baktığınızda, çoğunun organik bir şekilde büyüdüğünü görebilirsiniz.

Bu durum sadece şirketlerle sınırlı değil. Sponsorlu araştırmalarda da aynı durumu gözlemleyebiliriz. Multics ve Common Lisp büyük patlama projeleriydi, buna karşılık Unix ve MacLisp ise organik büyüme sergileyen projelerdi.

**10 Yeniden Tasarım**

E.B. White'ın dediği gibi, en iyi yazılar aslında yeniden yazılanlardır. Her iyi yazar bunu bilir ve bu kural, yazılım dünyası için de geçerlidir. Tasarımın en kritik kısmı, aslında yeniden tasarımdır. Özellikle programlama dilleri, daha sık yeniden tasarlanmalıdır.

İyi bir yazılım yazmak için aynı anda kafanızda iki karşıt fikri barındırabilmeniz gerekiyor. Genç bir hacker'ın yeteneklerine olan saf ve sınırsız güveni ile tecrübeli bir yazılımcının sağlam şüpheciliğini bir arada taşımalısınız. ""Bu ne kadar zor olabilir ki?"" diye düşünürken, diğer yandan ""Bu asla işe yaramaz"" fikrini de aklınızın bir köşesinde bulundurmalısınız.

Püf noktası, aslında burada gerçek bir çelişkinin olmadığını anlamaktır. İki farklı şey hakkında aynı anda hem iyimser hem de kuşkucu olmak istiyorsunuz. Sorunu çözme olasılığına karşı iyimser, fakat elde ettiğiniz çözümün değerine karşı kuşkucu olmalısınız.

İyi işler çıkaran insanlar genellikle üzerinde çalıştıkları şeyin iyi olmadığını düşünürler. Bu, onları daha iyi yapmak için sürekli olarak kendilerini sorgulamalarını ve geliştirmelerini sağlar. Bu yüzden, her zaman biraz daha iyi olmak için çaba sarf etmek önemlidir.Bir projeye başlarken, genellikle iki güç arasında denge kurmamız gerekir: umut ve endişe. İyi bir iş çıkarmak için bu iki duyguyu dengelemek önemlidir. İlk aşamada, bir sorunu çözebileceğimize dair içten bir umutla çalışırız. Ancak ikinci aşamada, yaptıklarımızı daha eleştirel bir gözle değerlendirir ve hataları görürüz. Bu noktada, eleştiriler umudumuzu aşmadığı sürece, sisteminiz henüz tamamlanmamış olabilir. Ama bu, ""kalan kısmını tamamlamak ne kadar zor olabilir ki?"" diyerek döngüyü sürdürmeyi bırakmamız anlamına gelmez.

Bu iki gücü dengelemek kolay değildir. Genç yazılımcılar genellikle iyimserdir. Bir şeyler üretirler, harika olduğunu düşünürler ve daha fazla düşünmeye gerek duymazlar. Deneyimli yazılımcılar ise genellikle kuşkuludur ve bu yüzden büyük hedefleri olan projelere cesaret edemezler.

Her ne yaparsanız yapın, yeniden tasarım sürecini devam ettirmek önemlidir. Bir metni, memnun olana kadar tekrar tekrar düzenleyebilirsiniz. Ancak genellikle yazılımlar yeterince yeniden tasarlanmaz. Yazılı metinlerin okuyucuları vardır, fakat yazılımların _kullanıcıları_ vardır. Eğer bir yazar bir makaleyi yeniden yazarsa, eski versiyonu okuyan kişilerin, yeni eklenen bir uyumsuzluk nedeniyle düşüncelerinin karıştığını söylemeleri pek mümkün olmaz.

Kullanıcılar çift uçlu bir kılıç gibidir. Hem dilinizi geliştirmenize yardımcı olabilirler, hem de sizi engelleyebilirler. Bu yüzden kullanıcılarınızı özenle seçin ve sayılarını artırmakta acele etmeyin. Kullanıcı sahibi olmak, optimizasyon gibidir: akıllıca olanı onu ertelemektir. Ayrıca genel bir kural olarak, her zaman düşündüğünüzden daha fazla değişiklik yapabilirsiniz. Değişikliği uygulamak, bir yara bandını çekmek gibidir: acıyı hissettikten hemen sonra unutursunuz.

Herkes bir dilin bir komite tarafından tasarlanmasının pek de iyi bir fikir olmadığını bilir. Çünkü komiteler genellikle kötü tasarımlar ortaya çıkarır. Ama bence komitelerin en kötü tarafı, yeniden tasarım süreçlerine müdahale etmeleridir. Değişiklikleri hayata geçirmek o kadar zahmetli olur ki, kimse uğraşmak istemez. Bir komite ne karar vermişse, genellikle o şekilde kalır, hatta komitenin çoğu üyesi o karardan memnun olmasa bile.

Yeniden tasarım konusunda bile iki kişilik bir komite engel olabiliyor. Bu, özellikle iki farklı insan tarafından yazılan yazılımların arayüzleriyle alakalı. Arayüzü değiştirmek için ikisinin de aynı anda onay vermesi gerekiyor. Bu yüzden, arayüzler genellikle hiç değişmiyor. Bu büyük bir sorun çünkü arayüzler genellikle bir sistemin en plansız parçaları oluyor.

Burada belki de bir çözüm, sistemlerin tasarımını dikey değil, yatay arayüzlerle oluşturmak olabilir - yani modüller, her zaman soyutlama tabakaları olarak dikey olarak üst üste yerleştirilir. Bu durumda, arayüz genellikle bunlardan birine ait olacaktır. İki seviye arasındaki alt seviye, ya üst seviyenin yazıldığı bir dil olacaktır, bu durumda arayüz alt seviyeye ait olur, ya da alt seviye, üst seviyenin hizmetkarı olur, bu durumda da arayüz, üst seviye tarafından belirlenebilir.

**11 Lisp**

Tüm bunlar, yeni bir Lisp için hala umut olduğunu gösteriyor. Hackerlara istediklerini veren her dil için, Lisp dahil, hala bir umut var. Sanırım hackerların Lisp'in tuhaflığından hoşlanmadığını düşünmekle hata yaptık. Bu yanıltıcı düşünce, belki de Lisp'in, özellikle Common Lisp'in gerçek sorununu görmemizi engelledi: Hackerların yapmak istediklerini yapmak için Common Lisp pek yararlı değil. Bir hacker dili, güçlü kütüphanelere ve hacklenebilecek bir şeye ihtiyaç duyar. Ancak Common Lisp'in ikisi de yok. Bir hacker dili kısa ve hacklenebilir olmalı. Ancak maalesef, Common Lisp bu özelliklere sahip değil.

İyi haber şu ki, kötü olan Lisp değil, Common Lisp.Eğer gerçek bir hacker dili olan yeni bir Lisp geliştirebilirsek, hackerlar bunu kullanacaklardır. Hangi dil iş görüyorsa onu kullanıyorlar. Bizim yapmamız gereken, bu yeni Lisp'in diğer dillerden daha iyi bir iş çıkarmasını sağlamak.

Tarih bize umut verici bir tablo çiziyor. Zamanla, yeni programlama dilleri, Lisp dilinden daha fazla özellik çalmaya başladı. Artık kopyalayacak pek bir özellik kalmadı. Yani artık yarattığınız dil, neredeyse Lisp olmak üzeredir. En son çıkan ve popüler olan dil Python, aslında basit haliyle bir Lisp dili. İçerisinde infix sözdizimi ve makro yok. Bu süreçte yeni bir Lisp dilinin çıkması, doğal bir ilerleme olacaktır.

Bazen bunu 'gelişmiş Python versiyonu' olarak adlandırsak daha çekici olur diye düşünüyorum. Bu, Lisp'ten daha havalı bir isim olabilir. Birçok insan için Lisp, bol parantezli ve yavaş bir yapay zeka dili olarak görülüyor. Fritz Kunze'nin resmi biyografisi bile Lisp kelimesine değinmekten özellikle kaçınıyor. Ancak benim tahminim, yeni Lisp'in adını korkusuzca Lisp koyabileceğimiz yönünde. En iyi hackerlar arasında -örneğin 6.001 dersini anlamış olanlar gibi- Lisp'e hala büyük bir saygı var. İşte bu kullanıcıları kazanmanız gerekiyor.

""Hacker Nasıl Olunur"" adlı yazısında Eric Raymond, Lisp'i Latin veya Yunanca gibi tanımlıyor - aslında kullanmayacağınız fakat zihninizi zinde tutmak için öğrenmeniz gereken bir dil:

> Lisp'i öğrenmek, nihayet anladığınızda yaşayacağınız o aydınlatıcı deneyim için değerlidir. Bu deneyim, Lisp'i sık sık kullanmasanız bile, sizi hayatınızın kalanında daha iyi bir programcı yapacaktır.

Eğer Lisp'i bilmiyor olsaydım, bu yazıyı okuduktan sonra kafamda bir sürü soru belirirdi. Beni daha iyi bir programcı yapacak bir dil derken, aslında daha iyi bir programlama dili olduğunu kastediyordur. Ve bu da aslında Eric'in söylediklerinin tam da çıkarımı.

Bu fikir hala gündemde olduğu sürece, yeni bir Lisp'e, adı ne olursa olsun, hackerlar sıcak bakacaklarını düşünüyorum. Ama bu Lisp, 1970'lerin klasik Lisp'leri gibi, bir hacker dilinde olmalı. Kısa, basit ve üzerinde oynanabilir olmalı. Ve hackerların bugün yapmak istedikleri işler için güçlü kütüphanelere sahip olmalı.

Kütüphanelerle ilgili olarak, Perl ve Python gibi dilleri kendi oyununda yenmenin mümkün olduğunu düşünüyorum. Önümüzdeki yıllarda yazılacak birçok yeni uygulama sunucu tabanlı olacak. Yeni bir Lisp dilinin, Perl kadar iyi string kütüphanelerine sahip olmaması için hiçbir sebep yok. Eğer bu yeni Lisp, aynı zamanda sunucu tabanlı uygulamalar için güçlü kütüphanelere sahip olursa, oldukça popüler hale gelebilir. Gerçek hackerlar, birkaç kütüphane çağrısıyla zor problemleri çözme yetenekleri olan yeni bir araca burun kıvırmazlar. Unutmayın, hackerlar tembeldirler.

Sunucu tabanlı uygulamalar için çekirdek dil desteği daha büyük bir kazanım olabilir. Örneğin, birden çok kullanıcılı programlara özel destek veya veri sahipliğinin tip etiketleri seviyesinde açıkça belirtildiği bir dil düşünün.

Sunucu tabanlı uygulamalar, yeni Lisp'in ne için kullanılacağı sorusuna da yanıt veriyor. Lisp'i Unix için bir betik dili olarak geliştirmekten zarar gelmez. (Daha kötü hale getirmek neredeyse imkansız.) Ama bence, mevcut dilleri alt etmek daha kolay olabilecek alanlar var. Tcl'nin modelini takip edip, sunucu tabanlı uygulamaları destekleyen tam donanımlı bir sistemle birlikte Lisp sağlamak daha iyi bir fikir gibi gözüküyor. Lisp, sunucu tabanlı uygulamalar için doğal bir seçim. Lexical closures, kullanıcı arayüzü sadece bir dizi web sayfası olduğunda alt programların işlevini sağlıyor. S-ifadeleri HTML ile güzel bir uyum sağlar ve makrolar HTML oluşturmakta oldukça işe yarar. Sunucu tabanlı uygulamalar yazmak için daha iyi araçlara ve yeni bir Lisp'e ihtiyaç var ve ikisi bir arada çok iyi çalışır.

**12 Rüya'cı Dili (Dream Language)**

Özetlemek gerekirse, bir hacker'ın hayalindeki dil nasıl olurdu bir bakalım. Bu dil, göze hoş gelen, tertemiz ve kısa bir dildir. Hızlıca başlayabilen interaktif bir üst düzeyi vardır.Programlama dünyasında, ortak problemleri çözen programları birkaç satır kodla yazabilirsiniz. Her programın kodunun çoğu, sizin uygulamanıza özgüdür. Yani, aslında geriye kalan her şey zaten sizin için yapılıp hazırlanmıştır.

Bu dilin sözdizimi son derece öz ve sadedir. Fazladan bir karakter yazmanıza veya sık sık büyük harf kullanmanıza gerek kalmaz. Ne kadar güzel, değil mi?

Büyük soyutlamalar kullanarak bir programın ilk versiyonunu hızlıca yazabilirsiniz. Daha sonra, işleri hızlandırmak istediğinizde, dikkatinizi nereye yoğunlaştırmanız gerektiğini size söyleyen harika bir profil oluşturucunuz var. Gerekirse, inline byte kodu yazarak iç döngüleri kör gibi hızlı hale getirebilirsiniz. İşte bu, programcılığın büyüsü!

Öğrenilecek birçok güzel örnek mevcut ve dil öyle içgüdüsel ki, birkaç dakika içinde örneklerden yola çıkarak nasıl kullanacağınızı öğrenebilirsiniz. Sürekli olarak kılavuza bakmanıza pek gerek yok. Kılavuz zaten oldukça ince ve içinde pek az uyarı veya özel durum bilgisi bulunuyor. Yani, dilin kendisi size öğretiyor, siz sadece izliyorsunuz!

Bu dilde, küçük bir çekirdek ve güçlü, son derece özgün kütüphaneler bulunuyor. Bu kütüphaneler, dilin çekirdek tasarımı kadar özenle oluşturulmuş. Tüm kütüphaneler birbiriyle kusursuzca çalışıyor; dilin her bir parçası, bir profesyonel fotoğraf makinesinin parçaları gibi birbiriyle tam uyumlu. Eski ve kullanılmayan hiçbir özellik yok. Tüm kütüphanelerin kaynak kodlarına rahatlıkla ulaşabilirsiniz. İşletim sistemiyle ve diğer dillerde yazılmış uygulamalarla iletişim kurmak son derece kolay. Bu dil, gerçekten her şeyi düşünmüş!

Dil, katmanlar halinde inşa edilmiştir. Üst seviye soyutlamalar, oldukça şeffaf bir biçimde, daha alt seviye soyutlamalar kullanılarak oluşturulur. Eğer isterseniz, bu alt seviye soyutlamaları da kullanabilirsiniz. Yani, isterseniz daha derine inebilirsiniz!

Sizinle kesinlikle saklanması gereken hiçbir şey paylaşılmaz. Dil size ne yapmanız gerektiğini söylemek yerine, işlerinizi kolaylaştırmak için soyutlamalar sunar. Hatta dil, onun tasarımında eşit bir katılımcı olmanızı teşvik eder. Her şeyi, hatta sözdizimini bile, değiştirebilirsiniz ve yazdığınız her şey, olabildiğince, önceden belirlenmiş olanlarla aynı statüye sahiptir. Bu dil, gerçekten sizin diliniz!

#### Notlar

[1] Modern anlamdaki makroların ilk fikri, Lisp 1.5'in yayınlanmasından iki yıl sonra, 1964'te Timothy Hart tarafından önerildi. Ancak başlangıçta, değişken yakalama ve çoklu değerlendirme problemlerini önleyecek çözümler henüz yoktu; Hart'ın makro örnekleri de bu iki sorundan muzdaripti.

[2] _Hava Beynine Çarptığında_ adlı eserinde, nöroşirürji uzmanı Frank Vertosick, baş asistanı Gary ile yaptığı bir konuşmayı anlatıyor. Bu konuşmada Gary, cerrahlarla iç hastalıkları uzmanları arasındaki farktan (""pireler"") bahsediyor:

> Gary ile büyük bir pizza sipariş ettik ve boş bir bölme bulduk. Şef bir sigara yaktı. ""Şu lanet pirelere bak, hayatlarında bir kez görecekleri bir hastalık hakkında gevezelik yapıyorlar. Pirelerin sorunu bu, garip şeyleri seviyorlar. Sıradan vakaları hiç sevmezler. İşte bizimle bu pireler arasındaki fark bu. Biz büyük, sulu bel fıtığı vakalarına bayılırken, onlar hipertansiyondan nefret ediyorlar....""

Bel fıtığı gibi bir şeyi 'lezzetli' olarak düşünmek (kelimenin tam anlamıyla) biraz tuhaf gelebilir. Ama sanırım onların ne demek istediklerini anlıyorum. Sıklıkla üzerinde keyifle çalıştığım hatalar olmuştur. Programcı olmayan bir kişi, bir hata üzerinde çalışmanın keyifli olabileceğini epey zor kabul eder. Her şeyin sorunsuz çalışmasının daha iyi olduğunu düşünür. Ama programcılar için, belirli türdeki hataların peşine düşmek de inkar edilemez bir tatmin sağlar. Bu, programcılığın bir parçasıdır ve bu dilde bu tür tatminlerin sayısı oldukça fazladır.""""

---

İlişkili Konseptler: programlama dili popülaritesi, bir programlama dili tasarlama, lisp programlama dili, tek kullanımlık programlar, programlama dili kütüphaneleri, programlama dili sözdizimi, programlama dili verimliliği, programlama dili yeniden tasarımı, hacker'ın hayalindeki dil, programlama dili evrimi, programlama dillerinde organik büyüme, sunucu tabanlı uygulamalar, programlama dili özlülüğü, programlama dili hacklenebilirliği."