2010-02-14 13 views
5

मैं बहु-मंच प्रोग्रामिंग के बारे में एक पेपर पर काम कर रहा हूं और मैं फायदे/नुकसान पर अनुभाग शामिल करना चाहता हूं। मेरी समझ से; मल्टी-प्लेटफार्म होने के कारण कोई भी एप्लीकेशन मल्टी-प्लेटफॉर्म डेवलपर के लिए एक बड़ी बिक्री बिंदु है क्योंकि यह लगभग किसी भी कंप्यूटर उपयोगकर्ता को अन्य चीज़ों के साथ संभावित खरीदार के रूप में सक्षम बनाता है। मैं बस संभावित नुकसान का पता लगाने की कोशिश कर रहा हूं। यदि कोई?क्या कोई भाषा प्लेटफॉर्म स्वतंत्र होने के लिए कोई नुकसान है?

उत्तर

2

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

इस के पीछे तर्क के बजाय प्रत्येक परिवेश के लिए एक ही आवेदन कई बार कोडिंग के है, तो आप कोडर के लिए कार्यक्रम के लिए तरह की एक अंतरफलक पैदा करते हैं। प्रत्येक मंच को इस इंटरफ़ेस के अपने कार्यान्वयन की आवश्यकता होती है लेकिन एक समान तरीके से कोड चलाने का इरादा है।

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

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

+2

क्या वह वातावरण या भाषाओं के बारे में पूछ रहा है? मैं कहूंगा कि एक प्लेटफार्म स्वतंत्र * भाषा * का सबसे व्यापक उदाहरण सी है, और सी में अबास्ट्रक्शन परतें आम तौर पर बाधा नहीं होती हैं। – Ken

2

वहाँ एक भाषा (शीर्षक में पूछा) मंच स्वतंत्र होने के नुकसान कर रहे हैं?

एक भाषा implementor के रूप में, मैं कहना है कि कई प्लेटफार्मों पर चलने कुछ बनाने एक बहुत अधिक काम है। अधिकांश अतिरिक्त कार्य रन-टाइम सिस्टम में है। कुछ मंच बनाना-स्वतंत्र करना भी कठिन है; आपको एएनएसआई सी

जैसे कुछ व्यापक रूप से उपयोग किए जाने वाले मानक से चिपकना होगा, मुझे यह जोड़ना चाहिए कि आपको बहुत सारे कोड लिखना आवश्यक नहीं है; आपको बस कड़ी मेहनत करनी है। Lua एक राक्षस बड़े कार्यान्वयन के बिना मंच-स्वतंत्र भाषा का एक अच्छा उदाहरण है। GHC इसके विपरीत है: कई प्लेटफ़ॉर्म — पर बहुत अच्छा प्रदर्शन पाने के लिए बहुत सारे कोड, लेकिन अकेले रन-टाइम सिस्टम संस्करण 6 यूनिक्स के आकार के चार गुणा है!

2

"सभी ट्रेडों का जैक, किसी के मालिक" के बारे में कैसे?

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

यह समुदाय प्रयासों पर लागू नहीं होता है जहां संसाधन प्रचुर मात्रा में आपूर्ति करते हैं, जैसे पर्ल।

0

प्राथमिक नुकसान कर रहे हैं:

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

मेजर नुकसान - आप मंच विशिष्ट संवर्द्धन का उपयोग नहीं कर सकते हैं ...

यह एक अधिक दार्शनिक सवाल है - जहां भाषा योग्यता और संकलक क्षमताओं के बीच की सीमा है ...

आप कर सकते हैं डायरेक्टएक्स कोड लिखें .. लेकिन एक ही परिणाम के लिए लिनक्स में होता है ...

0

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

0

आम लिस्प इस मामले में एक अध्ययन अध्ययन की तरह है! :-)

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

अन्य तरीकों में, वे मंच से स्वतंत्र होने की कोशिश की, और यह सिर्फ कम या कोई बढ़त के साथ जटिलता गयी। एक क्लासिक उदाहरण पथनाम उपप्रणाली है; make-pathname समारोह हस्ताक्षर इस तरह दिखता है:

make-pathname &key host device directory name type version defaults case 
1980 के जब यह किया गया था मानकीकृत, यह बहुत अमीर फ़ाइल सिस्टम के लिए देशी समर्थन शामिल करने के लिए उचित लग रहा था हो सकता है, लेकिन मैं एक VAX नहीं देखा है में

वापस (या किसी अन्य एक संस्करण फाइल सिस्टम के साथ प्रणाली) 10 से अधिक वर्षों में। आज, यह जटिलता है कि most people don't care about। (मुझे पता है कि पथनाम और तार्किक पथनाम तकनीकी रूप से अलग-अलग विशेषताएं हैं, लेकिन वे जो भी करने का प्रयास करते हैं, उससे दूर नहीं हैं।)

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

0

सूर्य से पूछें। कंपनी के लिए पूरी जावा चीज कैसे काम करती है? (हाँ, मुझे पता है, 1 और सभी के नमूने)

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

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

संबंधित मुद्दे