لماذا يوجد اختلاف كبير في قابلية القراءة بين مواصفات C# و ECMASCRIPT؟

Question

لقد كنت أدرس مواصفات ECMASCRIPT ووجدت أنه من الصعب للغاية القراءة والفهم. يجب أن أتراجع باستمرار للحفاظ على المفاهيم في رأسي. عند قراءة مواصفات C# ، يمكنني دراسة مكونات اللغة دون أن تتحرك باستمرار حول المستند.

مواصفات ecmascript

C# المواصفات

Answer 1

نظرًا لأنني الشخص الوحيد الذي نشره بانتظام على ذلك الذي كان عضوًا في كل من لجنة تصميم اللغة C# ولجنة ECMASCRIPT الفنية ، ربما يمكنني تقديم بعض الأفكار.

أولاً ، شكرًا على كلماتك الرقيقة حول مواصفات C#. لقد عملنا بجد للحفاظ على قابلية للقراءة ومن الجيد أن نعرف أننا نجحنا.

ثانياً ، لاحظت أن مواصفات C# لم تكن دائمًا على هذا النحو. تمت كتابة مواصفات C# 2.0 ك إضافة إلى مواصفات C# 1.0. كان للأمراء وكتل التكرار والأساليب المجهولة تأثيرات واسعة النطاق على العديد من أقسام المواصفات. لقد كان ألمًا حقيقيًا في قراءة المواصفات 2.0 واضطرار إلى القفز بين فصلين لفهم خوارزمية دقة الحمل الزائد الحقيقي. قام Mads بقدر كبير من أعمال التحرير في C# 3.0 لدمج كل التغييرات C# 2.0 أولاً في مكان معقول في المواصفات حتى لا تضطر إلى القفز في كل مكان.

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

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

كان لدى Waldemar Horwat ، المؤلف الرئيسي لـ Ecmascript 3 SPEC ، أهداف مختلفة إلى حد ما لمواصفات E3 - ليس أهدافًا أسوأ ، ولكن أهداف مختلفة. كان الهدف من مواصفات E3 هو أن يكون أكثر بكثير نحو دقيقة رياضيا نهاية الطيف. ستلاحظ كيف يتكون كل قسم من المواصفات عمليًا من خوارزميات الرمز الكاذب بشكل أساسي التي تصف في النثر الثقيل بالرياضيات بالضبط ما هو تأثير كل عملية على النظام.

ستلاحظ على سبيل المثال أن مواصفات E3 تتحدث عن الفرق بين الأرقام "الرياضية" وتمثيلها الثنائي. ذهبت مسودة واحدة من مواصفات E4 إلى حد الإشارة إلى أن هناك مشاكل نظرية محددة مع تعريف ساذج لـ "النوع" كمجموعة من القيم إذا كانت أنواع القيم أيضًا. هذا النوع من الأشياء سيكون خارج المكان تمامًا في المواصفات C# ؛ لا تسعى إلى الحصول على دعم رياضي نظري قوي لضمان صحة. ستلاحظ أن المواصفات C# لا تحدد حتى "النوع" - لقد تم كتابتها بافتراض أن القراء سيكونون محترفين (1) يعرفون بالفعل الأنواع التي هي لأغراض عملية ، و (2) لا يعرفون ولا يهتمون ما هي نظرية المحددة أو نظرية الفئة التي يجب أن تقولها حول الأساس الرياضي لأي تعريف من "النوع".

كان الهدف من عملية ECMASCRIPT هو لبائعين متعددين من اللغات المتشابهة للغاية للالتقاء والاتفاق على وصف دقيق لما كان في الأساس المشترك بين جميع تلك التطبيقات. لم يكن المقصود مواصفات E3 أبدًا أن تكون برنامجًا تعليميًا من أي نوع ، ويهدف أساسًا إلى اللغة والأداة المنفذين, بدلا من اللغة المستخدمون.

ذهب مواصفات Waldemar E4 إلى أبعد من ذلك. إذا كنت أتذكر بشكل صحيح ، فقد بدأ بتحديد "لغة مواصفات" بسيطة للغاية مع دلالات واضحة. ثم كتب مترجمًا لتلك اللغة المشتركة. ثم كتب المواصفات E4 بلغة المواصفات. وكانت النتيجة أنه يستطيع قم بتجميع المواصفات نفسها في مترجم ECMAscript العام. هذا هو بالضبط نوع "الرياضيات العليا" التي نحاول تجنبها في مواصفات C#. هذا نهج رائع للمواصفات إذا كنت تريد أن تكون دقيقًا ودقيقًا بشكل لا يصدق ، لكنها طريقة فظيعة لكتابة وثيقة مستخدمي اللغة يمكن أن تتعلم من.

هل هذا الجواب على سؤالك؟

Answer 2

من المحتمل أنك تعاني من اختلاف بين قابلية قراءة مواصفات اللغتين لأنها كتبت من قبل مجموعات مختلفة من الأشخاص ، ومناقشة اللغات التي تستخدم نماذج كائنات مختلفة.

كتبت لجنة جافا سكريبت من قبل لجنة بعد أن تطورت اللغة عضويا بعد عدة سنوات. تمت كتابة مواصفات C# من قبل مجموعة صغيرة من مهندسي الشركات بينما كانت اللغة تنمو بطريقة خاضعة للرقابة.

C# هو OOP المتمحور حول الفئة وجافا سكريبت هو محور النموذج الأولي. من المحتمل أنه إذا لم تكن على دراية بأحدها كما أنت مع الآخر ، فقد يكون من الصعب فهم بعض المواد في البداية ، خاصةً عندما تدخل في تفاصيل التنفيذ. هذا لا يشير بالضرورة إلى مشكلة مع وضوح وقابلية المواصفات.

Answer 3

بالنسبة إلى اللغات التقليدية ، فإن جافا سكريبت غريبة للغاية. في الواقع ، لا يوجد الكثير من اللغات الشائعة التي مثل JavaScript تعتمد على النموذج الأولي. تعتمد JavaScript تمامًا على الكائنات ، وجميع الكائنات عبارة عن صفائف ترابطية بشكل أساسي مع وظائف أيضًا كائن من الدرجة الأولى. هذا ليس عادة ما تتوقع رؤيته من لغة ولكن مع شعبية Ajax و Browser Side Programming أصبحت JavaScript لغة الويب. على الرغم من أنه كان من الممكن تجنب هذه المواصفات الغريبة ، إلا أنني أعتقد أن JavaScript يمكن أن يؤدي إلى بعض الترميز المثير للاهتمام والإبداعي. الإغلاق على سبيل المثال هي الشيء الذي يكافح معظم المطورين الجدد من أجل فهمه ، لكن في تجربتي مفيدة للغاية. إن الدلالي للغة في بعض الأحيان من المطورين الذين يعتقدون أن JavaScript هي نكهة C ، لكنهم سرعان ما يدركون أن هذا غير صحيح.

بالنسبة لي C# هو قمة لغات البرمجة. إنه صحيح ومضمر مع التوقعات الأكاديمية. من العار أن مرض التصلب العصبي المتعدد هو السائق الرئيسي لهذه اللغة. مثلي ، أنا متأكد من أن هناك العديد من الآخرين الذين سيستمتعون بتنفيذ مناسب لمنصة مع دعم لنظام C# على None Windows (Mono هي خطوة في الاتجاه الصحيح).

إذا كنت حريصًا على تعلم JavaScript وليس إطار عمل JavaScript ، فأنا أقترح حقًا التمسك بالكتب التي تناقش JavaScript مباشرة. ومع ذلك ، إذا كنت تعتزم البدء ولا تهتم كثيرًا بخصوصيات وعموميات JavaScriptBwokok اقتراح الكتب هي الطريقة الصحيحة للذهاب.

Answer 4

حسنًا ، أنت أول شخص أعرفه بمحاولة تعلم لغة بناءً على مستندات ECMA. على أي حال ، أود أن أقول أن الفرق يرجع في الغالب إلى مهارة الأشخاص الذين يكتبون المواصفات. من الواضح أن C# أسهل قليلاً في تحديد (نظرًا للطبيعة الأقل ديناميكية - كما أشير بالفعل) ، ولكن في النهاية ... ... IIRC JavaScript هو تصميم من قبل اللجنة (يكتب العديد من الأشخاص أيضًا على المواصفات) ، بينما C# تم تنفيذ Microsoft من قبل شخص واحد في النهاية ، ربما مع 1-2 مؤلفين على طول الطريق وبعض المساعدين ، ولكن في النهاية ، يكون Anders Hejlsberg (آمل أن أكون قد واجهت هذا الحق). قد يؤدي تصميم اللجنة والاضطرار إلى التصويت على الأشياء في بعض الأحيان إلى "تصميم" أقل مثالية لوثيقة.

لذلك ، في النهاية أعتقد أن الأمر يتعلق بمهارة الأشخاص الذين يكتبون المواصفات المختلفة التي يصعب قراءتها من الآخر.

Answer 5

جزء من السبب هو أن المعيار الذي ترتبط به هو في الواقع ecmascript. JavaScript و JScript و Actionscript هي كلها تطبيقات ECMASCRIPT ، وتم كتابة ECMASCRIPT لتشمل الأجزاء المشتركة لكل منها. في المقابل ، تم تصميم C# في المقام الأول من قبل ثلاثة أشخاص (وفقًا لمعيار ECMA-334) في Microsoft.

بخلاف ذلك ، يجب عليك تناوله مع لجنة التي كتبت معايير ecmascript.

Answer 6

ببساطة ، ربما يرجع السبب في ذلك إلى أنهم كتبوا من قبل مؤلفين مختلفين. كتبت المواصفات C# من قبل Microsoft الذي كان لديه اهتمام كبير بجعلها جيدة (بحيث يتم قبولها) في حين أن مواصفات ECMAScript قد كتبت من قبل لجنة بعد أن كانت اللغة قيد الاستخدام بالفعل.

Answer 7

حسنًا ، سيتم تشغيل أفضل جزء من جهاز كمبيوتر إلى آخر (نعم ربما اختلافات طفيفة في إصدارات .NET ، لكن الأشياء ستصرف عمومًا). سيتم تشغيل JavaScript بشكل مختلف تمامًا بين Internet Explorer vs Firefox vs Chrome.

على سبيل المثال ، لديك صفحة ويب مع عنصر

<input type="text" name="fred" />

وأنت تدير جافا سكريبت

document.getElementById("fred")

سيحصل Internet Explorer على العنصر (على الرغم من أن هذا سلوك خاطئ ، لا يوجد عنصر يحتوي على معرف Fred) ، لكن Firefox سوف يمنحك خالية.

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

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