- لم تكون دروساً منتظمة بل على فترات متباعدة (ولعل هذا هو السبب الاساسي في المشاكل التي حدثت).
- كنت اعلمهم شفاهة بلا مرجع مكتوب.
- لكن كل منهما كان لديه نسخة مطبوعة من كتاب تحقيق الذات في كتابة البرمجيات.
كان المثال الذي احاول شرحه دائماً هو برنامج "التحية"، الذي يسأل المستخدم عن اسمه ثم يرد بقول "مرحباً يا فلان". وفي الحالتين كانت نفس المشاكل تكرر نفسها.
1- المشكلة الاولى في موضوع analytical thinking، كان كل منهما يحاول كتابة البرنامج المطلوب عن طريق تخمين مكوناته من البرامج السابقة. فكان البرناج يبدو كخليط من مجموعة الامثلة التي قلتها له في نفس الجلسة او الجلسات السابقة. اعتقد اننا هنا في نقطة جوهرية: لكي تعلم الطفل، او اي شخص، كيف يبرمج لابد أن يدرك ماهية البرمجة نفسها: وهي أن تضع هدفاً محدداً ثم تفكر كيف تعبر عن ذلك الهدف عن طريق الاوامر الاساسية الموجودة في اللغة.
حاولت مع احد الطفلين (واشعر انها محاولة جيدة) ان اصف ذلك الموضوع عن طريق مثال اخذته من قصة "مروة والبرمجة الهيكلية"، عن الروبوت الذي لابد ان تعلمه مروة كيف يأخذ الكوب إلى المطبخ فلابد ان تعطيه ادق ادق التفاصيل. كان الحوار مثمراً وبدأ هو يستنتج فيقول "يعني لو نسيت وقلت له حوّد شمال بدل يمين، وكان الحمام هناك، حيخش الحمام بدل المطبخ!" وقد رأيت تشجيعه فقلت "أه! ولو وصفت له الكباية غلط ممكن يمسك الحلة بدالها". يلاحظ انني حاولت ان اجعل الشبه دقيقاً: الألي لا يفهم "مطبخ" أو "كوب" لكنه يفهم "ابحث بالكاميرا عن جسم حجمه كذا"، "تحرك إلى الامام"، "امسك الجسم الموجود امامك بيدك"...وان هذا يكافيء الاوامر المكتوبة بالازرق في لغة كلمات.
موضوع الconcepts عن طريق الحكايات اقوى مما ظننت، ويستحق المزيد من البحث. افكر في عمل video game بها مروة والروبوت، وعليك التحكم فيه بالاوامر ليقوم بأعمال المنزل. ربما يكون هذا اكثر تصويراً من اوامر "اطبع" و"اقرأ".
2- في التجربتين الطفل لم يكن مدركاً جيداً للsyntax الخاص بكلمات، اعتقد انه كان من الافضل بكثير عمل reference من ورقة واحدة للsyntax الخاص بالاوامر الخاصة بكل درس.
او ربما طريقتي هي الخاطئة، وكان ينبغي ان اشرح بطريقة الsyntax أولاً بدلاً من الconcepts أولاً. إن معلم الموسيقى يقضي وقتا طويلا في البداية يدربك على كل نغمة على حدى، وكذلك معلم الكاراتيه يدربك على نفس الحركة مئات المرات قبل ان تعرف اصلاً كيف تستخدمها في القتال.
ينبغي إجراء تجارب اخرى من دروس مبنية على تمارين مكثفة على الاوامر قبل التفكير في البرامج، مع تسجيل الملاحظات.
3- دائماً هناك مشكلة في امر اقرأ والمتغيرات. اولاً: كلمة "متغير" تمرّ دائماً من اذن وتخرج من الاخرى. هناك مصطلحات اكثر ثباتاً من "متغير": حين اقول انها اسماء فإن الامر يكون مقبولاً، وحين اضرب امثلة مثل "تيكيت مكتوب على الصندوق المخزن فيه قيمة" فإن وجه الشبه ليس دائماً مستخدما عملياً (اقصد استخدام تشبيه التيكيت في تحليل سلوك البرنامج) لكن على الاقل التشبيه نفسه مفهوم.
لا احب كلمة متغير كثيراً...إنها تركز على صفة جانبية (انه يمكن أن يتغير) بينما الاهمية الكبرى للمتغير انه اسم يدل على قيمة.
في الfunctional programming، يطلقون على هذا النوع من المتغيرات name bound to a cell..أي ان الاسم - الثابت - يشير إلى موضع تخزين، لكن من الممكن ان اغير ما اخزنه في ذلك الموضع. يعني من الآخر اخذوا تشبيه "اسم على صندوق" وجعلوه مصطلحاً علمياً رسمياً. هذا افضل؛ سأحاول تجنب موضوع "المتغير" بعد ذلك.
يلاحظ هنا كيف تفيد خبرة الشخص البرمجية في التعليم: إن افضل معلم برمجة في نظري هو شخص يعرف لغات كثيرة متنوعة، ويقدر على كتابة compiler متى شاء، ويفهم في علم لغات البرمجة PLT. لذلك يجدني الناس احثهم حثاً على هذه العلوم لأن دورها اكبر بكثير في نهضة المجتمع مما يبدو.
أيضاً في هذه الكود فإن القطعة البرمجية "أ" لها معنيان:
اقرأ أ
اطبع "مرحبا يا "، أ
المعنى الأول أن "أ" هو مكان التخزين الذي يجب ان تضع فيه ما قرأته من المستخدم. المعنى الثاني هو القيمة المخزنة في مكان التخزين هذا. بصورة رسمية اكثر، المعنى الأول memory address والثاني memory content. هناك لغات مثل لغة لوجو تميز نحوياً بين المعنيين:
"أ
... معناها المتغير نفسه
:أ
... معناها القيمة المخزنة فيه.
المشكلة اني لا اريد عمل هذا في كلمات لأنها مصممة لتكون سهلة للاطفال لكن قوية بما يكفي ليمكن عمل برامج قوية/تجارية بها، فلابد ان تشبه إلى حد ما اللغات التقليدية. ربما يمكنني عمل لغة "Kalimat mini" للاطفال فقط وتكون اسهل في التعلم. سأفكر.
ملاحظة اخرى: يبدو ان الافضل اعطاء المتغيرات اسماء مجردة مثل "أ"، "س"، بدلا من اسماء ذات معنى مثل "الاسم" أو - وهذه مشكلة كبيرة - "سامح" أو "كريم" ..هذا يؤدي دائماً للبس بين اسم المتغير ومعناه.
المفاجأة هي أنه - على ما يبدو - الاطفال اقدر مما تخيلت على التعامل مع التجريد. مثلاً حين كنت اشرح الامر أ=12 قلت ان أ هو اسم، وان 12 هو المسمى، أي الشيء الذي هذا اسمه. وجدت الامر مقبولاً وكنت استخدم كلمة "مسمى" بحريّة بعد ذلك.
إننا نتكلم هنا عن العلاقة العكسية..أي فكرة ان مثلاً مخدوم فلان هو الشخص الذي يخدمه فلان. إن العلماء يدركون تجريبيا النطاق العمري الذي يقدر الاطفال فيه على فهم هذه العلاقة وامثالها (انظر نظريات Piaget في مراحل التطور الفكري للطفل) ولابد ان يستفاد من هذه النظريات في وضع المناهج للاطفال، برمجية كانت او لا.
ايضاً مثال لقدرة الاطفال على التجريد: انني في النهاية قمت بعمل رسمة للذاكرة بعمودين: عمود للاسم وعمود للمسمى، وعند عمل trace للبرنامج استخدمته كنموذج للذاكرة ولشرح الsemantics الخاص بالاوامر: امر اقرأ أ يأخذ قيمة من المستخدم، ويكتبها بحيث تكون أ في العمود الأول والقيمة المقروءة في العمود الثاني. عند استخدام "أ" في امر اطبع يبحث عنها في العمود الأول حتى يجدها، ثم يأخذ ما بالعمود الثاني ويطبعه. كان لديّ بعض التوفيق في هذا.
نقطة اخيرة، انني استخدمت هذا التشبيه بتوفيق كبير: "تخيل انني قد وضعت علامة - × على عمود نور مثلا - في الشارع واتفقت مع شخصين..الأول سيأخذ الجاموسة ويربطها بجانب هذه العلامة. أما الآخر فقلت له أن يذهب لتلك العلامة وحين يجد شيئاً مربوطاً هناك يأخذه ويذبحه".
ضربت هذا المثل لأوضّح لماذا كان ينبغي استخدام نفس المتغير في السطرين في برنامج "اقرأ كذا/اطبع مرحبا يا كذا"، وصار الامر هكذا واضحاً جداً!
إن الشخص الاول لا يعرف ماذا سيحدث للجاموسة، فقط يعرف اين يتركها، بينما الثاني لا يعرف ما سيجد حين يصل للعلامة: قد تكون جاموسة او ماعز او خروف، لكن سيعرف ماذا سيفعل بها، وكان لابد من قائد، مخطط ، مبرمج، هو الذي يربط بين الشخصين عن طريق العلامة الثابتة. هذه هي فكرة البرمجة كلها تقريباً.
في بداية طرحي للمثال كانت العلامة هي عمود النور نفسه، لكن الطفل الذي كنت اعلمه اقترح أن تكون علامة × على احد العواميد لتمييز اي عمود هو. هذا تشبيه ادق لفكرة "اسم المتغير"، أليس كذلك؟ :)