Microsoft SWIT 2014 में जेफरी रिक्टर के साथ साक्षात्कार

27-28 मार्च को, Microsoft SWIT 2014 सम्मेलन कीव में आयोजित किया गया था। दो दिनों के भीतर, डेवलपर्स और आईटी प्रबंधक दुनिया भर के वक्ताओं से बड़ी संख्या में भाषण देख और सुन सकते थे।

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

(यदि यह आपको लगता है कि आप पहले भी इस विषय को पहले कहीं देख चुके हैं, तो नहीं, फिर एक साक्षात्कार था , और यह एक और है)।

हैलो, जेफरी। हम आपकी पुस्तकों और प्रस्तुतियों के बड़े प्रशंसक हैं, हमारे लिए अब यहाँ होना और आपके साथ बोलना एक बड़ा सम्मान है।
आपका धन्यवाद

मेरा नाम व्लादिमीर है, मैं सी ++ में लिखता हूं, और यह मेरे सहयोगी अलेक्जेंडर, एक नेट डेवलपर है। हमारे पास habrahabr.ru पर एक ब्लॉग भी है, शायद आपने इस समुदाय के बारे में नहीं सुना होगा, लेकिन यह हमारे साथ काफी लोकप्रिय है: रूस, यूक्रेन और अन्य देशों के लगभग एक लाख आईटी विशेषज्ञ। एक सप्ताह पहले, हमने Microsoft SWIT सम्मेलन में आपके आगमन की घोषणा की और लोगों को प्रश्न पूछने के लिए आमंत्रित किया। आपकी अनुमति से, मैं पाठकों के सबसे लोकप्रिय प्रश्न पूछूंगा, साथ ही साथ स्वयं से कुछ प्रश्न भी पूछूंगा।
लगभग।

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

आखिरकार, .NET माइक्रो फ्रेमवर्क मौजूद है - क्या यह इसके लिए नहीं है?
.NET प्लेटफ़ॉर्म को देखने के कई तरीके हैं। सबसे पहले, यह मानकों का एक सेट है जिसे कोई भी कंपनी ले सकती है और लागू कर सकती है, और ये कार्यान्वयन तब तक संगत होंगे जब तक वे मानकों का पालन करते हैं। Microsoft स्वयं कई .NET कार्यान्वयन का समर्थन करता है:
1. क्लासिक संस्करण, जो सभी डेस्कटॉप प्रोग्राम चलाता है, ASP.NET, सिल्वरलाइट, आदि के साथ सर्वर।
2. .NET कॉम्पैक्ट फ्रेमवर्क
3. .NET माइक्रो फ्रेमवर्क

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

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

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

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

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

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

क्या आप रोजलिन प्रोजेक्ट से परिचित हैं, जो C # और VB.NET कंपाइलर्स के लिए API प्रदान करता है? क्या आपको लगता है कि यह परियोजना सिर्फ एक खिलौना है, या मौजूदा भाषाओं के विस्तार के लिए एक महत्वपूर्ण शक्तिशाली उपकरण है, जो महत्वपूर्ण नए उत्पादों का निर्माण कर रहा है? क्या आप इस परियोजना के भविष्य में विश्वास करते हैं?
हां, मैं इस परियोजना को जानता हूं। इसके निर्माण में बहुत लंबा समय लगा, यह अभी भी विज़ुअल स्टूडियो की रचना में शामिल नहीं है, लेकिन आने वाले वर्षों में यह और अधिक महत्वपूर्ण हो जाएगा। परियोजना एक साथ कई कार्य करती है। सबसे पहले, उसने C # कंपाइलर डेवलपर्स को C # में फिर से लिखा। चूंकि अब कंपाइलर को तेजी से विकसित किया जा सकता है, भाषा की नई विशेषताओं को पेश करने की गति बढ़ जाएगी। दूसरे, अब C # के लिए एक रीफैक्टरिंग टूल लिखने का काम बहुत आसान हो गया है। Microsoft बड़ी संख्या में ऐसे उत्पादों के उद्भव की उम्मीद करता है, जिनके बीच प्रतिस्पर्धा होती है और उनकी गुणवत्ता में सुधार होता है। इसके अलावा, एक भाषा से दूसरी भाषा में कोड अनुवादक लिखना संभव हो गया।

क्या आपको लगता है कि भविष्य में रोजलिन हमेशा सी # भाषा की सभी प्रासंगिक विशेषताओं के साथ, संकलक के नवीनतम संस्करण का समर्थन करेंगे?
हां बिल्कुल। रोसलिन को विकसित करते समय, C # के वर्तमान संस्करण की सभी विशेषताओं को लागू किया गया था, फिर एक नया संस्करण जारी किया गया था - C # 6, जिनमें से क्षमताओं को भी अब रोज़लिन में जोड़ा गया है। इसके अलावा, C # भाषा संकलक का विकास मूल कोड से C # में ही कोड में स्थानांतरित हो गया है, जो रोजलिन में नई सुविधाओं के आसान एकीकरण की सुविधा भी प्रदान करेगा।

C ++ प्रोग्रामर के रूप में, C ++ / CLI और C ++ / CX पर आपकी राय में मेरी दिलचस्पी है। क्या आपको लगता है कि इन परियोजनाओं का भविष्य, अलग-अलग, अभिन्न भाषाओं या उनके भाग्य के रूप में है - नई Microsoft प्रौद्योगिकियों और मूल कोड वाली पुरानी परियोजनाओं के बीच एक पुल बनने के लिए?
सी ++ / सीएलआई - को कभी भी अधिक सफलता नहीं मिली। किसी तरह मुझे अपनी पुस्तक को C # से C ++ / CLI पर अनुकूलित करने की पेशकश की गई। परियोजना नहीं हुई - हमें ऐसा कोई नहीं मिला जो इसे पसंद कर सके और कर सके। यह भाषा Microsoft के लिए अजीब सा उपक्रम था ... मुझे यह भी पता नहीं है ... मैं कभी भी C ++ / CLI का उपयोग करते हुए एक व्यक्ति से उनकी मुख्य प्रोग्रामिंग भाषा के रूप में नहीं मिला। C ++ / CX के लिए, इसका उद्देश्य COM के साथ काम करना आसान बनाना है। COM एक तकनीक है जो 90 के दशक में बनाई गई थी, आप खुद जानते हैं कि यह सभी संदर्भ गिनती, इंटरफ़ेस रूपांतरण, और इसी तरह कितना भयानक है। .NET के बारे में आने वाले कारणों में से एक इस विरासत से छुटकारा पाने की इच्छा थी। घटक अच्छे हैं, लेकिन सीएलआर और प्रोग्रामर को न दें, स्मृति को आवंटित करने और मुक्त करने के मुद्दों से निपटें। विंडोज रनटाइम में, Microsoft देशी घटकों पर वापस लौटता है, और C ++ / CX इन घटकों के साथ काम करने का एक तरीका है। .NET घटकों के साथ काम करने की शैली में पारदर्शी है। C ++ भाषा स्वयं ही बनी हुई है, घटक एक्सटेंशन एक्सटेंशन केवल COM के साथ काम करने की भयावहता से हमें बचाता है।

एक दिलचस्प स्थिति है - मूल विकास के लिए Microsoft स्वयं C ++ का सक्रिय रूप से उपयोग कर रहा है (Windows के हाल के संस्करणों में समान Windows रनटाइम .NET में नहीं, बल्कि मूल घटकों के रूप में लिखा गया है), जबकि कंपनी तीसरे पक्ष के डेवलपर्स को इस ++ का उपयोग करने के लिए प्रोत्साहित नहीं करती है, लेकिन .NET और C # को बढ़ावा देता है। क्यों?
Microsoft के बड़े आकार के बावजूद, इसके संसाधन अभी भी सीमित हैं। आप सब कुछ कवर नहीं कर सकते, आप सभी तकनीकों का समर्थन नहीं कर सकते। प्रत्येक बात के लिए, विशिष्ट निर्णय किए जाते हैं: “कितने लोग इसका उपयोग करेंगे? विकास क्षमता क्या है? कंपनी अंततः कितना पैसा कमाती है? ” जाहिर है, अभी Microsoft की सर्वोच्च प्राथमिकता .NET और प्रबंधित कोड पर है। बेशक, C ++ / CLI और C ++ / CX दोनों का समर्थन किया जाएगा, बग्स को ठीक किया जाएगा, लेकिन इन उत्पादों के सक्रिय विकास के लिए कम संसाधन आवंटित किए जाएंगे।

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

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

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

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