💅🏾 🧙 ▶️ بول جراهام: الإيجاز = القوة 🙎🏿 👨🏾‍🤝‍👨🏽 💇🏿

اليوم في هاكر نيوز أثارنا مناقشة لمقالة بول جراهام في عام 2002 وقررنا إحياء ترجمتها من عدم الوجود.

"إن كمية المعنى المضغوطة في مساحة صغيرة من
خلال العلامات الجبرية ، هي ظرف آخر يسهل
الاعتراضات التي اعتدنا على الاستمرار بها من خلال مساعدتهم".
- تشارلز باباج (1791-1871)

في المناقشة حول مقالة LL1 Revenge في قائمة LL1 البريدية ، أثار بول بريسكود نقطة لم تكن من رأسي.

هدف Python هو الانتظام وسهولة القراءة ، ولكن ليس الإيجاز.

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

هدف Python هو الانتظام وسهولة القراءة ، ولكن ليس القوة.

وهو بدوره ليس تسوية جيدة للغاية (إذا كان حقًا تسوية) ، وهو أمر يستحق القيام به. يبدو أنك إذا قلت: الهدف من لغة Python ليس أن تكون لغة برمجة فعالة.

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

فرضية

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

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

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

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

المقاييس

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

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

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

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

التصميم

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

إذا كان الحمل المفاهيمي للبرنامج متناسبًا مع تعقيده ، ويمكن لمبرمج معين أن يتحمل حملًا مفاهيميًا معينًا ، فإن هذا هو نفس السؤال: كيف يمكن مساعدة المبرمجين على القيام بالمزيد؟ ويبدو لي أن هذا هو نفس السؤال: كيف تصمم لغة جيدة؟

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

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

مقارنة

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

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

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

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

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

التقارير في هذا المجال ، على الرغم من أنها ستكون أقل دقة من الدراسات "العلمية" ، من المرجح أن تكون ذات معنى. على سبيل المثال ، أجرى Ulf Viger من Ericsson دراسة وخلص إلى أن Erlang أقصر بـ 4-10 مرات من C ++ ، وأن سرعة تطوير البرامج عليه أعلى نسبيًا:

تكشف مقارنة المشاريع الداخلية في Ericsson عن إنتاجية مماثلة في سطور الكود في الساعة ، بما في ذلك جميع مراحل التطوير ، بغض النظر عن اللغة المستخدمة (Erlang أو PLEX أو C أو C ++ أو Java). الاختلافات في اللغات - فقط في المبلغ الإجمالي لشفرة المصدر.

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

الأذواق

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

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

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

محددات

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

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

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

مقروئية

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

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

الجهد الكلي = جهد لقراءة سطر واحد * عدد الأسطر

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

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

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

بأي درجة؟

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

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

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

لغات لكن ليس برامج

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

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

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

وبالتالي ، لا جدال - على الأقل بالنسبة لي - أن البرامج يمكن أن تكون موجزة بما فيه الكفاية. السؤال هو ، هل يمكن أن تكون اللغات نفسها قصيرة؟ هل يمكن للغات إجبار المبرمجين على الكتابة لفترة وجيزة (في العناصر) على حساب سهولة القراءة؟

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

(rec zero 1 * 1-)

يمكنك أيضًا كتابة تعريف تعاودي: على

(rfn fact (x) (if (zero x) 1 (* x (fact (1- x)))))

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

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

تم نشره هنا لأول مرة .

تعرف على تفاصيل كيفية الحصول على مهنة مرغوبة من الصفر أو المستوى الأعلى في المهارات والراتب من خلال الحصول على دورات SkillFactory عبر الإنترنت:

بول جراهام: الإيجاز = القوة