जावा से क्लोजर कितना स्वतंत्र है?

Question

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

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

लेकिन अन्य कार्यों के लिए मुझे कोई कारण नहीं दिखता है कि देशी क्लोज़र लाइब्रेरी विकसित नहीं हो सकी। Http, तारीख में हेरफेर, XML पार्सिंग, टेम्प्लेटिंग, JSON सीरियलाइज़ेशन और डीरिएरलाइज़ेशन, OAuth, गणित लाइब्रेरी आदि के बारे में सोचें।

तो मेरा सवाल है:

जावा पारिस्थितिक तंत्र से स्वतंत्र होने के लिए क्लोजर कितनी दूर आया है? क्या इनमें से अधिकांश और अन्य कार्यों के लिए इसके अपने मुहावरेदार पुस्तकालय हैं?

Comments

ClojureCLR .Net फ्रेमवर्क के लिए एक Clojure पोर्ट है।

— एसएल बर्थ -

मेरे स्वाद के लिए, जावा में बहुत अधिक क्लोजर कोर लागू किया गया है, यह ठीक से बूटस्ट्रैप नहीं है।

— एसके-तर्क

@ बर्थ: मुझे पता है कि अन्य प्लेटफार्मों पर पोर्ट मौजूद हैं, लेकिन यह सवाल के बारे में बहुत कुछ नहीं बताता है। यह सीएलआर पर चल सकता है और अभी भी इसकी अपनी लाइब्रेरी नहीं है।

— एंड्रिया

@JeremyHeiler, निश्चित रूप से एक ध्वनि दिमाग में कोई भी इस तरह के लक्ष्य को प्राप्त करने की कोशिश करेगा। सवाल है - क्लोजर को शुरू से ही इस तरह लागू क्यों नहीं किया गया? यह जावा में एक कंपाइलर को कोड करने की तुलना में बहुत आसान है।

— SK-तर्क

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

— जेरेमी हेइलर

Answer 1

क्लोजर जावा पुस्तकालयों के अधिक से अधिक स्वतंत्र होता जा रहा है क्योंकि इसका कोड बेस बढ़ता है और स्वाभाविक रूप से विविधता लाता है। क्लोजर की एक प्रमुख ताकत यह है कि इसे जावा कह सकते हैं, इसलिए भविष्य में क्लोजर कोड को देखने के लिए जो जावा का उपयोग नहीं करता है, संभावना नहीं होगी। कहा जा रहा है, मैंने जावा लिबास (कमांड लाइन आर्ग्स, बेसिक टेक्स्ट मिनुपुलेशन, आदि) को कॉल करते हुए विकास w / o का एक अच्छा सौदा किया है। यहां शुद्ध क्लोजर लाइब्रेरी की सूची दी गई है: http://www.clojure-toolbox.com/

Comments

मैंने शुद्ध क्लॉजुर लाइब्रेरी के भंडार के लिंक के लिए इस उत्तर को चुना है।

— एंड्रिया

Answer 2

मुझे लगता है कि यह कहना उचित है कि क्लोजर को एक मेज़बान भाषा के रूप में डिज़ाइन किया गया है और अब इसके तीन कार्यान्वयन हैं:

• JVM पर क्लोजर
• .NET पर ClojureCLR
• जावास्क्रिप्ट पर ClojureScript

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

मैं clojure.java.jdbc और clj-time (JodaTime के चारों ओर एक आवरण) बनाए रखता हूं, इसलिए इसका मतलब यह नहीं है कि वे * CLR या * स्क्रिप्ट संस्करणों पर उन का उपयोग करें, लेकिन विभिन्न नामस्थानों में API- संगत लाइब्रेरी एक संभावना हो सकती है।

"शुद्ध" क्लोजर लाइब्रेरी में से कई पहले से ही * सीएलआर या * स्क्रिप्ट संस्करणों पर उपयोग करने के लिए सीधी होनी चाहिए।

ओपी के प्रश्न के लिए: "क्लोजर-द-लैंग्वेज" बहुत पोर्टेबल है, लेकिन "क्लोज्योर-ए-इम्प्लीमेंटेशन" जानबूझकर जावा इकोसिस्टम के लिए बाध्य है, जैसा कि क्लीजुरेसीएलआर से .NET और क्लोजुरस्क्रिप्ट से जावास्क्रिप्ट में है।

Answer 3

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

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

नोट: मैं क्लजुरे समुदाय में गहराई से शामिल नहीं हूं, इसलिए यह आंशिक रूप से हार्स / अनुमान है।

Comments

संदर्भ के लिए: क्लोजुरे के लिए क्यों इनवॉकेन्डेमिक उपयोगी नहीं हो सकता है

— जेरेमी