प्रोग्रामिंग बॉटम-अप

जनवरी 1993

(यह निबंध On Lisp के परिचय से लिया गया है.)

प्रोग्रामिंग शैली का एक लंबे समय से चला आ रहा सिद्धांत यह है कि किसी प्रोग्राम के कार्यात्मक तत्व बहुत बड़े नहीं होने चाहिए. यदि किसी प्रोग्राम का कोई घटक उस स्तर से बड़ा हो जाता है जहां वह आसानी से समझ में आता है, तो वह जटिलता का एक गुच्छा बन जाता है जो गलतियों को छिपाने में उतना ही सक्षम होता है जितना कि एक बड़ा शहर भगोड़ों को छिपाने में. ऐसा सॉफ्टवेयर पढ़ना, परीक्षण करना और डीबग करना मुश्किल होगा.

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

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

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

सामान्य कोड में, एक बार जब आप उन भागों को अमूर्त कर लेते हैं जो केवल लेखा-जोखा हैं, तो जो बचता है वह बहुत छोटा होता है; आप जितना ऊपर भाषा को बनाते हैं, उतना ही कम दूरी तक शीर्ष से नीचे तक जाना होगा. इससे कई लाभ होते हैं:

भाषा को अधिक काम करने के लिए बनाकर, नीचे-ऊपर डिजाइन ऐसे प्रोग्राम देता है जो छोटे और अधिक गतिशील होते हैं. एक छोटा प्रोग्राम इतने सारे घटकों में विभाजित नहीं होना चाहिए, और कम घटक होने से प्रोग्राम पढ़ना या संशोधित करना आसान होता है. कम घटक होने से घटकों के बीच कम कनेक्शन होते हैं, और इसलिए वहां गलतियों का कम खतरा होता है. जैसे औद्योगिक डिजाइनर मशीन में गतिशील भागों की संख्या कम करने का प्रयास करते हैं, वैसे ही अनुभवी Lisp प्रोग्रामर नीचे-ऊपर डिजाइन का उपयोग करके अपने प्रोग्रामों की आकार और जटिलता को कम करते हैं.

नीचे-ऊपर डिजाइन कोड पुनः उपयोग को बढ़ावा देता है. जब आप दो या अधिक प्रोग्राम लिखते हैं, तो पहले प्रोग्राम के लिए लिखे गए कई उपयोगी यूटिलिटी अगले प्रोग्रामों में भी उपयोगी होंगे. एक बार जब आप एक बड़ा उपकरण सब्स्ट्रेट प्राप्त कर लेते हैं, तो एक नया प्रोग्राम लिखना उस प्रयास का केवल एक छोटा हिस्सा होगा जो कि आपको कच्चे Lisp से शुरू करने पर होता.

नीचे-ऊपर डिजाइन प्रोग्रामों को पढ़ना आसान बनाता है.

इस प्रकार के अमूर्तीकरण का एक उदाहरण पाठक को एक सामान्य-उद्देश्य ऑपरेटर समझने के लिए कहता है; कार्यात्मक अमूर्तीकरण का एक उदाहरण पाठक को एक विशेष-उद्देश्य सबरूटीन समझने के लिए कहता है. [1]

क्योंकि यह आपको हमेशा अपने कोड में पैटर्न की तलाश करने के लिए प्रेरित करता है, नीचे-ऊपर काम करना आपके प्रोग्राम की डिजाइन के बारे में अपने विचारों को स्पष्ट करने में मदद करता है. यदि प्रोग्राम के दो दूरस्थ घटक समान रूप से हैं, तो आप इस समानता को देखने और शायद प्रोग्राम को एक सरल तरीके से पुनः डिजाइन करने के लिए प्रेरित होंगे.

नीचे-ऊपर डिजाइन Lisp के अलावा अन्य भाषाओं में भी एक हद तक संभव है. जब भी आप लाइब्रेरी फ़ंक्शन देखते हैं, तो नीचे-ऊपर डिजाइन हो रहा है. हालांकि, Lisp आपको इस क्षेत्र में कहीं अधिक व्यापक शक्तियां देता है, और भाषा को बढ़ाना Lisp शैली में एक अनुपातिक रूप से बड़ा हिस्सा बन जाता है - इतना कि Lisp केवल एक अलग भाषा नहीं है, बल्कि प्रोग्रामिंग का एक पूरा अलग तरीका है.

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

नया: On Lisp को मुफ्त में डाउनलोड करें.

[1] "लेकिन कोई भी व्यक्ति आपके सभी नए यूटिलिटी को समझे बिना प्रोग्राम नहीं पढ़ सकता." इस तरह के कथनों के गलत होने का कारण देखने के लिए, देखें अनुभाग 4.8.