بالأمس أصدرت مؤسسة Mozilla النسخة 3.5 من المتصفح الشهير Firefox
و من الظريف الذي جعلني أكتب هذه السطور، أنك تستطيع أن ترى معدل التحميل لحظيا في العالم كله.
الأربعاء، يوليو 01، 2009
إصدار Firefox 3.5
بالأمس أصدرت مؤسسة Mozilla النسخة 3.5 من المتصفح الشهير Firefox
و من الظريف الذي جعلني أكتب هذه السطور، أنك تستطيع أن ترى معدل التحميل لحظيا في العالم كله.
السبت، يونيو 20، 2009
لماذا البرمجة الوظيفية (الجزء 2)
توقفت في الجزء الأول عند ترجمة المقدمة لـ "Why Functional Programming Matters". في هذا الجزء أكمل الترجمة:
مشابهة مع البرمجة الهيكلية "structured programming":
لعله يساعدنا على فهم الموضوع رسم مقارنة بـ "البرمجة الهيكلية". في الماضي، أختصرت صفات و مميزات البرمجة الهيكلية بالتالي: إنها لا تحتوي على تعليمات goto. أجزاء البنامج blocks ليس لها مداخل و مخارج متعددة. و البرامج الهيكلية يمكن تتبعها رياضيا أسهل من غيرها. هذه الميزات تشبه كثيرا ميزات البرمجة بالدوال.
الأن، و من خلال تجربتنا مع البرمجة الهيكلية يمكننا أن نقول أن هذه الخواص مع أهميتها، ليست هي ما جعل البرمجة الهيكلية ناجحة. صلب الموضوع و الفارق الأساسي بين البرنامج الهيكلي و غير الهيكلي، هو أن البرنامج الهيكلي مصمم من عدة وحدات برمجية منمذجة. هذا التصميم يعطينا مميزات في سرعة الإنتاج. أولا، الوحدات البرمجية الصغيرة يمكن برمجتها بسرعة و سهولة. ثانيا، يمكننا إعادة استخدام وحدات برمجية عامة في عدة برامج. ثالثا، يمكننا إختبار هذه الوحدات بمعزل عن البرنامج ككل، و هذا يوفر علينا الكثير من وقت الإختبار.
عدم وجود "goto" في اللغة، ليس هو العامل الرئيسي. صحيح أنها تساعد في نطاق سطور قليلة أو حتى عدة دوال، في المقابل، البرمجة الهيكلية تساعد في صحة البرنامج و جودته في النطاق الأوسع. لذا فإن البرمجة الهيكلية يمكن الإستفادة منها بغظ النظر عن اللغة المستعملة، سواء كانت FORTRAN أو Assmbly
الأن كثير من اللغات تتمتع بخصائص تساعد على البرمجة الهيكلية من حيث تقسيم البنامج إلى وحدات مصممة "Modular design" . ومع ذلك، هناك نقطة هامة جدا غالبا ما تنسى. عند كتابة برنامج منمذج في حل مشكلة ما، ربما يجزء أحدهم المشكلة إلى مشاكل جزئية أصغر و أبسط، ثم يحلها و يجمع بين الحلول. الطرق التي يمكن للمرء أن يجزء بها المشكلة الأصلية تعتمد مباشرة على الطرق التي يمكن للمرء أن يجمع بها حلول الأجزاء معا. لذلك، من أجل زيادة قدرة المبرمج على تجزئة مشكلة ما من الناحية النظرية، لا بد من توفير أنواع جديدة من طرق الجمع (الغراء) في لغة البرمجة. ما هو موجود حاليا من قواعد معقدة لتحديد نطاق المعلومات (information locality) و توفير إمكانة ترجمة الوحدات منفصلة (unit of compilation) تساعد فقط في تفاصيل سطحية، و لا توفر أساليب جديدة في مفهوم حلحلة المشاكل. يمكن للمرء أن يقدر أهمية الغراء عن طريق القياس على النجارة.
يمكن بسهولة تامة صنع كرسي من أجزاء -- قاعدة وسيقان وظهر الخ -- وجمعهم مع بعضهم البعض بالطريق الصحيحة. لكن هذا يتوقف على قدرة النجار على صناعة المفاصل وغراء الخشب. عندما نفتقر إلى هذين العاملين، فإن الطريقة الوحيدة لصنع كرسي هو نحته كاملا من قطعة واحدة من الخشب، وهو أمر أصعب بكثير. هذا المثال يوضح كلا من الإمكانيات الهائلة التي توفرها فكرة تجزئة المشاكل وأهمية وجود الغراء.
فلنعد الآن للبرمجة بالدوال. في ما تبقى من هذه الورقة سنناقش أن لغات الدوال توفر نوعين جديدين و مهمين من الغراء. وسنعطي أمثلة كثيرة من البرامج التي يمكن تجزئتها بطرق جديدة، و بالنتيجة تبسيط البرنامج إلى حد كبير. هذا هو المفتاح لقوة البرمجة بالدوال -- إنها تتيح طرقا جديدة للتجزئة. وهذا هو الهدف الذي يجب أن ينشده المبرمجين -- وحدات برمجية جزئية عامة أكثر و أصغر و أبسط، جنبا إلى جنب مع أساليب الغراء الجديدة التي ستوصف تاليا.
مشابهة مع البرمجة الهيكلية "structured programming":
لعله يساعدنا على فهم الموضوع رسم مقارنة بـ "البرمجة الهيكلية". في الماضي، أختصرت صفات و مميزات البرمجة الهيكلية بالتالي: إنها لا تحتوي على تعليمات goto. أجزاء البنامج blocks ليس لها مداخل و مخارج متعددة. و البرامج الهيكلية يمكن تتبعها رياضيا أسهل من غيرها. هذه الميزات تشبه كثيرا ميزات البرمجة بالدوال.
الأن، و من خلال تجربتنا مع البرمجة الهيكلية يمكننا أن نقول أن هذه الخواص مع أهميتها، ليست هي ما جعل البرمجة الهيكلية ناجحة. صلب الموضوع و الفارق الأساسي بين البرنامج الهيكلي و غير الهيكلي، هو أن البرنامج الهيكلي مصمم من عدة وحدات برمجية منمذجة. هذا التصميم يعطينا مميزات في سرعة الإنتاج. أولا، الوحدات البرمجية الصغيرة يمكن برمجتها بسرعة و سهولة. ثانيا، يمكننا إعادة استخدام وحدات برمجية عامة في عدة برامج. ثالثا، يمكننا إختبار هذه الوحدات بمعزل عن البرنامج ككل، و هذا يوفر علينا الكثير من وقت الإختبار.
عدم وجود "goto" في اللغة، ليس هو العامل الرئيسي. صحيح أنها تساعد في نطاق سطور قليلة أو حتى عدة دوال، في المقابل، البرمجة الهيكلية تساعد في صحة البرنامج و جودته في النطاق الأوسع. لذا فإن البرمجة الهيكلية يمكن الإستفادة منها بغظ النظر عن اللغة المستعملة، سواء كانت FORTRAN أو Assmbly
الأن كثير من اللغات تتمتع بخصائص تساعد على البرمجة الهيكلية من حيث تقسيم البنامج إلى وحدات مصممة "Modular design" . ومع ذلك، هناك نقطة هامة جدا غالبا ما تنسى. عند كتابة برنامج منمذج في حل مشكلة ما، ربما يجزء أحدهم المشكلة إلى مشاكل جزئية أصغر و أبسط، ثم يحلها و يجمع بين الحلول. الطرق التي يمكن للمرء أن يجزء بها المشكلة الأصلية تعتمد مباشرة على الطرق التي يمكن للمرء أن يجمع بها حلول الأجزاء معا. لذلك، من أجل زيادة قدرة المبرمج على تجزئة مشكلة ما من الناحية النظرية، لا بد من توفير أنواع جديدة من طرق الجمع (الغراء) في لغة البرمجة. ما هو موجود حاليا من قواعد معقدة لتحديد نطاق المعلومات (information locality) و توفير إمكانة ترجمة الوحدات منفصلة (unit of compilation) تساعد فقط في تفاصيل سطحية، و لا توفر أساليب جديدة في مفهوم حلحلة المشاكل. يمكن للمرء أن يقدر أهمية الغراء عن طريق القياس على النجارة.
يمكن بسهولة تامة صنع كرسي من أجزاء -- قاعدة وسيقان وظهر الخ -- وجمعهم مع بعضهم البعض بالطريق الصحيحة. لكن هذا يتوقف على قدرة النجار على صناعة المفاصل وغراء الخشب. عندما نفتقر إلى هذين العاملين، فإن الطريقة الوحيدة لصنع كرسي هو نحته كاملا من قطعة واحدة من الخشب، وهو أمر أصعب بكثير. هذا المثال يوضح كلا من الإمكانيات الهائلة التي توفرها فكرة تجزئة المشاكل وأهمية وجود الغراء.
فلنعد الآن للبرمجة بالدوال. في ما تبقى من هذه الورقة سنناقش أن لغات الدوال توفر نوعين جديدين و مهمين من الغراء. وسنعطي أمثلة كثيرة من البرامج التي يمكن تجزئتها بطرق جديدة، و بالنتيجة تبسيط البرنامج إلى حد كبير. هذا هو المفتاح لقوة البرمجة بالدوال -- إنها تتيح طرقا جديدة للتجزئة. وهذا هو الهدف الذي يجب أن ينشده المبرمجين -- وحدات برمجية جزئية عامة أكثر و أصغر و أبسط، جنبا إلى جنب مع أساليب الغراء الجديدة التي ستوصف تاليا.
السبت، يونيو 13، 2009
لماذا البرمجة الوظيفية (الجزء 1)
إبتداءا أرى أن الترجمة للمصطلح "functional programming" بـ "البرمجة الوظيفية" غير موفقة. إذ و حسب ويكيبيديا، فإن إشتقاق المسمى جاء من المعنى المستخدم في علم الرياضيات "Function" المعرب بأسم "الدالة". و لهذا المعنى دلالته التى لا تنتقل باستخدام الترجمة الحالية.
إذا رجعنا إلى تاريخ علم الحوسبة فإنا نجد أن اللبنة الأساس لـ "البرمجة الوظيفية" أو "طريقة البرمجة بالدوال" (من الان و خلال الموضوع سوف أستخدم التسمية الثانية) هي "نظرية حساب الامبدا λ" أو "lambda calculus" و هي نظرية رياضية تجريدية لا تهمنا تفاصيلها في فهم الموضوع.
أول لغة أستخدمت هذا الأساس النظري هي لغة LISP و هي ثاني أقدم لغة برمجة من المستوى الرفيع بعد لغة الـ FORTRAN، و تأسست عام 1958.
من اللغات المعروفة بهذا النوع أيضا (للمثال و ليس الحصر):
و قريبا سوف تصدر Microsoft ضمن Visual Studio 2010 لغة مبنية على نسق لغة Ocaml ل إطار .NET أسمتها بـ #F.
من تتبع أخبار البرمجة يلاحظ تنامي أهمية هذه الطريقة في البرمجة, خصوصا في زمن المعالجات المتعددة النوى. و حتى إن لم و لن تستخدم ايا من هذه اللغات للبرمجة، فإن فهم الطريقة سيوسع من أفق الرؤية في البرمجة عموما.
حسنا، بعد هذه المقدمة، ما يلي هي ترجمة بتصرف لورقة بحث صدرت عام 1984 معنونة بـ "لماذا البرمجة بالدوال تهم" "Why Functional Programming Matters" :
"
المقدمة
هذه الورقة تستعرض مدى أهمية البرمجة بالدوال و أيضا لتساعد مستعملي البرمجة بالدوال لاستغلال كل ميزات هذه الطريقة من خلال تبيين ماهيتها. سميت هذه الطريقة بالبرمجة بالدوال لأن البرنامج يتكون كليا من دوال. و يمكننا في الواقع القول أن البرنامج هو بمجمله دالة تأخذ المدخلات كمعطى للدالة و تكون قيمة الدالة هي النتيجة. عادة الدالة الرئيسية تعرف بدوال أخرى و تلك بدورها تعرف بدوال أخرى إلى أن نصل إلى دوال أصيلة في اللغة. هذه الدوال هي كالدوال المعروفة في الرياضيات.
الأمثلة في هذه الورقة ستستخدم لغة Miranda و لكنها ستكون بسيطة بحيث أنها لا تتطلب معرفة باللغة لفهمها.
الخواص المميزة للبرمجة بالدوال يمكن اختصارها بالتالي. البرامج ليس فيها جمل تعيين "assignment statements" , لذلك فإن المتغيرات لا تتغير قيمتها أبدا. و بمعنى أعم فإن البرمجة بالدوال ليس فيها "أثار جانبية" "side-effects" . استدعاء دالة لا يؤدي إلى أي تغيير عدا حساب نتيجة الدالة. هذه الخاصية تلغي تماما مصدرا رئيسيا من مصادر الأخطاء "bugs" و تجعل ترتيب التشغيل "order of execution" غير مهم، حيث أنه ليس هناك تأثير جانبي لأي دالة فإن نتيجة الدوال مربوطة بمعطياتها فقط و ليس للترتيب أي أثر. هذا يزيل عن كاهل المبرمج العمل على التحكم في سير البرنامج. و من فوائد انعدام التأثيرات الجانبية، إمكانية التبديل بين أي "تعبير" "expression" و قيمته أو العكس و هذا ما يسمى بـ "الشفافية المرجعية" "referential transparency" . هذه الحرية تجعل المعالجة الرياضية للبرنامج أسهل من غيرها.
حسنا، بعد كل هذا كل ما عرفناه هو ما ليس موجود في البرمجة بالدوال (لا تعيين، لا أثار جانبية، لا تحكم بالسير) لكن ما هي البرمجة بالدوال؟
- يتبع ...
إذا رجعنا إلى تاريخ علم الحوسبة فإنا نجد أن اللبنة الأساس لـ "البرمجة الوظيفية" أو "طريقة البرمجة بالدوال" (من الان و خلال الموضوع سوف أستخدم التسمية الثانية) هي "نظرية حساب الامبدا λ" أو "lambda calculus" و هي نظرية رياضية تجريدية لا تهمنا تفاصيلها في فهم الموضوع.
أول لغة أستخدمت هذا الأساس النظري هي لغة LISP و هي ثاني أقدم لغة برمجة من المستوى الرفيع بعد لغة الـ FORTRAN، و تأسست عام 1958.
من اللغات المعروفة بهذا النوع أيضا (للمثال و ليس الحصر):
و قريبا سوف تصدر Microsoft ضمن Visual Studio 2010 لغة مبنية على نسق لغة Ocaml ل إطار .NET أسمتها بـ #F.
من تتبع أخبار البرمجة يلاحظ تنامي أهمية هذه الطريقة في البرمجة, خصوصا في زمن المعالجات المتعددة النوى. و حتى إن لم و لن تستخدم ايا من هذه اللغات للبرمجة، فإن فهم الطريقة سيوسع من أفق الرؤية في البرمجة عموما.
حسنا، بعد هذه المقدمة، ما يلي هي ترجمة بتصرف لورقة بحث صدرت عام 1984 معنونة بـ "لماذا البرمجة بالدوال تهم" "Why Functional Programming Matters" :
"
المقدمة
هذه الورقة تستعرض مدى أهمية البرمجة بالدوال و أيضا لتساعد مستعملي البرمجة بالدوال لاستغلال كل ميزات هذه الطريقة من خلال تبيين ماهيتها. سميت هذه الطريقة بالبرمجة بالدوال لأن البرنامج يتكون كليا من دوال. و يمكننا في الواقع القول أن البرنامج هو بمجمله دالة تأخذ المدخلات كمعطى للدالة و تكون قيمة الدالة هي النتيجة. عادة الدالة الرئيسية تعرف بدوال أخرى و تلك بدورها تعرف بدوال أخرى إلى أن نصل إلى دوال أصيلة في اللغة. هذه الدوال هي كالدوال المعروفة في الرياضيات.
الأمثلة في هذه الورقة ستستخدم لغة Miranda و لكنها ستكون بسيطة بحيث أنها لا تتطلب معرفة باللغة لفهمها.
الخواص المميزة للبرمجة بالدوال يمكن اختصارها بالتالي. البرامج ليس فيها جمل تعيين "assignment statements" , لذلك فإن المتغيرات لا تتغير قيمتها أبدا. و بمعنى أعم فإن البرمجة بالدوال ليس فيها "أثار جانبية" "side-effects" . استدعاء دالة لا يؤدي إلى أي تغيير عدا حساب نتيجة الدالة. هذه الخاصية تلغي تماما مصدرا رئيسيا من مصادر الأخطاء "bugs" و تجعل ترتيب التشغيل "order of execution" غير مهم، حيث أنه ليس هناك تأثير جانبي لأي دالة فإن نتيجة الدوال مربوطة بمعطياتها فقط و ليس للترتيب أي أثر. هذا يزيل عن كاهل المبرمج العمل على التحكم في سير البرنامج. و من فوائد انعدام التأثيرات الجانبية، إمكانية التبديل بين أي "تعبير" "expression" و قيمته أو العكس و هذا ما يسمى بـ "الشفافية المرجعية" "referential transparency" . هذه الحرية تجعل المعالجة الرياضية للبرنامج أسهل من غيرها.
حسنا، بعد كل هذا كل ما عرفناه هو ما ليس موجود في البرمجة بالدوال (لا تعيين، لا أثار جانبية، لا تحكم بالسير) لكن ما هي البرمجة بالدوال؟
- يتبع ...
الاشتراك في:
الرسائل (Atom)