संकलित बनाम व्याख्या की गई भाषाएँ

284

मैं अंतर की बेहतर समझ पाने की कोशिश कर रहा हूं। मुझे बहुत सारे स्पष्टीकरण ऑनलाइन मिले हैं, लेकिन वे व्यावहारिक प्रभाव के बजाय अमूर्त मतभेदों की ओर हैं।

मेरे अधिकांश प्रोग्रामिंग अनुभव सीपीथॉन (गतिशील, व्याख्या किए गए) और जावा (स्थिर, संकलित) के साथ हुए हैं। हालांकि, मैं समझता हूं कि अन्य प्रकार की व्याख्या और संकलित भाषाएं हैं। इस तथ्य के अलावा कि निष्पादन योग्य फ़ाइलों को संकलित भाषाओं में लिखे गए कार्यक्रमों से वितरित किया जा सकता है, क्या प्रत्येक प्रकार के कोई फायदे / नुकसान हैं? अक्सर, मैं लोगों को यह तर्क देते हुए सुनता हूं कि व्याख्या की गई भाषाओं का अंतःक्रियात्मक रूप से उपयोग किया जा सकता है, लेकिन मेरा मानना है कि संकलित भाषाओं में संवादात्मक कार्यान्वयन भी हो सकते हैं, सही है?

— chimeracoder
स्रोत

32

आपने इस तुलना के लिए सबसे खराब भाषाओं को चुना। दोनों बायटेकॉम्फेड हैं। उनके बीच एकमात्र वास्तविक अंतर JITer है, और यहां तक कि पायथन में एक आंशिक (मानस) है।

— इग्नासियो वाज़क्वेज़-अब्राम्स

1

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

— मिकेरा

मानक एमएल एक अन्य संकलित भाषा है; अंतर्निहित संकलक वास्तविक देशी मशीन कोड भी जारी करता है।

— डोनाल्ड फेलो

2

publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/…

— pvllnspk

queception.com/question.php?question=16

— स्टैक ओवरफ्लो

459

एक संकलित भाषा वह है जहां कार्यक्रम, एक बार संकलित किया जाता है, लक्ष्य मशीन के निर्देशों में व्यक्त किया जाता है। उदाहरण के लिए, आपके स्रोत कोड में एक अतिरिक्त "+" ऑपरेशन को मशीन कोड में सीधे "ADD" निर्देश में अनुवादित किया जा सकता है।

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

आप एक संकलित भाषा में एक व्याख्या की गई भाषा में कुछ भी कर सकते हैं और इसके विपरीत - वे दोनों ट्यूरिंग पूर्ण हैं। हालांकि कार्यान्वयन और उपयोग के लिए दोनों के फायदे और नुकसान हैं।

मैं पूरी तरह से सामान्य करने जा रहा हूं (शुद्धतावादियों ने मुझे माफ कर दिया!) लेकिन, मोटे तौर पर, संकलित भाषाओं के फायदे हैं:

सीधे लक्ष्य मशीन के मूल कोड का उपयोग करके तेज़ प्रदर्शन
संकलन चरण के दौरान काफी शक्तिशाली अनुकूलन लागू करने का अवसर

और यहाँ व्याख्या की गई भाषाओं के फायदे हैं:

लागू करने में आसान (अच्छा संकलक लिखना बहुत कठिन है !!)
कोई संकलन चरण चलाने की आवश्यकता नहीं है: कोड को सीधे "फ्लाई पर" निष्पादित कर सकते हैं
गतिशील भाषाओं के लिए अधिक सुविधाजनक हो सकता है

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

— mikera
स्रोत

1

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

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

2

@ करीम: जेआईटी कंपाइलर केवल 1) और 2) एक बार करता है - उसके बाद यह सभी तरह से देशी कोड होता है। दुभाषिया को 1) और 2) दोनों करने की आवश्यकता होती है, हर बार कोड कहा जाता है (जो कई बार हो सकता है, कई बार ...)। इसलिए समय के साथ, JIT कंपाइलर लंबे अंतर से जीतता है।

— मिकेरा

3

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

— मिकेरा

2

यह वास्तव में एक गलत द्वैध है। एक भाषा के लिए कुछ भी आंतरिक नहीं है जो इसे हमारी व्याख्या को संकलित करता है। यह व्यापक रूप से आयोजित गलत धारणा से ज्यादा कुछ नहीं है। कई भाषाओं में कार्यान्वयन दोनों हैं और सभी भाषाओं में भी हो सकते हैं।

— एममेनाईनरी

2

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

— मायके

99

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

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

इसलिए आमतौर पर "संकलित" और "व्याख्या" द्वारा भाषाओं को वर्गीकृत करने का कोई मतलब नहीं है।

— lunaryorn
स्रोत

3

मैं सहमत हूँ। या यह कहें: देशी कंपाइलर हैं (खाने के लिए सीपीयू के लिए मशीन कोड बना रहे हैं), और नहीं-तो-देशी-कंपाइलर्स (टोकन सामान बनाना, यानी मध्यवर्ती कोड, कि मशीन कोड से पहले कुछ-इन-टाइम कंपाइलर कंपाइल करता है ( या दौरान) रनटाइम ONCE), और "वास्तविक" गैर-संकलक हैं जो कभी मशीन कोड का उत्पादन नहीं करते हैं और सीपीयू को कभी भी कोड को चलाने नहीं देते हैं। बाद वाले दुभाषिए हैं। आज, कंपाइल-टाइम पर मशीन (सीपीयू) कोड का उत्पादन करने वाले देशी कंपाइलर अधिक से अधिक दुर्लभ हो रहे हैं। डेल्फी / कोडगियर सर्वश्रेष्ठ जीवित लोगों में से एक है।

— TheBlastOne

57

अतीत के बारे में सोचना शुरू करें: विस्फोट

एक बार, लंबे समय से पहले, कंप्यूटिंग दुभाषियों और संकलक की भूमि में रहते थे। सभी प्रकार के उपद्रव एक के ऊपर एक गुण के आधार पर हुए। उस समय की आम राय कुछ इस तरह थी:

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

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

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

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

— NealB
स्रोत

1

अच्छा - पिछले पैराग्राफ में महान सारांश - धन्यवाद!

— ckib16

26

चरम और सरल मामले:

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

उन लोगों के साथ, मुझे समझाने दो कि जीवन इतना सरल नहीं है। उदाहरण के लिए,

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

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

— कार्ल स्मोत्रिक्ज़
स्रोत

23

से http://www.quora.com/What-is-the-difference-between-compiled-and-interpreted-programming-languages

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

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

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

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

— भाविन शाह
स्रोत

क्या आप इस वाक्य को ठीक कर सकते हैं: "ऐसे कंपाइलर हैं जो अन्य भाषाओं का जावास्क्रिप्ट में अनुवाद करते हैं, जो तब अक्सर एक वेब ब्राउज़र में चलाया जाता है, जो जावास्क्रिप्ट की व्याख्या कर सकता है, या इसे एक वर्चुअल मशीन या देशी कोड संकलित कर सकता है।"

— कोरा तुगे

बिल्कुल सही किया। एक और सामान्य गलती किसी भाषा की उपयोगिता को उसके मौजूदा एपीआई के लिए करना है।

— लिटिल एंडियन

10

संकलित स्रोत कोड पर स्रोत कोड की व्याख्या का सबसे बड़ा लाभ पोर्टेबिलिटी है ।

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

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

संकलित कोड का एक फायदा यह है कि यह स्रोत कोड को अंतिम उपयोगकर्ता (जो बौद्धिक संपदा हो सकता है ) से छुपाता है क्योंकि मूल मानव-पठनीय स्रोत कोड को तैनात करने के बजाय, आप एक अस्पष्ट बाइनरी निष्पादन योग्य फ़ाइल को तैनात करते हैं।

— निको बेल्लिक
स्रोत

1

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

— रोजेलियो ट्रिनियो

7

एक कंपाइलर और एक दुभाषिया एक ही काम करते हैं: एक प्रोग्रामिंग भाषा का अनुवाद दूसरी pgoramming भाषा में करना, आमतौर पर हार्डवेयर के करीब, अक्सर निष्पादन योग्य मशीन कोड।

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

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

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

— माइकल बोर्गवर्ड
स्रोत

1

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

4

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

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

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

इसलिए, बड़ी प्रणालियों के लिए जो बहुत कुछ बदलने नहीं जा रहे हैं, और कुछ भाषाओं के लिए, यह सब कुछ precompile और prelink करने के लिए अधिक समझ में आता है, वे सभी अनुकूलन करें जो आप कर सकते हैं। यह एक बहुत दुबले रनटाइम के साथ समाप्त होता है जो पहले से ही लक्ष्य मशीन के लिए अनुकूलित है।

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

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

— उरी
स्रोत

सी वास्तव में एक "मशीन" से बंधा नहीं है। C का वाक्य-विन्यास और शब्दार्थ साधारण नहीं है। सी-दुभाषिया को लागू करने के लिए विशेष रूप से मुश्किल नहीं होना चाहिए, केवल बहुत समय लेने वाली (क्योंकि मानक पुस्तकालय को भी लागू किया जाना है)। और btw, जावा को देशी मशीन कोड (gcj का उपयोग करके) में संकलित किया जा सकता है।

— चंद्रग्रहण

@lunaryorn: मैं GCJ के बारे में असहमत हूं। GCJ केवल आपको एक निष्पादन योग्य वातावरण देता है। "संकलित अनुप्रयोग GCJ रनटाइम, libgcj के साथ जुड़े हुए हैं, जो कोर क्लास लाइब्रेरी, एक कचरा संग्रहकर्ता और एक बाईटेकोड दुभाषिया प्रदान करता है"

— उरी

2

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

— चंद्र

@lunaryorn: आह। ठीक है, मैं स्पष्टीकरण की सराहना करता हूं और सही खड़ा हूं। हम मुख्य रूप से एक विंडोज़ वातावरण में जावा का उपयोग करते हैं, इसलिए मैंने वर्षों में gcj की कोशिश नहीं की है।

— उरी

2

आप C की व्याख्या कर सकते हैं ।

2

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

— स्टीवन मोहर
स्रोत

1

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

— एडेन बेल

2

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

— अहमद शाबान हेलवा
स्रोत

1

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

— salehvm
स्रोत

0

लघु (अन-सटीक) परिभाषा:

संकलित भाषा: संपूर्ण कार्यक्रम को एक बार मशीन कोड में अनुवादित किया जाता है, फिर सीपीयू द्वारा मशीन कोड चलाया जाता है।

व्याख्या की गई भाषा: प्रोग्राम को लाइन-बाय-लाइन पढ़ा जाता है और जैसे ही कोई लाइन पढ़ी जाती है, उस लाइन के मशीन निर्देश सीपीयू द्वारा निष्पादित हो जाते हैं।

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

संकलन और व्याख्या के बीच अंतर क्या है?

या मेरे बाद के ब्लॉग पोस्ट:

https://orangejuiceliberationfront.com/the-difference-between-compiler-and-interpreter/

— uliwitness
स्रोत