मैं इसे एक उत्तर के रूप में पोस्ट नहीं करने वाला था, लेकिन एक्सोनक्रॉस ने मुझसे पूछा, इसलिए यहां हम जाते हैं:
(सिडेनोट: यदि कोई कम कोड उदाहरण में मार्कडाउन समस्या को ठीक कर सकता है, तो मैं इसकी सराहना करूंगा।)
एरिक मैक्स फ्रांसिस ने लिखा है:
"ब्रैंडन जे। वान हर" ने लिखा है:
रूबी के बारे में पायथन से बेहतर क्या है? मुझे यकीन है कि कुछ है। यह क्या है? क्या पाइथन लोगों के बजाय रूबी लोगों से यह पूछना ज्यादा अच्छा नहीं होगा?
किसी के उद्देश्यों पर निर्भर हो सकता है या नहीं भी हो सकता है - उदाहरण के लिए, यदि किसी के उद्देश्यों में पायथन समुदाय का "समाजशास्त्रीय अध्ययन" शामिल है, तो उस समुदाय के प्रश्नों को डालने से इसके बारे में सूचना देने वाले के बारे में अधिक खुलासा साबित होने की संभावना है, कहीं और डालने से। :-)। व्यक्तिगत रूप से, मैंने पिछले OSCON में डेव थॉमस के एक दिवसीय रूबी ट्यूटोरियल का अनुसरण करने का अवसर लिया। सिंटैक्स मतभेदों के एक पतले लिबास के नीचे, मुझे रूबी और पायथन आश्चर्यजनक रूप से समान लगते हैं - अगर मैं भाषाओं के किसी भी सेट के बीच न्यूनतम फैले हुए पेड़ की गणना कर रहा था, तो मुझे पूरा यकीन है कि पायथन और रूबी पहले दो पत्तों को समेट लेंगे एक मध्यवर्ती नोड :-)
निश्चित रूप से, मैं रूबी में, प्रत्येक ब्लॉक के अंत में मूर्खतापूर्ण "अंत" टाइप करने के बजाय थका हुआ हो जाता हूं (बल्कि सिर्फ अनुत्तरदायी) - लेकिन फिर मुझे समान रूप से मूर्खतापूर्ण टाइपिंग से बचने के लिए मिलता है :
जो पायथन के
शुरू में आवश्यक है प्रत्येक ब्लॉक, तो यह लगभग एक धोने :-) है। अन्य वाक्यविन्यास अंतर जैसे @fooबनाम
self.foo, या रूबी बनाम पायथन में मामले का उच्च महत्व, वास्तव में मेरे लिए अप्रासंगिक हैं।
दूसरों को कोई संदेह नहीं है कि बस ऐसे मुद्दों पर प्रोग्रामिंग भाषाओं की उनकी पसंद है, और वे सबसे गर्म बहस पैदा करते हैं - लेकिन मेरे लिए यह केवल पार्किंसंस कानूनों में से एक का एक उदाहरण है (कार्रवाई पर बहस की राशि मुद्दे के विपरीत आनुपातिक है वास्तविक महत्व)। एक वाक्यविन्यास अंतर जो मुझे महत्वपूर्ण लगता है, और पायथन के पक्ष में - लेकिन अन्य लोगों को कोई संदेह नहीं होगा कि बस उल्टा लगता है - "आप एक फ़ंक्शन को कैसे कहते हैं जो कोई पैरामीटर नहीं लेता है"। पायथन में (सी की तरह), एक फ़ंक्शन को कॉल करने के लिए आप हमेशा "कॉल ऑपरेटर" को लागू करते हैं - आप जिस वस्तु को कॉल कर रहे हैं उसके ठीक बाद कोष्ठक को पीछे छोड़ते हुए (उन अनुगामी कोष्ठक के अंदर आप जिस कॉल में पास हो रहे हैं, उस पर जाएं - यदि आप कोई आर्ग नहीं कर रहे हैं, तब कोष्ठक खाली हैं)। यह किसी भी वस्तु के मात्र उल्लेख को छोड़ देता है, जिसमें कोई भी संचालक शामिल नहीं है, जिसका अर्थ केवल वस्तु का संदर्भ है - किसी भी संदर्भ में, विशेष मामलों, अपवादों, तदर्थ नियमों और इस तरह के बिना। रूबी में (पास्कल की तरह), एक फ़ंक्शन को तर्कों के साथ कॉल करने के लिए, आप आर्ग्स पास करते हैं (आमतौर पर कोष्ठक में, हालांकि यह हमेशा मामला नहीं है) - लेकिन अगर फ़ंक्शन कोई आर्ग नहीं लेता है, तो फ़ंक्शन का उल्लेख करने के लिए इसे सीधे कॉल करें। यह कई लोगों की अपेक्षाओं को पूरा कर सकता है (कम से कम, कोई संदेह नहीं है, जिनकी प्रोग्रामिंग का एकमात्र पिछला अनुभव पास्कल के साथ था, या अन्य "समान कॉलिंग" जैसे विजुअल बेसिक के साथ अन्य भाषाओं में) - लेकिन मेरे लिए, इसका मतलब है किसी वस्तु का मात्र उल्लेख EITHER का अर्थ वस्तु के संदर्भ में हो सकता है, या वस्तु के लिए एक कॉल, ऑब्जेक्ट के प्रकार पर निर्भर करता है - और उन मामलों में जहां मुझे केवल इसका उल्लेख करके ऑब्जेक्ट का संदर्भ नहीं मिल सकता है, मुझे स्पष्ट रूप से उपयोग करने की आवश्यकता होगी "मुझे इसका संदर्भ दें, इसे कॉल न करें!" ऑपरेटरों कि अन्यथा की जरूरत नहीं है। मुझे लगता है कि यह कार्यों (या विधियों, या अन्य कॉल करने योग्य वस्तुओं) की "प्रथम-श्रेणीता" और सुचारू रूप से इंटरचेंज वस्तुओं की संभावना को प्रभावित करता है। इसलिए, मेरे लिए, यह विशिष्ट वाक्यविन्यास अंतर रूबी के खिलाफ एक गंभीर काला निशान है - लेकिन मुझे समझ में नहीं आता कि अन्य लोग क्यों अन्यथा बात करेंगे, भले ही मैं शायद ही उनके साथ और अधिक असहमत हो सकता हूं :-)। सिंटैक्स के नीचे, हमें प्रारंभिक शब्दार्थ में कुछ महत्वपूर्ण अंतर मिलते हैं - उदाहरण के लिए, रूबी में तार परस्पर वस्तुएं हैं (जैसे C ++ में) पायथन में रहते हुए वे परस्पर नहीं हैं (जैसे जावा में, या मेरा मानना है कि C #)। फिर से, जो लोग मुख्य रूप से वे पहले से ही परिचित हैं, वे सोच सकते हैं कि यह रूबी के लिए एक प्लस है (जब तक कि वे जावा या सी # से परिचित नहीं हैं, निश्चित रूप से :-)। मुझे, मुझे लगता है कि अपरिवर्तनीय तार एक उत्कृष्ट विचार है (और मुझे आश्चर्य नहीं है कि जावा, स्वतंत्र रूप से मुझे लगता है, उस विचार को पुन: स्थापित किया जो पहले से ही पायथन में था), हालांकि मुझे "उत्परिवर्ती स्ट्रिंग बफर" प्रकार के रूप में भी बुरा नहीं लगेगा (और आदर्श रूप से जावा के अपने "स्ट्रिंग बफ़र्स" की तुलना में बेहतर आसानी से उपयोग के साथ एक); और मैं यह निर्णय परिचितता के कारण नहीं देता - जावा का अध्ययन करने से पहले, कार्यात्मक प्रोग्रामिंग भाषाओं के अलावा जहां जो लोग मुख्य रूप से पहले से ही परिचित हैं, वे सोच सकते हैं कि यह रूबी के लिए एक प्लस है (जब तक कि वे जावा या सी # से परिचित नहीं हैं, निश्चित रूप से :-)। मुझे, मुझे लगता है कि अपरिवर्तनीय तार एक उत्कृष्ट विचार है (और मुझे आश्चर्य नहीं है कि जावा, स्वतंत्र रूप से मुझे लगता है, उस विचार को पुन: स्थापित किया जो पहले से ही पायथन में था), हालांकि मुझे "उत्परिवर्ती स्ट्रिंग बफर" प्रकार के रूप में भी बुरा नहीं लगेगा (और आदर्श रूप से जावा के अपने "स्ट्रिंग बफ़र्स" की तुलना में बेहतर आसानी से उपयोग के साथ एक); और मैं यह निर्णय परिचितता के कारण नहीं देता - जावा का अध्ययन करने से पहले, कार्यात्मक प्रोग्रामिंग भाषाओं के अलावा जहां जो लोग मुख्य रूप से पहले से ही परिचित हैं, वे सोच सकते हैं कि यह रूबी के लिए एक प्लस है (जब तक कि वे जावा या सी # से परिचित नहीं हैं, निश्चित रूप से :-)। मुझे, मुझे लगता है कि अपरिवर्तनीय तार एक उत्कृष्ट विचार है (और मुझे आश्चर्य नहीं है कि जावा, स्वतंत्र रूप से मुझे लगता है, उस विचार को पुन: स्थापित किया जो पहले से ही पायथन में था), हालांकि मुझे "उत्परिवर्ती स्ट्रिंग बफर" प्रकार के रूप में भी बुरा नहीं लगेगा (और आदर्श रूप से जावा के अपने "स्ट्रिंग बफ़र्स" की तुलना में बेहतर आसानी से उपयोग के साथ एक); और मैं यह निर्णय परिचितता के कारण नहीं देता - जावा का अध्ययन करने से पहले, कार्यात्मक प्रोग्रामिंग भाषाओं के अलावा जहां मुझे लगता है कि अपरिवर्तनीय तार एक उत्कृष्ट विचार है (और मुझे आश्चर्य नहीं है कि जावा, स्वतंत्र रूप से मुझे लगता है, उस विचार को फिर से बहाल कर दिया है जो पहले से ही पायथन में था), हालांकि मुझे "म्यूटेबल स्ट्रिंग बफर" प्रकार के रूप में भी बुरा नहीं लगेगा (और आदर्श रूप से जावा के अपने "स्ट्रिंग बफ़र्स" की तुलना में बेहतर आसानी से उपयोग के साथ एक); और मैं यह निर्णय परिचितता के कारण नहीं देता - जावा का अध्ययन करने से पहले, कार्यात्मक प्रोग्रामिंग भाषाओं के अलावा जहां मुझे लगता है कि अपरिवर्तनीय तार एक उत्कृष्ट विचार है (और मुझे आश्चर्य नहीं है कि जावा, स्वतंत्र रूप से मुझे लगता है, उस विचार को फिर से बहाल कर दिया है जो पहले से ही पायथन में था), हालांकि मुझे "म्यूटेबल स्ट्रिंग बफर" प्रकार के रूप में भी बुरा नहीं लगेगा (और आदर्श रूप से जावा के अपने "स्ट्रिंग बफ़र्स" की तुलना में बेहतर आसानी से उपयोग के साथ एक); और मैं यह निर्णय परिचितता के कारण नहीं देता - जावा का अध्ययन करने से पहले, कार्यात्मक प्रोग्रामिंग भाषाओं के अलावा जहांसभी डेटा अपरिवर्तनीय हैं, मुझे पता था कि सभी भाषाओं में परिवर्तनशील तार थे - फिर भी जब मैंने पहली बार जावा में अपरिवर्तनीय-स्ट्रिंग विचार देखा था (जिसे मैंने पायथन सीखने से पहले अच्छी तरह से सीखा था), इसने मुझे तुरंत उत्कृष्ट के रूप में मारा, एक बहुत अच्छा फिट एक उच्च स्तरीय प्रोग्रामिंग भाषा के संदर्भ-शब्दार्थ के रूप में (मूल्य-शब्दार्थ के विपरीत जो मशीन के करीब की भाषाओं के साथ सबसे अच्छी तरह से फिट होते हैं और अनुप्रयोगों से दूर होते हैं, जैसे सी) एक प्रथम श्रेणी के रूप में स्ट्रिंग्स के साथ, बिल्ट-इन (और सुंदर) महत्वपूर्ण) डेटा प्रकार।
प्राथमिक शब्दार्थ में रूबी के कुछ फायदे हैं - उदाहरण के लिए, पायथन की "सूचियों बनाम ट्यूपल्स" को हटाने से अत्यधिक सूक्ष्म अंतर होता है। लेकिन ज्यादातर स्कोर (जैसा कि मैं इसे रखता हूं, सादगी के साथ एक बड़ा प्लस और सूक्ष्म, चतुर भेद एक उल्लेखनीय ऋण) रूबी के खिलाफ है (जैसे, दोनों बंद और आधे-खुले अंतराल के साथ, अंकन के साथ a.b और a .. .b [कोई भी दावा करना चाहता है कि यह स्पष्ट है कि कौन सा है? -)], मूर्खतापूर्ण है - IMHO, बिल्कुल।)। फिर से, जो लोग भाषा के मूल में समान लेकिन समान रूप से अलग-अलग चीजों पर विचार करते हैं, एक MINUS के बजाय एक PLUS, निश्चित रूप से इन "आसपास के अन्य तरीके" से गिनेंगे कि मैं उन्हें कैसे गिनता हूं :-)।
इन तुलनाओं से गुमराह न हों, यह सोचकर कि दो भाषाएँ
बहुत हैंअलग, तुम मन। वे नहीं कर रहे हैं लेकिन अगर मुझे "कैपेली डींगेलो" की तुलना "स्पेगेटिनी" से करने के लिए कहा जाता है, तो यह इंगित करने के बाद कि ये दो प्रकार के पास्ता किसी के लिए बस अविवेच्य हैं और किसी भी डिश में विनिमेय है जिसे आप तैयार करना चाहते हैं, मैं तब अनिवार्य रूप से होगा इस बात की सूक्ष्म जांच करने के लिए कि कैसे लंबाई और व्यास अलग-अलग होते हैं, कैसे किस्में के सिरों को एक मामले में टेप किया जाता है और दूसरे में नहीं, और इसी तरह - कोशिश करने और समझाने के लिए कि मैं क्यों, व्यक्तिगत रूप से, बल्कि कैपिटल डी होगा 'किसी भी तरह के शोरबा में पास्ता के रूप में एंजेलो, लेकिन इस तरह के लंबे पतले पास्ता रूपों (जैतून का तेल, कीमा बनाया हुआ लहसुन, कीमा बनाया हुआ लाल मिर्च, और बारीक जमीन एन्कोवीज) के लिए उपयुक्त सॉस के साथ जाने के लिए पास्ताच्युत के रूप में स्पेगेटीनी पसंद करेंगे। उदाहरण के लिए - लेकिन अगर आपने लहसुन और मिर्च को उबालने के बजाय कटा हुआ है, तो आपको स्पेगेटी के पतले विस्तार के बजाय स्पेगेटी के साउंड बॉडी का चयन करना चाहिए, और अच्छी तरह से achoview को त्यागने और कुछ नए स्प्रिंग बेसिल को जोड़ने की सलाह दी जाएगी [ या यहां तक कि - मैं एक विधर्मी हूँ ...! - हल्की पुदीना ...] पत्तियां - डिश को परोसने से पहले अंतिम समय पर)। ओह, क्षमा करें, यह दर्शाता है कि मैं विदेश यात्रा कर रहा हूं और थोड़ी देर के लिए पास्ता नहीं था, मुझे लगता है। लेकिन सादृश्य अभी भी बहुत अच्छा है! -) और अच्छी तरह से achoview को आगे बढ़ाने और इसके बजाय कुछ ताजा स्प्रिंग तुलसी [या यहाँ तक कि - मैं एक विधर्मी हूँ ... जोड़ने की सलाह दी जाएगी! - हल्की पुदीना ...] पत्तियां - डिश को परोसने से पहले अंतिम समय पर)। ओह, क्षमा करें, यह दर्शाता है कि मैं विदेश यात्रा कर रहा हूं और थोड़ी देर के लिए पास्ता नहीं था, मुझे लगता है। लेकिन सादृश्य अभी भी बहुत अच्छा है! -) और अच्छी तरह से achoview को आगे बढ़ाने और इसके बजाय कुछ ताजा स्प्रिंग तुलसी [या यहाँ तक कि - मैं एक विधर्मी हूँ ... जोड़ने की सलाह दी जाएगी! - हल्की पुदीना ...] पत्तियां - डिश को परोसने से पहले अंतिम समय पर)। ओह, क्षमा करें, यह दर्शाता है कि मैं विदेश यात्रा कर रहा हूं और थोड़ी देर के लिए पास्ता नहीं था, मुझे लगता है। लेकिन सादृश्य अभी भी बहुत अच्छा है! -)
इसलिए, पायथन और रूबी में, हम दो दिग्गजों के पास आते हैं (भाषा की दृष्टि से उचित - पुस्तकालयों को छोड़कर, और अन्य महत्वपूर्ण सहायक उपकरण जैसे उपकरण और वातावरण, प्रत्येक भाषा को कैसे एम्बेड / विस्तारित करें, आदि, आदि) अभी के लिए - वे वैसे भी प्रत्येक भाषा के सभी कार्यान्वयनों पर लागू नहीं होंगे, उदाहरण के लिए, जेथॉन बनाम क्लासिक पायथन, पायथन भाषा के दो कार्यान्वयन हैं!):
रूबी के पुनरावृत्तियों और कोडब्लॉक बनाम पायथन के पुनरावृत्तियों और जनरेटर;
रूबी के कुल, निरंकुश "dynamicity", "फिर से खोलना" किसी भी मौजूदा वर्ग, सभी में निर्मित सहित, और रन-टाइम में अपने व्यवहार को बदलने की क्षमता सहित - बनाम अजगर के विशाल लेकिन घिरे
dynamicity, जो मौजूदा के व्यवहार में परिवर्तन कभी नहीं अंतर्निहित कक्षाएं और उनके उदाहरण।
व्यक्तिगत रूप से, मैं 1 वॉश पर विचार करता हूं (मतभेद इतने गहरे हैं कि मैं आसानी से लोगों को या तो दृष्टिकोण से घृणा कर सकता हूं और दूसरे को श्रद्धांजलि दे सकता हूं, लेकिन मेरे व्यक्तिगत पैमानों पर प्लस और माइनस के बारे में भी); और [2] एक महत्वपूर्ण मुद्दा है - एक जो रूबी को "टिंकरिंग" के लिए अधिक उपयुक्त बनाता है, लेकिन ब्यूट पायथन बड़े उत्पादन अनुप्रयोगों में उपयोग के लिए समान रूप से अधिक उपयुक्त है। यह एक तरह से मज़ेदार है, क्योंकि दोनों भाषाएं अन्य लोगों की तुलना में बहुत अधिक गतिशील हैं, इसलिए अंत में मेरे POV से उनके बीच का महत्वपूर्ण अंतर इस पर टिका होना चाहिए - कि रूबी इस संबंध में "ग्यारह हो जाती है" (संदर्भ यहाँ "स्पाइनल टैप" है, निश्चित रूप से)। रूबी में,मैं कर सकता हूँ ! यानी, मैं गतिशील रूप से अंतर्निहित स्ट्रिंग वर्ग को बदल सकता हूं ताकि
a = "हैलो वर्ल्ड"
b = "हैलो वर्ल्ड"
अगर ए == बी
"बराबर! \ n" प्रिंट करें
अन्य
प्रिंट "अलग! \ n"
समाप्त
"बराबर" प्रिंट होगा। अजगर में, वहाँ कोई रास्ता नहीं मैं ऐसा कर सकता है। मेटाप्रोग्रामिंग के उद्देश्यों के लिए, प्रायोगिक ढांचे को लागू करना, और जैसे, रूबी की यह अद्भुत गतिशील क्षमता बेहद महत्वपूर्ण है
आकर्षक। लेकिन - अगर हम बड़े अनुप्रयोगों के बारे में बात कर रहे हैं, तो कई लोगों द्वारा विकसित किया गया है और इसे और भी अधिक बनाए रखा है, विभिन्न स्रोतों से पुस्तकालयों के सभी प्रकार सहित, और ग्राहक साइटों में उत्पादन में जाने की जरूरत है ... ठीक है, मैं नहीं चाहता ऐसी भाषा जो बहुत ही गतिशील है, बहुत बहुत धन्यवाद। मैं कुछ पुस्तकालय के अनजाने में अनजाने में अन्य असंबंधित लोगों को तोड़ने के बारे में सोचता हूं जो उन तारों पर अलग-अलग भरोसा करते हैं - जो कि कोड के टुकड़ों के बीच गहरे और गहरे छिपे "चैनल" की तरह है, जो अलग-अलग दिखते हैं और अलग-अलग होते हैं, जो मृत्यु में मंत्र करते हैं बड़े पैमाने पर प्रोग्रामिंग। किसी भी मॉड्यूल को किसी भी अन्य "गुप्त रूप से" के व्यवहार को प्रभावित करने देने से,
अगर मुझे इतने बड़े एप्लिकेशन के लिए रूबी का उपयोग करना था, तो मैं कोडिंग-शैली प्रतिबंधों पर भरोसा करने की कोशिश करूंगा, बहुत सारे परीक्षण (जब भी कुछ भी बदल जाए - फिर भी पूरी तरह से असंबंधित होना चाहिए ...), और पसंद है इस भाषा सुविधा के उपयोग पर रोक लगाने के लिए। लेकिन पहली जगह में फ़ीचर न होना और भी बेहतर है, मेरी राय में - जैसे कि पायथन खुद ही एप्लिकेशन प्रोग्रामिंग के लिए एक बेहतर भाषा होगी, अगर एक निश्चित संख्या में बिल्ट-इन "नॉट डाउन" हो सकता है, तो मैं KNEW कि , जैसे,
len("ciao")4 है (बजाय किसी के
मॉड्यूल lenमें नाम के बंधन को बदल दिया है कि क्या इसके बारे में चिंता करने की बजाय __builtins__...)। मुझे उम्मीद है कि अंततः पायथन अपने बिल्ट-इन को "नेल डाउन" करता है।
लेकिन समस्या का मामूली, चूंकि अंतर्निहित बिल को रिबंड करना काफी पदावनत करने के साथ-साथ अजगर में एक दुर्लभ अभ्यास है। रूबी में, यह मुझे प्रमुख बनाता है -
अन्य भाषाओं की बहुत शक्तिशाली मैक्रो सुविधाओं की तरह (जैसे, कहो, डायलन) मेरी अपनी राय में इसी तरह के जोखिम पेश करते हैं (मुझे आशा है कि पायथन को ऐसी शक्तिशाली मैक्रो प्रणाली कभी नहीं मिलती, नहीं मामला "लोगों को अपने स्वयं के डोमेन-विशिष्ट छोटी भाषाओं को भाषा में ही परिभाषित करने देने" - यह IMHO, आवेदन प्रोग्रामिंग के लिए पायथन की अद्भुत उपयोगिता को प्रभावित करता है, जो होने वाले टिंकर के लिए "आकर्षक उपद्रव" पेश करके हर प्रोग्रामर के दिल में लर्क ...)।
एलेक्स