पुरानी प्रोग्रामिंग भाषाओं को संशोधित क्यों किया जाता है?


46

यह सवाल नहीं है, "लोग अभी भी पुरानी प्रोग्रामिंग भाषाओं का उपयोग क्यों करते हैं?" मैं यह अच्छी तरह से समझता हूं। वास्तव में मैं जिन दो प्रोग्रामिंग भाषाओं को जानता हूं, वे सी और स्कीम हैं, दोनों 70 के दशक की हैं।

हाल ही में मैं C99 और C11 बनाम C89 में बदलावों के बारे में पढ़ रहा था (जो कि अभी भी अभ्यास में C का सबसे अधिक उपयोग किया जाने वाला संस्करण है और जो संस्करण मैंने K & R से सीखा है)। चारों ओर देखते हुए, ऐसा लगता है कि भारी उपयोग में हर प्रोग्रामिंग भाषा को कम से कम एक बार प्रति दशक या इसके बाद एक नया विनिर्देश मिलता है। यहां तक ​​कि फोरट्रान को अभी भी नए संशोधन मिल रहे हैं, इस तथ्य के बावजूद कि इसका उपयोग करने वाले अधिकांश लोग अभी भी फोरट्रान 77 का उपयोग कर रहे हैं।

इसके विपरीत कहें, टाइपिंग सिस्टम TeX। 1989 में, TeX 3.0 की रिलीज़ के साथ, डोनाल्ड नुथ ने घोषणा की कि TeX फीचर-पूर्ण था और भविष्य के रिलीज़ में केवल बग फिक्स शामिल होंगे। इससे भी आगे, उन्होंने कहा है कि उनकी मृत्यु पर, "सभी शेष कीड़े विशेषताएं बन जाएंगे" और बिल्कुल आगे कोई अपडेट नहीं किया जाएगा। अन्य टीईएक्स को कांटा करने के लिए स्वतंत्र हैं और उन्होंने ऐसा किया है, लेकिन परिणामी प्रणालियों का नाम बदलकर यह संकेत दिया जाता है कि वे आधिकारिक टीएक्स से अलग हैं। ऐसा नहीं है क्योंकि नथ सोचता है कि TeX एकदम सही है, लेकिन क्योंकि वह एक स्थिर, अनुमानित प्रणाली के मूल्य को समझता है जो पचास वर्षों में वही काम करेगा जो अब करता है।

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

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

यह एक वास्तविक सवाल है, बहस करने का निमंत्रण नहीं। जाहिर तौर पर मेरी इस पर एक राय है, लेकिन फिलहाल मैं सिर्फ यह समझने की कोशिश कर रहा हूं कि यह सिर्फ इसलिए नहीं है कि चीजें पहले से ही कैसे की जाती हैं। मुझे लगता है कि सवाल है:

भाषा मानक को अपडेट करने के वास्तविक (वास्तविक या कथित) फायदे क्या हैं, क्योंकि पुरानी के आधार पर एक नई भाषा बनाने का विरोध किया गया है?


2
कई कंपाइलरों को स्विच के साथ लागू किया जा सकता है जो पुराने मानकों (जैसे, जीसीसी के --std=xस्विच) को लागू करेगा , इसलिए ऐसा नहीं है जैसे कि पुराने मानकों को अस्थिर करने वाले टूल में नए मानक परिणाम बनाते हैं।
ब्लरफ्ल

2
आप "पुरानी पर आधारित एक नई भाषा" को कैसे परिभाषित करते हैं? मैं बहस करूँगा कि फोरट्रान 90 पुरानी F77 पर आधारित एक "नई भाषा" है। यह पूरी तरह से बदल गया है कि आप कैसे प्रोग्राम करते हैं - निश्चित बनाम मुक्त स्रोत, गतिशील बनाम स्थिर मेमोरी, आदि। आप यह भी तर्क दे सकते हैं कि फोरट्रान 2003 F90 पर आधारित एक "नई भाषा" है - इसमें F90 के साथ संगतता बनाए रखते हुए ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग को जोड़ा गया। C ++ और C. के बीच संबंध की तरह लगता है
tpg2114

1
मुझे लगता है कि यह सवाल बहुत महत्वपूर्ण है और मुझे समझ नहीं आता कि कुछ इसे बंद क्यों करना चाहते हैं। यह एक बहुत ही रोचक घटना है जिसकी संभवतः कुछ व्याख्या है। कुछ (20?) साल पहले मैं फोरट्रान की नई विशेषताओं के बारे में पढ़ रहा था और खुद से पूछा: यदि फोरट्रान प्रोग्रामर को इन सुविधाओं की आवश्यकता है, तो वे बस सी पर स्विच क्यों नहीं करते हैं? हाल ही में मैंने C ++ के बारे में समान विचार किया था: यदि C ++ डेवलपर्स लैम्बडास का उपयोग करना चाहते हैं, तो OCaml ( linux-nantes.org/~fmonnier/ocaml/ocaml-wing-c.php ) पर स्विच क्यों नहीं करना चाहते हैं? वे एक नई भाषा बनाना क्यों पसंद करते हैं और फिर भी इसे C ++ कहते हैं?
जियोर्जियो

3
@ tpg2114 (फोरट्रान 77: फोरट्रान 90) और (सी: सी ++) के बीच का अंतर यह है कि फोरट्रान 90 को फोरट्रान 77 माना जाता है, जहां लोगों को बताया जाता है, "यदि आप फोरट्रान सीखना चाहते हैं, तो फोरट्रान 2003 सीखें या कम से कम 90, क्योंकि यह अब मानक है। ” कोई भी ऐसा कुछ नहीं कहेगा, "यदि आप C सीखना चाहते हैं, तो C ++ सीखें, क्योंकि यह नया मानक है," क्योंकि उन्हें विभिन्न भाषाओं के रूप में प्रस्तुत किया जाता है। जैसा कि मैंने कहा, अनुमानों के परिणाम होते हैं।

6
BECAUSE C कभी नहीं मरता है
Adel

जवाबों:


13

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

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

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

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

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

एक पक्ष की टिप्पणी के रूप में, मुझे लगता है कि विरासत कोड के साथ संगतता बनाए रखते हुए विकास को अनुमति देने का तर्क कमजोर है: जावा सी कोड को कॉल कर सकता है, स्काला आसानी से जावा कोड के साथ एकीकृत कर सकता है, सी # सी ++ के साथ एकीकृत कर सकता है। ऐसे कई उदाहरण हैं जो बताते हैं कि आप आसानी से स्रोत कोड संगतता की आवश्यकता के बिना किसी अन्य भाषा में लिखी गई विरासत कोड के साथ इंटरफ़ेस कर सकते हैं।

ध्यान दें

कुछ उत्तरों और टिप्पणियों से मुझे लगता है कि कुछ पाठकों ने इस प्रश्न की व्याख्या की है कि "प्रोग्रामिंग भाषाओं को विकसित करने की आवश्यकता क्यों है।"

मुझे लगता है कि यह सवाल का मुख्य बिंदु नहीं है, क्योंकि यह स्पष्ट है कि प्रोग्रामिंग भाषाओं को विकसित करने की आवश्यकता है और क्यों (नई आवश्यकताओं, नए विचारों)। सवाल यह है कि "यह विकास कई नई भाषाओं को जन्म देने के बजाय एक प्रोग्रामिंग भाषा के अंदर क्यों होता है?"


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

@SunAvatar: जहां तक ​​मुझे पता है कि लिस्प की कई बोलियां हैं, लेकिन कुछ अन्य (कॉमन लिस्प, स्कीम, रैकेट, क्लोजर) की तुलना में अधिक सफल हैं। किसी भी समय आप एक नई भाषा शुरू करते हैं जो आप जोखिम लेते हैं कि केवल एक बहुत छोटा समुदाय इसके चारों ओर इकट्ठा होगा। लिस्प समुदाय में यह आम बात है: यदि किसी के पास एक नया विचार है, तो वे शाखा करते हैं और देखते हैं कि क्या होता है। अन्य भाषाओं के रचनाकारों के लिए, समुदाय को खोना कोई विकल्प नहीं है।
जियोर्जियो

@ सूना अवतार: मुझे मौजूदा पुस्तकालयों को एक मजबूत तर्क के रूप में विरासत में नहीं मिला है। आपको उसके लिए स्रोत कोड संगतता की आवश्यकता नहीं है। उदाहरण के लिए देखें कि Clojure और Scala जावा कोड का उपयोग कैसे कर सकते हैं।
जियोर्जियो

1
भाषाएं मरती नहीं हैं, केवल प्रोग्रामर जो उनका उपयोग करते हैं।
इवान प्लाइस

@SunAvatar: ऐसे समुदाय भी हैं जो एक अलग नीति का पालन करने की कोशिश करते हैं: एक नाम एक भाषा की पहचान करता है, और यदि समुदाय का एक हिस्सा एक बोली बनाता है जो बहुत अधिक विचलन करता है, तो वे भ्रम से बचने के लिए एक नए नाम का उपयोग करते हैं। उदाहरण के लिए देखें racket-lang.org/new-name.html
जियोर्जियो

21

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

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

जहां तक ​​नुथ जाता है, याद रखें कि वह एक अकादमिक है और टीईएक्स केवल सही साबित होता है, अद्यतन नहीं।


14
टेक्स = स्वरूप वैज्ञानिक कागज पाठ का समस्या डोमेन, बहुत अधिक नहीं बदला है। प्रोग्रामिंग भाषाओं का डोमेन = नए कंप्यूटरों के लिए नए उपयोग खोजें, बल्कि अधिक विस्तृत है। यही कारण है कि लैटिन अंग्रेजी में बहुत से नए शब्दों को नहीं जोड़ता है
मार्टिन बेकेट

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

@ मर्टिन बेकेट: "टेक्स का प्रारूप डोमेन = साइंटिफिक पेपर टेक्स्ट, ज्यादा नहीं बदला है।": मुझे लगता है कि आप प्रश्न के बिंदु को याद कर रहे हैं। ओपी यह नहीं पूछ रहा है कि क्या प्रोग्रामिंग भाषाओं में नवाचार होना चाहिए (कोई भी व्यक्ति इस बात से इनकार नहीं कर सकता है कि नवाचार आवश्यक है) लेकिन नई भाषाओं को बनाने के बजाय पुरानी भाषाओं को संशोधित क्यों किया जाता है।
जियोर्जियो

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

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

5

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


इसलिए यदि "पर्याप्त लोग पुरानी भाषाओं की परवाह करते हैं" यही कारण है, तो क्या आप कहेंगे कि आपका जवाब "मौजूदा भाषाओं के लिए भावुक लगाव" के रूप में प्रतिपादित किया जा सकता है? मैं यह नहीं कह रहा हूं कि केवल अपने जवाब को समझने की कोशिश कर रहा हूं।
अवनर शहर-काश्तन

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

1

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

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

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


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

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

"लैम्बदास के रूप में, मैं C ++ में उनकी उपयोगिता पर टिप्पणी नहीं कर सकता, लेकिन एल्गोरिदम को व्यक्त करने के तरीके को बदलने के लिए नहीं होने पर उन्हें जोड़ने से क्यों परेशान होता है?" शुरू से ही उनके पास है?
जियोर्जियो

2
@ जियोर्जियो भाषा में कैश और अमूर्त सुविधाओं का नियंत्रण है। यदि कोई मौजूदा भाषा दोनों प्रदान नहीं करती है, तो आप एक को त्याग किए बिना भाषाओं को स्विच नहीं कर सकते। आपको एक भाषा को संशोधित करना होगा या एक नया बनाना होगा।
mike30

@ माइक: आपको "कैश फीचर्स" से क्या मतलब है?
जियोर्जियो

-2

यह थोड़ी बोली जाने वाली भाषा की तरह है।

अतीत में जहाँ वे शब्द अब जितनी बार उपयोग नहीं किए जाते थे (या एक अलग अर्थ के लिए उपयोग किए जाते हैं)।

जैसे। अच्छा: (बहुत पुराना) अंग्रेजी में लगभग उलटा अर्थ है जो हम आज का उपयोग करते हैं, विशेष रूप से जब किसी के चरित्र का वर्णन करने के लिए उपयोग किया जाता है।

खराब: बहुत समय पहले खराब का केवल एक ही अर्थ था, अब इसका मतलब कुछ ऐसा हो सकता है जो "सुपर अद्भुत" हो (इसका उपयोग फ़ेसिक तरीके से किया जाता है (मुझे शायद वर्तनी याद आती है)!

एक और नया विकास लिखित भाषाओं के लिए मोबाइल फोन 'टेक्स्ट स्पीक' है।

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

मैं ऐसे लोगों को जानता हूं जो कई अलग-अलग भाषाएं बोलते हैं, और वे अक्सर सुझाव देते हैं कि 3 या 4 के बाद एक नया सीखना आसान हो जाता है।

मुझे नहीं पता कि क्या ऐसे प्रोग्रामर हैं जिनके पास एक समान अनुभव है, तो मुझे आश्चर्य नहीं होगा अगर वहाँ थे।

मुझे पता है कि मुझे JAVA में खुशी की प्रोग्रामिंग महसूस हो रही है (जितना मुझे अंग्रेजी में बोलने में खुशी महसूस हो रही है) इसका मतलब यह नहीं है कि मैं 'अमेरिकन इंग्लिश' या 'ऑस्ट्रलियन इंग्लिश' में संवाद नहीं कर सकता, हालांकि इसके लिए बाहर देखने के लिए कुछ 'गेटचेज' हैं। । बहुत कुछ जावा से PHP में पर्ल तक जाने के समान है, निर्माण समान हैं, लेकिन मुझे बाहर पकड़ने और दीवार के खिलाफ मेरे सिर को काटने के लिए बहुत कम गौचे हैं।

यह अंग्रेजी से फ्रेंच, या जावा से एसएएस में स्थानांतरित होने के लिए अलग है। ये इतने अलग हैं कि उन पर प्रवीण बनने में काफी समय लगता है।

वैसे भी इस पर मेरा कब्जा है।


मुझे लगता है कि आप "मुखर" सोच रहे हैं।
uliwitness
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.