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

जनवरी 1993

(यह निबंध ऑन लिस्प के परिचय से लिया गया है ।)

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

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

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

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

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

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

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

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

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

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

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

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

नई: लिस्प पर मुफ्त डाउनलोड करें ।

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