+1
أود حقا أن أرى هذا يحدث.
أكثر قابلية للقراءة مثل end المستخدم للفهرسة.

+1
في 27 ديسمبر 2013 ، الساعة 1:06 مساءً ، كتب "GaborOszlanyi" [email protected] :

+1
أود حقا أن أرى هذا يحدث.
أكثر قابلية للقراءة مثل النهاية المستخدمة للفهرسة.

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/JuliaLang/julia/issues/5238#issuecomment -31280112
.

أنا أحب هذا الاقتراح أيضا.

أنا مندهش قليلاً من الدعم الكبير الذي يحصل عليه هذا. لطالما شعرت أن المشغلين المحددين كانوا أكثر سهولة للتحكم في التدفق ، لكنني لم أدرك أن الشعور كان منتشرًا.

لم أكن من المعجبين عندما قدمت هذا الاقتراح ، لكن يجب أن أقول بعد المزيد من التفكير ، إنه أيضًا منطقي جدًا بالنسبة لي. هؤلاء هم في الواقع عوامل تحكم في التدفق ، على عكس كل الآخرين ، الذين يستخدمون الرموز بدلاً من النص. قد يقلل هذا من الالتباس مع & و | .

لقد لاحظت أن اللغات التي توفر and و or (Perl ، Ruby ، ​​Lua - للغات التي راجعتها) توفر أيضًا not (حتى Lua لا تقدم ! ). رد فعلي الأول هو أنني لا أحب ذلك ، لأنه فائض ! . ولكن ربما يكون هناك سبب قوي وراء اختيار هذه اللغات للقيام بذلك.

أنا شخصياً أحب not كثيرًا ، لكن لا أعتقد أن التبديل إلى not يقدم أي شيء مثل تقليل الغموض الذي يقدمه استخدام and و or .

not ليست عملية تدفق قصيرة / تحكم في التدفق أيضًا ، وأنا دائمًا أعاني من كيفية قراءتها فيما يتعلق بالترابط. المكان الوحيد الذي أحبه في Pyhton هو if not ... ولكن هذا لأنني قرأته كعملية تحكم في التدفق.

+1

هل يمكن أيضًا إضافة XOR كدائرة كهربائية قصيرة؟
ونسخة ماس كهربائى من الإصدارات المقلوبة (XNOR ، NAND ، NOR)؟

XOR غير قابل للدائرة القصيرة أبدًا. يمكن كتابة العناصر الأخرى بشكل تافه باستخدام ! بالإضافة إلى and و or .

+1
سأشير إلى أنه في روبي ، هناك ارتباك مستمر حول && vs 'و' (http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/) ، لذلك سيكون من الجيد أن نضع في اعتبارنا المنطق الذي تستخدمه روبي للحصول على مجموعتي المشغلين وقررنا ما إذا كان الأمر يستحق الارتباك أم && يجب إزالته تمامًا لصالح "و".

أفضّل أن تكون أسبقية منخفضة جدًا كما هو الحال في Perl و 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 ) غالبًا ما تقودني إلى كتابة رمز غير صحيح أتوقع بسذاجة أن يعمل (لأنه منطقي في english) ثم اضطررت إلى حك رأسي لبضع ثوان بينما أقوم بالتحويل عقليًا من اللغة الإنجليزية إلى العبارات المنطقية قبل أن أدرك خطأي. ومع ذلك ، فأنا لست متحيزًا بشكل خاص في أي من الاتجاهين ؛ فقط أدخل 2.

أنا أيضًا مقابل and و or

+1

+1
كلا المشغلين
and و or بأسبقية ضعيفة
أود أن أزعم أنه يجب كتابة cond = f() && g() cond = (f() && g()) .
أؤيد أيضًا استخدام not مع أسبقية ضعيفة على أساس أن ! ، الذي له أسبقية قوية في كل سياق رأيته ، يتطلب if !(something and something) وهو ما لا يعجبني في بعض التفاصيل ، غير منطقي ، وغير قابل للتغيير. أشعر أيضًا أنه من الصعب رؤية ! في بعض الأحيان. أنا أيضًا أجهل أصله لـ ! لكني أشعر أن له مكانًا أكثر ملاءمة كعامل عاملي على الأعداد الصحيحة - وبالتالي يفضل بناء جملة matlab ~ .

johnmyleswhite يتم إغلاق هذه القضية؟ أعتقد أن السفينة أبحرت على هذه السفينة.

:(

ماس كهربائى هذا الوجه العابس

أعتقد أنه لا يزال يتعين علينا النظر في هذا. يبدو أن الكثير من الناس لا يحبون استخدام && و || بالطريقة التي نستخدمها بها ونفضل استخدام and و or . هناك أيضًا مشكلة الأسبقية ، مما يجعل && و || محرجًا إلى حد ما. يمكننا الانتقال إلى المستقبل حيث يتطلب && و || أن يكون كلا المعاملين منطقيًا و and و or يفعلون ما && و || تفعله حاليًا ولكن بأولوية أقل بحيث يمكنك كتابة x == nothing and x = 0 وهكذا. إما ذلك أو تقديم بناء جملة شرطي مختلف من سطر واحد مثل x = 0 if x == nothing .

تحتوي الصيغة الأخيرة x = 0 if x == nothing على بعض مشكلات IMO التي يسببها الاقتراح في https://groups.google.com/forum/#!topic/julia -dev / cnmLcNg8h0Q.
هل الخياران التاليان مروعان لدرجة أن جوليا بحاجة إلى شروط ما بعد الشرطية؟

    if x == nothing ; x = 0 ; end

أو

   x == nothing && (x = 0)

بعد قولي هذا ، تمامًا كما لا أمانع في رؤية بناء repeat ; expr(s) ; until cond في Julia (لكن يمكنني العيش بدونه) ، لا أرى أي خطأ في امتلاك and و or تمت إضافة
يبدو أنها تتلاءم بشكل أفضل مع بناء جملة جوليا من استخدام الاقتراض من C && و || .

أعتقد أنه لا يزال يتعين علينا النظر في هذا.

+1

لقد فوجئت بأن التعيين أسبقية أقل من || ، لذلك جئت بحثًا عن المناقشة السابقة ووجدت هذه المشكلة. إنها ليست مشكلة كبيرة ، لكن هذه الأقواس تبدو في غير محلها بالنسبة لي. استغرق الأمر مني بعض الوقت (عدة ثوانٍ ، على ما أعتقد ، واختبارًا في REPL) لمعرفة موقع المهمة الذي كان غير صالح. - أشارت رسالة الخطأ إلى السطر الذي يتجاوز نهاية تعريف الوظيفة.

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

في المقابل ، تبدو الأقواس في cond = (f() && g()) بالنسبة لي. أعتقد أنني سأستخدمهم على أي حال.

مقابل ما يستحق ، أفضل أيضًا and و or .

+1 مني أيضًا.

الاستجابة تكاد تكون إيجابية بالإجماع لصالح and إلخ. أحسب رأيين ضدهما ، أحدهما غير مبال ، والآخران غير محددين والآخرين (15 أو أكثر) يؤيدون.

أعتقد أن حجة واحدة ضد (أكثر صعوبة في القراءة) غير صحيحة. الحجة هي أن قراءة foo and bar أكثر صعوبة من قراءة foo && bar على حساب 3 كلمات مقابل كلمة SYMBOL. ومع ذلك ، يستخدم الجميع تمييز النحو ، وفي هذه الحالة يحدث العكس. تم تلوين 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 عامل infix أيضًا ، كما هو الحال مع true ، false ، end ، إلخ. يبدو أكثر اتساقًا وقابلية للقراءة بهذه الطريقة.

+1

مجرد الانتقال إلى جوليا من بايثون. يبدو أن جوليا في خطر الدخول في فائض الرمز. من أجل الكود الذي يمكن قراءته من قبل الإنسان ، أؤيد بشدة and و or

قد يؤدي دعم الكلمة الرئيسية not أيضًا إلى تحسين قابلية قراءة الكود.

إذا قمنا بإيقاف / حظر استخدام and و or (وربما not ) في 0.7 / 1.0 ، على التوالي ، حتى نتمكن من إضافتها لاحقًا في حال قررنا ذلك حقا مثلهم؟

سأكون مع ذلك. أراهن أن JeffBezanson ضدها ، لكن إذا لم نسمح بذلك ، يمكننا دائمًا تغيير رأينا لاحقًا والسماح بذلك ، بينما لا يمكننا الذهاب في الاتجاه الآخر. قد يكون من المفيد أيضًا أن تكون قادرًا على إعطاء رسالة خطأ بسيطة "استخدم && بدلاً من and " للمستخدمين الذين يحاولون استخدام عوامل تشغيل بأسلوب Python.

أعتقد أن هذا سيكون رائعًا!

إعادة الفتح والإضافة إلى حدث هام للتأكد من أننا لا ننسى.

لا أفهم القصد من الإنجاز ، سنضيف and و or ؟ نحن نعيد النظر فيه؟ تبحث عن استخدام آخر لهذا؟ أو تقصد أنك ستضيف إهمالًا مثل التحذيرات ، لذلك يعرف الأشخاص القادمون من Python أنهم يستخدمون && بدلاً من and ؟

كان لدي https://github.com/JuliaLang/julia/pull/19788 حيث كانت أسماء مستعارة ، لكن يمكنني تغيير ذلك لاستبدالها.

يجب أن يعني المعلم: التوصل إلى قرار. أو ، إذا لم نتمكن من التوصل إلى قرار في الوقت المناسب ، فقم بإيقاف أي استخدام لـ and و or حتى نتمكن من تأجيل القرار دون المخاطرة بكسر أي رمز لاحقًا.

أتفهم أنه نظرًا للطموح لتجميد الشفرة في غضون أسابيع قليلة ، فقد يكون الوقت متأخرًا لإعادة فتح علبة الديدان الآن (وأنا أقدر فكرة إضافة الإهلاك لترك الباب مفتوحًا للمستقبل) ، ولكن فكرت واحدة:

عندما تم طرح هذا للمناقشة لأول مرة (2013) ، أعتقد أن مجتمع Julia كان في الأساس مطورين - أشخاص لديهم خلفيات CS قوية والذين اعتادوا على استخدام && و || . أشك في أن الأشخاص الذين قد يقدرون and و or الغالب هم مستخدمون غير مرتاحين لسلطات ascii والذين لم يقضوا وقتًا كافيًا في اللغات القديمة حتى يعتادوا تمامًا على && و || . قد يكون مهتمًا بمعرفة كيف شعر الناس حيال هذا إذا قمنا باستطلاع آراء مستخدمي Julia الحاليين (خاصة إذا طرحنا ذلك في الخطاب حيث من المحتمل أن يراه غير المطورين).

ما تم اقتراحه هو حجز بناء الجملة and و or و not . إذا فعلنا ذلك ، فيمكننا إضافة هؤلاء كمعاملين في أي وقت في الخط الزمني 1.x. لا مزيد من المناقشة مطلوب الآن.

سأكون على ما يرام مع تحليل هذه الأخطاء باعتبارها أخطاء بنية دائمة ، كما نفعل مع ** . ولكن ما زلت جدا، جدا ضد منحهم أي نوع من معنى غير ذلك.

كما أنني أجد أنه من المؤسف أننا نبحث عن المشكلات القديمة التي تم التوصل إلى قرار بشأنها بالفعل ، خاصة قريبة جدًا من 1.0.

لنكون واضحين: يتم ذلك إذا قام شخص ما بذلك.

شكرا على التوضيح! :د

يبدو الأمر سخيفًا جدًا بالنسبة لي أن أزعج نفسي بتحليلها وحظر أي استخدام آخر ، ومع ذلك أجعلها خطأً نحويًا. أعتقد أن معظم الناس يفضلون عدم وجود موقف يكون فيه and و or كلمات محجوزة (أي غير قابلة للاستخدام في سياقات مثل <strong i="7">@stackeval</strong> 1 0 and 1 or ) ومع ذلك لا يفعلون شيئًا مفيدًا. أود أن أقترح إما عدم تحليلها على الإطلاق ، أو تحليلها كأسماء مستعارة (وهو أمر غير معتاد ، كما يفعل C و Ruby).

لقد قررنا بالفعل عدم تحليلها كأسماء مستعارة ، ولهذا السبب تم إغلاق العلاقات العامة. لذا +1 لعدم تحليلها على الإطلاق.

في ظل خطر إعادة صياغة هذه المناقشة التي كانت قد تعرضت لغثيان إعلاني ، سألاحظ أنه فيما يتعلق بـ C و Ruby ، ​​فإن استخدام and و or في C أمر غير شائع جدًا في تجربتي ، والأكثر تتطلب أدلة أسلوب روبي الشائعة && و || بدلاً من and و or .

IMHO: يبدو أن المناقشات الأصلية كانت منقسمة إلى حد ما ، وإضافة هذه الحماية ببساطة تترك مساحة للمجتمع لإعادة النظر فيها في المستقبل الذي يرغبون فيه.

ليس لدي أي فكرة عن سبب إعادة فتح هذا.

يمكن استخدام لهجة جوليا مع ميزات نحوية مثل هذه باستخدام JuliaParser.jl بسهولة ، بمجرد استقرار واجهات برمجة التطبيقات الداخلية والبرمجة الفوقية ، لا يمكنك انتظار ذلك! :ابتسامة:

بالنسبة لأولئك الذين يأتون إلى هذه المشكلة دون متابعة ما حدث: على الرغم من أن فكرة استخدام and و or جمعت قدرًا لا بأس به من الدعم *) ، فإن العلاقات العامة الأولى للتعامل مع المشكلة - # 19788 - أدى بشكل أساسي إلى مناقشة غير حاسمة حول ما إذا كان يجب أن يكون and و or بدائل مباشرة لـ && و || أو يجب أن يكون لهما دلالات مختلفة قليلاً ، على سبيل المثال فيما يتعلق بالأسبقية ، ولكن مجرد جعلها أسماء مستعارة يعتبر غير مرغوب فيه. كان من الممكن أن يحجز PR # 24965 الكلمات الرئيسية (جنبًا إلى جنب مع not ) ، للسماح بإعطائهم معنى خلال دورة 1.x. ومع ذلك ، أدت المناقشة أثناء مكالمة الفرز إلى الرفض ، وبالتالي فإن أقرب نقطة يمكن إعادة النظر فيها هي 2.0. (وربما يحتاج المرء إلى تقديم حجة مقنعة حقًا لكي يحدث التغيير بعد ذلك).

*) يبدو كما لو أن التغيير المقترح أقل شيوعًا لدى المطورين الأكثر نفوذاً / "الأساسيين" ، لذا فإن مجرد النظر إلى عدد s قد يكون مضللاً ، على الرغم من ذلك.

آمل ألا أبالغ في التبسيط وأن أضع الأمور في نصابها الصحيح. أعتذر إذا لم أفعل.

لذا فإن أقرب نقطة يمكن إعادة النظر فيها هي 2.0. (وربما يحتاج المرء إلى تقديم حجة مقنعة حقًا لكي يحدث التغيير بعد ذلك).

لا أفهم سبب حدوث ذلك على الإطلاق إذا قررنا عدة مرات الآن عدم القيام بذلك. آمل أن نتمكن من تجنب بحث هذه المشكلة مرة أخرى لكل إصدار رئيسي.

إذا بقيت جوليا لفترة طويلة بما يكفي للتنافس مع بايثون ، يمكنني أن أضمن أن هذا سيظهر أكثر وأكثر. لا يرغب العديد من مستخدمي Python في العودة إلى بناء جملة C. إنه أحد الأسباب العديدة لشعبية بايثون: سهولة التعلم ، والإدمان على الاستخدام ، ولن ترغب في العودة إلى الطريقة القديمة في القيام بالأشياء.

غالبًا ما يزعم مصممو اللغة الجدد أنهم يريدون بناء جملة سهل الاستخدام ، لكنهم يميلون إلى الضياع في الميزات الفاخرة التي لن يرغب أو يستخدمها سوى مجموعة فرعية صغيرة من المستخدمين ، بينما يتجاهلون التعديلات البسيطة التي قد تؤدي إلى التبني.

مثال على ذلك: مشغلات Unicode الغريبة مدعومة ، ولكن ليست لغة طبيعية and و or .

يستخدم R أيضًا && و || والفهرسة 1. إنها ليست لغات أقدم (أو لغات ذات مستوى أدنى مثل C). أنا غير مبال بشأن أيهما أستخدم ولكن الأمر ليس أكثر صعوبة: لقد قمت بتدريس كل من R و Python لإكمال المبتدئين (لا يوجد فرق في البرمجة) وهذا ليس ما عانوا من أجله. عادة ما تكون المفاهيم الأساسية أكثر أهمية وتستغرق وقتًا أطول للتعلم من الرموز أو الكلمات المستخدمة في كتابة الكود. بناء الجملة "سهل الاستخدام" و "بديهي" بالنسبة لك كمستخدم R و Python و C وما إلى ذلك سيكون مختلفًا ببساطة بسبب ما تعرفه بالفعل. ليس هذا هو الحال بالنسبة للمبتدئين المطلقين الذين يجب أن نكون أكثر اهتمامًا بهم هنا لأنني أعتقد أن أولئك الذين لديهم خبرة في البرمجة بلغات أخرى لديهم الخبرة والخبرة للتعامل مع الاصطلاحات المختلفة بلغة جديدة.

السبب الوحيد الذي يبدو أنه قد نشأ هنا هو أن Python تستخدم and و or وأشخاص من هذا القبيل. هل هذا يستحق عناء التغيير؟ جوليا ليست بايثون ويجب ألا تحاول أن تكون كذلك. لدينا بالفعل بايثون. لمنح أي شخص دافعًا للتبديل إلى لغة جديدة ، يجب أن تكون مختلفة. قد لا يكون المستخدمون الجدد لـ Julia من مبرمجي Python ، فقد يكون لديهم خبرة بلغة مختلفة (أو لا شيء على الإطلاق إذا أصبحت شائعة بدرجة كافية).

أدرك أن هذه ربما تكون مشكلة ميتة ، ولكن ردًا على TomKellyGenetics ، أود أن أقترح أن IMHO كثير منا قد يجادل بأن R مؤهل كـ "أقدم" وليس سهل الاستخدام بشكل خاص ... وبينما أتفق مع المبتدئين ، && مشغلي and ، or ) أكثر دراية وقابلية للقراءة سواء كانوا بايثون المستخدمين أم لا.

يستخدم R أيضًا && و || و 1-الفهرسة. إنها ليست لغات أقدم (أو مستوى أدنى) فقط مثل C).

كنت أشير إلى اللغات الشبيهة بلغة C ، أي اللغات التي تقترض بشكل كبير بناء الجملة من C ، وعادة ما يكون ذلك باستخدام حجة تحقق ذاتها "إنها البنية التركيبية التي تستخدمها كل لغة أخرى". إن بناء الجملة R يشبه إلى حد ما C ، على الرغم من أنه يتباعد هنا وهناك. جوليا تشبه Fortran أكثر من C ، على الرغم من وجود بعض التداخل.

لقد قمت بتدريس كل من R و Python لإكمال المبتدئين (لا يوجد فرق في البرمجة) وهذا ليس ما عانوا من أجله.

يعاني طلاب IME الجدد في البرمجة من بناء الجملة فوق كل شيء آخر ، إنه الموت بآلاف التخفيضات. البرمجة غريبة ، واختيار الرموز المجردة على اللغة الطبيعية يجعلها أكثر غرابة ويسهل نسيانها. كثيرًا ما أسمع مبتدئين بلغات تشبه C يسألون أشياء مثل ، "كيف تكتب" أو "مرة أخرى؟"
لكن اللغة الطبيعية في البرمجة ليست مجرد مشكلة للمبتدئين. حتى المبرمجين المتمرسين من المرجح أن يفوتهم ! أكثر من not ، ويجد الكثيرون أنه من الأسهل قراءة وكتابة or و and على || و && .

جوليا ليست بايثون ويجب ألا تحاول أن تكون كذلك. لدينا بالفعل بايثون. لمنح أي شخص دافعًا للتبديل إلى لغة جديدة ، يجب أن تكون مختلفة.

جوليا ليست C أو Fortran أيضًا. الغالبية العظمى من اللغات الشائعة تشبه لغة C ، لذا فإن التميز عادة ما يعني القيام بشيء مختلف عن C. أنا في الواقع أحب Fortran و C وأحفادهم ، استخدمهم طوال الوقت ، لكن في بعض الأماكن يقصرون وأعتقد أننا نستطيع كن افضل. يعد استخدام المزيد من اللغة الطبيعية إحدى الطرق. تجدر الإشارة إلى أن Fortran 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] ، والذي تدعمه جوليا أيضًا. بالتأكيد لن أقترح توفير بدائل للغة الطبيعية لجميع المشغلين الرمزيين ، فقط القلة التي تجعل جوليا أكثر سهولة وقراءة.

FWIW ، لقد صوتت لاعتماد كلا المجموعتين من المشغلين ، لتسهيل التبني وإعطاء المستخدمين خيارات نمط. في مشاريع C ++ حيث يستخدم الناس كلاهما لم يزعجني أبدًا. لا أرى أي ضرر فيه ، فقط الفوائد.

بشكل عام ، أحب الاتجاه الذي سلكته بنية جوليا. توازن كبير بين اللغة والرموز الطبيعية ، وإثبات أن اللغة الرقمية يمكن أن تتفوق في البرمجة للأغراض العامة. لا أطيق الانتظار لترى كيف ينمو ويتطور. وهي طريقتي للقول إن إضافة عوامل اللغة الطبيعية متوافقة تقنيًا مع الإصدارات السابقة. :ابتسامة:

سأعطي فرصة للاحتفاظ بـ or ، and و not للاستخدام المحتمل في المستقبل ، ولإصدار تحذير / اقتراح لاستخدام الرموز المقابلة. هل يجب أن أفعل هذا في Julia 0.7 أو 1.0 أو كليهما؟

24965؟

آه ، فاتك ذلك ، شكرًا! أعتقد أن عدم حجز الكلمات الرئيسية لا يمنع دعم هذه الكلمات الرئيسية في المستقبل.

عذرًا ، اقرأ كل المناقشات ، ولكن ما زلت لم تفهمها ، كيف يمكنني استخدام and ، or في Julia الآن؟

لا يمكنك