إذا اخترع لغة برمجة القرن الحادي والعشرين

يناقش مؤلف المقال مشكلات لغات البرمجة الحديثة وحول الطرق التي يمكن بها تصحيح أوجه القصور.


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

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

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

يسقط بناء الجملة!

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

لم يعد إدخال النص من لوحة المفاتيح أمرًا صعبًا. لسنا ملزمين بوضع أنفسنا في موقف حيث من الضروري تخمين معنى بناء الجملة. القطع مثل (($: @ (<# [) ، (= # [) ، $: @ (> # [)) ({~؟ @ #)) ^: (1 <#) - نسق تسجيل قصير للغاية ورخيص (هذا ، بالمناسبة ، جزء حقيقي من الشفرة بلغة حقيقية ) ، لكنه لا يحسن قابلية القراءة بأي طريقة. والأهم من ذلك ، أنه من الصعب "google" أو العثور عليه على stackoverflow.

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

شيء من هذا القبيل

FILE * test_file = fopen("/tmp/test.txt", "w+");

يجب أن تتحول إلى

create file /tmp/test.txt for input and output as test_file

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

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

إلى أسفل مع أنواع المدمج في!

من المحتمل أن تكون معتادًا على مفارقات JavaScript . على سبيل المثال ، مثل:

> 10.8 / 100
0.10800000000000001

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

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

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

0xFFFF + 0x0001

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

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

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

1.000 / 3.000 = 0.333
0001 + 9999 = overflowed 9999
0.001 / 2 = underflowed 0

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

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

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

إلى أسفل مع ممارسة metalanguages!

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

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

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

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

وكان ضخم. يحتوي المعيار INCITS 226–1994 على 1،153 صفحة. تم كسر هذا السجل بعد 17 عامًا فقط بواسطة C ++ باستخدام المعيار ISO / IEC 14882: 2011 (1338 صفحة). يجب على C ++ سحب إرث لا يُطاق ، على الرغم من أنه لم يكن دائمًا كبيرًا جدًا. تم إنشاء Lisp الشائعة للجزء الأكبر من البداية.

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

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

لذلك ...

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

نعم ، هذا كوبول.

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

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

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

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

ولكن على الأرجح هذا اليوم لن يأتي أبدا.

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