وائل حسن
مهندس بيشارك كويس
عدد المساهمات : 104
تاريخ التسجيل : 18/05/2010
العمر : 36
الموقع : أرى بخارى بلادي وهي نائية -- وأستريح إلى ذكرى خراسانِ
Upload Photos : 
أهم مواضيعى : مدونتي الشخصية:
مدونة أفكار (مدونةٌ شخصيةٌ عن: السياسة، و المجتمع، و الأدب، و العلم.)
http://afkar-abo-eyas.blogspot.com
 |  موضوع: ترجمة لرسالة هامة فى علم تصميم لغات البرمجة  السبت 1 يناير - 9:45 | |
| بسم الله الرحمن الرحيم
هذه ترجمة لرسالة تعد من كلاسيكيات علم تصميم لغات البرمجة و هى رسالة (Goto statement considered harmeful) و التى كتبها د.ديجكسترا ثم أرسلها للنشر فى مجلة (Communications of the ACM, Vol. 11, No. 3, March 1968, pp. 147-148).
و قد حاولت جعل هذه الترجمة احترافية قدر الإمكان، و لكنى لا أدعى أن الأمر كان سهلاً لأن اللغة التى كان المؤلف يستخدمها كانت متقعرة جداً، لذا لم ألتزم بتعبيراته بالحرف بل حاولت قدر الإمكان التعبير عن المعنى بأبسط الكلمات بما لا يبعدنى عن الأصل تماماً، و لأن أمر كهذا ليس سهلاً فإنا أرجو من القارئ مسامحتى على أى تعبيرات لاقى فى فهمها النصب.
و إن كان القارئ الكريم قادراً على مطالعة الرسالة الأصلية التى توجد فى الرابط التالى ([ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذا الرابط] و تصحيح ترجمتى فله منى جزيل الشكر و أدعوه إلى إرسال الترجمة الجديدة إلى لتدارك خطأى و الاستفادة من جهده المشكور.
نص الترجمة:
لعديد من السنوات كنت معتاداً على ملاحظة أن كفاءة المبرمجين تعتبر دالة عكسية فى كثافة عبارة (Goto) فى البرامج التى ينتجونها، و فى توقيت أحدث اكتشفت لم لاستخدام Goto هذه التأثيرات الكارثية، و اقتنعت بأن جملة Goto يجب أن تمحى من لغات برمجة المستوى الأعلى (أى كل شئ فيما عدا شفرة الآلة المبسوطة). و فى ذلك الوقت لم أول اهتماماً كبيراً لهذا الاكتشاف، و أنا الآن أرسل قناعاتى للنشر لأنه فى المناقشات الأحدث و التى أثير فيها هذا الموضوع تم حثى على فعل ذلك.
و ملاحظتى الأولى أنه على الرغم من أن نشاط المبرمج ينتهى عندما يكمل إنشاء برنامج سليم، إلا أن العملية التى تتم تحت تحكم برنامجه هى الموضوع المهم فعلاً من نشاطه، و لأنها العملية التى يجب أن تحقق التأثير المطلوب فإنها يجب أن تحقق التوصيفات المطلوبة فى سلوكها المتغير (الديناميكى)،و على الرغم من ذلك فإنه ما إن ينتهى صنع البرنامج حتى يفوض أمر إنشاء العملية المقابلة للآلة.
ملاحظتى الثانية أن قوانا العقلية كيفت أكثر على التحكم فى العلاقات الثابتة و أن قدرتنا على التمثيل المرئى للعمليات المتنامية مع الزمن يتم تطويرها ببطء، و لهذا السبب فإنه يجب علينا (مادام المبرمجون الحكماء يعرفون حدودنا) بذل أقصى جهدنا لتقليل الفراغ التخيلى بين البرنامج الثابت و العملية المتغيرة لجعل التوافق بين البرنامج (الموجود فى حدود النص) و العملية (الموجودة فى حدود الزمن) تاماً قدر الإمكان.
لنركز الآن على كيفية تشخيصنا لتطور عملية (يمكنك أن تجعل طريقة تفكيرك فى هذا السؤال ملموسة أكثر: افترض أن عملية ما –و هى تعتبر تعاقباً لأحداث فى الزمن- تم إيقافها بعد حدث ما، فكم من البيانات يجب علينا إصلاحها حتى نعيد تنفيذ العملية حتى نفس النقطة؟) إذا كان نص البرنامج هو تتابع صرف لعبارات إسناد مثلاً (لغرض هذه المناقشة اعتبرت كمواصفات لأحداث فردية) فمن المناسب الإشارة فى نص البرنامج إلى نقطة بين موصفى حدثين متتاليين ( فى غياب جمل Goto فإننى أسمح لنفسى بالمغالطة النحوية فى الكلمات الثلاث الأخيرة فى الجملة السابقة: حيث إذا قرأناها "(موصفى حدثين) متعاقبين" فإننا نعنى متعاقبة فى النص، و لو قرأناها "موصفى (حدثين متعاقبين)" فإننا نعنى متعاقبة فى الزمن) و دعنا نسمى هذا المؤشر لمكان مناسب فى النص بـ"المميز النصى".
و عندما نضم جمل شرطية (if B then A)، و جمل أخرى (if B then A1 else A2) أو جمل اختيارية كما قدمها (C.A.R.Hoare):
(case[i] of(A1, A2, …, An))
أو تعبيرات شرطية كما قدمها (JMcCarthy):
(B1->E1,B2->E2, ….., Bn->En)
فإن الحقيقة تظل أن تقدم العملية يبقى ممثلاً بمميز نصى وحيد.
و حالما نضم إلى لغتنا الإجراءات فإنه يجب علينا الإعتراف أن مميز نصى واحد لا يبقى مناسباً، فى حالة كون المميز النصى يشير إلى مكان ما داخل جسم الإجراء فإن التقدم المتغير يمثل فقط عندما نحصل على استدعاء للإجراء الذى نعنيه، بضم الإجراءات يمكننا أن نمثل تقدم العملية عبر مميزات نصية متعاقبة، و طول هذه السلسلة يساوى العدد المتغير لنداءات الإجراء.
لنركز الآن على جمل التكرار مثل (while B repeat A) أو (repeat A while B). من الناحية المنطقية فإن هذه الجمل تعتبر زائدة، لأنه يمكننا التعبير عن التكرار بمساعدة الأجراءات العودية (recursive procedures). لأسباب تتعلق بالواقعية لا أرغب فى استثنائها: فمن ناحية فإن جمل التكرار يمكن بناؤها براحة بالغة بمعدات اليوم المحدودة، و من ناحية أخرى فإن أسلوب التفكير المعروف بالإستقراء يبقينا جاهزين جيداً للإحتفاظ بتركيزنا العقلى على العمليات المولدة بجمل التكرار. بضم الجمل التكرارية فإن المميزات النصية لا تظل كافية لوصف التقدم المتغير للعملية. يمكننا أن نقرن بكل دورة فى جملة تكرارية ما يمكننا تسميته (مميز متغير) يعد بعناد الرقم الترتيبى للدورة التكرارية الحالية. و بما أن الجمل التكرارية (مثل استدعاءات الإجراءات) يمكن أن تطبق بتفرع، فإننا نجد أن تقدم العملية يمكن دائماً تمثيله بمزيج منفرد من تعاقب من المميزات النصية و/أو المتغيرة.
النقطة الأساسية أن قيم هذه المميزات خارج نطاق تحكم المبرمج، و تولد (إما عن طريق متابع كتابة (write-up) برنامجه أو بالتطور المتغير للعملية) سواء أشاء أم لم يشأ.
لم نحتاج إلى مثل هذه الإحداثيات المستقلة؟ السبب أنه –و هذا يبدو موروثاً فى العمليات التعاقبية- يمكننا ترجمة أو إيجاد قيمة متغير فقط باعتبار تقدم العملية –فلو أردنا تحديد عدد (و لنقل ن) الأشخاص فى غرفة فارغة مبدئياً فيمكننا الوصول إلى هذا عن طريق زيادة (ن) بواحد كلما رأينا أحداً ما يدخل الغرفة. و فى اللحظة التى لاحظنا فيها أحدهم يدخل الغرفة و لكن لم نقم بعد بالزيادة المكافئة لـ(ن)، فإن قيمتها تساوى عدد الأشخاص فى الحجرة ناقص واحداً.
الاستخدام الجامح لعبارة Goto له عواقب فورية من حيث أنه يصبح فى غاية الصعوبة إيجاد مجموعة إحداثيات ذات معنى يمكننا من خلالها توصيف العملية. عادة فإن الناس يأخذون فى اعتبارهم كذلك قيم متغيرات مختارة بعناية، لكن هذا خارج عن نطاق التساؤل لأنه لا يمكن فهم معنى هذه القيم إلا بالنظر إلى التقدم! مع جملة Goto يمكن للمرء توصيف البرنامج بشكل فريد بعداد يحصى عدد الأحداث التى نفذت منذ بداية البرنامج. الصعوبة أنه فى إحداثى كهذا على الرغم من تفرده أنه ليس مفيداً على الإطلاق. فى نظام إحداثى كهذا يصبح من الأمور المعقدة للغاية تعريف كل تلك النقاط للتقدم حيث مثلاً (ن) تساوى عدد الأشخاص فى الغرفة ناقص واحد.
جملة Goto كما هو الوضع حالياً بدائية للغاية، و تعد بصورة كبيرة دعوة لتحويل البرنامج إلى فوضى. يمكن للواحد أن يحترم و يقدر الجمل المحسوب كبح جماح استخدامها. أنا لا أدعى أن الجمل المذكورة شاملة بمعنى أنها سوف تلبى كل الاحتياجات، لكن مهما كانت الجمل المقترحة (مثل جمل الاجهاض أو الاسقاط) فيجب أن تحقق متطلب وجود نظام إحداثيات منفصل عن المبرمج يمكن متابعته لوصف العملية بطريقة مساعدة و ذات معنى.
من الصعب إنهاء هذا بإقرار عادل. هل أحكم على من بهم تأثر فكرى. من الواضح أننى لم أتأثر بـ(peter landin) و (Christopher strachey). نهاية يجب أن أسجل (بما أننى أتذكر بصورة ممتازة) كيف أن (Heinz zemanek) فى اجتماع الـ(pre-ALGOL) فى بواكير 1959 فى كوبنهاجن عبر بوضوح شديد عن شكوكه فى أن جملة Goto سجب أن تعامل بشكل متساو مع جملة الإسناد. إلى مدى قريب لمت نفسى على عدم تمييز و تعقب عواقب ملاحظته.
الملاحظة حول النفور من جملة Goto بعيدة عن الحداثة. و أنا أتذكر قيامى بقراءة التوصية الصريحة بالحد من استخدام Goto تماماً كمخرج الطوارئ، و لكنى لم أكن قادراً على تعقبها؛ على ما يبدو فإنها كتبها (C.A.R.Hoare). فى [1.sec.3.2.1] قام (wirth) و (hoare) معاً بملاحظة فى نفس الاتجاه المشجع لبناء (case): "كالشرطية، هى تعكس الهيكل المتغير للبرنامج بشكل أكثر وضوحاً من جمل Goto و switch، و هى تحد من الحاجة إلى إنتاج عدد ضخم من العناوين فى البرنامج".
فى [2] يبدو أن (guiseppe jacopini) قد أثبت منطقياً زيادة جملة Goto غير الضرورية. و مع ذلك فتمرين ترجمة مخطط سريان آلياً إلى واحد عديم القفزات ليس منصوحاً به. إذاً فمخطط السريان الناتج لا يمكن توقع كونه واضح أكثر من الأصلى.
 | |
|
