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

जनवरी 1993

(यह निबंधOn Lisp* के परिचय से है।)*

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

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

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

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

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

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

बॉटम-अप डिज़ाइन कोड पुन: उपयोग को बढ़ावा देता है। जब आप दो या अधिक प्रोग्राम लिखते हैं, तो पहले प्रोग्राम के लिए आपने जो कई उपयोगिताएँ लिखी हैं, वे अगली प्रोग्रामों में भी उपयोगी होंगी। एक बार जब आपने उपयोगिताओं का एक बड़ा आधार प्राप्त कर लिया, तो एक नया प्रोग्राम लिखने में केवल एक अंश का प्रयास लग सकता है जो आपको कच्चे लिस्प से शुरू करने की आवश्यकता होती।

बॉटम-अप डिज़ाइन प्रोग्रामों को पढ़ने में आसान बनाता है।

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

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

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

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

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

[1] "लेकिन कोई भी आपके सभी नए उपयोगिताओं को समझे बिना प्रोग्राम नहीं पढ़ सकता।" ऐसे बयानों के गलत होने का कारण देखने के लिए, अनुभाग 4.8 देखें।