Haskell

Simon Peyton-Jones ile Haskell’in geliştirilmesi hakkında sohbet ediyoruz. Peyton-Jones özellikle tembel fonksiyonel dillerin tasarımı, gerçekleştirilmesi ve uygulanmasıyla ilgileniyor ve ‘tek bir şeyi iyi yapmak’ arzusundan, ayrıca Birleşik Krallık’ın Cambridge kentindeki Microsoft Research’te yürütülen mevcut araştırma projelerinden ayrıntılı biçimde söz ediyor.

Haskell, yalnızca saf fonksiyonel programlama dilleri için açık bir standart olarak mı geliştirildi?

Haskell, ISO standartları anlamında bir standart değildir – aslında resmi olarak hiç standartlaştırılmamıştır. Başlangıçta, her birinin küçük farklarla birbirinden ayrılan kendi dillerine sahip olması yerine, ortak bir dili kullanmak isteyen bir grup insanın girişimi olarak ortaya çıktı. Eğer buna açık bir standart deniyorsa, o zaman evet, yapmaya çalıştığımız buydu.

1980’lerin sonlarında bir komite kurduk ve o aşamada proje tamamen akademik olduğu için dünyadaki ilgili tüm araştırmacıları davet ettik. Tembel fonksiyonel programlamayı kullanan şirketler yoktu ya da en azından çok azdı. Temel fonksiyonel programlama üzerinde çalışan ve tanıdığımız tüm araştırmacıları katılmaya davet ettik.

Yaklaştığımız araştırmacıların çoğu evet dedi; sanırım o aşamada hayır diyen muhtemelen tek kişi, Miranda adlı bir dili olan David Turner ile Clean adlı bir dili olan Rinus Plasmeijer’di. Plasmeijer başlangıçta komitedeydi ama sonra ayrıldı. Komite tamamen uzlaşmaya dayanıyordu – herhangi bir kişinin kimin dahil olup kimin olmayacağına karar verdiği bir mekanizma yoktu. İsteyen herkes katılabiliyordu.

İsim nasıl ortaya çıktı?

Hepimiz, büyük bir kara tahtası olan bir odada oturduk ve isim için olası adaylar olduğunu düşündüğümüz şeyleri yazdık. Daha sonra hepimiz sevmediğimiz isimlerin üzerini çizdik. İşimiz bittiğinde pek fazla isim kalmamıştı!

Oraya yazdığınız isimlerden herhangi birini hatırlıyor musunuz?

Eminim Fun ve Curry vardı. Curry, Haskell Curry’nin soyadıydı. Zaten adına ‘currying’ denilen bir süreci vermişti ve Curry yerine Haskell’i kullanmaya karar verdik; çünkü bununla ilgili yapılabilecek çok fazla şaka olacağını düşündük!

Peki Haskell isminde karar kılmanızı sağlayan neydi?

Bu aslında bir eleme süreciydi ve belirgin biçimde farklı olmasını sevdik. Paul Hudak, Curry’nin dul eşini ziyaret etti ve o da bize adını kullanmamız için nazikçe izin verdi. Tek dezavantaj, insanların ‘Haskell’ derken ‘Pascal’ı kastettiğinizi düşünebilmesi. Telaffuza bağlı – ve insanların kafasını karıştırmamak uzun sürmüyor.

Geliştirmenin erken aşamalarında büyük sorunlarla karşılaştınız mı?

Haskell projesi, tembel fonksiyonel programlama dilleri hakkında var olduğunu düşündüğümüz bir uzlaşmayı bir araya getirmeyi amaçlıyordu. Daha önce ana konular ve odak noktaları üzerinde anlaşmış olduğumuz için, büyük meseleler pek yoktu. Ayrıca özellikle ele almamaya karar verdiğimiz bazı şeyler de vardı: özellikle modüller. Haskell’in temel bir modül sistemi vardır ama en ileri düzey bir modül sistemi değildir.

Bunu ele almamaya neden karar verdiniz?

Çünkü bu iş karmaşık ve üç problemi kötü çözmektense tek bir problemi iyi çözmek istedik. Ana odak olmayan kısımlar için, olabileceği kadar sofistike olmasa bile, çalıştığı bilinen basit bir şey yapmayı düşündük. Bir dili tasarlarken kullanabileceğiniz beyin kapasitesi sınırlıdır ve onu iyi kullanmanız gerekir – dağın tepesine ulaşmak için sadece belli miktarda oksijeniniz vardır. Çok fazla şeye harcarsanız, zirveye ulaşamazsınız!

Ele almamaya karar verdiğiniz ana unsurlar modüller miydi, yoksa kaçındığınız başka unsurlar da var mıydı?

Bir diğer daha küçük konu kayıtlar (records) idi. Haskell çok basit bir kayıt sistemine sahiptir ve çok daha karmaşık birçok kayıt sistemi vardır. Bu oldukça karmaşık bir tasarım alanıdır. Kayıt sistemleri, çok fazla çeşitliliğin olduğu ve hangisinin en iyi olduğunun zor belirlendiği alanlardır. Bu yüzden yine basit bir şey seçtik.

İnsanlar bazen şikâyet edip ‘açıkça mantıklı olan şu şeyi yapmak istiyorum ve Haskell buna izin vermiyor’ diyorlar. Biz de şunu söylemek zorunda kalıyoruz: işte burası, çaba harcamamayı seçtiğimiz yerlerden biriydi. Ancak bu genellikle temel bir sorun değildir; çünkü başka bir yoldan etrafından dolaşabilirsiniz. Dolayısıyla bundan mutsuz değilim. Bu, yaptığımız ekonomik bir tercihti.

Yani bu kararları hâlâ destekliyor musunuz?

Evet. Kayıt sınırlamasının muhtemelen şu anda aşılması en kolay şey olacağını düşünüyorum, ancak bu aşamada Haskell o kadar yaygın kullanılıyor ki, tam kapsamlı bir kayıt sistemi eklemek muhtemelen oldukça zor olurdu. Ayrıca hâlâ bariz bir kazanan yok! Bugün bile ‘Haskell’de kayıtlar nasıl görünmeli?’ diye sorsanız, hâlâ net bir cevap yok.

Yeni modüllerin ve kayıt biçimlerinin dile eklenmesi sizce mümkün mü?

Haskell’e ML tarzı bir modül sistemi kesinlikle eklenebilir ve araştırma literatüründe bununla ilgili birkaç makale var. Bu, tüm dili önemli ölçüde daha karmaşık hale getirirdi, ancak bundan bazı önemli faydalar da elde edilirdi. Bence şu anda, kiminle konuştuğunuza bağlı olarak, bazı insanlar için bu Haskell ile ilgili en acil sorun olurken, diğerleri için olmayacaktır.

Şu anda, tam ölçekli bir modül uygulama sistemiyle Haskell’in gözden geçirilmiş bir sürümü üzerinde aktif olarak çalışan kimseyi tanımıyorum.

Bunun gerçekleşmesi sizce olası mı?

Bunun Haskell’e [yeni modüller ve kayıt biçimleri] eklenerek yapılacağından şüpheliyim. Ancak ML ve Haskell’in her ikisinin de halefi olacak bir dil ile yapılabilir.

Modüller gibi büyük ve yeni bir şeyin eklenmesinin pek olası olmadığını düşünüyorum. Çünkü Haskell zaten şu anda oldukça karmaşık; zaten karmaşık olan bir dile yeni ve karmaşık bir şey eklemek çok zahmetli olacaktır! Sonra insanlar ‘peki, Haskell’e bir modül sistemi uyguladınız. Güzel, sırada ne var?’ diyecekler. Akademik itibar puanları açısından bakıldığında ise, maalesef çok fazla kazanım sağlamaz.

2006 yılında Haskell 1998’in yerini alacak yeni bir standart bulma süreci başlatıldı. Şu anda bu süreç nerede? Ne gibi değişiklikler yapılıyor?

Haskell’98 bir kontrol noktası ya da donmuş bir dil belirtimi gibidir. Yani Haskell’in kendisi çeşitli biçimlerde gelişmeye devam etti, ancak Haskell’98 derseniz herkes neyi kastettiğinizi bilir. Haskell derseniz ise, birçok farklı şeyi kastediyor olabilirsiniz.

Özellikle ’98 sürümü neden donduruldu?

Çünkü insanlar Haskell hakkında kitap yazmak ve onu öğretmek istediklerini söylemeye başlamışlardı. Bu nedenle, güvenilebilecek ve benim gibi derleyici geliştiricilerinin bakımını sürdürmeyi garanti edebileceği bir sürümü dondurmaya karar verdik. Yani bir Haskell’98 programınız varsa, bunun 10 yıl sonra bile çalışması gerekir.

Bunu yapmaya karar verdiğimizde, ona Haskell’98 adını vermeye karar verdik. Elbette, 5 yıl sonra farklı bir şey de yapmış olabilirdik. Şu anda olan da bu; insanlar ‘Haskell’98’de olmayan dil özelliklerini kullanmak istiyorum ama aynı zamanda “markalı” ya da onay damgalı bir dil tasarımının getirdiği istikrarı da istiyorum – yani bunun değişmeyeceğini ve derleyicilerin desteklemeye devam edeceğini söyleyen türden’ diyorlar.

Dolayısıyla bu yine gayriresmî bir standartlaştırma çalışması – uluslararası komiteler yok, resmî oylama yok. Bu, çok daha karmaşık bir süreç olan C++ standardı gibi bir şey değil.

En son sürüm şu anda Haskell Prime (Haskell’) olarak adlandırılıyor. Bu aslında gerçek bir isim değil; henüz bir isim düşünmediğimizi söyleyen bir yer tutucu sadece!

Peki Haskell Prime nasıl gelişiyor?

Tüm bir dil belirtimini tasarlamak ve bunu belli bir ölçüde resmileştirmek ya da yazıya dökmek çok fazla emek gerektirir. Şu anda bence takılı kalmamızın nedeni, yeterince çok insan için bunun yeterince yüksek bir öncelik olmaması. Bu yüzden oldukça yavaş ilerliyor – işin özeti bu.

Bununla birlikte, bu durum beni çok fazla strese sokmuyor. İnsanlar, güvenebilecekleri titiz bir dil tasarımına yeterince önem vermeye başladıklarında, bu işe daha fazla çaba koyacaklarını ve önlerinde mevcut bir tasarım süreci ile tüm seçeneklerin açıkça ortaya konmuş olacağını düşünüyorum. Bunu bir başarısızlık olarak görmüyorum; yeterince güçlü bir talep olmadığının bir göstergesi olarak görüyorum. Belki de şu anda mevcut olan şey gayet iyi işliyordur.

Bunun bu noktaya gelmesinin bir yolu da, sorumluluğunu üstlendiğim derleyicinin (GHC ya da Glasgow Haskell Compiler) fiilî standart haline gelmiş olmasıdır. Bunu kullanan çok insan var, dolayısıyla GHC kullanıyorsanız programınız çalışacaktır.

Ancak ilke olarak, bir dilin bir uygulama tarafından tanımlanmasının iyi bir şey olduğunu düşünmüyorum. Haskell şu anda GHC’nin kabul ettiği şeye dayanıyor, ama bağımsız bir tanımı olmalı. Bu yüzden Haskell Prime’ın gerçekleşmesini istiyorum; çünkü dilin, belirli bir derleyicinin fiilî standardı tarafından tanımlanması yerine, bağımsız bir tanımının olmasının sağlıklı olduğunu düşünüyorum.

Sizce Haskell Prime sonunda bu noktaya ulaşacak mı?

Bilmiyorum. Bu, birisinin tüm dili geçersiz kılacak kadar çarpıcı yeni bir şey ortaya koymasından önce, bunun yapılmasına duyulan aciliyetin artıp artmayacağı meselesi.

Şu ana kadar buna benzer bir şey gördünüz mü?

Henüz hayır.

Görmeyi bekliyor musunuz?

Söylemesi zor. Benim deneyimime göre, diller neredeyse her zaman beklenmedik bir şekilde ortaya çıkar. Java ortaya çıkmadan önceki dönemi çok net hatırlıyorum (o zamanlar hâlâ Haskell üzerinde çalışıyordum) ve C++’ın ana akım programlama üzerindeki boğucu hâkimiyetinin asla kırılamayacağını düşünüyordum. Sonra Java geldi ve C++’ın bu hâkimiyetini kırdı!

Java geldiğinde, kimse bu yaklaşmakta olan ve umut vadeden dil hakkında yorumlar yapmıyordu; bir anda sahneye çıktı. Python da benzer şekilde son derece popüler hale geldi, ondan önce Perl de öyle, kimse stratejik olarak bunun bir sonraki büyük şey olacağını söylemeden. Sadece ortaya çıktılar ve pek çok insan kullanmaya başladı; Ruby on Rails’e benzer bir şekilde.

Çok ama çok sayıda programlama dili var ve bir sonraki büyük şeyin ne olacağını tahmin etme konusunda uzman değilim. Kimsenin bu konuda uzman olduğunu da düşünmüyorum.

Peki bunu neden söylüyorum? Çünkü yerleşik dilleri, hatta Haskell, ML veya Scheme gibi işlevsel programlama alanındaki dilleri bile, yerinden etmek için; sadece ilgi çekici ve insanların daha hızlı program yazmasını sağlayan bir dil yapmak yetmez. Aynı zamanda tam ölçekli uygulamaları kaldırabilen, çok sayıda kütüphaneye sahip, profilleyicilerle, hata ayıklayıcılarla ve grafiksel analiz araçlarıyla çalışabilen bir uygulamaya da ihtiyacınız vardır. Bir programlama diliyle birlikte gelen bütün bir ekosistem vardır ve bunu inşa etmek gerçekten çok zahmetlidir. Bunun anlamı, mevcut bu temelin yerini almanın oldukça zor olduğudur.

Soyut olarak düşünürseniz, muhtemelen Haskell ve ML’in özelliklerini bir halef dilde bir araya getiren bir dil tasarlayabilirsiniz, ancak bunu birinin yapıp yapmayacağı net değil; çünkü mevcut dillere büyük yatırımı olan tüm bu insanları ikna edip gemi değiştirtmeleri gerekir. İnsanları bu sıçramayı yapmaya ikna edecek kadar müthiş bir şeyin ne zaman ortaya çıkacağını bilmiyorum. Henüz olduğunu düşünmüyorum ve bunun birinin ‘bunu yapmaya karar verdim!’ demesiyle değil, daha organik bir şekilde olacağını düşünüyorum.

Haskell’in evriminden söz etmişken, Parallel, Eager ve Distributed Haskell gibi varyantlar ile Concurrent Clean hakkında ne düşünüyorsunuz?

Bunların hepsi çok iyi şeyler. Haskell’in amacı da budur. Haskell özellikle çeşitliliği teşvik eder. Haskell’98’e Haskell yerine bu adı vererek, Haskell marka adını pek çok şeye uygulanabilir halde bırakıyoruz. Adında ‘Haskell’ geçen her şey genellikle oldukça yakındır; genellikle Haskell’98’in bir uzantısıdır. En azından Haskell’98’i içermeyen ‘bir-şey-Haskell’ adlı bir şey bilmiyorum.

Bunlar, Java ile hiçbir ilgisi olmayan JavaScript gibi, sadece markası olan rastgele diller değildir. Sadece ismin üzerine binmişlerdir. ‘Java ise iyidir’ diye düşünmüşlerdir!

Bu dillerden herhangi birini kendiniz kullanıyor musunuz?

Evet. Concurrent Haskell GHC’de uygulanmıştır, dolayısıyla Concurrent Haskell kullanıyorum demek, aşağı yukarı eşzamanlılık uzantısı ile GHC kullanıyorum demektir. Data Parallel Haskell de GHC’de uygulanmaktadır, bu yüzden bu şeylerin çoğu aslında aynı derleyicide uygulanmıştır ve hepsi aynı anda kullanılabilir. Ayrı uygulamalar değillerdir.

Distributed Haskell, GHC’nin bir çatallanmış sürümüdür. Bazı eski sürümleri yalnızca İnternet ile birbirine bağlı birden fazla bilgisayarda çalışır. Başlangıçta GHC’nin sadece bir parçasıydı, ancak eşzamanlılık uzantılarıyla veya GHC’deki birçok yeni özellikle aynı anda kullanılamaz; çünkü Distributed Haskell bir çatallanmaktır. Başlangıçta aynı kod tabanına sahipti ama o zamandan beri ayrıştı. GHC’de yapılan tüm değişiklikleri alıp çatallanmış dağıtık dala uygulayamazsınız – bu işe yaramaz.

Concurrent Clean ise tamamen farklıdır. Tamamen farklı bir dildir; tamamen farklı bir uygulaması vardır. Haskell’den önce vardı ve Rinus Plasmeijer liderliğinde tamamen farklı bir ekip tarafından yürütülmektedir. Bir aşamada Haskell ve Clean’i birleştirebileceğimizi ummuştum, ancak bu gerçekleşmedi.

Clean çok ilginç ve iyi bir dildir. İçinde çok sayıda ilginç şey vardır.

İki dilin birleşebileceğini ne zaman düşündünüz?

İlk başladığımızda, çoğumuzun [Haskell komitesinin] henüz çok fazla yatırım yapmadığı küçük prototip dilleri vardı, bu yüzden tek bir dil oluşturmak için hepsinden vazgeçmeye hazırdık. Ancak Rinus’un Concurrent Clean’e daha fazla yatırım yapmış olduğunu düşünüyorum ve bu nedenle [Haskell’e] katılmamayı seçti. Bununla ilgili hiçbir tereddüdüm yok; çünkü çeşitlilik iyidir ve tek tip bir kültür istemeyiz, aksi halde o kadar çok şey öğrenemezsiniz.

Clean’in, Haskell’de hiç bulunmayan ve benzersiz türleme (uniqueness typing) olarak adlandırılan tamamen farklı bir özelliği vardır. Bunu Haskell’e entegre etmek oldukça zor olurdu. Dolayısıyla iki dili ayrı tutmak için iyi bir neden vardı. Bu da modüller gibi, büyük bir değişiklik olurdu. Çok sayıda yan etkisi olurdu ve bu yan etkilerin bedeline değeceğine tüm Haskell katılımcılarını ikna etmenin mümkün olup olmadığı net değildi. Yine ‘tek bir şeyi iyi yapmak’ meselesi.

Bu, dilin hedefi gibi görünüyor: tek bir şeyi yapmak ve onu iyi yapmak . . .

Evet. Doğru.

Çok çekirdekli CPU’lar ve kümeler gibi şeyler için dağıtık programlamada bir artış görüyoruz. Haskell’in bu değişikliklerle başa çıkma konusundaki konumunu nasıl görüyorsunuz?

Bence özellikle Haskell, ama genel olarak saf işlevsel programlama, bu konuda öncülük ediyor. Etkilerle ilgili zorluklar hakkında bir saatlik bir sunumum var – bu bağlamda etkiler aslında yan etkiler anlamına geliyor. Yan etkiler, girdi/çıktı yapmak, ya da değiştirilebilir bir bellek konumuna yazmak, ya da bellek konumunun değerini değiştirmek gibi şeylerdir.

Pascal veya Perl gibi normal bir dilde, sürekli olarak ‘x’e 3 değerini ata’ dersiniz; yani x daha önce 4 değerine sahipse, artık 3 değerine sahiptir. Dolayısıyla x, y ve z gibi adlar, zaman içinde değişebilen bir değer içerebilen bir konumun adlarıdır.

Saf işlevsel bir dilde ise x, asla değişmeyen bir değerin adıdır. Perl ya da Pascal’da bir yordam çağırdığınızda, o yordama hiç argüman geçmeyebilir ve hiçbir sonuç da almayabilirsiniz, ancak yordamı çağırma eylemi diske yazmasına ya da başka birçok değişkenin değerini değiştirmesine neden olabilir. Bu yordam çağrısına baktığınızda zararsız görünür, ama göremediğiniz yan etkileri vardır. Bunlar çağrının kendisinde görünmez, ancak yordamı çağırmanın pek çok etkisi vardır; zaten onu bu yüzden çağırırsınız. Hiçbir etkisi olmasaydı, onu hiç çağırmazdınız.

İşlevsel bir dilde bir f fonksiyonunu çağırdığınızda, ona bazı argümanlar verirsiniz ve o da bir sonuç döndürür. Yaptığı tek şey, argümanları tüketmek ve sonucu teslim etmektir. Hepsi bu – başka hiçbir yan etki oluşturmaz. Bu da onu paralel bir makinede paralel değerlendirme için gerçekten çok uygun kılar. Örneğin işlevsel bir dilde f(x)’i çağırıp sonra bu sonucu g(y)’ye eklerseniz, f’nin de g’nin de yan etkisi olmadığı için, bu çağrıları paralel olarak değerlendirebilirsiniz.

Ama geleneksel, ana akım bir programlama dilinde f, g’nin okuduğu bir değişken üzerinde yan etkiye sahip olabilir. f, perde arkasında g’nin baktığı bir değişkene yazabilir. Dolayısıyla önce f’yi sonra g’yi mi, yoksa önce g’yi sonra f’yi mi çağırdığınız fark oluşturur. Ve kesinlikle onları aynı anda çağıramazsınız.

Aslında bu gerçekten çok basit. Çağırdığınız fonksiyonlar perde arkasında hiçbir yan etkiye sahip değilse, yaptıkları tek şey kendilerine verdiğiniz girdi değerlerinden bir değer hesaplamaksa, o zaman bu tür iki şeyiniz varsa, onları aynı anda yapabileceğiniz açıktır. İşte bu saf işlevsel programlamadır. Ana akım diller, varsayılan olarak paralel değerlendirme için tehlikelidir. Saf işlevsel diller ise varsayılan olarak paralel değerlendirme için uygundur.

İşlevsel olmak, tembel ya da tembel olmayan fark etmeksizin, yan etki olmaması demektir. Perde arkasında bir şeyler karıştırmaz – füzeleri fırlatmaz, diske yazmaz. Dolayısıyla az önce bahsettiğim sunumun mesajı şudur: saf işlevsel programlama varsayılan olarak paralel programlama için güvenlidir, ana akım programlama ise varsayılan olarak tehlikelidir.

Bu, ana akım programlamayı dikkatli davranarak daha güvenli hale getiremeyeceğiniz anlamına gelmez; bunun için çok ama çok fazla teknoloji geliştirilmektedir. Ya programcının dikkatli olması gerekir ya da sistem tarafından bir şekilde desteklenir, ancak yine de paralel değerlendirmeye izin verme yönünde ilerlemek mümkündür.

Hareket ettiğiniz yön, hangi yan etkilerin ortaya çıkabileceği üzerinde daha hassas bir denetim elde etmekle ilgilidir. Fonksiyonel programlama dillerinin burada sunacak çok şeyi olduğunu düşünmemin nedeni, zaten tayfın öteki ucunda yer alıyor olmalarıdır. Ana akım bir programlama diliniz varsa ve tamamen olmasa bile saf fonksiyonel bir yöne doğru ilerlemek istiyorsanız, saf fonksiyonel dünyada neler olduğundan çok şey öğreneceksiniz.

Bence karşılıklı etkileşim için çok sayıda verimli fırsat var. Bu yüzden Haskell’in çok çekirdekli işler için iyi bir konumda olduğunu düşünüyorum; çünkü insanların giderek Haskell gibi dillere bakıp “en azından buradan bazı iyi fikirler edinebiliriz” diyeceklerini düşünüyorum; ister gerçekten benimsedikleri dil ya da somut sözdizimi olsun ister olmasın.

Bütün bunları söylemişken, saf fonksiyonel programlamanın gözyaşı dökmeden paralellik anlamına geldiğini de söylemiyorum. Rastgele bir fonksiyonel programı alıp bir derleyiciye vererek paralel çalışmasını bekleyemezsiniz. Aslında bu son derece zordur. Yirmi yıl önce bunu yapabileceğimizi düşünüyorduk, ancak bunun yan etkilerden tamamen farklı nedenlerle, daha çok granülerlik ile ilgili olduğu ortaya çıktı. Yapılacak çok, çok sayıda çok, çok küçük paralel iş elde etmek çok kolaydır; fakat o minicik işlerin hepsini yapmanın getirdiği ek yükler, paralelliğin sağladığı faydaları bastırır.

Fonksiyonel programcıların paralel programlamayı tamamen çözdüklerini iddia ediyormuş gibi görünmek istemem – bundan çok uzağız! Sadece sunulacak çok şey olduğunu ve dünyanın bir şekilde bu yöne doğru ilerleyeceğini düşünüyorum.

Belli ki yirmi yıl önce bir miktar öngörünüz vardı . . .

Bunun aşırı derecede ileri görüşlü olmamızla ilgili olduğunu düşünmüyorum – mesele sadece tek bir işi iyi yapmaktı.

Peki, şansınız olsaydı Haskell’in geliştirilmesi sırasında farklı yaptığınız bir şey olur muydu?

Bu zor bir soru. Elbette daha zeki davranabilirdik, ama geriye dönüp baktığımda bile farklı yapacağım büyük bir şey görebildiğimden emin değilim.

Peki Haskell ile yazılmış gördüğünüz en ilginç program hangisi?

Bu ilginç bir soru. İlk başta Haskell’in derleyicisi olan GHC diyecektim. Ama sanırım en ilginci, gerçekten dikkat kesilmeme neden olanı, Conal Elliot’ın FRAN adlı Functional Reactive Animation çalışmasıydı. Bu makaleyi [ICFP 1997’de] sahneye adeta bomba gibi düşen bir şekilde yazdı.

Bunun size sağladığı şey, grafik animasyonları tanımlayabilmekti; örneğin zıplayan bir top gibi. Bir topu ekranda nasıl zıplatırsınız? Bunun bir yolu, bir döngü içinde dolaşan bir program yazmak ve döngü her tur attığında topun bir zaman adımı daha ileride olup olmaması gerektiğini hesaplamaktır. Topun eski görüntüsünü siler ve yeni bir görüntü çizersiniz. Çoğu grafik bir şekilde böyle yapılır, ancak bunu doğru yapmak kesinlikle zordur.

Bunu yapmanın başka bir yolu ise, ekranı yeniden boyamak yerine, “işte bir değer var ve bu değer topun herhangi bir zamandaki konumunu tanımlar” demektir. Bir değer bunu nasıl yapabilir? Conal, “Bana sadece bir fonksiyon verin, üreteceğim değer zamandan konuma bir fonksiyon olacak. Bu fonksiyonu size verirsem, onu herhangi bir zamanda uygulayabilirsiniz ve topun nerede olduğunu söyler” dedi. Böylece ekranı yeniden boyama işi, “şimdi yeniden boyamaya hazırım, o halde bu fonksiyonu tekrar uygulayayım; bana bir görüntü versin ve onu çizeyim” diyen başka bir kod parçasına yeniden devredilebilir.

Dolayısıyla zaman içinde evrilen değerlere dair oldukça buyurgan bir kavramdan, topun herhangi bir zamandaki konumunu tanımlayan saf bildirime dayalı bir değer fikrine dönüştürdü. Bu basit fikre dayanarak Conal, çok sayıda güzel animasyonu ve dinamikleri, etrafta hareket eden ve birbirine çarpıp zıplayan şeyleri son derece basit ve zarif bir biçimde tanımlayabildi. Ve ben bunu hiç düşünmemiştim. Bir değerin ne olabileceğine dair fikrimi genişletti.

Beni şaşırtan şey, bunun bu şekilde yapılabileceğini hiç beklememiş olmamdı; aslında bunu hiç düşünmemiştim. Haskell dili, Conal’ın sofistike düşünceler geliştirmesine ve bunları bir programcı olarak ifade etmesine imkân tanımıştı ve bunun oldukça havalı olduğunu düşündüm.

Bu aslında oldukça sık olur; çünkü Haskell çok yüksek seviyeli bir programlama dilidir, dolayısıyla büyük düşünen insanlar onunla büyük işler yapabilir.

Bir dile ‘tembel’ dediğinizde neyi kastediyorsunuz?

Normalde bir fonksiyon çağırdığınızda, çağırma-değerine-göre ya da katı fonksiyonel bir programlama dilinde bile, önce argümanı değerlendirir, sonra fonksiyonu çağırırsınız. Örneğin f’i 3 + 4 üzerinde çağırdığınızda, ilk adımınız 3 + 4’ü değerlendirip 7 elde etmek olur, ardından f’i çağırır ve ona 7’yi geçirdiğinizi söylersiniz.

Tembel bir dilde ise 3 + 4’ü değerlendirmezsiniz, çünkü f bunu görmezden gelebilir; bu durumda 3 + 4’ü hesaplamak için yapılan tüm iş boşa gitmiş olur. Tembel bir dilde ifadeleri, fonksiyonu çağırdığınızda değil, değerlerine gerçekten ihtiyaç duyulduğunda değerlendirirsiniz – bu, gereksinime göre çağırmadır. Tembel bir kişi, yöneticisi “o rapora gerçekten şimdi ihtiyacım var” diyene kadar bekler; hevesli bir kişi ise raporu çekmecesinde hazır tutar, ama yöneticisi belki de onu hiç istemeyecektir.

Tembel değerlendirme, görevleri gerçekten yapmak zorunda kalana kadar ertelemekle ilgilidir. Ve bu, örneğin Haskell’i ML veya Scheme’den ayıran şeydir.

Tembel bir dilde, değerlendirme sırasını öngörmek çok daha zordur. Bu şey hiç değerlendirilecek mi, değerlendirilecekse ne zaman, yanıtlaması zor bir sorudur. Bu da girdi/çıktı yapmayı çok daha zor hale getirir. Temel olarak, fonksiyonel bir dilde bir ifade içinde girdi/çıktı yapmamalısınız, çünkü girdi/çıktı bir yan etkidir.

ML veya Scheme’de şöyle derler: “eh, çoğu zaman fonksiyoneliz, ama girdi/çıktı için fonksiyonel olmayacağız ve yan etkilere ve sözde fonksiyon olan şeylere izin vereceğiz.” Ancak bunlar gerçekten fonksiyon değildir, çünkü yan etkileri vardır. Yani f’i çağırabilirsiniz ve bir şey yazdırabilirsiniz ya da füzeleri fırlatabilirsiniz. Haskell’de ise f’i çağırırsanız füzeleri fırlatamazsınız; çünkü bu bir fonksiyondur ve hiçbir yan etkisi yoktur.

Kuramsal olarak, tembel değerlendirme, ML veya Scheme’in “eh, girdi/çıktı yan etkilerine izin verelim” yaklaşımını benimseyemeyeceğiniz anlamına gelir; çünkü bunların hangi sırayla gerçekleşeceğini bilemezsiniz. Füzeleri fırlatmadan önce mi silahlandırdığınızı, yoksa silahlandırmadan önce mi fırlattığınızı bilemezsiniz.

Haskell tembel olduğu için, dili saf tutma konusunda çok daha tutarlı olmamız gerekti. Saf, katı, çağırma-değerine-göre bir diliniz olabilir, ama kimse bunu başaramadı; çünkü katı çağırma-değerine-göre bir dile sahip olur olmaz, safsızlıklar (yan etkiler) ekleme cazibesi ezici olur. Bu yüzden slogan şudur: “tembellik bizi saf tuttu”!

Başka saf diller biliyor musunuz?

David Turner tarafından tasarlanan Miranda; onun da David Turner tarafından tasarlanmış birçok öncül dili var – hepsi saf. Lisp’in çeşitli alt kümeleri saf. Ama hiçbiri yaygın olarak kullanılmıyor. Ah, bir de Clean saf(!). Ama saf fonksiyonel programlama için Haskell kesinlikle marka lideri.

Tembel dillerin tembel olmayan dillere göre çok fazla avantajı olduğunu düşünüyor musunuz?

Sanırım genel denge açısından evet; tembelliğin birçok avantajı var. Ama bazı dezavantajları da var, bu yüzden mesele [saflık durumuna kıyasla] biraz daha nüanslı.

Tembel bir dil, “burada çağırma-değerine-göre kullan” demenin yollarına sahiptir; hatta “dil çağırma-değerine-göre katı olmalı” (tembelin zıttı) deseniz bile, yine de tembellik elde etmenin yollarını isterdiniz. [Haskell’in] herhangi bir ardıl dili hem katı hem de tembel fonksiyonlar için destek sunacaktır. O zaman soru şudur: varsayılan hangisi ve bunlara ulaşmak ne kadar kolay? Bunları nasıl bir arada kullanırsınız? Dolayısıyla artık tamamen ya o ya bu durumu söz konusu değil.

Ama genel olarak evet, tembel yaklaşımı kullanmaktan kesinlikle çok memnunum; çünkü Haskell’i Haskell yapan ve onu saf tutan şey buydu.

Haskell’in saflığıyla çok gurur duyuyor gibisiniz

Mesele bu. Haskell’i farklı kılan şey bu. O bununla ilgili.

Haskell’in fonksiyonel programlama dilleri için bir standart oluşturma konusunda başarılı olduğunu düşünüyor musunuz?

Evet; yine ISO standardı anlamında bir standart değil, ama saf fonksiyonel diller için bir tür ölçüt veya marka lideri anlamında bir standart. Bu konuda kesinlikle başarılı oldu. Birisi “bana saf bir fonksiyonel programlama dilinin adını söyle” derse, Haskell dersiniz. Clean de diyebilirsiniz, ama Clean daha az yaygın.

Wikipedia’daki şu ifade gibi dil hakkındaki eleştirilere nasıl yanıt veriyorsunuz: ‘Haskell, birçok başka programlama dilinde bulunmayan pek çok gelişmiş özelliğe sahip olsa da, bu özelliklerin bazıları dili aşırı karmaşık ya da anlaşılması zor hale getirdiği gerekçesiyle eleştirilmiştir. Ayrıca, Haskell’in saflığından ve kuramsal köklerinden kaynaklanan şikâyetler de vardır’?

Kısmen bu bir zevk meselesi. Bir kişinin anlaması zor bulduğu şeyleri bir başkası zor bulmayabilir. Ama bu yine tek bir işi iyi yapmakla ilgilidir. Haskell gerçekten de bir tür uç yaklaşım benimsiyor: dil saf ve oldukça sofistike bir tür sistemine de sahip. Haskell’i fiilen gelişmiş tür sistemi fikirlerini keşfetmek için bir laboratuvar olarak kullandık. Bu da işleri karmaşık hale getirebiliyor.

Bence iyi bir nokta şu: Haskell bir laboratuvardır; fikirleri keşfetmek için bir laboratuvar. Gerçek uygulamalar için kullanılabilir olmasını amaçladık ve bence kesinlikle öyle ve giderek daha da öyle oluyor. Ancak, mümkün olan en fazla sayıda programcıya bir dil satmak isteyen bir şirket için bir ürün olarak tasarlanmadı; böyle bir durumda sözdizimini C’ye benzetmeye daha fazla özen gösterebilir ve karmaşık özellikler eklemeyi yeniden düşünebilirdiniz, çünkü insanları şaşırtmak istemezsiniz.

Haskell kesinlikle programcılar düşünülerek tasarlandı, ama ortalama bir C++ programcısı için tasarlanmadı. Bu zekâ meselesi değil, aşinalık meselesidir; C++ ya da Perl’den Haskell’e geçtiğinizde büyük bir zihinsel yeniden kablolama süreci yaşanır. Ve bu, özellikle karmaşık olduğu için değil, saf fonksiyonel bir dil olmasından kaynaklanır. Her saf fonksiyonel dil bu geçişi yapmanızı gerektirir.

Saf fonksiyonel bir programlama dili olacaksanız, bu acıya katlanmak zorundasınız. Bunun geleceğin yolu olup olmayacağı ve herkesin bunu yapıp yapmayacağı – bilmiyorum. Ama bazılarımızın bunu keşfetmeye çalışmasının değerli olduğunu düşünüyorum. Haskell’in ne olduğu konusunda özür dilemeden konuşuyorum – eğer saf fonksiyonel programlamayı öğrenmek istemiyorsanız ya da size rahat gelmiyorsa ya da onu öğrenmenin acısını yaşamak istemiyorsanız, bu sizin yapabileceğiniz bir tercihtir. Ama ne yaptığınız ve ne yapmaya çalıştığınız konusunda net olmak ve bunu çok açık, tutarlı ve sürekli bir şekilde yapmaya çalışmak değerlidir.

Haskell, en azından GHC ile birlikte, çok karmaşık hale geldi. İnsanlar özellikler önerdikçe, biz de bunları ekledikçe ve bunların diğer özelliklerle etkileşmesi gerektiğinden, dil giderek daha karmaşık bir hale evrildi. Bir noktada, belki de herhangi bir faninin kafasında tutamayacağı kadar karmaşık hale gelecek ve o zaman belki de yeni bir dilin zamanı gelmiştir – dillerin evrimi bu şekildedir.

Herhangi bir dilin, ister Haskell ister C++ olsun, bu noktaya ulaştığını düşünüyor musunuz?

Bilmiyorum. C++ da son derece karmaşık. Ama son derece karmaşık olan ve uzun ömürlü dillerin, onları seven, onlara aşina olan ve içinde çok fazla kod yazılmış büyük kullanıcı tabanları da olur.

C++ yakın zamanda ortadan kaybolmayacak. Haskell’in de yakın zamanda ortadan kaybolacağını düşünmüyorum; dolayısıyla karmaşıklığı dengelemek ve “peki, artık daha fazlasını yapmayacağız, bunu burada bitmiş sayıyorum, çünkü daha da karmaşık olmasını istemiyoruz” demek zor bir iş. Buna büyük bir mevcut yatırımı olan insanlar sonra “peki, şunu da yapabilir misiniz?” diye soruyor. Bu “şunu da yapma” isteği kısmen onlara faydalı olmak için, kısmen de benim araştırma yapma biçimim nedeniyle ortaya çıkıyor. Bir laboratuvarda oturuyorum ve insanlar “neden şunu yapmıyorsun?” diyor, ben de “aa, bunu denemek ilginç olur, bakalım ne çıkacak” diyorum.

Ama tüm değişiklikleri kayda geçirdiğimizde ortaya çok karmaşık bir şey çıkıyor; dolayısıyla Wikipedia’daki eleştiride kesinlikle doğruluk payı olduğunu düşünüyorum.

Yan bir soru olarak, sizi Microsoft Research’e çeken neydi? Bu geçiş Haskell çalışmalarınızı nasıl etkiledi?

Yaklaşık 17 yıl boyunca üniversitelerde çalıştım ve sonra Microsoft’a geçtim. Üniversitelerde çalışmaktan çok keyif alıyordum, ama Microsoft farklı bir şey yapma fırsatıydı. Arada bir hayatta değişiklik yapmanın iyi bir fikir olduğunu düşünüyorum. İçerik açısından kesinlikle bir değişiklik olacaktı, ama bu değişiklikten keyif aldım.

Microsoft’un araştırmaya karşı çok açık bir tutumu var ve taşınmadan önce bunu net bir şekilde anladığım konulardan biriydi. İyi insanları işe alıyorlar ve onları büyük ölçüde serbest bırakıyorlar. Bana ne yapmam gerektiği söylenmiyor; dolayısıyla Haskell ya da GHC üzerindeki çalışmalarım veya genel olarak araştırmalarım açısından, Microsoft’a geçmenin en büyük etkisi, öğretim yapmadığım ya da toplantılara gitmediğim için bunlara daha fazla zaman ayırabilmem oldu. Elbette bunların hepsi bir bakıma kayıptı ve öğretmenin de kendine özgü getirileri vardı.

Öğretimi özlüyor musunuz?

Pazartesi sabahı uyanıp da ders veriyor olmayı dilediğim olmuyor! Dolayısıyla sanırım onu teorik bir anlamda özlüyorum, yakın ve pratik bir anlamda değil. Hâlâ lisansüstü öğrencilerle danışmanlık yapıyorum. Microsoft verdikleri söze sadık kaldı. Ayrıca üniversitedeyken sahip olmadığım yeni fırsatlar da elde ediyorum; çünkü Microsoft güvenlik duvarının içinde geliştiricilerle genel olarak fonksiyonel programlama, özelde ise Haskell hakkında konuşabiliyorum; bunu daha önce hiç yapamazdım. Microsoft, neyi inceleyeceğime ve neyi yayımlayacağıma tamamen açık, dolayısıyla bu çok iyi bir araştırma ortamı – bildiğim tek bu tür araştırma laboratuvarı. Harika – sürekli bir izin döneminde olmak gibi.

Microsoft’un Haskell’i standart dili olarak kullanmasıyla ilgili şakanın bir gün gerçekleştiğini hiç düşündünüz mü? Haskell.NET?

Bunun iki cevabı var – ilki elbette evet, bu harika olurdu! Fonksiyonel programlamanın dünyaya sunacak gerçekten çok şeyi olduğunu düşünüyorum.

İkinci cevaba gelince, bunu biliyor musunuz bilmiyorum ama Haskell’in gayriresmî bir sloganı vardır: her ne pahasına olursa olsun başarıdan kaçının. Bunu birkaç yıl önce Haskell hakkında verdiğim bir konuşmada sanırım dile getirdim ve küçük bir deyiş haline geldi. Fazla tanınır, fazla yaygın ve fazla başarılı olduğunuzda (ve elbette Microsoft tarafından benimsenmek böyle bir şeydir), birdenbire artık hiçbir şeyi değiştiremez hale gelirsiniz. Sıkışıp kalır ve araştırma tarafıyla hiç ilgisi olmayan şeyler hakkında uzun zamanlar harcarsınız.

Ben öncelikle bir programlama dili araştırmacısıyım; bu yüzden Haskell’in şimdiye kadar yalnızca üniversite çevrelerindeki kişiler tarafından kullanılmış olması idealdi. Artık endüstride de yoğun biçimde kullanılıyor, ancak genellikle esnek insanlar tarafından ve çoğunlukla kendi kendini seçmiş, oldukça parlak bir grup söz konusu. Bunun anlamı şu: dili değiştirebilirdik ve şikâyet etmezlerdi. Ancak şimdi kütüphaneleri çalışmadığında şikâyet etmeye başlıyorlar; bu da aşırı başarılı olmanın tuzağına yakalanmaya başladığımız anlamına geliyor.

Aslında söylemeye çalıştığım şey şu: Haskell’in milyonlarca geliştirici tarafından kullanılan gerçek bir ana akım programlama dili hâline gelmemiş olması, bizim çok daha çevik olmamıza imkân tanıdı ve araştırma bakış açısından bu harika. Çok sayıda kullanıcımız var, dolayısıyla onlardan çok fazla deneyim elde ediyoruz. Araştırma açısından istediğiniz şey, çok sayıda kullanıcıya sahip olmak ama çok fazla da olmamak – bu yüzden de “her ne pahasına olursa olsun başarıdan kaçının.”

Ama diğer uçta, gerçekten ama gerçekten başarılı olmak ve Microsoft tarafından benimsenmek de muhteşem olurdu. Aslında koridorun aşağısındaki meslektaşım Don Syme’ı biliyor olabilirsiniz; bir dil tasarladı: F#. F#, Haskell ile C# arasında bir yerde duruyor – bir Microsoft dili, açıkça fonksiyonel ama saf değil ve tanımlayıcı hedefi bir .NET dili olmak. Bu nedenle .NET’ten gelen ve değiştirilemeyen pek çok avantajı ve aynı zamanda tasarım tercihini üstleniyor. Bunun bulunulabilecek harika bir tasarım noktası olduğunu düşünüyorum ve Don’un bunu yapmış olmasından, ayrıca bunu başarılı bir şekilde bir ürüne dönüştürmesinden son derece mutluyum – bir bakıma da üzerimdeki baskıyı azaltıyor, çünkü artık Microsoft ürünü olan bir fonksiyonel dil var!

Dolayısıyla ben de araştırma yapma ve orta düzey başarı yaklaşımını sürdürme konusunda özgürüm.

A–Z of Programming Languages serisindeki yaklaşan bir röportajda Don’la konuştuğunuzda, sanırım Haskell’den çok fazla ilham aldığını söylediğini duyacaksınız. Bazı fikirler Haskell’den F#’a geçti ve fikirler, somut sözdizimi, gerçekleştirim ve ince ayrıntılı tasarım tercihlerine kıyasla çok daha kolay göç edebiliyor.

Haskell eğitim amaçlı olarak çok kullanılıyor. Eski bir öğretim görevlisi olarak bundan memnun musunuz ve bunun neden böyle olduğunu düşünüyorsunuz?

Fonksiyonel programlama, program yazma işinin tamamına farklı bir bakış açısı kazandırır. Her lisans öğrencisinin fonksiyonel program yazmayı öğrenmesini istiyorum. Bunu yapacaksanız da Haskell mi, ML mi yoksa Clean mi öğreteceğinize karar vermeniz gerekir.

Benim tercihim Haskell olurdu, ancak bence en önemli şey, bir biçimde saf fonksiyonel programlamayı öğretmenizdir; çünkü bu sizi daha iyi bir buyurmalı programcı yapar. C++’a geri dönecek olsanız bile, fonksiyonel programlamaya aşina olursanız daha iyi C++ yazarsınız.

Kişisel olarak çok sayıda öğrenciye Haskell öğrettiniz mi?

Hayır, aslında öğretmedim! Glasgow’dayken tamamen birinci sınıf Ada öğretimiyle meşguldüm; çünkü o dönemde Glasgow’un birinci sınıfta öğrettiği dil buydu ve Glasgow, her kıdemli profesörün birinci sınıf öğrencilerine ders vermesi gerektiği görüşünü benimsiyordu; çünkü bunlar heyecanlandırılması ve en iyi şekilde muamele edilmesi gereken kişilerdi. Onları etkileme şansınızın en yüksek olduğu an da budur – ikinci sınıf dersine devam edecekler mi, etmeyecekler mi?

Ada öğretmekten keyif aldınız mı?

Evet, çok eğlenceliydi. Sonuçta hepsi bilgisayar bilimi ve 200 lisans öğrencisiyle bilişimin neden bu kadar eğlenceli olduğu üzerine konuşmak her zaman heyecan vericidir.

Tüm programcıların fonksiyonel program yazmayı öğrenmesi gerektiğini neden düşündüğünüze zaten değindiniz. Fonksiyonel programlamanın bir programcının kariyerinin bir aşamasında mı öğretilmesi gerektiğini düşünüyorsunuz, yoksa öğrenilen ilk şey mi olmalı?

Bilmiyorum – bu konuda çok güçlü bir görüşüm yok. Öğrencilerin neye katlanabileceği gibi pek çok ilişkili etken olduğunu düşünüyorum! Öğrenci motivasyonunun çok önemli olduğunu düşünüyorum; öğrencilerin daha önce adını duydukları bir dili ilk dil olarak öğretmenin güçlü bir motivasyon etkisi var.

Öte yandan, öğrenciler çok farklı deneyimlerle geldikleri için (bazıları yığınla programlama yapmışken bazıları hiç yapmamış oluyor), hiçbirinin aşina olmadığı bir dili öğretmek harika bir dengeleyici olabilir. Dolayısıyla bugün bir üniversitede olsaydım, birinci sınıf dili olarak fonksiyonel programlamanın öğretilmesi gerektiğini savunurdum; ama bunun “aksi düşünen ancak aptal olur” türünden kesin bir şey olduğunu da düşünmüyorum!

Bazıları Haskell’de standart IO ile uğraşmanın bekledikleri kadar “fonksiyonel” hissettirmediğini söylüyor. Siz ne düşünüyorsunuz?

Aslında fonksiyonel değil – IO, tartıştığımız gibi bir yan etkidir. IO, füzelerin fırlatılmasını sağlar: şimdi yap ve bu sırayla yap. IO, belirli bir sırada yapılması gerektiği anlamına gelir; yani şunu yap, sonra bunu yap dersiniz ve dünyanın durumunu değiştirirsiniz. Füzeleri fırlatmak açıkça bir yan etkidir; bunun başka bir yorumu yok.

Saf bir fonksiyonel programınız varsa, prensipte yapabileceği tek şey bir değer alıp sonuç olarak bir değer üretmektir. Haskell ilk ortaya çıktığında, yaptığı tek şey bir karakter dizisini alıp bir karakter dizisi üretmekti. Sonra “bu pek havalı değil, bununla füzeleri nasıl fırlatacağız?” diye düşündük. Ardından “ha, belki bir dize yerine, dış dünyaya füzeleri fırlatmasını ve diske yazmasını söyleyen bir komutlar listesi üretebiliriz” dedik. Bu da sonuç değeri olabilirdi. Hâlâ bir değer üretmiş oluyorduk – komutlar listesi – ama yan etkileri sanki başka biri yapıyordu; dolayısıyla biz hâlâ kutsal ve saftık!

Sonraki zorluk ise, “bir dosya oku” diyen bir değer üretmek ve dosyanın içeriğini programın içine almak oldu. Bunu yapmanın bir yolunu yazdık, ama bana her zaman biraz tatmin edici gelmedi ve bu da bizi monadlar fikrini geliştirmeye itti. Monadlar, IO’yu Haskell’in içine yerleştirme yolunu sağladı; yan etkiler içerse bile fonksiyonel bir programa sahip olmanızı mümkün kılan çok genel bir fikirdir. Saf fonksiyonel programlamanın etki olmadığı anlamına geldiğini söylüyordum; ancak monadlarla programlama, etkili olan program parçalarıyla saf olan parçaları birbirine karıştırmadan bir arada kullanmanıza olanak tanır. Yani birini ya da diğerini seçmek zorunda kalmazsınız.

Ama sorunuza dönersek, monadlar kullanılarak yapılan IO hâlâ saf fonksiyonel programlama gibi görünmez ve görünmemelidir; çünkü değildir. Bu monadik programlamadır; güzelce ayrı tutulur ve fonksiyonel kısımla harika biçimde bütünleşir. Dolayısıyla sanırım fonksiyonel hissettirmemesinin doğru olduğunu söylemek gerekir; çünkü fonksiyonel değildir ve olmamalıdır.

Haskell’in dünyaya kazandırdığı şey, içinde fikirleri keşfetmek için bir laboratuvar olmasının yanı sıra, bu monadik fikirdir. Oldukça uzun bir süre IO’yu düzgün yapamama noktasında takılı kalmıştık. F#, saf olmayan bir dil olmasına ve dolayısıyla yan etkiler yapabilmesine rağmen, özünde monadlara sahiptir. Yine de Don, F#’a “iş akışları” adını verdiği bir şeyi aktardı; bu da monadlar için kullanılan nazik ve dostça bir addan ibaret. Bunun nedeni, F# saf olmasa bile monadların kendi başına yararlı bir fikir olmasıdır. Zorunluluk, buluşun anasıdır.

Yani monadlar sizin gözünüzde Haskell’in kalıcı mirası mı?

Evet, monadlar büyük bir mesele. Basit ve tutarlı bir fikirden, büyük ölçekli uygulamalar için gerçekten pratik bir şey ortaya koyabilme fikri saf fonksiyonel programlamadır. Bence Haskell’in yaptığı büyük şeylerden biri bu – bu noktada duruşumuzu korumak, gerçekten en mutlu olduğumuz şey.

Bir ürünü satmak zorunda olan biri yerine bir araştırmacı olmanın zevklerinden biri de duruşunuzu koruyabilmenizdir ve Microsoft bunu yapmama izin verdi.

Sizce Haskell’in geleceği nasıl görünecek?

Bilmiyorum. Tahminim, dilin, çok sayıda insan tarafından kullanıldığı hâliyle, yumuşak bir şekilde evrilmeye devam edeceği yönünde.

Şu anda üzerinde çalıştığım ana konu paralelliktir; özellikle çok çekirdekli sistemler ve Avustralya’daki University of NSW’deki bazı meslektaşlarla çalışıyorum. Onlarla “iç içe veri paralelliği” denilen bir şey üzerinde çok yakın çalışıyorum.

Haskell’in çeşitli biçimlerinde zaten çeşitli paralellik türleri var, ama bunların hiçbirinden memnun değilim. İç içe veri paralelliğinin, bir avuç yerine onlarca hatta yüzlerce süreci gerçekten kullanabilmem için en iyi umudum olduğunu düşünüyorum. Ve iç içe veri paralelliği, mutlak surette fonksiyonel bir programlama dili içinde olmayı gerektiriyor. Bunu buyurmalı bir dilde yapmanız mümkün değil.

Peki bu yolda ne kadar ilerlediniz? Bir miktar başarı elde ediyor musunuz?

Evet, bir miktar başarı elde ediyoruz. Yapması karmaşık ve gerçek bir araştırma riski var – hatta hiç başaramayabiliriz. Ama eğer başaracağınızdan eminseniz, muhtemelen bu araştırma değildir!

Bunun üzerinde birkaç yıldır çalışıyoruz. Birkaç ay içinde başkalarının da üzerinde çalışabileceği prototiplere sahip olmalıyız, ancak gerçekten iyi çalışıp çalışmadığını bilmemiz için bir iki yıl daha geçmesi gerekecek.

Bu konuda oldukça umutluyum – oldukça radikal bir derleyici teknolojisi parçası. Programları, programcı için geleneksel paralel programlamaya kıyasla çok daha kolay yazılacak bir biçimde yazmanıza imkân tanıyor. Derleyici programı ciddi biçimde sarsıp dönüştürüyor ve bilgisayarın çalıştırması kolay olan bir program üretiyor. Yani yazması kolay bir programdan, çalıştırması kolay bir programa dönüşüm sağlıyor. Buna böyle bakmak gerekir. Dönüşüm oldukça radikal – yapılacak çok şey var ve doğru yapmazsanız program çalışır ama olması gerekenden çok daha yavaş çalışır; oysa bütün mesele hızlı olmaktır. Bence bu radikal program dönüşümünü yapabilmek için mevcut tek şans [saf fonksiyonel programlama].

Daha uzun vadede, Haskell’in nereye gittiğini sorarsanız, bence fikirler alanında olacak ve nihayetinde diğer dil tasarımlarını bilgilendirecek. Haskell’in Java, C++ ya da C# gibi ana akım hâline gelip gelmeyeceğini bilmiyorum. Haskell’deki fikirlerin bile ana akım hâline gelmesi beni tamamen tatmin eder. Bunun daha gerçekçi bir hedef olduğunu düşünüyorum – dillerin yaygın biçimde benimsenmesinde çok fazla etken var – fikirler nihayetinde uygulamalardan daha kalıcıdır.

Peki dilin geliştirilmesi ve kullanımı açısından en çok neyle gurur duyuyorsunuz?

Sanırım artık tahmin edebilirsiniz! Saflığa bağlı kalmak, monadların ve tür sınıflarının geliştirilmesi. Tür sınıflarından henüz bahsetmedik bile. Haskell’in, tür sınıfları adı verilen bir yenilikle başlayan tür sistemi, son derece etkili ve başarılı olduğunu kanıtladı. Bu, en başından beri Haskell’de bulunan ayırt edici bir başarıdır. Ama o zamandan beri bile Haskell mükemmel bir tür sistemi laboratuvarı olduğunu gösterdi. Haskell’in başka hiçbir dilde olmayan pek çok tür sistemi özelliği var. Bunun daha da geliştirilmesi üzerinde hâlâ çalışıyorum ve bununla oldukça gurur duyuyorum.

Peki önümüzdeki 5–20 yıl içinde bilgisayar dillerinin nereye gideceğini düşünüyorsunuz? Büyük eğilimler vb. görebiliyor musunuz?

Yeniden etkilere dönüyoruz. Genel olarak programlamanın nereye gideceğini bilmiyorum, ama önümüzdeki 10 yıl içinde, bu zaman ölçeğinde, ana akım programlamanın etkilere – ya da yan etkilere – çok daha dikkatli yaklaşacağını düşünüyorum. Öngöreceğim tek dil eğilimi bu. Ve elbette bunun bile bir tahmin olduğunu söylemek gerekir; kristal küreye bakıyorum.

Özellikle, dillerin saf ya da safımsı alt kümeler geliştireceğini düşünüyorum. Ana buyurmalı dillerde bile, dilin bazı bölümleri saf olacak.

Tüm deneyimleriniz göz önüne alındığında, öğrencilere ya da yükselen programcılara ne tavsiye edersiniz?

Geniş bir programlama dili yelpazesi öğrenin ve özellikle bir fonksiyonel dil öğrenin. Eğitiminizin yalnızca bir kitap okumaktan ibaret olmadığından emin olun; gerçekten bazı fonksiyonel programlar yazın, çünkü bu, programlama işinin tamamı hakkında düşünme biçiminizi değiştirir.

Bu, kayak yapabilip hiç snowboard yapmamış olmaya benzer: snowboard’a çıkarsınız ve hemen düşersiniz. Başta insanların bunu yapamayacağını düşünürsünüz, ama snowboard yapmayı öğrendiğinizde, aynı şeyi yapmanın farklı bir yolu olduğunu görürsünüz. Programlama dilleri için de durum aynıdır ve bu köklü bakış açısı değişimi, zamanınızın çoğunu hangi programlama tarzında geçirirseniz geçirin, sizi daha iyi bir programcı yapar.

Sadece kitap okumak işe yaramaz; saf fonksiyonel bir program yazmanız gerekir. Snowboard hakkında bir kitap okumak da yeterli değildir – yapmanız ve vücudunuzu neler olup bittiğini anlayacak şekilde eğitene kadar defalarca düşmeniz gerekir.

Bugün benimle sohbet etmeye vakit ayırdığınız için teşekkürler. Eklemek istediğiniz başka bir şey var mı?

Bir şey daha ekleyeceğim.

Haskell’in bir başka ayırt edici özelliği de çok güzel bir topluluğa sahip olmasıdır. Topluluktan hiç bahsetmedik, ama Haskell’in etrafında son derece dostane bir ekosistem büyüyor. İnsanların son derece yardımsever olduğu bir e-posta listesi var, topluluk tarafından sürdürülen bir wiki’si var ve yüzlerce kişinin yardım etmek için bulunduğu bir IRC kanalı var.

İnsanlar sık sık, başka yerlerde yaşadıkları deneyimlerle karşılaştırıldığında buranın alışılmadık derecede dostça bir yer gibi göründüğünü söylüyorlar (ve bununla ilgili spesifik olamam, çünkü gerçekten bilmiyorum). Bunu neye bağlayacağımı bilmiyorum, ama Haskell topluluğunun yardımsever ve kucaklayıcı bir yer olarak böyle bir üne sahip olmasından çok memnunum. Alışılmadık derecede sağlıklı bir topluluk ve bunu gerçekten seviyorum.

---