| |
 | Posted by dunecourser |  Permalink Reply |
|
dunecourser 
| Birazcık basit bir gözden bakmak istiyorum, o yüzden kısa tutacağım. (Hepsi ayrıntılarıyla düşünülmüş olmak zorunda değil.)
Sevdiklerim
- Kısa derleme süresi.
- C vâri syntax.
- Eldekinden faydalanmak.
UDA sayesinde dile sürekli yeni keywordler eklemiyoruz.
Dilin olanakları o özelliği simüle etmeye yetiyorsa derleyiciyi kurcalamıyoruz. (bkz. imported!"std" (Ben using() ya da import() tercih ederdim. :D))
Yeni özellikler eklerken mevcut keywordları kullanıyoruz. (bkz. readonly = in, ensure = in, in = in)
- Birden fazla memory management stratejisi.
Yerine göre farklı stratejiler kullanabileceğimi bilmek hoş. Yine de ben çoğu program için garbage collector'ı tercih edeceğim.
- Aralıklar.
Bunu siz övün. :)
- <> yerine !() ve template'ler
Bazı insanlar bunu sevmiyor ama parantezleri kullanmak zorunda kalmadığınız sürece ki genellikle kalmıyorsunuz, bu syntax okunaklılığı çok artırıyor. Template'leri bu kadar yaratıcı ve geniş ölçekte kullanabilmek, başka bir dilde bulamadığım bir özellik.
- Kontratlar ve kardeşleri.
- Derleme zamanı olanakları çok üstün.
- built-in unittest
Sanıyorum D'nin "bir ilk" etiketli özelliklerinden sadece biri. Yeni dillerde de bunu görmeye başladık. Ne kadar işe yarar olduğunu açıklamama gerek yok sanıyorum.
- UFCS
İyi isimlendirilmş template ya da fonksiyonlarla kullanıldığında çok beğeniyorum. (bkz. to!(variable, int) yerine variable.to!int)
operator overloading kullanmaktansa bunu kullanmak daha iyi: '+' gibi bir ifade gizlice fonksiyon çağırmıyor. Üstelik operator overloading olmayan bir dilimiz olsaydı, yazacağınız falanca bir matematik kütüphanesi arap saçına dönüşmezdi.
-----
Sevmediklerim
- Çok büyük.
Kodlama tarzı hakkında çok düşündürtüyor.
C'ninkileri onaran ama D'de pek kullanılmayan özellikler.
Büyüklüğüne rağmen eksik kaldığından diğer özelliklerini aksatıyor. (örn. built-in pattern matching daha yeni yeni dile eklenecek.)
- Garbage collector.
Hayır garbage collector'ın kendisinden değil. Ben garbage collector hakkındaki tartışmaları ve bunlara verilen yanıtları beğenmiyorum.
1. Allocator olarak malloc ve free'yi kullanacak olsam D'le kullanmazdım, libc yalnız D değil betterC için bile bir facia. Gider C ya da C++ kullanırım.
2. @nogc vb. attribute'lar gerçek bir alternatif değil çünkü dilin kullanışlı olan taraflarını da eliyor, üstelik @nogc kontrol edilirken garbage collector arayüzünü kullanamıyoruz. Phobos'taki çözüm şu sanıyorum: kod genellikle attribute'a sahip olmadan yazılıyor. unittest'ler kodun destekleyebildiği bütün attribute'ları test ediyor.
Dilin temeli bunun üzerinden atılmadığı ve iş yükünün çokluğu yüzünden çok zor ama başlıca memory management stratejilerini kütüphanelere göre ayırmak işe yarar mıydı?
import phobos.gc;
import phobos.rc;
import phobos.traditional;
import phobos.live;
Bunu dökümanlarda kategorileştirsek yine de işe yarar olurdu, hangi fonksiyonun @nogc uyumlu olduğunu kaynağa bakmadan anlayamıyoruz.
3. Geleneksel olarak garbage collector'tan kaçınılan alanlarda D kullanıcılarının kodları bildiğimiz ve sevdiğimiz D gibi değil.
4. Kendi kütüphaneni yazmak hızlı çalışan ve uyumlu çalışan kod yazmak için iyi bir fikir. Ama bunun yerine C++ ile debeleşmeyi yeğlerdim, çoğumuz yeğlerdi.
5. Evet, bu tartışmalar yıllar içinde D'ye çok zarar vermiş.
- İsimsiz unittestler.
- inout.
Var olma sebebini anlıyorum ama iyi tasarımlar problemleri çözerken yeni problemler yaratmazlar. inout D'de yeni problemler yaratıyor.
- mixin.
C'nin onarılmış özelliklerinden biri olup D'de özel durumlar dışında kullanmadığımız bir özellik daha. Kullanışlı olduğunu reddetmiyorum ama kullanmamak için özellikle çabalıyorum.
- anonymous struct'lar yok.
Template'leri daha da güçlendirecek bir özellikten mahrum kalıyoruz.
- UFCS ve fonksiyonlar için opsiyonel parantezler.
"Hello, World".writeln gibi örnekler dili karmaşıklaştırıyor. Kısıtlanabilir olması daha iyi olur muydu acaba?
double artı(double ilk, double son) @ufcs => 2.artı(5) // 2 + 5 = 7
double artı(double ilk, double son) => 2.artı(5) // error
Herhangi bir parametre bile almasa o parantezler insanın aklına karıştırabilecek durumlardan koruyor. Rust'ın one-line statement'leri elemesi gibi; daima süslü parantez kullanmak zorundasınız.
- @uda'lar tek tük.
@nogc yerine alias nogc = makeUDA!(@nonew, @noheap // ...) falan diyebilirdik.
-----
Kısa diye başlamıştım, biraz uzun oldu. :D
|
