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