d (programlama dili)

• syntax^* olarak c'ye benzeyen programlama dili. object oriented bir dildir. arrayler ve fonksiyonlar^* ile ilgili yenilikler^* getirir. ne kadar geli$eceği $u an kestirilemeyen dildir.
• http://www.digitalmars.com/d/comparison.html adresinden diger populer dillerle feature karsilastirmasi incelenebilen yeni bir programlama dili. 1.0 versiyonu 01.01.07 de release olmus.
  
  windows ve linux portu olan bir compileri veya gdc adinda bir gcc front-end'iyle geliyor.
  
  fikrimi sorarsaniz yazmaya degmeyen programlardan. built-in testing constructlari var falan diye anlatiyorlar ama efendim artik dil yazmiyoruz ki bitti o is, herkes yazdi hirsini aldi piyasa doydu insanlar baydi. ha yepisyeni bir programlama teknigi yok efendim soa tabanli dil olsa anlicam. yeni oo dil yazmisin. hadi onu yapamadin, bari dille beraber bir platform/frameworkle beraber ciksaydin ortaya.
  
  ayrica dilin sitesinde inanilmaz bir olay var. bir sure saka mi bu diye dusundum. download edip onbinlerce satir kodu gormez olaydim saka degilmis.
  http://www.digitalmars.com/d/index.html
  buradaki headliner yorumlara dikkat:
  
  "it seems to me that most of the "new" programming languages fall into one of two categories: those from academia with radical new paradigms and those from large corporations with a focus on rad and the web. maybe it's time for a new language born out of practical experience implementing compilers." -- michael
  
  bu michael d'yi gelistirenlerden biri. insandaki common sense/coding yetenegi ratiosu bu kadar mi 0 a yakin olur. "rad ve web odakli dil yapiyor herkes nedense ben yeni bisi yapacam" demis. nasil bir nefret hissettigimi anlatamiyorum. sonra da compiler ustune pratik tecrubesi olan birinin artik bu dil isine el atmasi gerekir demis ki inanamiyorum.
  
  stringleri 0 la terminate etmemisler bir de. etmemisler. printf calismiyor. printf calismiyor.
• dos icin ilk c++ compilerini yazan walter bright tarafindan gelistirilen yeni bir imperative programlama dili. cikis amaci java/c# gibi modern ancak c/c++ kadar makinaya yakin/performansa yonelik bir platform sunmaktir. kanimca programci verimi acisindan python-ruby gibi dinamik-derlenen dillere en cok yaklasan statik-derlenen dildir. teoride hersey iyi gibi gorunurken bu kadar gec ortaya cikisi, adam gibi bir frameworke sahip olmayisi gibi etkenler yuzunden bu saatten sonra piyasada yer etmesi imkansiz gibi gorunuyor.
• önüne iki nokta üst üstenin gelmediği halde, vernikli ilk okul sırasında otururken kara tahtada ilk gördüğümde, geniş zamanlı çocukluk hülyalarının klaideskop objektifinden hafızama not eylediğimde "en güleç hartir" olacığını anladığım alfabe beşincisi. en karizmatik olanıdır da aynı zamanda. daireni hemen üstünden yukarı doğru seyirten çıkıntısı, dudak imgesi yakıştırılan şeklin ironik/benbilirimci/iğneleyici/siklemeyici/testisci yanıdır. göz ardı edilemeyen bir yüzü sağa dönükler silsilesinde zincir bozan karakteri de vardır harfin. b gibi değildir, p ye yüz vermez, c yi umursamaz, e ye acır, a sen ne ayaksın diye sorgular. kendinden emin fonetik melodisi nedeniyle de öss istatistiklerine göre cevaplar arasında kararsız kalmış mağdurların, atmasyon yanıtlarında ilk sıradadır. kimi zaman güldürür kimi vakit öldürür.
• facebook'ta production koduna girmeyi basarabilmis program dili. http://forum.dlang.org/…7h5s$2gd8$1@digitalmars.com
  
  yine bi kisinin eforu muhtemelen ama olsun, dilin yaraticilari sevinmistir bi nebze.
  
  //edit// isvicreli bilimadami duzeltti beni: abi dilin yaratıcısı facebook'ta research scientist zaten :) (bkz: andrei alexandrescu)
• facebook, backend'de calisan c++ kodlarini yavas yavas bu dile port etmeye baslamis.
• https://github.com/d-programming-language
  http://dlang.org/
  http://ddili.org/
• en bahtsız programlama dili.
  
  neredeyse tüm alfabenin bir programlama diline isminin verildiği düşünülürse, evet, tüm sınıf kaybetmiştir ancak o, sınıf birincisinin yanında oturmakta olduğu halde kaybetmiştir.
  (bkz: c)
• d'de önemli bir proje geliştirmiş bir prof'un söylediğine göre garbage collectoru poblemli ve güvenilmemesi gerekli olan dil. reddit tartışması
• programlama dili tasarımına ilkokul'dan beri ilgim var. evet ilk programlama dilini ilkokuldayken tasarlamıştım. (bkz: selimcan/@ssg). o zamandan beri yeni ve değişik programlama dilleri beni heyecanlandırıyor, incelemekten keyif alıyorum. hani çok süper bir şey yapacağım da sırf dil yüzünden engelleniyor olduğumdan değil, programlamanın nasıl daha rahat, kolay ve üretken hale getirilebilebileceğini her daim merak ettiğimden.
  
  d ilk bakışta "c# gibi görünen c++" gibi durduğundan kulağa hoş geliyor. özellikler listesini duyunca ağzınızın sularını akıtıyor "oha bunu da yapıyormuş, şunu da yapıyormuş". o yüzden geçen sene the d programming language'i alıp okumuştum. kitabı okuduktan sonra ağzımda kalan tat kekremsi oldu. d'yi ufak tefek birkaç deneme dışında neredeyse hiç kullanmadım, kağıt üstündeki haline yorum yapacağım.
  
  d'nin tamamına bakınca görülen en büyük problem günümüzde bir tasarım hedefi olmaması. dile bakınca vizyonu "biz her şeyi yapıyoruz" gibi duruyor. halbuki d'nin çıkış hikayesi çok net bir vizyon barındırıyormuş: andrei alexandrescu bir gün c++ derleyicisi yazmaya karar vermiş. dilin ne kadar karmaşık olduğunu görünce "oha bunu yapacağıma yeni daha sade basit bir dil yaparım hem daha da süper olur" demiş ve d'yi geliştirmeye başlamış. (edit: uyarı geldi ilk sürümleri çıkaran andrei değilmiş ama d programming language kitabında dili geliştirme hikayesini bu şekilde anlatıyor. haliyle çıkarmadıysa dahi ekibine katılma gerekçesi kabul edelim).
  
  haliyle d'nin çıkış vizyonu bir "anti c++". yani c++'ın c'de çözdüklerini çözerken, karmaşıklığından azade olacak şekilde kıvılcımlanmış. ancak bugün quora'da yaratıcısı andrei'nin d övgüsü ve eleştirisini okuduğumda eleştirilerinden birinin de d'nin vizyonu olmadığı, çünkü komunite tarafından geliştirildiği şeklinde.
  
  geliştiricleri belli ki dili geliştirmenin bir noktasında karar mekanzimasını komuniteye devretmek ile linus torvalds tarzı bir diktatörlükle idare etmek arasında kalmış ve "neyse kitleye bırakayım kafalarına göre geliştirsinler" demişler. haliyle "vizyonsuzluk" d'nin kaderi değil, yaratıcısının tercihi. güzelim vizyon çöpe atılmış ve d her fantazinin gelişigüzel monte edildiği ucube bir şato olmuş.
  
  geçen d hakkında "over-engineered" demiştim. d dilinin spesifikasyonunu birazcık sıksan feature fışkırıyor: standart oop ve generics dışında template'lar, trait'ler, mixin'ler, channel'lar, contracts, scope guards, nested functions, compile-time evaluation, pure function, const-correctness, immutability. böyle "keşke olsa" denilen her şey konmuş rüya gibi. ama tam olarak d'nin laneti bu: çok büyük.
  
  d'nin sadece özellik listesi bile sayfalar sürüyor. dilin özelliklerine hakim olmak için bile başta kendisine tepki olarak çıktığı c++'tan ya da c#'tan dahi daha çok çaba sarf etmek gerekiyor. yani dilin gücü öğrenme eğrisine çok olumsuz etki etmiş. sonra andrei meşhur d eleştirisinde "pek popüler değil" diyor. e ya ne olacağdı? diğer dillerden 10 kat büyük dil yapmışsın sonra niye tutmuyor. e adam bakıyor "ya ben bunu öğrenemeyeceğim galiba" deyip fenalaşıyor. haliyle d'ye yönelik engineering çabası zayıf ve fit bir dil elde etmekte kullanılmaktan ziyade feature basmaya odaklanmış. bu yeni başlayan birinin "bu dilde bunu nasıl yaparım?" sorusuna yanıt bulmasını çok zorlaştırıyor.
  
  öte yandan bu kadar özelliğine rağmen programlama paradigmalarına tam bir çözüm getiremiyor. mesela fonksiyonel programlama için bir yığın özellik eklenmiş: immutability, pure function, higher order function'lar vs. ama kritik özelliklerden discriminated union ve pattern matching desteği yok. dile dahil "optional type" desteği yok. geçtim scala'yı swift'ten bile geride. haliyle compile-time type safety iş görmüyor. tamamen güvenli bir tip sistemi olmadığından mesela pure function desteği tamamen pure değil. o da strong ve weak pure diye ikiye ayrılıp saçma sapan diyarlara doğru yol alıyor. yani d programcısından öyle bir yetenek birikimi bekliyorsun ki adam "hmm burada weak pure function kullanırsam iyi olur" kararını verebilecek yetenekte olmalı. derleyici tail call optimization'ı garanti edemiyor. kısacası fonskiyonel programlama dili değil, haliyle sunduğu güzellikleri gölgeliyor.
  
  aynı durum nesneye yönelik programlamada da geçerli. mesela extension methods için üretilen çözüm (ucfs) evrensel haliyle ilk parametresi nesne/struct olan herhangi bir fonksiyonu tersten yazabilmeyi sağlamak üzerine. bu c# ya da java'dakinden de kötü bir yaklaşım. var olan tüm fonksiyonları çağırmak için iki ayrı yol tanımlıyor. haliyle hem tutarsızlığa hem overuse'a ve ondan dolayı abuse potansiyeline sahip. c#'ta o kadar kolay değil çünkü o sözdizimine tabi fonksiyonları özel olarak deklare etmen gerekiyor. her fonksiyon o notasyona amade değil, kapsam kat be kat daha dar.
  
  aynı şekilde tip<t> gibi neredeyse her dilde standart bir yaklaşım yerine yerine "tip!t", "tip!(t)" ve "tip(t)" olmak üzere üç ayrı sözdizimi. gerekçesi de parsing sırasında derleyicinin karşılaştığı muğlaklığı azaltmak. yani programcının konforu düşünülmemiş, derleyicinin konforu düşünülmüş. bu da "c++ çok karmaşık" diye ortaya çıkıp sonra bir noktada bundan vazgeçip "ama derleyici konforu da önemli"ye kayışın bir göstergesi. derleyici muğlaklıktan kurtulmuş bu sefer programcı muğlaklığa düşüyor. çünkü fonksiyon deklarasyonunda int f(a)(b) gibi sözdizimleri görünce parantezler birbirine giriyor. aynı muğlaklığın tip<t> için olduğunu iddia etmek mümkün (küçüktür ve büyüktür kıyaslarıyla) ancak onlar da bağlamsal olarak o kadar alakasız context'lerde kullanılıyor ki sıkıntı yaratmıyor. oysa parantez fonksiyon deklarasyonunda doğrudan problem. derleyici mühendisliği programcıyı umursmayacak kadar ileri gitmiş.
  
  reflection, rtti yok. bu da genel amaçlı kod üretme ve kullanma imkanını template'ların ve derleyicinin üstüne yıkıyor. runtime interoperability'yi sadece işletim sistemi üzerinden destekliyor.
  
  biraz da reflection yokluğundan olsa gerek, unit test'ler için dile özel keyword getirilmiş bu bir ilk olabilir: unittest. böylece kod test için build edilirken bu kod build ediliyor aksi halde edilmiyor. halbuki d dili bu özelliği zaten "versions" özelliğiyle sağlıyor. bir kod sadece test version'ında olsun diyebiliyorsun.
  
  böyle pişti vaziyetleri o kadar çok ve ortalığa saçılmış durumda ki. yani "derleyicisini yazması kolay olsun" dediğin dilde derleyicinin aynı işi farklı envai şekide yapma yolunu destekletmen gerekiyor. tüm bu harcanmış efor daha az sayıda ama doğru geliştirilmiş özelliğe odaklanabilecekken o imkanını da yitirmiş. dili öğrenmek yetmiyor, bir de başkasının kodunu anlayabilmen için aynı işin yapılabileceği farklı yolların tamamını da öğrenmen gerekiyor. oop dışındaki paradigmalara desteği kağıt üstünde tam olmadığından sonu hüsranla bitecek uzun maceraları göze almak zorunda bırakıyor. çok büyük ve yanlış yerlerin üstüne çok düşülmüş, temelde gözden çok şey kaçırılmış.
  
  d'nin doğru yaptığı çok şey var ve yanlışlarından sayınca fazla olabilir. ancak göze batan ufak tefek kısımlar bence adoption konusunda programcı denen takıntılı yaratığa tahmin edilenden çok daha fazla etki ediyor olmalı. bana ediyor. belki aynı standard library'sinde yaşandığı gibi "d'nin olması gereken hali" bir fork olarak çıkar ve bahsettiğim meseleleri adreslerse yeniden nefes alabilir.