कुछ भाषा समुदाय (जैसे, रूबी और पायथन) विखंडन को रोकने में सक्षम थे जबकि अन्य (जैसे, लिस्प या एमएल) नहीं थे?

Question

"लिस्प" (या "लिस्प-जैसा") शब्द विभिन्न भाषाओं, जैसे कॉमन लिस्प, स्कीम और आर्क के लिए एक छतरी है। अन्य भाषा समुदायों में समान विखंडन है, जैसे एमएल में।

हालांकि, रूबी और पायथन दोनों ही इस भाग्य से बचने में कामयाब रहे, जहां नवाचार स्वयं भाषा में बदलाव करने के बजाय कार्यान्वयन (जैसे PyPy या YARV) पर हुआ।

क्या रूबी और पायथन समुदायों ने भाषा के विखंडन को रोकने के लिए कुछ विशेष किया?

Comments

आप विखंडन कहते हैं जैसे यह एक बुरी बात है।

— सोनिया

@ सोनिया एक बाजार-साझा दृष्टिकोण से, विखंडन अक्सर एक आपदा है।

— क्रिसॉकॉक

क्या भाषाएं एक-दूसरे के साथ प्रतिस्पर्धा में हैं?

— बैरी ब्राउन

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

— क्रिश हार्पर

@ बैरी ब्राउन: शानदार बिंदु! भाषाओं को एक दूसरे के साथ बाजार की प्रतिस्पर्धा में नहीं होना चाहिए। लेकिन भाषा विक्रेता हैं और यह अक्सर भाषा डिजाइन को प्रभावित करता है (मुझे नहीं लगता कि यह रूबी, पायथन, लिस्प, एमएल का मामला है, हालांकि)।

— जियोर्जियो

Answer 1

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

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

लिस्प भाषाओं का "परिवार" अधिक है। तो एमएल है, जो लिस्प के समान विकासवादी मार्ग का अनुसरण करता है।

Comments

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

— क्रिसकॉक

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

— रॉबर्ट हार्वे

@ हेनरिकहंसन हास्केल एक मानक है, जैसा कि रॉबर्ट का उल्लेख है। इसलिए एचयूजीएस कंपाइलर को जीएचसी के साथ संगत होना चाहिए क्योंकि दोनों खुद को "हास्केल" कहते हैं। समान मानक-आधारित सुरक्षा C और C ++ तक फैली हुई है, यही वजह है कि जीसीसी और विज़ुअल स्टूडियो को संगत होना चाहिए (मालिकाना एक्सटेंशन का कोई उपयोग नहीं करना)। जिज्ञासा होती है कि लिस्प का क्या हुआ, जहां पहले से ही एक मानक (कॉमन लिस्प) है और फिर भी कई अन्य लिस्प्स हैं। ML का एक ही मुद्दा है जहाँ Standard ML और फिर भी अन्य ML हैं।

— क्रिसकॉक 16

"कॉमन लिस्प को लिस्प के डाइवर्जेंट वेरिएंट को मानकीकृत करने के लिए विकसित किया गया था, जो इसे पहले से बताता है" - en.wikipedia.org/wiki/Common_Lisp । दूसरे शब्दों में, मानक विकसित होने से पहले ही विखंडन था।

— रॉबर्ट हार्वे

मैं यह भी कहूंगा कि एमएल और लिस्प भाषाएं नहीं हैं क्योंकि पायथन और रूबी हैं। लिस्प और एमएल अधिक "अवधारणाओं" की तरह हैं, जो कई अलग-अलग भाषाओं द्वारा लागू किए गए हैं।

— बेंजामिन

Answer 2

एक संभावित कारक बस उम्र है। लिस्प और एमएल पायथन और रूबी की तुलना में बहुत पुराने हैं:

• लिस्प: 1958

• एमएल: 1973

• अजगर: 1991

• रूबी: 1995

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

Comments

संभवतः, लेकिन मुझे याद नहीं है कि फोरट्रान के पास यह डिग्री होने की वजह से है। (इसमें फोर्ट्रन डी की तरह सामान था, लेकिन अधिकांश फोर्ट्रान मानकीकरण के माध्यम से चले गए हैं।) मुझे लगता है कि coalescing की उम्र एक कारक हो सकती है।

— क्रिसचॉक

AFAIK, फोरट्रान में बहुत अधिक असंगति और गैर-मानक एक्सटेंशन और विभिन्न कार्यान्वयन थे जब तक कि मानक समितियों ने धीरे-धीरे इसे बाहर निकाला, शायद इसलिए कि यह लिस्प और एमएल की तुलना में अधिक व्यापक था।

— प्रातः

@erjian: FORTRAN की अपनी असंगतताएं थीं, क्योंकि इसके लिए एक गंभीर प्रोत्साहन था: व्यावसायिक उपयोग। LISP, ज्यादातर शिक्षाविदों में उपयोग किया जाता है, कभी भी यह लक्जरी नहीं था। यानी यह नहीं है कि इसका उपयोग कितना व्यापक था, लेकिन इसके उपयोगकर्ता कितने समृद्ध थे।

— '14:

या, वैकल्पिक रूप से, वेरिएंट को FORTRAN नहीं कहा जाता था। बुनियादी, जब यह बाहर आया, तो निश्चित रूप से एक सरलीकृत फोरट्रान की तरह देखा गया।

— डेविड थॉर्नले

@MSalters आम लिस्प वास्तव में एक (काफी सफल IMO) था, जो विभिन्न मैक्लिस्प बोलियों में असंगतताओं को दूर करने का प्रयास करता था, जो व्यावसायिक उपयोग द्वारा अन्य चीजों के बीच निर्धारित होती थी (और DARPA यह भी चाहता था कि सभी शोध प्रयोगशालाएं इसे आसानी से कोड साझा करने में सक्षम हों) । आज स्कीम, क्लोजर और आम लिस्प के अलावा, कोई व्यावहारिक सामान्य प्रयोजन लिस्प नहीं हैं, और ये तीनों अलग-अलग हैं, अलग-अलग संस्कृतियों और इतिहास के साथ बहुत अलग समुदाय हैं, उन्हें जावा और सी ++ की तुलना में अब एक ही भाषा की बोलियों के रूप में नहीं गिना जाता है। ।

— पावेल पेनेव

Answer 3

वे अनिवार्य रूप से सभी कार्यान्वयन परिभाषित भाषाएं हैं

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

दूसरी ओर हमारे पास तदर्थ और कार्यान्वयन-परिभाषित भाषाएं हैं। या ऐसी भाषाएं जो इतनी जटिल हैं कि यह एक व्यवहार्य वैकल्पिक कार्यान्वयन का निर्माण करने के लिए एक महत्वपूर्ण बाधा है:

• माणिक; पर्ल; अजगर - व्यवहार्य विकल्पों का उत्पादन करने के लिए सभी कार्यान्वयन-परिभाषित
• ghc haskell और erlang - अच्छी तरह से परिभाषित है, लेकिन कुछ भी ऐसा करने के लिए कठिन है जो ghc (या erlang) के साथ प्रतिस्पर्धा करता है जो लोग आमतौर पर परेशान नहीं करते हैं

यह नकारात्मक लग रहा है - ऐसी भाषाएं जो व्यवहार्य विकल्पों का उत्पादन करने के लिए बहुत कठिन हैं, बड़े पैमाने पर उल्टा है: दुर्लभ डेवलपर संसाधन एक सच्चे कार्यान्वयन पर केंद्रित हैं।

---

एक ऐतिहासिक नोट के रूप में, हास्केल समुदाय के कई लोगों ने सक्रिय रूप से विलय और देव प्रयास की एकाग्रता का पीछा किया, यह पहचानते हुए कि देव समुदाय का कोई भी झुकाव मतलब है कि हम सफल नहीं होंगे। जीएचसी को चुना और चैंपियन बनाया गया।

Comments

मैं "सक्रिय रूप से खोजे गए विलय और एकाग्रता" के बारे में अधिक जानना पसंद करूंगा।

— सैम टोबिन-होचस्टाट

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

— Vorg van Geir

फिर भी, पाइकॉन / रूबी परिपक्वता स्थिति तक पहुंचने के लिए हास्केल अभी भी अधिक व्यावहारिक हो सकता है। हास्केल cabalउपयोग करने के लिए एक मजेदार उपकरण नहीं है और इसे तोड़ने के लिए आसान है:। यहां तक ​​कि Yesod इसे स्वीकार करता है: Yesodweb.com/blog/2012/04/cabal-meta पायथन और रूबी पैकेज प्रबंधन के संबंध में बहुत बेहतर हैं।

— एहतेश चौधरी

@ शेरेन पायथन और रूबी एकीकरण से पहले अपने पैकेज की जांच नहीं करते ...

— डॉन स्टीवर्ट

-1: "रूबी; पर्ल; पायथन - व्यवहार्य विकल्पों का उत्पादन करने के लिए सभी कार्यान्वयन-परिभाषित" ज्योथॉन, आयरनपीथॉन, जेरीबी, आयरनरीबी, PyPy, स्टैकलेस कार्यान्वयन के लिए गलत साबित होते हैं (और ये सिर्फ प्रमुख हैं)। इसके अलावा, CPython संदर्भ कार्यान्वयन है, लेकिन भाषा की परिभाषा नहीं है, यह है

— vartec

Answer 4

मैं कहूंगा कि एक कारक एक परिभाषित मंच है । हास्केल के लिए मंच हास्केल मानक और जीएचसी (मैं कल्पना करता हूं) है। रूबी के लिए यह रूबी ऑन रेल्स था जिसने रूबी विकास मंच को "परिभाषित" किया। सी के लिए यह यूनिक्स था।

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

यह निश्चित रूप से, मेरी तरफ से पूरी तरह से अटकलें हैं। यह विचार हार्वे के उत्तर पर टिप्पणी से आया था। हालांकि, ऐसा लगता है कि परिभाषित मंच कई आकारों में आता है, लेकिन आम संपत्ति यह है कि यह वही है जो लोकप्रियता हासिल करता है।

Comments

मुझे वास्तव में यह विचार पसंद है। मैं लिस्प के कई रूपों का उपयोग कर सकता हूं क्योंकि उनमें से किसी के पास "हत्यारा ढांचा" नहीं है, लेकिन अगर मैं रेल का उपयोग करना चाहता हूं, तो मुझे विहित रूबी के साथ रहना चाहिए। निश्चित रूप से यह एकमात्र उत्तर नहीं है, लेकिन मुझे आपकी परिकल्पना पसंद है।

— चिरसायकॉक

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

— c69

आम लिस्प जल्दी से एक भी परिभाषा पर नहीं बैठा क्योंकि लोगों के पास कुछ चीजों के बारे में मजबूत राय थी, जैसे कि स्वच्छ मैक्रोज़।

— रॉबर्ट हार्वे

मैं इससे सहमत और असहमत दोनों हूं। मैं सहमत हूं क्योंकि एक 'किलर फ्रेमवर्क' कोर भाषा को मूल्यवान कार्यक्षमता के साथ पैच करता है, विकास को प्रोत्साहित करता है, और मानक कल्पना के बाहर तेजी से नवाचार की अनुमति देता है। मैं असहमत हूं, क्योंकि अगर फ्रेमवर्क मेंटेनर बहुत सावधान नहीं हैं, तो इनोवेशन में तेजी से बढ़ोतरी से बहुत सारे ब्लोट और / या लीक एब्स्ट्रैक्ट हो सकते हैं जो इसे अस्थिर कर सकते हैं।

— इवान प्लाइस

(cont) एक भाषा कोर कार्यक्षमता का विस्तार करने वाले jQuery जैसे फ्रेमवर्क आदर्श रूप में भविष्य में मर जाएंगे क्योंकि उन रूपरेखाओं द्वारा दिए गए सबसे मूल्यवान योगदानों को मानकीकृत और कोर में शामिल किया गया है। IMHO, चौखटे सबसे तेजी से मरते हैं क्योंकि डेवलपर्स आमतौर पर कोडबेस को स्थिर करने के लिए निर्भरता को कम / खत्म करना पसंद करते हैं। यदि भाषा डेवलपर्स प्रासंगिक बने रहना चाहते हैं, तो वे फ्रेमवर्क कार्यक्षमता को अपनाने और अपनाने के द्वारा उस प्रक्रिया को आसान बना देंगे, और अपने उपयोगकर्ताओं को तृतीय पक्ष रूपरेखाओं पर निर्भरता कम करने के लिए प्रोत्साहित करेंगे।

— इवान प्लाइस

Answer 5

भाषा के विकास को चलाने वाली संस्कृति को तौलना न भूलें

मैं इस तथ्य को भी वजन दूंगा कि अजगर / php पर विकास सार्वजनिक रूप से सक्रिय रूप से किया जाता है। आपके पास एक ऐसा व्यक्ति है, जो एक मानक विनिर्देश का पालन कर रहा है, जो किसी को भी / सभी को स्वतंत्र रूप से उपलब्ध है।

W3C HTML / CSS मानक के साथ बहुत कुछ करता है। आपके पास प्रेरित व्यक्तियों का एक छोटा समूह है जो भाषा को पूरा करने के लिए डिज़ाइन किए गए बारीक विवरण को नियंत्रित करते हैं। सार्वजनिक रूप से रिलीज़ होने से पहले सब कुछ स्पष्ट रूप से परिभाषित विनिर्देश में चला जाता है।

OTOH, LISP जैसी भाषाओं को प्रोफेसरों या अन्य व्यक्तियों द्वारा बंद दरवाजों के पीछे कांटा जाता है, जो वास्तव में मानते हैं कि भाषा के 'सर्वश्रेष्ठ उपयोग' पर उनका दृष्टिकोण सही है। वे एक ही समय में एक साथ सही और गलत हो सकते हैं क्योंकि कुछ कार्यों में कुछ कार्यान्वयन महान हैं; जबकि कोई भी हर चीज में सर्वश्रेष्ठ नहीं है।

यह जरूरी नहीं कि एक बुरी चीज है क्योंकि विविधता नवाचार को जन्म देती है। LISP जैसी भाषाएं हैं, और सीखने और अनुसंधान के लिए महान भाषाएं रहेंगी क्योंकि वे समझ की सीमाओं को धक्का देती हैं।

लेकिन नवाचार के लिए पर्यावरण को अच्छा बनाने वाले गुण स्थिरता के लिए आवश्यक रूप से फायदेमंद नहीं हैं; इसके विपरीत, ऐसे गुण जो स्थिरता के लिए वातावरण को अच्छा बनाते हैं, रचनात्मकता के लिए आवश्यक नहीं हैं।

जब विकास सक्रिय सहयोग पर आधारित होता है, तो कभी-कभी व्यक्तियों को अधिक से अधिक लाभ के लिए स्वीकार करने के लिए मजबूर किया जाता है। अनुसंधान के लिए बुरा / संगति के लिए अच्छा है।

---

तथ्य यह है, हम अभी भी प्रोग्रामिंग भाषा के विकास के जंगली-पश्चिम में रह रहे हैं। Language आदर्श भाषा ’को डिजाइन करने की समस्या इतनी बड़ी है कि स्मारकीय प्रयासों के बावजूद कोई भी इसे हल करने के करीब नहीं आया है।

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

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

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

Comments

सीढ़ी? क्या आपका मतलब बाद में है?

— जियोर्जियो

@ जियोर्जियो हाँ, मुझे इससे नफरत है जब मुझे लगता है कि गलत है।

— इवान प्लाइस

Answer 6

मुझे नहीं लगता कि यह कहना सही है कि पायथन और रूबी जैसी भाषाएँ खंडित नहीं हैं। पहले से ही हम कुछ विखंडन प्रभाव देखना शुरू कर रहे हैं। उदाहरण के लिए, पायथन 3 पायथन 2 के साथ पूरी तरह से पीछे की ओर संगत नहीं है, इसलिए दोनों संस्करणों को बनाए रखने की आवश्यकता है और मौजूदा कोड बहुत सारे पायथन के साथ ही काम करते हैं। कुछ पायथन स्पिनऑफ भी हैं, जिनमें PyPy भी शामिल है।

एक अन्य कारक भाषाओं की आयु है। विखंडन के अधीन सबसे पुरानी भाषाएं हैं और इस प्रकार विकास और संशोधन के दबाव के अधीन हैं। लिस्प का आविष्कार कई दशकों पहले किया गया था, इसलिए इसके कुछ विचारों को लेने और उन्हें नई भाषाओं में शामिल करने का पर्याप्त समय है। C एक खंडित भाषा का एक और उदाहरण है। जबकि C की भाषा में केवल एक ही प्रमुख संशोधन था (K & R से ANSI), इसमें C ++, Not Quite C, और C- जैसे सिंटेक्स को साझा करने वाले अन्य सभी सहित कई स्पिनऑफ़ हैं।

रूबी अपने आप में पिछली भाषाओं की "विखंडन" (यदि आप करेंगे) है। चूँकि यह C, स्मॉलटाक और पर्ल (दूसरों के बीच) से विचारों को शामिल करता है, यह वर्तमान में टुकड़ा करने वाली भाषा है । मैं यह नहीं देखता कि हम भविष्य में अन्य भाषाओं के साथ रूबी को आगे क्यों नहीं देख पाएंगे।

Comments

-1 क्योंकि: (1) पायथन 3.x विखंडन नहीं है। यह भाषा के विकास में सिर्फ अगला कदम है; पायथन 2.x कुछ वर्षों में पूरी तरह से गिरा दिया जाएगा । (२) अन्य भाषा कार्यान्वयन जो ९९% संगत हैं (१% कार्यान्वयन विवरण हैं और अधिकतर अस्पष्ट हैं) और सक्रिय रूप से भाषा को परिभाषित करने में भाग लेने से इंकार नहीं हैं। (३) एक बहुत भिन्न भाषा जो कुछ सामान्य जमीन को साझा करती है और कुछ हद तक संगत है (C ++ से C) शायद ही विखंडन हो। (४) मौजूदा भाषाओं से विचारों को स्वीकार करना विखंडन नहीं है, यह एकमात्र तरीका है जिससे कोई भाषा डिज़ाइन करता है।

@ डायलेन: पायथन 2.x पूरी तरह से कुछ वर्षों में गिरा दिया जाएगा? यह एक मूर्खतापूर्ण बात है, जब COBOL और फोरट्रान अभी भी आसपास हैं!

— मेसन व्हीलर

@MasonWheeler मैं विकास की बात कर रहा हूं। वीसीएस में अभी भी पुराने कोड संग्रहीत होंगे, इनऑफिशियल बाइनरी डाउनलोड दशकों तक रह सकते हैं, और कुछ दुकानें पोर्टिंग से बच सकती हैं। लेकिन मुझे उम्मीद है कि कुछ दूर-दूर तक नहीं, पायथन प्रोग्रामिंग का विशाल बहुमत पायथन 3 में होता है। आखिरकार, कुछ समय पहले 2.x सुविधा विकास बंद हो गया (और तब तक फिर से शुरू नहीं होगा जब तक कि आप अजगर-देव का ब्रेनवॉश नहीं करते) , बगफिक्स / सुरक्षा अद्यतन हमेशा के लिए जारी रखने वाले नहीं होते हैं, और पुस्तकालयों के एक महत्वपूर्ण हिस्से को पायथन 3 में रखा जाता है, जिसमें अधिकांश अन्य लोग या तो आगे की ओर देख रहे हैं (जैसे कि Djano) या अस्वाभाविक होना।

@MasonWheeler ओह, और फोरट्रान और कोबोल के रूप में: फोरट्रान को 2008 में एक नया मानक संशोधन ओम मिला, और तब से COBOL को मुट्ठी भर तकनीकी रिपोर्टों के साथ 2002 में एक मिला।

@MasonWheeler क्या आप जानते हैं कि आधुनिक COBOL ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के लिए अनुमति देता है?

Answer 7

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

एक और पहलू यह है कि लिस्प शायद लागू करने के लिए सबसे आसान प्रोग्रामिंग अवधारणा है - यही वजह है कि यह बार-बार किया जाता है।

Answer 8

लिस्प जैसी दिखने वाली भाषाएँ नाटकीय रूप से बदली जाने वाली बुनियादी और सैद्धांतिक हैं। व्याकरणिक परिवर्तन (मेरा मतलब केवल कमांडों के नाम बदलना नहीं है) बस उनके पीछे कार्यात्मक-प्रोग्रामिंग सिद्धांत फिट नहीं होंगे।

लेकिन यह तथ्य कि लिस्प जैसी भाषाएं हैं, यह दिखाती है कि "परिवर्तन" पहले से ही लिस्प के लिए किए गए थे। दूसरे शब्दों में, लोगों द्वारा बनाई गई भाषाएं हैं जो लिस्प से प्रेरित थीं या इसके पीछे सिद्धांत है और एक नई भाषा में एक समान तरीका बनाया है।

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

मुझे लगता है, पायथन जैसी भाषा की मूलभूत बातें वास्तव में कभी नहीं बदलेंगी। पायथन ऑब्जेक्ट-ओरिएंटेड है और इसलिए C ++ और Java में समानता है, लेकिन यह गतिशील है और इसलिए यह बहुत सारी स्क्रिप्ट भाषाओं के समान है।

वैसे कौन वास्तव में भाषाओं की परवाह करता है? जो मायने रखता है वह उद्देश्य है: फ्रेंच लैटिन के समान है लेकिन जो लड़कियां फ्रेंच समझती हैं वे अधिक गर्म हैं;)