विभिन्न भाषा कार्यान्वयनों में यूनिकोड पहचानकर्ता समर्थन को जोड़ने का क्या मतलब है?

14

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

unicode

— Egor Tensin
स्रोत

1

क्या आप चीजों के लिए नाम का मतलब है, या आप सितारों, लैम्ब्डा और मध्य डॉट्स जैसे विशेष पात्रों का मतलब है?

— फ्रैंक शियरार

5

जबरदस्त हंसी ! क्या आप जानते हैं कि अंग्रेजी बोलने वाली प्रतियोगिता के बाहर एक दुनिया मौजूद है। Amazign खोज, है ना?

— डेडलिंक

3

deadalnix: मैं ऐसे देश में रहता हूं, इसलिए हम जैसे पहचानकर्ता का उपयोग कर सकते हैं größe। उस ने कहा, मैं ऐसा कभी नहीं करता और मैं दृढ़ता से ऐसा करने को हतोत्साहित करता हूं। इसलिए, उद्धरण बहुत ही मान्य है।

— 14:28 पर user281377

2

deadalnix: मैं अब तक एक अंग्रेजी भाषी देश में कभी नहीं रहा। वास्तविक प्रश्न पर ध्यान क्यों नहीं दे रहे, प्रश्नकर्ता पर नहीं?

— ईगोर टेन्सिन

6

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

— मैथ्यू एम।

17

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

लेकिन अगर यूनिकोड का गलत तरीके से उपयोग किया जा सकता है, तो इसका मतलब यह नहीं है कि स्रोत कोड में यह अपने आप खराब है।

यूनिकोड के साथ एक विशिष्ट क्षेत्र के लिए कोड लिखते समय, आप अपने कोड को छोटा कर सकते हैं और इसे अधिक पठनीय बना सकते हैं । के बजाय:

const numeric Pi = 3.1415926535897932384626433832795;
numeric firstAlpha = deltaY / deltaX + Pi;
numeric secondAlpha = this.Compute(firstAlpha);
Assert.Equals(math.Infinity, secondAlpha);

तुम लिख सकते हो:

const numeric π = 3.1415926535897932384626433832795;
numeric α₁ = Δy / Δx + π;
numeric α₂ = this.Compute(α₁);
Assert.Equals(math.∞, α₂);

जो एक औसत डेवलपर के लिए पढ़ना आसान नहीं हो सकता है, लेकिन एक ऐसे व्यक्ति के लिए पढ़ना आसान है , जो रोजाना गणितीय प्रतीकों का उपयोग करता है ।

या, एसएलआर फोटोग्राफी से संबंधित एक आवेदन करते समय, इसके बजाय:

int aperture = currentLens.GetMaximumAperture();
Assert.AreEqual(this.Aperture1_8, aperture);

आप एपर्चर को प्रतीक per द्वारा प्रतिस्थापित कर सकते हैं , एक लेखन के साथ ƒ/1.8:

int ƒ = currentLens.GetMaximumƒ();
Assert.AreEqual(this.ƒ1¸8, ƒ);

यह असुविधाजनक हो सकता है : सामान्य C # कोड टाइप करते समय, मैं लिखना पसंद करूंगा:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.Average()
double sum = this.ProductPrices.Sum();

बजाय:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.x̅()
double sum = productPrices.Σ();

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

यह कहा जा रहा है, यह अभी भी कुछ मामलों में उपयोगी है। currentLens.GetMaximumƒ();मेरे पिछले उदाहरण में IntelliSense पर भरोसा किया जा सकता है और यह GetMaximumApertureछोटा और अधिक पठनीय होने के साथ टाइप करना आसान है । इसके अलावा, बहुत सारे प्रतीकों वाले विशिष्ट डोमेन के लिए, कीबोर्ड शॉर्टकट प्रतीक को कोड में उनके शाब्दिक समकक्षों की तुलना में जल्दी टाइप करने में मदद कर सकते हैं ।

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

^{Enjoy मैं निश्चित रूप से C # कोड में फुटनोट्स का आनंद नहीं ले पाऊंगा, जहां टिप्पणियों को लिखने के स्टाइल नियमों का एक सख्त सेट है। दूसरी ओर PHP में, अगर बहुत सारी चीजें समझाना हैं, लेकिन वे चीजें बहुत महत्वपूर्ण नहीं हैं, तो उन्हें फाइल के निचले हिस्से में क्यों न डालें, और विधि के PHPDoc में एक फुटनोट बनाएं ?}

— आर्सेनी मूरज़ेंको
स्रोत

ASCII में 37 वर्ण शामिल हैं जिनका उपयोग पहचानकर्ताओं में किया जा सकता है; मैं उम्मीद करूंगा कि ज्यादातर फोंट में, वे पर्याप्त रूप से स्पष्ट रूप से स्पष्ट हैं कि यहां तक कि लैटिन वर्णमाला में धाराप्रवाह नहीं लोग भी अलग-अलग फोंट में वर्णों के दो तार बताना सीख सकते हैं, वही पहचानकर्ता थे। जब एक प्रोग्रामर "Φ" के बजाय कोण के लिए "an" का उपयोग करता है, तो डिबगिंग का कितना प्रयास बेकार हो रहा है?

— सुपरकाट

1

@ सुपरकैट: अच्छी बात है। लेकिन आप जो उदाहरण देते हैं, वह उपकरण के खराब उपयोग को दिखाता है बजाय इसके कि उपकरण ही खराब है। Δxया -∞मान्य उपयोग हैं (कुछ कमियों के साथ जिन्हें मैंने अपने उत्तर में समझाया था)। Ф/ Φदूसरी ओर सिर्फ संकेत हैं कि प्रोग्रामर समझ नहीं पा रहा है कि वेरिएबल्स को ठीक से कैसे नाम दिया जाए।

— आर्सेनी मूरज़ेंको

1

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

— सुपरकैट

1

@ सुपरकैट: आपका मतलब ग्रीक अक्षर फी है? मेरा कहना यह है कि यदि प्रोग्रामर इस सिंबल का उपयोग ऐसे एप्लिकेशन में करता है जहां "संचयी वितरण फ़ंक्शन" शब्द अपेक्षित है, तो किसी भी व्यक्ति को डोमेन शब्दावली और प्रतीकों के बारे में पता होगा कि Φ का अर्थ क्या होगा। cumulativeDistributionFunctionकाफी लंबा है। CDFless से कम पठनीय है। cumDistFuncबदसूरत है। इसका अर्थ यह भी है कि यदि प्रोग्रामर इस संदर्भ में सिरिलिक छोटे अक्षर EF (the) का उपयोग करता है, तो यह केवल एक गलती है। उसी तरह, एक प्रोग्रामर एक गलत शब्द या एक गलत संक्षिप्त नाम का उपयोग कर सकता था।

— आर्सेनी मूरज़ेंको

1

यदि एक चर नाम अंडरस्क्राइबर्स से बना है, 0-9, az, और AZ, कोड की एक कॉपी के साथ कोई है जो कॉपी / पेस्ट (जैसे एक प्रिंटआउट) का समर्थन नहीं करता है, तो उसे सटीक रूप से पुन: पेश करने की उम्मीद कर सकता है। कोई व्यक्ति यह जानने के बिना "ɸ" को कॉपी करने की कोशिश कर रहा है कि इसका क्या मतलब है, यह बहुत आसानी से "to" के साथ समाप्त हो सकता है, और यहां तक कि अगर प्रोग्रामर जानता है कि यह "फी" माना जाता है, तो यह स्पष्ट नहीं होगा कि क्या "" "या" "" है उचित। [एक "लैटिन स्मॉल लेटर फ़ि" है, और एक "ग्रीक स्मॉल लेटर फ़ि" है - वे इस टिप्पणी फ़ॉन्ट में स्पष्ट रूप से अलग दिखाई देते हैं, लेकिन उदाहरण के लिए ल्यूसिडा सैन्स यूनिकोड]।

— सुपरकैट

8

में कहना चाहूंगा:

गैर-पेशेवरों और नौसिखियों को कम करने के लिए जो प्रोग्रामिंग सीखते हैं (जैसे स्कूल में) और अंग्रेजी नहीं जानते हैं। वे वैसे भी उत्पादन कोड नहीं लिखते हैं। मैंने कई बार कोड देखा है जैसे:
```
double upsos, baros;
cin >> upsos >> baros;
```
बस ग़रीब आदमी को अपनी भाषा में लिखने दें:
```
double ύψος, βάρος;
cin >> ύψος >> βάρος;
```

क्या आपको यह पसंद नहीं है?

class ☎ {
public:
    ☎(const char*);
    void 📞();
    void 🎧(👨);
};

☎ ☏("031415926");
☏.🎧(👨("Bob"));
ofstream f;
f.💾();

— ybungalobill
स्रोत

विडंबना यह है कि, "आपको यह पसंद नहीं है" के तहत कोड ठीक से प्रस्तुत नहीं करता है, जो इस बात का चित्रण करता है कि आप फंकी वर्णों का उपयोग करने से दूर क्यों रहना चाहते हैं।

— क्रिश

5

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

लेकिन ओपी सही इन्सोफर है: अब यह संभव है कि एक हिंदी बोलने वाले भारतीय को रूसी पहचानकर्ताओं और अरबी टिप्पणियों के साथ कोड बनाए रखना चाहिए। गरीब चीनी के लिए क्या बुरा सपना है जो गुणवत्ता की जांच करने वाला है और जो उपरोक्त 3 वर्णमालाओं में से किसी को भी नहीं पढ़ सकता है!

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

— इंगो
स्रोत

यूनिकोड पहचानकर्ताओं को अनुमति देने के साथ एक समस्या यह है कि यह स्रोत कोड को ऐसी जानकारी शामिल करने की अनुमति देता है जो शब्दार्थ से महत्वपूर्ण है लेकिन प्रिंट करने योग्य नहीं है। उदाहरण के लिए, यदि कोई वर्ग फ़ील्ड घोषित करता है А, तो उसका निर्माता पैरामीटर स्वीकार करता है Α, और निर्माता का एक कथन कहता है var x = A.boz();, क्या Aफ़ील्ड, पैरामीटर या शायद कुछ और का उल्लेख होगा ? कोई कैसे बता सकता है?

— सुपरकैट

1

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

— ingo

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

— सुपरकैट

4

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

— nikie
स्रोत

8

ज़रुरी नहीं। स्ट्रिंग शाब्दिक में, गैर-एएससीआईआई पात्रों को अपारदर्शी माना जा सकता है। पहचानकर्ताओं के साथ, आपको यह निर्णय लेने की आवश्यकता है कि कौन से वर्ण मान्य हैं, और क्या उन्हें सामान्य करना है (जैसे, várवैसा ही है vár?)

— dan04

4

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

विपणन तर्क

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

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

और इस तरह वे दावा कर सकते हैं: "आह, वाई के साथ आपके पास आपके पहचानकर्ताओं के लिए यूनिकोड समर्थन नहीं है! एक्स में हम ऐसा करते हैं, इसलिए छात्रों के लिए यह बहुत आसान है!"

सुगमता की पराकाष्ठा

दुर्भाग्य से, अभिगम्यता का तर्क निराशाजनक है।

ओह, मैं समझता हूं कि "diceThrowResult" के बजाय "résultatDuJetDeDé" लिखने में सक्षम होने के नाते (हाँ मैं फ्रांसीसी हूं) अल्पावधि में एक जीत की तरह लग सकता है ... हालांकि कमियां हैं!

प्रोग्रामिंग संचार के बारे में है

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

इसे पढ़ने से तात्पर्य है कि आपके द्वारा उपयोग किए गए पात्रों की कल्पना करने में सक्षम, यूनिकोड सभी फोंट द्वारा इतनी अच्छी तरह से समर्थित नहीं है
इसे समझने का मतलब पहचानकर्ताओं पर निर्भर होना है - जब तक कि आप उन्हें भद्दी टिप्पणियों के साथ पूरक नहीं करते हैं, लेकिन यह DRY नियम का उल्लंघन है।

बेशक, आपका सहपाठी वही भाषा बोल सकता है जो आप करते हैं (स्पष्ट नहीं, मेरे पास जर्मन, स्पेनिश, लिबाने और चाइनस के साथ प्रोग्रामिंग कक्षाएं थीं), और इसलिए आपका शिक्षक हो सकता है ... लेकिन मान लीजिए कि किसी तरह आप घर पर काम कर रहे हैं और अचानक मदद की जरूरत है: इंटरनेट महान है, आप हजारों हजारों लोगों से बात कर सकते हैं जो समाधान जानते हैं, वे केवल तभी जवाब देंगे जब वे आपके प्रश्न को समझेंगे। और आपको उनका जवाब भी समझने की जरूरत है।

प्रोग्रामिंग के लिए समझ की आवश्यकता होती है

एक्सेसिबिलिटी और दीक्षा को आपके लिए हेवीलाइनिंग करने के लिए खुद को पुस्तकालयों पर आधारित करने की आवश्यकता होती है: आप अपने पहले असाइनमेंट पर कंसोल से पढ़ने / लिखने के लिए एक IO परत को फिर से बनाना नहीं चाहते हैं।

वे पुस्तकालय किस भाषा में लिखे गए हैं?
वे पुस्तकालय किस भाषा में प्रलेखित हैं?

अगर आप मोरोकान अरबी का जवाब देते हैं, तो मुझे आश्चर्य होगा।

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

अंग्रेजी है...

... प्रोग्रामर (और अधिकांश वैज्ञानिकों) का लिंगुआ फ्रेंका।

जितनी जल्दी कोई इसे स्वीकार करता है, और इसके खिलाफ लड़ने के बजाय इसके साथ जाता है, जितनी जल्दी यह वास्तव में सीख सकता है और प्रगति कर सकता है।

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

फिर भी...

हां, जैसा कि यह तर्क दिया गया था कि कुछ यूनिकोड समर्थन (मुख्य रूप से प्रतीक) गणितीय या भौतिक विज्ञान के सूत्रों का अनुवाद करने वाले लोगों के लिए समझ को बहुत कम कर सकते हैं, उदाहरण के लिए, कोड में। दोष यह है कि कुछ प्रतीक अतिभारित हैं, लेकिन यह अभी भी मदद कर सकता है।

तो क्यों ?

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

और कुछ उपयोगकर्ताओं के लिए एक लाभ हो सकता है।

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

— मैथ्यू एम।
स्रोत

तो आप उन लोगों में से एक हैं जो ऐतिहासिक रूप से वास्तविक वास्तविकताओं को डी ज्यूरों में बदलने के लिए तैयार हैं (उच्चारण की कमी को क्षमा करें, किसी को भी इन दिनों परवाह नहीं है)?

— मिलिंद आर

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

— बनायेंगे

3

आप चीनी कीबोर्ड पर ASCII पहचानकर्ता कैसे टाइप करने जा रहे हैं? कुछ भाषा कीवर्ड एक बात है, और अपना पूरा कोड इस तरह से करना है।

प्रोग्रामर के पास अपने वैरिएबल को कॉल करने का अधिकार और क्षमता होनी चाहिए। यह आपके व्यवसाय में से कोई भी नहीं है कि वह किस भाषा में है।

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

— DeadMG
स्रोत

4

मैं "रूसी" कीबोर्ड का उपयोग करके यह संदेश टाइप कर रहा हूं। मैंने चीनी कीबोर्ड देखा है ( goo.gl/U1q0m ) और मुझे वास्तव में रूसी एक ( goo.gl/af04R ) के साथ कोई अंतर नहीं दिखता है । ध्यान दें, वैसे, दोनों का मूल निवासी के साथ लैटिन लेआउट है।

— ईगोर टेन्सिन 18

2

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

— ईगोर टेन्सिन

2

3 पैरा केवल अंग्रेजी का उपयोग करने का सटीक कारण है, है ना?

— एंटोन बार्कोवस्की

9

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

— डेडएमजी नोव

3

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

— माइकल बोर्गवर्ड 12

2

पीईपी 3131 के अनुसार - 2007 में दिनांकित गैर-एएससीआईआई पहचानकर्ताओं का समर्थन , राशनले राज्यों का पहला भाग:

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

मैंने अभी तक अन्य भाषाओं की जांच नहीं की है, लेकिन यह उन कारणों में से होना चाहिए, जिन्होंने समर्थन जोड़ा है।

— 吴烜 _ 中文编程
स्रोत

1

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

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

यूनिकोड राइट-टू-लेफ्ट टिप्पणियां मजाकिया भी हो सकती हैं। उदाहरण के लिए, वीएस 2010 में, XML टिप्पणियाँ (सही ढंग से) कोड में RTL के रूप में प्रदर्शित होती हैं ... लेकिन जब आप कोड में कहीं और पहचानकर्ता को खींचने के लिए Intellisense का उपयोग करते हैं, तो टूलटिप प्रदर्शित करता है (गलत तरीके से) LTR। बेहतर, शायद, अगर पहले स्थान पर कोई समर्थन नहीं था? फिर, एक आसान कॉल नहीं।

— sq33G
स्रोत