क्यों प्रोग्रामिंग अस्पष्ट और अस्पष्ट विचारों को व्यक्त करने का एक अच्छा तरीका है

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

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

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

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

यह समझना आसान है कि मानविकी विद्वान क्यों विचार प्रक्रिया की अस्पष्ट प्रकृति के बारे में शेख़ी पसंद करते हैं, क्योंकि मानव सोच की अनूठी प्रकृति के साथ इस तरह की अस्पष्टता के संबंध के बारे में गलत निष्कर्ष निकालना आसान है। लेकिन निष्कर्ष यहां महत्वपूर्ण नहीं है। इस चर्चा की पूरी गिरावट व्यापक विश्वास में निहित है कि एक कंप्यूटर प्रोग्राम लिखना असंभव है जो बहुत स्पष्ट रूप से परिभाषित कार्य के दायरे से परे कुछ करेगा, जो किया जाना चाहिए और इसे कैसे किया जाना चाहिए इसका एक स्पष्ट विवरण। इस विश्वास को दोनों वैज्ञानिकों (और यहां तक ​​कि "कंप्यूटर वैज्ञानिकों") और मानविकी द्वारा व्यापक रूप से बढ़ावा दिया जाता है।

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

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

, , , . 24 , ?

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

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

तर्क और प्रणाली

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

  । हर लड़का एक व्यक्ति है 
 (मैं अंडरस्टैंड)
  बुखार - हाथ का हिस्सा
 (मैं अंडरस्टैंड)
 ACH हर आदमी दो हाथों में है
 (यह प्रस्ताव UNCERTAIN। REPAIR IT है)
 ONE हर किसी के लिए दो हाथ हैं
 (मैं अंडरस्टैंड)
 Do जॉन के पास कितनी उंगलियां हैं?
 (मुझे पता नहीं है कि क्या वक्ता जॉन का एक हिस्सा है)
  जॉहन - लड़का
 (मैं अंडरस्टैंड)
 Do जॉन के पास कितनी उंगलियां हैं?
 (हाथ पर हाथ जोड़े)
 ERS हर हाथ में 5 उंगलियां
 (मैं अंडरस्टैंड)
 Do जॉन के पास कितनी उंगलियां हैं?
 (उत्तर - १०)
 H जॉनी क्या है?
 (यह प्रस्ताव UNCERTAIN। REPAIR IT है)
 ES अमेरिकी राष्ट्रपति क्या है?
 (पहचान पत्र के फार्म)
 UT केवल टेबल से ही देखें
 (G02840 - टेबल)
 (मैं अंडरस्टैंड)
 । दीपक - टेबल से बाएँ
 (G02841 - दीपक)
 (अबूझ जुदाई इम्पॉसिबल है)
 । टेबल - कुर्सी के लिए सही
 (G02842 - CHAIR)
 (मैं अंडरस्टैंड)
  RELATIVE PERSONALITY क्या है?
 (आदेश छोड़ दिया रास्ता)
 (CHAIR - BOY - TABLE) 

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

  हर हाथ 5 उंगलियों पर Y
 (मैं अंडरस्टैंड)
  एक आदमी दो हाथ है 
 (मैं अंडरस्टैंड)
  BOY - MAN 
 (मैं अंडरस्टैंड)
  TOM - BOY
 (मैं अंडरस्टैंड)
  डिक - BOY 
 (मैं अंडरस्टैंड)
  हैरी - BOY 
 (मैं अंडरस्टैंड)
  टॉम ने नौ फिंगर्स
 (यह जुडक्शन कंसेप्ट है, लेकिन मैं असूस (एचएएस) मीना (एचएएस पार्ट के रूप में)
 (मैं अंडरस्टैंड)
  डिक एक हाथ है
 (यह जुडक्शन कंसेप्ट है, लेकिन मैं असूस (एचएएस) मीना (एचएएस पार्ट के रूप में)
 (मैं अंडरस्टैंड)
 ERS HOW MUCH फिंगर्स को क्या करना है?
 (उत्तर - ९)
  कैसे बहुत कुछ करता है?
 (उत्तर - ५) 
  HOW MUCH फिंगर्स को कैसे होता है नुकसान?
 (उत्तर - १०) 
  HOW MUCH फिंगर्स को क्या करना है?
 (मुझे पता नहीं है कि क्या जॉय का पार्टर है) 

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

(1) कार्यक्रम के रूप में स्थापित किए जाने वाले निर्देशों के अनुसार।

सबसे सामान्य और सरल दृष्टिकोण: एक कंप्यूटर प्रोग्राम स्पष्ट संचालन का एक क्रम है जो कुछ डेटा के आधार पर किया जाता है। एक सरल प्रोग्राम उदाहरण लें: मान लीजिए कि एक्स एक संख्या है जिसे इनपुट जानकारी के रूप में दिया गया है:

 START: SET R = 1 LOOP: SET S = X/R SET T=R+S SET R = T/2 SET U = R x R SET V = X - U IF |V| > .001, GO TO LOOP ELSE PRINT V 

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

(2) एक पाठ्यक्रम के रूप में कार्यक्रम

राफेल के कार्यक्रम में, आपको यह तय करने की आवश्यकता है कि "x" का y "के रूप में निर्णय आने पर" शब्द "का अर्थ" मालिक "या" भाग के रूप में "है या नहीं:

   जॉहन - आदमी
 (मैं अंडरस्टैंड)
  डिक - आदमी
 (मैं अंडरस्टैंड)
  चेन - बाइक का हिस्सा
 (मैं अंडरस्टैंड)
 । चन्नसाव एक चैंन है
 (यह जुडक्शन कंसेप्ट है, लेकिन मैं असूस (एचएएस) मीना (एचएएस पार्ट के रूप में)
 (मैं अंडरस्टैंड)
 । जॉन एक चेन है 
 (मैं अंडरस्टैंड)
 A डिक एक चेयर है
 (यह जुडक्शन कंसेप्ट है, लेकिन मैं असूस (एचएएस) मीना (एचएएस पार्ट के रूप में)
 CH कच्छे का पानी निकलता है
 (यह प्रस्ताव UNCERTAIN है। इसे पूरा करें) 

कार्य, जैसे ही यह व्यक्त किया जाता है, उस कार्यक्रम के उस हिस्से में स्थानांतरित कर दिया जाता है जो पहले से पहले हुई हर चीज की समीक्षा कर सकता है। इस तरह के एक उपखंड निम्नलिखित आधार पर निर्णय लेता है:

1. क्या y किसी अन्य वस्तु का हिस्सा है? या आप किसी समूह का सदस्य हैं जो किसी चीज का हिस्सा है?
2. क्या यह ज्ञात है कि यू किसी का है या किसी समूह का सदस्य है जो किसी का है?
3. यदि प्रावधानों में से एक (1) या (2) सही है, तो उचित चुनाव करें। यदि कोई भी विकल्प फिट नहीं है, तो रोकें और अधिक जानकारी एकत्र करें। यदि दोनों कथन सत्य हैं, तो पैराग्राफ (4) के विकल्पों पर विचार करें। (इस प्रकार, कार्यक्रम इस बात के प्रमाण का उपयोग करता है कि पहले प्राप्त जानकारी को दुनिया के "मॉडल" में कैसे शामिल किया गया था।)
4. यदि आप इस बिंदु पर पहुंचते हैं, तो यू पहले से ही किसी चीज का हिस्सा है और पहले से ही किसी का है। हमें और अधिक सटीक परीक्षण की आवश्यकता है।

U1 और U2 को "कुछ" या "कुछ सिस्टम" होने दें, जो क्रमशः प्रश्नों (1) और (2) के उत्तर में मौजूद हैं। वे y पर निर्भर हैं। अब पूछें: x, U1 और U2 का सदस्य या विषय है? यदि कोई भी विकल्प फिट नहीं होता है, तो रोकें। यदि विकल्पों में से एक सही है, तो हम संबंधित परिणाम - "भाग" या "संबंधित" चुनेंगे। यदि दोनों विकल्प सही हैं, तो रोकें और अधिक जानकारी एकत्र करें। राफेल कहते हैं:

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

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

(3) सुझाव के रूप में कार्यक्रम

एक गलत धारणा है जो न केवल भयभीत मानविकी द्वारा साझा की जाती है, बल्कि अधिकांश कंप्यूटर "विशेषज्ञों" द्वारा भी साझा की जाती है; यह कहती है कि प्रोग्रामिंग अनिवार्य रूप से कार्य के लिए एक सटीक और स्पष्ट वातावरण है, जो फार्म और सामग्री के बीच एक प्राथमिक भ्रम पर आधारित है। यदि कवियों को चौदह पंक्तियों में छंद लेखन का कार्य दिया जाता, तो इससे प्रक्रिया अधिक सटीक नहीं होती; यदि संगीतकार पैमाने के सभी बारह चरणों का उपयोग करते हैं, तो यह फ़ॉर्म को संपूर्ण रूप में सीमित नहीं करेगा; यदि डिजाइनरों को केवल चौथे क्रम की सतहों का उपयोग करने की आवश्यकता होती है, तो कोई भी नोटिस नहीं करेगा! इस प्रकार, विवादों में ऐसी एकमतता का पालन करना हास्यास्पद है कि प्रक्रियाओं के विवरण में सटीकता (पुरानी) प्रोग्रामिंग भाषाओं का कठोर व्याकरण सटीकता में योगदान देता है। वास्तव में, किसी को प्रोग्राम में काम करने के लिए कंप्यूटर व्याकरण (सिंटैक्स) के नियमों का बहुत सावधानी से पालन करना चाहिए। कोई वर्तनी या विराम चिह्नों की अनुमति नहीं है! लेकिन यह कहना गलत है कि इससे आपको यह समझने में मदद मिलेगी कि आपका कार्यक्रम क्या करेगा। फोरट्रान भाषा में, यदि आप चाहते हैं कि आपका कार्यक्रम पहले से ही लिखित प्रक्रिया का उल्लेख करे, तो आपको "गो" से एक निर्धारित कमांड का उपयोग करना होगा। आप "USE" ("USE") या "GET TO" ("PROCEED ON TO") आदि नहीं कह सकते। इस मामले में वाक्य रचना बहुत सख्त है। लेकिन आप लगभग किसी भी चीज के लिए "जीओ" कर सकते हैं, इसलिए सामग्री मुक्त रहती है।

यह मान लेना और भी गलत है कि ऐसी कठोरता कंप्यूटर के कारण है! यह उन प्रोग्रामर्स के कारण है जिन्होंने भाषा को परिभाषित किया है! बोबरोव के छात्र कार्यक्रम में, यदि आप चाहें, तो एक बार और सभी के लिए "USE" ("USE") ALWAYS MEAN GO ("GO TO") दर्ज करें, और साधारण स्थितियों में आप "GO" के बजाय "USE" का उपयोग कर सकते हैं। बेशक, यह लचीलेपन का एक सरल उदाहरण है, लेकिन यह वास्तव में यह विचार है कि ज्यादातर लोग स्वीकार नहीं करते हैं: फोरट्रान भाषा की कठोरता और स्पष्टता, यदि कोई हो, सख्त पूर्वाग्रह के कारण है, और तथ्यों की कठोरता के लिए नहीं!

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

, m – -1, c – -2 (- m) (- c ), . ( .)

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

पदोन्नति के लिए एक ही समय में, "खाने" की स्थिति बनाई जाती है। यह केवल गणना और तुलना करने के लिए पर्याप्त नहीं है, क्योंकि जब सभी नरभक्षी एक बैंक में होते हैं, और मिशनरी दूसरे पर होते हैं, तो वे 3 से 0. के अनुपात में मिशनरियों की संख्या को पार कर जाते हैं, लेकिन कोई भी खाया नहीं जाता है।

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

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

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

एक्सप्रेस और सीमित आय की स्वतंत्रता

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

• मुख्य आधार: यदि मैं एक कार्यक्रम लिखता हूं, तो यह कुछ निजी करेगा, क्योंकि प्रत्येक कार्यक्रम कुछ विशिष्ट करता है।
• छोटा आधार: मेरा विचार अस्पष्ट है। मेरे सिर में कोई निश्चित परिणाम नहीं है
• निष्कर्ष: इसलिए, प्रोग्राम वह नहीं करेगा जो मैं चाहता हूं।

इसलिए, हर कोई सोचता है कि फ़र्ज़ी विचारों को कार्यक्रमों में व्यक्त नहीं किया जा सकता है।

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

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

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