"Paul Graham'ın 2002’de yazdığı bu makale, programlama dillerinin gücünü 'özlülük' kavramı üzerinden incelemeye yönelik. Graham, bir programlama dilinin ne kadar özlü olabileceğini ve bu özlülüğün dilin gücüne nasıl etki ettiğini tartışıyor. Ayrıca, bir dilin çok özlü olmasının bazı durumlarda okunabilirliği ve anlaşılabilirliği azaltabileceğini, bu durumun ise genellikle negatif bir etkiye sahip olduğunu belirtiyor. En iyi programlama dili tasarımının, kodun hem özlü hem de okunabilir olduğu bir denge noktasında olduğunu ifade ediyor.

---

# Programlama Dillerinde Özgün ve Etkili Olmanın Gücü (Succinctness is Power)

Mayıs 2002

> ""Bu kadar çok anlamı cebirsel işaretlerle küçük bir alana sıkıştırabilmek, bizim düşüncelerimizi kolaylaştıran bir faktördür."" - Charles Babbage, Iverson'ın Turing Ödülü Konuşması'nda

'Zeki Çocukların İntikamı' hakkında LL1 mailing listesindeki tartışmalar sırasında, Paul Prescod'un bir yorumu aklımda kalıcı bir iz bıraktı.

> ""Python'un amacı, özlük değil, düzen ve okunabilirlik üzerinedir.""

Bir programlama dilinin amacının özlülük olduğunu söylemek, ilk duyduğunuzda oldukça ağır bir iddia gibi gelebilir. Ama düşündüğümüzde, aslında özlülük güç demektir. Eğer bir denklem yaparsak, şöyle bir sonuç çıkar: 

> ""Python'un hedefi, güç değil, düzenlilik ve okunabilirliktir.""

Ve bu, (eğer bir ödün verme durumu söz konusuysa) vermeyi isteyeceğiniz bir ödün gibi görünmüyor. Bu durum, Python'un bir programlama dili olarak etkili olma amacının olmadığını söylemenin bir adım ötesi gibi.

Özlülük, güç müdür? Bu, dil tasarımıyla ilgilenen herkes için belki de en önemli soru gibi geliyor bana. Hatta bu sorunun doğrudan ele alınmasının oldukça faydalı olacağını düşünüyorum. Henüz cevabın basit bir 'evet' olduğundan emin değilim, ama başlamak için iyi bir hipotez gibi görünüyor.

**Hipotez**

Benim teorim, özlülüğün gücü temsil ettiği ya da en azından patolojik örnekleri bir kenara bırakırsak, ikisinin neredeyse aynı şey olduğu yönünde.

Bana göre, programlama dillerinin asıl amacı, özlülüktür. Bilgisayarlar, komutları makine dilinde direkt almayı da severler. Ancak, yüksek seviye dilleri geliştirmeye çalışmamızın ana nedeni, kaldıraç etkisinden yararlanmaktır. Yani, bir durumu makine dilinde 1000 satırla ifade etmek yerine, yüksek seviye bir dilde sadece 10 satırla ifade edebiliriz (ve daha önemlisi, bu şekilde düşünebiliriz). Yani, yüksek seviye dillerin esas görevi, kaynak kodunu daha küçük ve özlü hale getirmektir.

Eğer yüksek seviye dillerin ana amacı daha küçük bir kaynak kodu oluşturmaksa ve bir nesnenin gücü, amacını ne kadar iyi gerçekleştirdiği ise, o zaman bir programlama dilinin gücünü ölçen şey, programlarınızı ne kadar küçülttüğüdür.

Aksine, programlarınızı küçültmeyen bir dil, aslında programlama dillerinin yapması gereken işi kötü yapıyor. Bu, iyi kesmeyen bir bıçak ya da okunamayan bir yazıya benzer.

**Metrikler**

Ama küçük derken ne demek istiyorsunuz? Kod boyutunu genellikle kod satırlarına bakarak ölçeriz. Fakat bana kalırsa, bu ölçüm yöntemi sadece ölçmesi kolay olduğu için en yaygın olanı. Sanmıyorum ki bir programın gerçek uzunluğunu belirleyen tek şeyin bu olduğuna kimse inansın. Her dilin bir satıra ne kadar şey koymanız gerektiği konusunda farklı kuralları vardır; C dilinde bir sürü satır sadece bir ya da iki ayırıcıdan ibarettir.

Bir başka kolay test yöntemi bir programdaki karakter sayısını hesaplamaktır, ancak bu da çok iyi bir yöntem sayılmaz. Çünkü bazı diller (örneğin Perl) diğerlerine göre daha kısa tanımlama kullanır.

Bir programın boyutunu ölçmek için daha iyi bir kriter, öğe sayısı olabilir. Öğe, kaynak kodu temsil eden bir ağaç çiziminde ayrı bir düğüm olabilecek her şeydir. Bir değişkenin veya fonksiyonun adı bir öğedir; bir tam sayı ya da bir ondalık sayı bir öğedir; bir metin parçası bir öğedir; bir desenin ya da bir format direktifinin bir öğesi bir öğedir; yeni bir blok bir öğedir. Elbette bazı belirsiz durumlar var (örneğin -5 iki öğe mi, yoksa tek bir öğe mi?) ama çoğunluğu her dil için aynı olduğunu düşünüyorum, bu yüzden dil karşılaştırmalarını çok fazla etkilemezler.

Bu ölçüt daha detaylı bir şekilde ele alınmalı ve belki de özel diller durumunda yorumlanması gerekebilir. Fakat bence bu, bir programın kaç parçadan oluştuğunu ölçmeye çalışıyor. Sanırım bu egzersizde çizeceğiniz ağaç, bir programı hayal etmek için kafanızda oluşturmanız gereken şey.Bu yüzden, bu ağacın büyüklüğü, programı yazmak veya okumak için yapmanız gereken iş miktarıyla orantılıdır. 

**Tasarım**

Bu tür bir ölçüt, farklı dilleri karşılaştırmamıza yardımcı olabilir, ancak en azından benim için, bu özelliği asıl değil, sadece bir yan ürün. Bu özlülük testinin asıl değeri, dilleri _tasarlama_ sürecine rehberlik etmesi. Diller arasında en faydalı karşılaştırma, aynı dilin iki potansiyel versiyonu arasındadır. Dilin yapısında ne tür değişiklikler yaparak programları daha kısa hale getirebilirim?

Eğer bir programın kavramsal yükü, karmaşıklığına orantılıysa ve belirli bir programcı sadece sabit bir kavramsal yükü kaldırabiliyorsa, bu durum aslında şu soruyu gündeme getiriyor: Programcıların en çok iş yapabilmesini nasıl sağlarım? Ve bana kalırsa, bu soru ""Nasıl iyi bir dil tasarlarım?"" sorusuyla tamamen aynı.

(Not düşmek gerekirse, ""tüm diller birbirine eşittir"" gibi eskimiş bir ifadenin ne kadar yanıltıcı olduğunu en iyi dil tasarlarken anlarsınız. Yeni bir dil tasarladığınızda, sürekli olarak iki dili -x'i yaptığım dil ve yapmadığım dil- karşılaştırır ve hangisinin daha iyi olduğuna karar verirsiniz. Eğer bu gerçekten anlamsız bir soru olsaydı, madeni para atarak karar verebilirdiniz.)

Öz ve net ifadelere yönelmek, yeni fikirler bulmada etkili bir yol olabilir. Eğer birçok farklı programı daha kısa hale getirebiliyorsanız, bu kesinlikle bir rastlantı olmayabilir: büyük ihtimalle kullanışlı bir yeni soyutlamayı bulmuşsunuzdur. Hatta, tekrar eden desenleri bulmak için kaynak kodu tarayan bir program yazabilirsiniz. Diğer diller arasında, özlülükleriyle tanınan dillerden yeni fikirler alabilirsiniz: Forth, Joy, Icon.

**Karşılaştırma**

Bildiğim kadarıyla, bu konuları ilk defa Fred Brooks, _Mythical Man Month_ adlı kitabında ele almıştı. Programcıların, hangi dilde kod yazdıklarına bakılmaksızın, günde genellikle aynı miktarda kod ürettiklerini ifade etmişti. Bunu ilk kez yirmili yaşlarımın başında okuduğumda, bu benim için büyük bir sürprizdi ve çok büyük etkileri olabileceğini düşündürdü. Bu, (a) bir yazılımı daha hızlı kodlamanın tek yolunun daha öz bir dil kullanmak olduğunu ve (b) bunu yapmak için çabalayan bir kişinin, çabalamayan rakiplerini kolaylıkla geride bırakabileceğini gösteriyordu.

Eğer Brooks'un teorisi doğruysa, bu teori hacklemeyi anlamanın tam merkezine oturuyor gibi görünüyor. Yıllar boyunca, resmi çalışmalardan tutun da kişisel projeler hakkındaki tek tek anekdotlara kadar, bu konuda elde edebileceğim her türlü kanıta dikkatle göz attım. Ve Brooks'un iddialarını çürütebilecek hiçbir şey bulamadım.

Henüz beni tam anlamıyla ikna eden bir kanıt görmedim ve beklemediğim de bir gerçek. Lutz Prechelt'in programlama dillerini karşılaştıran çalışması gibi çalışmalar, beklediğim sonuçları elde ediyor olsalar da, genellikle test için anlamlı olabilecek sorunlar çok kısa oluyor. Bir dilin gerçek değerlendirmesi, bir ay süren programların nasıl yazıldığına bakmaktır. Ve eğer benim gibi düşünüyorsanız, bir dilin ana amacı, bir bilgisayara ne yapacağını söylemekten ziyade, düşünmek için kullanışlı olmasıdır. Dolayısıyla, gerçek test, o dilde ne tür yeni şeyler yazabildiğinizdir. Bu nedenle, belirli bir spesifikasyonu karşılaması gereken herhangi bir dil karşılaştırması, biraz yanlış bir şeyi ölçmüş oluyor.

Bir dilin gerçek sınavı, yeni problemleri nasıl keşfedip çözebildiğiniz, zaten var olan bir problemi çözme yeteneğiniz değil. Bu ikisi oldukça farklı kriterler. Sanatta, işlemeli ve mozaik gibi ortamlar, ne yapmak istediğinizi önceden biliyorsanız çok iyi çalışır, fakat eğer bilmiyorsanız, işler hiç de iyi gitmez. Bir imajı yaparken aynı zamanda keşfetmek istiyorsanız - örneğin bir insanın resmi gibi karmaşık bir şeyi yaparken - daha akıcı bir ortam kullanmanız gerekiyor, kalem veya mürekkep yıkama veya yağlı boya gibi. Ve aslında, halılar ve mozaiklerin nasıl yapıldığına bakarsanız, önce bir resim yapılır, sonra kopyalanır.(Aslında ""karikatür"" kelimesi, bu amaçla yapılan bir resmi tanımlamak için kullanılıyordu.)

Programlama dillerinin gücünü karşılaştırmak, biraz karikatürize edilmiş bir durum gibi görünebilir. Evet, belki hassas karşılaştırmalar yapabiliriz, ama kesin sonuçlar elde etmek her zaman mümkün olmayabilir. Özellikle, dilleri karşılaştırmak üzere yapılan özel çalışmalar genellikle küçük problemleri çözme eğilimindedir ve çözümlemesi gereken problemler önceden belirlenmiştir. Bu nedenle, daha güçlü dillerin gerçek gücünü genellikle küçümsemeye meyilliyiz.

Ancak, sahadan gelen raporlar genellikle daha anlamlı olabilir. Örneğin, Ericsson'dan Ulf Wiger'ın yaptığı bir çalışma, Erlang dilinin C++'dan 4 ila 10 kat daha özlü olduğunu ve bu sayede yazılım geliştirmenin de buna orantılı olarak daha hızlı olduğunu belirtti.

> ""Ericsson'daki iç geliştirme projeleri arasında yapılan karşılaştırmalar, hangi dilin (Erlang, PLEX, C, C++ veya Java) kullanıldığına bağlı olmaksızın, yazılım geliştirmenin her aşamasını içeren saat başı kod verimliliğinin benzer olduğunu gösteriyor. Bu durumda farklı diller arasındaki ayrımı belirleyen faktör, kaynak kodunun boyutu oluyor.""

Bu çalışma, Brooks'un kitabında sadece dolaylı olarak bahsettiği bir konuya açıkça değiniyor: Daha güçlü dillerde yazılan programlar genellikle daha az hata içerir. Bu durum, ağ anahtarları gibi uygulamalarda, belki de yazılımcı verimliliğinden daha önemli bir amaç haline geliyor.

**Tat Testi**

Sonuç olarak, bence içgüdülerinize kulak vermelisiniz. Bir dilde programlama yaparken nasıl hissediyorsunuz? En iyi dilin nasıl bulunacağını veya tasarlanacağını düşünüyorum; bir dilin düşünme biçiminizi ne kadar rahatlatıp rahatlatmadığına çok duyarlı olun ve ardından size en iyi hissi veren dili seçin veya tasarlayın. Eğer bir dil özelliği garip geliyorsa veya sizi sınırlıyorsa, merak etmeyin, emin olun bunu anlayacaksınız.

Bu aşırı hassasiyetin bir bedeli olacak. Kendinizi, beceriksiz dillerde programlama yapmaktan _rahatsız_ hissedeceksiniz. Benim için macrosuz dillerde programlama yapmak dayanılmaz bir kısıtlılık. Bu, dinamik yazılara alışmış birinin, her değişkenin türünü belirtmek zorunda olduğu bir dile geri dönmek zorunda kalmasının onun için ne kadar sıkıcı olduğuna benzer. Ve farklı türlerdeki objelerle bir liste yapamamak aynı şekilde dayanılmaz.

Yalnız olmadığımı biliyorum. Bunun başına gelen birçok Lisp hacker'ı tanıyorum. Aslında, programlama dillerinin göreceli gücünün en iyi ölçütü, hangi uygulama alanında olursa olsun, dili kullanabilecekleri her türlü işi kabul edenlerin oranı olabilir.

**Kısıtlayıcılık**

Bir dilin kısıtlayıcı olduğunu hissetmenin ne demek olduğunu, çoğu hacker çok iyi bilir. Peki bu his ne zaman ortaya çıkar? Bence, gitmek istediğiniz yol kapalı ve hedefinize ulaşmak için uzun bir dolambaçlı yol seçmek zorunda kaldığınızda hissettiğinizle aynıdır. Söylemek istediğiniz bir şey var, ama dil buna izin vermiyor.

Bence burada asıl mesele, kısıtlayıcı bir dilin yeteri kadar özgün olmaması. Sorun sadece planlananı ifade edememek değil. Asıl sorun, dilin sizi _daha uzun_ bir yola yönlendirmesi. Bir düşünce deneyi yapalım. Diyelim ki yazmak istediğiniz bir program var ve dil, size programı planladığınız şekilde ifade etme izni vermiyor. Ancak sizden programı _daha kısa_ bir şekilde yazmanızı istiyor. Bana kalırsa, bu pek de kısıtlayıcı hissettirmez. Bunun gibi bir durum, gitmek istediğiniz yolun kapalı olduğu ve kavşakta görevli polis memurunun sizi dolambaçlı bir yola değil, doğrudan bir kısayola yönlendirmesi gibi bir şey olurdu. Harika, değil mi?

Bir dilin kısıtlayıcı hissettirdiği durumların çoğunda (belki %90), yazdığınız programın, kafanızdaki versiyondan daha uzun olması gerektiği durumlar söz konusudur. Kısıtlayıcılık, genellikle özlülük eksikliğinden kaynaklanır. Yani, bir dil kısıtlayıcı hissettiriyorsa, genellikle bu dilin yeterince özlü olmadığını gösterir.Bir dil, yeterince özlü değilse, kısıtlayıcı bir his yaratabilir. Bu, herhangi bir iletişim biçimi için geçerlidir, ancak programlama dilleri için de aynıdır. 

**Okunabilirlik**

Başladığım alıntıda düzenlilik ve okunabilirlikten bahsediliyor. Düzenlilik ne demek, düzenli ve okunabilir bir kodun sadece okunabilir bir koda göre üstünlüğü var mı, onu tam bilmiyorum. Ama okunabilirlik ne demek onu tahmin edebiliyorum ve bence bu, özlülükle de ilgili.

Burada dikkat etmemiz gereken husus, tek bir kod satırının okunabilirliği ile tüm programın okunabilirliği arasındaki farktır. Asıl önemli olan ikincisidir. Evet, bir Basic kod satırı, bir Lisp kod satırına göre daha okunabilir olabilir. Ancak Basic dilinde yazılmış bir program, Lisp dilinde yazılmış aynı programdan daha fazla satıra sahip olacaktır (özellikle Greenspunland seviyesine geçtiğinizde). Dolayısıyla, Basic programını okumak için harcadığınız toplam çaba, muhtemelen daha fazla olacaktır.

> Toplam emek = bir satıra harcanan emek x satır sayısı

Bir dilin gücünün özde olduğu kadar okunabilirlikle doğru orantılı olduğundan emin değilim ama kesinlikle öz, okunabilirlikte bir etkendir (matematiksel bir şekilde düşünün; yukarıdaki denklemi göz önünde bulundurun). Bu yüzden bir dilin hedefinin, öz olmak yerine okunabilirlik olduğunu söylemek belki de anlamsız olabilir. Bu, sanki hedefin okunabilirlik değil de okunabilirlik olduğunu söylemek gibidir.

Satır başına okunabilirlik demek, bir dil ile ilk kez karşılaşan kullanıcı için, kodların _tehditkar görünmemesi_ demektir. Yani, satır başına okunabilirlik, kötü bir tasarım kararı olsa bile, iyi bir pazarlama stratejisi olabilir. Bu, insanlara taksitle ödeme yapma imkanı sunma tekniği ile aynıdır: yüksek bir peşin fiyatla onları korkutacağınıza, düşük aylık taksitleri söylersiniz. Ancak taksitli alışveriş, alıcı için genellikle zararlı olur, tıpkı satır başına okunabilirliğin programcı için olası zararı gibi. Alıcı, o düşük, düşük taksitleri bir sürü ödeyecek; ve programcı, o tek tek okunabilir satırları bir sürü okuyacak.

Bu dengeleme durumu, programlama dillerinden bile daha eskilere dayanıyor. Eğer romanlar ve gazete makaleleri okumaya alışkınsanız, ilk matematik makalesini okuma deneyiminiz bir hayli şaşırtıcı olabilir. Bir tek sayfayı okumak için belki de yarım saat harcamanız gerekebilir. Ancak, emin olun ki buradaki sorun, belki de öyle olduğunu düşüneceğiniz matematiksel notasyonlar değil. Matematik makalesini okumak zor çünkü içerdiği fikirler karmaşık. Eğer aynı fikirleri düz metin halinde ifade etmeye kalksaydınız (tıpkı matematikçilerin daha özlü notasyonlar geliştirilene kadar yapmak zorunda olduğu gibi), bu da makaleyi daha okunabilir kılmazdı. Çünkü bu durumda makale, bir kitap kadar geniş ve karmaşık olurdu.

**Ne Kadar?

Bazı kişiler, 'özlülük güçtür' düşüncesini reddediyor. Benim fikrim, bunun yerine 'bu iki kavram aynı mı, değil mi?' demekten çok, 'özlülük ne kadar güçtür?' diye sormak daha anlamlı olacak. Çünkü net bir şekilde, özlülük, üst düzey dillerin var oluş sebeplerinin büyük bir kısmını oluşturuyor. Eğer bu, dillerin tek amacı değilse, o zaman başka ne için varlar ve diğer işlevleri ne kadar önemli?

Bu öneriyi sadece tartışmayı daha medeni hale getirmek için değil, gerçekten yanıtını merak ettiğim için yapıyorum. Bir dil, kendi iyiliği için ne zaman çok öz olur? Eğer olursa, bu ne zaman olabilir?

Başladığım varsayım, patolojik örneklere rastlanmadıkça, özlülüğün güçle özdeş kabul edilebileceği yönündeydi. Kastettiğim, herhangi birinin tasarlayabileceği bir dilde, özlülük ve güç birbirine eşit olacaktı. Ancak, eğer biri çıkıp bu tezi çürütmek için özellikle bir dil tasarlamak isterse, muhtemelen bunu başarabilir. Aslında, bu konuda bile tam olarak emin değilim.

**Programlar Değil, Diller**

Burada belirtmemiz gereken bir nokta var: biz burada tek tek programların yoğunluğundan değil, genel olarak dillerin yoğunluğundan bahsediyoruz. Elbette, tek tek programların yoğun bir şekilde yazılması da mümkün.

Bunu On Lisp üzerinde anlatmıştım.Bir makro, kendini haklı çıkarmak için genellikle kendi boyutunun birkaç katını tasarruf etmek zorunda kalır. Evet, doğru duydunuz, bazen biraz daha karmaşık bir yapı, sonuçta daha az kod yazmanızı sağlar. Örneğin, bir makro yazmak size her kullanımda on satır kod tasarrufu sağlıyorsa ve makro da kendi başına on satırdan oluşuyorsa, eğer bir kez değil de birkaç kez kullanırsanız net olarak kod tasarrufu sağlarsınız. 

Ancak, bu durumda bile dikkatli olmak gerekiyor. Çünkü makro tanımlamaları okuması daha zor olabiliyor. Yani, makronun net bir okunabilirlik kazancı sağlamadan önce onu belki de on ya da yirmi kez kullanmanız gerekebilir.

Her dilin kendine ait bu türden zorlukları olduğunu düşünüyorum. Her programcı, bazen bazı zeki kişilerin belki de riskli programlama hileleri kullanarak kodu biraz daha kısa hale getirdiği durumlarla karşılaşmıştır. 

Bu konuda tartışacak bir şey yok-- en azından benim nezdimde. Bireysel programlar elbette kendi iyilikleri için çok öz olabilirler. Asıl merak edilen, bir dilin de bu şekilde olup olmayacağı. Acaba bir dil, programcıları genel okunabilirliği göz ardı edip daha kısa (eleman sayısı az) kod yazmaya zorlar mı?

Bir dilin fazla özlü olmasını hayal etmek zor çünkü bir şeyi ifade etmek için fazlasıyla yoğun ve sıkı bir yol olsa bile, büyük ihtimalle daha uzun bir ifade biçimi de olacaktır. Örneğin, eğer birçok makro veya yüksek seviye fonksiyonlar kullanan Lisp kodlarının çok yoğun olduğunu düşünüyorsanız, isterseniz, Pascal'a benzer bir kod da yazabilirsiniz. 

Eğer Arc'ta faktöriyel ifadesini yüksek seviye bir fonksiyon çağrısı olarak ifade etmek istemiyorsanız, bir de özyinelemeli tanımını yazabilirsiniz: 
```
(rfn fact (x) 
  (if (zero x) 
    1 
    (* x (fact (1- x))))) 
```
Hemen aklıma bir örnek gelmiyor, ama bir dilin fazla özlü olup olamayacağı konusu beni ilgilendiriyor. Kodu anlaması zor ve karmaşık bir şekilde yazmanızı zorlayan diller var mı acaba? Eğer bu konuda örnekleri olan varsa, onları görmek benim için çok ilginç olacak.

(Hatırlatma: Benim aradığım, yukarıda bahsettiğim ""elementler"" ölçütüne göre yoğun olan programlar. Sadece ayrıntıları atlayıp her şeyi tek bir karakterle ifade ederek kısaltılmış programlar değil.)""""

---

İlişkili Konseptler: programlamada özlülük, özlülüğün gücü, programlama dili tasarımı, programlamada okunabilirlik vs özlülük, programlama dili gücü, Python dil tasarımı, programlama dili karşılaştırması, programlama dili okunabilirliği, programlama dili düzenliliği, programlama dili özlülüğü, programlama dili karmaşıklığı, kodlama verimliliği, programlama dili verimliliği, programlama dili etkinliği."