Programlama dilini değişiklikler için daha kararlı (uyumlu) yapan herhangi bir mekanizma var mı?

Çok sayıda programlama dili vardır. Bazıları büyür ve çok popüler hale gelir. İnsanlar bu dilleri daha sık kullanıyor. Bu dilin kurucusu (veya kurucu kuruluş / topluluk), dili daha iyi hale getirmek için değişiklikler uygulamaya çalışabilir. Ancak bazen geriye dönük uyumluluk nedeniyle bazı değişiklikler yapmak zordur ve bu çirkin şeyler dilde yıllardır varlığını sürdürmektedir ve birçok kullanıcı tarafından kullanılmaktadır.

Dil tasarım aşamasında, daha kararlı hale getirmeye yardımcı olabilecek herhangi bir mimari ilke veya adım var mı, böylece dil tasarımcıları geriye dönük uyumluluğu kırmaktan korkmayacaklar mı?

Dil istikrarı teknik bir karar değildir. Dil yazarı ile kullanıcılar arasında yapılan bir sözleşmedir.

Yazar, belirli bir sürümü az çok kararlı olarak tanıtmaktadır. Bir dil ne kadar kararlı olursa, yazar o kadar fazla değişiklik yapabilir. Dille ilgilenen her kullanıcı, yeni özellikler öğrenmek veya gelecek ayki güncellemeyle kırılabilecek uygulamalar geliştirmek için zaman harcamak isteyip istemediğine karar verebilir.

Dengesiz bir dil kullanmak ilginç olabilir, çünkü yeni bir konseptle ilgileniyorsunuz ya da geri bildirimde bulunarak yardım etmek istiyorsunuz. Eğer bir iş yapıyorsanız, zamanınıza yatırım yapmadan önce bir teknolojinin daha istikrarlı olmasını beklemeyi tercih edebilirsiniz.Piyasa zamanı ve kullanıcı deneyimi gibi şeyler hakkında daha fazla önem verirsiniz.

Yani bu bir iletişim ve güven meselesidir. Pas dili gelişimine bakın. Neleri değiştirdikleri ve neleri sakladıkları konusunda çok netler. Belirli bir özellik hakkında bir kararı ertelemek istediklerinde, özellik kapısı dediklerini kullanırlar. Öte yandan, açısal ekip 2.0 duyuruları üzerinde çok fazla öfke ile karşı karşıya kaldı, çünkü değişiklikler beklenenden daha büyüktü.

Kütüphaneler bile yazarlarının kendi API'lerinin istikrarı hakkında iletişim kurması gerekir. Diğer insanlar tarafından kullanılan hemen hemen her teknoloji, istikrar ve mükemmellik arasında bir denge kurmak zorundadır. Bir araba üreticisi pedalların konumunu değiştiremez ve bir dizüstü bilgisayar tasarımcısı aynı nedenden ötürü yeni bir klavye düzeni icat etmez: ürününüzü kullanma yöntemleri hakkında karar veremiyorsanız kullanıcılarınıza yardımcı olmazsınız.

• Önceden ne kadar iyi tasarlanabileceğinden bağımsız olarak dillerin yaşamları boyunca değiştiğini unutmayın. Yeryüzündeki en harika dili hemen göndermeye çalışmak yerine, önce faydalı ve genişletilebilir olmaya çalışın. Gerçekten kullanabileceğim vasat bir dil, sadece teoride var olan herhangi bir harika programlama dilinden daha değerli.

• Sözdizimini genişletilebilir, örneğin makrolar gibi olanakları düşünün. Makrolar otomatik olarak iyi bir şey değildir ve çok güçlü olabilir. Bazı diller başlangıçta makro ihtiyacını azaltan çok esnek bir sözdizimine sahiptir. Dikkate alınması gereken birkaç senaryo:

  • |>Dili terk etmeden yeni bir operatör kullanabilir miyim ? Bu operatör için öncelik ve ilişkilendirilebilirlik seçebilir miyim?
  • Satır içi işlev / lambda / kapatma için ne kadar tören yapmam gerekiyor?
  • Bir foreach döngüsü sözdizimini uygulamak için mevcut dil sözdizimini kullanabilir miyim? Örneğin Ruby ve Scala bunu lambdaslarla esnek yöntem çağrısı sözdizimi ile yapabilirler.

• Semantiğin genişletilebilir olmasını sağlayacak tesisleri düşünün. Ortak ihtiyaçlar:

  • Kullanıcı tanımlı türlerin mevcut operatörlere kendi anlamlarını atayabileceği operatör aşırı yüklemesi. Bu, matematik ağırlıklı uygulamalarda bir dili çok daha eğlenceli hale getirir.
  • Değişmez aşırı yükleme. Dize değişmezlerini kendi dize türümde yapabilir miyim? Geçerli kapsamdaki tüm sayısal değişmezleri bignum yapabilir miyim?
  • Meta nesne protokolleri. Dilin özellikleri yoksa, bunları geçerli nesne sistemi içinde uygulayabilir miyim? Farklı bir yöntem çözüm emri uygulayabilir miyim? Nesnelerin depolanma şeklini veya yöntemlerin nasıl gönderileceğini değiştirebilir miyim?
• Regresyon testleri yapın. Çok fazla test. Sadece dil tasarımcıları tarafından değil, kullanıcılar tarafından da yazılmıştır. Bir özellik eklerken bu testleri kırarken, bu özelliğin faydalarını geriye dönük uyumluluğun yararına dikkatlice tartın.
• Dilinizi güncelleyin. Sadece belgelerinizde değil, aynı zamanda kaynak kodun kendisinde de. Bunu yaptıktan sonra, dilinizin değiştirilemeyen tek kısmı bu sürüm pragma sözdizimidir. Örnekler: Raket, bir lehçe belirlemenizi sağlar. Perl use v5.20, Perl v5.20'nin tüm geriye dönük uyumsuz özelliklerini etkinleştirmenizi sağlar. Açıkça beğenilen tek özellikleri de yükleyebilirsiniz use feature 'state'. Benzer: Python's from __future__ import division.
• Dilinizi birkaç ayrılmış kelimeyle sonuçlanacak şekilde tasarlamayı düşünün. Çünkü classsunmakta f I adında bir yerel değişken olması mümkün olmaz anlamına gelmez class. Uygulamada, bu, değişkenleri veya yöntem bildirimlerini sunan anahtar kelimelerle sonuçlanır ve bildirimleri tanıtmak için tür adlarını kullanma gibi C benzeri geleneğe karşılık gelir. Başka bir alternatif de $variablesPerl ve PHP'de olduğu gibi, sizin için sigils kullanmaktır .

Bu cevabın bir kısmı Guy Steele'in “Dili Büyütmek” (1998) ( pdf ) ( youtube ) konuşmasından etkileniyor .

Bence oldukça önemli bir adım, dilin sürümünü de yönetebilen bir paket yöneticisini tanıtmak.

Örneğin, Scala için SBT veya Clojure için Leiningen kullanıyorum. Her ikisi de proje başına dilin hangi sürümünü kullanmak istediğimi bildirmeme izin veriyor . Bu nedenle, mevcut projeleri daha rahat bir hızda yükseltirken, yeşil projelerin dilin en son sürümünde başlatılması oldukça kolaydır.

Tabii ki, dile bağlı olarak, bu hala ilgili kütüphanelerin ihtiyacınız olan sürüme taşınmasını beklemek zorunda kalabilirsiniz (bu, örneğin Scala'da olur), ancak yine de işleri kolaylaştırır.