Dinamik ve statik olarak yazılmış dil çalışmaları


69

Dinamik olarak yazılan ve statik olarak yazılmış dillerin etkinliği konusunda yapılan çalışmalar var mı?

Özellikle:

  • Programcı verimliliğinin ölçülmesi
  • Kusur oranı

Ayrıca, birim testinin yapılıp yapılmayacağının etkilerini de içerir.

Her iki tarafın yararları hakkında çok fazla tartışma gördüm, ancak birisinin üzerinde bir çalışma yapıp yapmadığını merak ediyorum.


8
@bigown, verimlilik ve kusur konularının bilgisayar bilimleri teorisi ile ilgili olduğu bana görünmüyor
Winston Ewert

2
@Winston: Bu tür meseleleri incelemek programcıların değil bilgisayar bilimcilerin işi.
Maniero

9
@bigown, evet onun bir bilgisayar bilimi sorunu ama bilgisayar bilimleri teorisi sorunu değil. CS teorisi temel olarak programlar ve bilgisayar hakkında matematiksel olarak kanıtlayabildiklerimizle ilgilenir. Programcı verimliliğinin sorunları cs teorisi soruları değildir. Hem burada hem de yığın akışında dinamik yazma tartışmaları yapıldı. Cstheory'de hiçbir şey olmadı.
Winston Ewert

8
Soru tamamen konuyla ilgili. Bu soru programlamak için kullandığımız araçların en önemli özelliklerinden birini tartışıyor.
Frank Shearar

4
@ Winston: Yazma sistemleri CS teorisine aittir, ancak pratik çalışmalar yapmaz.
David Thornley

Yanıtlar:


42

Bazı önerilen okumalar:

Tam olarak statik yazarken değil, ilgili:

Konuyla ilgili veya genel olarak programların statik analizine ilişkin bazı ilginç makaleler veya makaleler:

Ve bunun neyle ilgili olduğunu merak edenler için:

Bununla birlikte, aradığınız hiçbir şeyi yapamadıkları için size doğrudan bir cevap vereceklerinden şüpheliyim. Ancak ilginç okurlar.

Şahsen, Dinamik yazarak statik yazmanın hata algılamasını kolaylaştırdığını düşünüyorum. Ben yazım hataları ve bunun gibi küçük hatalar JavaScript ya da Ruby koduna bakarak çok fazla tür harcamak. Dinamik Typing'in size üretkenliği artırdığı görüşüne gelince, bunun çoğunlukla takımlaşmaya bağlı olduğunu düşünüyorum. Statik olarak yazılmış diller, arka plan yeniden derlemeye izin vermek ve bir REPL arayüzü sağlamak için doğru araçlara sahipse, o zaman her iki dünyanın da faydalarını elde edersiniz. Scala bunu örneğin interaktif konsolda öğrenmeyi ve prototiplemeyi çok kolaylaştıran, ancak statik yazmanın (ve bir çok dilden çok daha fazla ML-dilinden daha güçlü bir tipte sistem) faydaları sağlayan, bunu sağlar. Benzer şekilde, Java veya C ++ kullanarak (statik yazım nedeniyle) verimlilik kaybım olduğunu sanmıyorum, Bana yardımcı olacak bir IDE kullandığım sürece. Yalnızca basit yapılandırmalarla kodlamaya geri döndüğümde (editör + derleyici / yorumlayıcı), daha hantal hissettiriyor ve dinamik dillerin kullanımı daha kolay görünüyor. Ama yine de böcek avlıyorsun. Sanırım insanlar takım meselesi, takımlar dinamik diller için daha iyiymiş gibi geri dönüşümlü bir argüman olduğunu söyler, daha sonra birçok hata ve yazım hatası kodlama zamanında gösterilecektir, ama bu benim görüşüme göre sistemdeki açığı yansıtıyor. Yine de, genellikle JRuby'de prototip yapıyorum ve daha sonra Java'da yaptığım işlerin çoğunu kodlayacağım. Takımlar dinamik diller için daha iyi olsaydı, kodlama zamanında çoğu hata ve yazım hatası belirtilirdi, ancak bu bence sistemdeki hatayı yansıtıyordu. Yine de, genellikle JRuby'de prototip yapıyorum ve daha sonra Java'da yaptığım işlerin çoğunu kodlayacağım. Takımlar dinamik diller için daha iyi olsaydı, kodlama zamanında çoğu hata ve yazım hatası belirtilirdi, ancak bu bence sistemdeki hatayı yansıtıyordu. Yine de, genellikle JRuby'de prototip yapıyorum ve daha sonra Java'da yaptığım işlerin çoğunu kodlayacağım.

UYARI: Bu bağlantıların bazıları güvenilmezdir ve bazıları üyelere ücrete dayalı erişim kullanarak çeşitli bilgisayar topluluklarının portallarından geçer. Bunun için üzgünüm, her biri için birden fazla bağlantı bulmaya çalıştım, ancak olmasını istediğim kadar iyi değil.


Bu hata bulma - temelde yanlış hecelenen değişken isimleri veya metot isimleri veya aralarında bir yer var mı? ( Tam olarak bu nedenden ötürü örtük değişken bildirgesinden nefret ediyorum : Smalltalk'ta, tüm değişkenlerinizi en üste bildirirsiniz, bu nedenle değişken adını yanlış yazdığınızda derhal bilirsiniz. Daha önce görüntüde kullanılmıştır.))
Frank Shearar

Takım olarak, dilinize bağlı olduğunu söylemeliyim - Smalltalk, Eclipse’in (söyleneni) henüz yakalayamadığı bir Refactoring Tarayıcı da dahil olmak üzere mükemmel araçlara sahiptir.
Frank Shearar

@ Frank Shearar, Ruby ile başladığımdan beri (Java'dan geliyor), @ haylem'in söylediklerinin muhtemelen Smalltalk için geçerli olmadığını farkettim. Dinamik olarak yazılan dillerde otomatik yeniden yapılandırmanın imkansız olması konusundaki mantrım da yok. Haylem'in "şahsen" bölümüne tamamen katılıyorum .... SmallTalk'u görmezden gelmek elbette :) :) Bu, bir dereceye kadar adil, çünkü SmallTalk ölmese de Python veya Ruby'nin popülerliğini beğenmiyor (şimdi Ekim 2010'da) ).
Dan Rosenstark

3
@ haylem, şahsen bana dinamik dillerde çalışan dünyadaki tek kişi olmadığımı hissettirdiğin için teşekkür ederim ama bir seçim yapıldığında, çoğu zaman statik olarak yazılmış dilleri (aynı dava, Java vs. JRuby veya Groovy).
Dan Rosenstark

4
Bu ilginç çünkü dinamik yazma konusundaki tercihim oldukça farklı nedenlerden dolayı. Hızlı derlemeler ve etkileşimli tercüman yararlıdır, ancak dinamik yazmayı sevme nedenlerim değildir. Dinamik yazmayı seviyorum çünkü statik yazım dillerinin belirli bir kavramı tanımlamayı imkansız hale getirdiği birçok durum buluyorum.
Winston Ewert

19

Daha dün, bu çalışmayı buldum: Birim testi yeterli değil. Statik yazmaya da ihtiyacınız var.

Temel olarak yazar otomatik olarak bir projeyi statik olmayan bir yazım dilden statik bir yazı yazısına (python'dan haskell) dönüştürebilen bir araç kullandı.

Ardından, makul miktarda test ünitesi içeren bir dizi açık kaynaklı Python projesi seçti ve bunları otomatik olarak haskell'e çevirdi.

Haskell'e yapılan çeviri, değişkenlerin türüyle ilgili bir dizi hata ortaya çıkardı: hatalar test birimleri tarafından keşfedilmedi.


4
Dinamik yazmanın rahatsız edici gerçeği.
Den

6
"Haskell'e yapılan çeviri, değişkenlerin türüyle ilgili bir dizi hata ortaya çıkardı: hatalar test birimleri tarafından keşfedildi.": Dinamik olarak yazılmış bir dille, kodunuzun özelliklerini statik olarak test etmek zorundasınız. tipi dil derleyici tarafından otomatik olarak kontrol edilir. Bu hem zaman alıcı hem de hataya açıktır. +1
Giorgio

4
Reddit'teki bu linkteki bir mesaja cevap verdim. Gazeteden çıkarılan sonuçların makul olduğunu sanmıyorum.
Veedrac

Her iki daktilo sisteminin pro / cons ve kullanımları vardır. Bir makineli tüfek el-el-dövüş getirmek hakkında tartışmak gibi bir şey. Bu, çok uzak bir din savaşı. Bu, Veedrac ile aynı fikirdeyim dedi. Statik olmayan diller, türlerin neden olduğu hataları yakalamak için daha fazla test durumuna ihtiyaç duyar. Bu onların doğası ve aleyhtarı. Ancak, bir programcının, giriş türü için mutlaka kapsamlı bir test değil, beklenmeyen bir giriş durumundan kaynaklanan kodda hata yakalayan bir test yazması gerekir.
Andre Figueiredo

10
  • Stephan Hanenberg makalesinde (önceki yazıdaki Lorin Hochstein tarafından referans alınmıştır) ACM makalesinin “ Statik ve Dinamik Tip Sistemler Üzerine Bir Deney ” (2010) tartışmasına bağlantı .
  • Sonuç: Benzer kalitede üretkenlik dinamik bir dilde daha yüksekti.
  • Potansiyel önyargılar / geçerlilik sorunları: Deneysel denekler tüm öğrencilerdi. Ayrıca, programlama görevlerinin çeşitliliği de sınırlıdır (deneklerden tarayıcı ve ayrıştırıcı uygulaması istenmiştir).
  • ACM makalesi " Programlama Dilleri Verimliliği Etkiliyor mu? " (2007) Delorey, Knudson ve Chun.
  • Sonuç: JavaScript, Tcl, Perl, C # C ++ ve Java'dan daha üretken. Python ve PHP ortasına düşer.
  • Potansiyel önyargılar / geçerlilik sorunları: Kalite ölçüsü yok (sürüm sonrası keşfedilen böcekler gibi). Güvenilirlik ölçüsü yok (statik olarak yazılmış dillerde yazılmış yazılımlar daha güvenilir midir?). Örnek önyargı - tüm projeler açık kaynak CVS havuzlarından alındı. Ayrıca, zayıf ve güçlü yazılan diller (örneğin, işaretçiler) arasında hiçbir ayrım yoktur.
  • Tez " Yazılım Üretkenliği ve Kalitesine İlişkin Ampirik Çalışma " (2008) tarafından Michael F. Siok
  • Sonuç: Programlama dili seçimi, üretkenliği veya kaliteyi önemli ölçüde etkilemez. Bununla birlikte, işgücü maliyetlerini ve "genel yazılım projeleri portföyündeki kaliteyi" etkilemektedir.
  • Potansiyel önyargılar / geçerlilik sorunları: Aviyonik etki alanı ile sınırlıdır. Programlama dilleri statik olarak yazılmış olabilir. Tezi okumadım, bu yüzden titizliğini değerlendiremiyorum.
    Benim fikrim. Dinamik olarak yazılmış dillerin daha üretken olduğuna dair zayıf kanıtlar olmasına rağmen, kesin değildir. (1) Kontrol edilemeyen birçok faktör var, (2) çok az sayıda çalışma var, (3) uygun bir test yöntemini neyin oluşturduğu konusunda çok az tartışma yapıldı veya hiç tartışma olmadı.

6

İşte bir başlangıç ​​noktası:

Bu makale, programcıların dilden bağımsız olarak zaman içerisinde aynı sayıda satır satırı yazdıkları genel olarak alınan bilgeliği zorlamaktadır. Başka bir deyişle, makale, mekanik verimliliğin (yazılı kod satırları) işlevsel verimliliğin iyi bir ölçütü olmadığı ve en azından dil tarafından normalleştirilmesi gerektiğine dair deneysel kanıtları desteklemelidir .


5
IEEE üyesi olmayan insanlar için temel özet nedir?
Frank Shearar

1
@ Frankrarrar, çizdikleri sonuç, programlama dilinin verimliliği etkilediğidir. Her yıl dil başına programcı başına kod satırlarını ölçüyorlar, bunun iyi bir verimlilik ölçüsü olduğundan emin değilim.
Winston Ewert

3
@ Winston: Bu kesinlikle hatalı bir ölçümdür. COBOL'u çok üretken bir dil olarak bulacaksınız: faydalı bir şeyler yapmak çok fazla satır gerektiriyor, ancak yazması oldukça kolay.
David Thornley

Winston, David: Yazarların kod satırı üretkenliğinin işlevsel üretkenlik ölçüsü olduğunu önermediğinden eminim . Daha ziyade, bildiri, programcıların dilden bağımsız olarak zaman içerisinde aynı sayıda kod satırı yazdıkları genel olarak alınan bilgeliği zorlamaktadır. Başka bir deyişle, makale, mekanik verimliliğin (yazılı kod satırları) işlevsel verimliliğin iyi bir ölçütü olmadığı ve en azından dil tarafından normalleştirilmesi gerektiğine dair deneysel kanıtları desteklemelidir .
Pi Delport

Buna katılıyorum. Ama asıl soruma cevap vermiyor.
Winston Ewert

1

Statik ve dinamik diller buldum : konuyla ilgili bazı çalışmaları listeleyen ve her çalışma hakkında güzel bir özet veren bir literatür taraması .

İşte yönetici özeti:

Kontrollü deneylerden sadece üçü pratik öneme sahip olacak kadar büyük bir etki göstermektedir. C, C ++, Java, Perl, Python, Rexx ve Tcl'yi karşılaştıran Prechelt çalışması; Java ve Dart'ı karşılaştıran Endrikat çalışması; ve Cooley'nin VHDL ve Verilog ile olan deneyi. Ne yazık ki, hepsinde gerçekten güçlü bir sonuç çıkarmayı zorlaştıran konular var.

Prechelt çalışmasında, nüfuslar dinamik ve yazılı diller arasında farklıydı ve görevlerin koşulları da farklıydı. Lispers'ı, kendi çözümlerini bulmaya davet ederek, Darius Bacon gibi insanların rastgele öğrencilerle karşılaştırılmasını içeren bir örnekleme çalışması yapıldı. İzlemenin takibi, kelimenin tam anlamıyla Peter Norvig ile kod arasında rastgele üniversite öğrencilerinin kodlarının karşılaştırılmasını içerir.

Endrikat çalışmasında, özellikle statik yazmanın bir fark yaratacağını düşündükleri bir görev seçtiler ve konularını herkesin statik olarak yazılmış dili kullanarak ders aldığı bir popülasyondan çektiler. Öğrencilerin dinamik olarak yazılmış bir dilde deneyime sahip olup olmadıkları hakkında yorum yapmazlar, ancak dinamik olarak yazılmış bir dilde en çok veya daha az deneyime sahip olduğunu varsaymak güvenli görünmektedir.

Cooley'nin deneyi, insanları öğrenci olmayan bir popülasyondan çeken birkaç kişiden biriydi. Ancak, diğer tüm deneylerde olduğu gibi, görev önemsiz bir oyuncak görevidir. VHDL (statik dil) katılımcılarının hiçbirinin bu görevi zamanında tamamlayamamış olması çok üzücü gözükse de, bir okul projesinin dışında 1,5 saat içinde bir donanım tasarımını bitirmek çok nadirdir. Büyük bir görevin daha küçük görevlere bölünebileceğini iddia edebilirsiniz, ancak makul bir karşı koyma VHDL kullanarak birçok görevde itfa edilebilecek sabit maliyetlerin olduğunu söyler.

Deneylerin geri kalanı ile ilgili olarak, onlardan elimde olan ana paket, çalışmalarda açıklanan belirli koşullar altında, eğer varsa, herhangi bir etkinin küçük olmasıdır.

Örnek olay incelemelerine geçildiğinde, iki hata bulma olay incelemesi ilginç okumalar yapar, ancak türler için veya aleyhte dava açmazlar. Birincisi, Python programlarının Haskell'e kopyalanmasının, hat kapsamı yönelimli ünite testlerinde bulunamayan sıfır olmayan, bilinmeyen şiddette bir hata sayısı bulacağını göstermektedir. Erlang gazetelerinin çifti, statik analiz kullanarak, bazıları ciddi olan herhangi bir test sırasında bulması zor olan bazı hataları bulabileceğinizi gösteriyor.

Bir kullanıcı olarak, ayrı statik analiz araçlarını çalıştırmadan önce derleyicim bana bir hata verdiğinde uygun buluyorum, ancak yukarıda listelenen kontrollü çalışmaların etki boyutundan daha küçük, hatta küçük.

0install örnek olay incelemesini (çeşitli dilleri Python'la karşılaştıran ve sonunda Ocaml'a yerleşti) karşılaştığım en ilginç şeylerden biri olarak buldum, ancak bu, herkesin farklı şekilde yorumlayabileceği, bakarken görebileceğiniz türden öznel bir şey. .

Bu benim sahip olduğum izlenimime uyuyor (dünyanın küçük köşesinde ACL2, Isabelle / HOL ve PVS en çok kullanılan ispatlar ve insanların endüstride problem çözerken daha fazla otomasyon tercih etmeleri mantıklı geliyor), ama bu ayrıca öznel.

Ve sonra mevcut projelerden veri madenciliği yapan çalışmalar var. Ne yazık ki nedensellik belirlemek için bir şey yapan kimseyi bulamadım (örneğin uygun bir enstrümantal değişken bulmak), bu yüzden sadece korelasyonları ölçtüler. Korelasyonların bazıları beklenmedik ama nedenini belirlemek için yeterli bilgi yok.

Daha fazla keşfedilmeden potansiyel olarak ilginç veriler sunan tek veri madenciliği çalışması, Smallshire'un Python hatalarını incelemesidir, ancak çalışmasının gerçekte ne anlama geldiğini anlamak için metodoloji hakkında yeterli bilgi yoktur ve araştırmaya neden aradığını ima ettiği açık değildir. verileri sunmadan diğer diller için veriler3.

Çalışmalardan kayda değer bazı eksiklikler, deneyimli programcıları kullanan kapsamlı çalışmalardır, tek başına büyük “iyi” veya “kötü” programcı popülasyonuna sahip olan çalışmaları, önemli bir projeye yaklaşan herhangi bir şeye bakmayı (üç aylık bir projeye yaklaşırken) küçük kabul edilir, ancak kontrollü bir çalışmada kullanılan herhangi bir projeden daha büyük büyüklük dereceleridir), “modern” statik olarak yazılmış dilleri kullanarak, kademeli / isteğe bağlı yazmayı kullanarak, modern ana IDE'leri (VS ve Eclipse gibi) kullanarak, modern radikal IDE'leri kullanarak (LightTable gibi), eski okul editörlerini kullanarak (Emacs ve vim gibi), önemsiz olmayan bir kod tabanında bakım yapmak, gerçekçi bir ortama benzer herhangi bir şeyle bakım yapmak, zaten aşina olduğunuz bir kod tabanında bakım yapmak, vb.

Bu çalışmalarla ilgili internette yorum yaparsanız, çoğu bir bakış açısını ya da diğerini haklı çıkarmak için etrafta geçirilir. Dinamik ve statik ile ilgili Prechelt çalışması, Lisp'in takipleri ile birlikte, dinamik dil savunucularının çok yıllık favorileridir ve github madenciliği çalışması, son zamanlarda fonksiyonel programcılar arasında popüler olmuştur.


0

Dürüst olmak gerekirse Statik vs Dinamik yazarak gerçek bir soru olduğunu sanmıyorum.

Önce gelmesi gereken iki parametre olduğunu düşünüyorum:

  • dilin uzmanlık seviyesi: ne kadar deneyimli olursanız, "gotchas" hakkında ne kadar fazla şey bilirseniz ve onlardan kaçınmanız / onları kolayca takip etmeniz o kadar olasıdır. Bu, üzerinde çalıştığınız uygulama / program için de geçerlidir.
  • Test: Statik yazmayı seviyorum (C ++ 'da programlamayı seviyorum: p) ama orada bir derleyici / statik analizcinin sizin için yapabileceği çok fazla şey var. Test etmeden bir program hakkında kendinize güvenmeniz imkansızdır. Ve ben hepimiz bulanık testler için (uygun olduğunda), çünkü tüm olası giriş kombinasyonlarını düşünemezsiniz.

Eğer dilde rahatsanız, kod yazacaksınız ve hataları kolaylıkla takip edebileceksiniz.

Ayrıştırılmış kod yazarsanız ve her bir işlevi kapsamlı bir şekilde test ederseniz, iyi bilenmiş kodlar üreteceksiniz ve böylece üretken olacaksınız (çünkü ürünün kalitesini değerlendirmezseniz, verimli olarak nitelenemezsiniz, değil mi? )

Bu nedenle, üretkenlikle ilgili statik ve dinamik tartışmaların oldukça tartışmalı olduğunu ya da en azından diğer düşünceler tarafından büyük ölçüde yerini aldığını düşünüyorum.


2
Bu bir karşı soru ise, soru nerede? :) Dinamik ve dinamik yazmadan diğer faktörlerin daha önemli olduğuna katılıyorum. Bununla birlikte, dinamik yazma savunucuları daha iyi verimlilik talep eder ve statik yazma savunucuları daha iyi kod kalitesi talep eder. Birilerinin iddialarını destekleyecek gerçek kanıtları olup olmadığını merak ediyordum.
Winston Ewert

@Winston: Sayaç bitini çıkardım: p Bahsettiğiniz gibi çoğunlukla iddia ediyor. Bence dinamik yazım savunucularının çoğu, kullanım kolaylığı çoğunlukla araçlarla ilgiliyken, kullanım kolaylığı ile dinamik yazımın karıştırılması olduğunu düşünüyorum. Hızlı atma prototipleri yazma ve bir tercüman kullanarak kısa komutlar deneme olasılığının verimlilik artışı olduğunu kabul ediyorum, ancak Haskell'in bile (o anın en etkileyici tip sistemi olan dil) hızlı deneme için bir tercümana sahip olduğunu kabul ediyorum: )
Matthieu M.

Ancak birisi aslında bu soruyu düşünen bir araştırma yapana kadar - metodoloji, araçların hata oranlarından, üretkenlikten dilden daha büyük bir etkiye sahip olup olmadığına bakalım - sadece fıkraları karşılaştırmaya başladık.
Frank Shearar

0

Burda biraz var:

  • Stefan Hanenberg. 2010. Statik ve dinamik tip sistemler hakkında bir deney: statik tip sistemlerin gelişim süresi üzerindeki olumlu etkisinden şüphe ediyor. ACM'nin Uluslararası Amaçlı Konferansı, Nesneye Dayalı Programlama Sistemleri Dilleri ve Uygulamaları Konferansı (OOPSLA '10). ACM, New York, NY, ABD, 22-35. DOI = 10.1145 / 1869459.1869462 http://doi.acm.org/10.1145/1869459.1869462

  • Daniel P. Delorey, Charles D. Knutson, Scott Chun, "Programlama Dilleri Verimliliği Etkiliyor mu? Açık Kaynaklı Projelerden Veri Kullanan Bir Vaka Çalışması," ipi, s. '07: ICSE Atölyeleri 2007), 2007

  • Daly, M .; Sazawal, V., Foster, J .: Devam Eden Çalışmalar: Ruby'de Statik Yazma Üzerine Ampirik Bir Çalışma, ON-WARD 2009'da Programlama Dillerinin ve Araçlarının Değerlendirilmesi ve Kullanılabilirliği Çalıştayı (PLATEAU).

  • Lutz Prechelt ve Walter F. Tichy. 1998. Prosedür Bağımsız Değişken Tür Kontrolünün Faydalarını Değerlendirmek için Kontrollü Bir Deney. IEEE Trans. Softw. Müh. 24, 4 (Nisan 1998), 302-312. DOI = 10.1109 / 32.677186 http://dx.doi.org/10.1109/32.677186

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.