सिस्टम प्रोग्रामिंग के लिए सी #

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

पिछले 4 वर्षों से, मेरी टीम सिस्टम प्रोग्रामिंग के लिए डिज़ाइन किए गए C # के लिए एक्सटेंशन का एक सेट डिजाइन और कार्यान्वित कर रही है। अंत में, मैंने इस काम में अपने अनुभव का वर्णन पदों की एक श्रृंखला में करने का निर्णय लिया, और यह पद इस श्रृंखला में पहला है।


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

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

इसलिए, जैसा कि आरेख से देखा जा सकता है, मैं पुष्टि करता हूं कि लोकप्रिय प्रोग्रामिंग भाषाओं के पूरे सेट के बीच, आज दो व्यापक समूह हैं, जो दो चतुर्थांश के साथ आरेख में व्यक्त किए गए हैं।

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

और इसका मतलब यह है कि बहिष्कृत मध्य के कानून से C # जैसी भाषाएं "पीड़ित" हैं। अच्छे के बीच में खोजने से अंत नहीं होगा।

निचले दाहिने हिस्से में वे भाषाएँ हैं जो उत्पादकता की आखिरी बूंदों को खुद से बाहर निकाल देती हैं। ईमानदार होने के लिए: अधिकांश प्रोग्रामर इस क्वाड्रेंट में C # और Java नहीं डालेंगे, और मैं उनसे सहमत हूं। मैंने बहुत से लोगों को देखा, जो अपने मुंह में खट्टा स्वाद के साथ, कचरा संग्रह भाषाओं से वापस C ++ तक भाग रहे थे। (मैं ईमानदार रहूंगा और मेरा कहना है कि कचरा संग्रह केवल आंशिक रूप से दोष देने के लिए है; यह "पलायन" काफी हद तक खराब डिजाइन पैटर्न, रूपरेखा और भाषा को और भी बेहतर बनाने के लिए छूटे अवसरों के कारण है।) जावा पहले सी # की तुलना में "चतुर्थांश" के करीब है। कतार हॉटस्पॉट जैसी आभासी मशीनों के उत्कृष्ट संचालन के कारण है जो कोड पिचिंग और स्टैक आवंटन का उपयोग करते हैं। और फिर भी, अधिकांश कट्टर सिस्टम प्रोग्रामर पूर्व के प्रदर्शन लाभ के कारण C # और Java के बजाय C ++ को चुनते हैं। यद्यपि C ++ 11 उत्पादकता और सुरक्षा के मामले में C # और Java जैसी भाषाओं के थोड़ा करीब है, फिर भी यह C ++ की गारंटी प्रकार की सुरक्षा को जोड़ने के लिए एक स्पष्ट "अनिच्छा" दिखाता है। हां, अब आपके पास असुरक्षा के साथ पहले से ही बहुत कम चौराहे हैं, लेकिन मेरा दृढ़ता से मानना ​​है कि गर्भावस्था की तरह, आप "आधे सुरक्षित" नहीं हो सकते। असुरक्षा की भाषा का मतलब है कि आपको हमेशा सबसे खराब स्थिति पर भरोसा करना चाहिए और सुरक्षा प्रणाली को बहाल करने के लिए टूल का उपयोग करना चाहिए, इसके उल्लंघन के बाद, टाइप सिस्टम की सुरक्षा पर भरोसा करने के बजाय।

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

परिणाम को C # भाषा के एक्सटेंशन के एक सेट में व्यक्त किया जाना चाहिए, जो भाषा को न्यूनतम सीमा तक प्रभावित करता है, और पूरी तरह से नई भाषा में नहीं।

अगला सवाल: "हम C # पर आधारित क्यों हैं?" जिस भाषा में हम विकास करना चाहते हैं, वह प्रकार "सुरक्षा" प्रबलित कंक्रीट "पहलू है, और C #" आधुनिक प्रकार-सुरक्षित C ++ "की शैली में एक बहुत अच्छा कैनवास प्रदान करता है, जिस पर हम अपनी तस्वीर खींचना शुरू करेंगे। जावा की तुलना में C # हम जो चाहते हैं, उसके करीब है, क्योंकि इसमें आधुनिक चीजें हैं जैसे प्रतिनिधियों और लैम्ब्डा के भाव। अब डी, रस्ट और गो जैसे अन्य उम्मीदवार हैं। लेकिन जब हमने अपना काम शुरू किया, तो ये भाषाएं अभी तक दिखाई नहीं दी हैं या उपयोग के लिए पूरी तरह कार्यात्मक नहीं हैं। इसके अलावा, मेरी टीम Microsoft पर काम करती है, जहाँ प्रतिभाशाली C # डेवलपर्स का एक समूह आर्म की लंबाई पर उपलब्ध है। मैं ऊपर सूचीबद्ध विचाराधीन अन्य भाषाओं के विशेषज्ञों के साथ सहयोग करने को तैयार हूं, और यहां तक ​​कि इन भाषाओं के समुदायों के कई प्रमुख लोगों के साथ विचार साझा किए हैं। अच्छी खबर यह है कि हम जिन सभी भाषाओं पर विचार कर रहे हैं उनमें C, C ++, Haskell, आदि की सामान्य जड़ें हैं।

अंत में, आप पूछ सकते हैं, "C ++ पर क्यों नहीं बना?" मुझे यह स्वीकार करना चाहिए कि काम की प्रक्रिया में मैं अक्सर सोचता था कि क्या हमें C ++ से शुरू नहीं करना चाहिए और इससे कार्यक्षमता का "सुरक्षित सबसेट" काट देना चाहिए। हम अक्सर खुद को एक ब्लेंडर में "सी # और सी ++ को फेरबदल करते हुए देखते हैं, यह देखने की कोशिश करते हैं कि क्या होता है," और मैं स्वीकार करता हूं कि कभी-कभी सी # ने हमें वापस खींच लिया। विशेष रूप से, जब आप RAII, नियतात्मक विध्वंसक, लिंक, आदि के बारे में सोचना शुरू करते हैं। जेनरिक और टेम्प्लेट के बीच की सूक्ष्मता एक अलग पोस्ट के लायक है। मैं वास्तव में, जल्दी या बाद में, दो कारणों से C ++ पर स्विच करने पर विचार करने के लिए उम्मीद करता हूं: (1) इस कदम से भाषा के उपयोगकर्ताओं की संख्या में वृद्धि होगी (दुनिया में कई और प्रोग्रामर हैं जो C ++ को जानते हैं सी #) से जानते हैं और (2) मैं मानकीकरण का सपना देखता हूं ताकि खुले स्रोत समुदाय को भी "सुरक्षा और उत्पादकता" और "प्रदर्शन" के बीच चयन करने की आवश्यकता नहीं थी। लेकिन परियोजना के प्रारंभिक लक्ष्यों के हिस्से के रूप में, मुझे C # का उपयोग करने में खुशी है, और अंतिम कारण के लिए नहीं। .NET फ्रेमवर्क की समृद्ध कार्यक्षमता के लिए धन्यवाद।

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

उच्च स्तर पर, मैं बनाई गई भाषा की कार्यक्षमता को छह मुख्य श्रेणियों में वर्गीकृत करता हूं।

1. जीवन चक्र (लाइफटाइम समझ) को समझना। C ++ में RAII, नियतात्मक विध्वंसक और वस्तुओं का कुशल आवंटन होता है। सी # और जावा डेवलपर्स को कचरा कलेक्टर-संचालित ढेर पर बहुत अधिक भरोसा करने के लिए प्रोत्साहित करते हैं, और केवल आईडीसोपेरियल के माध्यम से वस्तुओं के निर्धारक विनाश के लिए फजी / कमजोर समर्थन का समर्थन करते हैं। मेरी टीम का हिस्सा लगातार C # में लिखे गए कार्यक्रमों को हमारी नई भाषा में परिवर्तित कर रहा है, और यह हमारे लिए असामान्य नहीं है कि कचरा संग्रहकर्ता कार्यक्रम के निष्पादन समय का 30-50% "खा जाता है"। सर्वर अनुप्रयोगों के लिए, यह तथ्य ग्राहकों को "मारता है" बैंडविड्थ, यह उपयोग की भावना को नीचा दिखाता है, क्योंकि यह इसके उपयोग के दौरान इंटरफ़ेस की जवाबदेही को कम करता है। हम कह सकते हैं कि हम C ++ की विशेषताओं का हिस्सा "चुरा लेते हैं", जिसका अर्थ है रेवल्यू रेफरेंस, मूवमेंट्स, डिस्ट्रक्टर्स, रेफरेंस और उधार। इसके साथ-साथ, हमने भाषा की सुरक्षा बनाए रखी, और कार्यात्मक प्रोग्रामिंग के विचारों के साथ C ++ से लिए गए विचारों को भी जोड़ा। यह सब हमें स्टैक पर वस्तुओं के आक्रामक आवंटन को लागू करने की अनुमति देता है, उन्हें नियतात्मक रूप से नष्ट कर देता है और बहुत कुछ।
2. साइड इफेक्ट्स को समझना (साइड-इफेक्ट्स समझ)। यह आइटम विचारों का एक विकास है जो हमने ओओपीएसएलए 2012 में प्रकाशित किया था। इसका तात्पर्य है कि सी + + (फिर से, एक सुरक्षित तरीके से) से कांस्ट ऑपरेटर के कार्यात्मक के भाषा भाग में, साथ ही साथ प्रथम श्रेणी की अपरिवर्तनीयता और अलगाव का परिचय है।
3. पैमाने पर Async प्रोग्रामिंग। समुदाय निरंतर इस मुद्दे के इर्द-गिर्द घूम रहा है, यह निर्धारित करता है कि निरंतरता-गुजरने या हल्के अवरोधक कोरटाइन का उपयोग करना है या नहीं। यह प्रश्न न केवल C # को प्रभावित करता है, बल्कि सभी मौजूदा भाषाओं को भी प्रभावित करता है। यहां प्रमुख नवाचार एक कंपोजेबल प्रकार की प्रणाली है, जो निष्पादन मॉडल के लिए "अज्ञेय" (उदासीन) है, और उनमें से किसी के साथ प्रभावी ढंग से बातचीत कर सकता है। यह कहना उचित होगा कि इस समस्या को हल करने के लिए हमारे पास केवल एक ही दृष्टिकोण है, लेकिन कई अन्य तरीकों की कोशिश करने के बाद, मैं कह सकता हूं कि मुझे वह पसंद है जिसे हमने चुना है।
4. प्रोग्रामिंग टाइप-सेफ सिस्टम (टाइप-सेफ सिस्टम प्रोग्रामिंग)। आप अक्सर दावे सुन सकते हैं कि प्रकार सिस्टम और प्रदर्शन हानि हाथ में जाते हैं। इसमें कोई संदेह नहीं है कि सीमा जाँच में समय लगता है, और यह भी कि हम डिफ़ॉल्ट रूप से सक्षम होने के लिए अतिप्रवाह जाँच को प्राथमिकता देते हैं। लेकिन यह आश्चर्यजनक है कि JIT संकलन के विपरीत एक अच्छे अनुकूलन वाले कंपाइलर के साथ कितना कुछ हासिल किया जा सकता है। हम आपको आवंटन के बिना और चीजें भी करने की अनुमति देंगे, जैसे कि लैम्ब्डा एपीआई पर आधारित, जिनमें से कॉल किसी भी आवंटन के साथ नहीं है (अब, एक नियम के रूप में, दो आवंटन आवश्यक हैं: एक प्रतिनिधि के लिए और दूसरा प्रदर्शन के लिए)। एक और "सुविधा" आवंटन के बिना "कट" उपशीर्षकों और सबस्ट्रिंग की क्षमता है।
5. आधुनिक त्रुटि मॉडल। यह आइटम एक और है जिससे समुदाय असहमत है। हम उन संभावित विकल्पों में से सबसे अच्छा होने पर विचार करते हैं, जो अनुबंध के सभी संभव और पूर्ण उपयोग (पूर्व शर्त, पोस्टकॉन्डिशन, इनवेंटरी, स्टेटमेंट, इत्यादि), पर्यावरण की बुनियादी सेटिंग के रूप में तेजी से विफलता से निपटने के लिए, केवल दुर्लभ गतिशील विफलताओं के लिए अपवाद (पार्सिंग) , I / O, आदि), और टाइप किए गए अपवाद केवल तब होते हैं जब विस्तारित अपवाद जानकारी की पूर्ण आवश्यकता होती है। यह सब प्रथम श्रेणी की वस्तुओं के रूप में टाइप सिस्टम में एकीकृत है, ताकि आपको अखंडता और सुरक्षा में आपकी जरूरत की हर चीज मिल जाए।
6. आधुनिक रूपरेखा । इसमें अतुल्यकालिक LINQ अभिव्यक्तियों और बेहतर प्रगणक समर्थन सहित चीजों की एक पूरी गुच्छा शामिल है, जो प्रदर्शन के मामले में C ++ पुनरावृत्तियों के साथ प्रतिस्पर्धा करेंगे और तत्वों को पुनः प्राप्त करने के लिए दोहरे इंटरफ़ेस प्रेषण की आवश्यकता नहीं होगी। सच कहूं, तो इस क्षेत्र में हमारे पास "अभी तक लागू नहीं" स्थिति के साथ चीजों की सबसे बड़ी सूची है। इसमें यह भी शामिल है: प्रथम श्रेणी की वस्तु के रूप में शून्य प्रकार, गैर-अशक्त प्रकार, लक्षण , प्रथम श्रेणी प्रभाव टाइपिंग, और बहुत कुछ। मुझे उम्मीद है कि 2014 के मध्य तक हमारे पास इस सूची के एक छोटे से हिस्से को लागू करने का समय होगा।

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

अपडेट पोस्ट करें

समुदाय के साथ एक खुले संवाद को सुविधाजनक बनाने के लिए एक निर्दोष ब्लॉग प्रविष्टि के रूप में जो कल्पना की गई थी, वह निश्चित रूप से कुछ अधिक हो गई है।

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

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

मुझे आपका उत्साह पसंद है, इसलिए कृपया संवाद के तकनीकी पक्ष से चिपके रहें। यदि अन्य सभी प्रतिबिंब और रैनिंग गायब हो जाते हैं, तो मैं एक खुश व्यक्ति बन जाऊंगा!

---

अनुवादक से आफ्टरवर्ड

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

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

मैं यह भी सलाह देता हूं कि आप RSDN द्वारा प्रकाशित "डॉली में समानांतर प्रोग्रामिंग और थ्रेड इन .NET में 10 प्रश्न " जो डफी के साथ साक्षात्कार का अनुवाद पढ़ें। हालांकि साक्षात्कार 2007 की तारीखों का है, मेरा मानना ​​है कि डफी के जवाब पुराने नहीं हैं।

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