लिस्प का भविष्य

यह स्टीफन डीगटिस के एक लेख का अनुवाद है।

लिस्प का भविष्य

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

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

बाजार की स्थिति

परंपरागत रूप से, एक योजना है, जो केवल विश्वविद्यालयों में पढ़ाने के लिए उपयोगी है क्योंकि समर्थित पुस्तकालयों की कमी के कारण, कॉमन लिस्प भी है, जो एक भयानक, भयानक गड़बड़ है (सी ++ की कल्पना करें, लेकिन कोष्ठक के एक पूरे समुद्र के साथ)।

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

हालाँकि, कुछ अन्य भी हैं, जैसे कि Nu, जो कि अगर आप iOS या Mac के लिए कुछ बना रहे हैं, तो एक रामबाण है, लेकिन पॉइंटर्स के लिए नहीं। (अरे, यह MacRuby की तरह दिखता है!)

लेकिन नू ने बंद क्यों नहीं किया? और सीएल और स्कीम क्यों मर गए? केवल एक क्लोजर गति क्यों प्राप्त कर रहा है? क्या एक और लिस्प बोली उसी सफलता की उम्मीद कर सकती है?

अभिशाप ... और आशीर्वाद

निस्संदेह, वाक्यविन्यास कहीं नहीं जा रहा है। एस-एक्सप्रेशंस लिस्प को बेहद सरल बनाते हैं और आपको एक शांत सुविधा का उपयोग करने की अनुमति देते हैं जिसे हम मैक्रोज़ कहते हैं, लेकिन ये सभी ब्रैकेट केवल घृणित हैं और कोई भी उन्हें संभाल नहीं सकता है जब तक कि यह एमएसीएस + परडिट पर काम नहीं करता है। लिस्प का सबसे बड़ा गुण शायद उसकी सबसे बड़ी कमजोरी है।

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

लेकिन हम मंच के बारे में क्या परवाह करते हैं?

नु एक बहुत ही रोचक बोली है। यह iOS / Mac विकास प्रक्रिया को आसान और अधिक मज़ेदार बनाने के लिए बनाया गया था। यह लिस्प मैक्रोज़ का एक सेट प्रदान करता है, साथ ही आपको विकसित करने में मदद करने के लिए उपयोगी उपकरणों का एक मेजबान भी प्रदान करता है।

लेकिन कोको एक एसडीके है, एक मंच नहीं है। जो कोई भी आपको बताता है अन्यथा आपको कुछ (शायद Xcode) बेचने की कोशिश कर रहा है। मैक / IOS अनुप्रयोगों में, पूरी बात चित्रमय इंटरफ़ेस में है, और आपके द्वारा विकास के किसी भी चरण में आपको आवश्यक प्रत्येक घटक पहले से ही प्रदान किया जाता है (आपको जोड़ने की आवश्यकता है, वे मंच के ढांचे के भीतर एक-दूसरे के साथ निकटता से जुड़े हुए हैं)। बस आपको थोड़ी कल्पना की जरूरत है।

तो इसमें गलत क्या है?

कोको में आवेदन लिखते समय, आपको मॉडल, नियंत्रक, विचार मिलते हैं, और आपको उद्देश्य-सी कोड की न्यूनतम मात्रा के साथ उन्हें "गोंद" करना होगा। इस प्रकार, आप लिस्प की सभी विशेषताओं को लागू करने का अवसर खो देते हैं। नू कोड की लगभग हर लाइन (ऑफहैंड - लगभग 95%) केवल ऑब्जेक्टिव-सी कोड को कॉल करने में सक्षम होगी, जो लिस्प का उपयोग केवल हास्यास्पद बना देता है।

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

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

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

सही मंच ढूंढ रहा है

लेकिन यह जेवीएम की एक अनूठी विशेषता नहीं है। सी, और सी ++, पायथन और रूबी के साथ भी यही बात होती है? आइए इसका सामना करते हैं, रूबी या पायथन में निर्मित लिस्प, निरर्थक है: ये भाषाएं आपको वांछित कार्यक्षमता के 90% को लागू करने की अनुमति देती हैं, इसलिए केवल मैक्रोज़ के लिए कुछ का आविष्कार क्यों करें, और इसके अलावा, ऐसी प्रणाली भी धीमी हो जाएगी।

और हां, एक एल्गोरिथम भाषा जैसे लिस्प और एक निम्न-स्तरीय भाषा जैसे सी, या सी + + जैसी स्पेगेटी-जनरेटिंग भाषा के बीच सामान्य संगतता नहीं हो सकती है। कोई व्यक्ति स्मृति को मुक्त करता है, क्यों, कब, और सामान्य रूप से, मेरा चिकन कहाँ है? यह सब बहुत भ्रामक है।

अन्य संभावित niches

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

लेकिन हम जल्दी से पृथ्वी पर उतरते हैं, इस एहसास के साथ कि ये भाषाएं, जिनमें से प्रत्येक का अपना प्रोग्रामिंग वातावरण (कोई Emacs) नहीं है, जिसे कोई भी हफ्तों के मामले में भाषा का विशेषज्ञ बनने के लिए जल्दी से मास्टर कर सकता है। लिस्प के लिए विशिष्ट एस-एक्सप्रेशंस केवल इसकी अनुमति नहीं देंगे।

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

आगे के भविष्य के लिए आगे!

सच्चाई यह है कि अभी कोई अन्य मंच मानक पुस्तकालयों, तृतीय-पक्ष समर्थन, विस्तार, व्यापक कार्यक्षमता, समुदाय और पोर्टेबिलिटी प्रदान नहीं कर सकता है जिस स्तर पर जेवीएम करता है। फिलहाल क्लीजुर लिस्प का सबसे अच्छा अवतार है, और भविष्य के लिए ऐसा रहेगा।