सिद्धांत-निर्माण के रूप में प्रोग्रामिंग (1985)

• Peter Naur का "Programming as Theory Building" प्रोग्रामिंग को प्रोग्राम टेक्स्ट बनाने की गतिविधि नहीं, बल्कि प्रोग्रामर द्वारा समस्या और उसके समाधान के बारे में एक सिद्धांत बनाने की गतिविधि मानता है।
• यहाँ "सिद्धांत" का मतलब केवल कोई अमूर्त प्रतिज्ञप्ति या दस्तावेजीकृत डिज़ाइन विवरण नहीं है।
  • वास्तविक दुनिया की समस्या का अर्थ क्या है, इसे समझना
  • यह समझा पाना कि प्रोग्राम की संरचना उस वास्तविकता से कैसे मेल खाती है
  • यह उचित ठहरा पाना कि डिज़ाइन ऐसा क्यों किया गया
  • और जब नई requirements आएँ, तो यह निर्णय कर पाना कि उन्हें मौजूदा संरचना में कैसे जोड़ा जाए
• इसलिए प्रोग्राम का मुख्य ज्ञान कोड या दस्तावेज़ों में पूरी तरह समाहित नहीं होता, बल्कि उस प्रोग्राम को समझने वाले प्रोग्रामर के दिमाग में होता है।

प्रोग्रामिंग और ज्ञान

• Naur प्रोग्रामिंग को वास्तविक दुनिया की गतिविधियों को ऐसे औपचारिक symbolic manipulations से मैप करने की गतिविधि मानते हैं जिन्हें कंप्यूटर कर सके।
• इस दृष्टिकोण में प्रोग्राम का modification भी प्रोग्रामिंग का हिस्सा है।
  • क्योंकि अगर वास्तविक दुनिया की गतिविधियाँ बदलती हैं, तो प्रोग्राम को भी बदलना पड़ता है।
• प्रोग्रामिंग का सार दस्तावेज़ या कोड जैसे deliverables नहीं, बल्कि वह विशिष्ट ज्ञान है जो प्रोग्रामर बनाते और संचित करते हैं।
• दस्तावेज़ महत्वपूर्ण हैं, लेकिन सहायक भूमिका में।
  • दस्तावेज़ सिद्धांत का पूरा विकल्प नहीं बन सकते।
  • वे सिद्धांत-निर्माण में मदद करने वाले औज़ार के अधिक निकट हैं।

उदाहरण 1: कंपाइलर का हस्तांतरण और विफलता

• समूह A ने भाषा L के लिए एक compiler बनाया।
• समूह B को विस्तारित भाषा L + M के लिए compiler बनाने हेतु A का compiler code, दस्तावेज़ और सलाह दी गई।
• कोड और दस्तावेज़ पर्याप्त मात्रा में दिए गए थे, लेकिन B कुछ डिज़ाइनों में मौजूदा संरचना की ताकत का उपयोग नहीं कर पाया और patch-जैसे समाधान सुझाए।
• A ने तुरंत समस्या पहचान ली और मौजूदा संरचना के भीतर एक अधिक सरल और स्वाभाविक समाधान प्रस्तुत किया।
• इस उदाहरण का सार:
  • केवल प्रोग्राम टेक्स्ट और दस्तावेज़ों से डिज़ाइन का गहरा सिद्धांत हस्तांतरित नहीं होता।
  • मौजूदा डिज़ाइन का "क्यों" और "इसे कैसे बढ़ाया जाना चाहिए" केवल दस्तावेज़ों से पर्याप्त रूप से नहीं पहुँचता।
• बाद में, A के मार्गदर्शन के बिना अन्य प्रोग्रामरों ने compiler में बदलाव किए, और मूल मजबूत संरचना धीरे-धीरे बेआकार additions से कमजोर होती गई।
• यह दिखाता है कि प्रोग्राम टेक्स्ट और दस्तावेज़ मुख्य डिज़ाइन सिद्धांत को संरक्षित रखने में सीमित हैं।

उदाहरण 2: बड़े पैमाने का real-time सिस्टम

• लगभग 2 लाख lines का एक industrial real-time सिस्टम उदाहरण के रूप में दिया गया है।
• installation और fault diagnosis संभालने वाले प्रोग्रामर, सिस्टम डिज़ाइन के शुरुआती चरण से लंबे समय तक उससे निकटता से जुड़े रहे थे।
• वे faults का निदान करते समय मुख्यतः अपनी तत्काल सिस्टम-समझ और comments वाले code पर निर्भर करते थे।
• दूसरी ओर, दस्तावेज़ और प्रशिक्षण पाने वाले बाहरी operations programmers बार-बार कठिनाइयों में फँसते रहे।
• निर्माता कंपनी के अनुभवी प्रोग्रामरों ने उन समस्याओं को आसानी से हल कर दिया।
• निष्कर्ष:
  • बड़े प्रोग्रामों का maintenance और modification मूलतः उन लोगों के ज्ञान पर निर्भर करता है जो लंबे समय तक उस प्रोग्राम से जुड़े रहे हों।
  • केवल दस्तावेजीकृत विवरण उस ज्ञान का पूरा विकल्प नहीं बन सकता।

Ryle की "सिद्धांत" की अवधारणा

• Naur, Gilbert Ryle की theory की अवधारणा को अपनाते हैं।
• सिद्धांत होना केवल कुछ propositions जान लेना नहीं है।
  • किसी काम को करना जानना
  • उस काम को समझा पाना
  • प्रश्नों का उत्तर दे पाना
  • और अपने निर्णय को उचित ठहरा पाना
• बुद्धिमान गतिविधि को अनिवार्य रूप से नियम-पालन वाली गतिविधि में सीमित नहीं किया जा सकता।
  • क्योंकि नियमों का पालन करना भी स्वयं बुद्धिमत्ता से किया जाना चाहिए।
  • और यदि नियमों का पालन कैसे करना है, इसके लिए फिर किसी और नियम की ज़रूरत मानी जाए, तो अनंत प्रतिगमन होगा।
• इसलिए बौद्धिक गतिविधि केवल नियमों का निष्पादन नहीं, बल्कि परिस्थितियों के बीच समानता पहचानने और उचित प्रतिक्रिया देने की क्षमता भी है।

सिद्धांत को पूरी तरह नियमों में व्यक्त नहीं किया जा सकता

• जिस व्यक्ति के पास कोई सिद्धांत होता है, वह वास्तविक दुनिया की विभिन्न परिस्थितियों के बीच अर्थपूर्ण समानताएँ पहचानता है।
• लेकिन ऐसी समानताओं को स्पष्ट मानदंडों या नियमों में पूरी तरह व्यक्त करना कठिन होता है।
• उदाहरण:
  • चेहरों की समानता
  • धुनों की समानता
  • वाइन के स्वाद की समानता
• इसी तरह प्रोग्रामिंग में भी, कोई नई requirement मौजूदा संरचना से कैसे मिलती-जुलती है, और उसे कहाँ integrate करना चाहिए, इसे साधारण नियमों में सीमित करना कठिन है।
• यही implicit knowledge का मूल है।

प्रोग्रामर के पास कैसा सिद्धांत होना चाहिए

• किसी प्रोग्राम का सिद्धांत रखने वाला प्रोग्रामर निम्न काम कर सके, यह आवश्यक है।

1. वास्तविक दुनिया और प्रोग्राम के correspondence को समझा सके

• वह यह समझा सके कि प्रोग्राम का प्रत्येक भाग वास्तविक दुनिया की किन गतिविधियों या अवधारणाओं से मेल खाता है।
• उल्टा भी, वह यह समझा सके कि वास्तविक दुनिया की कोई गतिविधि प्रोग्राम में कैसे व्यक्त होती है।
• क्या प्रासंगिक है और क्या अप्रासंगिक, इसका निर्णय करने के लिए वास्तविक दुनिया की समग्र समझ चाहिए।

2. यह उचित ठहरा सके कि प्रोग्राम ऐसा क्यों है

• वह यह बता सके कि प्रोग्राम की संरचना और implementation details को उस तरह क्यों डिज़ाइन किया गया।
• इस justification में rules, reasoning, design principles, quantitative estimates आदि का उपयोग हो सकता है।
• लेकिन अंततः किस principle को लागू करना है, इसका निर्णय प्रोग्रामर की प्रत्यक्ष अंतर्दृष्टि पर निर्भर करता है।

3. नई modification requirements पर रचनात्मक प्रतिक्रिया दे सके

• वह पहचान सके कि नई requirement मौजूदा प्रोग्राम की किस functionality या structure से मिलती-जुलती है।
• उस समानता के आधार पर वह modification को इस तरह डिज़ाइन कर सके कि वह मौजूदा सिद्धांत में स्वाभाविक रूप से समाहित हो जाए।
• इस क्षमता का स्थान केवल documented procedures नहीं ले सकते।

प्रोग्राम modification और लागत

• software में बदलाव होना अपरिहार्य है।
  • उपयोग के दौरान नई requirements आती हैं
  • और वास्तविक दुनिया की स्थितियाँ भी बदलती हैं।
• आम तौर पर माना जाता है कि मौजूदा प्रोग्राम को modify करना, नया बनाने से सस्ता होता है।
• लेकिन Naur के दृष्टिकोण से यह अपेक्षा हमेशा सही नहीं होती।
• प्रोग्राम modification की लागत केवल टेक्स्ट edit करने की लागत नहीं है।
  • मुख्य लागत मौजूदा प्रोग्राम के सिद्धांत को समझने में लगती है
  • और नई requirement को उस सिद्धांत में integrate करने में लगती है।
• इसलिए सिर्फ यह कि कोड आसानी से edit होने वाला text है, यह नहीं बताता कि modification आसान होगा।

flexibility की सीमाएँ

• यह तर्क कि प्रोग्राम में भविष्य के बदलावों के लिए पहले से flexibility डाल दी जाए, केवल आंशिक रूप से सही है।
• flexibility मुफ़्त नहीं आती।
  • यह तय करना पड़ता है कि किन संभावित भविष्य स्थितियों की तैयारी करनी है
  • parameters और structures डिज़ाइन करने पड़ते हैं
  • implementation, testing और explanation की लागत लगती है।
• इसकी उपयोगिता अनिश्चित भविष्य की घटनाओं पर निर्भर करती है।
• इसलिए flexibility, बदलावों से निपटने का सामान्य समाधान नहीं बन सकती।
• महत्वपूर्ण यह नहीं कि हर संभावित बदलाव के लिए पहले से structure डाल दिया जाए, बल्कि यह कि बदलाव आने पर प्रोग्राम के सिद्धांत के आधार पर उचित निर्णय लिया जा सके।

अच्छा modification और बुरा modification

• एक ही बाहरी behavior को संतुष्ट करने वाले modifications कई तरीकों से implement किए जा सकते हैं।
• सतह पर वे सभी सही दिख सकते हैं।
• लेकिन प्रोग्राम के सिद्धांत के दृष्टिकोण से उनमें बड़ा अंतर होता है।
  • कुछ modifications मौजूदा सिद्धांत का स्वाभाविक विस्तार होते हैं।
  • कुछ modifications मौजूदा संरचना पर चिपकाए गए patch की तरह काम करते हैं।
• यदि दूसरे प्रकार के modifications बार-बार हों, तो प्रोग्राम धीरे-धीरे रजाई-जोड़ संरचना बन जाता है।
• प्रोग्राम की दीर्घकालिक जीवंतता इस बात पर निर्भर करती है कि हर modification मौजूदा सिद्धांत में कितनी अच्छी तरह जड़ पकड़ता है।

प्रोग्राम का जीवन, मृत्यु और पुनर्जीवन

प्रोग्राम का जीवन

• जब प्रोग्राम का सिद्धांत रखने वाले प्रोग्रामर अभी भी उसे सक्रिय रूप से नियंत्रित कर रहे हों, तब प्रोग्राम जीवित है।
• वे modification requests पर बौद्धिक रूप से प्रतिक्रिया दे सकते हैं।

प्रोग्राम की मृत्यु

• जब प्रोग्राम का सिद्धांत रखने वाली टीम बिखर जाती है, तब प्रोग्राम मर जाता है।
• मरा हुआ प्रोग्राम फिर भी चल सकता है और उपयोगी परिणाम दे सकता है।
• लेकिन जब वह modification requests का ठीक से सामना नहीं कर पाता, तब उसकी मृत्यु स्पष्ट होती है।

प्रोग्राम का पुनर्जीवन

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

methodology की आलोचना

• Naur प्रोग्रामिंग methodologies को "ऐसे नियमों के संग्रह" के रूप में देखते हैं जो बताते हैं कि प्रोग्रामर किस क्रम में कौन-सा काम करे।
• सिद्धांत-निर्माण के दृष्टिकोण से इस अर्थ की methodology, प्रोग्रामिंग के सार को पकड़ नहीं पाती।
• कारण:
  • सिद्धांत-निर्माण का कोई तय क्रम नहीं होता।
  • सिद्धांत मूलतः भागों का रैखिक संयोजन नहीं है।
  • notation या document format सिद्धांत-निर्माण में मदद कर सकते हैं, लेकिन वे स्वयं सिद्धांत नहीं हैं।
• इसलिए निष्कर्ष निकलता है कि प्रोग्रामिंग की प्राथमिक गतिविधि के लिए कोई सार्वभौमिक रूप से सही method नहीं है।

इसका मतलब यह नहीं कि methodology पूरी तरह निरर्थक है

• Naur जिस चीज़ को अस्वीकार करते हैं, वह methodology को ऐसी प्रक्रिया मानना है जो यांत्रिक रूप से अच्छे डिज़ाइन की गारंटी दे।
• methodology, design techniques, notation और verification techniques का शैक्षिक मूल्य हो सकता है।
• अच्छे examples, structured principles और verification techniques से परिचित प्रोग्रामर बेहतर सिद्धांत बनाने की अधिक संभावना रखते हैं।
• लेकिन किस technique को कब और किस क्रम में लागू करना है, यह निर्णय उस प्रोग्रामर के विवेक पर छोड़ा जाना चाहिए जो वास्तविक समस्या को समझता हो।

प्रोग्रामर की स्थिति

• यदि प्रोग्रामिंग को औद्योगिक उत्पादन की तरह देखा जाए, तो प्रोग्रामर को आसानी से बदले जा सकने वाले पुर्ज़े की तरह माना जाता है।
• यह वह दृष्टिकोण है जिसमें माना जाता है कि procedures और rules का पालन कर कोई भी वही परिणाम दे सकता है।
• Naur इस दृष्टिकोण को अस्वीकार करते हैं।
• यदि प्रोग्राम का मुख्य output वह सिद्धांत है जो प्रोग्रामर के पास होता है, तो प्रोग्रामर आसानी से बदले जा सकने वाला श्रमिक नहीं है।
• प्रोग्रामर उस समूची गतिविधि को ज़िम्मेदारी से विकसित और प्रबंधित करने वाले पेशेवर के अधिक निकट है जिसमें कंप्यूटर शामिल है।
• इसलिए प्रोग्रामर को स्थायी status और responsibility मिलनी चाहिए।
• शिक्षा भी केवल syntax, notation और data processing skills से आगे बढ़कर सिद्धांत-निर्माण की क्षमता विकसित करने वाली होनी चाहिए।

XP के metaphor और सिद्धांत-निर्माण

• XP का "metaphor" Naur के सिद्धांत-निर्माण दृष्टिकोण से अच्छी तरह समझा जा सकता है।
• एक अच्छा metaphor टीम को प्रोग्राम की संरचना के बारे में मिलते-जुलते अनुमान लगाने में मदद करता है।
• उदाहरण:
  • प्रोग्राम को "assembly line" के रूप में समझना
  • प्रोग्राम को "restaurant" के रूप में समझना
• अच्छा metaphor केवल साधारण उपमा नहीं होता।
  • यह डिज़ाइनरों को यह समझने में मदद करता है कि किस तरह की संरचना की अपेक्षा करनी चाहिए
  • नया code कहाँ जोड़ा जाना चाहिए
  • और दूसरे लोगों द्वारा लिखे गए code के साथ उसे कैसे फिट होना चाहिए
• जितने अधिक टीम सदस्य हों और जितना अधिक parallel work हो, साझा metaphor का महत्व उतना बढ़ता है।
• यदि साझा सिद्धांत न हो, तो हर प्रोग्रामर अपना अलग सिद्धांत बना लेता है, और सिस्टम धीरे-धीरे असंगत और जटिल होता जाता है।

दस्तावेज़ीकरण की भूमिका

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

अच्छे डिज़ाइन दस्तावेज़ की संरचना

• अनुभवी डिज़ाइनर आम तौर पर दस्तावेज़ की शुरुआत निम्न चीज़ों से करते हैं।
  • मुख्य metaphor
  • प्रमुख components के उद्देश्य का विवरण
  • प्रमुख components के बीच मुख्य interactions का चित्र
• ये तीनों चीज़ें अगली टीम को डिज़ाइन-सिद्धांत बनाने में बहुत मदद करती हैं।
• source code स्वयं भी सिद्धांत पहुँचाने का एक माध्यम है।
  • consistent naming
  • simple structure
  • predictable patterns
  • अनावश्यक exceptions को न्यूनतम रखना
• "clean code" का बड़ा हिस्सा इस बात से जुड़ा है कि पाठक सिस्टम के बारे में एक सुसंगत सिद्धांत कितनी आसानी से बना सकता है।