"Paul Graham'ın 2003'te yazdığı bu makale, gelecekteki programlama dillerinin neye benzeyeceğini anlamaya çalışıyor. Graham, bir programlama dilini oluşturan temel operatörlerin dilin uzun vadeli hayatta kalması için en önemli faktör olduğunu ve dilin geri kalanının değiştirilebileceğini belirtiyor. Gelecekteki dillerin, daha az çalışmayı gerektiren programları yazmayı mümkün kılan diller olacağını öngörüyor. Ayrıca, bilgisayarların hız kazandıkça, programlama dillerinin verimlilik aralığını daha da genişletmesi gerektiğini ve bu durumun programcıları dil tasarımı konusunda doğru kararlar vermeye yönlendireceğini ifade ediyor.

---

# Yüz Yıl Sonrasının Programlama Dili Nasıl Olacak? (The Hundred-Year Language)

Nisan 2003

_(Bu yazı, PyCon 2003'teki ana konuşmamdan alıntıdır.)_

Geleceği tahmin etmek her zaman zordur, değil mi? Ama bazı şeyler hakkında eminiz. Herkesin uçan arabalar kullanacağını, çok katlı binaların gökyüzünü dolduracağını, genellikle karanlık bir dünyada yaşayacağımızı ve tüm kadınların dövüş sanatları eğitimi alacağını biliyoruz. Peki ya bu uçan arabaları kontrol eden yazılımları yazmak için hangi programlama dili kullanacağımızı hiç düşündünüz mü?

Bu konu üzerinde düşünmeye değer çünkü bu dilleri kullanma şansımız olmasa bile, eğer şanslıysak, bu dillerin yardımıyla bir noktadan diğerine geçiş yapabileceğiz.

Ben, dillerin de türler gibi evrimsel bir ağaç oluşturacağını ve birçok yerde çıkmaza giden dalların çıkacağını düşünüyorum. Bunu zaten yaşamaya başladık. Bir dönem oldukça popüler olan Cobol'un, her ne kadar popüler olsa da, zihinsel bir miras bırakmadığını görüyoruz. O, bir evrimsel çıkmaz yol - bir Neandertal dil.

Java için benzer bir son öngörüyorum. İnsanlar bazen bana mail atıp, ""Java'nın başarılı bir dil olmayacağını nasıl söyleyebilirsin? Bu zaten başarılı bir dil,"" diyorlar. Ve evet, eğer başarıyı, üzerine yazılmış kitapların raflardaki yerine veya bir iş bulabilmek için Java öğrenmek zorunda olduklarına inanan öğrenci sayısına göre ölçerseniz, Java başarılı bir dil. Ancak ben Java'nın başarılı bir dil olmayacağını söylediğimde, daha spesifik bir şey kastediyorum: Java'nın, Cobol gibi, evrimsel bir çıkmazda son bulacağını düşünüyorum.

Bu sadece bir tahmin. Yanılıyor olabilirim. Asıl amaç Java'ya laf atmak değil, dilin evrimsel ağacı konusunu gündeme getirmek ve 'dil X bu ağacın neresinde?' diye sorgulamaya başlamamızı sağlamak. Bu soruyu sormamızın sebebi sadece yüz yıl sonra 'bak, sana demiştim' diyebilmek değil. Asıl mesele, ana dallara yakın kalmak, şimdiki zaman için programlamada iyi olan dilleri bulmak için faydalı bir yöntem olabilir.

Herhangi bir zaman diliminde, en mutlu olduğunuz yer genellikle evrim ağacının ana dalları oluyor. Neandertaller hala etraftayken bile, bir Neandertal olmak gerçekten zor olsa gerek. Cro-Magnonlar sürekli olarak gelip seni döver ve yiyeceklerini çalarlardı.

Yüz yıl sonra dillerin neye benzeyeceğini bilmek istememin sebebi, hangi dalın üzerine bahse gireceğime şimdiden karar verebilmek.

Dillerin evrimi, türlerin evriminden farklıdır çünkü dal ayrımları tekrar birleşebilir. Örneğin, Fortran dili, Algol'dan türeyen dillerle birleşme eğiliminde gibi görünüyor. Teoride, türlerin de böyle birleşmeleri mümkün ama hücreden daha büyük bir türde bunun gerçekleşmiş olması oldukça düşük bir ihtimal.

Dillerin birbirine daha çok yakınlaşma eğilimi göstermesinin sebebi, hem seçeneklerin daha sınırlı olması hem de dildeki değişimlerin rastgele olmamasıdır. Dil tasarımcıları, diğer dillerden bilinçli olarak fikir alır ve bunu dil tasarımlarına aktarırlar.

Programlama dillerinin evriminin nereye gideceğini düşünmek, dil tasarımcıları için özellikle yararlıdır çünkü buna uygun olarak kendi rotalarını çizebilirler. Bu durumda, ""ana dalda kal"" ifadesi, sadece iyi bir dil seçmekten daha fazla bir anlam taşır. Bu, dil tasarımı konusunda doğru kararları vermek için bir yol gösterici haline gelir.

Her programlama dili, aslında iki parçadan oluşur: aksiyomların rolünü üstlenen temel operatörler ve bu temel operatörlere dayanarak yazılabilecek olan dilin geri kalanı.

Bence, bir dilin uzun vadede var olmasını sağlayan en önemli faktör, temel bileşenleridir. Geriye kalan her şeyi zamanla değiştirebilirsiniz. Bu durumu, bir ev satın alırken öncelikle konumu düşünme kuralına benzetebiliriz. Evi satın aldıktan sonra içini istediğiniz gibi düzenleyebilirsiniz, ama konumunu değiştiremezsiniz.

Aksiyomların sadece doğru seçilmesi değil, aynı zamanda sayılarının da fazla olmaması bence oldukça önemli. Bu, dilin evriminde esneklik ve sürdürülebilirlik sağlar. Bu yüzden, dil tasarımcılarına bir tavsiyem var: Temel bileşenlerinizi iyi seçin ve onları sade tutun. Bu, dilinizin gelecekte de var olmasını sağlayabilir.Matematikçilerin aksiyomlar hakkındaki düşünceleri her zaman ""ne kadar az o kadar iyi"" olmuştur. Bu, bence de doğru bir yaklaşım. 

En azından, bir dilin çekirdeğine dikkatlice bakıp, oradan çıkarılabilecek herhangi bir temel varsayım olup olmadığını görmek faydalı bir deneyim olabilir. Ben, her zaman dağınık bir insan olarak, bir şeyin birikmesinin, yeni birikimlere neden olduğunu gördüm. Bu durumu, sadece yatak altları veya oda köşelerinde değil, yazılım dünyasında da deneyimledim.

Evrimsel ağacın ana dallarının, en küçük ve en temiz çekirdeklere sahip dillerden geçtiğini düşünüyorum. Bir dil ne kadar çok kendisi içinde yazabilirse, o dil o kadar iyidir.

Elbette, yüz yıl sonra programlama dillerinin ne olacağını bile sorgularken büyük bir varsayım yapıyorum. Acaba yüz yıl sonra hala program mı yazıyor olacağız? Yoksa sadece bilgisayarlara ne yapmasını istediğimizi mi söyleyeceğiz?

Bu alanda şimdiye kadar çok fazla ilerleme olmadı. Tahminimce, yüz yıl sonra bile insanlar, bizim bugün tanıdığımız türden programlar kullanarak bilgisayarlara ne yapmaları gerektiğini söylemeye devam edecekler. Bugün program yazarak çözdüğümüz bazı görevler var ki, belki yüz yıl sonra program yazmaya gerek kalmadan çözülebilir. Ancak bence, bugün yaptığımız tarzda programlama, hala önemli bir yerde olacak.

Herhangi bir teknolojinin yüz yıl sonra neye benzeyeceğini tahmin etmek kulağa kibirli gelebilir. Ancak unutmayın ki, zaten neredeyse elli yıllık bir tarihimiz var. Son elli yılda diller ne kadar yavaş evrildiyse, yüz yıl sonrasını düşünmek o kadar da zor değil.

Diller, teknoloji olmadıkları için yavaşça evrimleşirler. Diller bir çeşit notasyon, yani bir gösterim biçimidir. Bir program, bir bilgisayarın sizin için çözmesini istediğiniz problemin resmi bir betimlemesidir. Bu yüzden, programlama dillerinin evrim hızı, taşımacılık veya iletişimden ziyade, matematiksel notasyonun evrim hızına daha çok benzer. Matematiksel notasyonun da evrimi vardır, ancak teknolojik ilerlemelerdeki büyük atılımlar gibi değil.

Yüz yıl sonra bilgisayarlar neye dönüşürse dönüşsün, şimdiye göre çok daha hızlı olacaklarına eminim. Eğer Moore Yasası geçerliliğini sürdürürse, bilgisayarlar bugünkü hızlarının inanılmaz bir şekilde 74 kentilyon (73,786,976,294,838,206,464) katı hızında çalışacaklar. Bunu düşünmek bile zor. Fakat, hız konusunda en olası tahmin, Moore Yasası'nın bir noktada işlevini yitireceği yönünde. Herhangi bir şeyin 18 ayda iki katına çıkması, sonunda bir tür sınıra ulaşacağı gibi görünüyor. Ancak, bilgisayarların çok daha hızlı olacağına kesinlikle inanıyorum. Yalnızca milyon kat daha hızlı olmaları bile, programlama dillerinin kurallarını ciddi anlamda değiştirecektir. Bu da, şu an için 'yavaş' olarak kabul edilen ve çok verimli kod üretmeyen diller için daha fazla alan demek.

Ve yine de bazı uygulamalar hız isteyecek. Bilgisayarlarla çözmeye çalıştığımız bazı sorunları aslında bilgisayarlar yaratıyor; örneğin, bir videoyu ne kadar hızla işlemeniz gerektiği, başka bir bilgisayarın onu ne hızda oluşturduğuna bağlı. Ve işlem gücünü sınırsızca emebilen başka bir sorun türü daha var: görüntü oluşturma, kriptografi, simülasyonlar gibi.

Eğer bazı uygulamalar giderek daha verimsiz olurken, diğerleri hala donanımın sunabileceği tüm hızı talep ediyorsa, daha hızlı bilgisayarlar demek, dillerin gittikçe daha geniş bir verimlilik aralığını kapsaması gerekeceği anlamına gelir. Bu durumu zaten yaşamaya başladık. Popüler yeni bazı dillerin mevcut uygulamaları, geçmiş on yılların standartlarına göre şaşırtıcı derecede israfçı.

Bu durum sadece programlama dilleriyle sınırlı değil. Tarihsel bir trend bu aslında. Teknoloji ilerledikçe, her yeni nesil, bir önceki nesilin israf olarak gördüğü şeyleri rahatlıkla yapabiliyor. Otuz yıl önce yaşayan biri, uzun mesafeli telefon görüşmelerini ne kadar rahatlıkla yaptığımıza hayrete düşerdi.Bir yüz yıl öncesinden biri, bugün bir paketin Boston'dan New York'a, Memphis üzerinden geçerek gideceğini duysa ne düşünürdü acaba? Eminim ki hayretler içinde kalırdı.

Şimdiki zamanı düşünelim. Teknolojinin bize sağladığı hız, önümüzdeki yüz yıl içinde daha da artacak. Ama bu hızın ne kadarını gerçekten kullanabileceğiz? Benim düşünceme göre, çoğunluğu boşa gidecek.

Programlamayı öğrendiğim zamanları hatırlıyorum. Bilgisayarların gücü o zamanlar hayli kısıtlıydı. Hala 4K TRS-80'in hafızasına sığabilmek için Basic programlarımdaki tüm boşlukları çıkardığımı hatırlıyorum. Şimdi, aynı işlemi defalarca tekrarlayan bu korkunç derecede verimsiz yazılımların enerji tüketmesi bana biraz mide bulandırıcı geliyor. Ama belki de ben yanılıyorumdur. Sonuçta, ben fakir bir ailede büyümüş ve önemli bir şey bile olsa, örneğin doktora gitmek gibi, para harcamakta zorlanan biriyim.

İsrafın türleri arasında gerçekten de iğrenç olanlar var. Örneğin, SUV'lar, hiç bitmeyecek ve hiçbir kirlilik yaratmayacak bir yakıtla çalışsa dahi, tartışmalara konu olabilirler. Çünkü SUV'lar, aslında hoş olmayan bir sorunun çözümüdür. (Minivanları nasıl daha maskülen gösterebiliriz?) Ama her türlü israf kötü değildir. Şimdi, onu destekleyecek altyapımız olduğuna göre, uzun mesafeli aramalarınızın dakikalarını saymanın cimri bir davranış olduğunu söyleyebiliriz. Eğer kaynaklarınız varsa, karşıdaki kişinin nerede olduğuna bakılmaksızın, tüm telefon görüşmelerini aynı şekilde düşünmek daha zarif bir yaklaşım olacaktır.

İsrafın iyi bir versiyonu da var, kötü bir versiyonu da. Benim ilgilendiğim iyi olanı; daha fazla harcayarak daha basit tasarımlar elde edebileceğimiz türdendir. Peki, yeni ve daha hızlı donanımlar sayesinde elde edeceğimiz fazladan döngüleri israf etme fırsatını nasıl kullanacağız?

Hız tutkusu, küçük bilgisayarlarımızla birlikte bizde çok derinlere işlemiş durumda ki, bunun üstesinden gelmek için bilinçli bir çaba sarf etmemiz gerekiyor. Dil tasarımında, en küçük bir kolaylık sağlama karşılığında verimliliği bile gözden çıkarabileceğimiz durumları bilinçli bir şekilde bulmalı ve değerlendirmeliyiz.

Çoğu veri yapısı aslında hız sebebiyle ortaya çıkıyor. Örneğin, bugün pek çok programlama dilinde hem karakter dizileri (strings) hem de listeler bulunuyor. Anlam olarak bakıldığında, karakter dizileri aslında karakterlerden oluşan bir liste türü. Peki, neden ayrı bir veri türüne ihtiyaç duyuyoruz ki? Aslında, gerçekten gerek yok. Karakter dizileri sadece performans için var. Ama bir dilin anlamını, programların daha hızlı çalışmasını sağlamak için karmaşıklaştırmak pek hoş bir durum değil. Bir dili karakter dizi türüyle doldurmak, gereğinden erken yapılmış bir optimizasyon gibi görünüyor.

Bir dilin temelini bir dizi aksiyom olarak düşünelim, sadece verimlilik uğruna ifade gücü katmayan ekstra aksiyomlara sahip olmak oldukça çirkin olmaz mı? Elbette, verimlilik önemlidir ama bence bu verimliliği sağlamanın doğru yolu bu değil.

Sorunu çözmenin en doğru yolu, bence, bir programın anlamını ve uygulama detaylarını birbirinden ayırmaktır. Hem liste hem de stringlere sahip olmak yerine, sadece listeler olmalıdır. Eğer gerekliyse, derleyiciye, stringleri bitişik baytlar halinde düzenlemesi için optimizasyon tavsiyeleri verebilecek bir yol olmalı.

Programın çoğunda hız önemli olmadığı için genellikle bu tür bir detaylı yönetimle uğraşmanıza gerek kalmayacak. Bilgisayarlar hızlandıkça bu durum daha da doğru olacak.

Uygulama detaylarına daha az odaklanmak, programların daha esnek olmasını sağlar. Bir program yazılırken özelliklerin değişmesi kaçınılmazdır ve aslında bu durum, istenen bir şeydir.

""Deneme"" kelimesi Fransızca ""denemek"" anlamına gelen ""essayer"" kelimesinden geliyor. Özünde, bir deneme bir şeyi çözmeye çalışırken yazdığınız bir şeydir. Bu, yazılım dünyasında da geçerli. Bana göre, en iyi programlar, yazarlarının ne yazmayı hedeflediklerini başlangıçta tam olarak bilmedikleri denemelerdir.

Lisp yazılımcıları, veri yapılarıyla esnek olmanın ne kadar değerli olduğunu zaten bilirler. Bir programın ilk versiyonunu genellikle her şeyi listelerle yapacak şekilde yazıyoruz.İlk versiyonlar bazen o kadar verimsiz olabilir ki, ne yaptıklarını düşünmemek için bilinçli bir çaba gerektirebilir. Bu, bir biftek yemek gibi olabilir, nereden geldiğini düşünmeden sadece yemek için çaba harcarız.

Ancak yüz yıl sonra, programcılar en az çabayla inanılmaz derecede verimsiz bir ilk versiyon oluşturabilecekleri bir dil arayışına girecekler. Şimdiki zaman diliminde bu şekilde tanımlayabiliriz. Ama onlar, işleri daha basit hale getirip, sadece programlaması kolay bir dil istediklerini söyleyecekler.

Verimsiz bir yazılım korkutucu değil. Asıl korkutucu olan, programcıları gereksiz işlerle uğraştıran bir dili kullanmaktır. Gerçek verimsizlik, makinenin zamanını çalmak değil, programcının zamanını çalmaktır. Bilgisayarlar hızlandıkça bu daha da belirgin hale gelecek.

Sanırım artık dizelerden kurtulma zamanı geldi. Bunu Arc projesinde yaptık ve kazanan taraf biz olduk; düzenli ifadelerle anlatması zor olan bazı işlemleri, özyinelemeli fonksiyonlarla kolayca anlatabildik.

Bu veri yapılarının sadeleştirilmesi ne kadar daha ilerleyecek? Bilinçli olarak genişlettiğim zihnim bile bazı ihtimaller karşısında şok olabiliyor. Örneğin, dizileri tamamen ortadan kaldırabilir miyiz? Sonuçta, onlar sadece anahtarlarının tam sayılar olduğu bir çeşit karma tablodan başka bir şey değil. Ya da belki de karma tabloları bile listelerle değiştirebiliriz, ne dersiniz?

Bundan daha şoke edici durumlar bile var. Örneğin, McCarthy'nin 1960'ta tanımladığı Lisp dilinde, sayılar yoktu. Mantıken bakıldığında, sayıları ayrı bir kavram olarak düşünmeye gerek yok. Çünkü onları listelerle temsil edebilirsiniz: n tam sayısı, n elemanı olan bir liste olarak ifade edilebilir. Bu şekilde matematiksel işlemler yapabilirsiniz. Ancak bu oldukça verimsiz bir yöntem olurdu.

Gerçekten de, kimse numaraların listeler olarak uygulanmasını pratikte önermedi. Aslında, McCarthy'nin 1960 tarihli makalesi ilk başta hiçbir şekilde hayata geçirilmesi planlanmamıştı. Bu bir teorik çalışma idi, Turing Makinesi'ne daha zarif bir alternatif yaratma çabası. Ancak ne olduysa oldu ve birisi bu makaleyi alıp işler bir Lisp yorumlayıcısına dönüştürdü. Ve elbette, numaralar listeler olarak temsil edilmedi; diğer tüm dillerde olduğu gibi, ikili sistemde yani binary olarak temsil edildi.

Bir programlama dili, sayıları temel veri türü olarak kullanmayı tamamen bırakabilir mi? Bunu ciddi bir soru olarak sormuyorum aslında, daha çok gelecekle bir nevi tavuk oyunu oynuyorum. Bu, durdurulamaz bir gücün hareketsiz bir objeyle karşılaştığı varsayımsal duruma benziyor. Burada ise düşünülemeyecek kadar verimsiz bir uygulamanın, düşünülemeyecek kadar büyük kaynaklarla karşılaşıyor. Neden olmasın? Gelecek çok uzun sonuçta. Eğer ana dildeki aksiyom sayısını azaltabilecek bir şey yapabiliyorsak, bu, zaman sonsuzluğa ilerledikçe bahis yapılacak taraf gibi görünüyor. Eğer bu düşünce yüz yıl sonra hala çekilmez görünüyorsa, belki bin yıl sonra görünmez olur.

Bunu net bir şekilde anlamanız adına şunu belirtmeliyim ki, ben bütün sayısal hesaplamaların listeler kullanılarak yapılmasını önermiyorum. Aslında benim önerim, herhangi bir uygulama notasyonu eklenmeden önce temel dilin bu şekilde tanımlanması yönünde. Pratikte matematiksel hesaplamalar yapmak isteyen herhangi bir program, büyük ihtimalle sayıları ikili sistemde temsil edecektir. Ancak bu durum, dilin temel anlamıyla ilgili bir konu değil, daha çok bir optimizasyon meselesidir.

Çalışma sürelerini hızlandırmanın bir diğer yolu da, uygulama ile donanım arasında bir dizi yazılım katmanı yerleştirmektir. Bu trendi zaten görmeye başladık: Son dönemde çıkan birçok programlama dili, bayt koduna derleniyor. Bill Woods bir keresinde bana, bir kural olarak, her bir yorumlama katmanının hızı yaklaşık on kat düşürdüğünü söyledi. Bu ekstra yük, size esneklik kazandırır.

Arc'ın ilk versiyonu, bu tür çok katmanlı yavaşlığın aşırı örneğiydi ve buna bağlı olarak belirli avantajları vardı. Bu, verimsizlikten avantaj elde etmenin bir örneği olabilir. Ancak bu, her durumda geçerli bir strateji olmayabilir.McCarthy'nin orijinal Lisp makalesinde tanımlanan 'eval' fonksiyonuna oldukça benzeyen bir ""metadairesel"" yorumlayıcı olan Common Lisp hakkında konuşalım biraz. Bu dil, sadece birkaç yüz satır koddan oluşuyordu ve bu da onu anlaması ve değiştirmesi çok kolay bir dil haline getiriyordu. Kullandığımız Common Lisp, CLisp, kendisi bir bayt kodu yorumlayıcısının üzerinde çalışıyordu. Dolayısıyla, biri (en üstteki) inanılmaz derecede verimsiz olan iki seviyeli bir yorumlama durumu vardı, ama dil yine de kullanılabilir durumdaydı. Belki tam anlamıyla kullanılabilir değildi, kabul ediyorum, ama yine de kullanılabilir durumdaydı.

Yazılımı birden çok katman halinde kodlamak, uygulamalar bile olsa, oldukça etkili bir tekniktir. Aşağıdan yukarıya programlama demek, bir programı çeşitli katmanlar halinde yazmak demektir, burada her bir katman kendisinden bir üstteki katmana bir dil oluşturur. Bu yaklaşım genellikle daha küçük ve daha esnek programlar üretir. Ayrıca, bu yaklaşım o çok arzulanan 'yeniden kullanılabilirlik' hedefine ulaşmanın da en iyi yoludur. Bir dilin tanımı gereği yeniden kullanılabilir olduğunu unutmayın. Uygulamanızı, belirli bir uygulamanın yazılması için bir dil oluşturabilecek seviyede aşağı çekebilirseniz, yazılımınızın çok daha büyük bir kısmı yeniden kullanılabilir hale gelir.

Nesne tabanlı programlamaya yeniden kullanılabilirlik fikri 1980'lerde bir şekilde yapıştı ve ne kadar aksi kanıtlansa da bu fikir kolay kolay çıkmıyor. Ancak, bazı nesne tabanlı yazılımların yeniden kullanılabilir olmasının sebebi, nesne tabanlı olmalarından ziyade, alttan yukarıya inşa edilmiş olmalarıdır. Kütüphaneleri düşünün: İster nesne tabanlı ister başka bir tarzda yazılmış olsunlar, onlar bir 'dil' oldukları için yeniden kullanılabilirler.

Bu arada, nesne yönelimli programlamanın yok olacağını tahmin etmiyorum. İyi programcılara belirli alanlar dışında pek bir katkısı olduğunu düşünmesem de, büyük organizasyonlar için oldukça çekici. Nesne yönelimli programlama, karmaşık kod yazmayı sürdürebilir hale getiriyor. Programlarınızı bir dizi yama gibi biriktirmenize olanak sağlar. Büyük organizasyonlar her zaman bu şekilde yazılım geliştirirler ve bu durumun yüz yıl sonra da bugünkü kadar geçerli olacağını tahmin ediyorum.

Geleceği konuşuyorsak, paralel hesaplamadan da bahsetmeliyiz, çünkü bu fikir genellikle orada yer alıyor. Yani, ne zaman konuşursanız konuşun, paralel hesaplamanın gelecekte gerçekleşecek bir şey olduğunu görürüz.

Gelecek bir gün ona yetişebilecek mi? En az 20 yıldır, paralel hesaplamanın kapıda olduğu söyleniyor. Ancak bu durum, programlama pratiğini çok da etkilemiş gibi görünmüyor. Ya da belki de etkiledi mi? Şimdiden çip tasarımcılarının bu durumu göz önünde bulundurması gerekiyor. Aynı şekilde, çoklu işlemcili bilgisayarlarda sistem yazılımı oluşturmaya çalışanların da bu durumla ilgilenmesi gerekiyor.

Asıl soru, paralelliğin soyutlama basamaklarında ne kadar yukarı çıkacağı. Bir yüz yıl sonra hatta uygulama geliştiricilerini bile etkiler mi dersiniz? Yoksa bu, derleyici yazarlarının düşündüğü, ancak genelde uygulamaların kaynak kodunda görünmeyen bir durum mu olur?

Bir şey neredeyse kesin: çoğu paralel işlem fırsatı kaçırılacak. Bu, daha genel bir tahminimin özel bir örneği aslında: ekstra bilgisayar gücünün çoğu boşa harcanacak. Tıpkı altta yatan donanımın nefes kesici hızı gibi, paralel işlemlerin de, eğer açıkça talep ederseniz mevcut olacağını ama genellikle kullanılmayacağını düşünüyorum. Bu da demek oluyor ki, önümüzdeki yüz yıl içinde, özel uygulamalar dışında, büyük ölçekli paralel işlemciliğin olmayacağını tahmin ediyorum. Sıradan programcılar için durum, paralel çalışacak bir dizi süreci ayrı ayrı başlatabilme hali olacak gibi görünüyor.

Bir programı optimize etmeye çalışırken, veri yapılarının belirli uygulamalarını istemek gibi, bunu da genellikle programın yaşamının oldukça ilerleyen bir aşamasında yaparsınız.Yazılım dünyasında, ilk sürümler genellikle verinin nasıl temsil edileceğine ya da paralel hesaplama yapmanın avantajlarına odaklanmaz. Bu, bazen gelecekteki potansiyeli göz ardı etmek anlamına gelebilir.

Ancak, paralellik genel olarak yüz yıl sonra yazılacak programların çoğunda kendine yer bulmayacak gibi görünüyor. Bu, erken aşamada yapılan bir optimizasyonun gereksiz olabileceği anlamına geliyor.

Peki, yüz yıl sonra kaç programlama dili olacak? Son zamanlarda, yeni programlama dilleri patlama yapmış durumda. Bunun nedeni, daha hızlı donanımın, programcılara hız ve rahatlık arasında dengeleme yapma olanağı sunması. Eğer bu bir trend ise, yüz yıl sonra kullanacağımız donanım bu trendi sadece daha da güçlendirecek.

Belki de yüz yıl sonra sadece birkaç dil yaygın olarak kullanılıyor olacak. Bu öngörümün bir nedeni de iyimserlik: Eğer işinizi gerçekten iyi yaparsanız, yavaş bir ilk versiyon yazmak için ideal olan bir dil yaratabilirsiniz. Aynı zamanda, doğru optimizasyon tavsiyeleriyle derleyiciye yol gösterildiğinde, gerektiğinde çok hızlı kodlar üretebilirsiniz. Bu yüzden iyimserim ve kabul edilebilir ve maksimum verimlilik arasında büyük bir boşluk olmasına rağmen, bir yüz yıl sonraki yazılımcıların bu boşluğun büyük bir kısmını kaplayabilecek dillere sahip olacağını tahmin ediyorum.

Bu fark arttıkça, profil oluşturucuların önemi çok daha belirgin hale gelecek. Şu anda profil oluşturmaya pek önem verilmiyor. Birçok kişi hala, hızlı uygulamalar elde etmenin yolunun hızlı kod oluşturan derleyicilerden geçtiğine inanıyor. Ancak, kabul edilebilir ve maksimum performans arasındaki fark genişledikçe, hızlı uygulamalar elde etmek için birinden diğerine iyi bir rehberliğin gerekliliği daha da belirgin hale gelecektir.

Sadece birkaç dil olabileceğini söylerken, belirli alanlara özgü ""minik dilleri"" kastetmiyorum. Bu tür gömülü dillerin harika bir fikir olduğunu düşünüyorum ve bunların sayısının artacağını tahmin ediyorum. Ancak kullanıcıların altındaki genel amaçlı dili görebilecekleri kadar ince bir şekilde yazılmalarını bekliyorum.

Geleceğin dillerini kim tasarlayacak? Son on yılın en heyecan verici gelişmelerinden biri, Perl, Python ve Ruby gibi açık kaynaklı dillerin yükselişi oldu. Dil tasarımı artık hackerların eline geçiyor. Şu ana kadar elde edilen sonuçlar biraz karışık olabilir ama yine de umut verici. Perl'de örneğin bazı çarpıcı derecede yenilikçi fikirler var. Evet, birçokları çarpıcı derecede kötü olabilir ama bu her zaman hırslı çabaların doğasıdır. Şu anki evrim hızıyla, Perl'in yüz yıl içinde neye dönüşeceğini tahmin etmek neredeyse imkansız.

Yapamayanların öğrettiği söylenir ama bu doğru değil (tanıdığım bazı en iyi programcılar profesörler). Ancak öğretenlerin yapamadığı birçok şey olduğunu kabul etmeliyiz. Araştırma, çeşitli sınıfsal kısıtlamalar getirir. Her akademik alanda üzerinde çalışabileceğiniz kabul görmüş konular vardır ve tabu olanlar da mevcuttur. Ne yazık ki, kabul edilen ve tabu konular arasındaki ayrım genellikle, konunun araştırma makalelerinde ne kadar entellektüel göründüğüne dayanır, ki bu durum iyi sonuç almanın öneminden daha baskın olur. Bu durumun en uç örneği belki de edebiyattır; edebiyat üzerine çalışan akademisyenler genellikle edebiyat üretenler için en ufak bir fayda sağlayacak bir şey söylemezler.

Bilimlerde durum biraz daha iyi olsa da, yapmanıza izin verilen iş türleri ile iyi bir dilin ortaya çıkması için gereken iş türleri arasındaki örtüşme ne yazık ki oldukça az. (Bu konuda Olin Shivers oldukça etkili bir şekilde serzenişte bulunmuştu.) Örneğin, tiplemeler, statik tiplemenin -ki bana göre gerçek makrolar olmadan hiçbir dilin kullanışlı olmadığı- varlığına rağmen, neredeyse tükenmez bir araştırma makalesi kaynağı gibi görünüyor.

Eğilim, dillerin sadece ""araştırma"" olarak değil, açık kaynak projeleri olarak geliştirilmesine yönelik değil, aynı zamanda bu dilleri kullanmak zorunda olan uygulama geliştiricileri tarafından tasarlanmasına yönelik. Yani artık derleyici yazanlar yerine, uygulama geliştiriciler dili tasarlıyor.Bence bu trend harika ve gelecekte de devam edecek gibi görünüyor. 

Fizik bilimini yüz yıl sonrasını tahmin etmek neredeyse imkansız olsa da, dil tasarımı konusunda düşündüğümüzde, yüz yıl sonra bile kullanıcıların ilgisini çekecek bir dil oluşturmak mümkün olabilir. 

Bir dil tasarlamak, istediğiniz programı yazmakla aynıdır. Hiçbir sınırlama olmadan, onu çevirebilecek bir derleyici ya da çalıştırabilecek bir donanım olup olmadığına bakmaksızın yazarsınız. Bu şekilde düşündüğünüzde, sınırsız kaynaklara sahip olduğunuzu varsayabilirsiniz. Bugün olduğu gibi, yüz yıl sonra da sınırsız kaynaklara sahip olma hayal gücümüzün olması gerektiğini düşünüyorum.

Hangi programı yazmak isteriz? Elbette en az emek harcayacağımızı. Ama tam olarak öyle demek de doğru değil. Aslında en az emek harcayacağımız program, programlama hakkındaki düşüncelerimizin şu an alışkın olduğumuz diller tarafından etkilenmediği durumda ortaya çıkar. Bu tür bir etkilenme o kadar yaygındır ki, onu aşmak büyük bir çaba gerektirir. Bizim gibi tembel varlıkların bir programı en az çabayla nasıl ifade edeceğini açıkça anlaması gerekir diye düşünebilirsiniz. Ancak, aslında, neyin mümkün olduğuna dair fikirlerimiz genellikle hangi dilde düşündüğümüze bağlı olarak o kadar sınırlıdır ki, programların daha kolay ifade edilme şekilleri genellikle bizi hayrete düşürür. Bunlar, doğal olarak içine dalınan bir şey değil, keşfedilmesi gereken bir konudur.

Burada işinizi kolaylaştıracak bir numara, programın uzunluğunu yazmak için ne kadar emek harcamanız gerektiğinin bir göstergesi olarak kullanmaktır. Elbette burada karakter sayısından bahsetmiyorum, daha çok birbirinden farklı sözdizimsel öğelerin sayısından - temelde ayrıştırma ağacının büyüklüğünden bahsediyorum. En kısa programı yazmak en az çaba gerektiriyor olmayabilir, ama genellikle en kısa olanı hedeflemekle, en az çabayı gerektiren biraz daha belirsiz hedefe ulaşmaktan daha iyi sonuçlar alıyorsunuz. O zaman dil tasarımı için algoritma şöyle olabilir: bir programa bakın ve şunu sorun, acaba bunu daha kısa bir şekilde yazmanın bir yolu var mı?

Pratikte, hayali bir yüz yıl sonraki dilde program yazmanın başarısı, temel kodlara ne kadar yakın olduğunuza bağlı olarak değişir. Mesela sıralama rutinlerini hemen bugün yazabilirsiniz. Ancak, yüz yıl sonra hangi türde kütüphanelere ihtiyaç duyulacağını şimdiden tahmin etmek zor olacaktır. Muhtemelen birçok kütüphane, belki de daha şimdiden var olmayan alanlar için gerekecektir. Örneğin, SETI@home projesi başarılı olursa, uzaylılarla iletişim kurmak için kütüphanelere ihtiyaç duyacağız. Tabii ki uzaylılar yeterince ilerlemişse ve zaten XML ile iletişim kurabiliyorlarsa, bu durum değişebilir!

Öteki uçta, belki de bugün ana dilin tasarlanması mümkün olabilir. Hatta, bazıları bunun aslında 1958'de zaten neredeyse tamamlanmış bir tasarım olduğunu söyleyebilir.

Eğer bugün elimizde yüz yıl önceki bir dil olsaydı, onunla programlama yapmak ister miydik? Bu soruya yanıt vermenin bir yolu da aynı durumu geçmişe taşımak. Diyelim ki 1960 yılında bugünün programlama dilleri olsaydı, acaba insanlar onları kullanmak ister miydi?

Bazı açılardan, cevap hayır. Bugünkü diller, 1960'larda hiç olmayan bir altyapı üzerine kurulu. Mesela, Python gibi girintinin önemli olduğu bir dil, yazıcı terminallerinde çok iyi çalışmazdı. Ama bu tür sorunları bir kenara koyarsak, örneğin tüm programların kağıt üzerinde yazıldığını varsayarsak, acaba 1960'ların programcıları bugünkü dillerle program yazmayı sever miydi?

Bence evet. Daha az yaratıcı olan ve erken dönem dillerinin kalıntılarıyla programlama düşüncelerini şekillendiren bazıları belki zorluk yaşayabilirdi. (İşaretçi aritmetiği olmadan veri nasıl değiştirilir?)""Gotosuz akış şemaları nasıl uygulanır?"" diye sorduğunuzda, aklıma hemen programlama dünyasının dehası olan bazı insanlar geliyor. Eğer bu zekalar bugünkü dilleri kullanmak zorunda kalmadan önce yaşasalardı, eminim bu dillerin tüm avantajlarını en iyi şekilde kullanabilirdi. 

Düşünsenize, eğer şu anda yüz yıllık bir dilimiz olsaydı, en azından harika bir pseudocode oluşturabilirdik. Ama bu dili yazılım yazmak için kullanmayı düşünün! Eğer bu yüz yıllık dil, bazı uygulamalar için hızlı kod üretmesi gerektiğini varsayarsak, donanımımızda kabul edilebilir seviyede çalışacak verimli bir kod oluşturabilme potansiyeli olabilir. Belki yüz yıl sonraki kullanıcılardan daha çok optimizasyon önerisi sunmamız gerekebilir, ancak yine de net kazanç sağlarız.

Şimdi, birleştirildiğinde ilginç olasılıklar sunan iki fikrimiz var: (1) aslında, bir yüz yıl dilini bugün tasarlayabiliriz ve (2) varsa, bu dilin bugün programlamak için iyi bir seçenek olabileceği. Bu fikirleri bu şekilde düşündüğünüzde, neden hemen şimdi yüz yıl dilini yazmayı denemeyelim ki, diye düşünmemek elde değil.

Dil tasarımı üzerinde çalışırken, belirli bir hedef belirlemenin ve bunu bilinçli bir şekilde zihninizde canlandırmanın iyi bir şey olduğunu düşünüyorum. Araba kullanmayı öğrendiğinizde, size öğretilen prensiplerden biri aracınızı yol üzerindeki çizgilere göre değil, daha uzaktaki bir noktaya doğru hizalamaktır. Hatta önünüzdeki sadece on metreyi düşünüyor olsanız bile bu yaklaşım, hep doğru olacaktır. Bence biz de programlama dilleri için aynı stratejiyi uygulamalı ve bu şekilde hareket etmeliyiz.

#### Notlar

Bana göre, Lisp Machine Lisp, bildirimlerin (dinamik değişkenler hariç) sadece bir optimizasyon tavsiyesi olduğu ve bir programın doğru anlamını değiştirmeyeceği ilkeyi ilk benimseyen dil oldu. Bu durumu açıkça belirten ilk dil ise sanırım Common Lisp oldu.

**Özel Teşekkürler**:Trevor Blackwell, Robert Morris ve Dan Giffin'e bu yazının taslaklarını okudukları ve geri bildirimde bulundukları için teşekkür ederim. Ayrıca, PyCon'da konuşmam için bana davetiye gönderen Guido van Rossum, Jeremy Hylton ve Python ekibinin tüm üyelerine de minnettarım.""""

---

İlişkili Konseptler: programlama dillerinin geleceği, programlama dillerinin evrimi, programlama dili tasarımı, programlama verimliliği, programlama dilleri ve donanım hızı, programlamada paralel hesaplama, açık kaynaklı diller, nesne yönelimli programlama, programlama dili aksiyomları, programlama dili çekirdeği, programlama dili optimizasyonu, programlama dili semantiği, programlama dili veri yapıları, programlama dili esnekliği, programlama dili yeniden kullanılabilirliği, programlama dili verimliliği, programlama dili özlülüğü, programlama dili altyapısı, yüz yıl dili."