خمسة أسئلة حول تصميم لغات البرمجة

الفلسفة التوجيهية

1. لغات البرمجة للناس

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

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

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

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

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

2. تصميم لنفسك ولأصدقائك

إذا نظرت إلى تاريخ لغات البرمجة ، فقد تم تصميم معظم أفضل اللغات للاستخدام من قِبل مؤلفيها ، وتم تصميم معظم اللغات الأخرى لأشخاص آخرين.

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

هذا لا علاقة له بمدى جودة اللغة. C منخفض المستوى تمامًا ، ولكن تم إنشاؤه للاستخدام من قِبل مؤلفيه ، ولهذا السبب يحب المتسللين ذلك.

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

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

3. إعطاء مبرمج أكبر قدر ممكن من السيطرة

تتصرف العديد من اللغات (خاصة تلك التي يتم إنشاؤها لأشخاص آخرين) مثل المربيات: فهي تحاول تحذيرك من أشياء ، في رأيهم ، لن تكون مفيدة لك. لدي رأي معاكس: إعطاء مبرمج التحكم بقدر ما تستطيع.

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

4. الإيجاز - أخت المواهب

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

أعتقد أن كل شيء تقريبًا يجعل البرامج أقصر. يجب أن يكون هناك الكثير من وظائف المكتبة ، كل ما يمكن أن يكون ضمنيًا - يجب أن يكون كذلك ؛ يجب أن يكون بناء الجملة أكثر إيجازًا ؛ يجب أن تكون أسماء الكيانات قصيرة.

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

5. التعرف على القرصنة.

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

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

القضايا المفتوحة

1. كيفية تنظيم المكتبات الكبيرة؟

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

2. هل الناس خائفون بالفعل من بناء الجملة البادئة؟

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

3. ماذا تحتاج لبرنامج الخادم؟

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

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

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

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

4. ما تجريدات جديدة تبقى مفتوحة؟

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

أسرار غير معروفة

1. يمكنك استخدام أي لغة تريدها

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

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

ماذا يعني هذا بالنسبة لنا ، المهتمين بتصميم لغات البرمجة ، وجود جمهور محتمل لعملنا.

2. السرعة تأتي من المحللون

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

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

3. تحتاج إلى تطبيق يجعل لغتك تتطور

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

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

[أثناء المناقشة ، أعرب Guy Steele أيضًا عن هذه الفكرة ، مضيفًا أن التطبيق لا ينبغي أن يتكون من كتابة مترجم للغتك ، إلا إذا كانت لغتك مخصصة لكتابة مترجمين.]

4. يجب أن تكون اللغة مناسبة لكتابة البرامج لمرة واحدة.

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

5. بناء الجملة المتعلقة دلالات

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

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

الأفكار التي تعود مع مرور الوقت

1. لغات البرمجة الجديدة

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

2. تقاسم الوقت

طرح ريتشارد كيلسي هذه الفكرة ، التي حان وقتها مرة أخرى ، وأنا أؤيدها تمامًا. تخميني (و Microsoft أيضًا) هو أن العديد من العمليات الحسابية ستنتقل من سطح المكتب إلى الخوادم البعيدة. وبعبارة أخرى ، عاد تقسيم الوقت. أعتقد أنك ستحتاج إلى دعم على مستوى اللغة. على سبيل المثال ، قام ريتشارد وجوناثان ريفز بالكثير من العمل لتنفيذ تخطيط العمليات في المخطط 48.

3. الكفاءة

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

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

في النهاية ، قد يتضح أن bytecode ليس خيارًا. يبدو أن شركة صن ومايكروسوفت تقاتلان حاليًا وجهاً لوجه في حقل الرمز البريدي. لكنهم يفعلون ذلك لأن bytecode هو المكان المناسب لتضمين أنفسهم في العملية ، وليس لأن bytecode وحده هو فكرة جيدة. قد يتضح أن هذه المعركة بأكملها سوف تمر مرور الكرام. سيكون مضحكا.

الفخاخ والفخاخ

1. العملاء

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

أعتقد أنه ستكون هناك زيادة سريعة في الأجهزة التي يمكنها الوصول إلى الويب ، ويمكننا أن نفترض أنها ستدعم html ونماذجها الأساسية. هل لديك متصفح على هاتفك؟ هل سيكون هناك هاتف في PalmPilot الخاص بك؟ هل ستحتوي شاشة Blackberry على شاشة أكبر؟ هل ستتاح لك الفرصة للذهاب عبر الإنترنت من gameboy الخاص بك؟ من ساعتك؟ لا اعرف وليس عليّ معرفة ما إذا كنت أراهن أن كل شيء سيكون على الخادم. هو ببساطة أكثر موثوقية لديك كل العقول على الخادم. .

2. وجوه المنحى البرمجة

أفهم أن هذا بيان مثير للجدل ، لكنني لا أعتقد أن OOP شيء مهم. أعتقد أن هذا نموذج مناسب لتطبيقات معينة تحتاج إلى هياكل بيانات محددة ، مثل أنظمة النوافذ والمحاكاة وأنظمة CAD. لكنني لا أفهم لماذا يجب أن تكون مناسبة لجميع البرامج.

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

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

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

3. تصميم من قبل اللجنة

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

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