مُلخَّص ندوة "البرمجيات الحرة: توضيحٌ، تأريخٌ، أمثلة"

البارحة كنتُ في هندسة أسوان و ألقيتُ المحاضرة التي كانت تحت عنوان "البرمجيات الحرة: توضيحٌ، تأريخٌ، أمثلة". و رغم أن عدد الحضور كان للأسف قليلاً جداً (من عشرة إلي خمسة عشر) إلا أنني أُفضِّل العدد القليل المُنتبِه المُتفاعِل علي العدد الكبير الذي لا يسره شيءٌ قدر الانتهاء من الملل الذي يُسببه لهم المُحاضِر.

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

و ها هو ذا العرض البسيط الذي استعنتُ به يومها لتحميله إذا رغبتم في هذا (مع تعديلاتٍ طفيفةٍ جداً):

  

 

أهم ما أنصح به "فرع الـIEEE للطلاب في أسوان" هو ألا يستسلموا لليأس مطلقاً، و أن يحاولوا قدر الاستطاعة؛ فالصبر كفيلٌ بإيصالهم إلي مبتغاهم بإذن الله تعالي. صحيحٌ أن الجو المحيط سيءٌ للغاية من حيث عدم الإقبال من جانب الطلبة، و كذلك عدم التعاون الكافي من المسؤولين، إلا أن القاعدة التي تُرِيح دائماً في مثل تلك المواقف تقول "عليك بالعمل و ليس عليك النتائج".

و أرجو الله عز و جل أن يوفقهم و من هو مثلهم.

نشأة البرمجيات مفتوحة المصدر (1)

هذا هو أول مقالٍ لي في سلسلة مقالاتٍ تتحدث عن (نشأة البرمجيات مفتوحة المصدر)، و قد تم نشره في موقع (صدي التقنية) علي الرابط:
http://tech-echo.com/2013/02/beginning-of-open-source-software/

 ***

 
في الآونة الأخيرة ازدادت شهرة ما يُعرف بالبرمجيات الحرة free software و البرمجيات المفتوحة المصدر open source software في العالم العربي، تزايد الشهرة في هذه الأيام لا يعني أن هذين النوعين من البرمجيات لم ينشآ إلا في الفترة الحالية، و لا يعني كذلك أنهما لم يكونا معروفين للمهتمين بالتقنيات الحاسوبية منذ فترةٍ طويلة، بل يعني فقط أن انتشار الاهتمام بهما بين القاعدة العريضة من التقنيين العرب ازداد مؤخراً، و نري هذا واضحاً في ازدياد المتابعين للمواقع التي تقدم أخبار تلك التقنيات، و كذلك في اهتمام الذين لا يستخدمونهما من الأصل؛ بسبب رغبتهم في زيادة ثقافتهم الحاسوبية، أو حتي فتح آفاقٍ جديدةٍ في العمل.

السؤال هنا: ما هي المصادر المفتوحة، و ما هي البرمجيات الحرة، و هل هناك فارقٌ فعليٌ بينهما ؟

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

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

في هذه المرحلة بدأت البرمجيات تصبح أكثر تعقيداً عما كانت عليه من قبل، و بدأت شركات الحواسيب تنتبه إلي أن البرمجيات تصلح كسلاحٍ تسويقيٍ ممتازٍ إذا تم منع الآخرين من استخدامها بدورهم، و هو ما سيُطلَق عليه في عالم البرمجيات الحرة فيما بعد اسم "الاحتكار" و سأطلق عليه هنا اسم "الاستئثار". و كانت أهم الخطوات الاستئثارية التي قامت بها الشركات و أثَّرت علي مسيرة عالم المصادر الحرة تلك التي قامت بها شركة (AT&T) مع نظام تشغيل اليُنِكْس unix.

و لكن قبل أن نتحدث عن تلك الخطوة الفارقة تعالوا نتحدث عن شخصٍ يسمَّي ريتشارد ماثيو ستولمان richard matthew stallman أولاً؛ فهو من أكثر الشخصيات تأثيراً علي عالم البرمجيات الحرة ذي الصبغة القانونية و الفلسفية، كما أنه من أكثر الشخصيات إثارةً للجدل سواءٌ في عالم البرمجيات الحرة أو في عالم البرمجيات المُغلَقة المصدر (الاستئثارية-الاحتكارية) !

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

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

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

الصدمة التي حدثت لستولمان مع عددٍ كبيرٍ من التقنيين الآخرين كانت ما حدث مع نظام اليُنِكْس؛ و اليُنِكْس هو نظام تشغيلٍ متطورٍ كانت له قصة النشوء التالية:
فى منتصف الستينيات تعاونت (جنرال إليكتريك general electric) و (معامل بِلْ bell laboratories التي تغيَّر اسمها فيما بعد ليصبح AT&T) و (معهد MIT للتقنية) لإنتاج نظام تشغيلٍ يُسمَّي MULTICS، و هو  اختصارٌ لاسم (multiplexed Information Computing System). و يتميز بالعديد من القدرات القوية مثل تعدد المهام multi-tasking و تعدد المستخدمين multi-users و إداره ملفاتٍ متعددة المستويات multi-level file management  و غيرهن من القدرات. لكن AT&T انسحبت من المشروع في نهاية الأمر.
إلا أنه في عام 1969 قام كِنْ ثومبسون Ken Thompson  مع دِنِس رِتْشى Dennis Ritchie  و عددٍ آخرٍ من المبرمجين الذين كانوا قد عملوا فى مشروع MULTICS باستئناف العمل فى AT&T لإنتاج نظام تشغيل مماثلٍ خاصٍ بهم، بحيث يعمل على أجهزةٍ من نوع minicomputer، وفي 1 يناير 1970 تم تشغيل أول إصدارات اليُنِكْس.

و في بداية الأمر كانت AT&T قد جعلت اليُنِكْس منتجاً بحثياً research product بإمكان الجميع أن يستخدموه فى أبحاثهم و يطوروا فيه على أن تظل الملكيه لـAT&T،  و منذ ساعتها انتشر يُنِكْس انتشار النار في الهشيم بين الجامعات و الشركات المختلفة، إلا أن تغير نظرة الشركات للبرمجيات جعل الأمور تتغير تماماً فيما بعد. و في عام 1983 و حينما وصلت نسخةٌ من إصدارة system3 إلي ستولمان لم يجد الكود المصدري الخاص بها معها، رغم أنه كما قلنا أن المعتاد كان العكس تماماً، و الأغرب أنه حينما حاول أن يحصل عليه فوجيء أنه لا يمكن ذلك إلا إذا وقَّع على اتفاقية عدم الكشف (Non-Disclosure Agreement) أو (NDA)  اختصاراً،  و هو الأمر الذى يجعل من حصوله على الكود عديم القيمة. كأنك تضع أحدهم في معركةٍ طاحنة مع مسدسٍ سريع الطلقات و لكن في نفس الوقت تشترط عليه أن يعيد لك المسدس و الطلقات بنفس عددها الأول !

المصيبة الكبري كانت أن نظام اليُنِكْس كما ذكرتُ من قبل رغم أن علامته التجارية كانت ساعتها ملكاً لشركة AT&T إلا أن الواقع أن الجامعات المختلفة و المبرمجين في الشركات و في المعاهد التقنية المتنوعة كانوا قد أسهموا بشكلٍ كبيرٍ في تطويره، و هكذا لم تكن الخطوة الأخيرة التي قامت بها AT&T إلا ضربةً تحت الحزام ! و في النهاية لا يمكنك الاعتراض بشكلٍ قانونيٍ لأن "العلامة التجارية كانت ملكاً لـAT&T فقط".

هنا و بعد كل لتلك الصدمات المتواليات قرر ستولمان أنه "ما حك جلدك مثل ظفرك ... فتولَّ أنت جميع أمرك".
أنا عن نفسي كنتُ سأقضي ربع ساعةٍ من الصراخ و ركل الأرض بقدمي و ربما أُطلِق بعض السباب كذلك، و من الممكن أن أكتب رسالةً بذيئةً لقيادات AT&T و أوقعها باسمٍ زائف، لكني في كل الأحوال بعد فعل ذلك كنتُ سأخرس كأفراس النهر تماماً.

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

و بما أن أول البرمجيات التي يحتاجها الحاسوب لكي يعمل هو نظام التشغيل operating system، فقد قرر ستولمان أنه سيكتب نظام تشغيلٍ حر يستطيع الناس استخدامه كبديلٍ لأنظمة التشغيل الاحتكارية.
اختار ستولمان أن يكون نظامه الجديد مشابهاً لنظام اليُنِكْس unix لأسبابٍ لا أعلمها جيداً، ربما كان السر في ذلك هو انه كتب برامجاً لليُنِكْس و يريد تشغيلها علي نظامه الجديد دون التغيير في أكوادها، أو ربما لأنه هو و المبرمجين الآخرين يعلمون الكثير بالفعل عن اليُنِكْس من خلال احتكاكهم السابق به، و بالتالي يصير من السهل تعاملهم مع المشروع الجديد كمطورين أو مستخدمين، أو ربما لأنه رأي أن تصميم اليُنِكْس تصميمٌ رائعٌ و سهل البناء، و ربما كان كل ما فات صحيحاً.

المهم أنه اختار أن يكون نظامه الجديد مشابهاً لليُنِكْس unix-like و أن يكون له الاسم "قِنُو GNU"  (يُُكتَب "جِنُو" في الترجمات المصرية)، و هو اختصارٌ لجملة "GNU's Not Unix" و يصف ستولمان هذا الاختصار بأنه إبداع hack في حد ذاته.
كانت طريقة ستولمان في بناء نظامه هي استبدال الأجزاء جزءاً تلو الآخر، فنظام اليُنِكْس يعمل كمجموعةٍ من التطبيقات تتخاطب فيما بينها و تتعاون لإنجاز العمل الكلي، و بالتالي من الممكن أن تستغن عن البرنامج غير الحر الأول و تكتب بديلاً له، ثم تستغن عن البرنامج غير الحر الثاني و تكتب بديلاً له، و هكذا إلي أن تجد أنك قد استبدلتَ كل مكونات النظام القديم بأخري جديدة حرة.
لكن المشكلة أن هذا كان معناه الحاجة في البداية إلي مكتباتٍ برمجيةٍ حرة، و تلك المكتبات البرمجية الحرة لا بد من بنائها من الصفر،
ثم بناء مترجمٍ compiler للغة الـc من الصفر !،
و مُحرِّر أكوادٍ code editor حر !
و مُنقِّحٍ debugger حر !

و علي هذا فقِسْ !!!

الخلاصة أن شخصاً آخر كان سـ"يضع ذيله في أسنانه" و يهرب من هذا الموضوع كما تهرب الغزلان من الأسود، إلا أن ستولمان كان (و لا يزال) متحجر الرأس جداً، لذا أصر علي الاستمرار و تجميع الآخرين لمساعدته في هذه الأعمال. لذا قام بالإعلان عن مشروع GNU عام 1984و نشر ما يُسمَّي "بيان قنو GNU manifesto" و الذي حث الآخرين فيه علي الانضمام إليه في مشروعه و مساعدته علي إنجاحه، و لرعاية المشروع و كل ما يتعلق به أسس ستولمان مؤسسة "البرمجيات الحرة Free Software Foundation" لترعي الجوانب القانونية و التنظيمية من العمل و تُصبح الشخصية الاعتبارية التي تتحدث بلسان حركة المصادر الحرة.

يُتبَع

استبدال الإجراءات متعددة الخرج بالإجراءات الداخلية

هناك لغات برمجةٍ تسمح بتفريع الإجراءات functions nesting، أي أنها تسمح بتعريف إجراءٍ أو أكثر داخل إجراءٍ آخر، و من تلك اللغات لغة الـpython علي سبيل المثال. و في أمثال تِلكم اللغات نري أننا نحصل علي فائدةٍ جميلةٍ من تفريع الإجراءات، حيث أن الإجراءات الداخلية يمكن أن تكون قادرةً علي التعامل مع المتغيرات و الثوابت و ما يشبههن اللاتي تم تعريفهن في الإجراءات الخارجية قبل تعريف الإجراء الداخلي، و كذلك التغيير في قِيم تلكم العناصر بحرية.
كما في المثال التالي المكتوب بالـpython:

def  func1():
    x = [10]
    y = [20]
   
    def  func2():
         x[0] = x[0]+ 1
         y[0] = y[0] + 1
   
    func2()
   
    print x[0],"    ", y[0]
   
func1()

الذي يعطي عند تنفيذه الخرج التالي:
11         21

و لو حاولنا إعادة صياغة البرنامج السابق بلغة لا تدعم تفريع الإجراءات مثل الـjava لوجدنا أننا سنضطر لكتابة كودٍ يشبه ما يلي:

public class Test {
    public static void main(String[] args) {
        Test t = new Test();
        t.func1();
    }
   
    void func1() {
        int x = 10, y = 20;
        result res = func2(new result(x, y));
        System.out.println("" + res.x + "    " + res.y);
    }

    result  func2(result res){
        res.x = res.x +1;
        res.y = res.y +1;
        return res;
    }

    class result {
        int x, y;
        public result(int x, int y){
            this.x = x;
            this.y = y;
        }
    }
}

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


إجراء1()

إجراء  إجراء1 :
    رقم س = 10
    رقم ص = 20
   
    س ، ص = إجراء2(س    ص)
   
    أكتب.نص.سطر(إلي.نص(س) +"       " + إلي.نص(ص))
   
إجراء  (رقم س2  رقم ص2)  إجراء2(رقم س1  رقم ص1):
    س2 = س1 +1
    ص2 = ص1 +1
   
   
و له تقريباً نفس عدد أوامر البرنامج المكتوب بالـpython، بل و يمكن اختصار البرنامج السابق أكثر من ذلك بجعل كود الإجراء إجراء2 كما يلي:

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

كما أنه يمكن الاستغناء عن الإجراءات الداخلية عن طريق التمرير بالمرجع passing by reference، و هو الأمر الموجود في لغاتٍ كثيرةٍ منها الـC  و الـ++C و الـ object pascal و الـD و غيرهن من اللغات الأخري. و يمكننا كتابة المثال السابق بلغة object pascal كما يلي*:

function func2(var x, y :integer);
begin
    x = x+1
    y = y+1
end;

function func1();
begin
    x :integer = 10;
    y :integer = 20;
   
    func2(x,y);
   
    writeln(x +"    " +y);
end;

begin
    func1();
End.

و بالطبع يمكنكم ملاحظة أنه تم الاستغناء عن الإجراءات الداخلية هنا أيضاً بكفاءة، لكن أيضاً يمكنكم ملاحظة أن تعقيد قواعد الـobject pascal جعل الأمر أقل سهولةً من حالتَيْ الـpython و إبداع.

كما أن هناك نقطةً أخري تتعلق بإمكانية حدوث ارتباكاتٍ و مشاكلٍ منطقيةٍ في اللغات التي تدعم الإجراءات الداخلية، حينما تكون تلك اللغات من نوع اللغات استنتاجية الأنواع Type inference، فمثلاً لو نظرنا إلي البرنامج الأول المكتوب بلغة الـpython لوجدنا أنه يستخدم الـlists و ليس المتغيرات الرقمية البسيطة، فلماذا لم أكتبه كما يلي:

def  func1():
    x = 10
    y = 20
   
    def  func2():
         x = x + 1
         y = y + 1
   
    func2()
   
    print x,"    ", y
   
func1()

علي الرغم من أن هذا هو الأمر الأقرب للمنطق ؟!
الجواب أنني حينما فعلتُ ذلك أَخرجَ لي مُفسِّر الـpython الخطأ التالي:

x = x + 1                                                                                                            

UnboundLocalError: local variable 'x' referenced before assignment

و السبب في هذا أنه اعتبر أن المتغيرين x و y داخل الإجراء func2 يختلفان عن المتغيرين x و y اللذين في func1 ! و بالتالي أصبح من الخطأ كتابة الأمرين:

x = x + 1
y = y + 1

لأننا بهذا نكون قد استخدمنا المتغيرين x و y قبل إعطائهما أي قيمة، رغم أن المبرمج يقصد أن يستخدم x و y الخاصين بالإجراء func1 و اللذان تم إعطاؤهما قيماً ابتدائيةً هن 10 و 20 علي الترتيب !

و الغريب أنك لو عرَّفتَ list داخل func1 فيمكنك استخدام عناصرها الداخلية بشكلٍ عاديٍ في func2، و هو ما لجأتُ إليه فعلاً في المثال الأول. و لكنك لو أسندتَ قيمةً لاسم تلك الـlist في الإجراء الداخلي func2 فإنه سيعتبر أنك تقوم بتعريف list جديدة داخل func2 تُغطِّي تلك التي تحمل نفس الاسم في func1 !
أي أنهً عند تنفيذ المثال التالي:

def  func1():
    x = [10]
    y = [20]
   
    def  func2():
         x = [11]
         y = [21]
   
    func2()
   
    print x[0],"  ",  y[0]
   
func1()

تكون النتيجة:

10    20

لأن القِيم [11] و [21] أُسنِدت إلي x و y  الخاصَّيْن بـfunc2، بينما بقي x و y الخاصَّيْن بـfunc1 كما هما، و هذا يعني معضلةً عند محاولة المبرمج التعديل في قيمة x أو y  في func1 من داخل func2؛ حيث أنني حينما حاولتُ إيجاد طريقةٍ لفعل ذلك تختلف عن استخدام خاصية الخرج المتعدد: لم أجد، و هو ما يؤيد عدم الحاجة الضرورية لتفريع الإجراءات، و أن كل الفوائد التي يمكن جنيها من ورائه يمكن الحصول عليها بشكلٍ أبسط و أسهل عن طريق الإجراءات متعددة الخرج. 

كما أن هذا الأمر يؤكد أيضاً ما ذهبتُ إليه من أفضلية فرض التعريف اليدوي للأنواع علي المبرمج و عدم جعل اللغة من النوع الذي يستنتج الأنواع بدون تدخل المبرمج**.

----------------------------------

* كل البرامج المكتوبة في هذا المقال تم تنفيذها عملياً و التأكد من خلوها من الأخطاء، ما عدا البرنامج المكتوب بالـobject pascal.

** تجدون كلامي عن هذه الجزئية في فصل (فائدة تعريف الحاويات يدوياً) الموجود في باب (أين الإبداع فيها؟) في نهاية كتاب (رسالة البرمجة بإبداع).