Programlama dilleri katı mı yoksa gevşek mi olmalı? [kapalı]

Python ve JavaScript'te, noktalı virgül isteğe bağlıdır.

PHP'de, dizi anahtarlarının etrafındaki alıntılar isteğe bağlıdır ( $_GET[key]vs $_GET['key']), ancak bunları atlarsanız, önce bu ada göre bir sabit arar. Ayrıca bloklar için iki farklı stile izin verir (iki nokta üst üste veya küme ayracı).

Şimdi bir programlama dili oluşturuyorum ve ne kadar katı yapmam gerektiğine karar vermeye çalışıyorum. Fazladan karakterlerin gerçekten gerekli olmadığı ve öncelikler nedeniyle açık bir şekilde yorumlanabileceği birçok durum var, ancak bunları hala zorlamam gerekip gerekmediğini merak etmem gerekip gerekmediğini merak ediyorum.

Ne düşünüyorsun?

Tamam, benim dilim süslü bir şablonlama dili kadar programlama dili değil. Haml ve Django şablonları arasında bir haç . C # web çerçevemle kullanılacak ve çok genişletilebilir olması gerekiyordu.

Farklı dil türlerinin farklı kullanımları vardır, bu nedenle bu sorunun cevabı gerçekten onu ne için kullanacağınıza bağlıdır.

Örneğin, Perl çok gevşek bir dildir ve hızlı düzeltme veya sayı gıcırdayan komut dosyaları yazmak için çok yararlı buluyorum. Sağlam sağlam projeler için C # kullanıyorum.

Hedef kullanım için dengeyi doğru almanız gerekir. Ne kadar katı olursa, kodu yazmak için o kadar uzun süre harcamanız gerekir, ancak daha fazla sağlamlık, yeniden kullanılabilirlik ve bakımı daha kolay olur.

Bir programlama dilinde aradığım şey (bir betik dilinin aksine) tutarlılık ve güçlü yazımdır.

Mevcut programlama dillerinde noktalı virgülün, örneğin belirsiz hale gelmeden belirli yerlerde atlanması mümkündür (bir {}bloktaki son ifade birdir). Bir programlama dili bu durumlarda karakterleri atlamanıza izin veriyorsa, bir programcının artık fazladan bir sorunu vardır; genel dil sözdiziminin üstünde, hangi durumlarda sözdiziminin bölümlerini de atlamasına izin verildiğini bilmelidir.

Bu ekstra bilgi, programcıya kod yazması için bir sorun oluşturmaz, ancak mevcut kodu daha sonra yorumlamak zorunda olan herkes için bir yük haline gelir (bir süre sonra orijinal yazar dahil).

PHP örneğiniz, sabit keyaynı bağlamda ekleneceği zaman bir programda ince hatalar olasılığını açar . Derleyicinin ne anlama geldiğini bilmesinin bir yolu yoktur, bu nedenle sorun derleme zamanı yerine çalışma zamanında görünür hale gelir.

Belirsizliğin olduğu her yerde, derleyicinin programcının gerçekten ne anlama geldiğini tahmin etmenin bir yolu olması gerekir. Bu her gerçekleştiğinde, programcının gerçekten farklı bir şey ifade etme şansı vardır, ancak belirsizlik çözümleme kuralını düşürmedi.

Mantıksal olarak doğru kod yazmak zaten yeterince zor. Sözdizimsel belirsizlikler eklemek yüzeyde "dostça" görünebilir, ancak kod tabanına yeni, beklenmedik, hata ayıklaması zor hatalar eklemek için açık bir davettir. Sonuç olarak, mümkün olduğunca katı olun.

Örneğinizden, noktalı virgüllerin Python ve JavaScript'te isteğe bağlı olduğunu belirttiniz. Javascript için, en azından, bu tamamen doğru değil. Noktalı virgüller, diğer C ailesi dillerinde olduğu gibi JS'de de gereklidir. Ancak JavaScript ayrıştırıcısı dil belirtimi tarafından belirli durumlarda eksik noktalı virgül eklemek için gereklidir. Bu yaygın olarak çok kötü bir şey olarak kabul edilir, çünkü niyetlerinizi yanlış anlama ve kodunuzu bozma eğilimindedir.

Dilinizi ne kadar gevşek hale getirmeniz gerektiğinin cevabı, bir Teksas aksanında "Ne kadar şanslı hissediyorsunuz, punk?"

Dillerin çok fazla çeşitliliği olmasaydı, herkes kodlama tutarlılığı için çok çalışmak zorunda kalmazdı. Kullanıcılar gereksiz yere karmaşıklığı artıran taleplerde bulunduklarında hoşlanmıyoruz, o zaman neden geliştirme dillerimizden isteyin?

Benim kişisel tercihim, yazım hatalarımı yakalamak için yeterli sıkılığa sahip olma yeteneğidir, ancak mümkün olduğunca az ek plaka. Bu konu hakkında http://www.perlmonks.org/?node_id=755790 adresinden bahsediyorum .

Bununla birlikte, dilinizi kendiniz için tasarlıyorsunuz. Olmasını istediğiniz her şey olmalısınız.

Dillerimin ne demek istediğimi yapmasını seviyorum. Genellikle bu gevşek doğru oldukça sert eğilir. Ayrıca, bu sınırlı alanda hata ayıklamak / analiz etmek için bir öğe veya blok üzerinde "katı" etiketlemek istiyorum.

Genellikle "Bir programcı olarak benim için kolaylaştıracak olan şey" tarafına düşme eğilimindeyim. Tabii ki bu birden fazla şey anlamına gelebilir. Javascript'te, garip bir hataya kadar harika çalışan neredeyse hiçbir tür kontrolü yoktur. Öte yandan Haskell'de, işin daha fazlasını ön plana çıkaran ancak bazı sınıf hatalarını toplayan bir çok tip kontrolü var.

Dürüst olmak gerekirse, ne yaptıklarını görmek ve hiçbirinin vurmadığı bir niş bulmaya çalışmak için bir grup dile bakarım!

Bunu yapmanın açık bir doğru yolu olduğunu düşünmüyorum ya da en azından insanların henüz üzerinde fikir birliği bulduğu bir şey yoksa. Farklı tür sistemlerle dil oluşturarak öğreniyoruz.

İyi şanslar.

İyi bir programlama dilinin, kuralların tutarlı bir şekilde uygulanması beklenen katı kurallara sahip olması gerektiğini öneririm, ancak kurallar yardımcı olacak şekilde yazılmalıdır. Ayrıca, esasen farklı iki program arasındaki "Hamming mesafesinin" sadece bir olduğu durumlardan kaçınmak için bir dil tasarlamayı düşünmesini öneriyorum. Açıkçası, sayısal veya dize değişmezleriyle böyle bir şey elde edilemez (123 yerine 1223 veya 13 yazıyorsa, derleyici programın ne anlama geldiğini çok iyi bilemez). Öte yandan, dil :=ödev ve ==eşitlik karşılaştırması için kullanılacaksa ve tek bir= herhangi bir yasal amaç için, hem karşılaştırma olması gereken kazara atamaların hem de atama olması gereken kazara yapılacak hiçbir şey yapma karşılaştırmasının olanaklarını büyük ölçüde azaltacaktır.

Derleyicilerin bir şey çıkarmaları için yararlı olduğu yerler olsa da, bu tür çıkarımlar genellikle en basit durumlarda en değerli ve daha karmaşık durumlarda daha az değerlidir. Örneğin, aşağıdakilerin değiştirilmesine izin vermek:

  Sözlük <karmaşıkTür1, karmaşıkTür2> öğe =
    yeni Sözlük <karmaşıkTür1, karmaşıkTür2 ()>;

ile

  var item = yeni Sözlük <karmaşıkTür1, karmaşıkTür2 ()>;

karmaşık bir tür çıkarım gerektirmez, ancak kodu büyük ölçüde daha okunabilir hale getirir (diğer şeylerin yanı sıra, yalnızca gerekli olduğu senaryolarda daha ayrıntılı sözdizimini kullanarak, örneğin depolama konumunun türü ifadenin türüyle tam olarak eşleşmediğinden oluşturmak, gerektirebilecek yerlere daha fazla dikkat edilmesine yardımcı olacaktır).

Daha sofistike tip çıkarımını denemenin en büyük zorluklarından biri belirsiz durumların ortaya çıkabileceğidir; İyi bir dilin, bir programcının bu tür belirsizlikleri çözmek için kullanabileceği derleyiciye bilgi eklemesine izin vermesi gerektiğini önermeliyim (örneğin, başkalarına tercih edilen bazı daktilo türlerini göz önünde bulundurarak), önemli olmadıklarını belirleyin (örn. aşırı yükler farklı kodlar yürütebilir, programcı bunların her ikisinin de kullanılabileceği durumlarda aynı şekilde davranmaları gerektiğini belirtmiştir) veya yukarıdaki yollardan hiçbiriyle ele alınamayanları (ve yalnızca) işaretler.

Benim için okunabilirlik çok önemli.

Dil konusunda deneyimli biri için, bir kod parçasının anlamı, bağlamı derinlemesine analiz etmeden açık olmalıdır.

Dil hataları mümkün olduğunca sık işaretleyebilmelidir. Her rastgele karakter dizisi sözdizimsel olarak doğru bir program yaparsa, bu yardımcı olmaz. Değişkenleri otomatik kullanıldıkları ilk defa oluşturulan Ve eğer yanlış yazılmış clientolarak cleintsize bir derleme hatası vermeyecektir.

Sözdiziminin yanı sıra, dil açıkça tanımlanmış bir anlambilime sahip olmalı ve belki de bu iyi bir sözdizimine karar vermekten daha zor ...

İyi örnekler:

• Java, "1"bir dizedir, 1bir int, 1.0bir çift ve 1Lbir uzun. Bir bakış ve ne olduğunu biliyorsun.

• Java'da =ödevdir. İlkel tipler için değer ve referans tipler için referans atar. Hiçbir zaman karmaşık verileri kopyalamaz veya karşılaştırmaz.

• Java'da bir yöntemi çağırmak parantezlere ihtiyaç duyar ve bu şekilde değişkenlerden açıkça ayırt edilir - bu nedenle, parantez yoksa, bir yöntem tanımı aramanıza gerek yoktur, sadece verileri okur.

Kötü örnekler:

• Java'da böyle bir sembol clientneredeyse her şey olabilir: bir paket yol öğesi, bir sınıf veya arabirim adı, bir iç sınıf adı, bir alan adı, bir yöntem adı, bir yerel değişken ve daha fazlası. Adlandırma kurallarını tanıtmak veya bunlara uymak kullanıcıya bağlıdır.

• Java'da nokta .aşırı kullanılır. Paket adı içinde ayırıcı, paket ve sınıf arasında ayırıcı, dış ve iç sınıf arasında ayırıcı, örnek ifadesi ve örnek üzerinde çağrılacak yöntem arasındaki bağlayıcı ve daha fazlası olabilir.

• Birçok dilde, ifblokların süslü parantezleri isteğe bağlıdır ve birisi (gerçekten mevcut olmayan) bloğa bir ifade daha eklerse kötü hatalara yol açar.

• Infix operatörleri: bazen sayısal bir ifadede durmam ve ne anlama geldiğini adım adım düşünmem gerekir. Hepimiz gibi infix gösteriminde matematik ifadeleri yazmak için kullanılır a * b / c * d + e. Çoğu zaman toplama ve çıkarma üzerindeki çarpma ve bölme önceliğini hatırlarız (ama bölündüğümüzü değil c*d, sadece cböldüğümüzü ve sonra çarparak olduğumuzu fark ettiniz mi d?). Ancak, kendi öncelik kurallarına ve bazı dillerde aşırı yüklenmeye sahip çok sayıda ek bilgi operatörü var, bu da takip edilmesi zor. Belki parantez kullanımını güçlendirmek daha iyi bir yaklaşım olabilirdi ...

Doğal dil ile bir benzetme düşünebilirsiniz. E-postada Grammar Nazi misiniz? Yoksa bölünmüş mastarlar, eksik bağlaçlar veya yanlış yerleştirilmiş değiştiriciler gibi bazı gramer hataları ile ilgili sorun yaşar mısınız? Cevap kişisel tercihe bağlı.