Projenin ölçeği ile dilin kesinliği arasında bir korelasyon var mı?

Dillerin katılığı ve paradigmalar arasındaki farkı bir meslektaşımla açıklayarak, şunu söylemekle:

• Dinamik ve yorumlanmış diller gibi hoşgörülü diller, prototipler ve küçük projeler veya orta büyüklükteki web uygulamaları için en iyi şekilde kullanılır. Python veya Node.js ile JavaScript gibi zarif dinamik diller seçerken, faydaları şunlardır:

  1. Hızlı gelişme,

  2. Azalan kazan plakası kodu,

  3.   Java gibi “kurumsal dillerden” kaçan genç, yaratıcı programcıları etkileme yeteneği .

• Statik olarak yazılmış / derlenmiş diller, iş için kritik uygulamalar veya orta ila büyük boyutlu uygulamalar için uygulamalar gibi daha yüksek katılık gerektiren uygulamalar için en iyisidir.

  1. Tanınmış paradigmalar ve modeller on yıllardır gelişmiştir,

  2. Statik kontrol kolaylığı,

  3. Onlarca yıllık deneyime sahip birçok profesyonel geliştirici bulma yeteneği.

• Haskell, Ada gibi sıkı diller veya C # 'daki Kod sözleşmeleri gibi teknikler, hayati öneme sahip sistemler ve son derece stabil olması beklenen sistemler gibi, esneklikten daha güvenli olan (Haskell aşırı esnek olsa bile) sistemler için daha iyidir. Avantajlar:

  1. Derleme zamanında olabildiğince fazla böcek yakalayabilme,

  2. Statik kontrol kolaylığı,

  3. Resmi ispatların kolaylığı.

Ancak, büyük şirketler tarafından büyük ölçekli projeler için kullanılan dillere ve teknolojilere bakarak, iddiamın yanlış olduğu görülüyor . Örneğin, Python, önemli miktarda katılık gerektiren YouTube veya diğer Google uygulamaları gibi büyük sistemler için başarıyla kullanılır.

Projenin ölçeği ile kullanılması gereken dilin / paradigmanın kesinliği arasında hala bir ilişki var mı?

Göz önünde bulundurmayı unuttuğum üçüncü bir faktör var mı?

Ben nerde hatalıyım?

Dinamik ve yorumlanmış bir dil kullanan ölçeklendirme projeleriyle ilgili ilginç bir vaka çalışması , David Pollak'ın Beginning Scala'da bulunabilir .

Beynimdeki kodu daha basit ve doğrudan bir şekilde ifade etmenin bir yolunu aramaya başladım. Ruby ve Rails'i buldum. Kurtarılmış hissettim. Ruby kavramları çok daha az kod satırında ifade etmeme izin verdi. Raylar, Spring MVC, Hibernate ve diğer "aerodinamik" Java web çerçevelerinden çok daha kolaydı. Ruby ve Rails ile kafamdakileri daha kısa sürede çok daha fazla ifade ettim. C ++ 'dan Java' ya taşındığımda hissettiğim kurtuluşa benziyordu ...

Ruby ve Rails projelerim birkaç bin kod çizgisinin ötesine geçti ve projelerime ekip üyeleri eklediğimde dinamik dillerin zorlukları ortaya çıktı.

Kodlama zamanı yazma testlerimizin yarısından fazlasını harcıyorduk ve gördüğümüz üretkenlik kazanımlarının çoğu test yazımında kaybedildi . Testlerin çoğu Java'da gereksiz olurdu çünkü birçoğu yöntem adlarını veya parametre sayısını değiştirerek kodu yeniden düzenlediğimizde arayanları güncellediğimizden emin olmaya yönelikti. Ayrıca, iki ila dört ekip üyesi arasında zihin erimesi olan ekipler üzerinde çalışmanın, Ruby'de işlerin iyi gittiğini, ancak ekibe yeni üyeler eklemeye çalıştığımızda, zihinsel bağlantıların yeni ekip üyelerine iletilmesinin zor olduğunu buldum .

Yeni bir dil ve gelişim ortamı aramaya başladım. Ruby kadar anlamlı fakat Java kadar güvenli ve yüksek performanslı bir dil arıyordum ...

Görebildiğiniz gibi, yazarın proje ölçeklendirmesinde büyük zorlukların test geliştirme ve bilgi transferinde olduğu ortaya çıktı.

Özellikle yazar, Bölüm 7'deki dinamik ve statik olarak yazılmış diller arasındaki test yazımındaki farklılıkları açıklamada daha fazla ayrıntıya giriyor.

Neden Lucky Stiff ... Ruby'nin bazı tavşanların yaratıklarla savaşan Dwemy's Array'ında metaprogramlama kavramlarını tanıtıyor . N8han14 , Scala'da çalışacak örneği güncelledi ...

Ruby koduyla karşılaştırıldığında, Scala kodunun kütüphane bölümleri daha karmaşıktı. Türlerimizin doğru olduğundan emin olmak için çok çalıştık. DupMonster ve CreatureCons sınıflarındaki Creature özelliklerini el ile yeniden yazmak zorunda kaldık. Bu daha çok iş method_missing. Yaratıklarımız ve Silahlarımızdaki değişmezliği desteklemek için adil miktarda çalışma yapmak zorunda kaldık.

Öte yandan, sonuç Ruby versiyonundan çok daha güçlüydü. Scala derleyicisinin bize neyin güvence verdiğini test etmek için Ruby kodumuz için testler yazmak zorunda olsaydık, çok daha fazla kod satırına ihtiyacımız olacaktı. Örneğin Tavşanımızın bir Balta kullanamadığından emin olabiliriz. Bu güvenceyi Ruby'de elde etmek için, Tavşan'a başvurmanın |^başarısız olduğunu gösteren bir test yazmalıyız . Scala sürümümüz, yalnızca belirli bir Yaratık için tanımlanan Silahların, bu Yaratık tarafından kullanılabilmesini, Ruby'de çok fazla çalışma zamanı yansıması gerektiren ...

Yukarıdakileri okumak, projeler büyüdükçe test yazımının engelleyici derecede zahmetli olabileceğini düşündürebilir. Bu akıl yürütme, bu soruda belirtilen çok büyük projelerin örneklerinin gösterdiği gibi yanlış olacaktır ("Python başarıyla ... YouTube için kullanılıyor").

Mesele şu ki, projelerin ölçeklendirilmesi gerçekten kolay değil. Çok büyük, uzun ömürlü projeler, üretim kalitesi test takımları, profesyonel test ekipleri ve diğer ağır şeyler ile farklı test geliştirme süreçlerini "karşılayabilir".

Youtube test paketleri veya Java Uyumluluk Kiti, Dwemy's Array gibi küçük bir eğitici projedeki testlerden farklı bir yaşam sürdüğünden emin .

İddianız yanlış değil. Sadece biraz daha derine inmelisin.

Basitçe söylemek gerekirse, büyük sistemler yalnızca bir dil değil, birden çok dil kullanır. "Katı" diller kullanılarak oluşturulan parçalar olabilir ve dinamik diller kullanılarak oluşturulan parçalar olabilir.

Google ve YouTube örneğinizle ilgili olarak, Python'u öncelikle çeşitli sistemler arasında "yapıştırıcı" olarak kullandıklarını duydum. Yalnızca Google bu sistemlerin neyle oluşturulduğunu bilir, ancak Google’ın kritik sistemlerinin çoğunun C ++ veya Java gibi katı ve "kurumsal" dilleri veya belki de kendileri Go gibi oluşturdukları bir dil kullanarak oluşturulduğunu iddia ediyorum.

Büyük ölçekli sistemler için hoşgörülü dilleri kullanamazsınız. Pek çok kişi Facebook'un PHP kullandığını söylüyor, ancak Facebook'un bu ölçekte verimli bir şekilde kullanmak için son derece katı programlama kuralları oluşturmak zorunda olduğunu belirtmeyi unutuyorlar.

Yani evet, büyük ölçekli projeler için bir miktar katılık gerekmektedir. Bu, dilin veya çerçevenin kesinliğinden veya programlama yönergelerinden ve kod sözleşmelerinden gelebilir. Birkaç üniversite mezunu kapamaz, onlara Python / Ruby / JavaScript veremez ve milyonlarca kullanıcıya yayılan bir yazılım yazmalarını bekleyebilirsiniz.

Kontrol edilmesi gereken iki tür hata vardır: tip hataları (bir tamsayı + değişken listesini birleştirir) ve iş mantığı hataları (bir banka hesabına para aktarın, kaynak hesabın para olup olmadığını kontrol edin).

Dinamik bir programlama dilinin "dinamik" kısmı sadece tip kontrolünün yapıldığı yerdir. "Dinamik olarak yazılmış" bir programlama dilinde, her ifadeyi yürütürken tip kontrolü yapılırken, derleme zamanında "statik olarak yazılmış bir dil" tipi kontrolü yapılır. Statik programlama dili için bir tercüman yazabilirsiniz ( emscriptem'in yaptığı gibi ) ve ayrıca dinamik bir programlama dili için statik bir derleyici yazabilirsiniz ( gcc-python veya shed-skin gibi).

Python ve Javascript gibi dinamik bir programlama dilinde, yalnızca programın iş mantığı için değil, programınızın herhangi bir sözdizimi veya yazım hatası olup olmadığını kontrol etmek için birim testleri yazmanız gerekir. Örneğin, kayanlar listesine bir tamsayı "+" eklerseniz (bu anlam ifade etmeyen ve bir hata verir), dinamik bir dilde, ifadeyi çalıştırmaya çalışırken çalışma zamanında hata ortaya çıkar. C ++, Haskell ve Java gibi statik bir programlama dilinde, bu tür bir hata derleyici tarafından yakalanacaktır.

Dinamik olarak kontrol edilmiş bir programlama dilinde küçük bir kod tabanı, tip hatalarını aramak daha kolaydır, çünkü kaynak kodunun % 100'ünü kaplamak daha kolaydır . İşte bu, kodu farklı değerlerle birkaç kez elle yürütüyorsunuz ve bitirdiniz. % 100 kaynak kodu kapsamına sahip olmak, programınızın tür hatalarının bulunmaması konusunda size ipucu verir .

Dinamik olarak kontrol edilmiş bir programlama dilinde büyük bir kod temeli ile, her bir ifadeyi mümkün olan her tür kombinasyonu ile test etmek zordur, özellikle dikkatsizseniz ve bağımsız değişkenlerine bağlı olarak bir dize, liste veya özel nesne döndürebilecek bir işlev yazabilirsiniz.

Statik olarak kontrol edilmiş bir programlama dilinde, derleyici derleme zamanında tip hatalarının çoğunu yakalayacaktır. En çok söylüyorum çünkü sıfır hatayla bölme veya sınır dışı hata dizisi de tip hatalarıdır.

Asıl tartışma değil, çoğu zaman dilleri programlama ile ilgili değil, o dilleri kullanan kişilerle ilgilidir. Ve bu doğrudur, örneğin, montaj dili diğer programlama dilleri kadar güçlüdür, ancak JavaScript’e kod yazıyoruz. Neden? Çünkü biz insanız. Öncelikle, hepimiz hataları yaparız ve daha kolay ve daha az hatayı belirli bir görev için uzmanlaşmış özel bir araç kullanmaya meyillidir. İkincisi, bir kaynak kısıtlaması var. Zamanımız sınırlı ve web sayfalarını montaj üzerine yazmak çok zaman alacaktı.

Büyük sistemler konusundaki deneyimim, dil seçimine göre değil, tasarım / mimari veya test kapsamı konularında da durmaları veya düşmeleridir . Büyük kurumsal projemde vasat bir Java olanı yerine yetenekli bir Python ekibim olmasını tercih ederim.

Diyelim ki, önemli ölçüde daha az kod yazmanıza izin veren herhangi bir dil, bakmaya değer olmalı (örneğin Python vs Java). Belki gelecek, ileri tip çıkarımlı (örneğin Scala kalıbında) akıllı, statik olarak yazılmış dillerdir. Veya C # gibi hibrit dynamicnitelikleriyle çalışıyor ...?

Ve "diğer" statik yazım avantajını da unutmayalım: Bence iyi bir özellik değil, benim görüşüme göre önemli bir özellik olan uygun IDE kod tamamlama / intellisense.

Diğer bir faktör ise kim arkasında yazılı büyük ölçekli uygulamalar. Bazı büyük kurumsal tarz projelerde Ruby veya Python'u kullanmak isteyen birçok yerde çalıştım, ancak kesin olarak projelerin açık kaynak niteliği nedeniyle BT yöneticileri ve kurumsal güvenlik ekipleri tarafından sürekli "vuruluyor".

Bana "Ruby on Rails'i kullanamayız, çünkü açık kaynak ve birileri oraya kritik veya korunan bilgileri çalmak için saldırılar düzenleyebilir" denildi. Üzgünüm, ama birisi açık kaynak == kötülüğü bu zihniyete sahipse, onu değiştirmek neredeyse imkansız. Bu düşünce çizgisi kurumsal bir hastalıktır.

C # ve Java edilir güvenilen dil güvenilen platformlar. Ruby ve Python güvenilir diller değil.