الفلسفة الإرشادية
1. لغات البرمجة للأشخاص
لغات البرمجة هي الطريقة التي يتحدث بها الناس مع أجهزة الكمبيوتر. سيكون الكمبيوتر سعيدًا بالتحدث بأي لغة غير غامضة. سبب وجود لغات عالية المستوى هو أن الناس لا يستطيعون التعامل مع لغة الآلة. الهدف من لغات البرمجة هو منع أدمغتنا البشرية الضعيفة والهشة من أن تطغى عليها الكثير من التفاصيل.
يعرف المهندسون المعماريون أن بعض مشكلات التصميم تكون عادية أكثر من غيرها. بعض مشاكل التصميم الأكثر وضوحًا وتجريدًا هي تصميم الجسور. في هذه الحالة، مهمتك هي قطع المسافة المطلوبة بأقل قدر ممكن من المواد. على الطرف الآخر من الطيف يوجد تصميم الكرسي. يجب على مصممي الكراسي قضاء وقتهم في التفكير في أعقاب الناس.
تطوير البرمجيات لديه فرق مماثل. يعد تصميم الخوارزميات لتوجيه البيانات عبر الشبكة مشكلة مجردة لطيفة، مثل تصميم الجسور. في حين أن تصميم لغات البرمجة يشبه تصميم الكراسي: عليك أن تتعامل مع نقاط الضعف البشرية.
وهذا أمر يصعب على معظمنا إدراكه. إن تصميم أنظمة رياضية أنيقة يبدو أكثر جاذبية في نظر أغلبنا من استرضاء نقاط الضعف البشرية. دور الأناقة الرياضية هو أن درجة معينة من الأناقة تجعل البرامج أسهل للفهم. لكن الأمر لا يتعلق بالأناقة فقط.
وعندما أقول إن اللغات يجب أن تكون مصممة لاستيعاب نقاط الضعف البشرية، لا أقصد أن اللغات يجب أن تكون مصممة للمبرمجين السيئين. في الواقع، يجب عليك تصميم برامج لأفضل المبرمجين، ولكن حتى أفضل المبرمجين لديهم حدودهم. لا أعتقد أن أي شخص سيستمتع بالبرمجة بلغة يُشار إليها بالحرف "x" مع عدد صحيح من المتغيرات.
2. صمم لنفسك ولأصدقائك
إذا نظرت إلى تاريخ لغات البرمجة، فستجد أن معظم أفضل اللغات تم تصميمها ليستخدمها مؤلفوها، ومعظم أسوأ اللغات تم تصميمها ليستخدمها أشخاص آخرون.
عندما يتم تصميم اللغات لأشخاص آخرين، فهي دائمًا مجموعة محددة من الأشخاص: فالناس ليسوا أذكياء مثل مبدعي اللغة. هكذا تحصل على لسان يتحدث إليك. كوبول هو المثال الأبرز، لكن معظم اللغات مشبعة بهذه الروح.
لا علاقة له بمدى ارتفاع مستوى اللغة. لغة C ذات مستوى منخفض جدًا، ولكن تم إنشاؤها ليتم استخدامها من قبل مؤلفيها، ولهذا السبب يحبها المتسللون.
حجة تصميم اللغات للمبرمجين السيئين هي أن عدد المبرمجين السيئين أكثر من عدد المبرمجين الجيدين. ربما هذا هو الحال. لكن هذا العدد الصغير من المبرمجين الجيدين يكتبون المزيد من البرامج بشكل غير متناسب.
سؤالي هو، كيف يمكنك إنشاء لغة تجذب أفضل المتسللين؟ يبدو لي أن هذا السؤال مطابق لسؤال كيفية إنشاء لغة برمجة جيدة؟ ولكن حتى لو لم يكن كذلك، فهو على الأقل سؤال مثير للاهتمام.
3. امنح المبرمج أكبر قدر ممكن من التحكم
تعمل العديد من اللغات (خاصة تلك المصممة لأشخاص آخرين) مثل المربيات: فهي تحاول تحذيرك من الأشياء التي لا تعتقد أنها ستفيدك. أنا أتبنى وجهة النظر المعاكسة: امنح المبرمج أكبر قدر ممكن من التحكم.
عندما تعلمت ليسب لأول مرة، أكثر ما أعجبني هو أننا كنا نتحدث على قدم المساواة. وفي اللغات الأخرى التي تعلمتها في تلك المرحلة، كانت هناك لغة، وكان هناك برنامجي بتلك اللغة، وكانا موجودين بشكل منفصل تمامًا. لكن في Lisp، كانت الوظائف ووحدات الماكرو التي كتبتها هي نفسها التي كتبت بها اللغة نفسها. يمكنني إعادة كتابة اللغة نفسها إذا أردت. كان لها نفس جاذبية البرامج مفتوحة المصدر.
4. الإيجاز هو أخت الموهبة
الإيجاز هو الاستخفاف وحتى الاحتقار. ولكن إذا نظرت إلى قلوب المتسللين، سترى أنهم يحبون الإيجاز حقًا. كم مرة سمعت المتسللين يتحدثون باعتزاز عن كيف يمكنهم، على سبيل المثال، في APL، القيام بأشياء مذهلة باستخدام سطرين فقط من التعليمات البرمجية؟ أعتقد أن الأشخاص الأذكياء حقًا يحبون الاهتمام بهذا الأمر.
أعتقد أن أي شيء تقريبًا يجعل البرامج أقصر هو أمر جيد. يجب أن يكون هناك الكثير من وظائف المكتبة، وكل ما يمكن أن يكون ضمنيًا يجب أن يكون كذلك؛ ينبغي أن يكون بناء الجملة أكثر إيجازا؛ حتى أسماء الكيانات يجب أن تكون قصيرة.
وليس فقط البرامج يجب أن تكون قصيرة. يجب أن تكون الأدلة أيضًا قصيرة. يمتلئ جزء كبير من الأدلة بالتفسيرات وإخلاء المسؤولية والتحذيرات والحالات الخاصة. إذا كنت بحاجة إلى اختصار الدليل، فإن الخيار الأفضل هو تصحيح اللغة التي تتطلب الكثير من الشرح.
5. التعرف على ما هي القرصنة
يرغب العديد من الأشخاص في أن تكون القرصنة عبارة عن رياضيات، أو على الأقل شيئًا أقرب إلى العلم. أعتقد أن القرصنة أشبه بالهندسة المعمارية. الهندسة المعمارية تدور حول الفيزياء حيث يحتاج المهندس المعماري إلى تصميم مبنى لا يسقط، لكن الهدف الحقيقي للمهندس المعماري هو إنشاء مبنى رائع، وليس القيام باكتشافات في مجال الاستاتيكا.
ما يحبه المتسللون هو إنشاء برامج رائعة. وأعتقد أنه، على الأقل في أفكارنا، يجب أن نتذكر أن كتابة برامج عظيمة أمر رائع، حتى عندما لا يُترجم هذا العمل بسهولة إلى العملة الفكرية المعتادة للأوراق العلمية. من وجهة نظر فكرية، من المهم تصميم لغة سيحبها المبرمجون بقدر أهمية تصميم لغة رهيبة تجسد فكرة يمكنك نشر ورقة بحثية عنها.
القضايا المفتوحة
1. كيفية تنظيم المكتبات الكبيرة؟
أصبحت المكتبات جزءًا مهمًا من لغات البرمجة. إنها تصبح كبيرة جدًا بحيث يمكن أن تكون خطيرة. إذا استغرق العثور على دالة في المكتبة تقوم بما تحتاجه وقتًا أطول من كتابة تلك الوظيفة بنفسك، فلن تفعل كل التعليمات البرمجية شيئًا سوى جعل دليلك أكثر سمكًا. (كانت كتيبات الرموز مثالاً على ذلك.) لذلك يتعين علينا حل مشكلة تنظيم المكتبة. ومن الناحية المثالية، قم بتصميمها بحيث يتمكن المبرمج من تخمين وظيفة المكتبة المناسبة.
2. هل يخاف الناس حقًا من بناء جملة البادئة؟
هذه مشكلة مفتوحة بمعنى أنني كنت أفكر فيها منذ عدة سنوات وما زلت لا أعرف الإجابة. يبدو بناء جملة البادئة طبيعيًا تمامًا بالنسبة لي، ربما باستثناء استخدامه في الرياضيات. ولكن قد يكون السبب وراء عدم شعبية ليسب يرجع ببساطة إلى تركيب الجملة غير المألوف... وسواء كان علينا أن نفعل أي شيء حيال ذلك، إذا كان هذا صحيحًا، فهذه مسألة أخرى.
3. ما الذي تحتاجه لبرنامج الخادم؟
أعتقد أن معظم التطبيقات التي ستتم كتابتها في العشرين عامًا القادمة ستكون تطبيقات ويب، بمعنى أن البرامج ستتواجد على خادم وتتواصل معك من خلال متصفح الويب. ولكتابة مثل هذه التطبيقات نحتاج إلى أشياء جديدة.
أحد هذه الأشياء هو دعم طريقة جديدة لإصدار تطبيقات الخادم. بدلاً من إصدار واحد أو إصدارين كبيرين سنويًا، مثل برامج سطح المكتب، سيتم إصدار برنامج الخادم في سلسلة من التغييرات الصغيرة. قد يكون لديك خمسة أو عشرة إصدارات في اليوم. وسيحصل الجميع دائمًا على أحدث إصدار.
هل تعرف كيفية تصميم البرامج لتكون قابلة للصيانة؟ يجب تصميم برنامج الخادم ليكون قابلاً للتغيير. يجب أن تكون قادرًا على تغييره بسهولة، أو على الأقل معرفة معنى التغيير البسيط وما هو المهم.
الشيء الآخر الذي يمكن أن يكون مفيدًا في برنامج الخادم هو استمرارية التسليم فجأة. في تطبيق الويب، يمكنك استخدام شيء مثل للحصول على تأثير الإجراءات الروتينية في عالم جلسات الويب عديمة الجنسية. قد يكون استمرارية العرض أمرًا يستحق العناء إذا لم تكن الميزة باهظة الثمن.
4. ما هي التجريدات الجديدة التي لا يزال يتعين اكتشافها؟
لست متأكدًا من مدى معقولية هذا الأمل، لكنني شخصيًا أرغب حقًا في اكتشاف تجريد جديد - شيء يمكن أن يكون ذا معنى مثل وظائف الدرجة الأولى أو العودية أو على الأقل المعلمات الافتراضية. ربما هذا حلم مستحيل. في كثير من الأحيان لا يتم اكتشاف مثل هذه الأشياء. لكنني لا أفقد الأمل.
أسرار غير معروفة
1. يمكنك استخدام أي لغة تريدها
في السابق، كان إنشاء التطبيقات يعني إنشاء برامج سطح المكتب. وفي برامج سطح المكتب هناك ميل كبير نحو كتابة التطبيقات بنفس لغة نظام التشغيل. لذا، قبل عشر سنوات، كانت كتابة البرامج بشكل عام تعني كتابة البرامج بلغة C. وفي نهاية المطاف، تطور التقليد: لا ينبغي كتابة التطبيقات بلغات غير عادية. وقد تطور هذا التقليد لفترة طويلة حتى أن الأشخاص غير التقنيين مثل المديرين وأصحاب رؤوس الأموال المغامرة قد تعلموه أيضًا.
يقوم برنامج الخادم بتدمير هذا النموذج بالكامل. مع برنامج الخادم يمكنك استخدام أي لغة تريدها. لا أحد تقريبًا يفهم هذا حتى الآن (خاصة المديرين وأصحاب رؤوس الأموال المغامرة). لكن بعض المتسللين يفهمون ذلك، ولهذا السبب نسمع عن اللغات الهندية مثل Perl وPython. لا نسمع عن Perl وPython لأن الناس يستخدمونهما لكتابة تطبيقات Windows.
ماذا يعني هذا بالنسبة لنا، نحن الأشخاص المهتمين بتصميم لغات البرمجة، أن هناك جمهورًا محتملاً لعملنا.
2. السرعة تأتي من الملامح
مطورو اللغة، أو على الأقل منفذي اللغة، يحبون كتابة مترجمين يقومون بإنشاء تعليمات برمجية سريعة. لكنني أعتقد أن هذا ليس ما يجعل اللغات سريعة بالنسبة للمستخدمين. لاحظ كنوث منذ فترة طويلة أن السرعة تعتمد على عدد قليل من الاختناقات. وأي شخص حاول تسريع برنامج ما يعرف أنه لا يمكنك تخمين مكان عنق الزجاجة. التعريف هو الجواب.
يقوم مطورو اللغة بحل المشكلة الخاطئة. لا يحتاج المستخدمون إلى معايير للتشغيل بسرعة. إنهم بحاجة إلى لغة يمكنها إظهار أجزاء برنامجهم التي تحتاج إلى إعادة كتابتها. في هذه المرحلة، هناك حاجة إلى السرعة في الممارسة العملية. لذلك ربما يكون من الأفضل أن يقضي منفذو اللغة نصف الوقت الذي يقضونه في تحسين المترجم وينفقونه على كتابة ملف تعريف جيد.
3. أنت بحاجة إلى تطبيق يجعل لغتك تتطور
قد لا تكون هذه هي الحقيقة المطلقة، لكن يبدو أن أفضل اللغات تطورت مع التطبيقات التي استخدمت فيها. تمت كتابة لغة C بواسطة أشخاص يحتاجون إلى برمجة الأنظمة. تم تصميم Lisp جزئيًا للتمايز الرمزي، وكان مكارثي حريصًا جدًا على البدء حتى أنه بدأ في كتابة برامج التمايز في أول ورقة بحثية لـ Lisp في عام 1960.
يعد هذا أمرًا جيدًا بشكل خاص إذا كان تطبيقك يحل بعض المشكلات الجديدة. وهذا يدفع لغتك إلى الحصول على ميزات جديدة يريدها المبرمجون. أنا شخصياً مهتم بكتابة لغة تكون مفيدة لتطبيقات الخادم.
[أثناء المناقشة، أشار جاي ستيل أيضًا إلى هذه النقطة، مضيفًا أن التطبيق لا ينبغي أن يتكون من كتابة مترجم للغتك، إلا إذا كانت لغتك مصممة لكتابة مترجمين.]4. أن تكون اللغة مناسبة لكتابة البرامج ذات المرة الواحدة.
أنت تعرف ما يعنيه برنامج اللقطة الواحدة: فهو عندما تحتاج إلى حل بعض المشكلات المحدودة بسرعة. أعتقد أنه إذا نظرت حولك، فستجد العديد من البرامج الجادة التي بدأت كمرة واحدة. لن أتفاجأ إذا بدأت معظم البرامج كبرامج لمرة واحدة. وبالتالي، إذا كنت ترغب في إنشاء لغة مناسبة لكتابة البرامج بشكل عام، فيجب أن تكون مناسبة أيضًا لكتابة البرامج لمرة واحدة، لأن هذه هي المرحلة الأولية للعديد من البرامج.
5. يرتبط بناء الجملة بالدلالات
يُعتقد تقليديًا أن بناء الجملة والدلالات شيئان مختلفان تمامًا. قد يبدو هذا صادما، لكنه ليس كذلك. أعتقد أن ما تريد تحقيقه في برنامجك يتعلق بكيفية التعبير عنه.
لقد تحدثت مؤخرًا مع روبرت موريس، وأشار إلى أن التحميل الزائد للمشغل يعد إضافة كبيرة لانتصار اللغات ذات بناء جملة infix. في اللغات ذات بناء الجملة البادئة، فإن أي وظيفة تحددها هي في الواقع عامل تشغيل. إذا كنت تريد إضافة نوع جديد من الأرقام التي قمت بتكوينها، فيمكنك ببساطة تحديد وظيفة جديدة لإضافتها. إذا قمت بذلك بلغة ذات بناء جملة infix، فسترى أن هناك فرقًا كبيرًا بين استخدام عامل التحميل الزائد واستدعاء دالة.
الأفكار التي تعود مع مرور الوقت
1. لغات البرمجة الجديدة
إذا نظرنا إلى السبعينيات، كان من المألوف تطوير لغات برمجة جديدة. هذا ليس الموضوع الان. لكنني أعتقد أن برنامج الخادم سيعيد مرة أخرى موضة إنشاء لغات جديدة. باستخدام برنامج الخادم، يمكنك استخدام أي لغة تريدها، لذلك إذا قام شخص ما بإنشاء لغة تبدو أفضل من البقية، فسيكون هناك أشخاص سيقررون استخدامها.
2. تقاسم الوقت
لقد جاء ريتشارد كيلسي بهذه الفكرة التي حان وقتها مرة أخرى وأنا أؤيدها تمامًا. أعتقد (ومايكروسوفت أيضًا) هو أن الكثير من أجهزة الكمبيوتر ستنتقل من سطح المكتب إلى الخوادم البعيدة. بمعنى آخر، لقد عادت مشاركة الوقت. أعتقد أن هذا سيحتاج إلى دعم على مستوى اللغة. على سبيل المثال، قام ريتشارد وجوناثان ريفز بالكثير من العمل لتنفيذ جدولة العمليات في المخطط 48.
3. الكفاءة
في الآونة الأخيرة، بدا أن أجهزة الكمبيوتر كانت بالفعل سريعة بما فيه الكفاية. نحن نسمع المزيد والمزيد عن الرمز الثانوي، وهو ما يعني على الأقل بالنسبة لي أن لدينا بعض القوة الاحتياطية. لكنني أعتقد أنه مع برنامج الخادم، لا نملكه. سيتعين على شخص ما أن يدفع مقابل الخوادم التي تقوم بتشغيل البرنامج، وسيكون عدد المستخدمين الذين يمكن للخادم دعمهم لكل جهاز مقسومًا على تكاليفهم الرأسمالية.
أعتقد أن الكفاءة ستكون مهمة، على الأقل في التعامل مع اختناقات الحوسبة. سيكون هذا مهمًا بشكل خاص لعمليات الإدخال/الإخراج، لأن تطبيقات الخادم تقوم بالكثير من هذه العمليات.
في النهاية، قد يتبين أن الرمز الثانوي ليس هو الحل. يبدو أن Sun وMicrosoft يتنافسان في مجال الرمز الثانوي في الوقت الحالي. لكنهم يفعلون ذلك لأن الكود الثانوي هو مكان مناسب لدمج نفسه في العملية، وليس لأن الكود الثانوي بحد ذاته فكرة جيدة. قد يتبين أن هذه المعركة برمتها سوف تمر دون أن يلاحظها أحد. اريد ان اكون مضحكا.
الأفخاخ والفخاخ
1. العملاء
هذا مجرد تخمين، ولكن التطبيقات الوحيدة التي ستستفيد هي تلك التي تكون من جانب الخادم بالكامل. إن تصميم البرامج التي تعمل على افتراض أن كل شخص سيكون لديه عميل يشبه تصميم مجتمع يعتمد على افتراض أن الجميع سيكونون صادقين. سيكون الأمر مريحًا بالتأكيد، لكن عليك أن تفترض أنه لن يحدث أبدًا.
أعتقد أنه ستكون هناك زيادة سريعة في الأجهزة التي تدعم الويب، ويمكننا أن نفترض أنها ستدعم لغة HTML الأساسية والنماذج. هل لديك متصفح على هاتفك؟ هل سيكون لدى جهاز PalmPilot الخاص بك هاتف؟ هل سيكون جهاز بلاك بيري الخاص بك بشاشة أكبر؟ هل ستتمكن من الوصول إلى الإنترنت من جهاز gameboy الخاص بك؟ من ساعتك؟ لا أعرف. ولن أضطر إلى معرفة ما إذا كنت أراهن على أن كل شيء سيكون على الخادم. من الأكثر موثوقية أن يكون لديك كل العقول على الخادم. .
2. البرمجة الشيئية
أدرك أن هذا بيان مثير للجدل، لكنني لا أعتقد أن OOP بهذه الأهمية. أعتقد أن هذا نموذج مناسب لتطبيقات محددة تحتاج إلى هياكل بيانات محددة، مثل أنظمة النوافذ والمحاكاة وأنظمة التصميم بمساعدة الحاسوب. لكنني لا أفهم لماذا يجب أن يكون مناسبًا لجميع البرامج.
أعتقد أن الأشخاص في الشركات الكبرى يحبون OOP، جزئيًا، لأنه يصنع الكثير من الأشياء التي تبدو وكأنها عمل. ما يمكن تمثيله بشكل طبيعي، على سبيل المثال، كقائمة من الأعداد الصحيحة، يمكن الآن تمثيله كفصل دراسي به كل أنواع السقالات والصخب والضجيج.
ميزة أخرى جذابة لـ OOP هي أن الأساليب تمنحك بعضًا من تأثير وظائف الدرجة الأولى. لكن هذا ليس خبرًا جديدًا لمبرمجي Lisp. عندما يكون لديك وظائف حقيقية من الدرجة الأولى، يمكنك ببساطة استخدامها بأي طريقة تناسب المهمة التي تقوم بها، بدلاً من دفع كل شيء إلى قالب معياري من الفئات والأساليب.
أعتقد أن ما يعنيه هذا بالنسبة لتصميم اللغة هو أنه لا ينبغي عليك تضمين OOP بشكل عميق فيه. ربما يكون الجواب هو تقديم أشياء أكثر عمومية وتأسيسية، والسماح للأشخاص بتصميم أي أنظمة كائنية كمكتبات.
3. التصميم من قبل اللجنة
إذا تم تصميم لغتك من قبل لجنة، فأنت محاصر، وليس فقط لأسباب يعرفها الجميع. يعلم الجميع أن اللجان تميل إلى إنشاء تصميمات لغوية متكتلة وغير متناسقة. لكنني أعتقد أن الخطر الكبير هو أنهم لا يخاطرون. عندما يتولى شخص واحد المسؤولية، فإنه يخوض مخاطر لن توافق اللجنة على مواجهتها أبدًا.
هل تحتاج إلى المخاطرة لإنشاء لغة جيدة؟ قد يشك الكثير من الناس في أن تصميم اللغة هو المكان الذي يجب أن تظل فيه قريبًا جدًا من الحكمة التقليدية. أراهن أن هذا ليس هو الحال. وفي كل ما يفعله الناس، فإن المكافأة تتناسب مع المخاطرة. فلماذا يجب أن يكون تصميم اللغة مختلفًا؟
المصدر: www.habr.com