Dinamik diller için gerçek bir avantaj var mı? [kapalı]

_{İlk önce Java'nın şimdiye kadar kullandığım tek dil olduğunu söylemek istiyorum, bu yüzden lütfen bu konudaki cehaletimi affedersiniz.}

Dinamik olarak yazılmış diller, herhangi bir değişkene herhangi bir değer koymanıza izin verir. Örneğin, aşağıdaki işlevi yazabilirsiniz (psuedocode):

void makeItBark(dog){
    dog.bark();
}

Ve ne pahasına olursa olsun içinden geçebilirsiniz. Değerin bir bark()yöntemi olduğu sürece kod çalışacaktır. Aksi takdirde, bir çalışma zamanı istisnası veya benzer bir şey atılır. _{(Bu konuda yanılıyorsam lütfen beni düzeltin).}

Görünüşe göre, bu size esneklik verir.

Ancak, dinamik diller hakkında biraz okuma yaptım ve insanların söylediği şey, dinamik bir dilde kod tasarlarken veya yazarken, tıpkı statik olarak yazılmış bir dilde yaptığınız gibi, türleri düşünün ve bunları dikkate alın.

Örneğin, makeItBark()işlevi yazarken, yalnızca 'havlayabilen şeyleri' kabul etmeyi niyet edersiniz ve yine de bu tür şeyleri yalnızca ona aktardığınızdan emin olmanız gerekir. Tek fark, şimdi derleyicinin bir hata yaptığınızda size söylemeyeceğidir.

Elbette, bu yaklaşımın bir avantajı vardır ki, statik dillerde, 'bu işlev havlayabilecek herhangi bir şeyi kabul eder' elde etmek için açık bir Barkerarabirim uygulamanız gerekir . Yine de, bu küçük bir avantaj gibi görünüyor.

Bir şey mi eksik? Dinamik olarak yazılmış bir dil kullanarak gerçekten ne kazanıyorum?

Dinamik olarak yazılmış diller tek tipli

Yazım sistemlerinin karşılaştırılması , dinamik yazmanın avantajı yoktur. Dinamik yazma, özel bir statik yazma durumudur - her değişkenin aynı türde olduğu statik olarak yazılmış bir dildir. Aynı şeyi Java'da (eksi netlik) her değişkenin türünde yaparak Objectve "nesne" değerlerinin türünde olmasını sağlayarak yapabilirsiniz Map<String, Object>:

void makeItBark(Object dog) {
    Map<String, Object> dogMap = (Map<String, Object>) dog;
    Runnable bark = (Runnable) dogMap.get("bark");
    bark.run();
}

Dolayısıyla, yansıma olmadan bile, aynı etkiyi, herhangi bir statik-yazıyla yazılmış herhangi bir dilde, sözdizimsel bir kenara bırakarak elde edebilirsiniz. Ek bir ifade gücü elde edemezsiniz; tam tersine, sahip daha az bir dinamik olarak yazılan dilde değilse, çünkü ifade gücünü inkar belirli türdeki değişkenler kısıtlamak için yeteneği.

Statik olarak yazılmış bir dilde ördek havlaması yapma

Dahası, statik olarak yazılmış iyi bir dil, bir barkişlemi olan herhangi bir türle çalışan kod yazmanıza izin verecektir . Haskell'de bu bir tür sınıfıdır:

class Barkable a where
    bark :: a -> unit

Bu, bazı türlerin aBarkable olarak kabul edilmesi için, barkbu türün değerini alan ve hiçbir şey döndürmeyen bir işlev olması gerektiğine dair kısıtı ifade eder .

Daha sonra genel fonksiyonları fonksiyon Barkablekısıtı olarak yazabilirsiniz :

makeItBark :: Barkable a => a -> unit
makeItBark barker = bark (barker)

Bu, gereksinimlerini makeItBarkkarşılayan her türden işe yarayacağını söylüyor Barkable. Bu benzer görünebilir interfaceJava veya C # ama büyük bir avantaja sahiptir - tipleri belirtmek gerekmez ön onlar tatmin tip sınıfları. O tip söyleyebiliriz Duckolduğunu Barkablebile istediği zaman Duckben yazmadım üçüncü bir türüdür. Aslında, yazarın Duckbir barkişlev yazmadığı önemli değil - Ducktatmin edici bir dil söylediğimde, gerçeği sonra sağlayabilirim Barkable:

instance Barkable Duck where
    bark d = quack (punch (d))

makeItBark (aDuck)

Bu, Ducks havlayabildiğini ve onların kabuk işlevinin yerine getirmeden önce ördekleri yumruklayarak uygulandığını söylüyor . Bunun dışında makeItBarkördekleri çağırabiliriz .

Standard MLve aynı tip sınıfı birden fazla şekilde OCamltatmin edebilmeniz için daha da esnektir . Bu dillerde, geleneksel sıralamayı kullanarak tamsayıların sipariş edilebildiğini söyleyebilirim ve sonra arkanı dönüp de bölünebilirlikle sıralanabilir olduklarını söyleyebilirim (örneğin , 10, 5 ile bölünebilir). Haskell'de, bir tür sınıfını yalnızca bir kez başlatabilirsiniz. (Bu, Haskell'in otomatik olarak bir ördek çağırmanın uygun olduğunu bilmesini sağlar ; SML veya OCaml'de, hangi fonksiyondan daha fazla olabileceğiniz konusunda açık olmanız gerekir .)10 > 5bark bark

Özlülük

Elbette, sözdizimsel farklılıklar var. Sunulan Python kodu yazdığım Java eşdeğerinden çok daha kısa. Uygulamada, bu özlü dinamik olarak yazılmış dillerin cazibesinin büyük bir parçasıdır. Ancak tür çıkarımı, statik olarak yazılmış dillerde özlediğiniz kodları yazmanıza olanak tanır, her değişkenin türünü açıkça yazmak zorunda kalmazsınız . Statik olarak yazılmış bir dil, tüm döküm ve harita manipülasyonlarının ayrıntılarını kaldırarak, dinamik yazma için yerel destek de sağlayabilir (örneğin, C # gibi dynamic).

Doğru ama kötü yazılmış programlar

Adil olmak gerekirse, statik yazım yazım denetleyicisi doğrulayamasa da teknik olarak doğru olan bazı programları mutlaka dışlar. Örneğin:

if this_variable_is_always_true:
    return "some string"
else:
    return 6

Statik olarak yazılmış dillerin çoğu if, başka bir dal asla oluşmasa da bu ifadeyi reddeder . Uygulamada hiç kimse bu tür bir kod kullanmıyor gibi görünmektedir - tip denetleyicisi için çok akıllıca olan herhangi bir şey muhtemelen kodunuzun gelecekteki yöneticilerinin sizi ve akrabalarınızı aklına getirecektir. Buna göre, birisi başarıyla 4 açık kaynaklı Python projesini Haskell'e çevirdi, bu da statik olarak yazılmış iyi bir dilin derleyemediği hiçbir şeyi yapmadıkları anlamına geliyor. Dahası, derleyici, ünitenin test edemediği birkaç tip ilişkili hata buldu.

Dinamik yazma için gördüğüm en güçlü argüman Lisp'in makroları, çünkü dilin sözdizimini keyfi bir şekilde genişletmenize izin veriyorlar. Bununla birlikte, Typed Racket , makroları olan, statik olarak yazılmış bir Lisp lehçesidir, bu yüzden statik olarak yazmak gibi görünmektedir ve makrolar aynı anda uygulanması daha zor olsa da, birbirini dışlayan değildir.

Elmalar ve Portakallar

Son olarak, dillerde sadece tür sistemlerinden daha büyük farklılıklar olduğunu unutmayın. Java 8'den önce, Java'da her türlü işlevsel programlama yapmak neredeyse imkansızdı; basit bir lambda 4 satırlık anonim sınıf kodu gerektirir. Java ayrıca, koleksiyon hazırlayıcıları için bir desteği de yoktur (örn. [1, 2, 3]). Ayrıca takımın kalitesi ve kullanılabilirliği (IDE'ler, hata ayıklayıcılar), kütüphaneler ve topluluk desteğinde farklılıklar olabilir. Birisi Python veya Ruby'de Java'dan daha üretken olduğunu iddia ettiğinde, bu özelliğin dikkate alınmaması gerekiyor. Tüm pilleri içeren dilleri karşılaştırma , dil çekirdekleri ve tür sistemleri arasında fark var .

Bu zor ve oldukça öznel bir konudur. (Sorunuz görüşe dayalı olarak kapanabilir, ancak bu kötü bir soru olduğu anlamına gelmez - tam tersine, bu tür meta dil soruları hakkında düşünmek bile iyi bir işarettir - soru-cevap formatına uygun değildir. Bu forumdan.)

İşte benim görüşüme göre: Yüksek seviyeli dillerin amacı bir programcının bilgisayarla yapabileceklerini kısıtlamak . Bu, birçok insan için şaşırtıcıdır, çünkü amacın, kullanıcılara daha fazla güç vermek ve daha fazlasını elde etmek olduğuna inanırlar . Ancak Prolog, C ++ veya List'te yazdığınız her şey sonunda makine kodu olarak yürütüldüğünden, programcıya zaten montaj dilinden daha fazla güç vermek imkansızdır.

Üst düzey bir dilin amacı , programcının kendi oluşturdukları kodu daha iyi anlamalarına ve aynı şeyi yapmaları için daha verimli olmalarına yardımcı olmaktır. Bir alt rutin adı hatırlamak onaltılık bir adresten daha kolaydır. Otomatik bir argüman sayacı, buradaki bir çağrı sırasından daha kolaydır, argüman sayısını tam olarak kendi başınıza, yardım almadan almanız gerekir. Bir tür sistemi daha da ileri giderek belirli bir yerde sağlayabileceğiniz türden argümanları kısıtlar .

Burası insanların algılarının değiştiği yer. Bazı insanlar (Ben bunların arasındayım), şifrenizin rutin kontrolünün yine de tam olarak iki argüman bekleyeceği ve her zaman bir sayısal kimliği izleyen bir dize olduğu sürece, bunu kodda bildirmenin ve otomatik olarak hatırlatılmasının yararlı olacağını düşünür. daha sonra bu kurala uymayı unutursun. Derleyiciye böylesine küçük ölçekli defter tutmanın dış kaynak kullanımı, daha üst düzeydeki endişeler için zihninizi boşaltmanıza yardımcı olur ve sisteminizi tasarlama ve tasarlamada sizi daha iyi hale getirir. Bu nedenle, tip sistemleri net bir kazançtır: bilgisayarın iyi olduğu şeyi yapmasına izin verir ve insanlar da iyi olduklarını yapar.

Diğerleri oldukça farklı görüyorlar. Bir derleyici tarafından ne yapmaları gerektiğini söylemekten hoşlanmazlar. Tip bildirgesine karar vermek ve yazmak için ek çaba harcamadan hoşlanmıyorlar. Nerede kullanacağınızı tam olarak hangi tür ve argümanları kullanacağınızı söyleyen bir plan olmadan gerçek işletme kodunu yazdığınız keşifsel bir programlama stilini tercih ederler . Ve kullandıkları programlama stili için bu oldukça doğru olabilir.

Tabii ki, burada fazlasıyla sadeleştiriyorum. Tip kontrolü kesinlikle açık tip beyanlara bağlı değildir; tip çıkarımı da var. Farklı türlerde argümanlar yapan rutinlerle programlama yapmak, aksi takdirde imkansız olacak oldukça farklı ve çok güçlü şeylere izin verir, bu sadece pek çok insanın bu boşluğu başarıyla kullanacak kadar dikkatli ve tutarlı olmamasıdır.

Sonunda, bu kadar farklı dillerin hem popüler olduğu hem de ölme belirtisi göstermediği gerçeği, insanların programlamayı çok farklı bir şekilde sürdürdüğünü gösteriyor. Programlama dili özelliklerinin büyük ölçüde insan faktörleriyle ilgili olduğunu düşünüyorum - insan karar verme sürecini daha iyi destekleyen nedir - ve insanlar çok farklı çalıştıkları sürece, piyasa aynı anda çok farklı çözümler sunacaktır.

Dinamik diller kullanılarak yazılmış kod, statik tip bir sisteme bağlanmaz. Bu nedenle, bu birleştirme eksikliği, zayıf / yetersiz statik tip sistemlere kıyasla bir avantajdır (bununla birlikte, büyük bir statik tip sisteme kıyasla bir yıkama veya dezavantaj olabilir).

Ayrıca, dinamik bir dil için, statik tip bir sistemin tasarlanması, uygulanması, test edilmesi ve bakımı gerekmez. Bu, uygulamayı statik tip sistemli bir dile kıyasla daha kolaylaştırabilir.