अनुप्रयोग विकास के लिए एक कट्टरपंथी दृष्टिकोण

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

इस भाषा से परिचित होने के सभी समय के लिए, वह व्यावहारिक रूप से कहीं भी झिलमिलाहट नहीं करता है, और रूसी में इसके बारे में लगभग कोई जानकारी नहीं है। आइए इस अंतर को भरने की कोशिश करते हैं। इस तथ्य के बावजूद कि मूल लेख 2006 वर्ष से है, विषय काफी प्रासंगिक है।
Nadezhda Zakharova और अद्भुत साइट नोटाबेनॉइड का अनुवाद करने में मदद के लिए बहुत धन्यवाद।

1. परिचय

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

इन सभी परियोजनाओं के लिए, हमने लिस्प का इस्तेमाल किया। मेरा दैनिक कार्य ग्राहकों के अनुरोधों को सुनना, व्यावसायिक प्रक्रियाओं का विश्लेषण करना और उनकी आवश्यकताओं के अनुसार सॉफ्टवेयर विकसित करना है।

आम तौर पर - ईआरपी या सीआरएम जैसे व्यावसायिक अनुप्रयोगों में - यह निरंतर परिवर्तन की एक प्रक्रिया है। एक नई परियोजना की शुरुआत में, न तो डेवलपर और न ही ग्राहक को पता होता है कि क्या आवश्यक है या अंतिम उत्पाद कैसा दिखना चाहिए।

यह एक पुनरावृत्ति प्रक्रिया के दौरान आता है (कुछ इसे "चरम प्रोग्रामिंग" कहते हैं)। क्लाइंट प्रत्येक नए संस्करण का मूल्यांकन करता है, फिर कार्यक्रम के आगे के विकास के लिए रणनीति पर चर्चा करता है। अक्सर, अप्रत्याशित आवश्यकताएं आपको एक परियोजना के बड़े हिस्से को फिर से लिखने के लिए मजबूर करती हैं। इसका मतलब यह नहीं है कि परियोजना की खराब योजना बनाई गई थी, क्योंकि मैं जिस प्रक्रिया का वर्णन करता हूं वह योजना है। एक आदर्श दुनिया में, सॉफ्टवेयर विकास सिर्फ योजना बना रहा है, लेखन कोड खर्च किए गए समय को सीधे शून्य पर जाना चाहिए।

हमें एक प्रोग्रामिंग भाषा की आवश्यकता है जो हमें सीधे व्यक्त करने की अनुमति देती है कि हम क्या करना चाहते हैं। हमारा मानना ​​है कि कोड यथासंभव सरल होना चाहिए ताकि कोई भी प्रोग्रामर किसी भी समय यह समझ सके कि कार्यक्रम में क्या हो रहा है।

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

सबसे पहले, हम आपको पिको लिस्प से परिचित कराना चाहते हैं, बताएं कि क्यों पिको एक निम्न स्तर पर अन्य लिस्प-एस या विकास प्रणालियों से काफी अलग है, और फिर उच्च स्तर पर इसके फायदे दिखाते हैं।

2. कट्टरपंथी दृष्टिकोण

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

2.1। मिथक 1: लिस्प को एक कंपाइलर की आवश्यकता होती है

वास्तव में, यह सबसे महत्वपूर्ण मिथक है। यदि आपने लिस्प समूह चर्चा में भाग लिया, तो आप जानते हैं कि संकलक एक प्रमुख भूमिका निभाता है। ऐसा लग सकता है कि यह रनटाइम का लगभग पर्यायवाची है। यह लोगों के लिए महत्वपूर्ण है कि संकलक कोड के साथ क्या कार्य करता है और कैसे कुशलता से। यदि यह आपको लगता है कि लिस्प कार्यक्रम धीरे-धीरे चल रहा है, तो आप तय करते हैं कि आपको एक बेहतर संकलक की आवश्यकता है।

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

हमें यकीन है कि विपरीत दृष्टिकोण सच है। एक तरफ (और न केवल एक दार्शनिक दृष्टिकोण से), एक संकलित लिस्प कार्यक्रम अब लिस्प बिल्कुल भी नहीं है। यह "कोड और डेटा की औपचारिक समानता" के मूल नियम का उल्लंघन करता है। परिणामी कोड में एस-एक्सप्रेशन नहीं हैं और लिस्प द्वारा संसाधित नहीं किया जा सकता है। स्रोत भाषा (लिस्प) को विभिन्न मशीनों पर अपरिहार्य असंगतताओं के साथ दूसरी भाषा (मशीन कोड) में परिवर्तित किया जाता है।

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

लेकिन क्या यह प्रयास के लायक है? बेशक, निष्पादन की गति अधिक है, और एक संकलक बनाना प्रशिक्षण उद्देश्यों के लिए दिलचस्प है। लेकिन हम तर्क देते हैं कि रोजमर्रा की जिंदगी में, एक अच्छी तरह से डिज़ाइन किया गया "दुभाषिया" अक्सर एक संकलित प्रणाली को पार कर सकता है।

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

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

लिस्प कंपाइलर इस गोंद को थोड़ा हटा देता है और कुछ नोड्स को आदिम या स्ट्रीम कार्यक्षमता के साथ सीधे मशीन कोड में बदल देता है। लेकिन, चूंकि किसी भी मामले में अधिकांश रनटाइम अंतर्निहित कार्यों पर पड़ता है, इसलिए ये सुधार उतने नाटकीय नहीं हैं, उदाहरण के लिए, जावा बाइटकोड कंपाइलर, जिसके लिए प्रत्येक नोड (बाइटकोड) में अपेक्षाकृत आदिम कार्यक्षमता है।

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

पिको लिस्प की आंतरिक संरचनाएं मूल रूप से व्याख्या की आसानी के लिए बनाई गई थीं। हालांकि वे पूरी तरह से सी में लिखे गए थे, और गति के लिए विशेष रूप से अनुकूलित नहीं थे, अपर्याप्त प्रदर्शन की समस्या कभी नहीं थी। पिको लिस्प में लिखी गई पहली व्यावसायिक प्रणाली छवियों को संसाधित करने और पुनर्प्राप्त करने के साथ-साथ मुद्रण के लिए पेज लेआउट बनाने के लिए एक प्रणाली थी। यह 1988 में बनाया गया था और इसे 12 मेगाहर्ट्ज सीपीयू और 8 एमबी रैम के साथ मैक II पर इस्तेमाल किया गया था।

बेशक, कोई लिस्प कंपाइलर नहीं था, सी में केवल निम्न-स्तरीय पिक्सेल जोड़-तोड़ और बेजियर फ़ंक्शन थे, फिर भी, जब कंप्यूटर पर काम करना आधुनिक लोगों की तुलना में सैकड़ों गुना धीमा था, तो किसी ने प्रदर्शन के बारे में शिकायत नहीं की।

हित के लिए, मैंने CLisp स्थापित किया और एक उदाहरण के रूप में सरल परीक्षणों का उपयोग करके पिको लिस्प के साथ इसकी तुलना की। बेशक, इसका मतलब यह नहीं है कि परीक्षण के परिणाम किसी एप्लिकेशन सर्वर के रूप में किसी विशेष सिस्टम की उपयोगिता दिखाते हैं, लेकिन वे इन प्रणालियों के प्रदर्शन का अनुमानित विचार देते हैं। सबसे पहले, मैंने एक साधारण पुनरावर्ती फाइबोनैचि फ़ंक्शन को निष्पादित करने का प्रयास किया।

(defun fibo (N) (if (< N 2) 1 (+ (fibo (- N 1)) (fibo (- N 2)) ) ) ) 

जब इस फ़ंक्शन को पैरामीटर 30 (फाइबो 30) के साथ कॉल किया जाता है, तो मुझे निम्नलिखित परिणाम मिले (एक पेंटियम-आई 266 मेगाहर्ट्ज लैपटॉप पर परीक्षण किया गया था):

पिको (व्याख्या)	12 सेकंड
स्पष्ट व्याख्या	37 सेकंड
संकलित संकलन	7 सेकंड

क्लिस्प दुभाषिया लगभग तीन गुना धीमा है, और कंपो पिको लिस्प की तुलना में लगभग दो गुना तेज है।

हालांकि, फाइबोनैचि फ़ंक्शन एक विशिष्ट लिस्प कार्यक्रम का एक अच्छा उदाहरण नहीं है। इसमें केवल एक आदिम धारा और अंकगणितीय कार्य होते हैं, जो आसानी से संकलक द्वारा अनुकूलित किया जाता है और सी में सीधे लिखा जा सकता है यदि यह समय महत्वपूर्ण है (इस मामले में, यह केवल 0.2 एस लगेगा)

इसलिए, मैंने एक और चरम मामले को लिया, एक फ़ंक्शन के साथ जो व्यापक सूची प्रसंस्करण करता है:

 (defun tst () (mapcar (lambda (X) (cons (car X) (reverse (delete (car X) (cdr X))))) '((abcabc) (bcdbcd) (cdecde) (defdef)) ) ) 

इस फ़ंक्शन को 1 मिलियन बार कॉल करने पर, मुझे मिला:

पिको (व्याख्या)	31 सेकंड
स्पष्ट व्याख्या	196 सेकंड
संकलित संकलन	80 सेकंड

CLisp दुभाषिया अब 6 गुना से अधिक धीमा है, लेकिन मेरे आश्चर्य की बात है, यहां तक ​​कि संकलित कोड पिको लिस्प की तुलना में 2.58 गुना धीमा है।

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

2.2। मिथक 2: लिस्प को बहुत अधिक डेटा प्रकारों की आवश्यकता होती है

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

दूसरी ओर पिको लिस्प, केवल तीन अंतर्निहित डेटा प्रकारों - संख्याओं, वर्णों और सूचियों का समर्थन करता है, और यह उन प्रकारों के साथ ठीक करता है। एक लिस्प प्रणाली कम डेटा प्रकारों के साथ तेजी से चलती है क्योंकि रनटाइम पर कम विकल्पों की जांच की जानी चाहिए। हो सकता है कि इससे मेमोरी का कम कुशल उपयोग होगा, लेकिन कम संख्या में आपको इस तथ्य के कारण जगह बचाने की अनुमति मिलती है कि टैग के लिए कम बिट्स की आवश्यकता होती है।

सभी तीन डेटा प्रकारों का उपयोग करने का मुख्य कारण सादगी है, और सादगी में लाभ गति और स्मृति क्षतिपूर्ति के लाभ को बढ़ाता है।

वास्तव में, पिको लिस्प सबसे निचले स्तर पर केवल एक डेटा प्रकार, कोशिकाओं का उपयोग करता है जो संख्या, वर्ण और सूची बनाने के लिए उपयोग किए जाते हैं। एक छोटी संख्या या न्यूनतम चरित्र केवल एक मेमोरी स्थान पर कब्जा कर लेता है, यदि आवश्यक हो तो गतिशील रूप से बढ़ रहा है। यह मेमोरी मॉडल कुशल कचरा संग्रह की अनुमति देता है और पूरी तरह से विखंडन से बचा जाता है (जैसा कि यह होगा, उदाहरण के लिए, वैक्टर के साथ)।

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

2.3। मिथक 3: डायनेमिक लिंकिंग खराब है

पिको लिस्प गतिशील सतह बंधन का एक सरल कार्यान्वयन का उपयोग करता है। लैम्ब्डा अभिव्यक्ति या बाध्यकारी वातावरण में प्रवेश करते समय प्रतीक के मूल्य को संग्रहीत करने वाले सेल की सामग्री को बचाया जाता है, और फिर एक नया मान सेट किया जाता है। वापस लौटने पर, मूल मूल्य बहाल हो जाता है। नतीजतन, प्रतीक का वर्तमान मूल्य इतिहास और निष्पादन की स्थिति से गतिशील रूप से निर्धारित किया जाता है, और शाब्दिक वातावरण के स्थिर चेक से नहीं।

शायद व्याख्या की गई प्रणाली के लिए यह सबसे सरल और सबसे तेज़ रणनीति है। सेल वैल्यू की खोज करने के लिए, किसी भी खोज की आवश्यकता नहीं होती है (केवल सेल वैल्यू तक पहुंचने की आवश्यकता होती है) और सभी पात्रों (स्थानीय या वैश्विक) को उसी तरह संसाधित किया जाता है। दूसरी ओर, संकलक शाब्दिक बंधन के लिए अधिक कुशल कोड का उत्पादन कर सकता है, इसलिए संकलित लिस्प कोड आमतौर पर कई प्रकार की बाध्यकारी रणनीतियों का समर्थन करके चीजों को जटिल करता है।

डायनेमिक लिंकिंग एक बहुत शक्तिशाली तंत्र है। आप वर्तमान मूल्य को कहीं से भी एक्सेस कर सकते हैं, चर और इसका मूल्य हमेशा भौतिक रूप से "वास्तविक चीजें" हैं, और न कि वे "प्रतीत" होते हैं (जैसा कि शाब्दिक बंधन के साथ होता है, और कुछ हद तक पारगमन वर्णों का उपयोग करके। पिको लिस्प में (नीचे देखें)।

दुर्भाग्य से, बड़े जोखिम के बिना महान अवसर असंभव हैं। एक प्रोग्रामर को मूल सिद्धांतों से परिचित होना चाहिए ताकि उनका लाभ उठाया जा सके और नुकसान से बचा जा सके। हालांकि, जब तक हम पिको लिस्प द्वारा अनुशंसित सम्मेलनों से चिपके रहेंगे, जोखिम कम से कम होंगे।

दो प्रकार की परिस्थितियाँ हैं जहाँ डायनेमिक लिंकिंग का उपयोग करके गणनाओं के परिणाम प्रोग्रामर के नियंत्रण से बाहर हो सकते हैं:

1. प्रतीक स्वयं से जुड़ा हुआ है, और हम प्रतीक के अर्थ को बदलने की कोशिश कर रहे हैं;
2. फ़ारग की समस्या (कार्यात्मक तर्क), जब एक प्रतीक का मूल्य गतिशील रूप से पास-थ्रू कोड द्वारा बदल दिया जाता है जो वर्तमान स्रोत कोड के वातावरण में अदृश्य है।

पारगमन प्रतीकों का उपयोग करके ऐसी स्थितियों से बचा जा सकता है।

पिको लिस्प में संक्रमणकालीन चरित्र ऐसे पात्र हैं जो तार की तरह दिखते हैं (और अक्सर तार के रूप में उपयोग किए जाते हैं) और जो केवल स्रोत कोड (या इसके केवल भागों) के साथ एक फ़ाइल की अवधि के लिए अस्थायी रूप से नजरबंद हैं। इस प्रकार, उनके पास सी कार्यक्रमों में स्थिर पहचानकर्ताओं की तुलना में शाब्दिक क्षमताएं हैं, केवल उनका व्यवहार पूरी तरह से गतिशील है, क्योंकि वे अन्य सभी मामलों में सामान्य चरित्र हैं।

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

2.4। मिथक 4: संपत्ति की सूची खराब है

मूल्य / फ़ंक्शन सेल के अतिरिक्त प्रतीकों के साथ जानकारी को संबद्ध करने का एक सुरुचिपूर्ण, समझदार तरीका है। वे बेहद लचीले हैं क्योंकि डेटा की मात्रा और प्रकार सांख्यिकीय रूप से तय नहीं हैं।

कई लोग सोचते हैं कि संपत्ति की सूची बहुत पुरानी है और हमारे समय में उपयोग होने वाली आदिम है। इसके बजाय, अधिक उन्नत डेटा संरचनाओं का उपयोग किया जाना चाहिए। हालांकि यह कुछ मामलों में सच है, प्रतीक में कुल संपत्तियों के आधार पर, पेबैक थ्रेशोल्ड उम्मीद से अधिक हो सकता है।

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

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

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

3. एप्लिकेशन सर्वर

इस सरल पिको लिस्प मशीन के आधार पर, हमने एक लंबवत संरचित अनुप्रयोग सर्वर विकसित किया है। यह डेटाबेस इंजन (एक प्रथम श्रेणी डेटा प्रकार के रूप में लगातार (लगातार) वस्तुओं के PicoLisp के कार्यान्वयन पर आधारित है और एक अमूर्त चित्रमय इंटरफ़ेस (उदाहरण के लिए, HTML या जावा एप्लेट्स) उत्पन्न करता है।

इस एकीकृत प्रणाली में एक प्रमुख तत्व लिस्प-आधारित मार्कअप भाषा है, जिसका उपयोग व्यक्तिगत एप्लिकेशन मॉड्यूल को लागू करने के लिए किया जाता है।

जब भी डेटाबेस से एक नया दृश्य, एक दस्तावेज़ या रिपोर्ट, या किसी अन्य सेवा के लिए आवेदन सर्वर से अनुरोध किया जाता है, तो लिस्प स्रोत फ़ाइल डाउनलोड की जाती है और मक्खी पर निष्पादित की जाती है। यह एक URL रिक्वेस्ट के समान है जो पारंपरिक वेब सर्वर में HTML फाइल सबमिट करने के बाद आता है।

हालांकि, इस तरह के परिदृश्य में मूल्यांकन किए गए लिस्प अभिव्यक्तियों में आमतौर पर एक इंटरैक्टिव यूजर इंटरफेस के निर्माण और प्रसंस्करण का दुष्प्रभाव होता है।

ये लिस्प अभिव्यक्तियाँ जीयूआई घटकों की संरचना, उपयोगकर्ता के कार्यों के जवाब में उनका व्यवहार और डेटाबेस ऑब्जेक्ट के साथ उनकी बातचीत का वर्णन करती हैं। संक्षेप में, उनमें सॉफ्टवेयर मॉड्यूल का पूरा विवरण होता है। इसे संभव बनाने के लिए, हमने पाया कि स्थानीयता सिद्धांत का सख्ती से पालन करना महत्वपूर्ण है, और उपसर्ग वर्ग और लिंक समर्थन दानव तंत्र का उपयोग करें (पिछले दो अन्य दस्तावेज़ में वर्णित हैं)।

3.1। स्थानीयता सिद्धांत

जैसा कि हमने कहा, व्यावसायिक अनुप्रयोग विकसित करना निरंतर परिवर्तन की एक प्रक्रिया है। इस तरह की परियोजनाओं के विकास में स्थानीयता सिद्धांत से बहुत मदद मिली है। इस सिद्धांत के लिए आवश्यक है कि एक मॉड्यूल के बारे में सभी जानकारी एक ही स्थान पर इस मॉड्यूल के साथ संग्रहीत की जानी चाहिए। यह प्रोग्रामर को केवल एक ही स्थान पर ध्यान केंद्रित करने की अनुमति देता है जहां यह सब संग्रहीत है।

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

इस प्रकार, हम मानते हैं कि कार्यों, वर्गों और विधियों के एक सार पुस्तकालय का निर्माण सार्वभौमिक है - यथासंभव सार्वभौमिक, समय और विभिन्न अनुप्रयोगों में निरंतरता, और अनुप्रयोगों के निर्माण के लिए उच्च स्तर की अभिव्यक्ति के साथ एक सख्त मार्कअप भाषा का निर्माण करने के लिए उपयोग किया जाता है।

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

3.2। तुतलाना

और यह बहुत ही मुख्य कारण है कि शुरुआत से ही हमने तर्क दिया कि लिस्प एकमात्र ऐसी भाषा है जो हमें सूट करती है।

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

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

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

सभी के अलावा, चूंकि पिको लिस्प डेटाबेस ऑब्जेक्ट्स और आंतरिक पात्रों के बीच एक औपचारिक अंतर नहीं करता है, ये सभी फायदे डेटाबेस के साथ काम करने के लिए भी लागू होते हैं, जिसके परिणामस्वरूप एक ही कोड का उपयोग करके एक ही स्थानीय संदर्भ में GUI और डेटाबेस संचालन के बीच सीधा संचार होता है।

4. निष्कर्ष

लिस्प समुदाय "अक्षम" लिस्प के व्यामोह से पीड़ित लगता है। यह संभवतः इस तथ्य के कारण है कि दशकों से उन्हें अपनी भाषा का दावा करने से मजबूर किया गया है कि "लिस्प धीमा है" और "लिस्प फूला हुआ है"।

यह आंशिक रूप से सच था। लेकिन आज के हार्डवेयर पर, निष्पादन की गति कई व्यावहारिक अनुप्रयोगों के लिए मायने नहीं रखती है। और उन मामलों में जब यह होता है, सी में कई महत्वपूर्ण कार्यों को एन्कोडिंग आमतौर पर इस समस्या को हल करता है।

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

पिको लिस्प को "कम अधिक हो सकता है" की अवधारणा के प्रमाण के रूप में देखा जा सकता है।