स्कीम बनाम आम लिस्प: किन विशेषताओं ने आपकी परियोजना में बदलाव किया है? [बन्द है]

Question

StackOverflow और इस साइट दोनों पर अस्पष्ट "स्कीम बनाम कॉमन लिस्प" के सवालों की कोई कमी नहीं है, इसलिए मैं इसे और अधिक केंद्रित बनाना चाहता हूं। सवाल उन लोगों के लिए है, जिन्होंने दोनों भाषाओं में कोड किया है:

स्कीम में कोडिंग करते समय, आपके कॉमन लिस्प कोडिंग अनुभव के कौन से विशिष्ट तत्व आपको सबसे ज्यादा याद आते हैं? या, आम तौर पर, कॉमन लिस्प में कोडिंग करते समय, आपने स्कीम में कोडिंग से क्या मिस किया?

मैं जरूरी नहीं कि सिर्फ भाषा सुविधाओं का मतलब है। निम्नलिखित सभी मान्य बातें याद आती हैं, जहां तक ​​सवाल है:

• विशिष्ट पुस्तकालय।
• विकास के वातावरण की विशिष्ट विशेषताएं जैसे SLIME, DrRacket, आदि।
• विशेष रूप से कार्यान्वयन की विशेषताएं, जैसे कि Gambit के C कोड को सीधे अपने स्कीम स्रोत में लिखने की क्षमता।
• और निश्चित रूप से, भाषा सुविधाएँ।

मैं जिस तरह के उत्तरों की उम्मीद कर रहा हूं, उनके उदाहरण:

• "मैं सामान्य लिस्प में एक्स को लागू करने की कोशिश कर रहा था, और अगर मेरे पास योजना की प्रथम श्रेणी की निरंतरता थी, तो मैंने पूरी तरह से वाई किया होगा, लेकिन इसके बजाय मुझे जेड करना पड़ा, जो एक दर्द से अधिक था।"
• "मेरे स्कीम प्रोजेक्ट में बिल्ड प्रक्रिया की स्क्रिप्टिंग तेजी से दर्दनाक हो गई क्योंकि मेरे स्रोत का पेड़ बढ़ता गया और मैं अधिक से अधिक सी लाइब्रेरी में जुड़ा। अपने अगले प्रोजेक्ट के लिए, मैं कॉमन लिस्प में वापस चला गया।"
• "मेरे पास एक बड़ा मौजूदा C ++ कोडबेस है, और मेरे लिए, मेरे Gambit स्कीम कोड में सीधे C ++ कॉल एम्बेड करने में सक्षम होने के कारण पूरी तरह से किसी भी कमियों के लायक था, जो स्कीम बनाम कॉमन लिस्प हो सकती है, यहां तक ​​कि SWIG समर्थन की कमी भी शामिल है।"

इसलिए, मैं सामान्य कहानियों के बजाय युद्ध की कहानियों की उम्मीद कर रहा हूं जैसे "योजना एक सरल भाषा है" आदि।

Comments

एक उत्कृष्ट, सुविचारित प्रश्न। मैं खुद इस बारे में उत्सुक हूं; उम्मीद है कि कुछ लोग दोनों भाषाओं में विशेषज्ञता के साथ कुछ अंतर्दृष्टि प्रदान करने के लिए तैयार हैं।

— रॉबर्ट हार्वे

@ जोश के - यह स्पष्ट रूप से जवाबदेह है, लेकिन जरूरी नहीं कि एक निश्चित उत्तर हो। सिवाय इसके कि मैं शर्त लगाता हूं कि कोई एक होगा क्योंकि कोई ऐसा जवाब लेकर आएगा जो इतना जबरदस्त हो कि हर कोई लाइक करे!

— ग्लेनट्रॉन

@ जोश: तब शायद आप स्कीम और कॉमन लिस्प से परिचित नहीं हैं। दोनों भाषाएँ अपने आप में बहुत शक्तिशाली हैं, फिर भी न तो मुख्यधारा की स्वीकृति है। ऐसा क्यों है? यह हो सकता है क्योंकि बहुत सारी बोलियाँ हैं; कौन सा आप चयन करते हैं? इस तरह की तुलना बहुत रोशन करने वाली हो सकती है, और ओपी ने इस सवाल का जवाब देने के लिए गुंजाइश को सीमित करने के लिए सावधानीपूर्वक शब्द का उपयोग किया है, जो मेरे विचार में, बहुत विशिष्ट और जवाबदेह हैं।

— रॉबर्ट हार्वे

दोस्तों, इस सवाल को सिर्फ इसलिए बंद न करें क्योंकि आपको यह पसंद नहीं है या आप इससे संबंधित नहीं हैं। यह स्पष्ट रूप से एक "वास्तविक" प्रश्न है; यदि आपको इसे बंद करने का एक बेहतर कारण नहीं मिल रहा है, तो आपको बंद करने के लिए मतदान नहीं करना चाहिए।

— रॉबर्ट हार्वे

आप उसके जवाब के लिए रिचर्ड स्टालमैन को ईमेल कर सकते थे।

— ssimans

Answer 1

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

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

ग्रीनस्पून का बिंदु था (भाग में) कि कई जटिल कार्यक्रमों में अंतर्निहित दुभाषिया हैं। भाषा में एक दुभाषिया बनाने के बजाय उन्होंने सुझाव दिया कि यह लिस्प जैसी भाषा का उपयोग करने के लिए और अधिक समझदार हो सकता है जिसमें पहले से ही एक दुभाषिया (या संकलक) अंतर्निहित हो।

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

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

कुछ समय बाद जब मैंने एक वेब-आधारित परियोजना पर काम करना शुरू किया, तो मैंने कई भाषाओं का ऑडिशन लिया। मैंने मिक्स में लिस्प और स्कीम को शामिल किया। अंत में मैंने एक योजना कार्यान्वयन का चयन किया- Chez योजना । मैं परिणामों से बहुत खुश हूं।

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

अब मैं आपके प्रश्न का उत्तर दे सकता हूं (कम से कम भाग में)।

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

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

हमने छोटे कार्यक्रमों का एक साथ रखा और मूल्यांकन और परीक्षण के लिए उनका उपयोग किया। इसने कई मुद्दों का खुलासा किया। उदाहरण के लिए: कुछ कार्यान्वयन में दोष थे जो कुछ परीक्षणों को पूर्ण होने से रोकते थे; कुछ कार्यान्वयन रन-टाइम में कोड संकलित नहीं कर सकते हैं; कुछ कार्यान्वयन आसानी से पूर्व संकलित कोड के साथ रन-टाइम संकलित कोड को एकीकृत नहीं कर सके; कुछ कार्यान्वयन में कचरा संग्रहकर्ता थे जो दूसरों की तुलना में स्पष्ट रूप से बेहतर (या स्पष्ट रूप से बदतर) थे; आदि।

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

लिस्प और स्कीम दोनों में कोड के कुछ महत्वपूर्ण हिस्से का उत्पादन करने के बाद कुछ तुलना और इसके विपरीत बिंदु हैं:

• लिस्प वातावरण अधिक परिपक्व हैं। आपको हिरन के लिए बहुत अधिक धमाके मिलते हैं। (कहा जाता है कि, अधिक कोड भी अधिक बग के लिए समान है।)

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

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

मैंने कहा कि इससे पहले कि हम कई जगहों पर स्कीम का उपयोग कर रहे थे, जिनका मूल रूप से इरादा नहीं था। क्यों? मैं अपने सिर के ऊपर से तीन कारणों के बारे में सोच सकता हूं।

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

दूसरा, हमने Chez से प्राप्त प्रदर्शन से प्यार करना सीखा। हम एक ऐसी चीज़ का उपयोग कर रहे थे जो एक स्क्रिप्टिंग भाषा की तरह महसूस करती थी - और हमें इससे देशी-कोड गति मिल रही थी। कुछ चीजों के लिए जो मायने नहीं रखती थी - लेकिन यह कभी चोट नहीं पहुंचाती थी, और कभी-कभी यह एक भयानक मदद करती थी।

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

क्या स्कीम सही है? नहीं; यह एक व्यापार बंद है। सबसे पहले, यह अलग-अलग डेवलपर्स को अधिक प्रभावी बनाने की अनुमति देता है - लेकिन डेवलपर्स के लिए एक-दूसरे के कोड को ग्रो करना अधिक कठिन होता है क्योंकि स्कीपपोस्ट जो कि अधिकांश भाषाओं में होते हैं (जैसे, लूप के लिए) योजना में गायब हैं (उदाहरण के लिए, एक मिलियन तरीके हैं) for a लूप)। दूसरा, डेवलपर्स से बात करने, किराए पर लेने, उधार लेने आदि के लिए बहुत छोटा पूल है।

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

इसके अलावा, सिर्फ दोहराने के लिए: हमने कई लिस्प्स और योजनाओं को बहुत पहले देखा था; वे सब विकसित और सुधार हुआ है।

Comments

वाह, यह वास्तव में कुछ भयानक डेल्फी कोड रहा होगा अगर यह किसी भी तरह एक लिस्प कार्यान्वयन से 3-6x धीमी प्रदर्शन करने में कामयाब रहा ! :(

— मेसन व्हीलर

+1: इस पोस्ट के बारे में सबसे दिलचस्प बात यह है कि आपने लिस्प में एक बड़ी परियोजना के पूरा होने के बाद लिस्प से स्कीम की ओर रुख किया। (या हो सकता है कि मैं सिर्फ comp.lang.lisp पर लंबे समय से झूठ बोल रहा हूं।)

— लैरी कोलमैन

"वाह, यह वास्तव में कुछ भयानक डेल्फी कोड रहा होगा अगर यह किसी भी तरह एक लिस्प कार्यान्वयन से 3-6x धीमी प्रदर्शन करने में कामयाब रहा!" ठीक है, मैं इसे बेहतर नहीं समझाने के लिए मेरी असफलता को गिनाऊंगा। लिस्प कार्यान्वयन उपयोगकर्ता अभिव्यक्तियों को लिस्प अभिव्यक्तियों में बदलने में सक्षम था - एक तुच्छ आसान प्रक्रिया - और फिर लिस्प अभिव्यक्तियों को मूल कोड (पूर्ण अनुकूलन के साथ) के लिए संकलित करें। ग्रीनस्पून के दसवें नियम का यही अर्थ है।

— माइकल लेनघन

शानदार जवाब! मैं इसे चुनता हूँ, कम से कम जब तक एक बेहतर दिखाता है :) एक सवाल: आप कहते हैं कि आपने "एक लंबे समय पहले" क्षेत्र की स्थिति के आधार पर Chez योजना के साथ जाने का निर्णय लिया। क्या आप एक वर्ष निर्दिष्ट कर सकते हैं?

— सुपरइलेक्ट्रिक

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

— जॉन आर। स्ट्रोम

Answer 2

मुझे आमतौर पर एक लिंक को जवाब के रूप में चिपकाना पसंद नहीं है, लेकिन मैंने इस पर एक ब्लॉग लेख लिखा है। यह संपूर्ण नहीं है, लेकिन इसके माध्यम से कुछ प्रमुख बिंदु मिलते हैं।

http://symbo1ics.com/blog/?p=729

संपादित करें : यहाँ सिद्धांत बिंदु हैं:

1. अनुभव : दोनों लिस्प दूसरे लिस्प्स के एक समूह के बाद आए। स्कीम ने न्यूनतम, स्वयंसिद्ध मार्ग लिया। सीएल बरोक मार्ग ले गया।
2. CASE : आमतौर पर स्कीम संवेदनशील होती है। सीएल नहीं है (हालांकि यह हो सकता है)। यह कभी-कभी छूट जाता है, लेकिन इसकी व्यावहारिकता पर (मेरे द्वारा) बहस की जाती है।
3. नाम : सीएल में प्रतीकों के नाम कई बार अजीब और भ्रमित करने वाले होते हैं। TERPRI, PROGNआदि योजना में आमतौर पर बहुत ही समझदार नाम हैं। यह सीएल में कुछ छूट गया है।
4. समारोह : सीएल का एक अलग कार्य नाम स्थान है। यह है नहीं योजना में याद किया। एक एकल नामस्थान होने से आमतौर पर बहुत साफ कार्यात्मक प्रोग्रामिंग की अनुमति मिलती है, जो अक्सर सीएल में कठिन या अजीब होता है। लेकिन यह एक लागत पर आता है --- आपको कभी-कभी योजना में " list" से " lst" जैसे नामों को स्थगित करना होगा ।
5. MACROS : मुझे योजना में निम्न स्तर के गंदे मैक्रोज़ सबसे ज्यादा याद आते हैं। हाँ, syntax-rulesजब तक आप वास्तव में कुछ चीजों को हैक नहीं करना चाहते, तब तक सब ठीक है और बांका है। दूसरी ओर, सीएल में हाइजीनिक मैक्रो कभी-कभी छूट जाते हैं। उनके पास कोई मानक तरीका नहीं होने का मतलब पहिया का फिर से आविष्कार करना है।
6. पोर्टेबिलिटी : यह अक्सर ऐसा होता है कि सीएल अधिक पोर्टेबल है, दोनों भाषाओं के मानकीकृत होने के बावजूद। सीएल बड़ा है, और इसलिए बाहरी पुस्तकालयों के बिना उपयोग करने के लिए अधिक मानक विशेषताएं हैं। इसका अर्थ यह भी है कि अधिक क्रियान्वयन-निर्भर चीजें आंशिक रूप से हो सकती हैं। इसके अलावा, योजना एक ट्रिलियन कार्यान्वयन होने से ग्रस्त है, जिनमें से अधिकांश कुछ असंगत हैं। यह सीएल को बहुत वांछनीय बनाता है।
7. पुस्तकालय : मेरे अंतिम बिंदु से संबंधित। योजना में SRFI हैं लेकिन सार्वभौमिक रूप से स्वीकार नहीं किए जाते हैं। पुस्तकालयों के साथ काम करने का कोई पोर्टेबल तरीका नहीं है। दूसरी ओर सीएल के पास तरीके हैं। और क्विक्लिस्प भगवान (एक्सच) से एक उपहार है --- उपयोग के लिए पुस्तकालयों का एक प्रकार का भंडार।
8. प्रभाव : योजना इतने सारे कार्यान्वयन से ग्रस्त है। कोई वास्तविक विहित कार्यान्वयन नहीं है। सीएल दूसरी ओर कुछ बहुत अच्छा उच्च प्रदर्शन या विशिष्ट उपयोग कार्यान्वयन (उच्च प्रदर्शन: SBCL, वाणिज्यिक: Allegro, एम्बेडेड: ECL, पोर्टेबल: CLISP, जावा: ABCL, ...) है।

जबकि मैंने केवल पहले व्यक्ति से थोड़ा ऊपर बात की थी, यह स्पष्ट होना चाहिए कि मुझे क्या याद है और मैं क्या नहीं करता।

[मैं माफी माँगता हूँ अगर ये बहुत सामान्य हैं। ऐसा लगता है कि आप बहुत अधिक विशिष्ट विवरण चाहते हैं। पोस्ट में कुछ विवरण हैं।]

Comments

(वास्तव में) लघु टीज़र सारांश के बारे में क्या? ^ ^

— डेव ओ।

कृपया हाइलाइट को इनलाइन करें। उत्तर स्व-स्थायी होना चाहिए।

@Dave O. और @ Thorbjørn Ravn Andersen: अनुरोध के अनुसार एक सारांश जोड़ा गया। धन्यवाद।

— चतुर्दशी 17:21 बजे

"बारोक मार्ग"! इसे लगाने का एक शानदार तरीका क्या है।

— मार्क सी

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

— डेविड थॉर्नले

Answer 3

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

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

मेरे सामान्य लिस्प कार्यान्वयन (SBCL) में एक IDE नहीं है, लेकिन यह Emacs और SLIME का उपयोग करने के लिए ओपन-सोर्स CL कार्यान्वयन के साथ प्रथागत है। यह संयोजन बहुत कुशल हो सकता है। भावों का मूल्यांकन करने की क्षमता के साथ-साथ आप उन्हें स्रोत फ़ाइल में टाइप करते हैं, एक REPL भी है जिसमें Emacs के सभी संपादन कमांड उपलब्ध हैं, इसलिए कोड कॉपी करना दोनों तरीकों से कुशलता से हो सकता है। यहां तक ​​कि REPL बफर में प्रदर्शित वस्तुओं को कॉपी और पेस्ट किया जा सकता है। Alt+(और Alt+)मिलान किए गए कोष्ठक और इंडेंटेशन से निपटने के लिए कुशल हैं।

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

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

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

Comments

विस्तार के लिए धन्यवाद! क्या मैं आपको सही ढंग से समझता हूं कि आपने सोचा था कि एसबीसीएल का एफएफआई क्लोजर की तुलना में उपयोग करना आसान था? यदि ऐसा है, तो मुझे इससे बहुत आश्चर्य होगा, यह देखते हुए कि आप केवल उन्हें लपेटने के बिना क्लोज़र से सीधे जावा विधियों को कॉल कर सकते हैं। (या क्या आपको मूल कोड को कॉल करने की आवश्यकता है?)

— सुपरइलेक्ट्रिक

@ सुपरप्रूफ: कॉलिंग "बिल्ट-इन" जावा तरीके क्लोर्ज से तुच्छ है; जावा विधियों को कॉल करना जो एक डाउनलोड की गई लाइब्रेरी में हैं: इतना नहीं। मैंने वास्तव में क्लासपाथ और आयात लाइनों को प्राप्त करने में अधिक समय बिताया, क्योंकि मुझे एसएफसीएल से सीएफएफआई के साथ काम करने के लिए मुझे अपना पहला सी तरीका प्राप्त करना पड़ा। लेकिन मैं जावा विशेषज्ञ नहीं हूं, इसलिए आपका माइलेज मई वैरी है।

— लैरी कोलमैन

Answer 4

मैं सीएल और रैकेट दोनों में कार्यक्रम करता हूं।

मैं अब कॉमन लिस्प में एक वेब साइट विकसित कर रहा हूं, और मैंने रैकेट में अपने पिछले नियोक्ता के लिए इन-हाउस कार्यक्रमों का एक सूट लिखा।

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

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

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

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

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

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

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

रैकेट का लेट-वैल्यू फॉर्म अत्यधिक क्रियात्मक था, इसलिए मैंने MULTIPLE-VALUE-BIND को लागू किया। यह पूरी तरह से आवश्यक था, क्योंकि रैकेट को आपके द्वारा उत्पन्न सभी मूल्यों को प्राप्त करने की आवश्यकता होती है, चाहे आप उनका उपयोग करें या नहीं।

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

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

Comments

मैंने स्वयं इसकी कोशिश नहीं की है, लेकिन मैंने उन लोगों के ब्लॉग पोस्ट देखे हैं, जो Emacs के साथ कमांड-लाइन रैकेट प्रोग्राम का उपयोग करते हैं। उदाहरण के लिए: bc.tech.coop/scheme/scheme-emacs.htm

— लैरी कोलमैन

सभी निष्पक्षता में ऐसा लगता है जैसे आप एक मुहावरेदार योजना पीओवी से चीजों को प्राप्त करने की कोशिश करने के बजाय सीएल लिखना चाहते हैं। उदाहरण के लिए, योजना लूप का उपयोग करने के बजाय पुनरावृत्ति को प्रोत्साहित नहीं करती है?

— स्लेज

@ArtB योजना केवल पुनरावृत्ति को प्रोत्साहित नहीं करती है, इसके लिए इसकी आवश्यकता होती है, इसलिए निश्चित रूप से ऊपर उल्लिखित परियोजना ने बहुत सारी पुनरावृत्ति का उपयोग किया है। और यह सिर्फ पुनरावृत्ति को जोड़ने के लिए कार्य किया गया था (आपको फॉर्म की प्रत्येक शाखा में पुनरावर्ती कॉल की एक प्रति शामिल करनी होगी cond, उदाहरण के लिए) और बग्स (क्या मैंने उस समय लूप समाप्ति परीक्षण सही ढंग से लिखा था?) आज भी, मुझे आभास मिलता है? रैकेट मुख्य रूप से छात्रों और पेशेवर प्रोग्रामर के लिए अभिप्रेत है। हर बार जब मैं अपने अलावा किसी और के बारे में सुनता हूं, तो वे "बिगिनिंग स्टूडेंट" का उपयोग करते हैं और यह एक क्लास के लिए होता है।

— खाता

यदि आप CONDs में कोड दोहरा रहे हैं तो क्या आप कह रहे हैं कि आपको एक और फ़ंक्शन की आवश्यकता है?

— स्लेज

@ArtB विभिन्न तर्कों के साथ लूप फ़ंक्शन को कॉल करने के लिए एक फ़ंक्शन? यह व्यर्थ की तरह होगा। आप किसी के स्कीम कोड के बारे में सिर्फ उसी तरह का दोहराव देखते हैं। रैकेट के स्वयं के स्रोत कोड में और भी उदाहरण हैं।

— अकाउंट

Answer 5

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

केवल R5RS हाइजीनिक मैक्रोज़ के साथ योजना कार्यान्वयन का उल्लेख करना मुश्किल है, क्योंकि मेरे रूपक शैली का स्वच्छता पर पर्याप्त रूप से अनुवाद नहीं किया जा सकता है।

सौभाग्य से, वहाँ योजना कार्यान्वयन (उदाहरण के लिए, रैकेट) है कि सीमा नहीं है।

Comments

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

— नारंगी Jun०

@ Orange80, एक दृष्टिकोण docs.racket-lang.org/mzlib/mzlib_defmacro.html का उपयोग करना है और निश्चित रूप से, R6RS मोड में कम प्रतिबंधात्मक तरीका है।

— तर्क

@ एसके-लॉजिक क्या आप मैक्रोज़ के साथ कर रहे हैं जो इतना अनहेल्निक है?

— स्लेज

@ एआरटीबी, मैं ईडीएसएल को कंपाइलर फ़ंक्शन के रूप में लागू कर रहा हूं जो उनके स्रोत एएसटी के साथ काफी कुछ कर सकता है। इस तरह के दृष्टिकोण के भीतर स्वच्छता एक कुल उपद्रव है। आप देख सकते हैं कि यह कैसे काम करता है: github.com/combinatorylogic/mbase

— SK-logic