ट्यूरिंग दलदल

ट्यूरिंग दलदल से डरें जिसमें सब कुछ संभव है, लेकिन कुछ भी ठोस नहीं किया जा सकता है ।
एलन पर्लिस

ट्यूरिंग दलदल क्या है? यह वह स्थिति है जिसमें प्रोग्राम इतना शक्तिशाली हो जाता है, इतना सामान्यीकृत होता है कि इसके साथ किसी भी विशिष्ट समस्या को हल करने के प्रयास स्क्रैच से लिखने की लागत के बराबर या अधिक होते हैं जो केवल इस समस्या को हल करता है।

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

मुझे लगता है कि प्रोग्रामिंग भाषा को ज्यादातर स्व-परिभाषित होना चाहिए। भाषा विनिर्देश को 2 भागों में विभाजित किया जाना चाहिए: ऑपरेटरों का एक छोटा कर्नेल (जो स्वयंसिद्धों की भूमिका निभाता है) और शेष भाषा, जो प्रमेयों की तरह है, को स्वयंसिद्ध शब्दों के रूप में परिभाषित किया गया है।
पॉल ग्राहम

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

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

प्रोग्रामिंग में, हम जो कुछ भी करते हैं वह एक सामान्य समस्या का एक विशेष मामला है। और कभी-कभी हमें इसका अहसास भी जल्दी हो जाता है ।
एलन पर्लिस

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

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

क्या आपको यकीन है कि ये सभी सीटी और चालें, ये सभी रमणीय उपकरण जो आपकी "शक्तिशाली प्रोग्रामिंग भाषा" बनाते हैं, वास्तव में समस्या के समाधान का हिस्सा हैं, और समस्या का हिस्सा नहीं हैं?
एद्जर दीक्जस्त्र

अनुवादक टिप्पणी

ट्यूरिंग दलदल वास्तव में यह लगता है की तुलना में अधिक आम है। और यह केवल महान अकादमिक दिमाग में खींचना ठीक होगा जो एक सार्वभौमिक पैमाने की समस्याओं को हल करता है। लेकिन नहीं - सार्वभौमिक उपकरण सब कुछ बनाने की कोशिश करते हैं! किसी कारण से, प्रत्येक डीवीडी जलने के कार्यक्रम का अपना ऑडियो / वीडियो / फोटो संपादक, कवर कला उपकरण, खिलाड़ी और कन्वर्टर्स हैं। प्रत्येक संदेशवाहक सभी संभावित संचार प्रोटोकॉल का समर्थन करने के लिए प्रतिबद्ध है, जिसमें ई-मेल, सोशल नेटवर्क, एसएमएस, पेपर पत्र और अलौकिक सभ्यताओं को संदेश भेजना शामिल है। सभी ओएस सभी प्रकार के उपकरणों पर चढ़ते हैं, प्रत्येक कोडेक पैक में एक टन कबाड़ शामिल होता है, कुछ कंसोल कार्यक्रमों के लिए प्रलेखन में 150 ए 4 पृष्ठ और कुछ हजार कमांड लाइन कुंजी होती हैं। इंटरनेट पर हर दूसरी साइट मौसम की कुंडली से घिरी हुई है, \ डेटिंग \ काम \ चैट \ मंचों। नई सुविधाओं, कार्यक्रमों और साइटों के एक अतिरिक्त उपयोगकर्ता को आकर्षित करने की कोशिश करते हुए एक दर्जन से अधिक लोग खो जाते हैं, जो तर्कसंगत कर्नेल की तलाश करने में हिचकिचाते हैं, जिसके लिए यह कार्यक्रम या साइट कभी बकवास के ढेर में चुना गया था।

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