क्या परिवर्तन के लिए प्रोग्रामिंग भाषा को अधिक स्थिर (संगत) बनाने के लिए कोई तंत्र है?

Question

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

क्या भाषा डिजाइन चरण के दौरान कोई वास्तु सिद्धांत या कदम हैं, जो इसे और अधिक स्थिर बनाने में मदद कर सकते हैं ताकि भाषा डिजाइनर पिछड़े संगतता को तोड़ने से डरते नहीं हैं?

Comments

भाषा की स्थिरता किसी भी प्रकार के ब्रेकिंग परिवर्तन को छोड़कर। क्या आप अपना प्रश्न स्पष्ट कर सकते हैं?

— शमौन बर्गोट

मेरे लिए अधिक स्थिर होने का अर्थ है कम परिवर्तन होना (उम्मीद है कि वे आवश्यक नहीं हैं), पीछे-असंगत परिवर्तनों के बिल्कुल विपरीत। जो आप में रुचि रखते हैं, या आप दोनों स्वतंत्र रूप से पूछ रहे हैं?

@Simon कैसे एक भाषा डिजाइन करने के लिए कि जब आप नई सुविधा को जोड़ने की कोशिश कर रहे हैं तो आप वापस तुलनीयता से डरने से डरते नहीं हैं

— Viacheslav Kondratiuk

@ डेलनान ने कहा, दोनों।

— वायाचेस्लाव कोंड्राटुक

@viakondratiuk डरने की कोई बात नहीं है कि भाषा का डिज़ाइन बदल नहीं सकता। एक बेहतर सवाल यह हो सकता है "भाषा को कैसे डिज़ाइन किया जाए ताकि नई सुविधाओं को जोड़ने से ब्रेकिंग परिवर्तन न हों ?"।

— svick

Answer 1

भाषा की स्थिरता तकनीकी निर्णय नहीं है। यह भाषा लेखक और उपयोगकर्ताओं के बीच एक अनुबंध है।

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

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

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

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

Answer 2

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

• सिंटैक्स को एक्स्टेंसिबल बनाने के लिए सुविधाओं पर विचार करें, जैसे मैक्रोज़। मैक्रोज़ स्वचालित रूप से एक अच्छी चीज नहीं हैं और बहुत शक्तिशाली हो सकते हैं। कुछ भाषाओं में शुरू से ही बहुत लचीला वाक्यविन्यास है जो मैक्रोज़ की आवश्यकता को कम करता है। परिदृश्य के एक जोड़े पर विचार करने के लिए:

  • क्या मैं |>भाषा को छोड़े बिना किसी नए ऑपरेटर को पेश कर सकता हूं ? क्या मैं इस ऑपरेटर के लिए पूर्वता और सहानुभूति चुन सकता हूं?
  • इनलाइन फंक्शन / लैम्ब्डा / क्लोजर के लिए मुझे कितने समारोह से गुजरना होगा?
  • क्या मैं फ़ॉरेस्ट लूप सिंटैक्स को लागू करने के लिए मौजूदा भाषा सिंटैक्स का उपयोग कर सकता हूं? उदाहरण के लिए, रूबी और स्काला अपने लचीले तरीके कॉल लैम्बदास के साथ वाक्य रचना के माध्यम से ऐसा कर सकते हैं।

• शब्दार्थ को स्थिर रखने के लिए सुविधाओं पर विचार करें। सामान्य जरूरतें हैं:

  • ऑपरेटर ओवरलोडिंग, जहां उपयोगकर्ता-परिभाषित प्रकार मौजूदा ऑपरेटरों को अपना अर्थ दे सकते हैं। यह गणित-भारी अनुप्रयोगों में भाषा को अधिक मनोरंजक बनाता है।
  • शाब्दिक ओवरलोडिंग। क्या मैं स्ट्रिंग शाब्दिक अपने स्वयं के स्ट्रिंग प्रकार का हो सकता हूं? क्या मैं मौजूदा दायरे में सभी संख्यात्मक शाब्दिक बना सकता हूं?
  • मेटाबोजेक्ट प्रोटोकॉल। यदि भाषा में लक्षण नहीं हैं, तो क्या मैं उन्हें वर्तमान ऑब्जेक्ट सिस्टम के अंदर लागू कर सकता हूं? क्या मैं एक अलग विधि संकल्प आदेश लागू कर सकता हूं? क्या मैं वस्तुओं को संग्रहीत करने के तरीके को स्वैप कर सकता हूं या कैसे तरीके भेजे जा सकते हैं?
• प्रतिगमन परीक्षण करें। परीक्षण के बहुत सारे। न केवल भाषा डिजाइनरों द्वारा लिखित, बल्कि उपयोगकर्ताओं द्वारा भी। एक सुविधा जोड़ने पर इन परीक्षणों को तोड़ दिया जाता है, पीछे की संगतता के लाभ के खिलाफ उस सुविधा के लाभों को सावधानीपूर्वक तौलना चाहिए।
• अपनी भाषा का संस्करण। न केवल आपके दस्तावेज़ में, बल्कि स्रोत कोड में भी। एक बार जब आप ऐसा कर लेते हैं, तो आपकी भाषा का एकमात्र भाग जो परिवर्तित नहीं हो सकता है वह है यह संस्करण pragma सिंटैक्स। उदाहरण: रैकेट आपको एक बोली निर्दिष्ट करने की अनुमति देता है। पर्ल आपको अनुमति देता है use v5.20, जो पर्ल v5.20 के सभी पीछे-असंगत सुविधाओं को सक्षम करता है। आप एकल सुविधाओं को भी स्पष्ट रूप से पसंद कर सकते हैं use feature 'state'। सदृश: पायथन from __future__ import division।
• अपनी भाषा को इस तरह से डिजाइन करने पर विचार करें जिसके परिणामस्वरूप कुछ आरक्षित शब्द हों। सिर्फ इसलिए classकि एक वर्ग का परिचय देने का मतलब यह नहीं है कि मैं एक स्थानीय चर का नाम नहीं दे पाऊंगा class। व्यवहार में, इसके परिणामस्वरूप ऐसे कीवर्ड होते हैं जो चर या विधि घोषणाओं को प्रस्तुत करते हैं, घोषणाओं को पेश करने के लिए टाइप नामों का उपयोग करने की सी-परंपरा की तरह काउंटर करते हैं। एक अन्य विकल्प आपके लिए $variables, जैसे पर्ल और पीएचपी में सिगिल का उपयोग करना है ।

इस उत्तर के कुछ भाग गाइ स्टील के भाषण "ग्रोइंग ए लैंग्वेज" (1998) ( पीडीएफ ) ( यूट्यूब ) से प्रभावित हैं ।

Comments

आपके कुछ बिंदु प्रोग्रामर के बारे में बात करते हैं, जो भाषा का विस्तार करने में सक्षम हैं और उनमें से कुछ भाषा के डिजाइनरों के बारे में बात करते हैं जो इसे विस्तारित करने में सक्षम हैं। दो ज्यादातर असंबंधित नहीं हैं? और मुझे लगता है कि सवाल बाद के प्रकार के बारे में बात कर रहा है ।

— svick

@svick विचार यह है कि एक भाषा अंत उपयोगकर्ताओं द्वारा इतनी व्यापक है कि भाषा को स्वयं बदले बिना बहुत विस्तार और प्रयोग किया जा सकता है। मेटाबोजेक्ट प्रोटोकॉल, ऑपरेटर ओवरलोडिंग और मैक्रो सिस्टम बाद के परिवर्तनों के लिए दरवाजा खुला छोड़ने का एक तरीका है। इन दरवाजों के माध्यम से जो कुछ भी लागू किया जाता है, वह मूल रूप से भाषा को नहीं तोड़ता है। दुर्भाग्य से, इन दरवाजों को बाद में खुद को फिर से डिजाइन करना पड़ सकता है। यही कारण है कि साइमन के जवाब का आधार इसमें किक करता है: इससे पहले कि आप स्थिरता का वादा करें, यह पता लगाने के लिए कि क्या आपकी भाषा वास्तव में काम करती है, बीटा परीक्षण का एक सा करें।

— आमोन

Answer 3

मुझे लगता है कि एक बहुत ही महत्वपूर्ण कदम एक पैकेज प्रबंधक को बढ़ावा देना है जो व्हिस्की भाषा के संस्करण को भी प्रबंधित कर सकता है।

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

बेशक, भाषा के आधार पर, यह आपको संबंधित पुस्तकालयों के लिए आवश्यक संस्करण के लिए प्रतीक्षा करने की आवश्यकता के साथ छोड़ सकता है (उदाहरण के लिए, स्केला में ऐसा होता है), लेकिन फिर भी चीजें आसान हो जाती हैं।

Comments

कोरोलरी के साथ कि जितना संभव हो उतना भाषा को आयात योग्य पैकेज / मॉड्यूल में परिभाषित किया जाना चाहिए

— jk।

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

— एंड्रिया