Mengü dil gereksinimlerini güzel listelemiş. Aynı türden bir yazı yine daha dün D haber gruplarında konu edildi:

http://forum.dlang.org/post/vwpzirpppabcgylmvpsx@forum.dlang.org

Başka dillere sataşmayı hiç sevmiyorum ve zaten hiç PHP bilmiyorum ama oradaki blog yazısı PHP'nin ne kadar kötü tasarlanmış bir dil olduğunu belgelerken dillerden neler beklememiz gerektiğini de listeliyor:

• Tahmin edilebilir (predictable) olmalı: İnsana yardım eden bir araç olduğuna göre kodlara bakıldığında ne anlama geldiği tahmin edilebilmeli.

• Tutarlı olmalı: Bir köşesini biliyorsak ona benzeyen başka köşesinin de öyle işlediğini tahmin edebilmeliyiz.

• Öz olmalı: Makine kodu da yazabildiğimiz halde kod tekrarlarına gerek olmadığı için üst düzey diller kullanıyoruz. Dil buna benzer tekrarlar gerektirmemeli.

• Güvenilir ve sağlam olmalı: Diller problem çözmek içindir; kendileri sorun kaynağı olmamalı.

• Hatası ayıklanabilir olmalı: Hataları programcının bulup gidermesi gerekecektir. Dil buna olanak sağlamalı.

Eleştiren her yazıda olması gerektiği gibi o yazı bütün ayrıntılara girerek PHP'nin neden bu konuların hepsinde de başarısız olduğunu gösteriyor.

Tabii amacım D'nin PHP'den üstün olduğunu göstermek veya PHP'ye sataşmak değil. Oradaki listenin bu konuyu da ilgilendirdiğini gördüğüm için yazdım.

Ama söylemeden de edemeyeceğim: Eğer PHP orada yazıldığı gibi bir amatörler topluluğu ("PHP is a community of amateurs.") ise veya körün köre kılavuzluk ettiği bir ortamsa ("the biggest problem with PHP: it is absolutely the blind leading the blind."), programcılıkla bazılarımız gibi hobi olarak ilgilenen arkadaşların dil sanarak PHP'ye takılmaları üzücü. Yazarın kullandığı Python, bazılarımızın bayıldığı D ve başka bir sürü gerçek dil varken o arkadaşların yanlışlıklarla dolu dillere takılmaları üzücü.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (erdem):

Doğru. Ben o kitabı okudum ve C++ şablonlarının bazı işlemlerde ne kadar yetersiz kaldığını kendim yaşadım. D'nin en güçlü olanaklarından bazılarının o kitabın C++'ta bulamadıklarından çıktığı açık.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Zaman bulunca başka yanıtlarım da olacak.

Alıntı (Salih Dinçer):

Phobos'taki değil, FReD kütüphanesinin ctRegex olanağından bahsediyorum. Andrei'nin şuradaki sunumunun 60 numaralı slaytında bir grafik var:

http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Three-Unlikely-Successful-Features-of-D

Orada FReD/RT diye gösterilen, kütüphanenin düzenli ifade komutunu çalışma zamanında ayrıştıran ve kullanan çözümü. FReD/CT ise aynı komutu derleme zamanında ayrıştırarak tam da o komuta özel bir motor derliyor:

import std.regex;
auto r1 = regex("^.*/([^/]+)/?$");        // çalışma zamanında
enum r2 = ctRegex!("^.*/([^/]+)/?$");     // derleme zamanında

Ben buna benzer becerileri derleme zamanında halledebilen bir tek C++'ı biliyorum ama düzenli ifadelerin gerçekleştirmelerine çok uzak olduğum için orada ne kadar zor olacağını bilmiyorum.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Cevaplar için teşekkürler, çok aydınlatıcı oldu...

Alıntı (Ali Çehreli):

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (Salih Dinçer):

dil, D ile yazılan bir D derleyicisi idi. Devam edildiğini sanmıyorum.

Benim bildiğim üç D derleyicisi var. Çok mu yani? :)

1. dmd: Bu aşamada bundan başkasının kullanılması bence anlamlı değil çünkü dili geliştirenlerin derleyicisi bu. Bütün eksik ve yeni olanaklar bunda gerçekleşiyor. Başka derleyiciler bunun gerisinde kalmak durumundalar.

2. gdc: Bu, dmd derleyicisinin ön tarafını (front end) senelerin gcc'sinin arka tarafı (back end) ile birleştiren bir proje. gcc aslında bir C derleyicisi değildir. gcc de başka her derleyici gibi iki taraftan oluşur:

• Ön taraf programlama dillerini bilir. Şimdilik bildiği diller şunlar: http://gcc.gnu.org/frontends.html

gdc henüz ana gcc sürümüne bağlı değil. Zamanla D de o listeye eklenecek.

• Arka taraf mikroişlemci mimarilerini bilir. Şimdilik bildiği mimariler şunlar: http://gcc.gnu.org/backends.html

Bu ayrımın yararı çok büyüktür. Böylece N tane dil M tane mimaride desteklenmiş olur. D, N+1'inci dil olmaya çalışıyor. Böylece hem başka mimarilere de açılacak hem de gcc'nin çok iyi kod üreten arka tarafından yararlanmış olacak. dmd'nin kendi arka tarafı gcc'ninkinden daha yavaş.

gdc mecburen dmd'yi arkadan takip ediyor. Şu anda dmd 2.059 sürümünde ama gdc onun 2.057 sürümünün ön tarafını kullanıyormuş: https://bitbucket.org/goshawk/gdc/wiki/Home

3. ldc: Bu da arka taraf olarak LLVM denen ortamı kullanan bir D derleyicisi. Bunun mantığı da aynı: ön tarafta farklı diller, arka tarafta farklı mimariler. Eğer sitesini doğru bulduysam son gelişmesi iki sene önceymiş: http://www.dsource.org/projects/ldc/wiki/Release_0.9.2?action=diff&version=6

Alıntı:

Öyle olduğunu bilmiyorum. Bir yerden yanlış bir izlenim mi edindin acaba?

Alıntı:

Öyle bir ilgi göremiyorum. D de C++ da derlemeli dil olduklarına göre işletim sisteminin veya kütüphanelerinin nasıl geliştirilmiş olduklarının hız açısından bir önemi yoktur. Sonuçta makine kodu durumundalar. İşletim sistemi kabul edip bize sunduysa da hızı da yeterlidir.

Alıntı:

GtkD gibi katmanlar aslında pek katman değil. D, C kütüphanelerini doğrudan çağırabiliyor. GtkD de aslında Gtk'nin C kütüphanesindeki işlevlerin D dilinde sunulması. Katman varsa da oldukça ucuz işlev çağrılarından oluştuğunu sanırım.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (Salih Dinçer):

Bilmiyordum. Karşılaşmış olsam da Linux'un sıradan paket bağımlılıklarından birisi olduğunu düşünüp kuruvermişimdir belki de. :)

Ama yine de gcc derleyicisinin kendisinin gerektiğini düşünmüyorum. Yani D programlarını derlerken arkada gcc'yi çalıştırdığını sanmıyorum. dmd'yi kurarken de çalıştırdığını sanmıyorum çünkü dmd'nin kurulumu eskiden beri yalnızca bir klasöre kopyalayıp çağırmak kadar basittir.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Konuyu tam okuyamadım fakat bende birkaç yorum yapmak istedim. Öncelikle Türkiyede adam gibi C++ bilen yok. Yüz, bilemedin ikiyüz kişi vardır.

Herhangi bir dilin kullanımı konusunda da biliyorsunuz projeler geliştirilirken bir çok aşamadan geçiyor. Fikir, mockup, prototip, vs. Bence D dili bu konuda yeterli araç, hız ve güvenliği bize verebiliyor.

Projelerde açıkcası bir dil-platform seçimi yaparken, yapılacak işin içeriğine bakıyoruz. Yaptığınız iş genelde sistem programları olunca her türlü seçeneği ele almak zorunda kalıyorsunuz.
Python, perl örneğin mockup ve prototip hazırlamak için iyi ve yetenekli diller. Fakat ben en küçük arayüzü bile C++ kullanmadan yapamıyorum. Aynı şekilde bir betik yazılacaksa, bunu python ile halletmek, awk' dan eftal geliyor.

Dilden dile atlamak çok zor bir durum. Hele yapıları birbirine benziyorsa bir süre sonra karıştırmaya başlıyorsunuz. Çünkü alıştığınız dilden gelen yapısal alışkanlıklar, yeni kullandığınız dilde hata yapmanıza neden olabiliyor. Her iki dil için aynı düşünüyorsunuz fakat aslında çok farklılar, bu yüzden aynı inşaa yöntemlerini kullanmak verimsizliğe neden oluyor.

Benim en çok kızdığım şey, C ve C++ ' ın bir tutulmasıdır mesela. İkisi aynı tabanı kullanmakla beraber, birbirinden çok farklı veri yapıları içerebiliyorlar ve aynı işler için farklı verimlilik oranlarına sahipler.

Bununla beraber, Qt kullanan adamın da, kendisini C++ bilir sayması kanıma dokunmakta. İyi şekilde soyutlama yapan bir kütüphane ile birşeyler inşaa etmek, o kütüphanenin kullandığı dili bilmek anlamına gelmiyor.

D dili yapısal özellikleri ve geniş standart kütüphanesi ile bana çok daha farklı geliyor. Sunduğu veri yapıları çok çeşitli. Ayrıca hem çöp toplama sistemi, hem de bellek ayırmalı modeli kullanabilmesi büyük bir esneklik.

Ayrıca D derleyicisinin kırpılmış da olsa C desteklemesi çok hoşuma gidiyor.

Ben D dilinin endüstriyel anlamda kendisine iyi bir yer edineceği kanısındayım.
Konuyu baştan aşağı okuyup, biraz daha yazmaktı niyetim. Cümleler kopuk gelirse, yorgunluktan dolayı affınıza sığınıyorum.
Saygılar.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]