الخميس، 17 نوفمبر، 2011

ترجمة hints on programming language design - جـ1

هذا جزءٌ من ترجمةٍ لورقةٍ علمية للبروفيسور (C.A.R Hoare) بعنوان (hints on programming language design) أي (ملاحظاتٍ حول تصميم لغة البرمجة)، و قد تأثرت بها بشدةٍ و أردت ترجمتها كاملةً ليستفيد منها طلبة العلم العرب بدون الحاجة للمعاناة مع النص الأصلي، و قد ترجمت القليل منها منذ فترةٍ طويلة و أنتوي إكمال الترجمة حينما يتيسر لي هذا بإذن الله تعالي.
و ها هو ذا النص المترجم:
 
ملخص:
هذه الورقة العلمية (المبنية على عنونةٍ رئيسة قدمت فى معرض/مؤتمر الـ(SIGACT/SIGPLAN) الخاص بأساسيات لغات البرمجة و الذى أقيم فى بوسطون من 1 إلى 3 أكتوبر 1973) تقدم نظرةً إلى لغة البرمجة على أنها أداةٌ يجب عليها أن تساعد المبرمج فى أصعب مناحى عمله، و تحديداً فى تصميم و توثيق و تنقيح البرمجيات
 و تُناقش المعايير الموضوعية لتقييم تصميم لغةٍ ما، و تُوضح ذلك بالتطبيق على خواص كلاً من: لغات المستوى العالى و اللغات اللصيقة بالآلة، و ملحقٌ بهذه الورقة قائمةٌ بأسماء مراجع منصوح بها لمصممى اللغات.

مقدمة:
أود فى هذه الورقة أن أقدم رؤيةً لتصميم و تطور لغات البرمجة و التى تبنيتها و طورتها عبر سنين عدة، و التى تنص على أن السبب الأساسى لوجود لغة البرمجة هو مساعدة المبرمج فى واقعه العملى
و لا أرغب فى إنكار أن هناك العديد من الصفات الأخرى المرغوب فيها للغة البرمجة، على سبيل المثال:
- الانفصال عن الآلة،
- استقرار التوصيف،
- استخدام رموزٍ و علاماتٍ مألوفة،
- مكتبةٌ ضخمةٌ و مفيدة،
- الشهرة الحالية الكبيرة، أو المِلكية من مؤسسةٍ غنيةٍ و قوية.
فهذه الصفات هى المهيمنة عند اختيار المستخدمين للغة برمجةٍ ما، و لكننى أرغب فى المجادلة حول عدم أحقيتها بذلك، و لهذا يجب أن أوضح نفسى جيداّ و أخشى أن كل قارئ سيجد بعضاً من نقاطى مثيراً للجدل كثيراً، و أتوقع أنه سيجد البعض الآخر من هذه النقاط واضحاً و ربما مملاً، و لكنى آمل أن يجد فيها بضع نقاطٍ جديدةٍ تستحق الإهتمام.
منهجى هو أن أقوم أولاً بعزل المناحى الأكثر صعوبةً فى عمل المبرمج، و من ثم أقوم فى بنودٍ عامةٍ بتحديد كيف لتصميم لغة البرمجة أن يساعد فى التغلب على هذه الصعوبات
و سأناقش عدداً من الأهداف التى وضعها مصمموا اللغات البرمجية السابقين نصب أعينهم و التى أظن أنها غير ذات صلةٍ أو أهميةٍ بل و حتى مضلِّلًة، و بعدها سأنتقل إلى مناحٍ معينةٍ فى لغات البرمجة عالية المستوى المألوفة، و سأوضح لم هى فى أحيانٍ ما أفضل من البرمجة بلغة الآلة، و فى أحيانٍ أخرى أسوأ.  
و نهاية فسأوضح الفارق بين تصميم صفات لغة، و تصميم لغاتٍ كاملة.
و الملحق يحوى قائمةً أنصح بها كخلفيةٍ تعليميةٍ عامةٍ لمصممى لغات البرمجة المستقبليين.
الأساسيات:
إذا ما نظر إلى لغة البرمجة على أنها أداةٌ لمساعدة المبرمج: فإنها يجب أن تمد له أقصى المساعدة فى أصعب مناحى عمله، و بالتحديد فى تصميم و توثيق و تنقيح debug البرامج.
* تصميم البرنامج:
المنحى الأول و الصعب للغاية فى التصميم هو تحديد ما الذى سيقوم به البرنامج بالضبط، و تحويل ذلك إلى توصيفٍ واضحٍ و دقيقٍ و مقبول، و غالباً على نفس القدر من الصعوبة تقرير كيفية القيام بذلك، أى كيفية تقسيم مهمةٍ معقدةٍ إلى مهامٍ فرعيةٍ أبسط، و توصيف الهدف من وراء كل مهمةٍ فرعيةٍ ثم تعريف واجهاتٍ واضحةٍ و دقيقةٍ و كفؤةٍ بينها
و لغة البرمجة الجيدة لن تساعد فقط على التعبير عن كيفية عمل البرنامج بل كذلك عما يهدف للوصول إليه، و يجب عليها أن تمكن من التعبير عن ذلك على مختلف المستويات، بدءاً من التخطيط العام و انتهاءا بالتكويد و تمثيل البيانات.
و يجب أن تساعد على تشييد و إجبار القناعات و التنظيمات البرمجية و التى ستؤكد التعاون المتناغم لأجزاء البرامج الضخمة حينما تُنْتَج منفردةً ثم يتم تجميعها.
التوثيق البرمجى:
الغرض من وراء توثيق البرنامج شرح الطريقة التى يعمل بها البرنامج، بحيث يسهل التعامل معها بعد دخولها للخدمة، إما لموافاة الإحتياجات المتغيرة لمستخدميها، أو لتطويرها على ضوء المعرفة المطورة، أو حتى لإزالة الأخطاء و التجاوزات بها
و النظرة إلى التوثيق على أنه شئٌ فرعىٌ يُضاف إلى المنتَج البرمجى بعد إنتاجه خطأٌ فى الأساس و عائقٌ فى طريق الإنتاج عملياً، و بدلاً من ذلك يجب النظر إلى التوثيق على أنه جزءٌ متكاملٌ من عملية التصميم و التكويد.
و لغة البرمجة الجيدة ستساعد المبرمج و تشجعه على كتابة شفرةٍ واضحةٍ مُوثَّقةٍ لنفسها، بل ربما حتى تطوير و عرض أسلوب كتابة مبهج. حيث أن مقروئية readability البرامج أهم بما لا يقاس من مكتوبيتها writability.
* تنقيح البرنامج:
قد تكون هذه العملية الطور الأكثر إتعاباً و تكلفةً و عدم توقعٍ فى تطوير البرنامج، و خاصة فى مرحلة تجميع البرامج الفرعية المكتوبة من قِبل العديد من المبرمجين على مدى فترةٍ طويلة، و الطريقة الأفضل لتقليل هذه المشاكل هى التصميم المبدئى الناجح للبرنامج، و التوثيق الجيد أثناء إنشاء الشفرة، و لكن و حتى أفضل البرامج تصميماً و توثيقاً سوف يحتوى على أخطاءٍ و عدم ملاءمةٍ يستطيع الحاسب نفسه المساعدة على تقليلها
و لغة البرمجة الجيدة سوف تقدم أقصى المساعدة على هذا، أولاً يجب أن تكون القواعد مصممةً بحيث تقلل إلى أقصى حدٍ ممكنٍ من أخطاء التكويد، أو على الأقل تضمن أن مثل هذه الأخطاء سيتم التعرف عليها من قِبل المصحح قبل حتى أن يبدأ البرنامج فى العمل.
هناك أخطاءٌ برمجيةٌ معينةٌ لا يمكن التحقق منها بهذه الطريقة و يجب أن يكون من السهل التعرف عليها أثناء العمل، و لا يمكن السماح بأن تكون ناتجةً من الاعتماد على الآلة أو على البناء و الذى لا يمكن توضيحه باللغة نفسها.
و هذه هى معياريةٌ أعطيها الاسم "الأمان safety". بالطبع فإن المصحح نفسه يجب أن يكون فى غاية الإعتمادية و الموثوقية بحيث يكون المبرمج واثقاً من أن أى تأثيرٍ غير متوقعٍ قد تم اكتشافه بواسطة برنامجه نفسه
و يجب أن يكون المصحح مضغوطاً و سريعاً، بحيث لا يكون هناك تأخيرٌ أو تكلفةٌ ذوى قيمةٍ فى تصحيح برنامجٍ ما و تشغيله للتجربة من جديد. و الشفرة الهدفية object code نفسها يجب أن تكون سريعةً و كفؤةً بحيث أن أوامر إضافية يمكن إدراجها حتى فى البرامج الضخمة و المستهلكة للوقت حتى يتم التحقق من أخطائها و عدم كفاءتها.
و الشرط الضرورى للوصول إلى أىٍ من هذه الأهداف هو البساطة القصوى فى تصميم اللغة، فبدون البساطة فإن مصمم اللغة نفسه لن يكون قادراً على تقييم عواقب اختياراته التصميمية، و بدون البساطة فإن كاتب المصحح لن يكون قادراً على جعله موثوقاً به، و لن يكون بإمكانه بطبيعة الحال إنتاج مصحح قوى و مضغوط، و لكن المستفيد الأكبر من بساطة اللغة هو المبرمج المستخدم لها، ففى كل النشاطات البشرية بدءاً من النجارة إلى رياضة القولف فإن الفائز الحقيقى الذى ينجح فى تحقيق أهدافه هو الشخص الذى يفهم الأدوات التى بين يديه جيداً و هو الأمر الذى ينطبق على المبرمجين كذلك.
فالمبرمج الذى يفهم لغته البرمجية تماماً بإمكانه أن يتولى مهاماً أكثر تعقيداً و أن يتمها بصورة أكثر سرعة و إرضاءاً بكثير عما لو لم يكن فهمه للغة البرمجة التى يستخدمها كاملة
و فى الحقيقة فإن حاجة المبرمج لفهم لغته كبيرةٌ للغاية، لدرجة أنه يكاد يكون من المستحيل إقناعه بالتغيير و استخدام لغةٍ أخرى غيرها، فمهما كانت مساوئ اللغة الحالية فقد اعتاد على التعايش معها و تفادى آثارها السيئة بالتنظيم و التوثيق، بل حتى الاستفادة من هذه المساوئ بطرقٍ يستحيل استخدامها مع اللغات الحديثة الخالية من تلك العيوب.
لذلك فإنه يبدو لازماً فى تصميم لغة برمجةٍ جديدةٍ قادرةٍ على جذب المبرمجين و دفعهم إلى استبدال لغاتهم القديمة المألوفة المعتادة باللغة الجديدة تحقيق البساطة فى أكبر الصور التى يمكن الوصول لها، بحيث يستطيع المبرمج أن يتعلم و يتذكر كل السمات التى تقدمها، و أن يستطيع اختيار الوسيلة الأكثر ملاءمةً لما يريد تحقيقه، و يستطيع كذلك فهم كل العواقب المترتبة على كل قرار. و من ثم يستطيع تركيز القدر الأكبر من جهده الإبداعى على فهم المشكلة المطلوب حلها و برامجه التى تحلها عوضاً عن التركيز على الأداة التى يستخدمها.
و شكلٌ قياسىٌ من البساطة هو البرمجة بلغة الآلة أو لغة التجميع لجهاز حاسب بسيط محدود، فجهاز كهذا لديه هيكلية نمطية للغاية، على سبيل المثال ذاكرةٌ مركزيةٌ تتكون من (2 أس م) من الكلمات مرقمةٌ تتابعياً من الصفر إلى أعلى، و بضعة مخزنات registers و واجهة قياسية تزامنية للتخاطب مع الأجهزة الطرفية و التحكم بها.  
أما الأوامر فهى مجموعة محدودة لكل منها شكل موحد، و تأثير كل أمر منها بسيط و يؤثر فى مخزن واحد و مكان واحد فى الذاكرة أو جهازاً طرفياً واحداً على الأكثر، و الأكثر أهمية أن هذا التأثير يمكن شرحه و فهمه بمعزل عن باقى الأوامر الأخرى، و نهايةُ فإن المبرمج يحصل على نتيجةٍ فورية تدله على أثر و كفاءة الشفرة التى كتبها، و المتعصبون للغات العالية المستوى غالباً ما ينبهرون بمدى تعقيد المشاكل التى يمكن معالجتها بمثل هذه الأدوات البسيطة.
فى الحواسيب الحديثة الأضخم و التى تحتوى على قائمة أوامر أساسية معقدة و أنظمة تشغيل أكثر تعقيداً فإنه من المرغوب فيه بشدة أن يكون تصميم لغة البرمجة عالية المستوى هادفاً للبساطة و التمثيل النمذجى الواضح لأفضل تصاميم العتاد، و لكن اللغات الأكثر استخداماً و التى تحقق هذه النظرة هى الفورتران، ليسب، و الجول60، و لغات قليلة تطورت منهن. و أخشى أن أغلب لغات البرمجة الأكثر حداثة تصبح أكثر تعقيداً، و من المزعج كثيراً قول مقترحيها أن تصميمات العتاد المستقبلية يجب أن تكون متمحورة حول البناء الممثل لهذه التعقيدات.

يُتبع.


ليست هناك تعليقات:

إرسال تعليق