प्रोग्रामिंग बॉटम-अप
1993
(यह निबंध On Lisp के परिचय से है।)
प्रोग्रामिंग शैली का एक लंबे समय से चला आ रहा सिद्धांत यह है कि प्रोग्राम के कार्यात्मक तत्वों को बहुत बड़ा नहीं होना चाहिए। यदि किसी प्रोग्राम का कोई घटक उस चरण से आगे बढ़ जाता है जहाँ वह आसानी से समझने योग्य है, तो वह जटिलता का एक ऐसा ढेर बन जाता है जो एक बड़े शहर की तरह भगोड़ों को आसानी से छिपा सकता है। ऐसे सॉफ़्टवेयर को पढ़ना, परीक्षण करना और डीबग करना कठिन होगा।
इस सिद्धांत के अनुसार, एक बड़े प्रोग्राम को टुकड़ों में विभाजित किया जाना चाहिए, और प्रोग्राम जितना बड़ा होगा, उसे उतना ही अधिक विभाजित किया जाना चाहिए। आप एक प्रोग्राम को कैसे विभाजित करते हैं? पारंपरिक दृष्टिकोण को टॉप-डाउन डिज़ाइन कहा जाता है: आप कहते हैं कि "प्रोग्राम का उद्देश्य इन सात चीजों को करना है, इसलिए मैं इसे सात प्रमुख सब रूटीन में विभाजित करता हूँ। पहले सब रूटीन को इन चार चीजों को करना है, इसलिए यह बदले में अपने चार सब रूटीन का उपयोग करेगा," और इसी तरह। यह प्रक्रिया तब तक जारी रहती है जब तक कि पूरे प्रोग्राम में उचित स्तर की ग्रैन्युलैरिटी न हो - प्रत्येक भाग कुछ महत्वपूर्ण करने के लिए पर्याप्त बड़ा हो, लेकिन एक इकाई के रूप में समझने के लिए पर्याप्त छोटा हो।
अनुभवी लिस्प प्रोग्रामर अपने प्रोग्राम को अलग तरह से विभाजित करते हैं। टॉप-डाउन डिज़ाइन के अलावा, वे एक सिद्धांत का पालन करते हैं जिसे बॉटम-अप डिज़ाइन कहा जा सकता है - समस्या के अनुरूप भाषा को बदलना। लिस्प में, आप केवल अपने प्रोग्राम को भाषा की ओर नीचे नहीं लिखते हैं, आप भाषा को अपने प्रोग्राम की ओर ऊपर भी बनाते हैं। जैसे-जैसे आप एक प्रोग्राम लिख रहे होते हैं, आपको लग सकता है "काश लिस्प में ऐसा-और-ऐसा ऑपरेटर होता।" तो आप उसे जाकर लिखते हैं। बाद में आपको एहसास होता है कि नए ऑपरेटर का उपयोग करने से प्रोग्राम के दूसरे हिस्से का डिज़ाइन सरल हो जाएगा, और इसी तरह। भाषा और प्रोग्राम एक साथ विकसित होते हैं। दो युद्धरत राज्यों के बीच की सीमा की तरह, भाषा और प्रोग्राम के बीच की सीमा खींची जाती है और फिर से खींची जाती है, जब तक कि अंततः यह आपके समस्या की प्राकृतिक सीमाओं, पहाड़ों और नदियों के साथ आराम न कर ले। अंत में आपका प्रोग्राम ऐसा दिखेगा जैसे भाषा उसके लिए डिज़ाइन की गई हो। और जब भाषा और प्रोग्राम एक-दूसरे के साथ अच्छी तरह से फिट होते हैं, तो आपको स्पष्ट, छोटा और कुशल कोड मिलता है।
यह जोर देने योग्य है कि बॉटम-अप डिज़ाइन का मतलब सिर्फ एक ही प्रोग्राम को अलग क्रम में लिखना नहीं है। जब आप बॉटम-अप काम करते हैं, तो आपको आमतौर पर एक अलग प्रोग्राम मिलता है। एक एकल, मोनोलिथिक प्रोग्राम के बजाय, आपको अधिक अमूर्त ऑपरेटरों वाली एक बड़ी भाषा मिलेगी, और उसमें लिखा गया एक छोटा प्रोग्राम। एक लिंटेल के बजाय, आपको एक मेहराब मिलेगा।
विशिष्ट कोड में, एक बार जब आप केवल हिसाब-किताब वाले हिस्सों को अमूर्त कर देते हैं, तो जो बचता है वह बहुत छोटा होता है; आप भाषा को जितना ऊँचा बनाते हैं, आपको ऊपर से नीचे तक उतनी ही कम दूरी तय करनी पड़ेगी। इससे कई फायदे होते हैं:
-
भाषा से अधिक काम करवाकर, बॉटम-अप डिज़ाइन ऐसे प्रोग्राम बनाता है जो छोटे और अधिक फुर्तीले होते हैं। एक छोटे प्रोग्राम को इतने सारे घटकों में विभाजित करने की आवश्यकता नहीं होती है, और कम घटकों का मतलब है कि प्रोग्राम को पढ़ना या संशोधित करना आसान होता है। कम घटकों का मतलब है घटकों के बीच कम कनेक्शन, और इस प्रकार वहां त्रुटियों की संभावना कम होती है। जैसे औद्योगिक डिजाइनर किसी मशीन में चलने वाले पुर्जों की संख्या कम करने का प्रयास करते हैं, वैसे ही अनुभवी लिस्प प्रोग्रामर अपने प्रोग्राम के आकार और जटिलता को कम करने के लिए बॉटम-अप डिज़ाइन का उपयोग करते हैं।
-
बॉटम-अप डिज़ाइन कोड के पुन: उपयोग को बढ़ावा देता है। जब आप दो या दो से अधिक प्रोग्राम लिखते हैं, तो पहले प्रोग्राम के लिए आपके द्वारा लिखे गए कई उपयोगिताएँ बाद के प्रोग्रामों में भी उपयोगी होंगी। एक बार जब आप उपयोगिताओं का एक बड़ा आधार प्राप्त कर लेते हैं, तो एक नया प्रोग्राम लिखना कच्चे लिस्प से शुरू करने की तुलना में केवल एक अंश प्रयास में हो सकता है।
-
बॉटम-अप डिज़ाइन प्रोग्राम को पढ़ना आसान बनाता है। इस प्रकार के अमूर्तता का एक उदाहरण पाठक से एक सामान्य-उद्देश्य ऑपरेटर को समझने के लिए कहता है; कार्यात्मक अमूर्तता का एक उदाहरण पाठक से एक विशेष-उद्देश्य सब रूटीन को समझने के लिए कहता है। [1]
-
क्योंकि यह आपको हमेशा अपने कोड में पैटर्न की तलाश में रखता है, बॉटम-अप काम करने से आपके प्रोग्राम के डिज़ाइन के बारे में आपके विचारों को स्पष्ट करने में मदद मिलती है। यदि किसी प्रोग्राम के दो दूरस्थ घटक रूप में समान हैं, तो आपको समानता को नोटिस करने और शायद प्रोग्राम को सरल तरीके से फिर से डिज़ाइन करने के लिए प्रेरित किया जाएगा।
बॉटम-अप डिज़ाइन लिस्प के अलावा अन्य भाषाओं में भी कुछ हद तक संभव है। जब भी आप लाइब्रेरी फ़ंक्शन देखते हैं, तो बॉटम-अप डिज़ाइन हो रहा होता है। हालाँकि, लिस्प आपको इस विभाग में बहुत व्यापक शक्तियाँ देता है, और भाषा को बढ़ाना लिस्प शैली में आनुपातिक रूप से एक बड़ी भूमिका निभाता है - इतना अधिक कि लिस्प सिर्फ एक अलग भाषा नहीं है, बल्कि प्रोग्रामिंग का एक पूरा अलग तरीका है।
यह सच है कि विकास की यह शैली छोटे समूहों द्वारा लिखे जा सकने वाले प्रोग्रामों के लिए बेहतर अनुकूल है। हालाँकि, साथ ही, यह छोटे समूह द्वारा किए जा सकने वाले काम की सीमाओं का विस्तार करता है। The Mythical Man-Month में, फ्रेडरिक ब्रूक्स ने प्रस्तावित किया कि प्रोग्रामर के समूह की उत्पादकता उसके आकार के साथ रैखिक रूप से नहीं बढ़ती है। जैसे-जैसे समूह का आकार बढ़ता है, व्यक्तिगत प्रोग्रामर की उत्पादकता कम होती जाती है। लिस्प प्रोग्रामिंग का अनुभव इस कानून को व्यक्त करने का एक अधिक खुशनुमा तरीका बताता है: जैसे-जैसे समूह का आकार घटता है, व्यक्तिगत प्रोग्रामर की उत्पादकता बढ़ती है। एक छोटा समूह, अपेक्षाकृत बोलें, इसलिए जीतता है क्योंकि वह छोटा होता है। जब एक छोटा समूह लिस्प द्वारा संभव की गई तकनीकों का भी लाभ उठाता है, तो वह जीत सकता है।
नया: On Lisp मुफ्त में डाउनलोड करें.
[1] "लेकिन कोई भी आपके सभी नए उपयोगिताओं को समझे बिना प्रोग्राम को नहीं पढ़ सकता है।" ऐसे बयान आमतौर पर गलत क्यों होते हैं, इसके लिए धारा 4.8 देखें।