हमें "अन्य" प्रोग्रामिंग भाषाओं की आवश्यकता क्यों है: शायद मैं रूपरेखा का प्रबंधन कर सकता हूं?

हैकर समाचार पर चर्चा पढ़ने के बाद, मैंने फिर से प्रोग्रामिंग भाषाओं के बारे में गंभीरता से सोचा। क्या यह मायने रखता है, आप केवल एक या कई जानते हैं? क्या मैं 5 भाषाओं को समान रूप से जान सकता हूं? या कम से कम इतना अच्छा है कि मैं "उन्हें जानता हूं" कहूं।

अंतर क्या है?

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



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

कोड पढ़ना और अभ्यास करना

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



मुझे लगता है कि सभी ने रेल / रूबी में alias_method_chain कहानी के बारे में सुना है। जाहिरा तौर पर, .NET और ViewState / Postback मॉडल के साथ एक ही बात हुई, और डाउनलोड के बीच पृष्ठ की स्थिति बनाए रखना, जब लोगों ने यह सोचना बंद कर दिया कि वेब विकास की दुनिया में लागू करना बेहतर, आसान और तेज़ कैसे है। Django (पायथन) में मॉडल और दृश्य के बारे में भी यही कहा जा सकता है: जब डिफ़ॉल्ट मॉडल और दृश्य संग्रहीत होते हैं, तो वास्तव में, दो फ़ाइलों में: model.py और views.py, और कई डेवलपर्स को पता नहीं होता है, या उन्हें अलग नहीं कर सकते हैं। । और ग्रेट एक्सप्रेशन ट्रीज़ इन सी #, जो (ऐसा लगता है) केवल LINQ / Enterprise लाइब्रेरी टीम द्वारा उपयोग किया गया था।



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

निष्कर्ष?

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



UPD: sylvio ने समझदार बात कही आप बहुत कुछ सीख सकते हैं:

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

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