अपनी दोषों को ठीक करने के लिए प्रोग्रामिंग भाषा को पीछे की ओर संगत रखें

56

सबसे पहले, कुछ संदर्भ (सामान जो आप में से ज्यादातर वैसे भी जानते हैं):

हर लोकप्रिय प्रोग्रामिंग भाषा का एक स्पष्ट विकास होता है, इसका अधिकांश समय इसके संस्करण द्वारा चिह्नित होता है: आपके पास जावा 5, 6, 7 आदि, PHP 5.1, 5.2, 5.3 आदि हैं। नया संस्करण जारी करने से नए एपीआई उपलब्ध होते हैं, बग को ठीक करते हैं, कहते हैं नई सुविधाएँ, नई रूपरेखाएँ इत्यादि।

लेकिन भाषा की (या मंच की) समस्याओं के बारे में क्या? यदि और जब किसी भाषा में कुछ गलत है, तो डेवलपर्स इसे (यदि वे कर सकते हैं) से बचते हैं या वे इसके साथ रहना सीखते हैं।

अब, उन भाषाओं के डेवलपर्स को प्रोग्रामर से बहुत अधिक प्रतिक्रिया मिलती है जो उनका उपयोग करते हैं। इसलिए यह समझ में आता है कि जैसे-जैसे समय (और संस्करण संख्या) बढ़ता जाएगा, उन भाषाओं में समस्याएं धीरे-धीरे आएंगी लेकिन निश्चित रूप से दूर हो जाएंगी। असल में ऐसा नहीं है। क्यों? पीछे संगतता, यही कारण है कि। लेकिन ऐसा क्यों है? अधिक ठोस स्थिति के लिए नीचे पढ़ें।

सबसे अच्छा तरीका है कि मैं अपने सवाल का एक उदाहरण के रूप में PHP का उपयोग कर सकते हैं:

PHP को हजारों लोगों से प्यार और नफरत है। सभी भाषाओं में दोष हैं, लेकिन जाहिर तौर पर PHP विशेष है। की जाँच करें इस ब्लॉग पोस्ट । यह PHP में तथाकथित दोषों की एक बहुत लंबी सूची है। अब, मैं एक PHP डेवलपर नहीं हूं (अभी तक नहीं), लेकिन मैं इसे सभी के माध्यम से पढ़ता हूं और मुझे यकीन है कि उस सूची का एक बड़ा हिस्सा वास्तव में वास्तविक मुद्दे हैं। (यह सब नहीं है, क्योंकि यह संभावित व्यक्तिपरक है)।

अब, अगर मैं उन लोगों में से एक था जो सक्रिय रूप से PHP विकसित करते हैं, तो मैं निश्चित रूप से उन समस्याओं को ठीक करना चाहूंगा, एक-एक करके। हालांकि, अगर मैं ऐसा करता हूं, तो कोड जो भाषा के किसी विशेष व्यवहार पर निर्भर करता है, अगर वह नए संस्करण पर चलता है तो टूट जाएगा। इसे 2 शब्दों में समेटना: पश्चगामी अनुकूलता।

मुझे समझ में नहीं आ रहा है: मुझे पीएचपी को पीछे क्यों रखना चाहिए? यदि मैं उन सभी समस्याओं के साथ PHP संस्करण 8 जारी करता हूं, तो क्या मैं यह कहते हुए एक बड़ी चेतावनी नहीं दे सकता कि: "इस संस्करण पर पुराना मत चलाओ!"।

एक चीज है जिसे डिप्रेसेशन कहा जाता है। हमारे पास यह वर्षों से था और यह काम करता है। PHP के संदर्भ में: इन दिनों में देखें कि लोग सक्रिय रूप से mysql_*कार्यों के उपयोग को कैसे हतोत्साहित करते हैं (और इसके बजाय अनुशंसा mysqli_*और पीडीओ)। पदावनति कार्य। हम इसका उपयोग कर सकते हैं। हमें इसका उपयोग करना चाहिए। यदि यह कार्य करता है, तो इसे संपूर्ण भाषाओं के लिए काम क्यों नहीं करना चाहिए?

मान लें कि मैं (PHP का डेवलपर) ऐसा करता हूं:

उन सभी दोषों के साथ PHP का एक नया संस्करण लॉन्च करें (मान लें 8)
नई परियोजनाएं उस संस्करण का उपयोग करना शुरू कर देंगी, क्योंकि यह बहुत बेहतर, स्पष्ट, अधिक सुरक्षित आदि है।
हालांकि, PHP के पुराने संस्करणों को नहीं छोड़ने के लिए, मैं इसे अपडेट जारी करता रहता हूं, सुरक्षा मुद्दों, बग्स आदि को ठीक करता हूं। यह उन कारणों के लिए समझ में आता है जो मैं यहां सूचीबद्ध नहीं कर रहा हूं। यह सामान्य अभ्यास है: उदाहरण के लिए देखें कि ओरेकल ने MySQL के संस्करण 5.1.x को कैसे अपडेट किया, भले ही यह ज्यादातर संस्करण 5.5.x पर केंद्रित था।
लगभग 3 या 4 वर्षों के बाद, मैंने PHP के पुराने संस्करणों को अपडेट करना बंद कर दिया और उन्हें मरने के लिए छोड़ दिया। यह ठीक है, क्योंकि उन 3 या 4 वर्षों में, अधिकांश परियोजनाओं को वैसे भी PHP 8 में बदल दिया गया होगा।

मेरा सवाल है: क्या ये सभी कदम समझ में आते हैं? क्या ऐसा करना कठिन होगा? अगर यह किया जा सकता है, तो यह क्यों नहीं किया गया है?

हां, नकारात्मक पक्ष यह है कि आप पीछे की संगतता को तोड़ते हैं। लेकिन क्या यह कीमत चुकाने लायक नहीं है? उल्टा, 3 या 4 वर्षों में आपके पास एक ऐसी भाषा होगी, जिसकी 90% समस्याएं ठीक हो चुकी हैं .... एक ऐसी भाषा जिसके साथ काम करना अधिक सुखद है। इसका नाम इसकी लोकप्रियता सुनिश्चित करेगा।

संपादित करें : ठीक है, इसलिए मैंने खुद को सही ढंग से व्यक्त नहीं किया जब मैंने कहा कि 3 या 4 साल में लोग काल्पनिक PHP में चले जाएंगे 8. मेरा क्या मतलब था: 3 या 4 वर्षों में, लोग PHP 8 का उपयोग करेंगे यदि वे एक शुरू करते हैं नया काम।

programming-languages backward-compatibility

— राडू मुरझिया
स्रोत

31

PHP इस विशेष प्रश्न के लिए एक बुरा उदाहरण है, क्योंकि अधिक बार आप उस संस्करण को नहीं चुनते हैं जिसके साथ आप काम करेंगे। अधिकांश PHP साइटें साझा किए गए सर्वरों पर तैनात हैं, और सर्वर का स्वामी संस्करण चुन रहा है, आप नहीं। प्रत्येक नए संस्करण के साथ बहुत सारे और बहुत सारे सामान निश्चित हो जाते हैं ( mysql_*उदाहरण के लिए, 5.5 में अपदस्थ किया गया था), लेकिन यह अप्रासंगिक है अगर होस्टिंग प्रदाताओं में से अधिकांश एक या दो संस्करण पीछे हैं (5.3 - दुर्भाग्य से - अभी भी बहुमत क्या है प्रदाता प्रदान करता है)।

— यनीस

5

... मुझे यह भी लगता है कि आपको कोड की मात्रा को कम करके आंका जाना चाहिए, चीजों की मात्रा जो टूट जाएगी, अनुकूलन के लिए तीसरे पक्ष की निर्भरता की मात्रा, आदि

— dagnelies

12

"मार्टियन हेडसेट" के बारे में जोएल स्पोल्स्की का यह महान ब्लॉग पोस्ट joelonsoftware.com/items/2008/03/17.html प्रत्येक डेवलपर के लिए अनिवार्य होना चाहिए जो बैकवर्ड संगतता के महत्व को कम करता है।

— डॉक ब्राउन

3

इसके अलावा, PHP धीरे-धीरे हर एक रिलीज के साथ कार्यक्षमता में कमी कर रही है - और परिणामस्वरूप बहुत सी चीजें टूट जाती हैं। दुर्भाग्य से, PHP एक मुश्किल जगह में फंस गया है, जहां उनके पास एक कठिन समय है यहां तक कि एक तरह से डिप्रेसेशन चेतावनियां भी पैदा होती हैं, जो डेवलपर्स को देखेंगे कि वे वैसे भी साइटों को बाधित नहीं करेंगे।

— शराबी

20

python 2.x => python 3.x एक अच्छी तरह से डिज़ाइन की गई भाषा से दूसरी, थोड़ी बेहतर डिज़ाइन की गई भाषा का एक परिवर्तन है, जिसमें कई असंगत निर्माणों को स्वचालित रूप से बदलने के लिए पहली पार्टी का समर्थन है। उनके बीच पोर्टिंग कोड लगभग उतना ही आसान है जितना आप दो भाषाओं के बीच बदलाव कर सकते हैं। Py3k अभी भी बहुत धीरे-धीरे जमीन पा रहा है।

— फॉशी

25

यह ठीक लगता है, लेकिन शायद ही कभी अभ्यास में काम करता है; लोग रनिंग कोड को बदलने के लिए बेहद अनिच्छुक हैं, और यहां तक कि नए, ग्रीन-फील्ड प्रोजेक्ट्स के लिए वे भाषा / संस्करण से स्विच करने के लिए बहुत अनिच्छुक हैं जो वे पहले से जानते हैं।

मौजूदा बदलना, कोड चलाना जो "ठीक काम करता है" ऐसा कुछ नहीं है जो किसी भी परियोजना की प्राथमिकता सूची में उच्च स्थान पर है। उन चीज़ों के लिए प्रयास करने के बजाय जो प्रबंधकों ने सोचा था कि पहले से ही भुगतान किया गया था, बस एक भाषा या प्लेटफ़ॉर्म की एक नई रिलीज़ में अपग्रेड करने में सक्षम होने के लिए, वे यह तय करेंगे कि डेवलपर्स को "अभी के लिए" पुरानी रिलीज़ पर रहना चाहिए। आप अपने उपयोगकर्ताओं को केवल नई रिलीज़ में उपलब्ध शानदार विशेषताओं के साथ लुभाने की कोशिश कर सकते हैं, लेकिन यह एक जुआ है जहाँ आप भाषा के लिए कोई स्पष्ट लाभ के लिए अपने उपयोगकर्ता आधार को कम करने का जोखिम उठाते हैं; लोकप्रिय राय में खंडित स्थापना आधार की कीमत के खिलाफ शांत, आधुनिक सुविधाओं को आसानी से तौला नहीं जा सकता है और आप "अपग्रेड ट्रेडमिल" होने के लिए प्रतिष्ठा पाने का जोखिम उठाते हैं।

(जाहिर है, यह ज्यादातर केवल अपने स्वयं के आनंद के लिए hobbyists द्वारा लिखित परियोजनाओं पर लागू नहीं होता है। हालाँकि, यहाँ (लौकिकता हो ...) PHP अव्यवस्थित रूप से शायद ही कभी हैकर्स द्वारा चुना जाता है क्योंकि यह पहली जगह के साथ लिखने के लिए इस तरह की खुशी है। )

— किलियन फोथ
स्रोत

65

आप पश्चगामी अनुकूलता के प्रभाव को कम आंक रहे हैं; आपका अनुमान है कि सभी सक्रिय परियोजनाएं 3 या 4 वर्षों में माइग्रेट होंगी, यह बहुत आशावादी है।

मान लीजिए मैं एक PHP डेवलपर हूं। PHP में खामियां हैं, लेकिन मुझे पता है कि उन खामियों के आसपास कैसे काम किया जाए - यही कारण है कि मुझे PHP डेवलपर के रूप में भुगतान किया जाता है। अब मान लीजिए कि PHP 8 बाहर आती है और उन खामियों को ठीक करती है, लेकिन यह पीछे की ओर संगत नहीं है। नतीजतन:

मुझे PHP 8 के लिए अपने कोड को अपडेट करने में समय बिताना होगा। यही समय है कि मैं ग्राहकों के अनुरोधों का जवाब दे सकता हूं, नई सुविधाओं को लागू कर सकता हूं, प्रतियोगिता में बना रह सकता हूं।
मेरे द्वारा ऐसा किए जाने के बाद भी , एक अच्छा मौका है कि मैंने कुछ कोने के मामले या अप्रत्याशित संगतता मुद्दे को याद किया है, जो मेरे कोड में बग को पेश करता है।

इसे देखते हुए, PHP 8 में कभी भी प्रवास न करने का एक मजबूत प्रोत्साहन है , भले ही यह "बेहतर, स्पष्ट, अधिक सुरक्षित हो आदि।" यह अनुमान है कि कॉबोल (!) की अभी भी अरबों पंक्तियाँ हैं - भले ही स्पष्ट रूप से बहुत बेहतर प्रौद्योगिकियाँ उपलब्ध हैं, एक अद्यतन की लागत, बग के जोखिम के साथ संयुक्त, बस इसके लायक नहीं है।

दूसरा, भले ही मैं अपने कोड को माइग्रेट करने का निर्णय लेता हूं, कोई भी nontrivial ऐप तीसरे पक्ष के पुस्तकालयों पर निर्भर करता है, और इस बात की कोई गारंटी नहीं है कि तीसरे पक्ष के पुस्तकालय माइग्रेट करेंगे। उदाहरण के लिए, Python 3 को दिसंबर 2008 में रिलीज़ किया गया था, लेकिन Django (शायद अग्रणी Python वेब फ्रेमवर्क) के पास लगभग पांच वर्षों तक स्थिर, उत्पादन-तैयार Python 3 समर्थन नहीं था ( यहां और यहां देखें )।

— जोश केली
स्रोत

8

वहाँ विशेष रूप से पुरानी बीमा कंपनियों Oo

— चाड हैरिसन

1

@ जोश केली: मैं आपसे सहमत हूं लेकिन मुझे लगता है कि ये समस्याएं केवल उन भाषाओं को प्रभावित करती हैं जिनमें आप स्पष्ट रूप से नए कोड से विरासत कोड को अलग नहीं कर सकते हैं, जैसे कि Python, PHP क्योंकि आपको पुस्तकालयों को शामिल करने की आवश्यकता है, और C ++ (टेम्प्लेट)। एक अलग संकलन मॉडल (जैसे जावा, स्काला, क्लोजर) के साथ भाषाएं दिखाती हैं कि विरासत कोड (जैसे जावा में) भले ही दो भाषाओं के स्रोत कोड स्तर पर संगत नहीं हैं, नए कोड (जैसे क्लोजर में) जोड़ना संभव है।

— जियोर्जियो

2

मुझे नहीं पता कि मुझे इसे एक अलग प्रश्न के रूप में या टिप्पणी के रूप में पोस्ट करना चाहिए। लेकिन वे एक प्रोग्रामिंग भाषा क्यों नहीं बना सके जो एक प्रथम श्रेणी अवधारणा के लिए कोड माइग्रेशन को बढ़ाता है? जावा में, एक @Deprecated एनोटेशन है जो आपको चेतावनी देता है। शायद दूसरी भाषा वास्तव में एक मैक्रो प्रदान कर सकती है जो पुराने कोड को सही नए कोड के साथ बदल देती है। यदि आप नवीनतम संस्करण का उपयोग कर रहे हैं तो यह पदावनत कोड को कॉल करने के लिए एक त्रुटि है, लेकिन पुराने कोड को गैर-डिप्रेस्ड नए कोड का उपयोग करने के लिए परिवर्तित किया जाता है। बस स्पिटबॉलिन '

— डैनियल कपलान

7

@tieTYT - कुछ प्रोग्रामिंग लैंग्वेज ऐसा करती हैं - पाइथन की 2to3 या गो की gofix ( वार्ता . golang.org/2012/splash.slide#68 ) देखें। यह निश्चित रूप से पुरानी विशेषताओं को चित्रित करने में मदद करता है, लेकिन इसकी सीमाएं हैं कि भाषा के शब्दार्थ में परिवर्तन होने पर सॉफ़्टवेयर अन्य सॉफ़्टवेयर को कितनी अच्छी तरह समझ और अपडेट कर सकता है।

— जोश केली

3

@hydroparadise मेरी चाची बैंकों और बीमा कंपनियों के साथ डेवलपर के रूप में काम करती है, और संकट के इन दिनों में उनकी कंपनी के कुछ ग्राहकों ने COBOL पर वापस जाने का फैसला किया क्योंकि सॉफ्टवेयर सस्ता है! यहां तक कि अर्थव्यवस्था उस दर को प्रभावित कर सकती है जिस पर कंपनियां नई भाषाओं / संस्करणों में जाती हैं।

— बकुरीउ

17

आप मानव व्यवहार के बारे में बहुत सी धारणाएँ बना रहे हैं। यदि आप इसे बहुत अधिक बदल देते हैं, तो लोग आपके प्रतिस्पर्धियों का मूल्यांकन करेंगे, क्योंकि उन्हें वैसे भी स्विच करने के लिए महत्वपूर्ण प्रयास करना होगा। ओपन सोर्स लैंग्वेज के लिए लोग पुराने वर्जन को ही फोर्क करेंगे।

एक उदाहरण के लिए अजगर को देखें। 3.x चार साल के लिए उपलब्ध है, और अभी भी व्यापक रूप से अपनाया नहीं गया है। लोग इसे नए प्रोजेक्ट के लिए इस्तेमाल करने की कोशिश करते हैं, लेकिन मुझे लगता है कि आप बस इतना ही कम आंक रहे हैं कि कितना कोड काम है।

बेशक, ज्यादातर लोग अजगर 2.x को "दोषपूर्ण" नहीं मानते थे। उनके पास php उपयोगकर्ताओं की तरह शिकायतें नहीं थीं। Php अधिक अनिश्चित स्थिति में है, क्योंकि बहुत सारे लोग केवल इसके बड़े मौजूदा कोड आधार के कारण इसके साथ चिपके रहते हैं। यदि आप पीछे की संगतता खो देते हैं, तो बहुत से लोग उस अवसर को ले लेंगे जो वे अजगर के लिए आगे बढ़ने का इंतजार कर रहे हैं।

— कार्ल बेवफेल्ड
स्रोत

मुझे लगता है कि आपके पास यहां (+1) एक अच्छा बिंदु है। मुझे लगता है कि पिछड़ी संगतता एक झूठी समस्या है, विशेष रूप से संकलित भाषाओं के लिए जिसमें आप अलग संकलन का उपयोग कर सकते हैं (देखें कि आप जावा के साथ स्काला और क्लोजर को कैसे एकीकृत कर सकते हैं, या सी # के साथ सी + +)। लेकिन यह महसूस करते हुए कि नई भाषा, सब के बाद, पुराने के अपडेटेड वर्जन की तरह ही एक कांटे से बचने के लिए बहुत महत्वपूर्ण है या लोग बस दूसरी भाषा में चले जाते हैं। मुझे लगता है कि ये कारण विरासत कोड से निपटने की तुलना में बहुत मजबूत हैं।

— जियोर्जियो

1

@ जियोर्जियो झूठी समस्या? उस सभी पुस्तकालय लेखकों को बताएं जिन्हें एक ही समय में एक भाषा के अधिक संस्करणों का समर्थन करना है।

— 19

@ शविक: अलग संकलन के साथ आपको किसी भाषा के विभिन्न संस्करणों का समर्थन करने की आवश्यकता नहीं है। उदाहरण के लिए देखें कि कैसे Scala जावा पुस्तकालयों का उपयोग कर सकता है जो Scala के लिए संकलित नहीं हैं।

— जियोर्जियो

9

PHP के अलावा किसी भी भाषा के लिए मैं कहूँगा, हाँ, यह बिल्कुल समझ में आता है! ठीक यही हाल अजगर 3 के स्विच के साथ कर रहा है।

हालाँकि, PHP के साथ समस्या यह है कि भाषा डिज़ाइन के साथ बहुत अधिक खामियाँ हैं, इस प्रकार जिसे आप "PHP 8" कह रहे हैं वह पूरी तरह से अलग भाषा होगी। और यदि आपको अलग-अलग भाषा में स्विच करना है, तो आप मौजूदा और स्थिर विकल्पों में से किसी के बजाय नए PHP के साथ क्यों चिपके रहेंगे?

इसके अलावा PHP समुदाय कुछ भी नया करने के लिए बहुत धीमा है। बस देखो कितना समय लग गया छुटकारा पाने में register_globals। यह वर्ष 2000 से सुरक्षा जोखिम के रूप में जाना जाता है। इसे केवल 12 साल बाद ही हटा दिया गया है। एक अन्य उदाहरण, जब PHP5 को पेश किया गया था, तो यह PHP4 पर भारी सुधार था, फिर भी समुदाय ने इसे अनुकूलित नहीं किया। मैंने गोद लेने के लिए जम्परपी 5 जैसे 4 साल और बड़े पैमाने पर कार्रवाई की । और यह भी महत्वपूर्ण मात्रा में पीछे असंगत परिवर्तन नहीं था।

— vartec
स्रोत

5

अस्वीकरण: मैं एक कोल्डफ्यूजन उपयोगकर्ता समूह का प्रबंधन करता हूं।

कोल्डफ्यूजन एक ही समस्या से ग्रस्त है: कई लोगों द्वारा प्यार, कई लोगों द्वारा तिरस्कृत। इसके अलावा, पूर्व-जावा संस्करणों के आधार पर टन और टन FUD। कोल्डफ्यूजन 10 पिछले साल सामने आया, एक बहुत बड़ा विक्रेता है और पिछले हफ्ते मैंने संस्करण 11 के पूर्व-रिलीज़ का परीक्षण करने के लिए साइन अप किया। इसके अलावा, दो प्रमुख ओपन सोर्स विकल्प हैं, एक JBoss द्वारा समर्थित है।

CF10 में नए कार्यों के टन हैं जिन्हें मैं लागू करना पसंद करूंगा, लेकिन CF 7 या 8 से माइग्रेट करना आपके कोड आधार के आकार, आगामी परियोजनाओं की संख्या और उन संसाधनों के आधार पर मुश्किल हो सकता है जिन्हें आपको एक बार परीक्षण करने के बाद फिर से परीक्षण करना होगा नवीनतम संस्करण पर फिर से। मैं 8 और 9 के बीच कई छोटे वाक्यविन्यास अंतरों में भाग लिया हूं, साथ ही किनारे के मामले जहां कोड उसी तरह से संकलित नहीं करता है। एक बार मिल जाने के बाद, मैंने उन्हें अपने कोडिंग मानकों में प्रलेखित किया ताकि भविष्य की परियोजनाओं में या नए डेवलपर्स द्वारा उनका उपयोग न किया जाए।

कहा कि, अगर कोल्डफ्यूजन 11 (या किसी भी प्रोग्रामिंग भाषा) को कुछ कार्यों और वाक्यविन्यास को पूरी तरह से चित्रित करना था, तो कार्यक्षमता को खोजने और बदलने के प्रयास का स्तर बहुत बड़ा हो सकता है। परीक्षण का प्रयास गरमागरम हो सकता है। क्या कंपनियां अपने डेवलपर्स, क्यूए और परियोजना प्रबंधकों को उन सभी अस्वीकृत चीजों को खोजने, बदलने और परीक्षण करने के लिए भुगतान करेंगी? संदिग्ध।

यदि किसी भाषा का नवीनतम संस्करण पीछे की ओर संगत है, लेकिन बिना किसी कोड परिवर्तन के प्रदर्शन में वृद्धि का परिचय देता है (CF9 CF8 की तुलना में लगभग 30% अधिक तेज है और CF10 CF9 की तुलना में बहुत तेज है), जो अभी भी काम करते हैं तो फ़ंक्शन कॉल के बारे में परवाह है?

एक कंपनी के रूप में, हमें अपने ग्राहकों को खुश करने और सेवाओं को बिल करने, व्यवसाय का निर्माण करने और अधिक ग्राहकों की भर्ती करने के लिए उनकी जरूरतों को पूरा करने के बारे में चिंता करनी होगी।

FWIW, मुझे कुछ समय में jQuery के नवीनतम संस्करण में हमें प्राप्त करना अच्छा लगेगा, लेकिन चूंकि कुछ फ़ंक्शन का उपयोग करने के बाद कुछ संस्करणों को हटा दिया गया था, और सिस्टम में हमारे पास जावास्क्रिप्ट की मात्रा को देखते हुए, मुझे नहीं पता कि कैसे हम इसे बंद करने जा रहे हैं।

— एड्रियन जे। मोरेनो
स्रोत

4

यहाँ एक व्यापार है; कुछ बगों को ठीक करने की आवश्यकता है, लेकिन कुछ चीजों को किसी के कोड को बिना तोड़े कहीं नहीं बदला जा सकता है। मुझे लगता है कि किसी को "नियम" बताते हुए याद रखना चाहिए कि हर बगिफ़ किसी के प्रोजेक्ट को तोड़ देगा, चाहे वह कितना भी अस्पष्ट या स्पष्ट रूप से बग क्यों न हो, कोई व्यक्ति किसी चीज़ के लिए इसका इस्तेमाल कर रहा होगा। ऐसा प्रोग्रामर्स का स्वभाव है।

यह (मेरे दिमाग में) प्रमुख रिलीज, मामूली रिलीज और संशोधन के बीच का अंतर है। एक सामान्य सिद्धांत के रूप में:

ब्रेकिंग परिवर्तनों को शामिल करने के लिए प्रमुख रिलीज़ को माना जाता है।
मामूली रिलीज से व्यवहार थोड़ा बदल सकता है।
संशोधन बहुत अधिक क्रॉस-संगत होना चाहिए।

उदाहरण के लिए, अगर मैं किसी भाषा के v2.3 में कुछ लिख रहा हूं, तो मुझे v2.3.2 में अपग्रेड करने पर किसी भी अंतर की सूचना मिलने की उम्मीद नहीं है। अगर मैं v2.4 में अपग्रेड करता हूं, तो कुछ चीजें बदल सकती हैं - छोटे सिंटैक्स ट्वीक्स, कुछ फंक्शन्स थोड़ा अलग तरह से व्यवहार करते हैं इसलिए मुझे लॉजिक को ट्विक करना होगा, अगर मैं v3.0 में अपग्रेड करता हूं, तो मुझे आश्चर्य नहीं होगा अगर इसे तोड़ दिया जाए पूरी तरह से - कार्य पदावनत या लापता, संचालन समर्थित नहीं है या इतना बदल गया है कि मैं इसे केवल पंक्ति में वापस नहीं कर सकता, मुझे वास्तव में नए परिवर्तनों के लिए कुछ कार्यों को फिर से लिखना होगा।

संपादित करें:

स्टीव वेंस के पेपर एडवांस्ड एससीएम ब्रांचिंग स्ट्रैटेजीज में यह कहना है:

आमतौर पर, रिलीज़ के दो से तीन स्तर होते हैं, जिनका नाम पीरियड्स से जुड़ा होता है (उदाहरण 1.2.3)। [...] इस संरचना में पहला नंबर एक प्रमुख संस्करण के साथ जुड़ा हुआ है, यह दर्शाता है कि इसमें पिछली से महत्वपूर्ण विशेषता और कार्यात्मक वृद्धि है; वहाँ भी हो सकता है महत्वपूर्ण असंगति है कि प्रवास की आवश्यकता है। दूसरा नंबर एक मामूली संस्करण का प्रतिनिधित्व करता है, जिसमें कम फ़ीचर और फ़ंक्शन एन्हांसमेंट, बग फिक्स की एक महत्वपूर्ण संख्या और कोई असंगति नहीं है। तीसरा नंबर पैच स्तर को संदर्भित करता है, जो लगभग विशेष रूप से बग फिक्स का एक संग्रह दर्शाता है; पैच स्तरों के बीच कोई सुविधा या फ़ंक्शन एन्हांसमेंट और कोई असंगति की अनुमति नहीं है।

केवल एक ही परिवर्तन मैं इसे उपरोक्त सिद्धांत के रूप में बताता हूँ कि प्रोग्रामर अक्सर "बग" का उपयोग करने के तरीके ढूंढते हैं, इसलिए "बग फिक्स की एक महत्वपूर्ण संख्या, और कोई असंगति नहीं है" के साथ एक मामूली संस्करण मुश्किल हो सकता है, क्योंकि यह संभावना है कि उन बग या तो किसी ऐसी चीज को तोड़ देंगे जो उनका उपयोग करती है, या एक अनावश्यक कारण बन जाएगा और समस्या पैदा करना शुरू कर देगा।

— Anaximander
स्रोत

मैं कार्यक्षमता जोड़ने के लिए 2.3-> 2.4 की अपेक्षा करता हूं, लेकिन इसे हटा नहीं।

— डोनल फैलो

1

संयोग से, मैं हाल ही में एक प्रासंगिक उद्धरण में आया था। यह एक टिप्पणी के लिए थोड़ा लंबा है, इसलिए मैं अपना जवाब संपादित करूंगा।

— अनएक्समैंडर

2

यह वास्तव में इस बात पर निर्भर करता है कि भाषा का लक्ष्य क्या है - भाषा के साथ किस प्रकार के अनुप्रयोगों का निर्माण करने का इरादा है।

उदाहरण के लिए, एंड्रॉइड को अनदेखा करना, जावा का उपयोग ज्यादातर बड़े एंटरप्राइज़ सिस्टम और मध्य-वेयर में किया जाता है; इस प्रकार के अनुप्रयोग आकार और समय दोनों में बहुत बड़े हो जाते हैं। इसके कुछ निहितार्थ हैं; 500K + एलओसी के साथ एक प्रणाली की कल्पना करें जिस पर कार्यकर्ता 50+ इंजीनियरों के विकास के चरण में है। आमतौर पर इस प्रकार का सिस्टम 10 डेवलपर्स के कहने के बाद रखरखाव में प्रवेश करता है; अब अगर भाषा बदलती है और परिवर्तन पीछे नहीं होते हैं तो संगत परियोजना को आसानी से एक नए संस्करण में स्थानांतरित नहीं किया जा सकता है क्योंकि प्रोग्रामर जो कुछ हिस्सों को लिखते हैं वे चले गए हैं और कोई भी इसे छूना नहीं चाहता है। यह छोटी समस्या है, बड़ी समस्या इस तथ्य में शामिल है कि 500 एलओसी के आवेदन को नई भाषा की कमी के लिए अनुकूलित करना महंगा है। उदाहरण के लिए यदि जेनेरिक को प्रकार के क्षरण के साथ लागू नहीं किया गया था औरList list = new List(); कोड की लाखों पंक्तियों को संकलित नहीं किया जाएगा - जिन्हें फिर से लिखना होगा - जो एक महान लागत पर है।

दूसरी ओर PHP सरल अनुप्रयोगों के लिए वेब पर इस्तेमाल किया जाता है; आमतौर पर इसे एकल प्रोग्रामर या छोटी टीम द्वारा विकसित किया जाता है। विचार यह है कि डेवलपर्स पूरे प्रोजेक्ट को अच्छी तरह से जानते हैं और भाषा परिवर्तन को अधिक आसानी से एकीकृत कर सकते हैं। इसके अलावा उद्देश्य यह है कि एक साइट का निर्माण बहुत तेजी से हो, और तेजी से बेहतर हो ताकि यदि कोई नई भाषा सुविधा इस बेहतर कर सके तो इसे कुछ पश्चगामी संगतता लागतों पर भी लागू किया जाता है।

— m3th0dman
स्रोत

1

एक तर्क दे सकता है कि Microsoft ने ASP.NET (क्लासिक ASP के उत्तराधिकारी के रूप में) या VB.NET के साथ एक समान परिवर्तन किया (हालांकि बाद वाले के साथ उन्होंने इतनी रियायतें दीं कि भाषा "रिबूट" करने के अधिकांश लाभ खो गए)।

वैसे भी, अगर किसी को माइग्रेशन टूल की सहायता से VB.NET में VB6 कोड को माइग्रेट करने का दुःस्वप्न याद है, तो वे इस बात से सही सहमत होंगे कि भाषा के माइग्रेशन टूल प्रमुख भाषा अपडेट के लिए बहुत अच्छी तरह से काम नहीं करते हैं।

प्लेटफ़ॉर्म को आगे बढ़ाना संभव हो सकता है लेकिन, आपको अभी भी कम से कम कुछ संशोधनों के माध्यम से "पदावनत" एपीआई के लिए समर्थन प्रदान करना चाहिए।

— माइकल ब्राउन
स्रोत

1

लोकप्रिय प्रोग्रामिंग भाषाओं में बहुत सारे "दोषों" के बारे में लोग चिल्लाते हैं, वे चीजें हैं जो उस दिन के सपने देखने वाले का पसंदीदा खिलौना है, जिसमें उस भाषा का अभाव है, ऐसा नहीं है कि भाषा मौलिक रूप से त्रुटिपूर्ण है क्योंकि इसमें इसका अभाव है।
अगले प्रचार के आसपास आता है, भाषा अचानक दोषपूर्ण है क्योंकि यह उस प्रचार का पालन नहीं करता है।

जावा में क्लोजर की कमी एक उत्कृष्ट उदाहरण है। यह भाषा में कोई दोष नहीं है, और भाषा को बदलना (जैसा कि एजेंडे पर दुख की बात है) उन्हें शामिल करने के लिए आईएमओ मौलिक रूप से अपंग करेगा या बहुत कम से कम इसे पढ़ने और समझने के लिए बहुत कठिन बना देगा।

बहुत सारे लोग जो देखते हैं, वह यह है कि प्रत्येक भाषा की अपनी ताकत और कमजोरियां होती हैं और वह ऐसी चीज बनाने की कोशिश कर रही है जो हर कमजोरी से बचने के दौरान हर चीज के स्ट्रेंथ को जोड़ती है, केवल एक बिल्कुल बेकार राक्षस बना देगा जो कुछ भी अच्छा नहीं है, अविश्वसनीय रूप से असुविधाजनक, असंभव है। प्रभावी ढंग से उपयोग करें।

जोड़ें, जैसा कि अन्य ने बताया है, कि मौजूदा उपयोगकर्ताओं को बनाए रखने के लिए बैकवर्ड संगतता महत्वपूर्ण है, जिनमें से कई हजारों घंटे और लाखों डॉलर / यूरो खर्च करने के लिए नहीं जा रहे हैं जो आपको लगता है कि "बेहतर" है अपनी मिलियन लाइन कोडबेस को वापस लेना है। वर्षों से वे जिस भाषा का उपयोग कर रहे हैं, उसके संस्करण की तुलना में, और आप बहुत अच्छी दलीलों की मेजबानी कर रहे हैं, ताकि आप अकेले ही अच्छी तरह से छोड़ सकें और यदि आप कुछ नए ओवरहीप आइडिया के साथ खेलना चाहते हैं, जो कि अगला "जावा किलर" है। घ के साथ उस खिलौने के साथ खेलने के बजाय सबसे अच्छा है कि "जावा iz शुल्क" जब तक यह "ठीक हो जाता है" उस खिलौने का क्लोन नहीं है।

— jwenting
स्रोत

1

मेरा सुझाव है कि किसी भाषा के नए संस्करणों को यह सुनिश्चित करने का प्रयास करना चाहिए कि 99.99999% कोड जो भाषा के पुराने और नए दोनों संस्करणों में संकलित हो, दोनों में समान रूप से काम करना चाहिए जब तक कि यह जानबूझकर ऐसा नहीं करने के लिए डिज़ाइन किया गया हो, और अधिकांश समय जब नया संस्करण पुराने संस्करण के तहत संकलित कोड से इनकार करता है, तो यह इसलिए होगा क्योंकि यह कोड था - सबसे अच्छा - डोडी, और इसे एक अलग तरीके से लिखा जाना चाहिए जो पुराने और नए संकलक दोनों के तहत संकलित होगा।

उदाहरण के लिए, अगर मैं जावा या सी # के समान एक नई भाषा डिजाइन कर रहा था, तो मैं कुछ संदर्भों में निहित प्रकार के रूपांतरणों को मना करूंगा जहां उन भाषाओं की अनुमति है। सी में एक सरल उदाहरण के रूप में, दिया गया

int someInt;
double someDouble;

अभिव्यक्ति someInt.Equals(someDouble)झूठी वापस जाने के लिए चर की सामग्री की परवाह किए बिना, की गारंटी है। यह संकलित करता है क्योंकि इसमें doubleरूपांतरित किया जा सकता है Object, और उस प्रकार के लिए intएक Equalsअधिभार होता है, इसलिए संकलक रूपांतरण करता है और कॉल करता है। क्या मैं C # और .NET फ्रेमवर्क का नया संस्करण डिजाइन कर रहा था, तो मुझे बॉक्सिंग रूपांतरण के लिए मना करना होगा क्योंकि यह संभवतः कुछ भी उपयोगी नहीं हो सकता है। यह संभव है कि कुछ प्रोग्राम हो जो इस तरह की तुलना करता है जो बेकार है, लेकिन हानिरहित है, और कंपाइलर को अस्वीकार करने से ऐसे कोड उस प्रोग्राम को तोड़ सकते हैं, लेकिन इस तरह के बेकार कोड को ठीक करना या निकालना एक सुधार होगा।

थोड़ा कम स्पष्ट उदाहरण के रूप में, मान लें

float f=16777216f;
int i=16777217;

और अभिव्यक्ति पर विचार करें f==i। ऐसा नहीं है कि कुछ कोड नाव / पूर्णांक तुलना करता है और ठीक से काम करता है, लेकिन कोड या तो के रूप में लिखा जाना चाहिए संभव है f==(float)i, (double)f==i;या (double)f==(double)i;[ intकरने के लिए doubleबढ़ावा देने के दोषरहित है, इसलिए बाद के दो बराबर होगा]। कुछ कोड जो सीधे तुलना करते हैं floatऔर integerमान हमेशा उन नंबरों से निपट सकते हैं जो पर्याप्त रूप से छोटे होते हैं floatऔर doubleतुलनात्मक रूप से व्यवहार करेंगे, लेकिन एक संकलक आमतौर पर यह नहीं जान सकता है; कोड को स्पष्ट करना चाहिए कि किस तरह की तुलना की आवश्यकता है, बजाय यह उम्मीद करने के कि भाषा के नियम प्रोग्रामर के इरादे से मेल खाएंगे।

— supercat
स्रोत

1

यह सबसे अच्छा है कि पीछे की संगतता को कभी न तोड़ें।

Microsoft ने VB6 प्रोग्रामिंग भाषा को एक नई भाषा के साथ बदल दिया जिसने संगतता को पूरी तरह से तोड़ दिया। इसलिए आज भी 16 साल पुराना VB6 अभी भी डॉटनेट संस्करण (टिबे इंडेक्स अगस्त 2014) की तुलना में अधिक लोकप्रिय है। और गार्टनर का अनुमान है कि VB6 कोड की 14 बिलियन लाइनें अभी भी उपयोग में हैं।

2014 में माइक्रोसॉफ्ट को फिर से घोषणा करनी पड़ी कि वे विजुअल बेसिक प्रोग्रामिंग कम्युनिटी की मांगों के बावजूद वीबी 6 को अपडेट या ओपन नहीं करेंगे। लेकिन उन्होंने 'कम से कम' 2024 तक वीबी 6 का समर्थन बढ़ाया है, और यह विंडोज 7 और 8 पर ठीक काम करता है। वीबी 6 के एक ही संस्करण के लिए 26 साल से अधिक का समर्थन होगा।

मौजूदा काम करने वाले सॉफ़्टवेयर को फिर से लिखा जाना चाहिए, यहां तक कि माइक्रोसॉफ्ट ने भी डॉटनेट का उपयोग करने के लिए "अपडेट" कार्यालय कभी नहीं किया है?

— VB6 प्रोग्रामिंग
स्रोत

इससे पहले के 14 उत्तरों पर कुछ भी पर्याप्त नहीं लगता है

— gnat

1

पीछे की संगतता को तोड़ने के साथ कुछ अलग समस्याएं हैं। कुछ समस्याएं इस तथ्य से उपजी हैं कि अधिकांश प्रोग्रामिंग भाषाएं भी प्लेटफ़ॉर्म (दुभाषिए / रनटाइम) हैं, अन्य समस्याएं मानव प्रकृति की धारणा से उपजी हैं।

A. पुराने संस्करणों में लिखे गए कोड को प्रदर्शन, सुरक्षा या सुविधाओं में सुधार करने वाली नई रिलीज़ का लाभ नहीं मिलेगा। आप कंपाइलर / दुभाषिया के कई प्रमुख संस्करणों का समर्थन करके इस समस्या को कम कर सकते हैं, लेकिन यह एक विशाल संसाधन नाली है (यानी इसका महंगा या एक लंबा समय लगता है, और गधे में एक दर्द है)।

नए संस्करणों के लिए लिखे गए बी कोड पुराने संस्करणों में लिखे गए कोड के अनुरूप नहीं हो सकते हैं। आप एक दुभाषिया / संकलक के द्वारा इसके चारों ओर काम कर सकते हैं जो भाषा के कई प्रमुख संस्करणों को संभाल सकता है, लेकिन यह अलग-अलग दुभाषियों / संकलक (ए के लिए वर्कअराउंड) का समर्थन करने की तुलना में गधे के दर्द में अधिक है।

C. प्रमुख परिवर्तन, यदि वे बहुत बार होते हैं / जल्दी से भी बस भाषा का उपयोग करना कठिन हो जाता है, क्योंकि आपके पास सीखने और अनलिखने के लिए अधिक है। किसी भाषा में परिवर्तन करने से लोग नई भाषा पर स्विच करने के लिए किनारे पर धकेल सकते हैं, या लोगों को भाषा के पुराने संस्करणों का उपयोग करना जारी रख सकते हैं और बस नए संस्करण पर स्विच नहीं कर सकते (जैसे कि अजगर के साथ हुआ है)। फिर, परिवर्तन नए उपयोगकर्ताओं को भी आकर्षित कर सकते हैं और पुराने को उत्तेजित कर सकते हैं।

डी। नए प्रलेखन को बनाए रखने और बनाए रखने की आवश्यकता है। Google पर चीजों को देखने और हमेशा यह जानने के लिए कि आप वर्तमान में उपयोग किए जा रहे किसी भिन्न संस्करण के लिए डॉक्स पढ़ रहे हैं, यह हमेशा एक भ्रमित करने वाला अनुभव है।

यदि आप एक प्रोग्रामिंग लैंग्वेज बनाते हैं, तो बाहरी मॉड्यूल्स को इस बात की परवाह नहीं है कि आप किस संस्करण का उपयोग कर रहे हैं, सही कारणों के लिए बैकवर्ड कम्पैटिबिलिटी को तोड़ना (भाषा की बड़ी खामियों को ठीक करने के लिए) लगभग निश्चित रूप से सही काम है । इसकी संभावना है कि प्रमुख कारण ऐसा नहीं किया जाता है कि प्रोग्रामिंग भाषा डिजाइनरों जिआदा ( किसी और के जवाब खंडन करने के लिए ) अनुकूलता को तोड़ने की लागत, विशेष रूप से जल्दी पर। तथ्य यह है कि, संगतता की समस्याओं को उस भाषा के उपयोगकर्ताओं के माध्यम से काम किया जा सकता है। और यह केवल प्रोग्रामिंग भाषाओं के लिए नहीं है; यह एपीआई, उपयोगकर्ता इंटरफेस पर लागू होता है - किसी भी स्थिति में वास्तव में कोई भी इंटरफ़ेस।

जब यह अपने UI, या इसके डेवलपर API को बदलता है, तो फेसबुक लोगों को नरक से बाहर निकालता है। अतीत में, इसके मंच के साथ काम करना मुश्किल हो गया। कुछ मामलों में, एपीआई ने केवल नीले रंग से काम करना बंद कर दिया। लेकिन लोग इसका उपयोग करते रहे, और अब एपीआई और यूआई 5 साल पहले की तुलना में बेहतर हैं। लोग परिवर्तन के बारे में शिकायत करेंगे कि क्या उसके लिए अच्छा या बुरा है, लेकिन वह (शिकायत करना) उस परिवर्तन को त्यागने का एक अच्छा कारण नहीं है। दुर्भाग्य से, प्रोग्रामिंग भाषा डेवलपर्स इसका उपयोग अपनी भाषा की समस्याओं को बरकरार रखने के लिए एक कारण के रूप में करते हैं।

भाषाओं में खुद को बेहतर बनाने के लिए बदलाव न करने के कुछ और कारण हैं:

ई। भाषा डेवलपर्स को लगता है कि उनके उपयोगकर्ताओं को परिवर्तन का डर उनकी भाषा को स्थिर करने का एक अच्छा कारण है

एफ। भाषा डेवलपर्स ने अपनी भाषा को पसंद किया जब उन्होंने इसे बनाया, और वे शायद इसकी खामियों के साथ इसे ठीक समझते हैं।

जी। भाषाएं जैसे-जैसे बढ़ती जाती हैं, आमतौर पर डेवलपर्स का एक छोटा कोर सेट खत्म हो जाता है, और अधिक समिति-निर्मित जानवरों में बदल जाता है। इसका मतलब यह है कि उन भाषाओं के बारे में निर्णय धीमे और अक्सर रूढ़िवादी और गैर-जिम्मेदार होते हैं।

एच। अंतिम कारण यह है कि कुछ टूटने वाले परिवर्तनों को दुभाषिया / रनटाइम के लिए किए गए डिजाइन निर्णयों के महत्वपूर्ण पुनर्मूल्यांकन की आवश्यकता होती है। कभी-कभी भाषा में सुधार के लिए बस बहुत काम करने की आवश्यकता होती है। मुझे लगता है कि यह सबसे अधिक tho से एक दुर्लभ समस्या है।

अक्सर, भाषा डिजाइनर आवश्यक रूप से उपकरण डिजाइनर नहीं होते हैं, और इसलिए वे इस समस्या के अच्छे समाधानों के बारे में नहीं सोचते हैं, या वे उन्हें अच्छी तरह से निष्पादित नहीं करते हैं। यहाँ कुछ समाधान हैं जिन्हें मैं ब्रेकिंग-चेंज समस्या को हल करने के बारे में सोच सकता हूं:

चीजों को अच्छी तरह से आगे बढ़ाएं जब उन्हें हटा दिया जाएगा।
एक अच्छा , मानक कनवर्टर उपकरण प्रदान करें । पायथन ने 2to3 टूल प्रदान किया, लेकिन इसे अच्छी तरह से विज्ञापित नहीं किया गया था, जैसा कि मुझे याद है, अजगर 3 के साथ मानक नहीं आया था, और बहुत अच्छी तरह से काम भी नहीं किया था (मुझे याद है कि इसे समस्याओं को ठीक करने के लिए 2to3 द्वारा उत्पन्न कार्यक्रमों के माध्यम से जाना चाहिए ठीक नहीं किया)। यदि आपका कंपाइलर / दुभाषिया पुराने संस्करण का पता लगाता है तो यह कनवर्टर टूल अपने आप चल सकता है। क्या आसान हो सकता है?

— बीटी
स्रोत

फेसबुक सादृश्य के साथ समस्या यह है कि उपयोग में फेसबुक विरासत नहीं है। कोई विकल्प नहीं है। या तो आप फेसबुक के वर्तमान संस्करण का उपयोग करते हैं, या आप फेसबुक का उपयोग बिल्कुल नहीं करते हैं। इस बीच, अभी भी मौजूद Python 2होने के बाद सात साल का उपयोग करने वाले लोगों के टन Python 3है - अगर यह अभी भी मौजूद नहीं है, तो वे टटोलेंगे, लेकिन वे इसे बंद कर देंगे Python 3।

— केविन

मुझे नहीं लगता कि यह सादृश्य के साथ कोई समस्या है, यह वास्तव में मेरी बात थी। फेसबुक ने "खामियों को ठीक करने" का रास्ता चुना है और ज्यादातर "पीछे की ओर अनुकूलता" मार्ग को छोड़ दिया है। यही कारण है कि उनके पास अपने एपीआई का विरासत संस्करण नहीं है। एक चरम का इसका एक आदर्श उदाहरण है।

— बीटी

प्रोग्रामिंग भाषाओं में पीछे की ओर संगतता को तोड़ने से पुराने संस्करण का उपयोग और / या जारी रखने के लिए लोगों को आगे बढ़ाना पड़ेगा। फेसबुक का पुराना संस्करण अब मौजूद नहीं है; मुझे लगता है कि आप एक ऐसा क्लोन बना सकते हैं जो पुराने एपीआई का समर्थन करता है, लेकिन कोई भी इसका उपयोग नहीं करेगा, क्योंकि फेसबुक एक विशाल उपयोगकर्ता-आधार वाला ब्रांड है।

— केविन

फेसबुक का यह फायदा है कि जब यह अपडेट होता है, तो पिछले संस्करण अनिवार्य रूप से मौजूद नहीं होते हैं। प्रोग्रामिंग भाषाएं ऐसी नहीं हैं, और यह एक प्रासंगिक अंतर है - आप प्रोग्रामिंग भाषा के पुराने संस्करण का उपयोग कर सकते हैं, जैसे कि Python 2, क्योंकि यह अभी भी मौजूद है।

— केविन

में तुम्हारी बात समझ रहा हूँ। मुझे अब भी लगता है कि इसका दो छोर हैं। यदि किसी भाषा के असमर्थित संस्करण में बड़ी खामियां स्पष्ट हो जाती हैं, तो यह उस संस्करण की तर्ज पर मौजूद हो सकती है, क्योंकि कोई भी इसका उपयोग नहीं करना चाहेगा।

— बीटी

0

मुझे नहीं पता कि यह PHP कोड के लिए कोई समस्या है, लेकिन कई भाषाओं में पुरानी, विरासत कोड को वर्षों के बाद या कभी-कभी, यहां तक कि दशकों तक भी अपडेट नहीं किया जाता है, क्योंकि यह काम करता है, इसे चलाने वाले व्यवसाय के लिए महत्वपूर्ण है और बहुत बड़ा है (कहें लाखों SLOC), इसलिए इसे दोबारा लिखने का कोई मतलब नहीं होगा। यही वजह है कि पुरानी समस्याओं के बावजूद, विशेषकर पुस्तकालयों में (भले ही वे अद्यतन करने में आसान हों), जावा ने पिछड़े-सहानुभूति को लगभग धार्मिक मुद्दा बना दिया। मुझे लगता है कि C99 और C11 जैसे मानकों को अपनाने के बावजूद, लिनक्स कर्नेल से बहुत सारे कोड दशकों से भी अपडेट नहीं किए गए थे।

यहां तक कि ऐसी भाषाओं में जो "एंट्रेप्रेसी" कम हैं, पुराने, कार्यात्मक कोड को तोड़ना एक समस्या हो सकती है। पाइथन 2 के साथ यही हुआ है -> 3. पुस्तकालयों और सिस्टम स्क्रिप्ट का एक पूरा गुच्छा स्थिर था और अब इसे बनाए नहीं रखा गया है, इसलिए नहीं कि उन्हें छोड़ दिया गया था, बल्कि इसलिए कि वे स्थिर थे और अपना काम कर रहे थे। इन्हें अपनाने में कुछ साल लग जाते हैं। इसलिए, एक डेवलपर के रूप में, आप आवश्यक रूप से अजगर 3 पर नहीं जा सकते हैं यदि आपकी पसंदीदा लाइब्रेरी ने अभी तक कदम नहीं उठाया है, तो आपका अपना कोड अजगर 3 के तहत भी काम नहीं करेगा, इस प्रकार सामुदायिक विखंडन हो सकता है।

— फेबियन
स्रोत

-1

समस्या पश्चगामी संगतता समस्या के भीतर है। अधिकांश PHP स्क्रिप्ट जो मैं निष्पादित करता हूं वे पुराने RedHat सर्वर पर चल रही हैं। अगर मुझे भविष्य की स्क्रिप्ट के लिए भाषा के नए संस्करण का उपयोग करना था, तो मुझे इस सर्वर पर PHP को अपडेट करना होगा - और मेरी पुरानी लिपियों को तोड़ने का जोखिम होगा / पुराने सभी कोड के साथ फिर से लिखने के लिए घंटों लेने के लिए नया मानक। इसके अलावा, मेरे सभी डेवलपर्स का उपयोग एक निश्चित तरीके से प्रतिक्रिया करने के लिए पीएचपी के लिए किया जाता है (चाहे वह तरीका 'टूट गया हो' या नहीं)। यदि यह अब उस तरह से प्रतिक्रिया नहीं करता है, तो यह उत्पादकता के लिए एक बड़ी बाधा हो सकती है, क्योंकि डेवलपर्स को मूल रूप से स्वयं को फिर से सिखाना पड़ सकता है।

— ब्रैंडन
स्रोत