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

(इस बीच, आप और मैं केवल सबसे प्रबुद्ध भाषा और परिष्कृत उपकरण का उपयोग करते हैं जो हमारे जैसे स्वामी के निपुण हाथों के लिए डिज़ाइन किए गए हैं)।

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

अपने आप को धर्मी आग से बचाने के लिए और आपकी (शायद नाजुक) भावनाओं को ठेस न पहुँचाने के लिए, मैं भाषा के बारे में बात करूँगा ...

... कौन अभी आया। एक पुआल पुतले के बारे में, जिसकी एकमात्र भूमिका आलोचकों को दांव पर लगाने की है।

मुझे पता है कि यह मूर्खतापूर्ण लगता है, लेकिन मेरा विश्वास करो, अंत में हम देखेंगे कि किसका चेहरा (या चेहरे) पुआल के सिर पर चित्रित किया गया था।

नई भाषा

यह केवल एक ब्लॉग लेख के लिए एक पूरी तरह से नई (और बेकार) भाषा सीखने के लिए एक ओवरकिल होगा, तो हम कहते हैं कि यह उस भाषा के समान है जो हम पहले से जानते हैं। उदाहरण के लिए जावास्क्रिप्ट। घुंघराले ब्रेसिज़ और अर्धविराम। if , while , आदि - हमारी भीड़ का लिंगुआ फ्रेंका ।

मैंने JS को इसलिए नहीं चुना क्योंकि यह लेख उसके बारे में है। यह एक ऐसी भाषा है जिसे औसत पाठक प्राप्त करने की संभावना रखते हैं। देखा:

 function thisIsAFunction(){ return "!"; } 

चूंकि हमारा भरवां जानवर एक शांत (पढ़ा हुआ - बुरा) भाषा है, इसलिए इसमें प्रथम श्रेणी के कार्य हैं । तो आप कुछ इस तरह लिख सकते हैं:

 //  ,     , //    function filter(collection, predicate) { var result = []; for (var i = 0; i < collection.length; i++) { if (predicate(collection[i])){ result.push(collection[i]); } } return result; } 

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

शायद परीक्षणों में:

 describe("", function(){ it(" ", function(){ expect("").not.toBe(""); }); }; 

या जब आपको डेटा को पार्स (पार्स) करने की आवश्यकता हो:

 tokens.match(Token.LEFT_BRACKET, function(token){ // Parse a list literal... tokens.consume(Token.RIGHT_BRACKET); }); 

फिर, त्वरित करने के बाद, आप सभी प्रकार के शांत पुन: प्रयोज्य पुस्तकालयों और अनुप्रयोगों को लिखते हैं जो फ़ंक्शन, फ़ंक्शन कॉल, फ़ंक्शन से फ़ंक्शन के चारों ओर घूमते हैं - एक कार्यात्मक बूथ।

अनुवादक: मूल "फंतालापलुज़ा" में। उपसर्ग -a-palooza इतनी शांत है कि आप इसे सभी के साथ साझा करना चाहते हैं।

आपका रंग क्या है?

और यहाँ विषमताएँ शुरू होती हैं। हमारी भाषा में एक अजीब विशेषता है:

1. प्रत्येक फ़ंक्शन का एक रंग होता है।

प्रत्येक फ़ंक्शन - एक अनाम कॉलबैक या नाम के साथ एक नियमित फ़ंक्शन - या तो लाल या नीला है। चूंकि हमारे ब्लॉग में कोड के हाइलाइटिंग कार्यों के विभिन्न रंग को उजागर नहीं करते हैं, चलो सहमत हैं कि वाक्यविन्यास है:

 blue*function doSomethingAzure(){ //   ... } red*function doSomethingCarnelian(){ //    ... } 

हमारी भाषा में रंगहीन कार्य नहीं हैं। एक सुविधा बनाना चाहते हैं? - एक रंग चुनना होगा। ये नियम हैं। और कुछ और नियम हैं जिनका आपको पालन करना चाहिए:

2. रंग फंक्शन को कहने के तरीके को प्रभावित करता है

कल्पना कीजिए कि कॉलिंग फ़ंक्शन के लिए दो सिंटैक्स हैं - "ब्लू" और "रेड"। कुछ इस तरह:

 doSomethingAzure(...)*blue; doSomethingCarnelian()*red; 

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

मूर्ख शासन, सही? ओह, लेकिन एक और बात:

3. केवल लाल फ़ंक्शन लाल फ़ंक्शन का कारण बन सकता है।

आप लाल से नीले फ़ंक्शन को कॉल कर सकते हैं । यह कोषेर है:

 red*function doSomethingCarnelian(){ doSomethingAzure()*blue; } 

लेकिन दूसरे तरीके से नहीं। यदि आप कोशिश करते हैं:

 blue*function doSomethingAzure(){ doSomethingCarnelian()*red; } 

- आप पुराने जोकर स्पाइडर मावे से मिलने जाएंगे।

यह उदाहरण से filter() जैसे उच्च कार्यों को लिखना कठिन बनाता है। हमें प्रत्येक नए फ़ंक्शन के लिए एक रंग चुनना चाहिए और यह उन कार्यों के रंग को प्रभावित करता है जिन्हें हम इसमें पास कर सकते हैं। स्पष्ट समाधान filter() लाल बनाना है। तब हम कम से कम लाल, कम से कम नीले कार्यों को कॉल कर सकते हैं। लेकिन फिर हमें कांटों के ताज में अगले कांटे के बारे में चोट लगी है, जो दी गई भाषा है:

4. लाल कार्यों के कारण दर्द होता है

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

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

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

काश, उदासी जिन्होंने इस भाषा को विकसित किया (हर कोई जानता है कि प्रोग्रामिंग भाषाओं के लेखक सैडिस्ट हैं, ठीक है?) हम में आखिरी कांटा चिपका दें:

5. भाषा के कुछ मुख्य कार्य लाल हैं।

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

यह सभी कार्यात्मक भाषाओं का दोष है!

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

यदि हम केवल नीले रंग के कार्य करते हैं, तो हम अपने सभी कार्यों को नीला बनाते हैं। अन्यथा, हम लाल बनाते हैं। जब तक हम फ़ंक्शन को स्वीकार नहीं करते हैं, तब तक हमें "फ़ंक्शन के रंग के लिए बहुरूपता" (पॉलीक्रोमैटिक?) या अन्य बकवास के बारे में चिंता करने की आवश्यकता नहीं है।

लेकिन अफसोस, उच्च-क्रम के कार्य केवल एक उदाहरण हैं। समस्या तब आती है जब हम अपने कार्यक्रम को पुन: उपयोग के लिए कार्य में तोड़ना चाहते हैं।

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

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

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

रंग रूपक

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

लाल कार्य - अतुल्यकालिक

यदि आप जावास्क्रिप्ट या Node.js में प्रोग्राम करते हैं, तो हर बार जब आप एक फ़ंक्शन को परिभाषित करते हैं जो कॉलबैक फ़ंक्शन (कॉलबैक) को "रिटर्न" करने के लिए कहता है , तो आप एक लाल फ़ंक्शन लिखते हैं। नियमों की इस सूची को देखें और देखें कि वे मेरे रूपक में कैसे फिट होते हैं:

1. सिंक्रोनस फ़ंक्शंस एक परिणाम लौटाते हैं, अतुल्यकालिक फ़ंक्शंस नहीं करते हैं, बदले में, वे कॉलबैक कहते हैं।
2. सिंक्रोनस फ़ंक्शंस परिणाम को रिटर्न वैल्यू के रूप में लौटाते हैं, एसिंक्रोनस फ़ंक्शंस इसे वापस करते हैं, जिससे कॉलबैक होता है जो आपने उन्हें दिया था।
3. आप किसी अतुल्यकालिक फ़ंक्शन को सिंक्रोनस से नहीं कह सकते, क्योंकि आप परिणाम को तब तक नहीं जान सकते जब तक कि बाद में एसिंक्रोनस फ़ंक्शन निष्पादित नहीं किया जाता है।
4. अतुल्यकालिक कार्यों को कॉलबैक के कारण अभिव्यक्तियों में संकलित नहीं किया जाता है, उनकी त्रुटियों को अलग-अलग तरीके से नियंत्रित करने की आवश्यकता होती है और उन्हें एक try/catch ब्लॉक या प्रोग्राम को नियंत्रित करने वाले कई अन्य अभिव्यक्तियों में उपयोग नहीं किया जा सकता है।
5. Node.js के बारे में पूरी बात यह है कि कर्नेल लाइब्रेरी सभी अतुल्यकालिक है। (हालांकि वे वापस दान करते हैं और बहुत सी चीजों में _Sync() संस्करण जोड़ना शुरू करते हैं।)

जब लोग "कॉलबैक नरक" के बारे में बात करते हैं, तो वे इस बारे में बात करते हैं कि उनकी भाषा में "लाल" कार्यों के लिए कितना कष्टप्रद है। जब वे अतुल्यकालिक प्रोग्रामिंग के लिए 4089 पुस्तकालय बनाते हैं (2019 में पहले से ही 11217 - लगभग। ट्रान्सलेटर), तो वे पुस्तकालय स्तर पर इस समस्या से निपटने की कोशिश करते हैं कि वे भाषा के साथ फंस गए हैं।

मैं वादा करता हूं कि भविष्य बेहतर है

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

Node.js के लोगों ने लंबे समय से महसूस किया है कि कॉलबैक चोट लगी है, और समाधान की तलाश कर रहे थे। कई लोगों को प्रेरित करने वाली तकनीकों में से एक promises , जिसे आप उपनाम futures द्वारा भी जान सकते हैं।

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

Promis कॉलबैक और त्रुटि हैंडलर के लिए एक आवरण है। यदि आप परिणाम के लिए एक कॉलबैक और त्रुटि के लिए एक और कॉलबैक पारित करने के बारे में सोच रहे हैं, तो future इस विचार का अवतार है। यह एक मूल वस्तु है जो एक अतुल्यकालिक ऑपरेशन है।

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

लेकिन ईमानदार होने के लिए, यह पेट या कमर में एक हिट के बीच अंतर की तरह है। हां, यह इतना दुख नहीं है, लेकिन कोई भी इस तरह की पसंद से खुश नहीं होगा।

आप अभी भी अपवाद हैंडलिंग या अन्य के साथ वादों का उपयोग नहीं कर सकते हैं
प्रबंध संचालक। आप ऐसे फ़ंक्शन को कॉल नहीं कर सकते जो समकालिक कोड से future लौटाता है। (आप कर सकते हैं , लेकिन फिर आपके कोड के अगले अनुचर एक टाइम मशीन का आविष्कार करेंगे, जिस पल में आपने किया था, उस समय पर लौटें और कारण # 2 के लिए अपने चेहरे पर एक पेंसिल चिपकाएं।)

वादे अब भी आपकी दुनिया को सभी आने वाली पीड़ाओं के साथ अतुल्यकालिक और तुल्यकालिक हिस्सों में विभाजित करते हैं। इसलिए भले ही आपकी भाषा promises या futures का समर्थन promises , लेकिन यह अभी भी मेरी भरपाई की तरह दिखता है।

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

परियोजना लिंक आधिकारिक तौर पर छोड़ दिया गया

मुझे समाधान का इंतजार है

सी # प्रोग्रामर शायद आत्मसंतुष्ट महसूस करते हैं (इसका कारण यह है कि वे अधिक से अधिक पीड़ित बन रहे हैं हेल्सबर्ग और कंपनी सब कुछ छिड़कती है और भाषा को चीनी के साथ छिड़कती है )। C # में, आप एसिंक्रोनस फ़ंक्शन को कॉल करने के लिए await कीवर्ड का उपयोग कर सकते हैं।

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

Async-wait अच्छा है, इसलिए हम इसे डार्ट में जोड़ते हैं। इसके साथ अतुल्यकालिक कोड लिखना बहुत आसान है। लेकिन, हमेशा की तरह, एक "लेकिन" है। यहाँ यह है। लेकिन ... आप अभी भी दुनिया को आधे हिस्से में बांटते हैं। एसिंक्रोनस फ़ंक्शंस अब लिखना आसान है, लेकिन वे अभी भी एसिंक्रोनस फ़ंक्शंस हैं।

आपके पास अभी भी दो रंग हैं। Async-wait से कष्टप्रद समस्या का समाधान # 4 होता है - वे कॉलिंग को लाल फ़ंक्शन कहते हैं, जो ब्लू कॉलिंग से अधिक कठिन नहीं है। लेकिन बाकी नियम अभी भी यहाँ हैं:

1. सिंक्रोनस फ़ंक्शंस मान लौटाते हैं, अतुल्यकालिक फ़ंक्शंस एक रैपर ( Task<T> C # या Future<T> डार्ट में) मान के आसपास लौटाते हैं।
2. सिंक्रोनस बस कहा जाता है, अतुल्यकालिक जरूरत का await ।
3. एक अतुल्यकालिक फ़ंक्शन को कॉल करके, आपको एक आवरण वस्तु मिलती है जब आप वास्तव में एक मूल्य चाहते हैं। जब तक आप अपने फ़ंक्शन को अतुल्यकालिक नहीं बनाते हैं और तब तक await साथ इसे कॉल नहीं कर सकते (लेकिन अगले पैराग्राफ को देखें)।
4. थोड़ी प्रतीक्षा की सजावट के अलावा, कम से कम हमने इस समस्या को हल किया।
5. C # कोर लाइब्रेरी अतुल्यकालिक से पुरानी है, इसलिए मुझे लगता है कि उन्हें यह समस्या कभी नहीं हुई।

Async वास्तव में बेहतर है। मैं सप्ताह के किसी भी दिन नग्न कॉलबैक के लिए async-wait पसंद करूंगा। लेकिन हम खुद से झूठ बोलते हैं अगर हम सोचते हैं कि सभी समस्याओं का समाधान किया जाता है। जैसे ही आप उच्च-क्रम के कार्यों को लिखना शुरू करते हैं, या कोड का पुन: उपयोग करते हैं, आप फिर से महसूस करते हैं कि रंग अभी भी है, आपके सभी स्रोत कोड के माध्यम से खून बह रहा है।

कौन सी भाषा रंग नहीं है?

इसलिए JS, Dart, C # और Python को यह समस्या है। कॉफीस्क्रिप्ट और जेएस (और डार्ट विरासत में मिली) में संकलित अन्य भाषाओं में से अधिकांश। मुझे लगता है कि core.async के साथ सक्रिय प्रयासों के बावजूद, क्लोजुरस्क्रिप्ट को भी यह पकड़ है

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

सब कुछ जावा में पहले से ही है

C #, वास्तव में, इस समस्या के आसपास भी पहुँच सकता है। उन्होंने रंग होना चुना । इससे पहले कि वे async-wait और यह सब Task<T> जंक जोड़े, आप बस नियमित तुल्यकालिक एपीआई कॉल का उपयोग कर सकते हैं। तीन अन्य भाषाओं में "रंग" समस्या नहीं है: गो, लुआ और रूबी।

लगता है कि वे आम में क्या है?

धाराओं। या अधिक सटीक: कई स्वतंत्र कॉल ढेर जो स्विच कर सकते हैं । ये आवश्यक रूप से ऑपरेटिंग सिस्टम के धागे नहीं हैं। गो में कोराटाइन्स, लुआ में कॉरटाइन और रूबी में धागे सभी पर्याप्त हैं।

(यही कारण है कि सी # के लिए यह थोड़ा चेतावनी है - आप धागे का उपयोग करके सी # में एसिंक्रोनस दर्द से बच सकते हैं।)

पिछले ऑपरेशन की मेमोरी

मूलभूत समस्या यह है कि "(अतुल्यकालिक) ऑपरेशन पूरा होने पर उसी स्थान से कैसे जारी रखा जाए"? आपने कॉल स्टैक के रसातल में गिर गए और फिर किसी प्रकार के आई / ओ ऑपरेशन को कॉल किया। त्वरण के लिए, यह ऑपरेशन आपके ओएस के अंतर्निहित अतुल्यकालिक एपीआई का उपयोग करता है। आप इसके पूरा होने की प्रतीक्षा नहीं कर सकते । आपको अपनी भाषा के ईवेंट लूप पर वापस लौटना चाहिए और ऑपरेशन पूरा करने के लिए OS समय देना चाहिए।

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

लेकिन अतुल्यकालिक I / O करने के लिए, आपको सी। टाइप ट्रिक -22 में पूरे कॉल स्टैक को छोड़ना चाहिए। आपके पास सुपर फास्ट I / O है, लेकिन आप परिणाम का उपयोग नहीं कर सकते हैं! हुड के तहत अतुल्यकालिक I / O वाली सभी भाषाएँ - या, JS के मामले में, ब्राउज़र ईवेंट लूप - किसी भी तरह से इस पर मजबूर हैं।

नोड, अपने हमेशा के लिए मार्चिंग कॉलबैक के साथ, इन सभी कॉल को बंद कर देता है। जब आप लिखते हैं:

 function makeSundae(callback) { scoopIceCream(function (iceCream) { warmUpCaramel(function (caramel) { callback(pourOnIceCream(iceCream, caramel)); }); }); } 

इनमें से प्रत्येक कार्यात्मक अभिव्यक्ति इसके पूरे संदर्भ को बंद कर देती है। यह कॉल स्टैक से ढेर तक, जैसे कि iceCream और caramel जैसे मापदंडों को स्थानांतरित करता है। जब कोई बाहरी फ़ंक्शन परिणाम देता है और कॉल स्टैक नष्ट हो जाता है, तो यह अच्छा है। डेटा अभी भी कहीं न कहीं ढेर पर है।

समस्या यह है कि आपको इनमें से प्रत्येक लानत कॉल को फिर से जीवित करना होगा। इस रूपांतरण के लिए एक विशेष नाम भी है: निरंतरता-गुजर शैली

लिंक भयंकर कार्यक्षमता

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

किसी ने कभी नहीं सोचा था कि एक प्रोग्रामर ऐसा कोड लिख सकता है। और फिर नोड दिखाई दिया, और अचानक हम सभी एक कंपाइलर बैकेंड लिखने का नाटक करते हैं। हमने गलत रास्ते को कहां मोड़ दिया?

ध्यान दें कि वादे और futures वास्तव में बहुत मदद नहीं करते हैं। यदि आप उनका उपयोग करते हैं, तो आप जानते हैं कि आप अभी भी कार्यात्मक अभिव्यक्तियों की विशाल परतों को जमा कर रहे हैं। आप सिर्फ अतुल्यकालिक फ़ंक्शन के बजाय उन्हें .then() पास करते हैं।

उत्पन्न समाधान की प्रतीक्षा है

Async-wait वास्तव में मदद करता है। यदि आप कंपाइलर के लिए हुड के नीचे देखते हैं जब यह await , तो आप देखेंगे कि यह वास्तव में सीपीएस रूपांतरण करता है। इसलिए आपको C # में await का उपयोग करने की आवश्यकता है - यह कंपाइलर के लिए एक संकेत है - "फ़ंक्शन को बीच में रोकें।" await बाद सब कुछ एक नया फ़ंक्शन बन जाता है जो कंपाइलर आपकी ओर से संश्लेषित करता है।

यही कारण है कि async-wait को .NET फ्रेमवर्क के अंदर रनटाइम समर्थन की आवश्यकता नहीं है। कंपाइलर इसे संबंधित क्लोजर की एक श्रृंखला में संकलित करता है, जिसे यह पहले से जानता है कि कैसे संभालना है। (दिलचस्प बात यह है कि क्लोजर को रनटाइम सपोर्ट की भी आवश्यकता नहीं होती है। वे गुमनाम कक्षाओं में संकलित किए जाते हैं। C # में क्लोजर केवल ऑब्जेक्ट होते हैं।)

आप शायद सोच रहे हैं जब मैं जनरेटर का उल्लेख करता हूं। क्या आपकी भाषा में yield है? फिर वह कुछ ऐसा ही कर सकता है।

(मेरा मानना ​​है कि जेनरेटर और एसिंक्स-वेट वास्तव में आइसोमोर्फिक हैं। कहीं-कहीं मेरी हार्ड ड्राइव के धूल भरे नुक्कड़ और क्रेन में कोड का एक टुकड़ा निहित है जो केवल एसिंक्स्ट-वेट का उपयोग करके जनरेटर पर गेम लूप को लागू करता है।)

तो मैं कहाँ हूँ? अरे हाँ। तो कॉलबैक, वादे, एसिंक्स-वेट और जनरेटर के साथ, आप अपने अतुल्यकालिक फ़ंक्शन को लेते हैं और इसे बंद करने वाले झुंड में तोड़ते हैं जो ढेर पर रहते हैं।

आपका फ़ंक्शन रनटाइम पर बाहरी कॉल करता है। जब ईवेंट लूप या I / O ऑपरेशन समाप्त हो जाता है, तो आपका फ़ंक्शन कहा जाता है और जहां यह था वहां से जारी है। लेकिन इसका मतलब यह है कि आपके फ़ंक्शन के शीर्ष पर सब कुछ भी वापस आ जाना चाहिए। आपको अभी भी पूरे स्टैक को पुनर्स्थापित करने की आवश्यकता है।

यह वह जगह है जहां से नियम आता है: "आप लाल फ़ंक्शन को केवल लाल फ़ंक्शन से कॉल कर सकते हैं"। आपको main() या ईवेंट हैंडलर को बंद करने में पूरे कॉल स्टैक को सहेजना होगा।

कॉल स्टैक कार्यान्वयन

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

गो भाषा, मेरी समझ में, यह पूरी तरह से करता है। जैसे ही आप कोई I / O ऑपरेशन करते हैं, Go इस coroutine को पार्क करेगा और किसी अन्य को जारी रखेगा जो I / O द्वारा अवरुद्ध नहीं है।

यदि आप गोलंग मानक पुस्तकालय में I / O संचालन को देखते हैं, तो वे समकालिक लगते हैं। दूसरे शब्दों में, वे बस काम करते हैं और फिर तैयार होने पर परिणाम वापस करते हैं। लेकिन इस तुल्यकालन का मतलब जावास्क्रिप्ट के समान नहीं है। Go- , IO . Go .

Go — , . , , .

, API, , . .

, , . , . , 50% .

, , , .

Javascript -, , , JS , JS , . , JS .

, ( ) — , , , async . import threading ( , AsyncIO, Twisted Tornado, ).

, , , , , , .

, Go, Go .

, , , ( - ) , "async-await ". .

, .

, , .