चलो एरिक लिपर्ट ने इसका उत्तर दिया:
इस बिंदु पर स्पष्ट प्रश्न है: यदि सीपीएस इतना भयानक है तो हम हर समय इसका उपयोग क्यों नहीं करते हैं? अधिकांश पेशेवर डेवलपर्स ने इसके बारे में कभी नहीं सुना है, या जिनके पास है, वे इसे केवल पागल योजना प्रोग्रामर के रूप में सोचते हैं?
सबसे पहले, यह ज्यादातर लोगों के लिए कठिन है, जो सबरूटीन्स, लूप्स, ट्राइ-कैच-एंड इत्यादि के बारे में सोचने के अभ्यस्त हैं और इस तरह से नियंत्रण प्रवाह के लिए उपयोग किए जा रहे प्रतिनिधियों के बारे में तर्क करने के लिए। मैं अभी CS442 से CPS पर अपने नोट्स की समीक्षा कर रहा हूं और मैं देखता हूं कि 1995 में मैंने एक टिप्पणी लिखी थी: "निरंतरता के साथ आपको अपने सिर पर खड़े रहना होगा और अपने आप को अंदर खींचना होगा"। प्रोफेसर दुग्गन (*) यह कहने में बिल्कुल सही थे। एक दो दिन पहले याद करें कि C # अभिव्यक्ति M (B ()? C (): D ()) के CPS परिवर्तन के हमारे छोटे छोटे उदाहरण में चार लंबो शामिल थे। हर कोई कोड पढ़ने में अच्छा नहीं है जो उच्च-क्रम के कार्यों का उपयोग करता है। यह एक बड़ा संज्ञानात्मक बोझ डालता है।
इसके अलावा: एक भाषा में बेक किए गए विशिष्ट नियंत्रण प्रवाह विवरणों के बारे में एक अच्छी बात यह है कि वे तंत्र को छिपाते हुए आपके कोड को नियंत्रण प्रवाह के अर्थ को स्पष्ट रूप से व्यक्त करते हैं - कॉल स्टैक्स और रिटर्न पते और अपवाद हैंडलर सूचियां और संरक्षित क्षेत्र और इसी तरह। निरंतरता कोड की संरचना में नियंत्रण प्रवाह के तंत्र को स्पष्ट करती है। तंत्र पर सभी जोर देने से कोड का अर्थ बढ़ सकता है ।
में अगले लेख , वह बताते हैं कि कैसे asynchrony और निरंतरता वास्तव में एक-दूसरे के बराबर हैं, और, एक साधारण लेने (लेकिन अवरुद्ध,) तुल्यकालिक नेटवर्क संचालन और asyncronous शैली में यह फिर से लिखने का एक प्रदर्शन के ऊपर जाता है, सभी छिपा कवर करने के लिए सुनिश्चित करने के गोचर जो इसे ठीक करने के लिए कवर किया जाना है। यह कोड की एक बड़ी गड़बड़ी में बदल जाता है । अंत में उनका सारांश:
पवित्र भलाई, हमने जो गॉडफुल गड़बड़ की है। हमने आपके द्वारा देखी गई सबसे अधिक पवित्र स्पेगेटी की दो दर्जन पंक्तियों में पूरी तरह से स्पष्ट कोड की दो पंक्तियों का विस्तार किया है। और निश्चित रूप से यह अभी भी संकलित नहीं है क्योंकि लेबल दायरे में नहीं हैं और हमारे पास एक निश्चित असाइनमेंट त्रुटि है। हमें, अभी भी उन समस्याओं को ठीक करने के लिए कोड को फिर से लिखना होगा।
याद रखें कि मैं सीपीएस के पेशेवरों और विपक्ष के बारे में क्या कह रहा था?
- प्रो: मनमाने ढंग से जटिल और दिलचस्प नियंत्रण प्रवाह सरल भागों से बाहर बनाया जा सकता है - जांच।
- CON: कंटीन्यू के माध्यम से कंट्रोल फ्लो का रिवीजन पढ़ना मुश्किल है और इसके बारे में तर्क करना मुश्किल है।
- कांग्रेस: कोड जो नियंत्रण प्रवाह के तंत्र का प्रतिनिधित्व करता है वह कोड - चेक के अर्थ को पूरी तरह से अभिभूत करता है।
- CON: CPS में साधारण कोड कंट्रोल फ्लो का ट्रांसफॉर्मेशन उस तरह का होता है जो कंपाइलर अच्छा होता है, और लगभग कोई और नहीं होता - चेक।
यह कोई बौद्धिक अभ्यास नहीं है। असली लोग अंत में कोड को नैतिक रूप से उपरोक्त सभी समय के बराबर लिखते हैं जब वे एसिंक्रोनस के साथ व्यवहार करते हैं। और, विडंबना यह है कि प्रोसेसर भी तेजी से और सस्ता हो गया है, हम अपना अधिक से अधिक समय उस सामान के इंतजार में बिताते हैं जो प्रोसेसर-बाउंड नहीं है। कई कार्यक्रमों में, बहुत समय व्यतीत होता है, प्रोसेसर के साथ शून्य से नेटवर्क पैकेट के इंतजार में इंग्लैंड से जापान और फिर से यात्रा करने के लिए, या फिर डिस्क के लिए, या जो भी हो।
और मैंने इस बारे में भी बात नहीं की है कि अगर आप अतुल्यकालिक संचालन को और आगे बढ़ाना चाहते हैं तो क्या होगा। मान लीजिए आप आर्काइवडक्शन को एक अतुल्यकालिक ऑपरेशन बनाना चाहते हैं जो एक प्रतिनिधि लेता है। अब इसे कॉल करने वाले सभी कोड को CPS में भी लिखना होगा। टेंट सिर्फ फैलता है।
अतुल्यकालिक तर्क प्राप्त करना महत्वपूर्ण है, यह केवल भविष्य में अधिक महत्वपूर्ण होने जा रहा है
, और जो उपकरण हमने आपको दिए हैं, वे आपको
"अपने सिर पर खड़े हों और अपने आप को अंदर बाहर करें" जैसा कि प्रोफेसर डुग्गन ने बुद्धिमानी से कहा।
कंटीन्यू पासिंग स्टाइल शक्तिशाली है, हां, लेकिन ऊपर दिए गए कोड की तुलना में उस शक्ति का अच्छा उपयोग करने का एक बेहतर तरीका है।
दोनों लेख, और एक नई C # भाषा सुविधा पर निम्न श्रंखला जो संकलक में इस सारी गड़बड़ी को आगे बढ़ाती है और आपको अपने कोड को एक विशेष कीवर्ड के साथ सामान्य नियंत्रण प्रवाह के रूप में लिखने की सुविधा देती है, जो कुछ खास हिस्सों को अतुल्यकालिक के रूप में चिह्नित करता है, भले ही आप पढ़ने लायक हों। ' फिर से एक सी # डेवलपर नहीं। मैं नहीं हूं, लेकिन जब मैं पहली बार इसके पार गया था तब भी यह काफी ज्ञानवर्धक अनुभव था।