الشعبية

مايو 2001

(كُتب هذا المقال كنوع من خطة العمل للغة برمجة جديدة. لذا فهو يفتقر (لأنه يأخذها كأمر مسلم به) إلى أهم ميزة في لغة برمجة جيدة: التجريدات القوية جدًا.)

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

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

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

1 آليات الشعبية

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

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

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

رأي الهاكرز الخبراء ليس القوة الوحيدة التي تحدد الشعبية النسبية للغات البرمجة - فالبرامج القديمة (Cobol) والضجيج (Ada، Java) تلعب دورًا أيضًا - لكنني أعتقد أنها أقوى قوة على المدى الطويل. بالنظر إلى كتلة حرجة أولية ووقت كافٍ، تصبح لغة البرمجة على الأرجح شائعة بقدر ما تستحق. والشعبية تفصل بشكل أكبر بين اللغات الجيدة والسيئة، لأن ردود الفعل من المستخدمين الحقيقيين تؤدي دائمًا إلى تحسينات. انظر إلى مدى تغير أي لغة شائعة خلال حياتها. Perl و Fortran حالات متطرفة، لكن حتى Lisp تغيرت كثيرًا. Lisp 1.5 لم يكن لديها وحدات ماكرو، على سبيل المثال؛ تطورت هذه لاحقًا، بعد أن أمضى الهاكرز في MIT بضع سنوات في استخدام Lisp لكتابة برامج حقيقية.[1]

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

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

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

2 العوامل الخارجية

لنبدأ بالاعتراف بعامل خارجي واحد يؤثر على شعبية لغة البرمجة. لتصبح لغة برمجة شائعة، يجب أن تكون لغة البرمجة النصية لنظام شائع. كانت Fortran و Cobol لغات البرمجة النصية لأجهزة IBM الرئيسية المبكرة. كانت C لغة البرمجة النصية لـ Unix، ولاحقًا Perl. Tcl هي لغة البرمجة النصية لـ Tk. Java و Javascript مخصصتان لتكونا لغات البرمجة النصية لمتصفحات الويب.

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

اليوم، Lisp هي لغة البرمجة النصية لنظامين شائعين بشكل معتدل، Emacs و Autocad، ولهذا السبب أشك في أن معظم برمجة Lisp التي تتم اليوم تتم في Emacs Lisp أو AutoLisp.

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

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

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

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

تحتاج اللغة أيضًا إلى كتاب عنها. يجب أن يكون الكتاب رفيعًا، مكتوبًا جيدًا، ومليئًا بأمثلة جيدة. K&R هو المثالي هنا. في الوقت الحالي، أقول تقريبًا أن اللغة تحتاج إلى كتاب منشور بواسطة O'Reilly. هذا يصبح اختبارًا للأهمية بالنسبة للهاكرز.

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

3 الإيجاز

بالنظر إلى أنه يمكنك توفير الأشياء الثلاثة التي تحتاجها أي لغة - تنفيذ مجاني، وكتاب، وشيء للهاك - كيف تصنع لغة يحبها الهاكرز؟

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

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

أضف س إلى ص مع إعطاء ع

بدلاً من

ع = س+ص

كشيء بين إهانة لذكائه وخطيئة ضد الله.

قيل أحيانًا أن Lisp يجب أن تستخدم first و rest بدلاً من car و cdr، لأن ذلك سيجعل البرامج أسهل في القراءة. ربما للساعتين الأوليين. لكن الهاكر يمكنه أن يتعلم بسرعة كافية أن car تعني العنصر الأول في القائمة و cdr تعني الباقي. استخدام first و rest يعني 50٪ كتابة إضافية. كما أنها أطوال مختلفة، مما يعني أن الوسائط لن تصطف عند استدعائها، كما هو الحال غالبًا مع car و cdr، في أسطر متتالية. لقد وجدت أن كيفية محاذاة الكود على الصفحة مهمة جدًا. بالكاد أستطيع قراءة كود Lisp عندما يتم تقديمه بخط بعرض متغير، ويقول الأصدقاء أن هذا ينطبق على اللغات الأخرى أيضًا.

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

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

4 قابلية الهاك

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

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

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

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

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

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

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

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

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

5 برامج يمكن التخلص منها

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

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

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

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

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

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

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

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

6 المكتبات

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

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

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

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

7 بناء الجملة

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

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

مشكلة أكثر خطورة هي انتشار التدوين البادئ. بالنسبة للهاكرز الخبراء، هذه مشكلة حقيقية. لا أحد يريد كتابة (aref a x y) عندما يمكنهم كتابة a[x,y].

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

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

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

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

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

أخبرني هاكر Lisp بارز أن نسخته من CLTL تنفتح على قسم format. نسختي أيضًا. هذا ربما يشير إلى مجال للتحسين. قد يعني أيضًا أن البرامج تقوم بالكثير من عمليات الإدخال/الإخراج.

8 الكفاءة

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

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

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

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

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

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

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

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

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

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

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

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

9 الوقت

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

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

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

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

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

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

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

النهج الآخر، طريقة الانفجار الكبير، يتجسد في شركة ناشئة مدعومة من رأس المال الاستثماري، ويتم تسويقها بكثافة. يندفعون لتطوير منتج، ويطلقونه بدعاية كبيرة، وعلى الفور (يأملون) لديهم قاعدة مستخدمين كبيرة.

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

هذا النمط لا ينطبق فقط على الشركات. تراه في الأبحاث المدعومة أيضًا. كانت Multics و Common Lisp مشاريع انفجار كبير، وكانت Unix و MacLisp مشاريع نمو عضوي.

10 إعادة التصميم

"أفضل كتابة هي إعادة الكتابة"، كتب E. B. White. كل كاتب جيد يعرف هذا، وهذا صحيح للبرامج أيضًا. أهم جزء في التصميم هو إعادة التصميم. لغات البرمجة، خاصة، لا يُعاد تصميمها بما فيه الكفاية.

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

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

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

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

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

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

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

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

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

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

11 Lisp

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

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

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

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

في "كيف تصبح هاكرًا"، يصف إريك ريموند Lisp بأنها تشبه اللاتينية أو اليونانية - لغة يجب أن تتعلمها كتمرين فكري، على الرغم من أنك لن تستخدمها فعليًا:

Lisp تستحق التعلم للتجربة التنويرية العميقة التي ستمر بها عندما تفهمها أخيرًا؛ ستجعلك تلك التجربة مبرمجًا أفضل لبقية أيامك، حتى لو لم تستخدم Lisp نفسها كثيرًا في الواقع.

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

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

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

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

توفر التطبيقات المستندة إلى الخادم أيضًا الإجابة على سؤال ما الذي سيتم استخدام لغة Lisp الجديدة هذه للهاك. لن يضر جعل Lisp أفضل كلغة برمجة نصية لـ Unix. (سيكون من الصعب جعلها أسوأ.) لكنني أعتقد أن هناك مجالات يمكن فيها التغلب على اللغات الحالية بسهولة أكبر. أعتقد أنه قد يكون من الأفضل اتباع نموذج Tcl، وتوفير Lisp مع نظام كامل لدعم التطبيقات المستندة إلى الخادم. Lisp مناسبة بشكل طبيعي للتطبيقات المستندة إلى الخادم. توفر الإغلاقات المعجمية طريقة للحصول على تأثير الروتينات الفرعية عندما يكون واجهة المستخدم مجرد سلسلة من صفحات الويب. تتناسب S-expressions بشكل جيد مع HTML، ووحدات الماكرو جيدة في إنشائها. هناك حاجة إلى أدوات أفضل لكتابة التطبيقات المستندة إلى الخادم، وهناك حاجة إلى لغة Lisp جديدة، وسيعمل الاثنان معًا بشكل جيد للغاية.

12 لغة الأحلام

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

بناء جملة اللغة موجز للغاية. لا تحتاج أبدًا إلى كتابة حرف غير ضروري، أو حتى استخدام مفتاح Shift كثيرًا.

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

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

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

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

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

ملاحظات

[1] تم اقتراح وحدات ماكرو قريبة جدًا من الفكرة الحديثة من قبل تيموثي هارت في عام 1964، بعد عامين من إصدار Lisp 1.5. ما كان مفقودًا في البداية هو طرق لتجنب التقاط المتغيرات والتقييم المتعدد؛ أمثلة هارت تخضع لكليهما.

[2] في كتاب "عندما يضرب الهواء دماغك"، يروي جراح الأعصاب فرانك فيرتوسيك محادثة يتحدث فيها كبير المقيمين لديه، غاري، عن الفرق بين الجراحين وأطباء الباطنة ("البراغيث"):

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

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