التغلب على المتوسطات

هل تريد بدء شركة ناشئة؟ احصل على تمويل من Y Combinator.


أبريل 2001، مراجعة أبريل 2003

(هذه المقالة مستمدة من خطاب ألقي في مؤتمر Franz Developer Symposium لعام 2001.)

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

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

كان الشيء الآخر غير العادي في هذا البرنامج هو أنه كُتب بشكل أساسي بلغة برمجة تسمى Lisp. كانت واحدة من أولى التطبيقات الكبيرة للمستخدم النهائي التي كُتبت بلغة Lisp، والتي كانت حتى ذلك الحين تستخدم في الغالب في الجامعات ومختبرات الأبحاث.[1]

السلاح السري

كتب إريك ريموند مقالة بعنوان "كيف تصبح هاكر"، وفيها، من بين أمور أخرى، يخبر الهاكرز الطموحين باللغات التي يجب أن يتعلموها. يقترح البدء بـ Python و Java، لأنهما سهلتان في التعلم. سيحتاج الهاكر الجاد أيضًا إلى تعلم C، لاختراق Unix، و Perl لإدارة النظام وسكربتات cgi. أخيرًا، يجب على الهاكر الجاد حقًا التفكير في تعلم Lisp:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

كان الأشخاص الذين فهموا تقنيتنا بشكل أفضل هم العملاء. لم يهتموا باللغة التي كُتبت بها Viaweb أيضًا، لكنهم لاحظوا أنها تعمل بشكل جيد حقًا. لقد سمحت لهم ببناء متاجر رائعة عبر الإنترنت في دقائق حرفيًا. وهكذا، عن طريق الكلام الشفهي في الغالب، حصلنا على المزيد والمزيد من المستخدمين. بحلول نهاية عام 1996 كان لدينا حوالي 70 متجرًا عبر الإنترنت. في نهاية عام 1997 كان لدينا 500. بعد ستة أشهر، عندما استحوذت عليها Yahoo، كان لدينا 1070 مستخدمًا. اليوم، بصفتها Yahoo Store، تستمر هذه البرامج في الهيمنة على سوقها. إنها واحدة من أكثر القطع ربحًا في Yahoo، والمتاجر المبنية بها هي أساس Yahoo Shopping. غادرت Yahoo في عام 1999، لذلك لا أعرف بالضبط عدد المستخدمين لديهم الآن، لكن آخر ما سمعته كان حوالي 20,000.

مفارقة Blub

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

سأبدأ ببيان مثير للجدل بشكل صادم: تختلف لغات البرمجة في قوتها.

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

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

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

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

فكر في Cobol. Cobol هي لغة عالية المستوى، بمعنى أنها تُترجم إلى لغة الآلة. هل سجادل أي شخص بجدية بأن Cobol مكافئة في القوة لـ Python، على سبيل المثال؟ إنها أقرب إلى لغة الآلة من Python.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

أيكيدو للشركات الناشئة

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

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

عادةً ما تتغير التكنولوجيا بسرعة. لكن لغات البرمجة مختلفة: لغات البرمجة ليست مجرد تكنولوجيا، بل هي ما يفكر به المبرمجون. إنها نصف تكنولوجيا ونصف دين.

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

بالطبع، كلا هاتين الإجابتين تحتاجان إلى شرح.

سأبدأ ببيان مثير للجدل بشكل صادم: تختلف لغات البرمجة في قوتها.

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

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

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

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

فكر في Cobol. Cobol هي لغة عالية المستوى، بمعنى أنها تُترجم إلى لغة الآلة. هل سجادل أي شخص بجدية بأن Cobol مكافئة في القوة لـ Python، على سبيل المثال؟ إنها أقرب إلى لغة الآلة من Python.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

أيكيدو للشركات الناشئة

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

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

عادةً ما تتغير التكنولوجيا بسرعة. لكن لغات البرمجة مختلفة: لغات البرمجة ليست مجرد تكنولوجيا، بل هي ما يفكر به المبرمجون. إنها نصف تكنولوجيا ونصف دين.

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

ملاحظات

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

في يناير 2003، أصدرت Yahoo إصدارًا جديدًا من المحرر مكتوبًا بلغة C++ و Perl. من الصعب القول ما إذا كان البرنامج لم يعد مكتوبًا بلغة Lisp، على الرغم من ذلك، لأنه لترجمة هذا البرنامج إلى C++ كان عليهم حرفيًا كتابة مترجم Lisp: ملفات المصدر لجميع قوالب إنشاء الصفحات لا تزال، على حد علمي، كود Lisp. (انظر القاعدة العاشرة لجرينسبون.)

[2] يقول روبرت موريس إنني لم أكن بحاجة إلى أن أكون سريًا، لأنه حتى لو كان منافسونا يعرفون أننا نستخدم Lisp، لما فهموا السبب: "لو كانوا أذكياء بما فيه الكفاية لكانوا يبرمجون بالفعل بلغة Lisp."

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

[4] ملاحظة للمهتمين: أو ربما شبكة، تضيق نحو الأعلى؛ ليس الشكل هو المهم هنا بل فكرة وجود ترتيب جزئي على الأقل.

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

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