السبت، 31 مارس 2012

كلمات والاطفال: بعض النتائج التجريبية

هناك تجربة تكررت مع طفلين في نفس السن تقريباً (9، 10). حدثتا في ظروف متشابهة، ولعل من المفيد أن احكيهما للإفادة. حفاظاً على الخصوصية لن اذكر مع من جربت، لكن ظروف التجربة كانت كالآتي:
  • لم تكون دروساً منتظمة بل على فترات متباعدة (ولعل هذا هو السبب الاساسي في المشاكل التي حدثت).
  • كنت اعلمهم شفاهة بلا مرجع مكتوب.
  • لكن كل منهما كان لديه نسخة مطبوعة من كتاب تحقيق الذات في كتابة البرمجيات.
لم تكن التجارب بمنهج علمي (many free variables, no control group, insufficient sampling) لكني ارى المعلومات مفيدة جداً.
كان المثال الذي احاول شرحه دائماً هو برنامج "التحية"، الذي يسأل المستخدم عن اسمه ثم يرد بقول "مرحباً يا فلان". وفي الحالتين كانت نفس المشاكل تكرر نفسها.

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 الخاص بالاوامر: امر اقرأ أ يأخذ قيمة من المستخدم، ويكتبها بحيث تكون أ في العمود الأول والقيمة المقروءة في العمود الثاني. عند استخدام "أ" في امر اطبع يبحث عنها في العمود الأول حتى يجدها، ثم يأخذ ما بالعمود الثاني ويطبعه. كان لديّ بعض التوفيق في هذا.

نقطة اخيرة، انني استخدمت هذا التشبيه بتوفيق كبير: "تخيل انني قد وضعت علامة - × على عمود نور مثلا - في الشارع واتفقت مع شخصين..الأول سيأخذ الجاموسة ويربطها بجانب هذه العلامة. أما الآخر فقلت له أن يذهب لتلك العلامة وحين يجد شيئاً مربوطاً هناك يأخذه ويذبحه".

ضربت هذا المثل لأوضّح لماذا كان ينبغي استخدام نفس المتغير في السطرين في برنامج "اقرأ كذا/اطبع مرحبا يا كذا"، وصار الامر هكذا واضحاً جداً!

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

في بداية طرحي للمثال كانت العلامة هي عمود النور نفسه، لكن الطفل الذي كنت اعلمه اقترح أن تكون علامة × على احد العواميد لتمييز اي عمود هو. هذا تشبيه ادق لفكرة "اسم المتغير"، أليس كذلك؟ :)

هناك 4 تعليقات:

root3 يقول...

حاجة كمان:

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

مع انه ممكن اللي بيشرح يكون شايف انه التكرار ده نوع من الملل، و هيكرّه الطفل في المعلومة .. بس العكس كان بيحصل، يمكن كنت بجرب مع أطفال نسبة ذكاءهم منخفضة D:
ممكن أغير الـ sample في المستقبل و اشوف النتيجة :]

---
عجبني مثال عمود النور جداااااا (Y)

Mohamed Samy يقول...

لم اذكر هذا في المقال، لكن التكرار والتنوع كانوا بالفعل سلاحاً قوياً (والاطفال الذين جربت معهم كانوا اذكياءً، ما شاء الله). ربما هي مسألة انتباه اكثر منها ذكاء.

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

Issam Elbaytam يقول...

AA
It's not easy for me to relate to the arabic terms as you use in the language, somehow in English they seem more natural, may be because I am so used to them, I have not read formal arabic in a long time.

Anyway, as I read the keywords I thought a more natural way to say "Read" would be "Ask For" and I thought that it would be more natural to use better naming for the variables.

Something like Ask For PersonName
Print PersonName
I am thinking that child would understand that he is instructing the program to ask for a value from the user not "read" a value from the user.

I am no expert just a quick reaction to reading the article.

Have you thought about asking them to act out the program. Ask one child to program another child by giving him instructions.

Mohamed Samy يقول...

@Issam

WAS,

I do think the keyword "read" is confusing, and I did think about replacing it with "ask", the problem is that I want Kalimat to be suitable for both children and professionals and "ask" screams "educational language" to the user...

Yes, the actual keyword is meaningless since they're all mere symbols to the compiler, but perception & culture matter a lot.

In a world where programmers prefer C++ because it's more 'hardcore' a lot of people would ignore Kalimat instead of spread it around once they perceive it as a toy language.

Maybe I could create a "Kalimat Mini" version better suited to education, as I've said :)