ما هي أفضل لغة برمجة ؟

علي موقع Arabia I/O كان هناك تساؤلٌ يقول فيه صاحبه: "ما هي أفضل لغة لبرمجة تطبيقات سطح المكتب ؟"، فكتبتُ إجابةً مُختصَرةً علي سؤاله تصلح للإجابة عن كل الأسئلة التي من عينة: "ما هي أفضل لغة برمجة لفعل كذا و كذا ؟"، أو حتي للإجابة علي السؤال الأعم و الأشمل: "ما هي أفضل لغة برمجة ؟".

و كان ردي كما يلي (مع تصرُّف بسيط للغاية):

أيهما أنسب للمبتدئين: #C أم java ؟

سألني أحد الإخوة الأفاضل السؤال التالي (ببعض التصرف):

السلام عليكم، 

هناك شئٌ يُحيرني بشدة: فقد اشتركتُ في دورة microsoft الخاصة بالمدارس الثانوية، و هذه الدورة في لغة #C و بعض تقنيات الـNET. الخاصة بـmicrosoft، و لا أعرف هل أُكمِل هذه الدورة أم لا؛ أقصد هل أتعلَّم لغةً مغلقة المصدر من microsoft أم أتحول الي لغةٍ مفتوحة المصدر كـjava.

و كان ردي المُختصَر عليه كما يلي (ببعض التصرف):

البرمجة الكائنية بدون وراثةٍ متعددة

البرمجة الكائنية oop بدون وراثةٍ متعددة multiple inheritance تماماً كزوجةٍ مُتدينةٍ جميلةٍ و لكنها لا تُنجب؛ بالتأكيد وجودها أفضل بكثيرٍ جداً من عدم وجودها، و لكن لا يُمكنك أن تُنكر أنه لا أحد يرغب في البقاء بلا أبناء.

خاطرةٌ عن الـ#C

خاطرةٌ عن الـ#C

لغة الـ#C لغةٌ رائعةٌ و فاتنة بالفعل، و قد بدأت مشواري البرمجي الحقيقي معها و مع بيئة الفيجوال ستوديو visual studio، لكن أكبر المشاكل التي تواجه الـ#C أن الجميع يعتبرها واجهةً فقط لتقنية الـ.Net (و قد كنتُ منهم لفترةٍ طويلة)، لذلك فإن كل من يبرمج بها يستخدمها و هو يؤمن أنه ما دام يستخدمها فلن يستطيع البرمجة إلا للويندوز فقط، بل و سيظل مرتبطاً أبد الدهر ببيئة الفيجوال ستوديو و مكتبة الـ.NET.


و من أسباب ذلك أنه علي الرغم من قوة الـ#C إلا أن نقلها إلي منصات متعددة من الصعب أن يكون كنقل الـjava مثلاً: فالجافا مصممة من الأساس لكي تتنقل برامجها بحرية عبر المنصات المختلفة، و هذا مراعي في مكتبتها القياسية الـJDK، بينما مكتبة الـ.Net بها أجزاء من الصعب جداً نقلها أو مُحاكاتها بالكامل (مثل جزء الواجهة الرسومية GUI الضخم) و بالتالي لا يكون أمام المبرمج الذي اعتمد علي أكواد مكتبة الـ.Net غير المتنقلة إلا أن يبقي علي منصة الويندوز فقط، و للأسف فمعظم مبرمجي الـ#C قاموا بالفعل بعمل الكثير من البرامج الضخمة منذ فترة بطريقةٍ شديدة الارتباط بنظام التشغيل ويندوز و صار من المستحيل عملياً تحويل هذه البرمجيات للعمل علي منصاتٍ أخري.

و مما يزيد الطين بلةً أن هناك براءات اختراع مملوكة لمايكروسوفت يتم استخدامها (بالطبع) داخل مشروع مونو mono (الذي يعتبر البديل مفتوح المصدر لمنتجات مايكروسوفت التي تربط الـ#C بها، و يعطيها القوة التي تضاهي قوة الجافا)، و بالتالي يضع هذا المبرمجين تحت طائلة مايكروسوفت التي لا تري إلا مصالحها (بطبيعة الحال).

ترجمة Why Pascal is Not My Favorite Programming Language

بنك الأفكار الخاص:

ترجمة الورقة العلمية

Why Pascal is Not My Favorite Programming Language

هناك ورقةٌ علميةٌ تُسمي Why Pascal is Not My Favorite Programming Language كتبها  البروفيسور الشهير (Brian Kernighan)، و تحتوي علي مجموعةٍ من الانتقادات المنطقية لتصميم لغة الـpascal بما يجعل المؤلف لا يستخدمها كلغةٍ أولي للبرمجة.

و قد قرأتُها منذ فترة فأعجبني أسلوبها و ما تحتويه من انتقاداتٍ عقلانية، و من إعجابي بها فكرت في ترجمتها و لكني (كالعادة) لم أتمكن نظراً للانشغال من فعل هذا، و لذلك أقترح علي من يستطيع فعل ذلك أن يفعل مشكوراً.

و هناك مجموعةٌ أخري من الأوراق العلمية و المقالات و التدوينات المشابهة أنقل منها ما يلي: 

• Why Java is Not My Favorite Programming Language
•  Why C Is Not My Favourite Programming Language

• Why C++ is not my favorite programming language

• Why C# Is Not My Favorite Programming Language

• Why Python is not my favorite language 

  و لو كان بالإمكان ترجمتها جميعاً لكان في هذا استفادةٌ قصوي.  

   

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

نقد نموذج لغة الـPython للأصناف classes و الدوال functions.

على الرغم من أن لغة الـPython تمثل بالنسبة لى لغةً من أفضل اللغات (بل أفضلها علي الإطلاق) من حيث شكل البرنامج المكتوب بها، إلا أنها تحتوى على قراراتٍ تصميميةٍ أجد أنه من الواجب الرد عليها؛ لأنها تمثل قراراتٍ سيئةٍ بما فيه الكفاية لمن كانت له قناعاتٌ تصميميةٌ كقناعاتى.

و من أوضح هذه القرارات الغريبة هو نظرة اللغة إلى الأصناف classes و الدوال functions؛ حيث أن هذه النظرة الغريبة ترى فى الأصناف ما يشبه الدوال، و ترى فى الدوال ما يشبه الأصناف !، فنرى أن الأصناف فى الـPython عبارةٌ عن حاويةٍ لمجموعةٍ من الأوامر المتتابعة التى تُنفذ بشكلٍ متتالٍ واحداً تلو الآخر، و أن المكونات الداخلية للأصناف مثل الدوال و المُشَيِّدَات constructors و خلافها ما هى إلا عباراتٌ تنفيذيةٌ بدورها، و يعنى هذا أنه يمكننى أن أقوم بكتابة عبارات اسناد قيمٍ و استدعاءاتٍ لإجراءاتٍ ما داخل صلب الصنف و ليس داخل مشيداته أو دواله، و مثالٌ على هذا (كودٌ للتوضيح فقط):

حيث يتم فى البداية تعريف دالة تسمى func1، ثم تم استخدامها لإسناد قيمةٍ إلى متغيرٍ يسمى A، ثم تلى ذلك تعريف دالةٍ أخرى تسمى func2.

و تكتمل الصورة حينما نعلم أنه يمكننا فى الـPython تعريف دالةٍ داخل دالةٍ أخرى، و استخدامها عن طريق كتابة اسم الدالة الحاوية لها و إتباعها بقوسى دالةٍ نكتب فيهما المعاملات الممررة للدالة الداخلية. و تُعْرف الدوال الحاوية بالاسم closures.

و مثالٌ على هذا:

و بالنظر إلى صفات الأصناف و الدوال فى الـPython سنرى أن لكليهما الصفات التالية:

1. اسم الدالة  و اسم أى كائنٍ من الصنف هما مؤشران يشيران للدالة و الكائن، أى أنه يمكن تغيير الدالة أو الكائن الذى يشير إليه الاسم. مثل البرنامج التالي:
   

حيث أنه فى الأمر قبل الأخير جعلنا الاسم (log) يشير إلى كود الدالة (exp)، بينما جعلنا الاسم (exp) يشير إلى كود الدالة (log). و النتيجة التالية لاستدعاء الاسمين قبل التبديل و بعده تدل على أثر التبديل و نجاحه:

2. كلاهما يمثل كتلةً من الأوامر التى تُنَفَّذ بشكلٍ تتابعى.
3. كلاهما له القدرة على احتواء تعريفاتٍ لأصنافٍ داخله، أى أنه يمكن للدالة أن تحتوى على تعريف صنفٍ من الأصناف داخلها لتعود و تستخدمه بصورةٍ طَبْعيةٍ كما يحدث فى حالة الأصناف المتفرعة فى باقى لغات البرمجة.
   

4. كلاهما له القدرة على احتواء دوالٍ داخليةٍ يتم استدعاؤها عند الحاجة إليها عن طريق اسم المكون الحاوى لها. مع فارقٍ: أن الدوال تحتوى داخلها دالةً داخليةً واحدةً فقط بينما يمكن للصنف تعديد الدوال، و كذلك فإن الدوال التى فى الصنف يتم استدعاؤها باسمها بينما تُستدعى الدوال الداخلية باسم المتغير الذى استدعى دالتها الحاوية. 
   مثال1:
   
   مثال2:
   

و من الصفات السابقة نرى أن هناك تقريبٌ لا معنى له بين صفات مكونين برمجيين يجب إبقاء كل منهما منفصلاً عن الآخر، و عدم إثارة البلبلة التى لا داعى لها بجعل كل منهما يحمل شيئاً من صفات الآخر بشكل لا يحقق أى أهدافٍ فى حقيقة الأمر.

فالدوال هى فى الأصل كتلةٌ من الأوامر التى تُنَفَّذ بشكلٍ تتابعىٍ بحيث يتم استدعاؤها عند الحاجة إليها فيوفر وجودها تكرار الأكواد و مساحة البرنامج النصية و يزيد القدرة على اكتشاف الأخطاء و السرعة فى ذلك و غيرها من العوامل الأخرى، أما الأصناف ففى الأصل لم تنشأ إلا لتكون حاويةً تجمع بين مجموعةٍ من المتغيرات و مجموعةٍ من الدوال التى تعمل عليها، و عن طريق الاستنساخ instantiating من الأصل يتم الاستفادة من كود الصنف أقوى استفادة، عن طريق عزل المحتويات الداخلية للكائنات عن المبرمج النهائى و غيرها من الفوائد، فما معنى وجود دوالٍ تحوى دوالاً أخرى داخلها ؟! أو صنفٍ يحوى أوامر تُنفذ بشكلٍ متسلسلٍ و كأنها كتلةُ أوامرٍ فى صلب دالةٍ من الدوال !

و ما الفائدة التى ستعود علينا من ذلك المزج و التقريب الغريبين؟، و أى ضررٍ سيعود علينا عند التفريق بينهما كما تفعل بقية اللغات؟.

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

البساطة و الاستقرار:

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

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

أما الخيار الأول فيناسب من بدأ مشواره فى تعلم البرمجة منذ أن كان صغيراً و بالتالى كان أمامه الفترة الكافية للتعلم قبل مواجهة سوق العمل الذى يضغط الأوقات و الأعصاب إلى أقصى الحدود، و لا يمكن أن يتناسب مع ظروف شخص مثل كاتب هذه الأسطر على سبيل المثال؛ فالعمل يدفع من هم مثله على القراءة و التعلم و الاحتراف فى مجالات أخرى غير لغة البرمجة المعنية، بل وربما يدفع سوق العمل على إتقان لغةٍ أخرى غير اللغة التى يهتم بها المبرمج و يجد أنها تناسب نمط تفكيره، و أنا خير مثالٍ على ذلك فأنا أستخدم فى البرمجة لغة الـ(++C) التى أمقتها بعنف شديد و أنا مطالب باحترافها و التمكن منها حتى أستطيع العمل بها بحرفية فى مجال معالجة الصور الرقمية، و لأننى أحب الـ(java) و الـ(#C) إلا أننى لا أستطيع بالطبع مجاراة آخر التحديثات و التغييرات التى تتم لهما؛ لأننى لا أستطيع أن أقضى وقتى كله فى تعلم الـ(++C) من ناحية و تعلم الجديد فى الـ(#C) من ناحيةٍ أخرى على حين أن هناك علوم أخرى يجب أن أحصلها حتى أكون مبرمجاً بحق، مثل هندسة البرمجيات و الخوارزمات و غيرها و التى لم أتعلمها من قبل لأننى احترفت مجال البرمجة و الحوسبة عموماً منذ فترة لا تزيد على الثلاث سنوات بحال من الأحوال !.
و هناك من يناسبه خيار المتابعة المستمرة للغة غير البادئ فى التعلم منذ الصغر، و هو من بدأ مع اللغة منذ بداياتها الأولى و أول إصداراتها، و بالتالى كانت لديه الفرصة الرائعة للمتابعة المستمرة كأفضل ما يكون، و هؤلاء ليسوا بالقليلين بل هم فى كل مكان حولنا و يمكن أن نراهم كثيراً حينما يأتى الأمر على لغة مثل الـ(#C) التى أصبحت البرمجة بها موضة من موضات المبرمجين اليوم، و بالتالى انهمك الجميع فى دراستها و هى بعد فى المهد و بالمتابعة تعلموا الجديد أولاً بأول.أما الخيار الثانى القائل بالتمكن من الجزء الأكبر و الأهم من اللغة فقط لكى يتبقى الوقت اللازم لتعلم باقى العلوم البرمجية فهو أمر فيه جدال يطول، و ذلك لأنه و إن كان مع أصحابه الحق فى القول بأهمية تعلم باقى العلوم البرمجية غير لغة البرمجة ذاتها فإنهم لا ينتبهون إلى نقطة أخرى فى غاية الأهمية و هى أنهم بتطبيقهم خيار التجزيئ للغة لن يتمكنوا من فهم الأكواد البرمجية التى يكتبها غيرهم ممن يبرمجون بنفس اللغة البرمجية و لكنهم يستخدمون مكونات لم يتعلموها هم. ولن يكون مثل هذا الموقف قليل الحوث بل سيحدث كثيراً جداً كلما زادت كمية الأكواد التى يطلع عليها المبرمجون، و هى كثيرة العدد جداً فى هذه الأيام بفضل عالم المصادر المفتوحة الذى كشر عن أنيابه بقوة و أصبحت قوته الضاربة غير قابلة للجدال فى كل مجال من مجالات البرمجة.

و هذا يعنى أن أمثال هؤلاء المبرمجين سيجبرون إن عاجلاً أو آجلاً على التعرف على معظم المكونات التى تركوها خلفهم فى اللغة إن لم تكن كلها، و بالتالى يكون من الأفضل لهم أن يفعلوا ذلك من البداية فى ذروة تعلم اللغة ما دام الأمر لا مفر منه فى النهاية و من ثم يكون ما نخافه من الإهمال لباقى عناصر العلم البرمجى أو حتى عدم التنبه الكامل لها حتى الانتهاء من تعلم لغة البرمجة التى هى الأداة التى يستخدمها المبرمج فى عمله ليس إلا.و هكذا نرى بأم أعيننا الوقت الكبير يضيع فى تعلم ما كان يجب أن يكون هو الأمر الأبسط فى العملية التعليمية كلها بينما الأمور الأهم تترك لما بعد، و بعد كل ذلك تأتى مرحلة التطبيق على المجالات التى سوف تستخدم فيها كل تلك الخبرات البرمجية مثل برمجة الشبكات أو برمجة تطبيقات معالجة الصور الرقمية. و ليس لنا بعد كل ذلك الوقت المهدر التعجب من كره الكثيرين من التعمق فى دراسات البرمجيات النظرية مثل هندسة البرمجيات و الخوارزمات و رؤيتهم لها على أنها غير ذات جدوى بينما ينظرون إلى تعلم لغة برمجة على أنه هو كل شئ فى عالم البرمجة مادام يأخذ وقتاً كبيراً و يأتى دائماً فى المقدمة لكل شئ و يركز عليه الجميع أغلب اهتمامهم.
و هكذا نرى أيضاً كل عام أكواماً من الكتب التعليمية التى لم تعد لها أى فائدة رغم الجهد الذى بذله مؤلفوها فيها لأنها أصبحت تتحدث عن ماضى اللغة لا عن حاضرها، و رغم المال الذى دفعه فيها مشتروها الراغبين فى تعلم اللغة، و بالتدريج سيكون على المتعلم التفرقة بين الكتب القديمة و الحديثة بمنتهى الحرص حتى لا يقع فى معلومات مغلوطة عن اللغة. و مثل هذا الموقف نراه فى الـ(#C) التى كنا منذ فترة ليست بالبعيدة نقول عنها أنها لغة ذات أنواع ثابتة أو (statically typed) و من ثم فاجأتنا الإصدارات الجديدة أنها صارت أيضاً ذات أنواع متغيرة أو (dynamically typed). و هذا الحال بالطبع لا يرضينى ولا أقتنع بجدواه على الإطلاق، بل أقول أن كل هذا عبث سخيف ليس له أن يستمر و لا يحق لأحد أن يفرضه على الآخرين بأى داع من الدواعى، فمنتجوا لغات البرمجة الشهيرة الذين يزيدون فى قواعدها يوماً بعد يوم مثل (microsoft) و لغتها الـ(#C) يجب عليهم أن يتوقفوا حالاً عن هذا و إلا كان لزاماً على معاشر المبرمجين مقاطعة أمثال تلك اللغات تماماً فيصير أمثال أولئك المنتجين مثالاً لكل من يتحدى إرادة مجتمع المبرمجين و يجبرهم على اللهاث وراءه فى عملية تعليمية تعذيبية الطابع لا نهاية لها.

الأسباب التى تجعل المنتجين للغات البرمجة يفعلون هذا:

إذا ما فكرنا فى هذه المسألة بعمق لوجدنا أن الأسباب التى تجعل منتجي لغات البرمجة يزيدون من قواعد لغاتهم أو "يطورونها" تختلف حسب المنهجية التى ينظر بها ذلك المنتج إلى المجتمع البرمجى نفسه، و لنا فى لغة الـ(#C) خير مثال على ذلك، فمنتج لغة الـ(#C) هو (microsoft) التى لا تسعى (مثلها مثل كل الشركات التجارية) إلا وراء الكسب المادى مهما روجت دعايتها إلى كونها تسعى خلف التقدم العلمى. المهم أن (microsoft) يهمها للحصول على المكسب المادى من وراء لغة الـ(#C) أن يكون لها أكبر عدد من المستخدمين من المبرمجين مختلفى الطباع و الأهواء، لذا نرى أن الـ(#C) تحوى داخلها من الصفات ما يجعلها تجميعةً من مختلف أنواع التفكير البرمجية و يزداد هذا الأمر وضوحاً يوماً بعد يوم بالزيادات التى تضعها (microsoft) فيها بدعوى التطوير و التحديث.و قد ضربنا لذلك مثالاً بالـ(statically typing) و الـ(dynamically typing)، و نضرب له مثالاً آخر هو البرمجة الآمنة و البرمجة غير الآمنة أو الـ(safe programming) و الـ(unsafe programming)، و التى تمكن مبرمجى الـ(#C) من استخدام المؤشرات التى تعودوا عليها فى الـ(++C) إذا ما أرادوا استخدامها فى اللغة الجديدة، وهو الأمر الذى قد يسعد بعض من مبرمجى الـ(++C) و يقنعهم بالفعل بالانتقال إلى البرمجة بالـ(#C) و لكنه فى نفس الوقت يجعل الـ(#C) بالنسبة لمن هم مثلى أرضاً مشكوك فى كونها حقل ألغام.

عدم الخلط بين الاستقرار و الجمود:

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

و فى النهاية فإننى ألخص موقفى فى تلك النقطة الجوهرية من مبحث تصميم لغات البرمجة فى البنود التالية:

1. يجب أن تكون اللغة مصممةً على نارٍ هادئة؛ حتى لا نحتاج إلى التغيير الكثير فيها فيما بعد.
2. يجب أن تضم اللغة المكونات التى لا يمكن الاستغناء عنها و لا يمكن أن تحل محلها مكوناتٌ أخرى تم ضمها بالفعل للغة، أى أن الأولوية فى الضم للغة ستكون للمكونات التى لا غناء عنها و التى تغنى عن غيرها بينما يتم رفض ذلك الغير.
3. إذا ما كانت هناك تطوراتٌ فى البرمجة تجعل مكوناً جديداً جديراً بالضم إلى اللغة، فيجب أن يتم حسم مسألة كون هذا المكون الجديد لا يهدم مكوناتٍ أخرى أم لا، فإن كان لا يفعل و كان سهل التأقلم مع المكونات الموجودة بالفعل فيمكن ضمه إلى اللغة بعد فترة استقرارٍ جيدةٍ لا تقل فى رأيى عن سنةٍ كاملة عن التغيير الضرورى السابق مباشرة.
4. على مدى حياة اللغة يجب أن يكون هناك حدٌ يتم بعده رفض ضم أى مكونٍ للغة مهما كانت أهميته و هو ما يمكن أن نسميه حد التخمة، و أقدر أنا هذا الحد بحجم الكتاب الذى يشرح نحو اللغة على نحو محترف مختصر، فلو زاد حجم الكتاب على الخمسين صفحةً من ورق الـ(A4) المكتوب بخط وسط لا صغيرٍ و لا كبيرٍ يمكننى أن اعتبر هذه اللغة قد بلغت حد التخمة و يجب التقليل من كل ذلك الكم من القواعد التى لا داعى لها.و رغم أن الأمر يخضع للتقدير الشخصى بالفعل إلى حد كبير إلا أنه بالحس الشخصى يمكن التوصل إلى نتائج شديدة الشبه عند النظر إلى لغات البرمجة المختلفة من عينى أشخاص مختلفين استناداً إلى المعيار السابق للتخمة، أى أنه رغم كون المعيار غير فائق التحديد: إلا أنه عملياً سيكون ذا قوة توحيدٍ قياسيةٍ كبيرةٍ بين المبرمجين و الناقدين للغات البرمجة.
5. عندما تبلغ اللغة حد التخمة و يكون هناك مكوناتٌ لابد من وجودها فى لغة البرمجة الجيدة لتلائم الأفكار الجديدة فى العمل البرمجى، أو عندما نحتاج إلى تغيير أحد الأفكار الرئيسة فى لغة البرمجة، أو حتى تكون هناك مكوناتٌ عفى عليها الزمن و يجب التخلص منها، فيجب علينا أن نفكر فى إنتاج لغة برمجةٍ جديدةٍ تستلهم الجيد الذى فى اللغة القديمة و تضع الجديد المرغوب فى ضمه محل القديم المرغوب فى تركه، و هذا يجعل تصميمَ اللغات أسهل، و تطورَها أكثر قابليةً للفهم، كما أنه يعطى للراغبين فى البرمجة باللغة على نفس الشكل القديم لها الفرصة لفعل ذلك، و لا يجبرهم على التغيير للشكل الجديد مادام الشكل الجديد قد صِيغ على شكل لغةٍ برمجيةٍ أخرى مختلفة لهم كل الحق فى التقرير لأنفسهم إن كانوا سيتعلمونها و يستخدمونها أم لا.

المفاضلة بين لغات البرمجة 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 مثل & && |  || ! فى ذلك و كانت ستؤدى دور الكلمات المحجوزة؛ إلا أن هناك وظيفةً لا يمكن لهذه العلامات أداؤها: و هى تحويل النص البرمجى إلى لغةٍ قريبةٍ من اللغة العادية الحديثية؛ مما يزيد من مقروئية الكود بما لا يوصف بالنسبة للمبتدئين و الأطفال الصغار الذين ستستخدم اللغة فى تعليمهم البرمجة.

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

الأمن:

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

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

و يمكننا أن نضع الأمن اللغوى بتوسع و شمول فى ثلاث عناصر هى:

1. وجود مكونات تسهل العمليات كثيرة الاستخدام و التى قد يخطئ فيها المستخدم إذا ما كانت تتطلب كثيراً من الجهد نظراً لكثرة تكرارها، و بالتالى فإن تسهيل العملية على المبرمج بتوفير المكونات الجاهزة فى لغة البرمجة التى تقوم بالعملية كاملة بالنيابة عنه لا يخدم فقط الناحية الإنتاجية فى العملية البرمجية بل يخدم بشكل أساسى عملية تفادى الأخطاء البرمجية.
2. استبعاد المكونات أو التعبيرات البرمجية التى تسبب البلبة و الارتباك و من ثم الأخطاء البرمجية بكل أنواعها من أخطاء نحوية و أخطاء زمن تشغيل و أغلاط منطقية، و مهما جادل المجادلون فى فائدة مثل تلك المكونات أو التعبيرات فيجب أن يوقنوا أنه يمكن الاستغناء عنها، لأنها نتاج فكر بشرى وجدها حلاً لما واجهه من مشاكل و ليست تنزيلاً من السماء يجب قبوله كما هو، و يمكن بالقليل من التفكير أو حتى بالكثير منه ابتكار مكوناتٍ أو أساليب جديدة تغنى عن تلك المكونات و التعبيرات المربكة.
3. وجود المكونات التى مهمتها الأساسية معالجة الأخطاء الناتجة مثل معالجات الاستثناءات exceptions handlers فى الـ(java) و الـ(#C) و كثير من اللغات الأخرى، و هذه المكونات تجعل عملية البرمجة متعةً حقيقية؛ لأنها تقرب الأمر من التفكير العالى للبشر إلى أقصى الحدود، فبدلاً من البحث اليدوى عن كل الاستثناءات المتوقع حدوثها و كتابة الأحداث اللازمة لمعالجتها أصبح لدينا تلك الصياغة التى يمكننا بها ببساطةٍ تحديد الإجراء المناسب لكل نوعٍ من أنواع الاستثناءات.

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

الشمول:

حينما تريد برمجة تطبيق نظامى يحتاج إلى الأداء الأفضل فعليك بالبرمجة بلغة الـ(C)، و حينما تريد برنامجاً يتعامل مع النوافذ و الواجهات المرئية فعليك بالـjava أو الـ(visual basic) أو الـ(C#)، أما التعامل مع قواعد البيانات فأمر هو أسهل مع الـjava و الـ(C#).. أما الدلفى فسلتجأ إليها حينما تريد أن... حيث أن لغة.... ليست قوية فى هذا المجال و كذا فإن لغتى ....و.... معقدتان بما يكفى لتحيلا حياتك إلى جحيم فى هذه المنطقة من المجال البرمجى. و.... حيث أن....

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

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

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

1. أنظمة الذكاء الاصطناعى التى تحتاج إلى استخدام القواعد المنطقية فى عملها، فمثل هذه الأنظمة لها مستوى عال للغاية من التجريد و البعد عن الآلات و طرق عملها، و بالتالى فإن لغة البرمجة التى تستخدم فيها لابد أن تكون بعيدة كل البعد عن التعقيد بل يجب أن تكون سهلة متدفقة غزيرة الإنتاجية و تستخدم المنطق، مثل لغات الـ(prolog) و الـ(logo) و غيرها من نوعية تلك اللغات المنطقية العالية للغاية فى المستوى. و لا يمكن مع مجالات كهذه أن نستخدم لغات منخفضة المستوى مثل الـ(C)، فكل ما سنجنيه حينها هو الإحباط و اليأس فى يقظة و الكوابيس و بلل الفراش مناماً.
2. أنظمة قواعد البيانات و التعامل معها، حيث نجد أنه يتم استخدام نوع خاص من اللغات البرمجية مهما اختلف شكله فهو متشابه و يسمى لغات (الاستعلام) للتعامل معها، مثل لغات الـ(SQL) التى من بينها الـ(SQL) القياسى و (oracle SQL) و (MS SQL)و غيرها، و التقنية الجديدة التى ابتكروها فى (microsoft) و هى تقنية الـ(LINQ) التى يستهدف أن تستخدم للتعامل مع كل أنواع مصادر البيانات و ليس مجرد قواعد البيانات فقط، أى أنه لم يتم استخدام لغات البرمجة العام العادية مثل الـ(java) و الـ(C#) على الرغم من أنه يمكننا صنع مكتبات لتلك اللغات تقوم بعمل الصياغات المختلفة للغات الاستعلام و إن كان ذلك صعباً بعض الشئ، لكن الأمر ليس فى إمكانية فعل ذلك من عدمه إنما يكمن سر الموضوع فى طبيعة التعامل مع قواعد البيانات عام. و لذلك نجد أنهم لم يقوموا بدمج إمكانيات تلك اللغات فى اللغات البرمجية العام مباشرة بل قاموا بإعطائها القدرة على استخدام أوامر لغات الاستعلام الصريحة و إن كان هناك بعض التغليف اللازم لقبول تلك العبارات فى بيئة لغة البرمجة العادية، و المثال التالى بلغة الـ(C#) يرينا مثل ذلك التغليف عملياً:
   
   على الرغم من أنه كان من الممكن الاستغناء عن كل ذلك بصنع إجراء تأخذ كمعاملات لها اسماء الحقول التى سيتم اختيارها للتعامل معها و اسم الجدول الذى يحويها و الشرط الذى يجب أن ينطبق على القيم المختارة، و هذا كما قلنا صعب للغاية و لكن الأمر ليس فى الصعوبة فقط إنما فى الاختلاف الشديد عن البرمجة العادية و هو الأمر الذى تعزى إليه هذه الصعوبة نفسها و تعد جانباً من جوانب تجلياته.
   

3. تطبيقات الواجهات المرئية التى هى من أسهل ما يمكن عند التعامل معها باستخدام لغات البرمجة الكائنية و ألعن ما يمكن لو تم التعامل معها بلغات البرمجة الوظائفية، حيث فى اللغات الكائنية يمكننى ببساطة أن أقول (بمفردات اللغة البرمجية طبعاً) أننى أريد كائناً من نوع النافذة، و هذا الكائن يحوى زر له القيم الفلانية و صندوق نص له القيم العلانية و...و... إلى آخره، أى أن الأمر يسير جداً و منطق للغاية، فماذا عن اللغات الوظائفية أو الإجرائية و تعاملها (بطريقة وظائفية أو إجرائية صرفة) مع هذا الأمر؟، أنا شخصياً قد تعاملت مع مكتبة الـ(openCV) من خلال عملى فى مجال معالجة الصور أى الـ(image processing) و بالطبع كنت أتعامل معها باستخدام لغة الـ(C++) للحصول على أفضل أداء ممكن (و لأسباب أخرى ليس هذا محلها) و يسعدنى أن أقول أن الأمر كان مسخرة بالنسبة لى أنا المبرمج المغلوب على أمره، حيث كان على أن أستدعى إجراء (cvNamedWindow) لها الشكل التالى:
   
   لكى تقوم بإنشاء نافذة مرئية ثم كان على أن أستدعى إجراء أخرى لكى أقوم مثلاً بضم عمود تعقب (track bar) إلى تلك النافذة التى صنعتها تواً و هى إجراء (cvCreateTrackbar) التى لها الشكل التالى:
   
   و لكى أقوم بتكرار الأمر أى إنشاء أكثر من نافذة و ضم عمود تعقب لكل نافذة يكون على أن أقوم بتكرار الأوامر ذاتها مراراً، لأن خاصية كتابة صنف يفعل ذلك ثم الاشتقاق منه فى كل مرة غير موجودة بالطبع فى البرمجة الوظائفية بل هى (و ياللعجب) الفكرة الرئيسة فى البرمجة الكائنية.

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

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

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

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

1. كونها صيغة تستهدف المعالج مباشرة أم تستهدف مفسراً:
   فمواقع الشبكة بالطبع تعتمد على برامج متصفحات الشبكة فى عملها مثل (Firefox) و (internet explorer) و غيرها من المتصفحات دائماً، و لا تعمل بأى حال من الأحوال بصورة منفردة مستقلة، فى حين أن برامج سطح المكتب لها الخيار فى أن تكون معتمدة على مفسر معين مثل برمجيات الجافا التى تعمل على منصة الـ(JVM) و برامج الـ(C#) و الـ(visual basic.NET) التى تعمل على منصة الـ(.NET)، و لها كذلك الخيار فى أن تكون مستقلة تعمل مباشرة على المعالج و تتحاور مع نظام التشغيل لتطلب منه ما تريد من مهام بنفسها لا من خلال وسيط.

2. شكل الصيغة التى تعتمد على المفسر لبرامج سطح المكتب و شكل صيغة برمجيات مواقع النت:
   حيث أنه مادامت طبيعة البرامج الخاصة بسطح المكتب لها عالمها المنفصل عن عالم متصفحات الشبكة بالكلية فربما يكون هذا الأمر قد أثر على الصيغ النهائية التى تخزن بها التعليمات العليا التى كتبها المبرمج (و أنا عن نفسى لا أعلم جيداً لأنى لم أدرس هذا الأمر قبلاً لذا أقول ربما).

أما عن تصميم لغات البرمجة فكما قلت من قبل فإنى لا أجد أى فارق حقيقى من وجهة نظر المبرمج عالى المستوى، و دليل على ذلك لغات كالـ(java script) التى لا تشبه لغة الـ(HTML) من قريب أو بعيد. و تستخدم فى برمجة مواقع النت ضمن أكواد الـ(HTML). بل و لماذا أضرب المثال بالـ(java script) فى حين أن الحبيبة الغالية الـ(java) موجودة فى مجال تصميم مواقع النت بكل عنفوانها و هى اللغة التى تستخدم فى الأصل لبرمجة برامج سطح المكتب، و أنا هنا آخذ الجافا كدليل أقوى و حاسم فى هذه النقطة لأنها تقول كلامى عن الافتعال فى التفرقة بين نوعى لغات البرمجة (لسطح المكتب و للشبكة) بصورة عملية لا جدال فيها.

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

حيث لو أخذنا على سبيل المثال بناء بيئات سطح المكتب فى أنظمة التشغيل المختلفة مثل (KDE) و (GNOME) و (LXDE) فى الأنظمة شبيهة اليونيكس و غيرها من البيئات المشهورة الأخرى لوجدنا أنها قد بنيت باستخدام لغة الـ(C++) التى يتحقق فيها شرط اللغات التى تصلح لهذا المجال، و لكن على الرغم من ذلك فقد كان من الممكن أن يتم بناؤها بلغات أخرى غير الـ(C++) مثل الـ(java) مثلاُ التى تم باستخدامها فعلاً بناء سطح مكتب الـ(java) أو الـ(java descktop) لنظام التشغيل الجميل (open solaris)، إلا أن ذلك لم يتم لأن المبرمجين الذين قاموا بذلك العمل كانوا ممن يستخدمون لغة الـ(C++) بحكم كونهم من المهتمين بتطوير و بناء النظم الأساسية أو البنية التحتية فى عالم الحاسوب، و بالتالى أصبح استخدام الـ(C++) فى هذا المجال أمراً طبعياً بل و أصبح مع الزمن من التابوهات المحرمة فى عالم البرمجة، مثله كمثل عدم صنع لغة أخرى تحل محل لغة الـ(C) فى بناء البنى التحتية بدون تعقيد تلك الأخيرة الذى يعرفه الكل.

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

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

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

و على سبيل المثال لا الحصر يمكننا أن نرى أن حال لغة الـ(visual basic) فى مجال التكامل مع نظام الويندوز (windows) و حزمة برامج مكتب (microsoft) (Microsoft office) جعلها هى اللغة الأشهر فى هذا على الرغم من ضعف اللغة النحوى و عدم تعاملها مع المشاريع الكبيرة بكفاءة مناسبة، و لكن لأن (microsoft) ركزت على هذا الموضوع بقوة فقد كان من المعتاد أن نسمع فى فترة عنفوان الـ(visual basic) عبارات على شاكلة (الإنتاجية العالية = visual basic) و (تطبيق به نوافذ مرئية = تطبيق مكتوب بـ visual basic) على الرغم من أن هناك مجالات أخرى تصلح لها الـ(visual basic) برمجياً مثل كل اللغات عالية المستوى العام الاستخدام إلا أنها اشتهرت بهذا و اشتهرت أكثر بأنها خلاف سهولتها فى ذلك المجال فأنها متعبة جداً فى باقى المجالات.

و لعل هناك سبب آخر يندرج تحت القول بالتركيز على مجال معين هو الإهمال المتعمد، ففى بعض الأحيان يكون هناك إهمال متعمد من منتج اللغة البرمجية لمجال من المجالات لغرض ما هو فى الغالب تجارى أو يصب فى خانة هدف تجارى، و لغة الـ(visual basic) و لغات الـ(.NET) عموماً دليل على ذلك كل الدلالة، فالمبرمج الذى يستخدم اللغات السابقة حكم على نفسه بالبقاء تحت مظلة أنظمة تشغيل (microsoft) للأبد، لأن المحمولية لم تكن أبداً فى أى يوم من الأيام هدف من أهدافها و هو الأمر الذى يعيه الجميع من المبرمجين.

و لعل الشئ الذى يخفف ذلك على مبرمجى الـ(.NET) هو وجود المشاريع مفتوحة المصدر التى تغنى عن بديلها المنتج من قبل (microsoft) و هو مشروع الـ(mono) من شركة (novell) الذى يتكون من بيئة برمجية متكاملة للغة الـ(C#) و بيئة عمل تحل محل بيئة الـ(.NET) الخاصة بزمن التشغيل على نظام الويندوز و تعمل على باقة أنظمى التشغيل المشهورة مثل اللينوكس و السولاريز و ماك و التى تم إهمالها بالطبع فى بيئة الـ(.NET) الخاصة بـ(microsoft).

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

و قد أدى مثل هذا الأمر (و أمور أخرى ليس هذا محلها) إلى تحذير السيد ريتشارد ماثيو ستولمان من استخدام بيئة الـ(mono) فى عمل البرمجيات مقتوحة المصدر، و أنا عن نفسى أقبل اعتراضه هذا تماماً رغم أننى من محترفى البرمجة بالـ(C#) إلا أن الحق أحق أن يتبع، و إسناد الظهر إلى (microsoft) سيكون أكثر قرارات عمرى حماقة إن اتخذته، لذا فأنا أسأل الله تعالى ألا أضطر إليه فى يوم من الأيام.

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

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

و بالتطبيق على اللغات البرمجية الحالية فسنرى أن اللغات التى تحقق هذا الشرط قليلة للغاية مقارنة بما هو مستخدم منها بالفعل، و أشهر الأمثلة التى ستضرب لهذا النوع من اللغات هى لغات الـ(java, C++, visual basic .NET, C#) لذا ففى قابل كلماتى سوف أناقش موقفى من كل لغة موضحاً حقيقة هذا الزعم من كذبه.

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

فالـjava تعطى المبرمج بها القدرة على البرمجة لمجالات واسعة المدى مثل:

1. برامج سطح المكتب ذات الواجهات المرئية.
2. برامج سطح المكتب النصية.
3. برامج العملاء على الشبكة.
4. برامج الخادمات.
5. مواقع الشبكة.
6. برمجة الأجهزة الذكية مثل الهواتف المحمولة و الثلاجات المعدلة و غيرها من تلك النوعية من الأجهزة.
7. برمجة الألعاب.
8. التعامل مع قواعد البيانات.

و بالتالى فليس هناك مجال يمكن أن يفكر فيه المبرمج إلا و وجد الـjava واقفة فى انتظاره مادة إليه يد المساعدة، و أهم من ذلك كون الـjava تعمل على أنظمة التشغيل المختلفة بمنتهى المساواة و بنفس الكود البرمجى، و كما يعبر صناع الـjava عن هذا المبدأ بقولهم (أكتب مرة واحدة و شغل فى أى مكان) و يستحق هذا المبدأ بحق كل ما بذل من جهد للوصول إلى تحقيقه بالصورة الرائعة التى نراها و التى أعطت الـjava لقب ملكة المحمولية بلا جدال.

أما الـ(C#) فهى لغة قوية بالفعل، و دليل اقتناعى بذلك أنها أكثر اللغات التى أنا ملم بها (أكثر حتى من الـjava) على الرغم من أننى أعز الـjava أكثر منها بكثير، و لكن و رغم كل هذا فإن الـ(C#) لا تصمد أمام الـjava إذا ما قارناهما من منطلق الشمولية، و ذلك على الرغم من أنها تصلح لنفس المجالات التى ذكرناها للـjava و هى:

1. برامج سطح المكتب ذات الواجهات المرئية.
2. برامج سطح المكتب النصية.
3. برامج العملاء على الشبكة.
4. برامج الخادمات.
5. مواقع الشبكة.
6. برمجة الأجهزة الذكية مثل الهواتف المحمولة و الثلاجات المعدلة و غيرها من تلك النوعية من الأجهزة.
7. برمجة الألعاب.
8. التعامل مع قواعد البيانات.

و لكن بالطبع مع وضع جملة (مع أنظمة تشغيل microsoft فقط) أمام اسم كل مجال مما ذكر بالقائمة فى الأعلى، و هذا الأمر ليس بالهين أبداً إذا ما علمنا أن نسبة الخوادم التى تستخدم نظام تشغيل اللينوكس تبلغ ما يزيد على السبعين فى المائة من مجموع الخوادم العاملة فعلاً و أن أشهر المواقع العالمية تستخدمه بدلاً من الـwindows الذى أذاقهم الأمرين بضعفه الشديد و تكلفته الأشد.

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

فشمولية محصورة فى ركن معين من عالم الحوسبة مقارنة بالشمولية المنفتحة على العالم الحوسبى كله تشبه بالضبط موقف الجارية من الزوجة رغم الغرابة فى التشبيه، فالزوجة و الجارية متساويتان فى الحق فى المعاملة الحسنة من الزوج أو المالك، و للزوج عليهما حقوق مشترك كثيرة، و لكن هل هناك أى مجال للمقارنة بين وضع الزوجة و وضع الجارية؟ أى صاحب عقل سيرفض المقارنة من الأصل، و بالمثل المقارنة بين شمولية الـjava و شمولية الـ(C#) فهما اسمياً تكادان تتساويان تماماً من ناحية أنواع التطبيقات و المجالات التى يمكن أن تستخدم فيها، و لكن ذلك لا يكفى أبداً للمساواة بين الزوجة (الـjava) و الجارية الـ(#C).

و ما قيل عن الـ(C#) يقال بالضبط عن الـ(visual basic .NET) نظراً للتوءمة التى صنعتها Microsoft بين اللغتين حينما ضمتهما إلى إطار عمل الـ(.NET)، و بالتالى هى تأخذ نفس حكم الـ(C#) بلا زيادة أو نقصان.

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

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

الوراثة:

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

1- الوراثة العادية لصنفٍ من الأصناف لصنفٍ آخر، و هو التعريف النمطى الذى يعطيه الكل للوراثة فى البرمجة الكائنية المنحى (oop).
2- الإعلان عن كائن object أو نسخة instance من صنفٍ ما، فلو فكرنا فيها جيداً لوجدنا أن الكائنات التى نُعلن عنها ما هى إلا إعادة استخدامٍ لكود الصنف بدون الحاجة إلى كتابته مرةً أخرى لكل كائنٍ كما يحدث فى منهجيتى البرمجة الوظائفية functional و الإجرائية procedural، و كذلك فإن أى تغييرٍ يطرأ على كود الصنف سيكون مطبقاً على كافة النسخ المنتجة منه. و بذا يتحقق شرطى الوراثة عندى على هذه العملية.
3- استخدام المكتبات البرمجية ذاته، و هذا الأمر قد يدفع إلى الظن بأن الوراثة عندى ما هى إلا مسمىً آخر لعملية إعادة الإستخدام علي عكس ما نوهت قبلاً، و لكننى أعود لأؤكد أن هذا الظن خاطئٌ تماماً؛ ففى عملية إعادة الإستخدام يكون الشرط الرئيس لكى يمكنك أن تقول أن ما حدث هو إعادة استخدام هو: أن يقوم المبرمج باستخدام كودٍ برمجىٍٍ ما مرةً أخرى فقط، أى أنه لا يُشترط لكى تكون العملية ضمن نطاق إعادة الاستخدام أن تكون التغييرات الجديدة فى الأصل (و التى تمت بعد إعادة الاستخدام) ذات أثرٍ على الفروع المستخدمة للأصل البرمجى، فى حين أن هذا شرطٌ أساسىٌ عندى لكى أُطلق على العملية لقب الوراثة. 
و حينما ننظر إلى عملية النسخ و اللصق التقليدية فسنجد أنها خير مثالٍ يوضح الفارق بين الوراثة عندى و إعادة الاستخدام، لأنها يَصْدُق عليها وصف إعادة الاستخدام بكل قوة، فى حين أنه لا ينطبق عليها مفهومى للوراثة و لا يمكننى أن أعدها لوناً من ألوان التوراث؛ لعدم تطبيق التغيرات المُحْدَثة إلا على الأصل المنسوخ فقط.
 
و قد أفضت فى شرح الفارق بين نظرتى للوراثة و بين النظرة الحالية لها لكى أستطيع بعد ذلك أن أتحدث بحريةٍ عن مدى أهمية الوراثة عندى، و ذلك بدون خوف الإلتباس على القارئ لهذه الأسطر.  
و الحق أن للوراثة عندى أهميةً فى الحدود القصوى لها، فأنا أعتقد اعتقاداًً جازماً أن أى كودٍ مُهَنْدَسٍ جيداً قد يكون قابلاً لإعادة الاستخدام التوارثى بطريقةٍ تُمَكِّنُنا من حل المشاكل الجديدة بطرقٍ أسرع و أفضل بكثير.
و جديرٌ بالذكر أن الوراثة تدخل فى أغلب المواضيع الهامة التى تتعلق بالمفاضلة بين لغات البرمجة إن لم يكن فيها كلها؛ و ذلك لأن لها من الفوائد الكثير و الكثير، و يمكننى أن أعد هنا طرفاً من هذه الفوائد فيما يلى:
1- سرعة الإنتاج: و القول المنتشر بين معاشر البرمجين و الذى يصف هذه النقطة جيداً هو (عدم إعادة اختراع العجلة)، حيث لن يكون على المبرمج كتابة الآلاف من الأسطر فى كل مرةٍ يحتاجها فى عمله، بل يكتبها مرةً واحدةً فقط ثم يقوم باستدعائها كل مرةٍ بمنتهى السرعة، مما يعنى التركيز على المشكلة الحقيقية و عدم هدر الجهد فى أمرٍ فُعِل من قبل و هو ما يؤدى إلى الإنتاجية الكبيرة فى النهاية.
2- الأمن: الأكواد التى ستُستخدم فى الوراثة ستكون قد اختُبرت جيداً قبل وضعها فى الخدمة التوارثية، مما يعنى أن المبرمج المستخدم لهذه الأكواد الموروثة يستطيع الإطمئنان إلى كون الكود الموروث ذي أمانٍ عال، فلا يحتاج إلى إعادة اختباره مرةً أخرى، و ذلك على العكس من الأكواد الجديدة التى يكتبها إن لم يستخدم الوراثة، حيث سيكون عليه التأكد من أمن تلك الأكواد فى كل مرة.
3- توفير التكلفة: عند إنتاج البرمجيات بصورةٍ تُجارية يكون من أهم الأمور إنتاج التطبيق المراد بأقل التكاليف الممكنة، و قد قام علم هندسة البرمجيات من الأصل ليصل إلى هذا الهدف من ضمن الأهداف الرئيسة التى قام لأجلها. و نحن حينما نعيد استخدام الأكواد التى صنعناها من قبل فإننا نوفر الوقت و الجهد و المال بصورةٍ كبيرةٍ للغاية تظهر أكبر ما تظهر فى المشاريع البرمجية العملاقة.
4- توارث الكفاءة: حينما يتم اكتشاف خوارزمٍ algorithm جديدٍ أكثر كفاءةً للقيام بالعملية التى كان يُستخدم فيها خوارزمٌ أقل كفاءةً: يكون إحلال الجديد محل القديم مكسباً كبيراً، ليس فقط للتطبيقات التى ستستخدم الخوارزم بعد الإحلال بل حتى للتطبيقات التى تستخدم الخوارزم من أيامه الأولى قبل التجديد، أى أن التغييرات الجديدة لن تجد طريقها فقط للمستخدمين الجدد بل سيتم توارثها هى الأخرى.
5- التجرد الأقصى و بساطة حل المشاكل: حينما تتوافر تحت يد المبرمج أدواتٌ كثيرةٌ جاهزةٌ للعمل باستخدامها: سيكون الأمر الوحيد الذى سيركز عليه جهده و تفكيره هو حل المشكلة التى يريد استخدام البرمجة لحلها، و هو الأمر الذى سيجعل البرمجة أكثر سهولةً بكثير، بل و أكثر إمتاعاً بكثير.