Dinamik tür dillere karşı statik tür diller


205

Dinamik yazım dillerinin statik yazım dillerine göre avantajları ve sınırlamaları nelerdir?

Ayrıca bakınız : dinamik dillerin sevgisi (çok daha tartışmacı bir konu ...)


10
Bu soru çok öznel.
Jason Dagit

7
Ben öznel demezdim, ama alev yemi. Ancak bununla ilgili bazı nesnel gerçekler var.
Vinko Vrsalovic

2
Kabul edildi: çok öznel. İki yaklaşımı karşılaştırmak ve karşılaştırmak ilginçtir, ancak forum kıyametinin eşiğinde tehlikeli bir şekilde sallanmaktadır.
Daniel Spiewak

17
Dinamik diller, demo / takas uygulamalarının hızlı gelişimi için mükemmeldir, çünkü umurunda bir yazım hatası yaparsanız, web sayfası yine de yüklenir, burada veya orada yanlış birkaç veri öğesi olabilir. Derleyici hatası almadan değişkenlerinizi yanlış yazabilme yeteneğinin "avantaj" olarak görüldüğü başka bir durum düşünemiyorum.
Alex R

4
Böyle bir hata genellikle JavaScript'i çok iyi bir şey olarak düşündüğüm bir çığır açan durma noktasına getirir. En azından benim de değerli bulduğum hataları fırlatacaktı. Nedense hep javascript hatalarını boş try / catch ifadeleri ile gömmek isteyen statik bir yazma paradigmasından bir adam. Deneyimlerime göre bir fenomen. O nedir? Ne olursa olsun, kodumuzu çalıştırdığımızda geri bildirim almıyoruz.
Erik Reppen

Yanıtlar:


139

Tercümanın tür ve tür dönüşümlerini çıkarma yeteneği geliştirme süresini daha hızlı hale getirir, ancak derleme zamanında yakaladığınız statik olarak yazılmış bir dilde alamadığınız çalışma zamanı hatalarını da kışkırtabilir. Ama hangisi daha iyi (ya da her zaman doğru olsa bile) bu günlerde (ve uzun zamandan beri) toplulukta sıcak bir şekilde tartışılıyor.

Konuyla ilgili iyi bir take dan Gerekli olduğunda nerede Olası Statik Yazma, Dinamik Yazma: Programlama Dilleri Arasındaki Soğuk Savaş Sonu Microsoft'ta Erik Meijer ve Peter Drayton tarafından:

Statik yazmanın savunucuları, statik yazmanın avantajlarının programlama hatalarının daha erken tespit edilmesini (örneğin bir boole'ye bir tamsayı eklemenin önlenmesi), tip imzaları biçiminde daha iyi belgelemeyi (örneğin, isimleri çözerken sayı ve tür argümanlarını dahil etmek), derleyici optimizasyonları için fırsatlar (örneğin, alıcının tam türü statik olarak biliniyorsa sanal çağrıları doğrudan çağrılarla değiştirme), artırılmış çalışma zamanı verimliliği (örneğin, tüm değerlerin dinamik bir tür taşıması gerekmez) ve daha iyi bir tasarım süresi geliştirici deneyimi (örn. alıcının türü, IDE uygulanabilir tüm üyelerin bir açılır menüsünü sunabilir). Statik yazım fanatikleri bizi “iyi yazılmış programlar yanlış gidemeyeceğine” inandırmaya çalışıyor. Bu kesinlikle etkileyici gibi görünse de, oldukça boş bir ifadedir. Statik tip kontrolü, programınızın çalışma zamanı davranışının derleme zamanı soyutlamasıdır ve bu nedenle mutlaka kısmen sağlam ve eksiktir. Bu, tür denetleyicisi tarafından izlenmeyen özellikler nedeniyle programların yine de yanlış gidebileceği ve yanlış gidemedikleri sırada tür denetlenemediği programlar olduğu anlamına gelir. Statik yazmayı daha az kısmi ve daha eksiksiz yapma dürtüsü, tip sistemlerinin “fantom tipleri” [11] ve “titrek tipler” [10] gibi kavramların tanık olduğu gibi aşırı karmaşık ve egzotik olmasına neden olur. Bu, bacağınıza bağlı bir top ve zincir ile bir maraton koşmaya çalışmak ve ilk kilometreden sonra kefalet etmenize rağmen neredeyse bunu yaptığınızı zaferle bağırmak gibidir. Statik tip kontrolü, programınızın çalışma zamanı davranışının derleme zamanı soyutlamasıdır ve bu nedenle mutlaka kısmen sağlam ve eksiktir. Bu, tür denetleyicisi tarafından izlenmeyen özellikler nedeniyle programların yine de yanlış gidebileceği ve yanlış gidemedikleri sırada tür denetlenemediği programlar olduğu anlamına gelir. Statik yazmayı daha az kısmi ve daha eksiksiz yapma dürtüsü, tip sistemlerinin “fantom tipleri” [11] ve “titrek tipler” [10] gibi kavramların tanık olduğu gibi aşırı karmaşık ve egzotik olmasına neden olur. Bu, bacağınıza bağlı bir top ve zincir ile bir maraton koşmaya çalışmak ve ilk kilometreden sonra kefalet etmenize rağmen neredeyse bunu yaptığınızı zaferle bağırmak gibidir. Statik tip kontrolü, programınızın çalışma zamanı davranışının derleme zamanı soyutlamasıdır ve bu nedenle mutlaka kısmen sağlam ve eksiktir. Bu, tür denetleyicisi tarafından izlenmeyen özellikler nedeniyle programların yine de yanlış gidebileceği ve yanlış gidemedikleri sırada tür denetlenemediği programlar olduğu anlamına gelir. Statik yazmayı daha az kısmi ve daha eksiksiz yapma dürtüsü, tip sistemlerin “fantom tipleri” [11] ve “titrek tipler” [10] gibi kavramların tanık olduğu gibi aşırı karmaşık ve egzotik olmasına neden olur. Bu, bacağınıza bağlı bir top ve zincir ile bir maraton koşmaya çalışmak ve ilk kilometreden sonra kefalet etmenize rağmen neredeyse bunu yaptığınızı zaferle bağırmak gibidir. ve bu nedenle zorunlu olarak sadece kısmen sağlam ve eksiktir. Bu, tür denetleyicisi tarafından izlenmeyen özellikler nedeniyle programların yine de yanlış gidebileceği ve yanlış gidemedikleri sırada tür denetlenemediği programlar olduğu anlamına gelir. Statik yazmayı daha az kısmi ve daha eksiksiz yapma dürtüsü, tip sistemlerin “fantom tipleri” [11] ve “titrek tipler” [10] gibi kavramların tanık olduğu gibi aşırı karmaşık ve egzotik olmasına neden olur. Bu, bacağınıza bağlı bir top ve zincir ile bir maraton koşmaya çalışmak ve ilk kilometreden sonra kefalet etmenize rağmen neredeyse bunu yaptığınızı zaferle bağırmak gibidir. ve bu nedenle zorunlu olarak sadece kısmen sağlam ve eksiktir. Bu, tür denetleyicisi tarafından izlenmeyen özellikler nedeniyle programların yine de yanlış gidebileceği ve yanlış gidemedikleri sırada tür denetlenemediği programlar olduğu anlamına gelir. Statik yazmayı daha az kısmi ve daha eksiksiz yapma dürtüsü, tip sistemlerin “fantom tipleri” [11] ve “titrek tipler” [10] gibi kavramların tanık olduğu gibi aşırı karmaşık ve egzotik olmasına neden olur. Bu, bacağınıza bağlı bir top ve zincir ile bir maraton koşmaya çalışmak ve ilk kilometreden sonra kefalet etmenize rağmen neredeyse bunu yaptığınızı zaferle bağırmak gibidir. ve yanlış gidemedikleri halde tür denetlenemeyen programlar vardır. Statik yazmayı daha az kısmi ve daha eksiksiz yapma dürtüsü, tip sistemlerin “fantom tipleri” [11] ve “titrek tipler” [10] gibi kavramların tanık olduğu gibi aşırı karmaşık ve egzotik olmasına neden olur. Bu, bacağınıza bağlı bir top ve zincir ile bir maraton koşmaya çalışmak ve ilk kilometreden sonra kefalet etmenize rağmen neredeyse bunu yaptığınızı zaferle bağırmak gibidir. ve yanlış gidemedikleri halde tür denetlenemeyen programlar vardır. Statik yazmayı daha az kısmi ve daha eksiksiz yapma dürtüsü, tip sistemlerin “fantom tipleri” [11] ve “titrek tipler” [10] gibi kavramların tanık olduğu gibi aşırı karmaşık ve egzotik olmasına neden olur. Bu, bacağınıza bağlı bir top ve zincir ile bir maraton koşmaya çalışmak ve ilk kilometreden sonra kefalet etmenize rağmen neredeyse bunu yaptığınızı zaferle bağırmak gibidir.

Dinamik olarak yazılan dillerin savunucuları, statik yazmanın çok katı olduğunu ve dinamik dillerin yumuşaklığının, onları değişen veya bilinmeyen gereksinimlere sahip prototip sistemleri için ideal olmayan veya öngörülemeyen şekilde değişen diğer sistemlerle (veri ve uygulama entegrasyonu) etkileşime soktuğunu iddia eder. Elbette, dinamik olarak yazılan diller, yöntem yakalama, dinamik yükleme, mobil kod, çalışma zamanı yansıması, vb. Gibi gerçekten dinamik program davranışı ile başa çıkmak için vazgeçilmezdir. John Ousterhout, statik olarak yazılan sistemlerin programlama dilleri, kodu dinamik olarak yazılan komut dosyası dillerinden daha az yeniden kullanılabilir, daha ayrıntılı, daha güvenli ve daha az etkileyici hale getirir. Bu argüman, dinamik olarak yazılan komut dosyası dillerinin birçok savunucusu tarafından tam anlamıyla papağanlanmaktadır. Bunun bir yanlışlık olduğunu ve deklaratif programlamanın özünün ödevi ortadan kaldırdığını iddia ederek aynı kategoriye girdiğini iddia ediyoruz. Veya John Hughes'un dediği gibi [8], bir dili özellikleri atlayarak daha güçlü hale getirmek mantıklı bir imkansızlıktır. Tüm tip kontrolünü çalışma süresine ertelemenin iyi bir şey olduğunu savunmak, hataların geliştirme sürecinde mümkün olduğunca erken yakalanması gerektiği ile devekuşu taktikleri oynamaktır. özellikleri atlayarak bir dili daha güçlü hale getirmek mantıklı bir imkansızlıktır. Tüm tip kontrolünü çalışma süresine ertelemenin iyi bir şey olduğunu savunmak, hataların geliştirme sürecinde mümkün olduğunca erken yakalanması gerektiği ile devekuşu taktikleri oynamaktır. özellikleri atlayarak bir dili daha güçlü hale getirmek mantıklı bir imkansızlıktır. Tüm tip kontrolünü çalışma süresine ertelemenin iyi bir şey olduğunu savunmak, hataların geliştirme sürecinde mümkün olduğunca erken yakalanması gerektiği ile devekuşu taktikleri oynamaktır.


37
"yöntem yakalama, dinamik yükleme, mobil kod, çalışma zamanı yansıması" hepsi sadece kayıt için Java'da yapılabilir.
Will Hartung

13
Fantom tipleri "aşırı derecede karmaşık" değildir.
Jon Harrop

12
Meijer gazetesine bağlantı 16.05.2010 tarihi itibariyle kesilmiştir.
jchadhowell

5
@jchadhowell, burada öğrenebilirsiniz. araştırma.microsoft.com/
tr-tr/um/people/emeijer/Papers/…

4
@VinkoVrsalovic Tip çıkarımı ve polimorfizmi olan statik diller hızlı prototipleme için oldukça iyidir. Dinamik dil ve statik dillerin güvenliği ile aynı konforu sunarlar.
Edgar Klerks

119

Statik tip sistemler, belirli hataları statik olarak ortadan kaldırmaya, programı çalıştırmadan kontrol etmeye ve belirli açılardan sağlamlığı kanıtlamaya çalışır. Bazı tip sistemler diğerlerinden daha fazla hata yakalayabilir. Örneğin, C # düzgün kullanıldığında boş gösterici istisnalarını ortadan kaldırabilirken, Java'nın böyle bir gücü yoktur. Twelf, ispat sorununun sona erdirileceğini , durdurma problemini " çözeceğini " garanti eden bir tip sistemine sahiptir .

Ancak hiçbir tip sistem mükemmel değildir. Belirli bir hata sınıfını ortadan kaldırmak için, kuralları ihlal eden bazı mükemmel geçerli programları da reddetmeleri gerekir. Bu yüzden Twelf durma problemini gerçekten çözmez, sadece garip yollarla sona eren çok sayıda mükemmel geçerli kanıtlar atarak bunu önler. Benzer şekilde, Java'nın tür sistemi PersistentVectorheterojen diziler kullanması nedeniyle Clojure'un uygulanmasını reddeder . Çalışma zamanında çalışır, ancak tür sistemi bunu doğrulayamaz.

Bu nedenle, çoğu tip sistem statik kaçırıcının geçersiz kılınması için "kaçışlar" sağlar. Çoğu dil için bunlar döküm biçimini alır, ancak bazılarının (C # ve Haskell gibi) "güvensiz" olarak işaretlenmiş tüm modları vardır.

Öznel olarak statik yazmayı seviyorum. Düzgün uygulandığında (ipucu: Java değil ), statik bir tür sistemi, üretim sistemini çökertmeden önce hataları ayıklamak için çok büyük bir yardımcı olabilir. Dinamik olarak yazılan diller, en iyi ihtimalle sıkıcı olan daha fazla birim testi gerektirir. Ayrıca, statik olarak yazılan diller, dinamik yazım sistemlerinde imkansız veya güvensiz olan bazı özelliklere sahip olabilir ( örtülü dönüşümler akla ilk gelen). Her şey bir ihtiyaçlar ve öznel tat meselesi. Artık Ruby'de bir sonraki Eclipse'i derlemede yedek komut dosyası yazmaya veya Java kullanarak bir çekirdeği yamalamaya çalışmam.

Oh, ve " x yazmanın y yazmadan 10 kat daha verimli " olduğunu söyleyen insanlar sadece duman üfler. Dinamik yazma birçok durumda daha hızlı "hissedebilir", ancak fantezi uygulamanızı çalıştırmaya çalıştığınızda bir kez daha kaybeder . Benzer şekilde, statik yazma mükemmel güvenlik ağı gibi görünebilir, ancak Java'daki daha karmaşık genel tür tanımlarından bazılarına bir bakış, göz körlüğü için koşan çoğu geliştiriciyi gönderir. Tip sistemleri ve üretkenlikle bile gümüş mermi yoktur.

Son not: statik ile dinamik yazmayı karşılaştırırken performans konusunda endişelenmeyin. V8 ve TraceMonkey gibi modern JIT'ler statik dil performansına tehlikeli bir şekilde yaklaşıyor. Ayrıca, Java'nın aslında doğası gereği dinamik bir ara dile derlediği gerçeği, çoğu durumda dinamik yazmanın, bazı insanların ortaya çıkardığı büyük performans katili olmadığı bir ipucu olmalıdır.


5
Performans hakkında. Yaygın durumlarda bu kadar büyük bir fark yaratmaz, ancak yüksek gerilimli matematiklerde ve benzerlerinde gerçek bir fark vardır. Testler, bir işlev çağrısı olduğunu kanıtladı, ipy vs C # durumunda, bin döngü ile farklı. Birincisinin bir yöntemin var olduğundan emin olması gerektiğinden.
Dykam

29
"C # düzgün kullanıldığında boş gösterici istisnalarını ortadan kaldırırken Java'nın böyle bir gücü yok." ? Bir örnek veya alıntı çok takdir edilecektir.
Srinivas Reddy Thatiparthy

13
"Java'daki daha karmaşık genel tür tanımlarından bazıları, çoğu geliştiriciyi göz körlüğü için koşturuyor" - bu en kötü durum örneğinizse, açıkçası C ++ ;-) kullanmadınız
bacar

3
"Ayrıca, Java'nın aslında doğası gereği dinamik bir ara dile derlenmesi, çoğu durumda dinamik yazmanın, bazı insanların bunu yaptığı büyük bir performans katili olmadığı konusunda bir ipucu olması gerekir." - "iyi performans" içeren bir dil örneğiniz Java olduğunda, yeniden düşünmek isteyebilirsiniz.
Yakk - Adam Nevraumont

" Java, doğası gereği dinamik bir ara maddeye kadar derler ." Statik kontroller önceden gerçekleştirilmiştir ve bu nedenle derleyici dadd, işlenenlerin önceden olduğunu bildiği için talimatlar seçtiği için bunları kapsayan ek çalışma süresi kontrolü gerekmez double.
Michael Beer

45

Her ikisi de çok, çok çok çok yanlış anlaşıldı ve aynı zamanda tamamen farklı iki şey. bu birbirini dışlayan değil .

Statik türler dilin dilbilgisinin bir kısıtlamasıdır. Statik olarak yazılan diller kesinlikle bağlamsız değildir. Basit gerçek şu ki, tüm verilerini basitçe bit vektörleri olarak ele almayan, bağlamsız gramerlerde bir dili akılcı bir şekilde ifade etmek zorlaşır. Statik tip sistemler, dilin dilbilgisinin bir parçasıdır, basitçe onu bağlamsız bir gramerden daha fazla sınırlar, böylece gramer kontrolleri kaynak üzerinde iki geçişte gerçekleşir. Statik tipler, tip teorisinin matematiksel kavramına karşılık gelir, matematikteki tip teorisi bazı ifadelerin yasallığını kısıtlar. 3 + [4,7]Matematikte söyleyemem , bunun nedeni onun tür teorisinden kaynaklanıyor.

Bu nedenle statik türler teorik bir bakış açısıyla 'hataları önlemenin' bir yolu değildir, dilbilgisinin bir sınırlamasıdır. Gerçekten, +, 3 ve aralıkların olağan ayarlanmış teorik tanımlara sahip olması şartıyla, eğer tip sistemini kaldırırsak, 3 + [4,7]oldukça iyi tanımlanmış bir sonuç kümesi vardır. 'çalışma zamanı türü hataları' teorik olarak mevcut değildir, tür sisteminin pratik kullanımı, insanların hiçbir anlam ifade etmeyeceği işlemleri önlemektir . İşlemler hala sadece elbette bitlerin değiştirilmesi ve manipüle edilmesidir.

Buradaki yakalama, bir tür sistemin bu tür işlemlerin gerçekleşip gerçekleşmeyeceğine karar verememesidir. Olduğu gibi, tüm olası programları bir 'tür hatası' olacak olan ve olmayan programlara bölün. Sadece iki şey yapabilir:

1: bir programda tür hatalarının oluşacağını
kanıtlayın 2: bir programda oluşmayacaklarını kanıtlayın

Bu kendimle çelişiyormuşum gibi görünebilir. Ama bu kuralsız 'gibi bir program reddeder, ya da 'türü hatası' o takdirde deyimiyle ne C veya Java tipi denetleyicisi yapmasıdır edemez , 2 de başarılı Onlar meydana gidiş değildir ispat edemez bu gerçekleşmeyecekleri anlamına gelmez, sadece kanıtlayamayacağı anlamına gelir. Tür hatası olmayan bir programın derleyici tarafından kanıtlanamaması nedeniyle reddedilmesi çok iyi olabilir. Basit bir örnekif(1) a = 3; else a = "string";, elbette her zaman doğru olduğundan, else-branch hiçbir zaman programda yürütülmez ve hiçbir tür hata oluşmaz. Ancak bu davaları genel olarak kanıtlayamaz, bu yüzden reddedilir. Bu, statik olarak yazılmış birçok dilin en büyük zayıflığıdır, sizi kendinize karşı korurken, ihtiyacınız olmadığı durumlarda da mutlaka korunursunuz.

Ancak, popüler inanışın aksine, ilke 1'de çalışan statik olarak yazılmış diller de vardır. Sadece bir tür hataya neden olacağını kanıtlayabilecekleri tüm programları reddederler ve yapamayacakları tüm programları geçerler. Bu nedenle, tip hataları olan programlara izin vermeleri mümkündür, bunun iyi bir örneği Yazılı Raket, dinamik ve statik yazım arasında melezdir. Ve bazıları bu sistemde her iki dünyanın da en iyisini elde ettiğinizi iddia ediyor.

Statik yazmanın bir diğer avantajı, türlerin derleme zamanında bilinmesidir ve bu nedenle derleyici bunu kullanabilir. Java'da biz yaparsak "string" + "string"veya sonunda metindeki 3 + 3her iki +belirteç tamamen farklı bir işlemi ve veriyi temsil ediyorsa , derleyici yalnızca türlerden hangisini seçeceğini bilir.

Şimdi burada çok tartışmalı bir açıklama yapacağım ama bana katlanacağım: 'dinamik yazım' mevcut değil .

Çok tartışmalı Sesler, ama onun gerçek, dinamik yazılan diller teorik bir perspektiften olan türsüz . Bunlar sadece tek bir türle statik olarak yazılmış dillerdir. Ya da basitçe söylemek gerekirse, pratikte bağlamdan bağımsız bir dilbilgisi tarafından gerçekten dilbilgisel olarak üretilen dillerdir.

Neden türleri yok? Her işlem her edimsel olarak tanımlandığından ve izin verildiğinden, 'çalışma zamanı türü hatası' tam olarak nedir? Teorik bir örnekten tamamen yan etki . Yapıyor ise print("string")bir dize yazdırır hangi bir işlemdir, o zaman olduğu length(3)eski yazma yan etkisi yoktur, stringstandart çıkışa sadece ikincisi için error: function 'length' expects array as argument.bu,. Teorik bir bakış açısıyla, dinamik olarak yazılmış bir dil diye bir şey yoktur. Onlar türden değil

Tamam, 'dinamik olarak yazılan' dilin bariz avantajı ifade gücüdür, bir tür sistemi ifade gücünün sınırlandırılmasından başka bir şey değildir. Ve genel olarak, bir tür sistemi olan diller, tür sistemi göz ardı edilirse, izin verilmeyen tüm işlemler için tanımlanmış bir sonuç doğuracaktır, sonuçlar insanlara mantıklı gelmeyecektir. Birçok dil, bir tür sistemi uyguladıktan sonra Turing tamlığını kaybeder.

Bariz dezavantaj, insanlar için saçma olan sonuçlar doğuracak operasyonların gerçekleşebilmesidir. Buna karşı korunmak için, dinamik olarak yazılan diller genellikle bu işlemleri saçma bir sonuç üretmek yerine, bir hata yazma ve muhtemelen programı tamamen durdurma yan etkisine sahip olacak şekilde yeniden tanımlarlar. Bu bir 'hata' değildir, aslında, dil spesifikasyonu genellikle bunu ima eder, bu dilin teorik bir perspektiften bir dize basmak kadar çok davranışıdır. Böylece tip sistemleri programcıyı kodun akışı hakkında akıl yürütmeye zorlar ve bunun gerçekleşmemesini sağlar. Ya gerçekten, neden bu yüzden o yaparBu, hata ayıklama için bazı noktalarda da kullanışlı olabilir, bu da bunun bir 'hata' değil, dilin iyi tanımlanmış bir özelliği olduğunu gösterir. Aslında, çoğu dilin sahip olduğu 'dinamik yazmanın' tek kalıntısı sıfıra bölünmeye karşı koruma sağlamaktır. Dinamik yazım budur, tür yoktur, sıfırın diğer tüm sayılardan farklı bir tür olduğundan daha fazla tür yoktur. İnsanların 'tür' olarak adlandırdığı şey, bir dizinin uzunluğu veya bir dizenin ilk karakteri gibi bir datumun başka bir özelliğidir. Ve dinamik olarak yazılan birçok dil de böyle şeyler yazmanıza izin verir "error: the first character of this string should be a 'z'".

Başka bir şey, dinamik olarak yazılan dillerin çalışma zamanında kullanılabilir ve genellikle bunu kontrol edip onunla başa çıkıp ondan karar verebilmesidir. Tabii ki, teoride, bir dizinin ilk karakterine erişmek ve ne olduğunu görmekten farklı değildir. Aslında, kendi dinamik C'nizi yapabilirsiniz, sadece uzun uzun int gibi sadece bir tür kullanın ve 'tipinizi' kaydetmek ve şamandıra veya tamsayı ekleme işlemini yapmak için işlevlerini buna göre yazmak için ilk 8 bitini kullanın. Bir türü olan statik olarak yazılmış bir diliniz veya dinamik bir diliniz var.

Pratikte tüm bunlar, statik olarak yazılan diller genellikle ticari yazılım yazma bağlamında kullanılırken, dinamik olarak yazılan diller bazı sorunları çözme ve bazı görevleri otomatikleştirme bağlamında kullanılır. Statik olarak yazılan dillerde kod yazmak sadece uzun sürer ve zahmetlidir, çünkü iyi olacağını bildiğiniz şeyleri yapamazsınız, ancak tür sistemi hala yapmadığınız hatalar için kendinize karşı korur. Birçok kodlayıcı, bunu kendi sistemlerinde yaptıklarından bile fark etmezler, ancak statik dillerde kod yazarken, genellikle yazı sisteminin yanlış gidemeyen şeyleri yapmanıza izin vermeyeceği gerçeğini araştırırsınız, çünkü yanlış gitmeyeceğini ispatlayamaz.

Belirttiğim gibi, 'statik olarak yazılmış' genel olarak vaka 2, masum olduğu kanıtlanana kadar suçlu anlamına gelir. Ancak, tür sistemlerini tür teorisinden türetmeyen bazı diller, kural 1'i kullanır: Masum, kanıtlanmış suçluya kadar, ideal melez olabilir. Yani, belki Typed Racket tam size göre.

Ayrıca, daha saçma ve aşırı bir örnek için, şu anda 'türlerin' gerçekten bir dizinin ilk karakteri olduğu bir dil uyguluyorum, bunlar veri, 'tip', 'tip', kendisi olan veriler bir tür ve veri, bir tür olarak kendini gösteren tek veri. Türler statik olarak sınırlı değildir veya sınırlı değildir, ancak çalışma zamanı bilgilerine dayalı olarak yeni türler oluşturulabilir.


1
"Birçok dil, bir tür sistemi uyguladıktan sonra Turing tamlığını kaybeder." normal programlama dilleri için geçerli değildir, değil mi? okuduğum kadarıyla, normal diller tam değil
Răzvan Flavius ​​Panda

1
@ RăzvanPanda: Lajla muhtemelen Typed lambda hesabı veya teorem kanıtlayıcılarında kullandıkları bazı programlama dillerindeki varyasyonlardan bahsediyordu . Bunların çoğu yalnızca durması garanti edilen ve bu nedenle Turing tamamlanmayan programları ifade edebilir. Bu tip sistemlere dayanan pratik fonksiyonel programlama dilleri, çekirdek hesabı özyinelemeli tiplerle genişleterek bu sınırlamayı aşmaktadır.
hugomg

1
"Kulağa çok tartışmalı geliyor, ama doğru, dinamik olarak yazılmış diller, teorik bir bakış açısına sahip değil." - ... ve bir anda, neden bahsettiğiniz hakkında hiçbir fikriniz olmadığını biliyorum. Dinamik yazma, türlerin tanımlayıcılara değil, değerlere ait olduğu anlamına gelir. Programların kanıtlanmasını zorlaştırır, ancak mutlaka imkansız değildir. Doğrusal ve parametrik polimorfizm zaten bağlantı zamanı optimizasyonunun geliştirilmesine yol açmıştır; hangi dinamik olarak yazılan en iyi dilleri derlemek aynı sorunu çözer: olası tüm giriş ve çıkışları bilmek.
DeftlyHacked

25

Belki de dinamik yazmanın en büyük tek faydası daha sığ öğrenme eğrisidir. Öğrenilecek bir yazı sistemi ve yazım kısıtlamaları gibi köşe durumlar için önemsiz bir sözdizimi yoktur. Bu, dinamik yazmayı çok daha fazla kişi için erişilebilir hale getirir ve sofistike statik tip sistemlere erişilemeyen birçok kişi için uygun hale getirir. Sonuç olarak, dinamik yazım, eğitim bağlamında (örn. Scheme / Python at MIT) ve programcı olmayanlar için alana özgü dillerde (örn. Mathematica ) yakalanmıştır . Dinamik diller de çok az rekabete sahip oldukları veya hiç rekabet etmedikleri nişlerde yakalanmıştır (örn. Javascript).

Dinamik olarak yazılan en özlü diller (ör. Perl, APL, J, K, Mathematica ) alana özgüdür ve tasarlandıkları nişlerdeki en özlü genel amaçlı statik olarak yazılan dillerden (örneğin OCaml ) önemli ölçüde daha özlü olabilir .

Dinamik yazmanın ana dezavantajları şunlardır:

  • Çalışma zamanı türü hataları.

  • Aynı doğruluk seviyesine ulaşmak çok zor veya hatta neredeyse imkansız olabilir ve çok daha fazla test gerektirir.

  • Derleyici onaylı doküman yok.

  • Düşük performans (genellikle çalışma zamanında ancak bazen derleme zamanında, örneğin Stalin Şeması) ve gelişmiş optimizasyonlara bağımlılık nedeniyle öngörülemeyen performans.

Şahsen, dinamik dillerde büyüdüm, ancak başka uygun seçenek olmadıkça, profesyonel olarak 40 kutuplu onlara dokunmazdım.


2
Giriş için daha düşük bir engel olduğunu söyleyebilirim, ancak ustalık daha az bir öğrenme eğrisi değildir.
Erik Reppen

Öğrenecek bir yazı sisteminiz olmadığı için öğrenme eğrisi daha az değil mi?
Jon Harrop

Hala bir tür sistem var. Bir bool ve dize eklediğinizde ne olacağı konusunda makul tahminler yapabilirsiniz, ancak türlerin dinamik olarak yazılmış bir dilde nasıl zorlandığına dair bazı gerçek ayrıntıları bilmek genellikle çok yardımcı olur. Sadece katı milletlerin elde edemediği şey budur. Aslında bu şeyleri öğreniyoruz.
Erik Reppen

@ErikReppen: "Tip sistemi" nin farklı tanımlarını kullanıyoruz. Cebirsel veri türleri, jenerikler gibi statik tip bir sistem öğrenmek zorunda olmamdan bahsediyordum. Bahsettiğiniz "türler" sadece veridir. Bazı işlevlerin çalışma zamanında bazı verileri reddetmesi evrenseldir.
Jon Harrop

12

Artima'nın Yazımından : Güçlü ve Zayıf, Statik ve Dinamik makaleleri:

güçlü yazma, eşleşmeyen türler arasındaki karıştırma işlemlerini önler. Türleri karıştırmak için açık bir dönüşüm kullanmalısınız

zayıf yazma, açık bir dönüşüm olmadan türleri karıştırabileceğiniz anlamına gelir

Pascal Costanza'nın makalesinde Dinamik ve Statik Yazma - Bir Desen Tabanlı Analiz (PDF), bazı durumlarda statik yazmanın dinamik yazmadan daha hataya açık olduğunu iddia ediyor. Bazı statik olarak yazılmış diller, "Doğru Şey" i yapmak için dinamik yazmayı manuel olarak taklit etmeye zorlar. Lambda Ultimate'da tartışıldı .


1
"statik yazım, dinamik yazımdan daha fazla hataya açıktır" - Evet, evet ve ÇİFT evet! Her iki dilde de çok fazla deneyime sahibim ve her durumda dinamik dil "sadece çalışıyor", statik 2x hata ayıklama süresi gerektiriyor (Bkz. C ++ ve Delphi). Bu genellikle tip sorunlarından, özellikle de modüller ve çılgın tipli fonksiyonlar arasında veri iletilmesinden kaynaklanır. Her ne kadar teorik hatalar olsa da dinamik diller sözde neden olabilir, pratikte, dinamik türleri kötüye kullanan zayıf bir programcı değilseniz, tip zorlamasının neden olduğu bir hata ile karşılaşmak benim için çok nadirdir.
dallin

7
Birkaç yıl önce bir taslak Costanza gazetesi okudum. "Statik" yazdığı her yerde gerçekten "Java" demekti. Ona, iddialarını çürüten OCaml gibi dillerde düzinelerce karşı örnek verdim ama yine de devam etti ve yine de yayınladı. Bu makalenin görünüşüne göre, hala aynı eski saçmalığı yayınlıyor. Örneğin, bu makalede "C # genellikle Java'nın kötü bir kopyasıdır" olduğunu iddia etmektedir. Bilimsel bir makalede yeri yok ...
Jon Harrop

@dallin benim deneyim tam tersi: C, C ++, Java, Python, Perl ve benzerleri çok programlamak zorunda kaldım, zorla sürece dinamik olarak yazılmış bir dilde küçük bir tweak program daha büyük bir şey asla başlayamaz. Python'da bir WSGI projesi hakkında düşünürken hala titriyorum: overeritr yapmak zorunda olduğum geri aramalar nesnelerin referanslarında geçti ve bazen çöktüğü için kod çöktü, çünkü bazı nesneler değil, bazı temel türler olduğu ortaya çıktı. geçiliyor. Bunun gibi buggy şeyler oluşturmayı kolaylaştıran bir dil doğrudan tehlikelidir.
Michael Beer

@MichaelBeer Ayrıca C / C ++ gibi, doğrudan hafızayı yönetmenize izin veren bir dilin tehlikeli olduğunu da söyleyebilirsiniz! Kesinlikle saatlerce hafıza hatalarıyla boğuştum. Büyük Java projeleri de piknik yapmıyor. Herhangi bir dilde, dilin tehlikelerini ve iyi uygulamaları anlamanız gerekir. Şimdiye kadar üzerinde çalıştığım en kötü projeler, küçük yapıya sahip takım PHP projeleriydi, ama aynı zamanda iyi bir çerçeve ve iyi programlama uygulamaları kullandıklarında rüya olan dinamik dillere sahip projeler üzerinde de çalıştım.
dallin

@dallin Anlaştı, her dil kendi tuzaklarını aldı. Ancak bahsettiğim kusurlar, dinamik olarak yazılan herhangi bir dile özgüdür, hafızayı doğrudan manipüle etme olasılığı, statik olarak yazılan dillerin doğal bir özelliği değildir. Mem'i doğrudan değiştirmenize izin veren dinamik olarak yazılan dilleri hayal edebilirsiniz. C ++ 'ın düz bir felaket olduğuna katılıyorum, dilin mucidi bu gezegendeki tek bir kişinin dilin tüm bölümlerini bilemediğine inanıyor. Ancak, bu statik olarak yazılan C ++ 'dan sorumlu tutulamaz, ancak 30 yıldan beri büyüyen bir canavar ...
Michael Beer

3

Bağlama bağlıdır. Güçlü yazımın yanı sıra dinamik yazım sistemine uygun birçok fayda vardır. Dinamik türler dilinin akışının daha hızlı olduğunu düşünüyorum. Dinamik diller sınıf nitelikleri ve derleyicinin kodda neler olup bittiğini düşünmesi ile sınırlı değildir. Biraz özgürlüğün var. Dahası, dinamik dil genellikle daha ifade edicidir ve daha az kodla sonuçlanır, bu da iyidir. Buna rağmen, daha fazla hataya eğilimlidir ve bu da sorgulanabilir ve daha çok birim test kaplamasına bağlıdır. Dinamik şeritli kolay prototip, ancak bakım kabus haline gelebilir.

Statik tipli sisteme göre ana kazanç IDE desteği ve kodun statik statik analizörüdür. Her kod değişikliğinden sonra koddan daha emin olursunuz. Bakım, bu tür aletlerle pasta huzurudur.


0

Statik ve dinamik diller hakkında birçok farklı şey vardır. Benim için temel fark, dinamik dillerde değişkenlerin sabit tiplere sahip olmaması; bunun yerine, türler değerlere bağlıdır. Bu nedenle, çalıştırılan tam kod çalışma zamanına kadar belirsizdir.

Erken ya da naif uygulamalarda bu büyük bir performans sürüklemesidir, ancak modern JIT'ler statik derleyicileri optimize ederek elde edebileceğiniz en iyilere yakın bir şekilde yaklaşmaktadır. (bazı saçak durumlarda, bundan daha iyi).


0

Her şey iş için doğru araçla ilgilidir. İkisi de% 100 daha iyi değildir. Her iki sistem de insan tarafından yaratılmış ve kusurları var. Üzgünüm, ama emiyoruz ve mükemmel şeyler yapıyoruz.

Dinamik yazmayı seviyorum çünkü yolumdan çıkıyor, ancak evet çalışma zamanı hataları planlayamadığım kadar sürünebilir. Statik yazım olarak yukarıda belirtilen hataları düzeltebilir, ancak sabit bir karakter ve bir dize arasında döküm yapmaya çalışan bir acemi (yazılı dilde) programcı çılgınını sürün.


-3

Statik Yazma: Java ve Scala gibi diller statik yazılmıştır.

Değişkenler bir kodda kullanılmadan önce tanımlanmalı ve başlatılmalıdır.

örneğin. int x; x = 10;

System.out.println (x);

Dinamik Yazma: Perl dinamik yazılan bir dildir.

Değişkenlerin kodda kullanılmadan önce başlatılması gerekmez.

y = 10; bu değişkeni kodun sonraki bölümünde kullan


5
Bunun tür sistemiyle ilgisi yoktur.
Thiago Negri
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.