كيف يتم إنشاء لغة برمجة؟

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

• تصميم لغة البرمجة و وضع قواعدها القياسية:

و هناك العديد من المناهج في تصميم لغات البرمجة، و التي تختلف فيما بينها حسب الهدف النهائي الذي يضعه مصمم/وا تلك اللغة؛ فهناك منهجية "التطوير superset" (و تعريب هذا المصطلح من عندي) و التي يتم فيها أخذ لغة موجودة فعلياً و إضافة بعض الإمكانيات الجديدة لها ثم صنع لغة جديدة، و ذلك للحفاظ علي قدرة المُفسِّر interpreter و/أو المترجِم compiler الخاص بتلك اللغة الجديدة علي تنفيذ البرامج المكتوبة باللغة القديمة (حالة من التوافقية العكسية backword compatibility)، و هذا له من الفوائد الكثير جداً و منها أنه يحافظ علي كل البرمجيات المكتوبة باللغة القديمة و لا يجبر أصحابها علي إعادة كتابتها بلغة حديثة، و غير ذلك من المميزات. و لكنه أيضاً له من العيوب ما يجعلني أنفر منه بشدة؛ لأنه يفرض علي مصمم اللغة خطوطاً حمراء بالغة القوة لا يجوز له تجاوزها بحال من الأحوال، و أي خرق فيهن سيعرضه لهدم التوافقية العكسية التي يسعي وراءها و لو في حالات قليلة !

مثل حالة لغة الـ++C التي تُعتبر تطويراً للغة الـC بحيث يتم إضافة نمط البرمجة الكائنية إليها زيادة علي النمط الإجرائي procedural الذي تعتمد عليه تلك الأخيرة، حتي أن اسم الـ++C في البداية كان "C with classes" حسبما أتذكر!، و كذلك هناك لغة الـobjective C و التي تُعتبر أيضاً تطويراً كائنياً للغة الـC، و التي قال مبتكرها Brad Cox واصفاً إياها: "a hybrid language that contains all of C language plus major parts of Smalltalk"، و هو ما معناه: "لغةٌ هجينة تحوي كل لغة الـC بالإضافة إلي الأجزاء الرئيسة من Smalltalk".

و هناك أيضاً حالة لغة الـTypeScript الخاصة بـMicrosoft و التي قاموا فيها بإضافة قواعد البرمجة الكائنية OOP المعتمدة علي الأصناف classes إلي لغة الـjavascript، مع جعلها تدعم نظام التنويع الثابت static type system مع النظام المتغيرdynamic typing الذي تدعمه الـjavascript. و ذلك لجعل الأخيرة أكثر قدرة علي التعامل مع المشاريع البرمجية الضخمة التي يعاني أصحابها من قصور الـjavascript عند استخدامهم إياها فيها (علي الأقل هذه وجهة نظر مهندسي Microsoft).

و بالطبع هناك لغة الـobject pascal التي هي تطويرٌ للغة الـpascal... إلخ.

و بالإضافة لمنهجية التطوير فهناك منهجية "الاجتزاء subset" (و هو تعريبٌ آخر من عندي) التي يتم فيها أخذ قواعد لغة برمجة مشهورة ثم حذف بعضها و/أو تغييره بما يتوافق مع أهداف المصمم/ين، مثل لغة Rpython التي هي اجتزاء للغة الـpython في مشروع الـpypy، و التي تم فيها مثلاً التخلص من بعض القواعد المتعلقة بالقدرة علي تغيير أنواع المتغيرات في زمن التنفيذ runtime في لغة الـpython؛ حيث أنهم احتاجوا إلي أن يكون بإمكانهم تحويل أكواد مكتوبة بلغة python إلي لغة الـC، و لكنهم وجدوا أن هناك تلك المواصفات (و غيرها) لا يمكن فعل ذلك معها (و أنا أظن أنه إن تم فسيكون علي حساب الكثير جداً من الوقت و الجهد، و سيحتاج إلي حيل سحرية و أكواد أفعوانية، و لن يكون الناتج النهائي مرضياً بحالٍ من الأحوال، أي سيكون الأمر باختصار موتاً و خراب ديار !)، و لذلك قرروا منعها و عمل مترجم لا يعترف بها، و بما أن مجموعة المواصفات الجديدة أصبحت نسخة مصغرة من مجموعة المواصفات الخاصة بلغة الـpython فقد أطلقوا عليها Restricted Python أي "بايثون المُقيَّدة"، و في موقعهم هناك توضيحات لمثل هذه التقييدات لمن يرغب في الاطلاع عليها http://doc.pypy.org/en/late...

و هناك كذلك لغة ASM.js التي استوحتها mozilla من لغة javascript، و لكن هذه المرة كان الحال علي العكس من حالة الـTypescript؛ لأنه في الـASM.js تم التخلص من بعض القواعد عالية المستوي في الـjavascript و الاحتفاظ ببقية القواعد التي تجعل عمل البرمجيات المكتوبة بها أكثر سرعة، خاصةً حينما يتم تحسين المتصفحات لتسريع تلك العمليات بالذات. و الهدف النهائي من وراء هذا هو أن تعمل كأنها web assembly، فيتم ترجمة البرامج الأصلية native من أكواد C و/أو ++C إلي ASM.js لتعمل بسرعة قريبة جداً من سرعة البرنامج الأصلي لكن داخل بيئة المتصفح !

و في النهاية هناك منهجية أخذ مميزات العديد من اللغات الأخريات و محاولة المزج بينهن قدر الإمكان، مع عدم الالتزام بالتوافقية العكسية مع البرامج المكتوبة بأي لغة قديمة (و هو النوع الذي أميل إليه بشكل شخصي، و إن كنتُ أقدِّر بقية الأنواع و حاجتنا إليها).

• بناء مفسر و/أو مترجم يقوم بتنفيذ البرامج المكتوبة بتلك اللغة:

و هذا الأمر ينطوي علي الكثير جداً من الأعمال، منها بناء ما يسمي بالـlexer و الـparser و التمثيل الوسيط intermediate representation و الواجهات الخلفية backends، و غيرهن من التفاصيل الداخلية الخاصة بمثل هذه البرمجيات المعقدة. و خطوة بناء المفسر و/أو المترجم هي التي تجعل اللغة تتحول من مجرد تخطيط نظري إلي واقع ملموس يمكن التعامل معه و تجريبه و إعطاء الانطباعات العملية عنه. بينما لو ظلت اللغة مجرد تصميم نظري فربما يكون فيها من العلل التصميمية ما لا يمكن اكتشافه؛ للحاجة إلي وضعه علي المحك و الحكم عليه واقعياً.

• بناء الأدوات المساعدة للمبرمجين في تسهيل البرمجة بتلك اللغة:

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

و الأدوات المساعدة منها محرر أكواد text editor له فهم كبير بقواعد اللغة و يمكنه مساعدة المبرمج في التعامل مع الأكواد المكتوبة باللغة بسهولة و يسر، فييسر له عملية البحث عن نصوص معينة، أو تغيير المُعرِّفات identifiers الخاصة بالمتغيرات variables و الدوال و الإجراءات functions and procedures و الأصناف classes و ما شابههن من المكونات بمنتهي اليسر، و هو الأمر الذي تظهر أهميته الشديدة ف حالة المشاريع ذات أعداد الأسطر البرمجية الضخمة. و كذلك من أفضل الطرق التي يساعد بها محرر النصوص المبرمج هو تلوين الأكواد بشكل يجعل الأخير يحتاج لوقت أبسط بكثير لاستخلاص المعلومات التي تهمه من وسط عشرات الأسطر التي تقع عينه عليها. و هناك المُنقح debugger الذي يساعد المبرمج علي العثور علي العلل bugs في الأكواد التي بها خلل في خوارزماتها، و غيرهن من الأدوات الأخريات اللاتي يزدن إنتاجية المبرمج.

• تحسين تصميم لغة البرمجة:

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

==================

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