المفاضلة بين لغات البرمجة 6

الألفة:

فى مجلة مجتمع لينوكس العربى و بالتحديد فى العدد رقم 7 الصادر فى رمضان 1430هـ الموافق أغسطس 2009م، كانت هناك قصةٌ قصيرةٌ من ضمن سلسلة قصصٍ قصيرةٍ تتحدث عن مغامرات مبرمجٍ لها الاسم (من مغامرات المحقق وميرت فونلى)، و كانت قصة ذلك العدد تسمى (سطرٌ بلغة بيرل) حيث فيها تَعَرض واحدٌ من المبرمجين المبتدئين لمشكلةٍ ما فطلب من المحقق وميرت فونلى مساعدته على حلها، و هنا فكر المبرمج الخبير بعض الشئ، و من ثم خرج ببرنامج بلغة perl يحل المسألة كلها، و الأهم أنه من سطر واحد !.
و الحقيقة أننى منذ أن قرأت تلك القصة و حتى الآن و أنا أضعها فى رأسى مثالاً للادعاء و السخافة؛ لأن القصة تحاول القول أن لغة perl قويةٌ و ذات أدواتٍ عالية القوة لدرجة أنه يمكنها أن تحل مشكلةً صعبةً بسطر برمجى واحد. و لو كان الأمر هكذا لما كان هناك ما يضر فى الأمر و لكنت أنا واحداً من أكثر الناس إسراعاً للبرمجة بperl، و لكن الأمر كان على خلاف ذلك تماماً، فنظرة واحدة إلى البرنامج ذى السطر الواحد و هو:

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

1. صعب القراءة و الفهم إلى درجةٍ كبيرةٍ على الخبير بلغة perl؛ لتراكب التعبيرات بما جعله بالفعل شبيهاً بأحجية السحرة و طلاسمهم، فما بالنا بالمبرمجين البسطاء الذين هم عامة المبرمجين. و الدليل على صعوبة فهم البرنامج أن شرحه الموجود فى القصة كان أكبر من البرنامج بمراحل، حيث وصل إلى ما يقارب الصفحتين بينما لم يأخذ البرنامج نفسه إلا سطراً واحداً !. 
2. صعب الصيانة و التطوير؛ لأن تعقيده سيأخذ من المتابع له وقتاً كبيراً لفهمه أولاً، ثم سيأخذ الوقت الأطول للتغيير فيه عند الرغبة فى التطوير، و لأنه معقدٌ فإن التغيير فيه مغامرةٌ محفوفةٌ بالمخاطر لن ألج أنا (عن نفسى) مثلها أبداً إلا مرغماًً.
   و لما كان من أول مواصفات البرامج الجيدة هو أن تكون واضحةً للقارئ بحيث تكون فى النهاية سهلة الفهم و سهلة التطوير قدر الإمكان: فإن البرنامج السابق يرسب فى معايير البرمجيات الجيدة بمنتهى الجدارة.

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

لكن المشكلة أن من يقتنع بهذا الرأى ارتكب ثلاثة أخطاء كبيرة هى:

1. اعتقد أن البرامج صغيرة الحجم هى بالضرورة سهلةٌ على التقبل و الاستيعاب، و قد قلنا أن هذا خطأ لأن الإسراف المرضى فى العلامات الغريبة على العقل البشرى فى حياته اليومية سيحيل البرامج بالنسبة له إلى تعويذة سحرية و طلاسم يقضى أمامها أغلب الوقت لفكها و فهم مراد الساحر (أقصد المبرمج ^_^ ) منها.
2. اعتقد أن الإنتاجية تتأثر أول ما تتأثر بسرعة الكتابة و هو تصور طفولى لا يخطر إلا ببال المبتدئين من المبرمجين الذين لا يرون من البرمجة إلا ما يرون فى مسائل المنهج الدراسى الذى يدرسونه فى الجامعة، أو مسائل الامتحانات بأفكارها البسيطة المكررة لا أكثر و لا أقل. فأصبحت كل البرمجة بالنسبة لهم معرفة المطلوب منهم و من ثم الجلوس أمام الحاسوب و البدء فى الكتابة بسرعة ليمكنهم الحل و المراجعة قبل انتهاء الوقت المحدد !.
3. أهمل وجود الأدوات البرمجية المساعدة الحالية التى تجعل بإمكانياتها القوية اللغات التى تسرف فى استخدام الرموز البسيطة و التى تسرف فى استخدام الكلمات الطويلة على قدم المساواة، و عن تجربة مع لغة الـ(#C) و بيئة التطوير المتكاملة الـ(Visual studio .NET) أقول أن أمر الكتابة السريعة كان بالنسبة لى أمراً منطقياً بدهياً لما توفره لى بيئة الـ(Visual studio .NET) من إمكانيات مساعدة و اقتراحات فى كل خطوة أخطوها، و هو ما كان يجعلنى أركز جل تفكيرى بل كله على الأفكار و الخوارزمات التى سأستخدمها فى البرنامج ليؤدى مهمته بكفاءة و قوة.
   بل إن الأمر فاق هذا إلى المساعدة فى إنتاج الكود للأجزاء التى تحتاج إلى وقت كبير من المبرمج لعملها بينما يمكن للحاسوب مساعدة المبرمج على القيام بها بكفاءة و سرعة شديدين، مثل مصممات النوافذ forms designers التى توشك بيئات البرمجة المتكاملة جميعها على الاتفاق على ضمها فيها؛ لما تزيحه من عبء وصف شكل النوافذ باستخدام الكود مباشرة، بينما باستخدام مصممات النوافذ فإن كل ما علي المبرمج هو أن يسحب المكون الذى يريده و يضعه فى المكان الذى يشاء ببساطة و سلاسة شديدن.
   و إنى ألاحظ أن إهمال تلك الإمكانيات يوشك أن يكون آفةً فى جمعٍ كبيرٍ من المبرمجين المخضرمين، بما يوحى بأنهم يتصورون أن استخدام مثل تلك الإمكانيات سيقلل من كفاءتهم؛ لأنها أدواتٌ للمبرمجين المبتدئين الذين لا يمكنهم الاعتماد على أنفسهم كل الاعتماد فى بناء و كتابة أكوادهم. و هى النظرة التى أضمها بحماسٍ إلى قائمة الأمور التى تثير جنونى فى عالم البرمجة، فهذه الأدوات معلومٌ من النظر و الخبرة بالضرورة أنها ذات أثرٍ بالغ القوة فى العمل و الإنتاج البرمجى فى المشاريع الكبيرة و تؤدى إلى طفراتٍ إنتاجيةٍ رائعة، مما يعنى أنه من العقل السليم إستخدامها و الاستفادة منها بأقصى حد ممكن. و بالتالى يكون التصور السابق أسخف من أن يخطر ببال أحد من الأصل فما بالك باعتناقه و تطبيقه فى مجال تصميم لغات البرمجة و من ثم طرح نتائجه للتداول بين أيدى الجيل الجديد من المبرمجين الذين عليهم أن يتحملوا نزوات الجيل السابق و عناده !.

عدم الخلط بين الألفة و الإطناب المرضى:

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

1. قاعدة ضم المألوف من العلامات، فلا تُضم علامةٌ أو رمزٌ إلا إذا كانا مما ألفه المبرمجون فى تعاملاتهم مع النصوص العادية، مثل الفاصلة ، و النقطة . و القوسين ()، والتقليل قدر الاستطاعة من الرموز و العلامات التى يقل التعامل بها أو ينعدم فى حياة المبرمج العادية.
2. استخدام تلك الرموز و العلامات المألوفة فى نفس الوظيفة التى كانت تستخدم فيها فى اللغة العادية، مثل استخدام النقطة . فى نهاية الأوامر البرمجية و استخدام النقطتين القائمتين : عند بدء تعبيرٍ أو تركيبٍ من الجمل (كما تفعل لغة الـpython).
3. استخدام الكلمات بدلاً من الرموز فى الأماكن المناسبة لهذه الرموز، فى الأحيان التى تكون فيها للكلمات القدرة على القيام بوظائف زائدة لا يمكن للعلامات القيام بها، فمثلاً فى لغات برمجة كثيرة استُخدِمت الكلمات المفتاحية AND OR NOT للاستخدامات  المنطقية فى اللغة، على الرغم من أنه كان بالإمكان استخدام العلامات المشهورة فى لغات البرمجة من عائلة الـC مثل & && |  || ! فى ذلك و كانت ستؤدى دور الكلمات المحجوزة؛ إلا أن هناك وظيفةً لا يمكن لهذه العلامات أداؤها: و هى تحويل النص البرمجى إلى لغةٍ قريبةٍ من اللغة العادية الحديثية؛ مما يزيد من مقروئية الكود بما لا يوصف بالنسبة للمبتدئين و الأطفال الصغار الذين ستستخدم اللغة فى تعليمهم البرمجة.