لغة المائة عام

أبريل 2003

(هذه المقالة مستمدة من كلمة رئيسية في مؤتمر PyCon لعام 2003.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

بالطبع، أنا أقوم بافتراض كبير بمجرد طرح سؤال حول كيف ستكون لغات البرمجة بعد مائة عام. هل سنكتب برامج بعد مائة عام؟ ألن نخبر أجهزة الكمبيوتر بما نريد منها أن تفعله؟

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

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

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

مهما كانت المواد التي ستصنع منها أجهزة الكمبيوتر بعد مائة عام، يبدو من الآمن التنبؤ بأنها ستكون أسرع بكثير مما هي عليه الآن. إذا استمر قانون مور في العمل، فستكون أسرع بـ 74 كوينتيليون (73,786,976,294,838,206,464) مرة. هذا يصعب تخيله نوعًا ما. وفي الواقع، قد يكون التنبؤ الأكثر احتمالًا في قسم السرعة هو أن قانون مور سيتوقف عن العمل. أي شيء يُفترض أن يتضاعف كل ثمانية عشر شهرًا يبدو أنه سيصطدم بنوع من الحد الأقصى الأساسي في النهاية. لكن ليس لدي مشكلة في الاعتقاد بأن أجهزة الكمبيوتر ستكون أسرع بكثير. حتى لو انتهى بها الأمر بأن تكون أسرع بمليون مرة فقط، فإن ذلك يجب أن يغير القواعد الأساسية للغات البرمجة بشكل كبير. من بين أمور أخرى، سيكون هناك مجال أكبر لما يمكن اعتباره الآن لغات بطيئة، مما يعني لغات لا تنتج شفرة فعالة جدًا.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ملاحظات

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

شكرًا لـ Trevor Blackwell و Robert Morris و Dan Giffin لقراءة مسودات هذا، ولـ Guido van Rossum و Jeremy Hylton وبقية فريق Python لدعوتي للتحدث في PyCon.