+1
मैं वास्तव में ऐसा होते देखना चाहूंगा।
अधिक पठनीय जैसे end अनुक्रमण के लिए उपयोग किया जाता है।

+1
दिसंबर 27, 2013 1:06 pm पर, "GaborOszlanyi" [email protected] लिखा है:

+1
मैं वास्तव में ऐसा होते देखना चाहूंगा।
अनुक्रमण के लिए उपयोग किए जाने वाले अंत की तरह अधिक पठनीय।

-
इस ईमेल का सीधे उत्तर दें या इसे Gi tHub पर देखेंhttps://github.com/JuliaLang/julia/issues/5238#issuecomment -31280112
.

मुझे भी यह सुझाव पसंद है।

इसे मिल रहे समर्थन से मैं थोड़ा हैरान हूं। मैंने हमेशा महसूस किया है कि वर्तनी वाले ऑपरेटर नियंत्रण प्रवाह के लिए अधिक सहज थे, लेकिन मुझे नहीं पता था कि भावना व्यापक थी।

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

मैंने देखा है कि जो भाषाएं and और or (पर्ल, रूबी, लुआ - जिन्हें मैंने चेक किया है) प्रदान करती हैं, वे भी not प्रदान करती हैं (लुआ भी पेशकश नहीं करती है ! )। मेरी पहली प्रतिक्रिया यह है कि मुझे यह पसंद नहीं है, क्योंकि यह ! साथ बेमानी है। लेकिन शायद इसका एक मजबूत कारण है कि इन भाषाओं ने ऐसा करना क्यों चुना।

मुझे व्यक्तिगत रूप से not बहुत पसंद है, लेकिन ऐसा नहीं लगता कि not स्विच करने से अस्पष्टता में कमी जैसी कोई चीज़ मिलती है जो and और or प्रदान करती है।

not शॉर्ट सर्किट/कंट्रोल फ्लो ऑपरेशन भी नहीं है, और मैं हमेशा संघर्ष करता हूं कि सहयोगीता के संबंध में इसे कैसे पढ़ा जाए। पाइहटन में मुझे यह एकमात्र जगह पसंद है if not ... लेकिन ऐसा इसलिए है क्योंकि मैंने इसे नियंत्रण प्रवाह संचालन के रूप में पढ़ा है।

+1

XOR को शॉर्ट सर्किट के रूप में भी जोड़ा जा सकता है?
और उल्टे संस्करणों का शॉर्ट सर्किट संस्करण (XNOR,NAND,NOR)?

एक्सओआर कभी भी शॉर्ट-सर्क्युटेबल नहीं होता है। अन्य को ! प्लस and और or ऑपरेटरों के साथ तुच्छ रूप से लिखा जा सकता है।

+1
मैं बताऊंगा कि रूबी में, && बनाम 'और' (http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/) के बारे में लगातार भ्रम है, इसलिए यह अच्छा होगा यदि हम उस तर्कसंगतता को ध्यान में रखें जिसका उपयोग रूबी ऑपरेटरों के दोनों सेटों के लिए करता है और यह तय करता है कि क्या यह भ्रम के लायक है या यदि && को पूरी तरह से 'और' के पक्ष में हटा दिया जाना चाहिए।

मैं and और or लिए पसंद करूंगा, जैसे कि वे पर्ल और रूबी में करते हैं ताकि आप चीजों को लिख सकें

k <= n and k *= 2

कभी-कभी आप बूलियन परिणाम को किसी चीज़ पर असाइन करना चाहते हैं:

cond = f() && g()

जिसका विरोध होता दिख रहा है।

खैर, यही कारण है कि रूबी और पर्ल के पास अलग-अलग प्राथमिकता वाले ऑपरेटरों के दोनों सेट हैं। इसकी पैरवी नहीं कर रहे हैं, बस कह रहे हैं। मुझे यकीन नहीं है कि यह उपयोग वास्तव में कितना सामान्य है, जबकि हमारे कोड के माध्यम से ग्रेपिंग करने से बहुत सी k <= n && (k *= 2) प्रकार की चीजें सामने आती हैं।

सबसे पहले, मैं and और or लिए भी हूं।
मैं देख रहा हूँ कि अभी जूलिया में सबसे कम चार वरीयता समूह हैं

1. += आदि, := , => , और ~ सहित असाइनमेंट
2. टर्नरी ऑपरेटर ?
3. ||
4. &&

मुझे लगता है कि यह अच्छी समझ में आता है ( ~ बारे में निश्चित नहीं है, लेकिन यह बिंदु के बगल में है)। तार्किक and और or असाइनमेंट के दाहिने हाथ की ओर और ? स्थिति के रूप में उपयोगी हैं। यदि आप and या or तर्क के रूप में असाइनमेंट या टर्नरी ऑपरेटर का उपयोग करने जा रहे हैं, तो मुझे लगता है कि आप जानते हैं कि आप कुछ असामान्य कर रहे हैं और कोष्ठक क्रम में हैं।

बीटीडब्ल्यू, मुझे लगता है कि बहुत से लोग उम्मीद करेंगे कि तार्किक संचालन के लिए and और or उपयोग करने वाली भाषा तार्किक अस्वीकृति के लिए not उपयोग करेगी। लेकिन अगर हमारे पास ! रखने का अच्छा कारण है, तो यह ठीक हो सकता है। (मुझे लगता है कि ! सख्ती से केवल तार्किक निषेध नहीं है, कम से कम अगर #4892 लागू किया गया है तो विलय कर दिया गया है।)

मैं के बारे में थोड़ा दु: खी होगा not के बजाय ! , लेकिन मैं यहाँ जो कुछ भी साथ जायेंगे।

मुझे वास्तव में नहीं लगता कि not बिल्कुल समान है - and और or नियंत्रण प्रवाह ऑपरेटर हैं, फ़ंक्शन नहीं, जबकि ! केवल एक फ़ंक्शन है।

मैं स्टीफन से सहमत हूं। केवल एक चीज not वास्तव में आपको उतनी ही कोष्ठक का उपयोग करने की आवश्यकता नहीं है। मुझे लगता है कि यह एक अलग मुद्दा है।

मैं सिर्फ नए यूजर्स की शुरुआती उम्मीदों के बारे में बात कर रहा था। लेकिन मैं सोचता हुँ
ऐसा लगता है कि रखने में सक्षम होने का एक अच्छा कारण है!

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

इस चर्चा के लिए http://en.wikipedia.org/wiki/Short-circuit_evaluation की तालिका कुछ प्रासंगिक हो सकती है।

जैसा कि कोई पायथन दुनिया से आ रहा है, मैं खुद को @GunnarFarneback के साथ समझौते में पाकर हैरान हूं। हाल ही में मैंने पाया है कि अंग्रेजी सशर्त ( and , or , not ) अक्सर मुझे गलत कोड लिखने के लिए प्रेरित करता है जिसे मैं काम करने की उम्मीद करता हूं (क्योंकि यह समझ में आता है अंग्रेजी) और फिर कुछ सेकंड के लिए अपना सिर खुजलाना पड़ता है, जबकि मैं मानसिक रूप से अपनी त्रुटि का एहसास करने से पहले अंग्रेजी से तार्किक बयानों में परिवर्तित हो जाता हूं। उस ने कहा कि मैं किसी भी दिशा में विशेष रूप से पक्षपाती नहीं हूं; बस मेरे 2¢ में डाल रहा हूँ।

मैं and और or लिए भी हूं

+1

+1
दोनों ऑपरेटर हैं
and और or कमजोर प्राथमिकता के साथ
मेरा तर्क है कि cond = f() && g() को cond = (f() && g()) लिखा जाना चाहिए।
मैं कमजोर पूर्वता के साथ not के उपयोग का भी समर्थन करता हूं क्योंकि ! , जिसकी मेरे द्वारा देखे गए हर संदर्भ में मजबूत पूर्वता है, के लिए if !(something and something) जो मुझे कुछ गहरी पसंद नहीं है , तर्कहीन और अपरिवर्तनीय स्तर। मुझे यह भी लगता है कि ! कभी-कभी देखना मुश्किल होता है। मैं ! की उत्पत्ति से भी अनजान हूं लेकिन मुझे लगता है कि पूर्णांक पर फैक्टोरियल ऑपरेटर के रूप में इसकी एक और सही जगह है - इस प्रकार मैटलैब के ~ सिंटैक्स के लिए प्राथमिकता।

@johnmyleswhite इस मुद्दे को बंद कर दिया जाए? मुझे लगता है कि जहाज इस पर रवाना हो गया है।

:(

शॉर्ट सर्किट वह भद्दा चेहरा

मुझे लगता है कि हमें अभी भी इस पर विचार करना चाहिए। बहुत से लोग && और || का उपयोग करना पसंद नहीं करते हैं जिस तरह से हम उनका उपयोग कर रहे हैं और and और or । वरीयता का मुद्दा भी है, जो && और || कुछ अजीब बनाता है। हम एक ऐसे भविष्य की ओर बढ़ सकते हैं जहां && और || लिए दोनों ऑपरेंड को बूलियन और and और or आवश्यकता है जो && और || वर्तमान में करते हैं लेकिन कम प्राथमिकता के साथ ताकि आप x == nothing and x = 0 आदि लिख सकें। या तो वह या x = 0 if x == nothing जैसे एक अलग एक-पंक्ति सशर्त वाक्यविन्यास पेश करें।

अंतिम वाक्य रचना x = 0 if x == nothing में आईएमओ की कुछ समस्याएं हैं जो https://groups.google.com/forum/#!topic/julia -dev/cnmLcNg8h0Q में सुझाव करता है।
क्या निम्नलिखित दो विकल्प इतने भयानक हैं कि जूलिया को पोस्ट-कंडीशन की आवश्यकता है?

    if x == nothing ; x = 0 ; end

या

   x == nothing && (x = 0)

उस ने कहा, जैसे मुझे जूलिया में repeat ; expr(s) ; until cond निर्माण देखने में कोई फर्क नहीं पड़ता (लेकिन इसके बिना रह सकता है), मुझे and और or होने में कुछ भी गलत नहीं दिखता है
वे C && और || से उधार लिए गए उपयोग की तुलना में जूलिया सिंटैक्स के साथ बेहतर फिट लगते हैं।

मुझे लगता है कि हमें अभी भी इस पर विचार करना चाहिए।

+1

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

isempty(o) || (m.over[s][NULL] = o)

इसके विपरीत, cond = (f() && g()) में कोष्ठक मुझे ठीक लगते हैं। मुझे लगता है कि मैं वैसे भी उनका इस्तेमाल करूंगा।

इसके लायक क्या है, इसके लिए मैं and और or भी पसंद करूंगा।

मुझसे भी +1।

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

एक तर्क के खिलाफ (पढ़ने में अधिक कठिन) मुझे लगता है कि गलत है। तर्क यह है कि 3 शब्दों बनाम शब्द SYMBOL शब्द के कारण foo and bar को foo && bar से पढ़ना अधिक कठिन है। हालांकि हर कोई सिंटैक्स हाइलाइटिंग का उपयोग कर रहा है, और इस मामले में विपरीत होता है। and एक कीवर्ड के रूप में रंगीन है, इसलिए a<1 and b>3 वास्तव में बाएं और दाएं उप-अभिव्यक्तियों को नेत्रहीन रूप से विभाजित करने के पक्ष में रंग देगा, जबकि a<1 && b>3 तीनों ऑपरेटर एक ही रंग के होंगे, क्यू संभावित ऑपरेटर-प्राथमिकता-सिर-खरोंच।

एक तर्क _for_ जो अभी तक प्रस्तुत नहीं किया गया है, वह यह है कि बूलियन ऑपरेटरों के शब्दों में एक सुरुचिपूर्ण स्थिरता है, क्योंकि ऑपरेशन का परिणाम या तो true या false , यानी एक शब्द भी। इसलिए शुरुआती के लिए बिटवाइज़ बनाम लॉजिकल के लिए & बनाम and को याद करना बहुत आसान है। & बनाम && याद रखना कहीं अधिक कठिन है, क्योंकि यह एक मनमाना असाइनमेंट प्रतीत होता है। गारंटीशुदा शुरुआती & गलत तरीके से उपयोग करेंगे, क्योंकि & अंग्रेजी में and शब्द को व्यक्त करता है। यह प्राथमिकता बग (?) का कारण बन सकता है।

एक और संभावित तर्क _for_ यह होगा कि मस्तिष्क स्वाभाविक रूप से {BUNCH OF SYMBOLS} शब्द {BUNCH OF SYMBOLS} को पार्स करता है।

सिर्फ स्विच क्यों नहीं? इसे करने के लिए अब हमेशा सबसे अच्छा समय है, यह अब से आसान कभी नहीं होगा। वर्तमान में && का उपयोग करने वाले कोड को ठीक करना बिल्कुल कठिन नहीं है।

है and or not xor शायद nand सिर्फ पूर्णता के लिए ?? मुझे ! रखने के विचार से कोई ऐतराज नहीं है। प्रोग्रामर को यह चुनने दें कि कब किसका उपयोग करना है। उसमें कोी बुराई नहीं है! कहने के बाद, ! पहले से ही foo! स्टाइल फ़ंक्शंस में उपयोग है, इसलिए कुछ "प्रतीक पुन: उपयोग को कम करें" तर्क है।

@StefanKarpinski 2013 से वापस डेटिंग के पक्ष में आम सहमति प्रतीत होती है, मैं इसे लागू करने का प्रयास कर सकता हूं, लेकिन मुझे चिंता है कि क्या इस पर विचार किया जाएगा, क्योंकि यह मुद्दा बंद नहीं हुआ है, मुझे लगता है कि यह अभी भी खुला है के लिए विचार - विमर्श? प्रतीकों के बजाय इस शब्द का उपयोग करने से isa एक इंफिक्स ऑपरेटर होने के साथ अच्छी तरह से चलेगा, जैसा कि true , false , end , आदि। ऐसा लगता है इस तरह से अधिक सुसंगत और पठनीय।

+1

बस पाइथन से जूलिया में जा रहा है। लगता है जूलिया को सिंबल ओवरफ्लो होने का खतरा है। मानव पठनीय कोड के लिए, मैं and और or पुरजोर समर्थन करता हूं

not कीवर्ड का समर्थन करने से कोड की पठनीयता में भी सुधार हो सकता है।

क्या हमें क्रमशः 0.7/1.0 में and और or (और संभवत: not ) के उपयोग को प्रतिबंधित/निषिद्ध करना चाहिए, ताकि हम बाद में इन्हें जोड़ने का निर्णय ले सकें। वास्तव में उन्हें पसंद है?

मैं इसके साथ नीचे होगा। मैं शर्त लगाता हूं कि @JeffBezanson खिलाफ है, लेकिन अगर हम अभी अनुमति नहीं देते हैं तो हम हमेशा बाद में अपना विचार बदल सकते हैं और इसे अनुमति दे सकते हैं, जबकि हम दूसरी दिशा में नहीं जा सकते। यह भी उपयोगी एक साधारण "उपयोग देने के लिए सक्षम होने के लिए हो सकता है && के बजाय and उपयोगकर्ताओं को, जो अजगर शैली ऑपरेटरों की कोशिश करने के त्रुटि संदेश"।

मुझे लगता है कि यह बहुत अच्छा होगा!

फिर से खोलना और मील का पत्थर जोड़ना यह सुनिश्चित करने के लिए कि हम भूल न जाएं।

मैं मील के पत्थर के इरादे को नहीं समझता, हम and और or जोड़ने जा रहे हैं? हम इस पर पुनर्विचार कर रहे हैं? इसका एक और उपयोग खोज रहे हैं? या फिर आप मतलब है आप चेतावनी की तरह निंदा जोड़ने के लिए जा रहे हैं, तो अजगर से आने वाले लोगों का उपयोग करने के && के बजाय and ?

मेरे पास https://github.com/JuliaLang/julia/pull/19788 था जिसमें वे उपनाम थे, लेकिन मैं उन्हें बदलने के लिए इसे बदल सकता हूं।

मील के पत्थर का मतलब होना चाहिए: किसी निर्णय पर पहुंचें। या, यदि हम समय पर किसी निर्णय पर नहीं पहुँच पाते हैं, तो and और or किसी भी उपयोग को हटा दें ताकि हम बाद में किसी के कोड को तोड़ने के जोखिम के बिना निर्णय को स्थगित कर सकें।

मैं समझता हूं कि कुछ हफ्तों में कोड को फ्रीज करने की आकांक्षा को देखते हुए अब कीड़े के इस कैन को फिर से खोलने में देर हो सकती है (और मैं भविष्य के लिए दरवाजा खुला छोड़ने के लिए मूल्यह्रास जोड़ने के विचार की सराहना करता हूं), लेकिन एक विचार:

जब यह पहली बार चर्चा (2013) के लिए आया, तो मुझे लगता है कि जूलिया समुदाय मुख्य रूप से डेवलपर्स था - मजबूत सीएस पृष्ठभूमि वाले लोग जो && और || का उपयोग करने के आदी थे। मुझे _संदेह_ है कि जो लोग and और or सबसे अधिक सराहना कर सकते हैं, वे ऐसे उपयोगकर्ता हैं जो एएससीआई सलाद के साथ सहज नहीं हैं और जिन्होंने अभी तक पुरानी भाषाओं में पर्याप्त समय नहीं बिताया है ताकि वे पूरी तरह से अभ्यस्त हो सकें। && और || । यह देखने में दिलचस्पी हो सकती है कि अगर हम वर्तमान जूलिया उपयोगकर्ताओं को मतदान करते हैं तो लोग इस बारे में कैसा महसूस करते हैं (खासकर यदि हम इसे प्रवचन पर लाए जहां अधिक गैर-डेवलपर्स इसे देखने की संभावना रखते हैं)।

जो प्रस्तावित किया गया है वह and , or और not सिंटैक्स को आरक्षित कर रहा है। अगर हम ऐसा करते हैं, तो हम इन्हें 1.x टाइमलाइन में किसी भी समय ऑपरेटर के रूप में जोड़ सकते हैं। अभी और चर्चा की आवश्यकता नहीं है।

मैं इन्हें स्थायी सिंटैक्स त्रुटियों के रूप में पार्स करने के साथ ठीक हूं, जैसा कि हम ** । लेकिन मैं अभी भी उन्हें किसी भी तरह का अर्थ देने के बहुत खिलाफ हूं।

मुझे यह भी दुर्भाग्यपूर्ण लगता है कि हम पुराने मुद्दों की खोज कर रहे हैं जिनके लिए पहले ही निर्णय लिया जा चुका है, खासकर 1.0 के करीब।

स्पष्ट होना: यदि कोई ऐसा करता है तो यह हो जाता है।

स्पष्टीकरण के लिए धन्यवाद! :डी

यह मुझे बहुत मूर्खतापूर्ण लगता है कि मैं उन्हें पार्स करने और अन्य उपयोग को प्रतिबंधित करने से परेशान हूं, और फिर भी इसे एक वाक्यविन्यास त्रुटि बना देता हूं। मुझे लगता है कि ज्यादातर लोगों के पास ऐसी स्थिति नहीं होगी जहां and और or आरक्षित शब्द हैं (यानी <strong i="7">@stackeval</strong> 1 0 and 1 or जैसे संदर्भों में प्रयोग योग्य नहीं हैं) फिर भी कुछ भी उपयोगी नहीं है। मैं सुझाव दूंगा कि या तो उन्हें बिल्कुल भी पार्स नहीं किया जाना चाहिए, या उपनाम के रूप में पार्स किया जाना चाहिए (जो असामान्य नहीं है, क्योंकि सी और रूबी ऐसा करते हैं)।

हमने पहले ही उन्हें उपनाम के रूप में पार्स नहीं करने का फैसला किया है, इसलिए पीआर बंद कर दिया गया था। तो +1 उन्हें बिल्कुल भी पार्स न करने के लिए।

इस चर्चा को फिर से शुरू करने के जोखिम पर, जो कि विज्ञापन मतली थी, मैं ध्यान दूंगा कि सी और रूबी के संबंध में, सी में and और or का उपयोग करना मेरे अनुभव में बहुत ही असामान्य है, और सबसे अधिक सामान्य रूबी शैली गाइडों को && और || बजाय and और or ।

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

मुझे नहीं पता कि इसे फिर से क्यों खोला गया।

इस तरह की वाक्यात्मक विशेषताओं के साथ एक जूलिया बोली को आसानी से JuliaParser.jl का उपयोग करके किया जा सकता है, एक बार आंतरिक और मेटा-प्रोग्रामिंग एपीआई स्थिर हो जाने के बाद, इसके लिए इंतजार नहीं कर सकता! :मुस्कुराओ:

इस मुद्दे पर आने वालों के लिए जो हुआ है उसका पालन किए बिना: हालांकि and और or का उपयोग करने के विचार ने उचित मात्रा में समर्थन एकत्र किया *), इस मुद्दे पर पहुंचने वाले पहले पीआर - #19788 - मुख्य रूप से इस बात पर एक अनिर्णायक चर्चा हुई कि क्या and और or को && और || लिए प्रत्यक्ष प्रतिस्थापन होना चाहिए या थोड़ा अलग शब्दार्थ होना चाहिए, उदाहरण के संबंध में वरीयता के लिए, लेकिन सिर्फ उन्हें उपनाम बनाना अवांछित समझा गया। पीआर #२४९६५ ने १.x चक्र के दौरान उन्हें एक अर्थ देने की अनुमति देने के लिए कीवर्ड ( not ) आरक्षित किए होंगे। हालांकि, एक ट्राइएज कॉल के दौरान चर्चा के परिणामस्वरूप अस्वीकृति हुई, इसलिए जल्द से जल्द जिस बिंदु पर इस पर पुनर्विचार किया जा सकता है वह 2.0 के लिए है। (और तब होने वाले बदलाव के लिए शायद किसी को वास्तव में सम्मोहक मामला बनाने की आवश्यकता होगी।)

*) ऐसा लगता है कि प्रस्तावित परिवर्तन अधिक प्रभावशाली/"कोर" डेवलपर्स के साथ कम लोकप्रिय है, इसलिए केवल s की संख्या को देखकर भ्रामक हो सकता है।

मुझे आशा है कि मैंने अति-सरलीकृत नहीं किया और चीजों को शालीनता से ठीक किया। क्षमा करें अगर मैंने नहीं किया।

इसलिए जल्द से जल्द जिस बिंदु पर इस पर पुनर्विचार किया जा सकता है वह 2.0 के लिए है। (और तब होने वाले बदलाव के लिए शायद किसी को वास्तव में सम्मोहक मामला बनाने की आवश्यकता होगी।)

मैं नहीं देखता कि ऐसा क्यों होगा यदि हमने कई बार तय किया है कि अब ऐसा नहीं करना है। मुझे उम्मीद है कि हम हर बड़ी रिलीज के लिए इस मुद्दे को फिर से खोदने से बच सकते हैं।

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

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

मामले में मामला: विचित्र यूनिकोड ऑपरेटर समर्थित हैं , लेकिन प्राकृतिक भाषा नहीं and और or ।

आर && और || और 1-इंडेक्सिंग का भी उपयोग करता है। यह सिर्फ पुरानी नहीं है (या सी जैसी निचली स्तर की भाषाएं)। मैं इसके प्रति उदासीन हूं कि किसका उपयोग करना है लेकिन यह अधिक कठिन नहीं है: मैंने आर और पायथन दोनों को शुरुआती (कोई प्रोग्रामिंग अंतर नहीं) पूरा करना सिखाया है और यह वह नहीं है जिसके साथ उन्होंने संघर्ष किया। आमतौर पर अंतर्निहित अवधारणाएं अधिक महत्वपूर्ण थीं और कोड लिखने के लिए उपयोग किए गए प्रतीकों या शब्दों की तुलना में सीखने में अधिक समय लेती थीं। एक आर, पायथन, सी, आदि उपयोगकर्ता के रूप में आपके लिए "उपयोगकर्ता के अनुकूल" और "अंतर्ज्ञानी" वाक्यविन्यास केवल इसलिए अलग होंगे क्योंकि आप पहले से ही परिचित हैं। यह पूरी तरह से शुरुआती लोगों के लिए मामला नहीं है, जिनके बारे में हमें यहां अधिक चिंतित होना चाहिए क्योंकि मुझे लगता है कि अन्य भाषाओं में अनुभव प्रोग्रामिंग वाले लोगों के पास एक नई भाषा में विभिन्न सम्मेलनों को संभालने का अनुभव और विशेषज्ञता है।

ऐसा लगता है कि यहां उठाया गया एकमात्र कारण यह है कि पायथन and और or और उस तरह के लोगों का उपयोग करता है। क्या यह बदलने की परेशानी के लायक है? जूलिया पायथन नहीं है और उसे बनने की कोशिश नहीं करनी चाहिए। हमारे पास पहले से ही पायथन है। किसी को भी नई भाषा अपनाने की प्रेरणा देने के लिए, यह अलग होना चाहिए। जूलिया के नए उपयोगकर्ता पाइथन प्रोग्रामर नहीं हो सकते हैं, उनके पास एक अलग भाषा के साथ अनुभव हो सकता है (या कोई भी नहीं अगर यह काफी लोकप्रिय हो जाता है)।

मैं इसे शायद एक मृत मुद्दा मानता हूं, लेकिन दूंगा कि IMHO हम में से कई तर्क देंगे कि R "पुराने" के रूप में योग्य है और यह विशेष रूप से उपयोगकर्ता के अनुकूल नहीं है ... और जब मैं सहमत हूं कि शुरुआती लोगों के साथ, && ऑपरेटर "वह नहीं है जिसके साथ उन्होंने संघर्ष किया", मुझे लगता है कि अधिकांश छात्र मैंने पढ़ाया है अंग्रेजी भाषा ऑपरेटरों को ढूंढें ( and , or ) अधिक परिचित और पठनीय चाहे वे पायथन हों उपयोगकर्ता या नहीं।

R && का भी उपयोग करता है और || और 1-इंडेक्सिंग। यह सी जैसी पुरानी (या निम्न स्तर की) भाषाएं नहीं हैं।

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

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

प्रोग्रामिंग के लिए नए IME छात्र बाकी सब चीजों के शीर्ष पर सिंटैक्स के साथ संघर्ष करते हैं, यह एक हजार कटौती से मृत्यु है। प्रोग्रामिंग विदेशी है, और प्राकृतिक भाषा पर अमूर्त प्रतीकों को चुनना इसे और भी अधिक विदेशी और भूलना आसान बनाता है। मैंने अक्सर सी-जैसी भाषाओं में शुरुआती लोगों को यह पूछते हुए सुना है, "आप फिर से 'या' कैसे लिखते हैं?"
लेकिन प्रोग्रामिंग में प्राकृतिक भाषा सिर्फ शुरुआती लोगों के लिए एक मुद्दा नहीं है। यहां तक कि अनुभवी प्रोग्रामर याद आती है की संभावना है एक ! एक से अधिक not , और कई खोजने के लिए इसे आसान गति को पढ़ सकते हैं और टाइप or और and से अधिक || और && ।

जूलिया पायथन नहीं है और उसे बनने की कोशिश नहीं करनी चाहिए। हमारे पास पहले से ही पायथन है। किसी को भी नई भाषा अपनाने की प्रेरणा देने के लिए, यह अलग होना चाहिए।

जूलिया सी या फोरट्रान भी नहीं है। अधिकांश लोकप्रिय भाषाएं सी-लाइक हैं, इसलिए बाहर खड़े होने का मतलब आमतौर पर सी से कुछ अलग करना होता है। मुझे वास्तव में फोरट्रान, सी और उनके वंशज पसंद हैं, हर समय उनका उपयोग करते हैं, लेकिन कुछ जगहों पर वे कम पड़ जाते हैं और मुझे लगता है कि हम कर सकते हैं बेहतर करें। अधिक प्राकृतिक भाषा का उपयोग करना एक तरीका है। यह ध्यान देने योग्य है कि फोरट्रान 77 और बाद के संस्करण अच्छे प्रभाव के लिए .not. , .and. और .or. का उपयोग करते हैं। इस अर्थ में मैं वास्तव में चाहता हूं कि जूलिया अधिक फोरट्रान जैसी हो, कम सी जैसी हो!

इस समस्या का समाधान हो गया है; पहचानकर्ता के रूप में and और or की अनुमति है और हम नियंत्रण प्रवाह के लिए && और || का उपयोग करना जारी रखेंगे। मुझे यकीन नहीं है कि इस पर अभी भी चर्चा क्यों की जा रही है।

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

मुझे लगता है कि यह बहस का विषय है कि क्या a and b वास्तव में a && b से अधिक पठनीय है। && सबसे अलग है। तथ्य यह है कि || और && समान लंबाई के हैं, इससे भी अच्छे स्वरूपण हो सकते हैं। a = b और a + b जैसे ऑपरेटर प्रतीकों में से एक कारण यह है कि वे set a to b जैसी किसी चीज़ पर दृश्य संरचना जोड़ते हैं। a[i] या element i of a ?

आप चीजों को करने के पुराने तरीके से वापस नहीं जाना चाहेंगे।

मेरे लिए, चीजों को करने का पुराना तरीका मैनुअल मेमोरी प्रबंधन और बहुरूपता के लिए कमजोर समर्थन है, न कि && की वर्तनी।

जूलिया के पास कुछ प्राकृतिक भाषा के भाव हैं, जैसे for a in [1, 2, 3] । यह for a = [1, 2, 3] तुलना में बेहतर पढ़ता है और अधिक सहज है, जिसका जूलिया भी समर्थन करता है। मैं निश्चित रूप से यह सुझाव नहीं दूंगा कि हम सभी प्रतीकात्मक ऑपरेटरों के लिए प्राकृतिक भाषा विकल्प प्रदान करें, केवल कुछ ही जो जूलिया को अधिक सहज और पठनीय बनाते हैं।

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

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

मैं भविष्य में संभावित उपयोग के लिए or , and और not आरक्षित करने और संबंधित प्रतीकों का उपयोग करने के लिए चेतावनी/सुझाव जारी करने पर एक शॉट दूंगा। क्या मुझे इसे जूलिया 0.7, 1.0, या दोनों में करना चाहिए?

२४९६५ ?

आह, वह चूक गया, धन्यवाद! मुझे लगता है कि खोजशब्दों को आरक्षित न करना भविष्य में इन खोजशब्दों का समर्थन करने से नहीं रोकता है।

क्षमा करें, सभी चर्चाएं पढ़ें, लेकिन फिर भी समझ में नहीं आया, मैं अब जूलिया में and , or का उपयोग कैसे कर सकता हूं?

आप नहीं कर सकते