.NET में अतुल्यकालिक, स्टैक ओवरफ्लो पर लोकप्रियता, "चर्च" सॉफ्टवेयर: स्टीफन क्लीरी के साथ साक्षात्कार

स्टीफन क्लीयर स्टैक ओवरफ्लो के शीर्ष 100 उपयोगकर्ताओं में शामिल हैं। ज्यादातर .NET में इसके अतुल्यकालिक उत्तर के लिए धन्यवाद। उनका जीवन प्रोग्रामिंग तक ही सीमित नहीं है: ट्विटर पर, वह पहले खुद के बारे में लिखते हैं "ईसाई", और उसके बाद ही "डेवलपर"।

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

जीवनी

- पहला सवाल सरल है: हमें अपनी व्यावसायिक जीवनी के बारे में बताएं।

- मुझे काफी पहले से प्रोग्रामिंग में दिलचस्पी थी, मैं 7-8 साल का था। तब स्कूल में मैं लोगो भाषा में एक छोटा सा कार्यक्रम लिखने में सक्षम था, और यह मेरा पहला प्रोग्रामिंग अनुभव था। बाद में, जब मैं १२-१३ था, मैंने अपने पहले कंप्यूटर पर सेव किया। और जब मैंने कॉलेज में प्रवेश करते समय कंप्यूटर विज्ञान को चुना, तो यह एक बहुत स्पष्ट निर्णय था: मैं पहले से ही एक मूर्त समय के लिए कंप्यूटर में रुचि रखता था।

1998 में, कॉलेज से स्नातक होने के बाद, मैंने उद्योग और अन्य कारखाने स्वचालन के लिए वाहनों द्वारा स्वचालित रूप से नियंत्रित कन्वेयर में लगी एक स्थानीय कंपनी के लिए काम करना शुरू कर दिया। सात साल बाद, कंपनी डेट्रॉइट चली गई, लेकिन मैं वहां नहीं जाना चाहता था और तब से मैं विभिन्न कंपनियों में काम करने में कामयाब रहा। 2013 के बाद से, मैं दूरस्थ रूप से काम करता हूं, पिछले साल और डेढ़ - फेथलाइफ़ में।

- यह हास्यास्पद है कि आपने लोगो के साथ शुरुआत की, और अब एक कंपनी में जिसका मुख्य उत्पाद लोगो कहा जाता है। और वास्तव में आप वहां क्या कर रहे हैं?

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

मैं बैकएंड करता हूं, मुझे अक्सर ASP.NET वेब एपीआई से निपटना पड़ता है, और अभी मैं डॉकर के साथ काम कर रहा हूं। अभी हमारे पास क्लाउड में हिस्सा है, और ऑन-प्रिमाइसेस में हिस्सा है, और कुछ को बिल्कुल भी क्लाउड में स्थानांतरित नहीं किया जाना चाहिए, लेकिन हम कुछ चीजों को वहां स्थानांतरित करना चाहते हैं - और मैं यह कर रहा हूं।

धर्म

- यह अक्सर नहीं होता है कि आप "चर्च" सॉफ़्टवेयर बनाने वाली कंपनी से मिलते हैं, इसलिए मैं स्पष्ट करना चाहता हूं: क्या बैकएंड पर काम हर जगह की तरह दिखता है, या इसकी अपनी विशिष्टताएं हैं? और डेवलपर आमतौर पर विश्वासी होते हैं और खुद कंपनी के उत्पादों का उपयोग करते हैं या नहीं?

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

यद्यपि फेथलाइफ़ चर्च के लिए उत्पाद बनाता है, लेकिन यह एक ईसाई कंपनी नहीं है। यहां पहुंचने के लिए, आपको एक ईसाई होने की आवश्यकता नहीं है: सबसे पहले, इस तरह का चयन अमेरिकी कानून का उल्लंघन करेगा (भर्ती में धार्मिक भेदभाव होगा), और दूसरी बात, कंपनी वैसे भी यह नहीं चाहेगी।

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

- जैव क्षेत्र में आपके ट्विटर पर "क्रिश्चियन" और "डेवलपर" शब्द हैं। क्या आपकी पहचान के इन दो हिस्सों को किसी तरह से काटना है?

- मैं कहूंगा कि वे अलग हैं। मैंने हमेशा अपने खाली समय में काम नहीं करते हुए, कामकाजी जीवन और घर को अलग करने की कोशिश की (हालांकि यह हमेशा काम नहीं करता था)। चर्च मेरे व्यक्तित्व का एक बड़ा हिस्सा है, मेरे ज्यादातर दोस्त वहीं से हैं। काम के दौरान, मैंने कुछ दोस्त बनाए।

"ठीक है, आपका बायो भी कहता है" ओएसएस लिखने के आदी, "और लोगों को मुफ्त सॉफ्टवेयर देने पर परोपकारी और ईसाई लगता है। इस मामले में, कोई संबंध नहीं है?

- हम्म, शायद। मुझे लगता है, एक दार्शनिक दृष्टिकोण से, आप वास्तव में खुले स्रोत और ईसाई धर्म के बीच संबंध देख सकते हैं: दोनों मामलों में, जोर "लोगों को दे" पर है।

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

- आप स्टैक ओवरफ्लो पर भी सक्रिय हैं - क्या यह भी आपके लिए समुदाय को निःस्वार्थ रूप से कुछ देने का एक तरीका है?

- मैं यह नहीं कहूंगा कि, मेरे लिए यह "अध्यापन" की तरह लगता है। हालांकि "शिक्षण" को ईसाई धर्म से भी जोड़ा जा सकता है ... मेरे परिवार में कई शिक्षक थे, और मैं इसे अपने तरीके से जारी रखता हूं - पेशे के रूप में नहीं, बल्कि स्टैक ओवरफ्लो और सम्मेलनों की मदद से। इसलिए मैं इसके लिए अपनी जरूरत को पूरा करता हूं।

ढेर अतिप्रवाह

- हमारे पास अभी भी स्टैक ओवरफ्लो के बारे में कई प्रश्न हैं, पहला निराला। आपको हाल ही में विंडोज फोन 8 पर जवाब के लिए एक बैज मिला है:



यह कैसे हुआ कि 2019 में आपको लगभग मृत तकनीक के बारे में जवाब के लिए बिल्ला मिला? क्या कोई अभी भी उसके बारे में सवाल पूछ रहा है?

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

- एसओ पर, आपकी प्रतिष्ठा 320,000 है - और यह पौराणिक जॉन स्कीट की प्रतिष्ठा के एक चौथाई से अधिक है, हालांकि आपने जवाब दिया कि वह उससे छोटे परिमाण का एक आदेश देता है। आपको यह कैसे मिला?

- मुझे पूरा यकीन नहीं है उन लोगों के लिए प्रतिष्ठा प्राप्त करना आसान है जो हर किसी से पहले साइट पर आए थे, और हालांकि मैं शुरुआती दत्तक ग्रहण करने वालों में से था, फिर भी मैं कई लोगों की तुलना में बाद में आया। मैंने सवालों का जवाब देना शुरू किया - पहले, प्रति दिन 1-2, जो जॉन स्कीट से बहुत दूर है। Async / इंतजार के विषय पर, साथ ही साथ संगामिति और बहु-प्रसार पर ध्यान केंद्रित किया गया - केवल इसलिए कि यह वास्तव में, इसकी विशेषता बन गया। कई साल पहले मैं पहले से ही अतुल्यकालिक में लगा हुआ था, और फिर यह दर्दनाक था। इसलिए जब async / प्रतीक्षा प्रकट हुई, मैंने तुरंत देखा कि उनका क्या अर्थ था। इसलिए मैं सही समय पर सही जगह पर था, और मेरे "शिक्षक के खून" ने लोगों को समझ में आने वाली भाषा में सब कुछ समझाने में मदद की। और स्टैक ओवरफ्लो के मामले में, मैं एक स्थानीय async / प्रतीक्षारत विशेषज्ञ निकला। और जॉन स्कीट - ठीक है, उन्होंने सीधे तौर पर यह नहीं कहा, लेकिन मुझे लगता है कि यह मुझे async के बारे में अधिकांश प्रश्न छोड़ देता है / मेरी प्रतीक्षा करता है। लेकिन निश्चित रूप से, वह मुझसे ज्यादा जवाब देता है, वह पकड़ा नहीं जा सकता है!

- प्रतिष्ठा की संख्या को देखते हुए, यह सोचना आसान है कि "एक व्यक्ति उत्तर देने के लिए अपना आधा जीवन लगा देता है" - और आप वास्तव में एसओ पर कितना समय बिताते हैं?

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

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

- जब जॉन स्कीट डॉटनेट पर हमारे पास आए, तो हमने उनसे स्टैक ओवरफ्लो की वर्तमान स्थिति और साइट की समस्याओं पर विचार किया। तुलना करना दिलचस्प है: आप इस बारे में क्या सोचते हैं?

"मुझे लगता है कि SO में सुधार हो रहा है, विशेष रूप से अंतिम वर्ष में।" वे अब प्रश्नों की गुणवत्ता में सुधार के लिए बहुत प्रयास कर रहे हैं। अक्सर, इस साइट पर कुछ पूछने वाले लोग पहले से अपरिचित होते हैं कि तकनीकी प्रश्न कैसे सही तरीके से पूछे जाएं।

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

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

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

और सवालों की गुणवत्ता की समस्या के अलावा, एक प्रवृत्ति भी है - विशेष रूप से स्टैक ओवरफ्लो पर, जहां हर कोई अंकों के लिए संघर्ष करता है, जितनी जल्दी हो सके जवाब देने की कोशिश कर रहा है - जल्दी से सवाल को बंद करें या सबसे सुखद जवाब नहीं स्क्रिबल करें। मेरा मतलब यह नहीं है कि '' चंचल '', मैंने बहुत कम स्पष्ट रूप से चंचल टिप्पणियों को देखा है - केवल कुछ वर्षों में। बल्कि, वे कठोर हैं, और प्रश्न के लेखक के लिए यह दोस्ती के रूप में पढ़ा जाता है।

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

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

asynchrony

- iPhone की 10 वीं वर्षगांठ के लिए समर्पित एक पोस्ट में , आप लिखते हैं कि इसकी उपस्थिति अतुल्यकालिक प्रोग्रामिंग को प्रभावित करती है, क्योंकि मोबाइल एप्लिकेशन उत्तरदायी होना चाहिए। और क्या आप उन लोगों के लिए अतुल्यकालिक के विकास पर एक सामान्य ऐतिहासिक पृष्ठभूमि दे सकते हैं, जिन्होंने हाल ही में विकास शुरू किया है और दुनिया को बिना async / प्रतीक्षा के नहीं देखा है?

- खैर, अतुल्यकालिक प्रोग्रामिंग हमेशा संभव हो गया है। मुझे लगता है कि 60 के दशक में वे पहले से ही ऐसा कर रहे थे। और लंबे समय तक उनके पास समान फायदे थे: एक अधिक उत्तरदायी यूआई और एक अधिक स्केलेबल सर्वर हिस्सा। और समर्थन हमेशा एक समस्या रही है: अतुल्यकालिक कोड बनाए रखना बहुत मुश्किल था। प्रारंभ में, यह कॉलबैक पर बनाया गया था।

मुझे लगता है कि बड़ा कदम वादा का आगमन था। इसे वे जावास्क्रिप्ट में कहते हैं, और C # में यह टास्क या वैल्यूटैस्क है। और यह एक बड़ा कदम था, क्योंकि अब हमारे पास ऑपरेशन का प्रतिनिधित्व करने वाली एक वस्तु है। आप इसकी प्रगति आदि की निगरानी कर सकते हैं। और किसी भी भाषा में async / प्रतीक्षारत अनिवार्य रूप से वादा के चारों ओर केवल वाक्यात्मक चीनी है।

मैं कहूंगा कि प्रॉमिस की उपस्थिति ऐसी घटना है जिसका अतुल्यकालिक कोड पर सबसे अधिक प्रभाव पड़ा है। और async / प्रतीक्षा के मामले में, यह महत्वपूर्ण है कि राज्य मशीन आपके लिए बनाई गई है। पुराने दिनों में, जब हमने कॉलबैक के साथ काम किया, तो हमें अपनी खुद की राज्य मशीनों को खुद बनाना था। और यह हमेशा मुश्किल था क्योंकि आप अनिवार्य रूप से कुछ स्थिति या संक्रमण को भूल गए, और कुछ भी काम नहीं किया। और डिबग करना बहुत मुश्किल था। Async / wait में एसिंक्रोनस कोड लिखने की बहुत क्षमता नहीं थी, लेकिन कोड लिखने की क्षमता जो समर्थित हो सकती है।

- और अब क्या आप देखते हैं कि स्थिति ठीक हो गई है, या नए बदलाव जल्द ही हमारे लिए इंतजार कर रहे हैं?

- मुझे लगता है कि अब सब कुछ बहुत स्थिर है। Async / प्रतीक्षित क्रांतिकारी दिखे - लेकिन केवल उन लोगों के लिए जिन्होंने पहले अतुल्यकालिक प्रोग्रामिंग नहीं की थी। और काम करने वालों के लिए, यह बहुत स्वाभाविक लगा। लेकिन, सामान्य तौर पर, यह एक बड़ी घटना थी।

और अब एक और घटना .NET कोर 3 के साथ आती है। वे वही करते हैं जो हर कोई एसिंक्रोन स्ट्रीम कहता है, हालांकि वे वास्तव में एसिंक्रोनस एनुमरबेल हैं। मुझे लगता है कि यह लोगों को भ्रमित करेगा, क्योंकि पहले से ही एक स्ट्रीम प्रकार है जो कि async धाराओं के साथ कुछ नहीं करना है। सामान्य तौर पर, अधिक वृद्धिशील सुधार होंगे। क्या हम किसी चीज़ को बड़े पैमाने पर देख पाएंगे जब async / wait ने पहली बार खुद की घोषणा की? मुझे ऐसा नहीं लगता।

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

- समय के साथ सब कुछ कितना बदल जाता है, इस सवाल का। कई प्रोग्रामिंग किताबें तेजी से अप्रचलित हो रही हैं, लेकिन जहां परिवर्तन कम हैं, वे लंबे समय तक रहते हैं। C # कुकबुक में आपकी कंज्यूरेबिलिटी के बारे में , अपडेट के लिए कितना आवश्यक है?

- अच्छा सवाल है। मैंने अभी हाल ही में दूसरा संस्करण प्रकाशित किया, और पहला 2014 में सामने आया। यही है, पांच साल बीत चुके हैं, और हम पहले से ही दूसरे संस्करण पर हैं - मेरे लिए यह एक तेज विकास की तरह दिखता है।

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

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

- हाल ही में, ट्विटर पर async / प्रतीक्षारत के बारे में ट्विस्ट आया है, जो DTD और अभिनेता मॉडल पर कई पुस्तकों के लेखक वॉन वर्नोन के एक ट्वीट के साथ शुरू हुआ है:



वह async / importunity का इंतजार नहीं करता है - उसकी राय में, यह पूरे कोड में फैलता है और थ्रेड ब्लॉकिंग का कारण बन सकता है। आप इस बारे में क्या सोचते हैं? क्या इसके लायक कुछ और डिजाइन करना था?

- हां, शायद यह तथ्य कि प्रोजेक्ट के आस-पास async / इंतजार फैल रहा है, सबसे आम शिकायत है। मैं यहां कुछ बातों का उल्लेख करना चाहूंगा।

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

Async / प्रतीक्षा के व्यापक प्रभुत्व से बचने के लिए अलग-अलग दृष्टिकोण हैं। पहले सभी इनपुट / आउटपुट को अलग-अलग ऑब्जेक्ट में अलग करना है। आप पोर्ट और एडेप्टर जैसे डिज़ाइन पैटर्न का उपयोग कर सकते हैं: इससे आप अपने व्यवसाय तर्क के बाहर सभी I / O को शामिल कर सकते हैं, और फिर इसे किसी भी async / प्रतीक्षा की आवश्यकता नहीं होगी। हाल ही में मैंने एक पूरी रिपोर्ट देखी कि कैसे "हर जगह" async को रोकने के लिए परियोजना को फिर से तैयार करके ताकि व्यापार तर्क I / O के साथ कभी भी व्यवहार न करे। मैं इस दृष्टिकोण की सिफारिश करूंगा।

एसिंक्स / वेट के प्रभुत्व से निपटने के लिए एक और तरीका है, लेकिन यह .NET में संभव नहीं है। मेरी राय में, गो ने गोरोइंट्स के साथ ऐसा करने की कोशिश की। वास्तव में, सब कुछ है - यह एक ठोस async / प्रतीक्षा है। आप भाषा से async / प्रतीक्षारत निकाल सकते हैं और इसे हर चीज़ में जोड़ सकते हैं और इसे अंतर्निहित कर सकते हैं।

और कोई उपाय नहीं है। जब async / wait दिखाई दिया, तो किसी ने (मुझे ठीक से याद नहीं है) किसने कहा कि यह एक ज़ोंबी वायरस की तरह था: जैसे ही आपके कोड का हिस्सा संक्रमित होता है, वितरण शुरू हो जाता है।

- कुछ डेवलपर्स एक्टर मॉडल का उपयोग करते हैं, इसे प्रवाह नियंत्रण की सादगी से समझाते हैं (अभिनेता, वास्तव में, सिंगल-थ्रेडेड हैं)। क्या आपको लगता है कि पुस्तकालयों के सही विकल्प के साथ, डेवलपर्स प्रोग्रामिंग संगामिति की जटिलता से छुटकारा पा सकते हैं?

"ठीक है, काफी नहीं।" क्योंकि अभिनेता मॉडल के साथ भी, समस्याएं बनी हुई हैं। आप बहु-थ्रेडेड प्रोग्राम में इस तरह की दौड़ की स्थितियों का सामना नहीं करेंगे, लेकिन आपको दोस्ती की कठिनाइयों का सामना करना पड़ेगा।

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

इसके अलावा, अतुल्यकालिक संदेशों के साथ अभिनेताओं का उपयोग करना राज्य प्रबंधन को बहुत भ्रमित कर सकता है, जब तक कि यह पूरी तरह से संदेशों में न हो। और यहां तक ​​कि इस मामले में, आपको अंततः सुसंगतता के साथ कठिनाइयां होंगी। सामान्य तौर पर, मेरे दृष्टिकोण से, अभिनेता मॉडल सभी समस्याओं को हल नहीं कर सकता है। मैं इसे इस तरह से वर्णित करूंगा: यह केवल वही बदल सकता है जहां वास्तव में समस्याएं उत्पन्न होंगी।

"आप एक दाता के रूप में जाने जाते हैं, लेकिन आप टाइपस्क्रिप्ट जैसी अन्य भाषाओं का उपयोग करते हैं।" जब आप उन्हें आज़माते हैं, तो यह आपको C # और .NET पर कैसे दिखता है? क्या आप वहां कुछ ऐसा मिलते हैं जिसे आप C # में देखना चाहेंगे?

- बढ़िया सवाल। C # ने अन्य भाषाओं से बहुत कुछ लिया। उनमें से एक जिसमें से वह बहुत कुछ ले गया वह पायथन है। और मुझे यह पसंद है। मैंने वर्षों तक पायथन में नहीं लिखा है, लेकिन मुझे लगता है कि यह एक बहुत अच्छी तरह से डिज़ाइन की गई भाषा है। मैं वास्तव में प्रगणक ब्लॉक की सराहना करता हूं जो पायथन से C # उधार लिया गया है। और पायथन पहले में से एक था जहां Async धाराएँ दिखाई दीं, इसलिए हम कह सकते हैं कि C # इसे वहां से ले गया।

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

- DotNext पर आपकी रिपोर्ट के बारे में सवालों के आखिरी जोड़े। आप वहां अतुल्यकालिक धाराओं के बारे में बात करने जा रहे हैं - क्या आप संक्षेप में .NET डेवलपर्स को बता सकते हैं कि क्या उम्मीद है और यह रिपोर्ट उनके लिए क्यों उपयोगी होगी?

- तो, ​​Asyncronous धाराओं पर मेरी रिपोर्ट: उन्हें भाषा में क्यों जोड़ा गया, और उनके उपयोग के लिए मुख्य परिदृश्य क्या है। मैं इसे बहुत व्यावहारिक रूप से देखता हूं, और हुड के नीचे क्या हो रहा है, इसके सभी विवरणों में नहीं जाते हैं। , async streams, , , async streams, .

— . — DotNext?

— , , , . , : , .

, , , . - async streams , , , . , DotNext.

DotNext 2019 Moscow 6-7 . , — .