Dinamik yazılan diller tüm eleştiriyi hak ediyor mu? [kapalı]

İnternette programlamada dil seçimi hakkında birkaç yazı okudum. Son zamanlarda birçok dinamik yazı dili popülerdi, örneğin Ruby, Python, PHP ve Erlang. Ancak birçok işletme halen C, C ++, C # ve Java gibi statik yazılmış dillerle kalmaktadır.

Ve evet, statik yazılı dillerin yararlarından biri, programlama hatalarının derleme zamanında, çalışma zamanında değil, daha önce yakalanmasıdır. Ancak dinamik yazılı dillerin de avantajları var. ( Wikipedia'da daha fazlası )

İşletmelerin Erlang, Ruby ve Python gibi dilleri kullanmaya başlamamalarının ana nedeni, dinamik tipte olmaları gibi görünüyor. Bu aynı zamanda StackOverflow'taki insanların Erlang aleyhine karar vermelerinin ana nedeni gibi görünüyor. Bkz Neden Erlang "karşı" karar yaptılar .

Ancak, işletmelerde dinamik yazmaya karşı güçlü bir eleştiri var gibi görünüyor, ancak bunun neden bu kadar güçlü olduğunu anlamıyorum .

Gerçekten, işletmelerde dinamik yazmaya karşı neden bu kadar çok eleştiri var? Projelerin maliyetini gerçekten çok mu etkiliyor, yoksa ne? Ama belki yanılıyorum.

Evet, yaptıklarına inanıyorum.

Yeni bir proje için dil seçiminde göz önünde bulundurulması gereken birkaç neden vardır:

• Çalışma zamanı hızı. C / C ++ / Fortran ile karşılaştırıldığında, Perl ve Python o kadar yavaş ki komik.
• Başlatma hızı. Yukarıdaki hızlı dillere kıyasla, Java düşüyor ve JVM yüklenip yüklenmeye devam ederken ağlıyor while(1)...
• Prototip-yeteneği. C ++ veya Java için gereken bildirim / tanım çalışmalarını ayrıntılı bir şekilde yapmak ve yapmak, hata sayılarıyla güvenilir bir şekilde ilişkili olan bilinen tek ölçüm olan LOC'u artırır. Aynı zamanda çok zaman alır. Ayrıca türler ve bağlantılar hakkında biraz daha düşünmeyi gerektirir.
• Dahili güvenilirlik. Dinamik olarak içindekilerle uğraşmak, kendi kendini değiştiren kodunuzda hata ayıklamaya başlayana kadar harika . (Python, Lisp, Perl)
• Doğruluk doğrulaması. Bir derleyici, kodunuzun C ++ kodunda hızlı bir defadan fazla geçmesini sağlayabilir ve bu gerçekten çok iyi olabilir.
• Statik analiz detayları. C ve Java oldukça iyi statik analizlere sahiptir. Perl teorik düzeyde tamamen statik olarak analiz edilemez (Muhtemelen Python da). Lisp'in de olmadığından oldukça eminim.
• Garip platformlar genelde sadece C alır.
• Destek zinciri Böceklerinize bakıp üzerinde çalışacağınız bir sözleşmeniz varsa , bu çok büyük .

Eğer Çalıştığınız kurum "Bundan sonra" bir ilke sahip olduğunu tahmin edebilirsiniz varsa (Orada bunun için bir muhasebe terim) ve alışkanlık sadece rastgele yazılıma değil işin karar, o zaman çok daha iyi bir durum için sahip yazılımı kullanarak. Majör İşletme satışı olmadığı için (sürdürme sorumluluğunu üstlenmenin bir sonucunu taşır) Python / Perl / $ dynamic_language, riski önemli ölçüde azaltır.

Tecrübelerime göre, açık kaynaklı bakım sağlayıcılar çoğu zaman tamiratlarla ilgili sorumluluk almak ve güncellemeleri yayınlamakla ilgili bir sorun yaşarlar. “Ücretsiz, üzerinde çalışsan SİZ!” olduğu değil çoğu işletmeler (değil başka şeylerin yanı sıra çekirdek Senay,) kabul edilebilir bir cevap.

Tabii ki, yüksek risk / yüksek ödül kuralları ile oynama eğiliminde olan ve teknolojinin donma sınırında kalmaya çok açık olan webapp / başlangıç ​​dünyasından bahsetmiyorum .

Kurumsal karar vericilere çok fazla teknik kredi veriyorsunuz. Eski bir deyiş var, "Kimse IBM'i satın aldığı için kovulmadı." Farklı bir rotaya giderseniz ve işler her zaman taşınırsa (her zaman yaparlar), kimse suçlanma riskini almak istemez. Standartlara uyun ve başka birini suçlayın.

Sonunda geleceğin işletmeleri olacak ve bu dilleri kullanacak birçok genç şirket var.

Ve VBA'de yazılmış buggillion kod satırlarını da unutmayalım!

İşletmelerin C, C ++, C # ve Java kullanmasının nedeni statik olarak yazılmış olmaları değildir (en azından doğrudan değil). Kurumsal karar vericiler, bu tür seçimleri, tip sistemlerinin nesnel bir karşılaştırmasına dayanarak yapmıyorlar, sizi temin ederim.

Şirketler şununla ilgilenir:

• Uzun süreli bakım maliyetleri : 10 yıl içinde işlerin iyi çalışmaya devam etmesini makul bir şekilde bekleyebilir misiniz? Dil gelişiminin muhafazakar ve geriye dönük olarak uyumlu olması (Java'da olduğu gibi) gerçekten iyi bir şeydir. Statik yazım burada yardımcı olur çünkü derleme zamanında büyük bir hata türünü üretim sisteminize girmeden yakalar.
• Yetenek kullanılabilirliği - parlak yeni sisteminizi korumak için geliştiriciler bulabilecek misiniz? Orijinal geliştirici ayrılırsa, diğer herkes kodu anlayacak mı? Bu, herhangi bir "yeni" dilin (özellikle dağıtım, yapım sistemleri, operasyonel destek vb. İçin yeni gereksinimler yaratıyorsa) sunulmasına büyük engel teşkil eder. Bu, yaygın olarak kullanılan dillere büyük avantajlar sağlar (C, C ++, C # ve Java)
• Entegrasyon maliyetleri : kolay zaten yerinde varsa veya edinilen muhtemel olduğunu diğer teknolojilerle entegre / bağlamak için nedir? Zaten eski J2EE sistemleri yığınınız varsa, onlarla entegrasyon yapmanız gerekir. Yeni bir Java EE çözümünün Python'dan çok daha pratik olması muhtemeldir.
• Tahmin edilebilirlik / düşük risk : platform / dil kanıtlanmış mı ve çalışacağından emin olabilir miyim? Bu genellikle basit üretkenlikten daha önemlidir. Bir yöneticinin patronunu, insan gücünün yeni bir sistem kurması için kendisine büyük bir bütçe vermesi için ikna etmesi, daha sonra geri dönmesi ve işe yaramadığını söylemesi daha kolaydır.
• Kurumsal Destek / destek - büyük uluslararası kuruluşlar dili ve platforma destek vermeye kararlı mı? Beni desteklemek için bir sözleşme imzalayacaklar mı, böylece işler ters giderse arayacak birisine sahip olabilir miyim?
• Satıcı tarafsızlığı / platform bağımsızlığı - Tek bir tedarikçiye kilitleneceğim mi? Yoksa geniş bir gelecekteki tedarikçi seçeneklerine / geçiş yollarına sahip miyim? Rakipleriniz öğle yemeğinizi yerken ilerleme kaydedememek için mimari bir çıkmazda sıkışıp kalmak istemezsiniz. İşinizi kurumsal bir mimar olarak düzgün yapıyorsanız, bu konuda en az 5-10 yıl düşünmeniz gerekir.

Şahsen, eğer Enterprise'da dinamik dilleri kullanmak istiyorsanız, o zamana kadarki en iyi şansınız mevcut bir kurumsal ekosisteme destek veren bir şey kullanmak olduğunu düşünüyorum. En kayda değer, yeni dinamik JVM dilleridir: örneğin, JRuby, Groovy, Clojure. İlgili IT yönetimine gelince, bunlar "güvenli" dinamik dil seçimleridir çünkü Java kurumsal ekosisteminin geri kalanıyla birlikte çalışırlar ve iyi çalışırlar.

İşletmelerin Erlang, Ruby ve Python gibi dilleri kullanmaya başlamamalarının ana nedeni, dinamik tipte olmaları gibi görünüyor.

Bence bu sadece onların birincil bahanesi. Asıl sebep, işletmelerin hepsini gerçekten ciddiye almaması ve belki biraz fazla amatör olduklarını hissetmeleridir. Java ve .NET, “büyük işletme adları” dır, iyi bir ticari pazarlamaya ve ticari müşteri desteğine sahiptir ve bu nedenle gerçekten çok ciddiye alınmaktadır.

Büyük işletme isimleri kadar popüler hiçbir yerde statik olarak yazılmış bir dil olmaması talihsizdir. Neden açık kaynaklı / özgür yazılım programlama ortamları neredeyse her zaman dinamik olarak yazılıyor? Bu, statik olarak yazılmış bir dilin yapması o kadar kolay olmadığını ve dinamik yazmanın “tembel bir adamın kesilmesi” olduğunu gösterebilir. Bu durumda, dinamik olarak yazılmış dillere karşı karar veren işletmelerin bir anlamı olabilir.

• Dinamik olarak yazılmış diller, statik olarak yazılmış kuzenlerinden daha yavaş olma eğilimindedir.
• Hatalar yakalamak daha zor ve hata ayıklamak zor olabilir
• Derleyici / tercüman yapabilecekleriniz ve yapamadıklarınız konusunda çok daha az titiz olma eğilimindedir. yani, derleme aşamasında hemen hemen sadece sözdizimi hatalarını yakalarsınız
• Eğer bir dinamik yazdığınız dilin tasarımı ile çok dikkatli değilseniz, sen Javascript, ile bitirmek -kokuyor kod dili

EDIT: Şu anda ana programlama dilimin dinamik olarak yazılmış Python olduğunu söylemeliyim. Şahsen, değişkenleri önceden bildirmek zorunda kalmamakla birlikte gelen özgürlüğü seviyorum, ancak zaman zaman, bir fonksiyonun gecikmeden ziyade hataları yakalamak için ne tür parametreler alacağını belirtmek güzel olurdu .

Dinamik olarak yazılmış diller (bazı programcılar / patronlar tarafından) çalışmayan kodlar üretmek için de algılanır. Dinamik olarak yazılmış bir programın derlenmesi, doğruluğu hakkında çok az şey anlatır. Statik olarak yazılmış bir dilin derlenmesi, size çok daha fazla şey anlatır. (Öte yandan, derlemeler arasında hala çok uzun bir yol var ve doğru olanı yapıyor, bu göründüğü zaman daha az anlamlı olabilir)

Dinamik olarak yazılmış diller, betik dilleri olarak algılanır. Hiçbir zaman bash veya toplu iş dosyasına bir uygulama yazmazsınız. Dinamik olarak yazılmış tüm diller bu kategoriye girmeye meyillidir (haksız).

Dinamik olarak yazılmış diller daha yavaş, sonra statik olarak yazılmış diller. (Ancak JIT’de iyi çalışmanın bunu nasıl değiştirdiğini göreceğiz)

Not: Bu çoğunlukla özneldir ve deneyimlerime ve izlenimlerime dayanır.

Dinamik olarak yazılmış diller, statik olarak yazılmış dillerden çok farklıdır. Bu farklılıklar muhtemelen ağır işletme yazılımlarında diğer uygulamaların çoğundan daha önemli hale gelir.

Statik olarak yazılmış diller çok kuralcı olma eğilimindedir. Bir yöntem yalnızca imzasıyla tam olarak eşleşen girdiyi alacaktır. Erişim seviyeleri çok önemli olma eğilimindedir ve arayüzler açıkça tanımlanmıştır, bu tanımları uygulamak için ayrıntılı ama açık kısıtlamalar vardır.

Dinamik olarak yazılmış diller ise çok pragmatiktir. Yazım dönüşümleri genellikle örtük olarak gerçekleşir, yeterince benzer davrandığı sürece yanlış giriş türü sağlarsanız, işlevler bile yürütülebilir. Python gibi dillerde, erişim seviyeleri bile teknik kısıtlamalardan ziyade sözleşmeye dayalı olacaktır (yani sadece privatekullanmanız söylenmemesi ve komik bir adı olması nedeniyle).

Birçok programcı dinamik dilleri tercih eder, çünkü bunlar tartışmalı bir şekilde hızlı prototip oluşturmaya izin verirler. Kod genellikle daha kısa biter (yalnızca tür bildirimlerinin bulunmamasından dolayı) ve hızlı ve kirli bir çözüme ihtiyaç duyduğunuz veya bir şeyi test etmek istediğiniz için uygun protokolü ihlal etmek istiyorsanız, bu mümkün.

Şimdi, "girişimci" şirketlerin genellikle statik olarak yazılmış dilleri tercih etmesinin nedeni, tam olarak bu kısıtlamalar konusunda daha kısıtlayıcı ve daha açık olmalarıdır. Uygulamada, statik olarak yazılmış kodlar bile, bir derleyiciye sahip salaklar tarafından kırılabilir olsa da, birçok problem daha önce süreç içinde çok daha görünür hale gelecektir (çalışma zamanından önce). Bunun anlamı, kod tabanı büyük, monolitik ve karmaşık olsa bile, kodu çalıştırmak veya QA departmanına göndermek zorunda kalmadan birçok hata kolayca yakalanabilir.

Bu avantaj, o ortamın dışındaki pek çok programcının olumsuz yönlerinden ağır basmamasının nedeni, bunların kodun kapsamlı bir şekilde incelenmesiyle veya hatta çalıştırmaya çalışılarak kolayca yakalanabilecek hatalar olmasıdır. Özellikle test odaklı bir metodoloji uygulandığında, bu hatalar çoğu zaman yakalaması ve düzeltmesi kolay değildir. Ayrıca, bu tür birçok şirketin çok daha kısa bir sürüm döngüsüne sahip olmasıyla, üretkenlik genellikle sağlamlıktan daha önemlidir ve geliştiricilerin kendileri tarafından birçok (temel) test yapılır.

Girişimci şirketlerin dinamik olarak yazılmış dilleri fazla kullanmamasının diğer nedeni ise eski koddur. Aptal gibi göründüğü kadar aptalca, büyük şirketler raf ömrünün çok üstünde olsalar bile, genellikle işe yarayan çözümlere bağlı kalacaktır. Bu yüzden birçok büyük şirket Internet Explorer 6'yı zorluyor ve işletim sistemlerini yükseltmek için çok yavaşlar. Bu nedenle, genellikle "eski" dillerde (örneğin Java'nın eski sürümleri) yeni kodlar yazmaları da olasıdır: Canlı olmayan bir yazılıma birkaç satır kod eklemek, yeni bir yazının tamamını okumak için onay almaktan çok daha kolaydır. dil.

tl; dr: statik diller bürokrasiye daha fazla benziyor, bu nedenle girişimci yöneticiler daha iyi.

Hayır, dinamik olarak yazılmış dillerin tüm eleştirileri hak ettiğini sanmıyorum. (İsterseniz, statik olarak yazılmış diller kadar eleştiriyi de hak ederler.)

Deneyimlerime göre (ve bu ifadeyi genelleştirmeye çalışmıyorum), dinamik dilleri eleştiren programcılar bunları kullanmadı. Konuşma genellikle "ama statik yazarken derleyici çok fazla hata yakalar!" ve derim ki "peki, bu sadece benim sorunum değil, tecrübelerime göre". (Genellikle diğer programcılar Java, Delphi veya benzer bir geçmişe sahiptir; Haskell veya ML programcıları bilmiyorum.)

Birisi iddiaları tekniği Foo olamayacağını zaman gerçekten beni sancı tek şey muhtemelen bu tekniği icat edildiğinde tarafından ve dinamik yazdığınız için ... dinamik yazılan dilde yapılması (veya çok zor yapmak olabilir) dil. IDE? Smalltalk. Otomatik yeniden düzenleme Smalltalk. Arayanlar-of / uygulamacılarıdır-of? Smalltalk.

İşletmeler yeterince yeni dilleri ve araçları benimsememektedirler ve bunun için iyi sebepler vardır. Ancak, C # gibi ana araçlardan biri bu özelliklerden bazılarını uyguladığında, o zaman ana şirketlere sızacaklar.