"Paul Graham'ın 2001’de yazdığı bu makale, programlama dili tasarımı üzerine beş önemli noktayı ve bazı sorunları tartışıyor. Graham, programlama dillerinin insan beyninin ayrıntılarla boğulmasını önlemek için olduğunu, dillerin insan zayıflıklarına uygun tasarlanması gerektiğini belirtiyor. Kendi kullanımınız için tasarlanan dillerin genellikle daha iyi olduğunu, programcılara mümkün olduğunca çok kontrol sağlanması gerektiğini ve kodların kısa tutulmasının önemini vurguluyor. Ayrıca, programlama dillerinin tasarımının, dilin kendisi için yazılan bir uygulama ile birlikte geliştiğini ve atıl programlar yazmak için iyi bir dilin, çoğu yazılımın larva aşaması olan atıl programları yazmak için de iyi olması gerektiğini belirtiyor.

---

# Programlama Dilleri Tasarımında Dikkate Almanız Gereken Beş Soru (Five Questions about Language Design)

Mayıs 2001

_(10 Mayıs 2001'de MIT'de yapılan programlama dili tasarımı paneli için aldığım notlar bunlar.)_

**1. Programlama Dilleri: İnsanlar İçin Bir Köprü**

Programlama dilleri, bizim bilgisayarlarla konuşma yoludur. Bilgisayarlar, herhangi bir dili anlamaktan hoşlanır, ancak belirsizlik onlar için bir kabus olabilir. İşte bu yüzden, üst düzey programlama dilleri var. Çünkü biz insanlar, makine dilini anlamakta zorlanırız. Programlama dillerinin asıl amacı, bizim karmaşık detaylarla boğulmamamızı sağlamaktır.

Mimarlar, bazı tasarım sorunlarının diğerlerinden daha kişisel olduğunu çok iyi bilirler. En net ve en soyut tasarım sorunlarından biri köprü tasarlamaktır. Burada işin büyük bir kısmı, belirli bir uzaklığı en az malzemeyle kaplamaktır. Ancak bu spektrumun diğer ucunda, sandalye tasarımı bulunur. Sandalye tasarımcıları, büyük bir kısmını insanların oturduğu kısmı düşünerek geçirirler.

Yazılımın da çeşitlilik gösterdiğini görürüz. Bir ağda veri yönlendirmek için algoritmaları tasarlamak, köprü tasarlamak gibi, hoş ve soyut bir durumdur. Diğer yandan, programlama dilleri tasarlamak, sandalye tasarlamak gibi insana özgü zaaflarla başa çıkmayı gerektirir.

Birçoğumuz bunu kabul etmeyi sevmeyiz. Büyük matematiksel zarafetle sistemler tasarlamak, çoğumuza, insanların zayıflıklarını sömürmekten çok daha çekici gelir. Ve tabii ki, matematiksel zarafetin de bir yeri var: bazı türleri, programları daha anlaşılır kılar. Ama zarafet, sadece kendi başına bir amaç olmamalıdır.

""Dillerin insan zaaflarına göre tasarlanması gerektiğini"" söylediğimde, bunun beceriksiz programcılar için tasarlanması gerektiği anlamına gelmiyor. Benim görüşüme göre, aslında dilleri en iyi programcıları düşünerek tasarlamalıyız. Ancak unutmayın ki, en yetenekli programcıların bile bazı sınırları vardır. Örneğin, tüm değişkenlerin ""x"" harfi ve sonunda tam sayılarla belirtilen bir dilde kod yazmayı kimse sevmez.

**2. Kendin ve Arkadaşların için Tasarla.**

Programlama dillerinin tarihine baktığınızda, en iyi diller genellikle kendi yaratıcıları tarafından kullanılmak üzere tasarlanmıştır. En kötü diller ise genellikle başkalarının kullanması için tasarlanmıştır.

Diller, başka insanlar için tasarlandığında, bu 'başka'lar genellikle dilin tasarımcısından daha az zeki bir grup oluyor. Sonuç olarak, size tepeden bakan bir dil ortaya çıkıyor. Bu durumun en uç örneği hiç şüphesiz Cobol'dir. Ancak birçok dil, bu ""tepeden bakan"" ruhuyla şekillenmiştir.

Dilin ne kadar soyut olduğu hiçbir şeyi değiştirmez. C dili belki biraz basit düzeyde bir dil ama sonuçta yazarları onu kullanmak için tasarladı ve işte bu yüzden hackerlar bu dili seviyor.

Kötü programcılar için dillerin tasarlanması gerektiği argümanı, iyi programcılardan daha çok kötü programcı olmasına dayanır. Bu belki doğru bir durum olabilir. Ancak az sayıdaki iyi programcı, yazılımların dikkat çekici bir oranını yazıyor.

Benim ilgilendiğim bir soru var: en iyi hackerların bayılacağı bir dil nasıl tasarlanır? Bana kalırsa, 'nasıl iyi bir programlama dili tasarlanır?' sorusuyla tamamen özdeş bir soru bu. Ama hatta öyle olmasa bile, bu durum en azından ilgi çekici bir soru olmaya devam eder.

**3. Programcının Elini Mümkün Olduğunca Serbest Bırakın.**

Birçok dil (özellikle başkaları için tasarlananlar), sanki bir dadı gibi davranıyor: Size, onların sizin için iyi olmayacağını düşündüğü şeyleri yapmanızı engellemeye çalışıyorlar. Benim tercihim tam tersi yönde: Programcıya olabildiğince çok kontrol yetkisi vermek.

Lisp'i ilk öğrendiğimde, bana eşit bir partner gibi davranması hoşuma gitmişti. O zamana kadar öğrendiğim diğer dillerde, dil ile benim yazdığım program birbirinden çok farklıydı. Ancak Lisp'te, benim yazdığım fonksiyonlar ve makrolar dilin kendisini oluşturanlardan farksızdı. İstesem dili tamamen yeniden yazabilirdim. Bu durum, açık kaynaklı yazılımların çekiciliğini anımsatıyordu.

**4. Kısa ve Öz Olmayı Amaçlayın.**

Özlülük genellikle küçümsenir ve hatta aşağılanır. Ancak, ""Az söz, çok iş"" ilkesi programlama dünyasında da geçerlidir. Kısa ve öz kodlar, daha anlaşılır, daha hızlı ve daha kolay bakım yapılabilir yazılımların temelini oluşturur. Bu yüzden, programlama dili tasarımında da özlülük hedeflenmelidir.Hackerların dünyasına bir göz atmak, onların bu dünyayı ne kadar çok sevdiklerini anlamak demektir. Örneğin, bir APL kodunda birkaç satırın neler başarabileceğini hayranlıkla anlatmalarını duyduğunuzda, gerçekten zeki insanların hayran olduğu her şeyin ne kadar değerli olduğunu anlarsınız.

Programlamada, her şeyin kısaltılması ve basitleştirilmesi önemlidir. Kütüphane fonksiyonları bol olmalı, çünkü ne kadar çok şey varsayımsal yapılabilirse o kadar iyidir. Sözdizimi bile fazlasıyla öz olmalı. Hatta nesnelerin isimleri bile kısa olmalı. 

Ve sadece programlar değil, kullanım kılavuzları da kısa olmalı. Kılavuzların büyük bir bölümü genellikle açıklamalar, uyarılar, özel durumlar ve ayrıntılarla doludur. Eğer kendinizi kılavuzu kısaltmaya zorlarsanız, en iyi ihtimalle, bu kadar çok açıklama gerektiren dil sorunlarını gidererek bunu başarırsınız.

**5. Hacking'in Gerçekten Ne Olduğunu Kabul Edin.**

Birçok kişi, hacklemenin matematik ya da en azından doğa bilimleri gibi bir şey olmasını diler. Ancak bence hackleme, daha çok mimarlık gibi bir şey. Mimarlık da fizikle ilişkilidir çünkü mimarlar, çökmeyecek binalar tasarlamak zorundadır. Ancak asıl amaçları statik hakkında yeni buluşlar yapmak değil, muhteşem binalar yaratmaktır.

Hackerlar, büyük programlar yapmayı severler. Ve bence, en azından kendi zihnimizde, bu yaratıcılığın geleneksel akademik makalelerle kolayca ölçülemeyecek olsa bile, harika programlar yaratmanın takdire şayan bir şey olduğunu hatırlamamız gerekiyor. Zihinsel olarak, programcıların seveceği bir dil tasarlamak, bir makale yayınlayabileceğiniz korkunç bir dil tasarlamak kadar değerlidir.

**1. Büyük Kütüphaneler Nasıl Düzenlenir?**

Programlama dillerinde kütüphaneler giderek daha önemli bir yer ediniyor. Ancak büyüyorlar ve bu da tehlikeli olabilir. Kendi başınıza yazmaktansa, istediğiniz işlemi yapacak kütüphane fonksiyonunu bulmak daha uzun sürüyorsa, tüm bu kodlar sadece kullanım kılavuzunuzu kalınlaştırıyor. Dolayısıyla, kütüphaneleri nasıl düzenleyeceğimize dair çözümler bulmamız gerekiyor. İdeal olanı ise, bir programcının hangi kütüphane çağrısının doğru işlemi yapacağını tahmin edebileceği bir şekilde tasarlamaktır.

**2. İnsanlar Gerçekten Önek Sözdiziminden Çekiniyor mu?**

Bu, yıllardır kafamı kurcalayan ve hala cevabını bulamadığım bir sorun. Matematik dışında, önekli sözdizimi bana oldukça doğal gibi geliyor. Ancak Lisp'in popüler olmamasının sebebi belki de alışılmadık bir sözdizimine sahip olmasından kaynaklanıyor olabilir. Eğer durum buysa, bu konuda ne yapılabilir? İşte bu tamamen başka bir konu.

**3. Sunucu Tabanlı Yazılım İçin Neler Gerekiyor?**

Bence önümüzdeki yirmi yıl içinde yazılacak en heyecan verici yeni uygulamaların çoğu, web tabanlı olacak. Yani, bu programlar sunucuda bulunacak ve bir web tarayıcısı aracılığıyla sizinle iletişim kuracaklar. Ve bu tür programları yazabilmek için belki de bazı yeni şeylere ihtiyacımız olacak.

Bize gerekli olan şeylerden biri, sunucu tabanlı uygulamaların yeni yayınlanma biçimi için destek olacak. Masaüstü yazılımlar gibi yılda bir ya da iki büyük sürüm çıkarmak yerine, sunucu tabanlı uygulamalar sürekli küçük değişikliklerle güncellenir. Günde beş ya da on defa güncelleme yapılabilir bile. Ve genel kural olarak herkes daima en son sürümü kullanır.

Programları nasıl hata bulmak için tasarladığınızı biliyor musunuz? İşte, sunucu tabanlı yazılımlar da aynı şekilde tasarlanmalı; yani kolayca değiştirilebilir olmalı. En azından hangi değişikliklerin küçük, hangilerinin ise büyük olduğunu bilmeniz gerekir.

Şaşırtıcı bir şekilde, sunucu tabanlı yazılımlar için devamlılıkların da işe yarayabileceği ortaya çıkabilir. Web tabanlı yazılımlarda, bir web oturumunun doğası gereği durumsuz dünyada alt programlar etkisini elde etmek için devamlılık geçirme tarzı gibi bir yaklaşımı kullanabiliriz. Belki de maliyeti çok fazla değilse, gerçek devamlılıkları kullanmak da faydalı olabilir.

**4.Daha Keşfedilmesi Bekleyen Yeni Soyutlamalar Nelerdir?**

Bu beklentimin ne kadar gerçekçi olduğundan emin değilim, ama benim kişisel olarak gerçekten yapmayı çok istediğim bir şey var: Yeni bir soyutlama keşfetmek. Yani birinci sınıf fonksiyonların, özyinelemenin ya da anahtar kelime parametrelerinin yarattığı kadar büyük bir etki yaratan bir şey bulmak. Bu belki hayal gibi gelebilir. Çünkü bu tür şeyler pek sık rastlanan türden değil. Ama ben her zaman gözlerimi açık tutuyorum, belki bir gün bu keşfi yaparım diye.

**1. Hangi Dili Kullanmak İsterseniz, Onu Kullanabilirsiniz.**

Uygulama programları yazmak, genellikle masaüstü yazılımı yazmak anlamına gelirdi. Masaüstü yazılımında, uygulamanın işletim sistemi ile aynı dilde yazma eğilimi oldukça yaygındı. Bu yüzden on yıl önce, yazılım yazmak genellikle C dilinde yazılım yazmak demekti. Zamanla bir gelenek oluştu: uygulama programları, alışılmışın dışında dillerde yazılmamalıdır. Bu gelenek, yöneticiler ve risk sermayedarları gibi teknik olmayan kişilerin de kavrayacağı kadar uzun bir süre boyunca gelişti.

Sunucu tabanlı yazılım, bu tüm modeli alt üst ediyor. Sunucu tabanlı yazılımla istediğiniz her dilde kod yazabilirsiniz. Hala neredeyse kimse bunu tam anlamıyla kavrayamadı (özellikle yöneticiler ve yatırımcılar). Ancak bir avuç uyanık yazılımcı bu durumu fark etti ve bu sayede Perl ve Python gibi bağımsız, yeni diller hakkında konuşmaları duyuyoruz. Perl ve Python hakkında konuşmamızın sebebi insanların bu dilleri Windows uygulamaları yazmak için kullanmaları değil.

Bu, programlama dilleri tasarlamakla ilgilenen bizler için, artık çalışmalarımızı takip edecek bir kitle olabileceği anlamına geliyor.

**2. Hızın Kaynağı Profilerlardır.**

Dil tasarımcıları veya dilin uygulamasını gerçekleştirenler, genellikle hızlı kod çıktısı veren derleyiciler yazmayı severler. Ancak, kullanıcılar için dillerin hızlı olmasını sağlayanın bu olmadığını düşünüyorum. Knuth, hızın sadece birkaç kritik noktada önemli olduğunu uzun zaman önce belirtmişti. Ve deneyen herkes bilir ki, bu kritik noktaların nerede olduğunu tahmin etmek mümkün değil. İşte tam da bu noktada profilleyiciler devreye giriyor.

Dil tasarımcıları aslında yanlış bir sorunun peşindeler. Kullanıcıların hızlı çalıştıran benchmarklara ihtiyaçları yok. Onlara gerçekten lazım olan, hangi bölümlerini yeniden yazmaları gerektiğini gösteren bir dil. İşte hızın sırrı burada. Bu yüzden belki de, dil implementasyonları üzerine çalışanlar, derleyici optimizasyonlarına harcadıkları zamanın yarısını iyi bir profil oluşturucu yazmaya ayırsalar, sonuç net kazanç olabilir.

**3. Bir Dili Tasarlamak İçin Bir Uygulamanıza İhtiyacınız Var.**

Bu kesin bir kural olmayabilir ama, en iyi dillerin genellikle üzerinde çalıştıkları bir uygulamayla birlikte geliştiğini görüyoruz. Örneğin, C dili sistem programlaması için ihtiyaç duyan kişiler tarafından yazıldı. Lisp ise kısmen sembolik türev almayı kolaylaştırmak amacıyla geliştirildi. McCarthy bu konuda o kadar hevesliydi ki, 1960'da ilk Lisp makalesini yazarken bile türev programları yazmaya başlamıştı.

Eğer uygulamanız yeni bir problemi çözüyorsa, bu durum çok iyi olur. Bu sayede dilinizde, programcıların ihtiyaç duyduğu yeni özelliklerin oluşmasını sağlarsınız. Benim kişisel ilgim ise, sunucu tabanlı uygulamalar için ideal bir dil yazmakta.

[Panel sırasında Guy Steele da aynı noktayı gündeme getirdi ve ek bir öneride bulundu. Dedi ki eğer dilinizin amacı derleyici yazmak değilse, uygulamanızın kendi dilinizin derleyicisini yazmak olmamalı.]

**4. Bir Dil, Tek Kullanımlık Programlar Yazmak İçin İyi Olmalı.**

Bir 'atılabilir program'ın ne olduğunu biliyorsunuz: hızla yazdığınız ve belirli bir işlem için kullanılan bir program. Etrafınıza baktığınızda, birçok büyük ve karmaşık programın aslında bu tür basit ve hızlıca yazılmış programlarla başladığını görebilirsiniz. Aslında, _çoğu_ programın bu şekilde, bir atılabilir program olarak başladığını söylemek bile mümkün.Yazılım geliştirme dünyasında, yeni bir programlama dilinin oluşturulması, bir çocuğun doğumuna benzer. Bu dil, atılabilir programları yazmak için uygun olmalıdır çünkü çoğu yazılımın hayat döngüsü, bu tür basit programların oluşturduğu bir larva evresi ile başlar. 

**5. Sözdizimi ve Anlam Birbiriyle İlişkilidir.**

Dil bilgisi ve anlamın birbirinden ayrı olduğunu düşünmek alışılagelmiş bir durum. Ancak, belki de aslında bu ikisi arasında bir bağlantı olabilir. Düşündüğünüz şeyi nasıl ifade ettiğiniz, onun anlamını etkileyebilir.

Robert Morris ile yaptığım bir konuşmada, operatör aşırı yüklemenin önekli sözdizimi olan dillerde daha işlevsel olduğunu söyledi. Önekli bir dilde, her fonksiyonun aslında bir operatör gibi çalıştığını düşünebilirsiniz. Kendi yarattığınız bir sayı türü için bir toplama işlemi tanımlamak isterseniz, bunları ekleyen yeni bir fonksiyon oluşturabilirsiniz. Ancak, bunu önekli sözdizimi olan bir dilde yaparsanız, aşırı yüklenmiş bir operatör kullanmanın ve bir fonksiyon çağırmanın görsel olarak ne kadar farklı göründüğünü göreceksiniz.

**1. Yeni Programlama Dilleri.**

1970'lerde yeni programlama dilleri tasarlamak çok popülerdi. Ancak son dönemlerde bu popülerlik kayboldu. Ancak sunucu tabanlı yazılımların yükselişi, yeni dillerin tekrar popüler olacağını düşünüyorum. Sunucu tabanlı yazılımlarda istediğiniz dili kullanabilirsiniz, yani eğer biri gerçekten diğerlerinden daha iyi bir dil tasarlar ise, risk alıp onu kullanacak insanlar mutlaka olacaktır.

**2. Zaman Paylaşımı**

Richard Kelsey, son panelde bu fikrin yeniden gündeme geldiğini söyledi ve ben tamamen ona katılıyorum. Tahminim (ve anlaşılan Microsoft da aynı fikirde), bilgisayar işlemlerinin büyük bir kısmı masaüstünden çıkıp uzaktaki sunuculara taşınacak. Yani, zaman paylaşımı geri geliyor. Ve bence bu durum dil seviyesinde de desteklenmeli. Örneğin, Richard ve Jonathan Rees'in Scheme 48'de süreç planlaması üzerine çokça çalıştığını biliyorum.

**3. Verimlilik.**

Son zamanlarda bilgisayarların sonunda yeterince hızlı olduğu düşüncesi yayılmaya başlamıştı. Daha çok 'byte code' terimini duymaya başlamıştık ki bu da bana, artık bilgisayarlarımızın hızından biraz feragat edebilecek kadar rahatladığımızı düşündürüyordu. Ancak, sunucu tabanlı yazılımların durumunu düşündüğümüzde, aynen böyle devam edeceğimizi sanmıyorum. Bu tarz yazılımların çalıştığı sunucuların masraflarını birilerinin karşılaması gerekiyor ve kullanıcı başına düşen sunucu maliyeti, onların toplam sermaye maliyetlerini belirleyen anahtar faktör olacak.

Bu nedenle, bence verimlilik en azından bilgisayarla ilgili darboğazlarda önemli olacak. Özellikle i/o işlemlerini hızlı yapmak önemli olacak çünkü sunucu tabanlı uygulamalar çok fazla i/o işlemi gerçekleştirir.

Sonuçta bayt kodunun pek de kazanç sağlamadığını görebiliriz. Görünüşe göre Sun ve Microsoft, şu anda bir tür bayt kodu savaşı içerisindeler. Ama bunu yapıyorlar çünkü bayt kodu, kendilerini sürece dahil etmek için pratik bir yol sağlıyor, bayt kodunun kendisinin iyi bir fikir olduğu için değil. Bu tüm savaş alanının tamamen atlandığı bir sonuçla bile sonlanabilir. Bu durum gerçekten de oldukça komik olurdu.

**1. Müşteriler.**

Bu sadece bir tahmin, ama benim tahminim çoğu uygulama için kazanan modelin tamamen sunucu tabanlı olacağı yönünde. Herkesin sizin yazılımınızı kullanacağını varsayarak bir yazılım tasarlamak, herkesin dürüst olacağını varsayarak bir toplum kurmaya benzer. Elbette bu çok ideal olurdu ama bunun hiçbir zaman gerçekleşmeyeceğini kabul etmek zorundayız.

Bence, web erişimi olan birçok cihazla karşılaşacağız ve bu cihazlar hakkında emin olabileceğimiz tek şey basit HTML ve formları destekleyebilecekleri olacak. Cep telefonunuzda bir tarayıcı olacak mı? Palm pilotunuzda bir telefon olabilir mi? Blackberry'nizin ekranı daha mı geniş olacak? Gameboy'unuzda web'i dolaşabilecek misiniz? Ya da saatiniz üzerinden mi? Bilmiyorum. Fakat eğer her şeyin sunucuda olacağına bahse girersem, bunları bilmeme gerek kalmayacak.**Verilerin Sunucuda Olması: Güçlü ve Sağlam Bir Çözüm**

Biraz teknik bir konuya gireceğiz: verilerin sunucuda olması. Bu, bazıları için tartışmalı bir konu olabilir, ancak ben bu çözümün oldukça güçlü ve sağlam olduğunu düşünüyorum. 

**2. Nesne-Yönelimli Programlama.**

Şimdi de nesne yönelimli programlamaya bir göz atalım. Bu, bazıları için büyük bir numara gibi görünebilir, ancak benim düşünceme göre, belirli uygulamalar için - örneğin pencere sistemleri, simülasyonlar ve CAD programları gibi uygulamalar - oldukça işlevsel bir model. Ancak, neden her türlü programlama için bu modelin kullanılması gerektiğini hala tam olarak anlamış değilim.

Büyük şirketlerdeki bazı insanlar, nesneye yönelik programlamayı seviyor olabilir çünkü bu yol, bir sürü 'iş yapıyormuş' gibi görünen şeyler üretiyor. Örneğin, doğal olarak bir tam sayılar listesi olarak ifade edilebilecek bir konu, şimdi tüm karmaşıklığı ve yoğunluğuyla bir sınıf olarak temsil ediliyor.

Nesneye yönelik programlamanın başka bir çekiciliği, metodların size birinci sınıf fonksiyonların etkisini sunabilmesi. Ama bu, Lisp programcıları için eski bir haber. Gerçek birinci sınıf fonksiyonlara sahip olduğunuzda, hepsini sınıf ve metodların kalıbına sokmak yerine, ellerinizdeki işe uygun şekilde kullanabilirsiniz.

Dil tasarımı açısından baktığımda, nesne yönelimli programlamayı çok derinlere inmeden oluşturmanın önemli olduğunu düşünüyorum. Belki de çözüm, daha genel ve temel özellikler sunmak ve insanların kendi nesne sistemlerini kendi kütüphanelerinde tasarlamalarına izin vermek olabilir.

**3. Komiteler Tarafından Tasarlanan Ürünler.**

Dilinizi bir komite tarafından tasarlanması, beklenenden çok daha büyük bir sorun olabilir. Herkes, komitelerin genellikle düzensiz ve tutarsız tasarımlar ürettiklerini bilir. Ancak bence daha büyük tehlike, komitelerin risk almaktan çekinmeleridir. Tek bir kişi kontrolü ele aldığında, bir komitenin hiçbir zaman onay vermeyeceği riskleri alabilir.

Peki, iyi bir dil oluşturmak için risk almak zorunda mıyız? Dil tasarımının, genelde kabul görmüş kurallara oldukça sıkı bir şekilde bağlı kalmamız gereken bir alan olduğunu düşünen birçok kişi olabilir. Fakat bence bu doğru değil. İnsanların yaptığı her şeyde, ödül riskle orantılıdır. Dil tasarımı neden bu genel kuralın dışında kalabilsin ki?""""

---

İlişkili Konseptler: programlama dili tasarımı, programcılar için tasarım, programlama dillerinde kontrol, programlama dillerinde özlülük, hackleme ve programlama dilleri, sunucu tabanlı yazılım dilleri, programlama dillerinde sözdizimi ve semantik, programlama dillerinde verimlilik, nesne tabanlı programlama, dil tasarımında riskler, belirli uygulamalar için programlama dilleri tasarlama, sunucu tabanlı uygulamalar için programlama dilleri tasarlama."