Bir programlama dilini geriye doğru uyumlu tutun, kusurlarını giderin

İlk olarak, bazı bağlamlar (zaten çoğunuzun bildiği şeyler):

Her popüler programlama dili, sürümüyle işaretlenen çoğu zaman açık bir gelişime sahiptir: Java 5, 6, 7 vb., PHP 5.1, 5.2, 5.3 vb. Vardır. Yeni bir sürüm yayınlamak, yeni API'leri kullanılabilir hale getirir, hataları giderir, yeni özellikler, yeni çerçeveler vb. Sonuç olarak: hepsi iyi.

Peki ya dilin (veya platformun) problemleri? Eğer bir dilde yanlış bir şey olursa, geliştiriciler ya onlardan kaçınabilir (eğer yapabilirlerse) veya onunla yaşamayı öğrenirler.

Şimdi, bu dillerin geliştiricileri, onları kullanan programcılardan çok fazla geri bildirim alıyor. Bu nedenle, zaman (ve sürüm numaraları) geçtikçe, bu dillerdeki sorunların yavaş ama kesin olarak ortadan kalkacağını anlamış oluyor. Şey, tam olarak değil. Neden? Geriye dönük uyumluluk, bu yüzden. Ama bu niye böyle? Daha somut bir durum için aşağıyı okuyun.

Sorumu açıklamanın en iyi yolu, PHP'yi örnek olarak kullanmaktır:

PHP binlerce insan tarafından sevilir ve nefret edilir. Tüm dillerin kusurları vardır, ancak görünüşe göre PHP özeldir. Bu blog gönderisine göz atın . PHP'de sözde kusurların çok uzun bir listesi vardır. Şimdi, bir PHP geliştiricisi değilim (henüz değil), ancak hepsini okudum ve bu listenin büyük bir kısmının gerçekten gerçek meseleler olduğundan eminim. (Potansiyel olarak öznel olduğu için hepsi değil).

Şimdi, aktif olarak PHP'yi geliştirenlerden biri olsaydım, kesinlikle tek tek bu sorunları çözmek isterdim. Ancak, bunu yaparsam, dilin belirli bir davranışına dayanan kod, yeni sürümde çalışıyorsa bozulur. 2 kelimeyle özetleyin: geriye uyumluluk.

Anlamadığım şey: neden PHP'yi geriye dönük olarak uyumlu tutmalıyım? PHP 8'i tüm bu sorunları çözdüğümde salıverirsem, "Bu sürümde eski kod çalıştırma!" Diyerek büyük bir uyarı veremem?

İtiraz denilen bir şey var. Yıllarca yaşadık ve çalışıyor. PHP bağlamında: insanların bugünlerde mysql_*fonksiyonların kullanımını aktif olarak nasıl engellediğine bakın (ve bunun yerine tavsiye mysqli_*ve PDO). Azaltma işe yarıyor. Kullanabiliriz. Kullanmalıyız. İşlevler için çalışıyorsa, neden tüm diller için çalışmamalı?

Diyelim ki (PHP geliştiricisi) bunu yapıyorum:

• Tüm bu hataların düzeltilmesiyle yeni bir PHP sürümü (diyelim 8).
• Yeni projeler bu sürümü kullanmaya başlayacak, çünkü çok daha iyi, daha net ve daha güvenli.
• Ancak, PHP'nin eski sürümlerini terk etmemek için, güncellemeleri yayınlamaya, güvenlik sorunlarını, hataları vb. Düzeltmeye devam ediyorum. Bu, burada listelemediğim nedenlerden dolayı mantıklı geliyor. Yaygın bir uygulamadır: örneğin, çoğunlukla 5.5.x sürümüne odaklanmış olsa da Oracle'ın MySQL'in 5.1.x sürümünü nasıl güncellediğine bakın.
• Yaklaşık 3 veya 4 yıl sonra, PHP'nin eski sürümlerini güncellemeyi bırakıp ölüme terk ediyorum. Bu iyi, çünkü o 3 veya 4 yıl içerisinde, çoğu proje yine de PHP 8'e geçecek.

Sorum şu: Bütün bu adımlar bir anlam ifade ediyor mu? Yapması çok mu zor olurdu? Yapılabilirse, neden yapılmıyor?

Evet, olumsuz tarafı geriye dönük uyumluluğu kırmanızdır. Ama bu bedel ödemeye değer değil mi? Bir üst olarak, 3 ya da 4 yıl içinde, problemlerinin% 90'ının sabit olduğu bir dile sahip olacaksınız… çalışmak için daha keyifli bir dil. Adı popülerliğini sağlayacak.

EDIT : Tamam, 3 veya 4 yıl içinde insanların varsayımsal PHP 8'e taşınacağını söylediğimde kendimi doğru ifade etmedim. Demek istediğim şuydu: 3 veya 4 yıl içinde, eğer insanlar başlarsa PHP 8 kullanacaklar yeni proje.

Kulağa hoş geliyor ama pratikte nadiren işe yarıyor; insanlar çalışma kodunu değiştirmek konusunda son derece isteksizdir ve hatta yeni, yeşil alan projeleri için bile bildikleri bir dilden / sürümden geçmek konusunda isteksizdirler.

Var olan, "iyi çalışan" çalışan kodun değiştirilmesi, herhangi bir projenin öncelik listesinde en üst sıralarda yer almaz. Yöneticilerin zaten ödenmiş olduğunu düşündükleri şeylere çaba göstermek yerine, sadece bir dil veya platformun daha yeni bir sürümüne geçebilmek için, geliştiricilerin sadece "şimdilik" eski sürümde kalmaları gerektiğine karar verecekler. Kullanıcılarınızı yalnızca yeni sürümde mevcut olan harika özelliklere sahip olmaya ikna etmeye çalışabilirsiniz, ancak dil için net bir kazanç elde etmemeniz için kullanıcı tabanınızı azaltma riskiniz var. Şık ve modern özellikler, popüler kurulumda parçalanmış montaj tabanının fiyatına karşı kolayca ölçülemez ve siz de "yükseltme koşu bandı" olarak ün kazanma riskini taşıyorsunuz

(Açıkçası, bunun çoğu hobistlerin sadece kendi zevkleri için yazdıkları projeler için geçerli değildir. Ancak (burada flamebait ...) PHP orantısız bir şekilde bilgisayar korsanları tarafından nadiren seçilmiştir çünkü ilk etapta yazmak böyle bir zevktir. )

Geriye dönük uyumluluğun etkisini hafife alıyorsunuz; Tüm aktif projelerin 3 veya 4 yıl içinde göç edeceği tahmininde bulunmak çok fazla iyimser.

Bir PHP geliştiricisi olduğumu varsayalım. PHP'de kusurlar var, ama bu hataların etrafında nasıl çalışacağımı biliyorum - bu PHP geliştiricisi olarak ödeme almamın bir parçası. Şimdi PHP 8'in ortaya çıktığını ve bu kusurları düzelttiğini varsayalım, ancak geriye dönük olarak uyumlu değil. Sonuç olarak:

• PHP 8 kodumu güncellemek için zaman harcamak zorundayım. Bu, müşteri isteklerine cevap vermek, yeni özellikler uygulamak, rekabete ayak uydurabilmek için harcayacağım zamandı.
• Bunu yaptıktan sonra bile , kodumda hatalar ortaya çıkaran bazı köşe davası veya öngörülemeyen uyumluluk sorununu özleme şansım çok iyi.

Buna bakıldığında , "daha iyi, daha net, daha güvenli vb." Olsa bile PHP 8'e asla göç etmeme konusunda güçlü bir teşvik var . Halen milyarlarca sıra COBOL (!) Olduğu tahmin edilmektedir - açık bir şekilde daha iyi teknolojiler mevcut olsa da, bir güncelleme maliyeti, hata riskiyle birleştiğinde, buna değmez.

İkincisi, kendi kodumu taşımaya karar vermeme rağmen, önemsiz olmayan herhangi bir uygulama üçüncü taraf kitaplıklara dayanır ve üçüncü taraf kitaplıkların taşınacağı garantisi yoktur. Örneğin, Python 3 Aralık 2008'de piyasaya sürüldü, ancak Django (muhtemelen önde gelen Python web çerçevesi) neredeyse beş yıl boyunca istikrarlı, üretime hazır Python 3 desteği yoktu ( buraya ve buraya bakın ).

İnsan davranışı hakkında çok fazla varsayımda bulunuyorsunuz. Çok fazla değiştirirseniz, insanlar rakiplerinizi değerlendirebilir, çünkü yine de geçiş yapmak için büyük çaba harcamak zorunda kalacaklar. Açık kaynaklı diller için insanlar sadece eski sürümü kullanacaklardır.

Bir örnek için python'a bakın. 3.x dört yıldır mevcuttu ve hala yaygın olarak kabul görmedi. İnsanlar bunu yepyeni projeler için kullanmaya çalışıyorlar, ama bence kod işinin ne kadar sürdüğünü azıcık tahmin ediyorsun.

Tabii ki, çoğu insan python 2.x'in "kusurlu" olduğunu düşünmedi. PHP kullanıcıları gibi şikayetleri yoktu. Php, çok daha istikrarsız bir konumdadır, çünkü pek çok insan sadece mevcut büyük kod tabanı nedeniyle buna bağlı kalmaktadır. Geriye dönük uyumluluğunu yitirirseniz, birçok insan pitona taşınmak için bekledikleri fırsatı değerlendirir.

PHP dışındaki herhangi bir dil için, evet, bu kesinlikle mantıklı! Bu tam olarak Python'un Python 3'e geçişle yaptığı şeydir.

Bununla birlikte, PHP ile ilgili sorun, dil tasarımında kendisinde çok fazla kusur olması, bu nedenle "PHP 8" olarak adlandırdığınız şey tamamen farklı bir dil olacaktır. Ve eğer farklı bir dile geçmek zorunda kalıyorsanız, şu anda mevcut ve kararlı alternatifler yerine neden yeni PHP'ye sadık kaldınız?

Ayrıca PHP topluluğu yeni bir şeyi uyarlamak için son derece yavaştır. Sadece kurtulmanın ne kadar sürdüğünü görün register_globals. 2000 yılından bu yana bir güvenlik riski olduğu bilinmektedir. Sadece 12 yıl sonra kaldırıldı. Bir başka örnek, PHP5 tanıtıldığında, PHP4'e göre büyük bir gelişme oldu, ancak topluluk bunu uyarlamadı. Evlat edinmeye başlamak için 4 yıl sürdüm ve GoPHP5 gibi büyük eylemler yaptım . Ve bu bile önemli miktarda geriye dönük uyumsuz değişime sahip değildi.

Yasal Uyarı: Bir ColdFusion kullanıcı grubunu yönetiyorum.

ColdFusion da aynı sorunları yaşıyor: birçok kişi tarafından seviliyor, birçok kişi tarafından küçümsendi. Ayrıca, Java öncesi sürümlere göre ton ve ton FUD. Geçen yıl ColdFusion 10 çıktı, büyük bir satıcı ve geçen hafta sürüm 11'in yayınlanmasını test etmek için kaydoldum. Ayrıca, iki büyük açık kaynak alternatifi var, biri JBoss tarafından destekleniyor.

CF10'da uygulamak istediğim TON'ların yeni işlevleri var, ancak CF 7 veya 8'den geçiş yapmak kod tabanınızın boyutuna, yaklaşmakta olan proje sayısına ve bir kez daha regresyon testi yapmanız gereken kaynaklara bağlı olarak zor olabilir En son sürümde. Kodun aynı şekilde derlemediği kenar durumlarının yanı sıra, 8 ile 9 arasındaki birkaç küçük sözdizimsel farklılıkla da karşılaştım. Bulunduktan sonra, bunları gelecekteki projelerde veya yeni geliştiriciler tarafından kullanılmaması için Kodlama Standartlarımıza belgeledim.

Bununla birlikte, eğer ColdFusion 11 (veya herhangi bir programlama dili), belirli işlevleri ve sözdizimini tamamen kullanımdan kaldırıyorsa, işlevselliği bulma ve değiştirme çabası büyük olabilir. Test etme çabaları devasa olabilir. Şirketler, geliştiricileri, KG ve proje yöneticilerine, bu kullanımdan kaldırılan şeyleri bulmak, değiştirmek ve test etmek için para ödeyecek mi? Şüpheli.

Bir dilin en son sürümü geriye dönük olarak uyumluysa, ancak kod değişikliği olmadan performansında bir artış sağlıyorsa (CF9, CF8'den yaklaşık% 30 daha hızlıdır ve CF10, CF9'dan çok daha hızlıdır), yine de çalışıyorsa, işlev çağrılarını değiştirmeyi kim umursar?

Bir şirket olarak, müşterilerimizi memnun etmek ve hizmetlerini faturalandırmak, işi kurmak ve daha fazla müşteri almak için ihtiyaçlarını karşılamak konusunda endişelenmeliyiz.

FWIW, bizi bir noktada jQuery'nin en son sürümüne götürmeyi çok isterdim, ancak bazı fonksiyonlar kullandıklarımızdan sonra birkaç sürümden mahrum bırakıldığından ve sistemdeki JavaScript hacmini verdiğimizden, nasıl olduğunu bilmiyorum Onu çekeceğiz.

Burada bir takas var; bazı hatalar GERÇEKTEN düzeltilmeye ihtiyaç duyuyor, ancak bazı şeyler birilerinin kodunu bozmadan değiştirilemez. Herhangi bir hatanın ne kadar belirsiz veya açık bir şekilde kırıldığına bakılmaksızın, birisinin bir şey için kullanacağına bakılmaksızın, her hatanın birinin projesini kıracağını "kural" olarak belirten birini hatırlıyor gibiyim. Bu programcıların doğasıdır.

Bu (benim düşünceme göre) büyük sürümler, küçük sürümler ve revizyonlar arasındaki farktır. Genel bir prensip olarak:

• Büyük sürümlerin kırılma değişiklikleri içerdiği varsayılmaktadır.
• Küçük sürümler davranışı biraz değiştirebilir.
• Revizyonlar hemen hemen çapraz uyumlu olmalıdır.

Örneğin, bir dilin v2.3'ünde bir şeyler yazıyorsam, v2.3.2'ye yükseltirsem herhangi bir fark görmeyi beklemem. V2.4'e yükseltirsem, birkaç şey değişebilir - küçük sözdizimi tweaks, bazı fonksiyonlar biraz farklı davranır, bu yüzden mantığı dengelemeliyim, v3.0'a yükseltirsem, kırılırsa şaşırmam Tamamen - kullanımdan kaldırılmış veya eksik olan işlevler, işlemler desteklenmiyor veya çok fazla değiştirilmiyor, o kadar fazla değişiklik yapmamıştım ki, aslında yeni değişiklikleri hesaba katmak için bazı işlevleri yeniden yazmam gerekiyor.

Düzenle:

Steve Vance'ın Gelişmiş SCM Dallanma Stratejileri adlı makalesinde şöyle yazılmıştır :

Tipik olarak, noktalara bağlı sayılarla adlandırılan iki ila üç serbest bırakma seviyesi vardır (örn. 1.2.3). [...] Bu yapıdaki ilk sayı, öncekilerden önemli özelliklere ve işlevsel gelişmelere sahip olduğunu gösteren büyük bir versiyonla ilişkilendirilmiştir; göç gerektiren önemli uyumsuzluklar da olabilir. İkinci sayı, daha az özellik ve işlev geliştirmeleri, önemli sayıda hata düzeltmesi ve uyumsuzluk içermeyen küçük bir sürümü temsil eder. Üçüncü sayı, neredeyse yalnızca bir hata düzeltmeleri koleksiyonunu belirten bir yama düzeyini ifade eder; hiçbir özellik veya fonksiyon geliştirmesi yoktur ve yama seviyeleri arasında uyumsuzluğa izin verilmez.

Bunu yapacağım tek değişiklik, programcıların sık sık “kullanım” yolları bulmaları için yukarıda belirtilen prensiptir, bu nedenle “önemli sayıda hata düzeltmesi ve uyumsuzluk yok” gibi küçük bir sürüm zor olabilir, çünkü Hatalar ya onları kullanan bir şeyi kırar ya da geçici çözümün gereksiz hale gelmesine ve sorunlara neden olmaya başlar.

Bu gerçekten dilin hedefi nedir - dilin ne tür uygulamalar yapması gerektiği üzerine kuruludur.

Mesela, Android'i görmezden gelmekle, Java çoğunlukla büyük kurumsal sistemlerde ve orta mallarda kullanılır; bu tür uygulamalar hem boyutta hem de zaman içinde çok büyük olma eğilimindedir. Bunun bazı etkileri var; geliştirme aşamasında 50+ çalışan mühendis olan 500K + LoC'li bir sistem hayal edin. Tipik olarak, bu tip bir sistem, 10 geliştiriciyle bundan sonra bakıma girer; Şimdi eğer dil değişirse ve değişiklikler geriye dönük olarak uyumlu değilse, bazı bölümleri yazan programcılar gitmiş ve kimse dokunmak istemiyor çünkü proje kolayca yeni bir sürüme geçirilemiyor. Bu daha küçük problemdir, daha büyük problem, 500 LoC uygulamasını yeni dil kısıtlamalarına adapte etmenin biraz pahalı olması gerçeğinden oluşur. Örneğin, jenerik tip silme veList list = new List(); Milyonlarca kod satırı derlenmeyecekti, yeniden yazılması gerekecek - ki bu büyük bir bedel.

Öte yandan, PHP web üzerinde basit uygulamalar için kullanılma eğilimindedir; genellikle tek bir programcı veya küçük bir ekip tarafından geliştirilir. Buradaki fikir, geliştiricilerin tüm projeyi oldukça iyi bilmesi, dil değişikliklerini daha kolay bir şekilde bütünleştirebilmesidir. Ayrıca amacı çok hızlı bir site oluşturmaktır ve daha hızlı ne kadar iyi olursa, yeni bir dil özelliği bunu daha iyi yapabilirse, bazı geriye dönük uyumluluk maliyetlerinde bile uygulanır.

Microsoft, ASP.NET ile (klasik ASP'nin halefi olarak) veya VB.NET ile benzer bir değişiklik yaptığını iddia edebilir (bununla birlikte, dilin "yeniden başlatılmasının" yararlarının çoğunun kaybolduğu pek çok taviz vermesine rağmen).

Her neyse, herhangi biri, bir geçiş aracı yardımıyla bile Göç VB6 kodunun kabusunu VB.NET'e hatırlıyorsa, dil geçiş araçlarının ana dil güncellemeleri için çok iyi çalışmadığı konusunda hemfikirdir.

Platformu ileriye taşımak mümkün olabilir, ancak yine de "kullanımdan kaldırılmış" API'ler için en az birkaç revizyonla destek sağlamalısınız.

Popüler programlama dillerinde çığlık atan "kusurların" çoğu değil, onlar çığlıkçıların günün en sevdiği oyuncağı, o dilin yoksun olması, o dilin temelde kusurlu olmasından ÖNCE.
Bir sonraki yutturmaca gelir, dil aniden hatalı olur çünkü bu yutturmaca uymaz.

Java’da kapama eksikliği klasik bir örnektir. Bu hiç bir dilde bir dil değildir ve dili ne yazık ki (gündemde olduğu gibi) içerecek şekilde değiştirmek, IMO'yu temel olarak sakatlar ya da en azından okumayı ve anlamayı zorlaştırır.

Çok fazla insanın kaybedeceği şey, her dilin güçlü ve zayıf yönlerine sahip olması ve her zayıflığın önüne geçerken her şeyin gücünü birleştiren bir şey yaratmaya çalışmak, hiçbir şeyde iyi olmayan, inanılmaz derecede haksız, imkansız, tamamen kullanılamaz bir canavar yaratacaktır. etkili kullanın.

Diğerlerinin de belirttiği gibi, geriye dönük uyumluluğun, milyon satır kod tabanlarını "daha iyi" olduğunu düşündüğünüz her şeye uyarlamak için binlerce saat ve milyonlarca dolar / Euro harcayamayacak olan mevcut kullanıcıları korumak için hayati öneme sahip olduğunu da ekleyin. yıllardır kullandıkları dilin versiyonundan daha fazla ve yeterince iyi ayrılmak için çok iyi tartışmalara ev sahipliği yapıyorsunuz ve sözde bir sonraki "java katili" olan sözde yeni bir aşırı sinirli fikirle oynamak istiyorsanız, d o oyuncağın klonu olmak için “sabitlenene kadar” “Java iz ded” diye bağırmak yerine, o oyuncakla en iyi şekilde oynamak.

Bir dilin daha yeni sürümlerinin, dilin hem eski hem de yeni sürümlerinde derlenen kodun% 99.99999'unun, bunu yapmak için kasıtlı olarak tasarlanmadıkça ve çoğu zaman aynı şekilde çalışmasını sağlamak için çaba göstermesini tavsiye ederim. yeni sürüm eski sürümün altında derlenen kodu reddettiğinde, kodun - en iyi ihtimalle - tehlikeli olduğu ve hem eski hem de yeni derleyici altında derlenecek şekilde yazılmış olması gerekirdi.

Örneğin, Java veya C # 'ya benzer yeni bir dil tasarlıyor olsaydım, bu dillerin izin verdiği bazı bağlamlarda örtük tip dönüşümleri yasaklardım. Verilen C # 'da basit bir örnek olarak,

int someInt;
double someDouble;

ifadenin someInt.Equals(someDouble), değişkenlerin içeriğinden bağımsız olarak false döndürmesi garanti edilir. Derler çünkü doubledönüştürülebilir Objectve bu tür intbir Equalsaşırı yüke sahiptir , bu nedenle derleyici dönüşümü yapar ve çağrı yapar. Yeni bir C # sürümü ve .NET Framework tasarımı tasarlıyorsam, yararlı bir şey yapamadığı için boks dönüşümünü yasaklardım. İşe yaramaz ancak zararsız bir şekilde böyle bir karşılaştırma yapan bir program olması ve derleyicinin bu kodu reddetmesi bu programı bozabilir, ancak bu işe yaramaz kodu düzeltmek veya kaldırmak bir gelişme olabilir.

Biraz daha az net bir örnek olarak, varsay

float f=16777216f;
int i=16777217;

ve ifadeyi düşünün f==i. Bazı kodu / tamsayı karşılaştırmaları yüzer yapar ve düzgün çalışır, ancak kod ya olarak yeniden yazılması gerektiğini mümkündür f==(float)i, (double)f==i;ya da (double)f==(double)i;[ intüzere doubleson iki eşdeğer olacağını bu yüzden promosyon, kayıpsızdır]. Doğrudan karşılaştıran floatve integerdeğer veren bazı kodlar her zaman yeterince küçük sayılarla ilgilenebilir floatve doublekarşılaştırmalar aynı şekilde davranır, ancak bir derleyici genellikle bunu bilemez; Kod, dilin kurallarının programcının amacına uygun olacağını ummak yerine ne tür bir karşılaştırma yapılması gerektiğini açıkça belirtmelidir.

Geriye doğru uyumluluktan asla vazgeçmemek en iyisidir.

Microsoft, VB6 programlama dilini, tamamen uyumluluğu sağlayan yeni bir dille değiştirdi. Bu yüzden bugün bile 16 yaşındaki VB6, dotNet versiyonundan daha popülerdir (Tiobe endeksi Ağustos 2014). Ve Gartner, halen kullanımda olan 14 milyar satırlık VB6 kodunun olduğunu tahmin ediyor.

2014'te Microsoft, Visual Basic programlama topluluğunun taleplerine rağmen, VB6'yı güncellemeyeceklerini veya açmayacaklarını açıklamak zorunda kaldı. Ancak VB6 desteğini 'en az 2024'e kadar uzattılar ve Windows 7 ve 8'de iyi çalışıyorlar. Bu VB6'nın aynı sürümü için 26 yıldan fazla sürecek.

Neden mevcut çalışan yazılımın yeniden yazılması gerekiyor, Microsoft bile dotNet'i kullanmak için Office'i hiç "güncellemedi".

Geriye dönük uyumluluk kırma ile ilgili birkaç farklı sorun var. Sorunlardan bazıları, programlama dillerinin çoğunun da platformlar (tercümanlar / çalışma zamanları) olması, diğer sorunların ise insan doğası varsayımından kaynaklanmasıdır.

A. Eski sürümlerde yazılmış olan kod, performansı, güvenliği veya özellikleri geliştiren yeni sürümlerden faydalanamaz. Derleyicinin / yorumlayıcının birden çok ana sürümünü destekleyerek bu sorunu azaltabilirsiniz, ancak bu çok büyük bir kaynak boşalmasıdır (yani pahalı ya da uzun zaman alır ve eşek için bir acıdır).

B. Yeni sürümler için yazılmış kod, eski sürümlerde yazılmış kodlarla uyumlu olmayabilir. Bunun için dilin birçok ana versiyonunu idare edebilecek bir tercüman / derleyici kullanarak çalışabilirsiniz, ancak bu, ayrı tercümanlar / derleyicileri (A için geçici çözüm) desteklemekten daha çok acı vericidir.

C. Büyük değişiklikler, çok sık / hızlı bir şekilde gerçekleşmesi durumunda, aynı zamanda, daha fazla öğreneceğiniz ve öğreneceğiniz bir dili olduğundan, dili kullanmayı zorlaştırır. Bir dilde yapılan değişiklikler, insanları yeni bir dile geçmeye zorlayabilir veya kişilerin dilin eski sürümlerini kullanmaya devam etmesine ve sadece yeni sürüme geçmemesine neden olabilir (python ile olduğu gibi). Sonra tekrar, değişiklikler aynı zamanda yeni kullanıcıları çekebilir ve eskileri heyecanlandırabilir.

D. Yeni belgelerin muhafaza edilmesi ve muhafaza edilmesi gerekir. Google'da bazı şeyleri aramak ve şu anda kullanmakta olduğunuzdan farklı bir sürüm için dokümanlar okuduğunuzu bulmak için her zaman oldukça kafa karıştırıcı bir deneyim.

Genel olarak, eğer harici modüllerin hangi sürümü kullandığınızı umursamaya gerek duymadığı bir programlama dili oluşturursanız, doğru nedenlerle geriye doğru uyumluluğu kırmak (dildeki ana kusurları gidermek) neredeyse kesinlikle doğru olanı yapmaktır. . Bunun yapılmamasının en büyük sebebi, programlama dili tasarımcılarının özellikle başlarda uyumluluğun kırılma maliyetini abartması ( başkasının cevabına aykırı olması) muhtemel olmasıdır . Gerçek şu ki, uyumsuzluk kırma sorunları bu dilin kullanıcıları tarafından çözülebilir ya da çözülebilir. Ve bu sadece programlama dilleri için geçerli değildir; Bu API'ler, kullanıcı arayüzleri için geçerlidir - herhangi bir durumda gerçekten herhangi bir arayüz.

Facebook, kullanıcı arayüzünü veya geliştirici API'lerini değiştirdiğinde insanları rahatsız ediyor. Geçmişte, platform ile çalışmak zorlaştı. Bazı durumlarda, API'ler yalnızca mavi dışında çalışmayı durdurdu. Ancak insanlar onu kullanmaya devam etti ve şimdi API'ler ve kullanıcı arayüzleri 5 yıl öncekinden daha iyi sıçradı ve sınırlandı. İnsanlar değişimin onlar için iyi ya da kötü olup olmadığından şikayet edeceklerdir, ancak bu (şikayet etme) bu değişikliği bırakmak için iyi bir neden değildir. Ne yazık ki, programlama dili geliştiricileri bunu, dillerinin problemlerini sağlam tutmak için bir neden olarak kullanırlar.

Bu nedenle, dillerin kendilerini geliştirmek için değişiklik yapmamasının birkaç nedeni de şunlardır:

E. Dil geliştiricileri, kullanıcılarının değişim korkusundan, dillerini durgunlaştırmak için iyi bir neden olduğunu düşünüyor.

F. Dil geliştiricileri, dillerini yaptıklarında bir nevi beğenmişlerdir ve büyük olasılıkla kusurlarının iyi olduğunu düşünmektedirler.

G. Yaşlandıkça diller genellikle küçük bir çekirdek geliştirici grubuna sahip olmayı bırakıp daha fazla komite tarafından yaratılan canavarlara dönüşür. Bu, bu dillerle ilgili kararların yavaş, genellikle muhafazakar ve yaratıcı olmadığı anlamına gelir.

H. Son sebep, bazı kırılma değişikliklerinin tercüman / çalışma zamanı için verilen tasarım kararlarının yeniden değerlendirilmesini gerektirmesidir. Bazen dilin iyileştirilmesi mümkün olması için çok fazla çalışma gerektiriyor. Bunun çoğu kişiden daha nadir bir sorun olduğunu tahmin ediyorum.

Genellikle, dil tasarımcılarının mutlaka araç tasarımcıları olmaları gerekmez ve bu nedenle bu soruna iyi çözümler düşünmezler veya bunları iyi uygulamazlar. Değişim problemini çözmeyi düşünebileceğim bazı çözümler:

1. Kaldırılacağı zamandan önce işleri çok az kullan.

2. İyi , standart bir dönüştürücü aracı sağlayın . Python 2to3 aracını sağladı, ancak iyi tanıtılmadı, hatırladığım kadarıyla python 3 ile standart olarak gelmedi ve çok iyi çalışmadı (sorunları çözmek için 2to3 tarafından oluşturulan programları manuel olarak gözden geçirmem gerektiğini hatırlıyorum. tamir etmedi). Derleyici / tercümanınız eski bir sürüm tespit ederse, bu dönüştürücü aracı otomatik olarak çalıştırılabilir. Daha kolay ne olabilir?

Bunun PHP kodu için bir sorun olup olmadığını bilmiyorum, ancak birçok dilde, eski kod yıllar sonra hiçbir zaman güncellenmez veya bazen on yıllar boyunca bile çalışır, çünkü çalıştığından, çalışan işletme için çok önemlidir (çok Milyonlarca SLOC), yani yeniden yazmak mantıklı olmaz. Java'nın eski kütüphaneleri bilmesine rağmen, özellikle kütüphanelerde (güncellemeleri daha kolay olsalar bile) geriye dönük bir uyumluluğun neredeyse dini bir mesele haline gelmesinin bir nedeni budur. Sanırım Linux çekirdeğindeki pek çok kod C99 ve C11 gibi standartların benimsenmesine rağmen onlarca yıldır güncellenmedi.

Daha az "entreprisey" olan dillerde bile, eski, işlevsel kodu kırmak bir sorun olabilir. Python 2 -> 3'te olan şey buydu. Bir sürü kitaplık ve sistem el yazısı sabit kalmıştı ve artık devam etmiyorlardı, terkedildikleri için değil, istikrarlı oldukları ve işlerini yaptıkları için. Bunları uyarlamak birkaç yıl alır. Bu nedenle, bir geliştirici olarak, en sevdiğiniz kitaplık henüz hamle yapmadıysa, mutlaka python 3'e atlayamazsınız, bu nedenle kendi kodunuz python 3 altında da çalışmayacak ve böylece topluluk parçalanmasına neden olacaktır.

Sorun geriye dönük uyumluluk sorununda yatmaktadır. Çalıştırdığım PHP betiklerinin çoğu eski bir RedHat sunucusunda çalışıyor. Dilin yeni sürümünü gelecekteki komut dosyaları için kullanacak olsaydım, PHP'yi bu sunucuda güncellemem gerekirdi ve eski komut dosyalarımın kırılması / tüm eski kodun yeniden yazılması için saat sürmesi gerekiyordu. Yeni standart Ayrıca, tüm geliştiricilerim PHP'nin belirli bir şekilde yanıt vermesine alışkın (bu şekilde 'bozuk' olsun veya olmasın). Artık bu şekilde tepki vermezse, geliştiriciler temelde kendilerine PHP'yi yeniden öğretmek zorunda kalabilecekleri için verimlilik açısından büyük bir engel olabilir.