परिचय
70 के दशक के बाद से, सरलीकृत अंग्रेजी विकसित हो रही है, जिसका उद्देश्य भाषा का एक सबसेट निर्धारित करना है जो भाषा के गैर-देशी वक्ताओं की एक विस्तृत श्रृंखला के लिए समझ में आता है। अनुशंसित, उदाहरण के लिए, तकनीकी दस्तावेज के लिए। इस तरह के सबसेट पर स्वचालित अनुवादक स्पष्ट रूप से और अधिक सही ढंग से काम करेंगे, आदर्श रूप से पाठ उत्पन्न करने के लिए जिसे मैन्युअल प्रूफरीडिंग की आवश्यकता नहीं है।
यदि आप इस दृष्टिकोण को अन्य प्रोग्रामिंग भाषाओं में कोड को स्वचालित रूप से परिवर्तित करने के कार्य के लिए C # पर लागू करते हैं, तो आप भाषा निर्माण, सिस्टम लाइब्रेरी और तकनीकों का एक सबसेट चुन सकते हैं, जिन्हें संभवतः अन्य भाषाओं की एक विस्तृत श्रृंखला में अनुवादित किया जा सकता है। इसके अलावा, रूपांतरण एक बार (माइग्रेशन) नहीं है, लेकिन सी # में परियोजना की एकीकरण क्षमताओं का विस्तार करने के लिए निरंतर है - ताकि किसी भी समय आप किसी भी संपादन की आवश्यकता के बिना किसी अन्य भाषा में एक कार्य कोड प्राप्त कर सकें।
मुझे परिचय दें: UniSharping
इस समस्या को हल करने के लिए C # .NET के प्रतिबंध को U # (यूनिवर्सल शार्प) कहा गया, और रूपांतरण प्रक्रिया और इसके उपकरण को UniSharping कहा गया । निष्पादन योग्य मॉड्यूल, सेटिंग्स और प्रलेखन GitHub पर उपलब्ध हैं, सिस्टम गैर-व्यावसायिक उपयोग (गैर-वाणिज्यिक फ्रीवेयर) के लिए स्वतंत्र है।
क्रॉस-प्लेटफ़ॉर्म के लिए, Microsoft पहले से ही पुस्तकालयों और प्रौद्योगिकियों के संदर्भ में .NET फ्रेमवर्क की एक सीमा बना चुका है: .NET कोर। यह सही दिशा में पहला कदम है, यू # "क्रॉस-प्रोग्रामेबिलिटी" के लिए दूसरा कदम उठाता है।
भाषा के निर्माण में कुछ यू # सीमाएं थीं - ये गोटो और केस गोटो एटविज्म हैं, साथ ही उपज, जो स्वचालित मोड में पर्याप्त रूप से मॉडलिंग नहीं की जाती है। यह अनुशंसित नहीं है (हालांकि यह संभव है) संरचना का उपयोग करने के लिए, नामों के साथ बारीकियां हैं - यह सब एक अलग दस्तावेज़ में विस्तार से वर्णित है। यू # पार्सर त्रुटियां और चेतावनी देता है, और सही पीढ़ी की गारंटी देने के लिए, आपको सी # स्रोत कोड को समायोजित करना चाहिए ताकि वे आदर्श रूप से पूरी तरह से गायब हो जाएं। यदि आपको अभी भी मूल संस्करण रखने की आवश्यकता है, तो आप प्रीप्रोसेसर निर्देशों का उपयोग कर सकते हैं #if JAVA || PHP ... #else ... #endif। ये प्रतिबंध यू # इंजन के स्तर पर लागू होते हैं और बाहरी सुधार के साथ-साथ समर्थित भाषाओं की सूची के अधीन नहीं होते हैं।
लेकिन सिस्टम लाइब्रेरी के स्तर पर प्रतिबंधों को सख्ती से सेट नहीं किया जाता है और बाहरी रूप से विशेष पाठ फ़ाइलों के माध्यम से कॉन्फ़िगर किया जाता है जो यह निर्धारित करते हैं कि किसी विशेष वर्ग और उसके सदस्यों को संबंधित भाषा में कैसे अनुवाद किया जाए। यदि कोई प्रत्यक्ष एनालॉग है, तो यह इंगित किया जाता है, यदि स्थिति अधिक जटिल है, तो या तो अंतिम भाषा के कोड का एक टुकड़ा लिखा जाता है, या सामान्य रूप से एक विशेष (सेवा) वर्ग जो वांछित समस्या को हल करता है। बहुत मुश्किल मामलों में, आपको इंजन स्तर पर "हार्डकोड" करना होगा, लेकिन ऐसी स्थितियां काफी दुर्लभ हैं (लगभग एक दर्जन)। सिस्टम कक्षाएं और उनके सदस्यों को स्थापित करने की प्रक्रिया को एक अलग दस्तावेज़ में वर्णित किया गया है। यहां साइट पर वर्तमान संस्करण में जावा और पायथन में एनालॉग्स के साथ समर्थित सी # कक्षाएं और उनके सदस्यों की एक सूची है , एक ऑनलाइन डेमो भी है।
प्रौद्योगिकी के लिए, अब सूची कंसोल एप्लिकेशन और यूनिट परीक्षणों (यूनिटटेस्ट) तक सीमित है। खैर, एक विशेष मामले के रूप में, व्यक्तिगत लिब परियोजनाओं को वांछित भाषा के संगत निर्माण में अनुवादित किया जाता है।
एक सफल अनुवाद के लिए, स्रोत C # प्रोजेक्ट (समाधान) में कुछ स्टार्ट-अप हिस्सा होना चाहिए जो स्रोत C # के भीतर कार्यक्षमता की जांच करता है। यह अच्छा है अगर यह ऑटो-टेस्ट (विभिन्न कार्यान्वयन या स्व-लिखित में मानक यूनिटटेस्ट) की एक व्यापक प्रणाली है, लेकिन कम से कम एक कंसोल एप्लिकेशन होना चाहिए जो किसी भी उपयोगकर्ता के हस्तक्षेप के बिना लॉन्च किए जाने पर सही ढंग से काम करता हो। इसके लिए आवश्यकता स्पष्ट है - अंतिम भाषा में पीढ़ी के बाद, आप तुरंत प्रदर्शन की जांच कर सकते हैं। आदर्श रूप से, सभी परीक्षणों को C # के समान काम करना चाहिए।
परियोजना का इतिहास
इस तरह के एक कनवर्टर का विचार लंबे समय से आसपास है। मेरी मुख्य प्राकृतिक भाषा प्रसंस्करण एसडीके पुलेंटी परियोजना रूपांतरण के लिए एक आदर्श उम्मीदवार है: बड़ी मात्रा में जटिल और लगातार सुधार कोड। जावा के साथ एकीकृत करने के लिए, मुझे इसे वेब सेवाओं, टीसीपी सर्वर आदि में लपेटना पड़ा।
पिछली गर्मियों में, मुझे पहला विकल्प बनाने के लिए समय और ऊर्जा मिली। उन्होंने पुलेंटी परियोजना का जावा में अनुवाद किया, साथ ही स्वयं जावा में भी।
अगले छह महीनों में, कनवर्टर कई आंतरिक परियोजनाओं पर विकसित हुआ जो कंपनी में थे, मुख्य रूप से सिस्टम कक्षाओं के विस्तार के माध्यम से।
2018 के वसंत में, पायथन का समर्थन करने का विचार आया, जिसे गर्मियों में लागू किया गया था। लेकिन प्रारंभिक संस्करण में एक दूसरी भाषा का समावेश प्रदान नहीं किया गया था और यह अनाड़ी निकला। गर्मियों में मुझे कई अंतिम भाषाओं की क्षमता के लिए इंजन को पूरी तरह से फिर से तैयार करना पड़ा। इसके अलावा, हार्डकोड से सिस्टम कक्षाओं के लिए सेटिंग्स को बाहरी पाठ फ़ाइलों में ले जाया गया। मुझे उम्मीद है कि आपकी मदद के बिना इस सेट का विस्तार नहीं होगा।
आगे की योजना इस प्रकार हैं:
- पायथन को जावा स्तर तक खींचें। पायथन को अब पुलेंटी स्तर पर समर्थित किया गया है, लेकिन जावा इसकी तुलना में अन्य परियोजनाओं पर बहुत आगे निकल गया है।
- Pullenti प्रोजेक्ट स्तर पर PHP का कम से कम समर्थन करें।
- C ++ का समर्थन करें। हां, मुझे एहसास है कि यह बहुत मुश्किल है, क्योंकि यह स्पष्ट नहीं है कि मेमोरी को मुक्त करते समय कौन सी पॉइंटर एक लिंक है और जिसके लिए डिलीट किया जाना चाहिए। लेकिन विचार हैं ...
कौन काम आ सकता है
ज्यादातर वे जो C # में संभावित क्रॉस-प्लेटफॉर्म SDKs विकसित करते हैं। UniSharping कनवर्टर के लिए धन्यवाद, उनका SDK "क्रॉस-सॉफ़्टवेयर" भी बन सकता है, जो संभावित उपयोगकर्ताओं के सर्कल का विस्तार करेगा।
हाल ही में, रूस में एसटीआर की स्थिति मजबूत हुई है, जो अधिकांश सरकारी एजेंसियों और कुछ बड़ी कंपनियों में अनिवार्य हो गई है। बता दें कि .NET कोर भी हमेशा काम नहीं करता है, क्योंकि यह "Microsoft" है। चलो कुछ कंपनी C # में अपनी सूचना प्रणाली विकसित करती है। उत्पाद को "ओपन सोर्स कंपनी" में पेश करने के लिए, आप प्रोजेक्ट के लॉजिकल पार्ट (बैक-एंड) का चयन कर सकते हैं, स्वचालित रूप से इसे आवश्यकतानुसार रिलीज़ में बदल सकते हैं और विजुअल पार्ट (फ्रंट-एंड) को ओपन सोर्स सॉफ़्टवेयर में बना सकते हैं। यही है, सी # में विकास जारी रखने के लिए, और जावा में केवल फ्रंट-एंड।
मैं बाहर नहीं करता कि सिद्धांत रूप में वेब परियोजनाओं का रूपांतरण संभव है (सीमाओं के साथ), लेकिन मेरे पास इसके लिए आवश्यक कौशल और जानकारी नहीं है। यदि किसी को भी ऐसा अवसर दिखाई देता है, तो इसे UniSharping में लागू करना काफी संभव है।
मैं ध्यान देता हूं कि एक वास्तविक जटिल सी # परियोजना के लिए, जावा या किसी अन्य भाषा का समर्थन करने से कोड को संशोधित करने, परियोजना में पोर्टेबल भाग को उजागर करने और इकाई परीक्षणों के साथ इसे "घेरने" के लिए कुछ प्रयास करने की आवश्यकता होगी। इसके अलावा, अभी भी असमर्थित सिस्टम क्लासेस और मेथड्स को सेट करना और UniSharping की त्रुटियों को ठीक करना (मेरी मदद से) अभी भी काम है। लेकिन प्रक्रिया अभिसरण है, जिसके अंत में परियोजना एक क्रॉस-प्रोग्रामर बोनस की उम्मीद करती है।