Clojure: Rich Hickey
Clojure’un geliştiricisi Rich Hickey, başka bir Lisp lehçesi geliştirme tercihi, Clojure’un Java ve C# ile daha iyi rekabet edebilmesi için karşılaşılan zorluklar ve Clojure’un “ilk başvurulan” bir dil hâline gelmesini görme isteği hakkında Computerworld ile konuşmak için zaman ayırdı.
Clojure’un geliştirilmesine ne sebep oldu?
C++/Java/C# ile yaklaşık 20 yıl programlama yaptıktan sonra bundan yorulmuştum. Common Lisp’in ne kadar güçlü, dinamik ve ifade yeteneği yüksek olduğunu görmüştüm ve ticari geliştirme çalışmalarımda, JVM/CLR’yi hedefleyen bu çalışmalarımda, aynı güce sahip olmak istiyordum. Lisp ile Java arasında köprü kurmaya yönelik birkaç girişimde bulunmuştum, ancak hiçbiri tatmin edici değildi. Standart bir biçimde, standart platformlarda dağıtılabilen ve mevcut yatırımlarla çok sıkı bir bütünleşmeye sahip bir şeye ihtiyacım vardı.
Aynı zamanda, kariyerim boyunca bu OO dillerinde yayın otomasyon sistemleri gibi çok iş parçacıklı programlama yaptım ve acıdan başka bir şey görmedim. Kendimi savunma ve akıl sağlığımı koruma amacıyla, Java ve C# kodumu, değişmezliği vurgulayan, OO olmayan işlevsel bir tarza kaydırmıştım. Bunun, biraz garip ve dile özgü olmayan bir biçimde de olsa, oldukça iyi çalıştığını gördüm.
Dolayısıyla, JVM/CLR üzerinde yerel olan, dinamik, ifade gücü yüksek, işlevsel bir dil istiyordum ve böyle bir şey bulamadım.
Clojure adı nereden geliyor?
Bu, closure programlama yapısına yapılan bir kelime oyunudur (ve aynı şekilde telaffuz edilir). C (CLR), L (Lisp) ve J (JVM) harflerini içeren bir ad istiyordum. Arama sonuçları yoktu ve alan adı müsaitti – sevilmeyecek ne var?
Dilin çözmeyi hedeflediği belirli bir problem var mıydı?
Clojure, basit ve hızlı olan, sağlam programlar yazmayı desteklemek üzere tasarlanmıştır. Geleneksel OO dillerinde, hem sözdizimsel hem de anlamsal olarak o kadar çok tali karmaşıklık çekiyoruz ki, artık bunun farkına bile vardığımızı sanmıyorum. “Doğru olanı yapmayı” bir gelenek ve disiplin meselesi değil, varsayılan durum hâline getirmek istedim. Sağlam bir eşzamanlılık yaklaşımı ve mevcut Java kitaplıklarıyla mükemmel birlikte çalışabilirlik istedim.
Neden mevcut bir Lisp’i genişletmek yerine başka bir Lisp lehçesi geliştirmeyi seçtiniz?
Lisp’ler geleneksel olarak son derece genişletilebilir olsalar da, çekirdek veri yapıları için değişmezlik gibi bazı tasarım kararları almıştım ve bunlar mevcut Scheme ve Common Lisp programlarıyla geriye dönük uyumluluğu bozardı. Temiz bir sayfayla başlamak, pek çok şeyi farklı yapmama olanak tanıdı; bu önemliydi, çünkü Clojure’un yalnızca mevcut Lisp kullanıcılarına hitap etmesini istemiyordum. Sonuçta Clojure, Lisp geçmişi olmayanlar için çok farklı ve daha erişilebilir bir dildir.
Neden JVM’yi seçtiniz?
Başlangıçta hem JVM’yi hem de CLR’yi hedefledim, ancak sonunda her şeyi iki kez yapmak yerine iki kat daha fazla iş yapmak istediğime karar verdim. Etrafında çok daha büyük bir açık kaynak ekosistemi olduğu için JVM’yi seçtim ve bunun iyi bir tercih olduğu kanıtlandı. Bununla birlikte, CLR uyarlaması David Miller tarafından yeniden canlandırıldı, Clojure projesinin resmî bir parçasıdır ve JVM sürümüyle özellik eşitliğine yaklaşmaktadır.
Clojure-in-Clojure: kendi kendini barındırma, programlama dilleri için genellikle büyük bir dönüm noktasıdır – bu süreç nasıl gidiyor?
Her şey iyi gidiyor. Temel atma aşamasının sonuna yaklaşıyoruz. Clojure’un uygulanmasında yararlandığım, Java’nın Clojure’un kendisinde birebir karşılığı olmayan birkaç temel yeteneği vardı. Şimdi bunların sonuncusu da yerine oturuyor. Bundan sonra, Clojure derleyicisinin ve Clojure veri yapılarının Clojure’un kendisinde, özgün Java uygulamasıyla eşdeğer verimlilikte uygulanmasının önünde hiçbir engel kalmayacak.
Dili geliştirirken herhangi bir büyük sorunla karşılaştınız mı?
En büyük zorluklardan biri, Clojure’un Java ve C#’a uygulanabilir bir alternatif olabilmesi için yeterli performansa sahip kalıcı veri yapılarını doğru şekilde yapmak oldu. Bu olmadan devam etmezdim.
Hepimiz Richard Gabriel’in “Worse is Better”ın Yükselişi makalesini okuduk. Clojure gibi bir projenin bu tutumu tersine çevirmeye yardımcı olabileceğini düşünüyor musunuz?
Worse is Better’da ortaya konan argümanlar oldukça incelikli ve hepsini anladığımdan emin değilim, bu yüzden Clojure her iki tarafı da benimsemeye çalışıyor! Arayüzün ve uygulamanın sadeliğine değer veriyor. Bir çatışma olduğunda Clojure, pragmatizm tarafında hata yapmayı tercih eder. Sonuçta bu bir araçtır.
Çok çekirdekli CPU’ların yaygınlaşması ve hiper iş parçacığının yeniden yükselişiyle birlikte, eşzamanlı görevlerle uğraşmak artık daha önemli. Clojure bunu nasıl ele alıyor?
Eşzamanlılık için güçlü destek, Clojure’un merkezi özelliklerinden biridir. Bu, işlevsel programlamaya verilen önemle başlar. Clojure’daki tüm çekirdek veri yapıları değişmezdir; dolayısıyla en baştan itibaren, kilitleme ya da başka herhangi bir karmaşıklık olmaksızın iş parçacıkları arasında serbestçe paylaşılabilen verilerle çalışırsınız ve çekirdek kütüphane işlevleri yan etkilerden arındırılmıştır.
Ancak Clojure, zaman içinde değişen değerleri yönetme gereksinimini de kabul eder. Bunu, değerleri referanslar içine yerleştirerek destekler; bu referanslar hem durumlu doğalarını açıkça belirtir hem de dil tarafından yönetilen açık eşzamanlılık semantiklerini sağlar.
Örneğin, Clojure’daki referans kümelerinden biri işlemseldir; bu, bellek içi verilerinizle veritabanına benzer işlemler yürütmenize olanak tanır ve bir veritabanı gibi, birden fazla iş parçacığı aynı veri için yarıştığında atomik/tutarlı/yalıtılmış bütünlüğü otomatik olarak garanti eder. Her durumda, Clojure’un referans türleri, manuel kilitlemenin karmaşıklıklarından ve kilitlenmelerinden kaçınır.
Paralellik desteği ve yaklaşan Java ForkJoin çerçevesi hakkında bize neler söyleyebilirsiniz?
Eşzamanlılık birden fazla görevin koordinasyonuna odaklanırken, paralellik tek bir görevi bölerek bu çok çekirdeklerden yararlanıp sonucu daha hızlı elde etmeye odaklanır. Java eşzamanlılık uzmanları ForkJoin çerçevesi biçiminde bunu zaten yaptıkları için, Clojure’un içine paralellik için herhangi bir düşük seviyeli altyapı eklemedim; ForkJoin, paralel hesaplama için gelişmiş bir iş parçacığı havuzu ve iş çalma sistemidir.
Bu çerçeve olgunlaştıkça ve Java 7’ye dâhil edilmeye doğru ilerledikçe (ve Java 6 ile kullanılabilir oldukça), ForkJoin kullanarak bir işlevi bir vektör üzerinde alt görevlere bölerek eşleme gibi paralel algoritmaları uygulamaya başladım. Clojure’un veri yapıları bu tür bir ayrıştırmaya çok uygundur; bu nedenle mevcut veri yapıları üzerinde zengin bir paralel işlevler kümesi görmeyi bekliyorum — yani özel “paralel” veri yapıları kullanmanız gerekmeyecek.
Dağıtık sistemlerde çalışmaya ne dersiniz? MapReduce Lisp’ten çıkmıştı …
Dağıtımın genel amaçlı bir programlama dilinin içine sabitlenmesi gerektiğini düşünmüyorum. Clojure, JVM üzerindeki dağıtım için mevcut birçok seçeneği kullanabilir — JMS, Hadoop, Terracotta, AMQP, XMPP, JXTA, JINI, JGroups vb. — ve insanlar bunların birçoğundan hâlihazırda yararlanıyor.
Clojure için neden Eclipse Lisansı’nı seçtiniz?
EPL, birlikte kullanıldığı türev olmayan çalışmaları etkilemeden karşılıklılık sağlaması avantajına sahiptir. Bu nedenle ticari kullanıma dost ve işletmeler için kabul edilebilir olarak yaygın biçimde değerlendirilir.
Web çerçeveleri? “Compojure” adlı bir tane olduğunu fark ettim. Bunu Clojure’un büyüyebileceği bir yön olarak görüyor musunuz?
Kesinlikle. Clojure için birçok alanda hâlihazırda ilginç çerçeveler var. Clojure kütüphanelerinin güzel yanlarından biri, düşük seviyeli altyapı için kendini kanıtlamış Java kütüphanelerinden yararlanabilmeleri ve daha üst düzey kullanım ile esnekliğe odaklanabilmeleridir.
Clojure’u öğrenmek isteyenlere hangi kitapları önerirsiniz?
Stuart Halloway’in yazdığı, Pragmatic Programmers tarafından yayımlanan Programming Clojure, şu anda başlıca kitap ve oldukça iyi — özlü ve ilham verici. Şiddetle tavsiye ederim. Üzerinde çalışılan birkaç kitap daha olduğunu biliyorum.
Clojure ile yazılmış gördüğünüz en ilginç program(lar) hangileriydi?
Hakkında konuşamayacağımdan emin olmadığım, ilginç işler yapan birçok girişim var. Clojure, gençliğine rağmen son derece çeşitli alanlarda uygulanmış durumda — örneğin hukuki belge işleme, R benzeri bir istatistik dili ve bir veteriner hastanesinde mesaj yönlendirme sistemi.
Yakın zamanda Clojure 1.0’ı yayımladınız. Hangi özellikler sizi en çok heyecanlandırdı?
1.0 sürümü, yeni özelliklerden ziyade kararlılıkla ilgiliydi. Örneğin, özellik tabanı üretim çalışmaları yapmak için insanların büyük bir eksiklik hissetmeyeceği kadar yeterliydi ve Stuart’ın kitabı için bir temel oluşturabilirdi.
Projeyi GitHub’da barındırmak, katkıda bulunanların sayısını ve Clojure etrafındaki topluluğu artırmanıza yardımcı oldu mu?
Katkıda bulunanlar listesi istikrarlı biçimde büyüyor. GitHub’da olmanın, insanların katkılar üzerinde çalışmasını kolaylaştırdığını düşünüyorum.
Clojure üzerinde bir izin döneminde çalışmaya başladığınızı anlıyorum. Şimdi durum nasıl değişti?
Clojure üzerinde tam zamanlı çalışmaya devam etmek isterim, ancak bunu yapabilmek için bir gelir modeli bulmam gerekiyor. Henüz bunu çözdüğümü söyleyemem, fakat Clojure ticari olarak daha yaygın benimsendikçe daha fazla fırsat olmasını umuyorum.
Perl ustaları “Perl Mongers”, Python’cular “Pythonistas” olarak anılıyor. Clojure için de benzer bir şeye ihtiyaç olduğunu düşünüyoruz. Öneriniz var mı?
Herkesin “Clojurians” üzerinde uzlaştığını düşünüyorum.
Lisp programcıları ve iç içe listeler meselesi nedir?
Veri yapılarıyla programlama bazılarına yabancı gelebilir, ancak alışkanlık eşiğini aştıktan sonra ne kafa karıştırıcıdır ne de karmaşıktır. Denemeden önce değerini takdir etmesi zor olabilen, önemli ve değerli bir özelliktir.
Bu soru mutlaka sorulmalı … Arka arkaya gördüğünüz en yüksek kapanış parantezi sayısı nedir?!
Hangi parantezler?! Artık onları görmüyorum ve kısa bir süreden sonra çoğu Clojure geliştiricisi de görmüyor. Üst üste yığılmalarının bir avantajı, kodun dikey olarak daha yoğun hâle gelmesidir; böylece birçok satır kapanış }’si (Java vb.) ya da end’i (Ruby) yerine mantığın daha fazlasını tek bir ekranda görebilirsiniz.
Geriye dönüp baktığınızda, dilin geliştirilmesinde değiştirmek istediğiniz bir şey var mı?
Clojure’un tasarımının önemli bir bölümünün kullanımdan beslenmiş olması ve hâlen de öyle devam etmesi bence oldukça önemli. Süreçten ve sonuçtan memnunum.
Clojure’un geleceğini nerede görüyorsunuz?
Şu anda, girişimlerin ve ISV’lerin Clojure’u gizli bir silah ve güçlü bir araç olarak kullandığı erken benimseyenler aşamasındayız. Clojure genel amaçlı bir dildir ve şimdiden çok çeşitli alanlarda uygulanmaktadır. Tahmin etmek imkânsız, ancak dinamik geliştirmenin hızını sağlamlık, performans ve platform uyumluluğuyla birlikte istediğinizde başvurulan bir dil hâline gelmesini görmek beni çok mutlu ederdi.
Sizce Clojure’un kalıcı mirası ne olacak?
Hiçbir fikrim yok. İşlevsel programlama tarzının yaygınlaşmasında Clojure’un bir rol oynaması güzel olurdu.