الأربعاء، 30 نوفمبر، 2011

أنا آسف يا KDE ^_^


ما حدث لي في اليومين السابقين يستحق التسجيل بكل الوسائل الممكنة؛ فقد كانا مليئين بالمفاجئات الغريبة للغاية، و كذا كانا مليئين بالإحباطات و السخافات التي تجعلني أكاد أنتزع وَرِيدَيْ عنقي بأسناني كمداً :)

حسنٌ: فلنبدأ بالسرد بالترتيب:
أولاً: تعرفون جميعاً أنني اتخذت قراراً ثورياً بتغيير واجهة الـKDE التي أحبها للغاية و أعتقد أنها الأفضل بلا منازع، و ذلك رغم أنني لا أحب تغيير نظام التشغيل المستقر علي الإطلاق؛ و لكن السبب الذي جعلني أفكر في هذا بمنتهي الجدية: أن الـKDE ضعيفةٌ للغاية من ناحية الاستقرار و الثبات، و كثرة الانهيارات في برامجها تكاد تطيح بصوابي.
و أول الأمور الغريبة التي حدثت لي البارحة: أنني كنت في زيارةٍ قصيرةٍ لصديقٍ لي في قريتنا، و بعد أن أنهيت الزيارة و وصلت إلي منزلي: فتحت حاسوبي و ولجت إلي الشبكة، و هنا لاحظت أن سرعة التحميل كبيرةٌ بصورةٍ واضحةٍ (بل و مريبة ^_^)، فما كان مني إلا أن ألقيت نظرةً علي سرعة الاتصال، و هنا فوجئت بها تتعدي الخمسين كيلو بايت في الثانية (في حين أن اشتراكي لا يكفل لي إلا سرعةً أقصاها 10 ك.ب/ث ! و في العادة تكون 4 ك.ب/ث !)، بالطبع لم أصدق عيني و أرجعت البصر كرتين و أكثر: فوجدت السرعة تصل إلي 120 ك.ب/ثانية !
و هنا قررت أن أصدق ^_^ و أن أغتنم الفرصة التي لن تتكرر مرةً ثانيةً بالتأكيد، و بسرعةٍ ولجت إلي صفحة تحميل توزيعة ubuntu في إصدارها الجديد 11.10 و قمت بالفعل بالبدء بالتحميل، و لدهشتي وصلت سرعة التحميل في بعض الأحيان إلي أكثر من 200 ك.ب/ثانية !

و هكذا بعد أقل من ساعةٍ و نصف كانت لدي صورة ISO من التوزيعة الحديثة !، فقمت باستعمال برنامج unetbootin (و هو برنامج يجعل من الممكن تنصيب توزيعات القنو/لينوكس باستخدام ذاكرة الفلاش) و وضعت التوزيعة علي الفلاشة الخاصة بي، ثم قمت بمحاولة تنصيب التوزيعة من الفلاشة، و لكن التنصيب فشل ! و بتكرار المحاولة فهمت أن البرنامج لم يتعامل مع التوزيعة الجديدة كما يجب، فقمت باستعمال برنامج start up desck creator و الذي نجح في التعامل الصحيح مع التوزيعة، فقمت بتنصيبها.

و الجدير بالذكر أن الـKDE أخرجت لي رسالة خطأٍ حينما أعدت تشغيل الجهاز لتنصيب الـubuntu و كأنها تأبي إلا أن تهديني انهياراً أخيراً قبل الوداع ^_^

لكن المهم أنني ما إن انتهيت من تنصيب ubuntu حتي وجدت الهول ذاته؛ فقد نظرت في البرامج التي تم تنصيبها مع التوزيعة تلقائياً فوجدتها قليلة العدد للغاية علي عكس ما هو موجودٌ في باقي التوزيعات المشهورة و الأقل شهرةً من ubuntu !
و لا تظنوا أن ذلك راجعٌ لكون النسخة التي استخدمتها كانت علي قرص ضوئي 700 ميقا؛ فقد جربت توزيعاتٍ أخري مثل PclinuxOS علي أسطوانة 700 ميقا فوجدتها أغني من ناحية عدد البرامج المدمجة معها !
و لكني رضيت بقضاء الله تعالي و عزيت نفسي بأنه يمكنني أن أنصب تلك البرامج التي أحتاجها فيما بعد، لكن المصيبة أنني حينما حاولت معرفة سرعة الاتصال بالشبكة كما أفعل في الـKDE بنظرةٍ بسيطة: فوجئت بأن البريمج الخاص بذلك في ubuntu لا يسمح لي بهذا، علي عكس ما هو موجودٌ في الـKDE:

و للأسف حاولت تصوير القائمة المماثلة في ubuntu فلم أستطع ذلك !
ثم جاءت الطامة الثانية حينما حاولت تنصيب برنامج متصفح الملفات dolphin الذي أحبه في واجهة الـKDE و لا أقبل باستخدام برنامجٍ أقل قوةً منه، و كانت المصيبة أنه غير موجودٍ في مستودعات التوزيعة ! هذا رغم أن برنامج مركز البرمجيات تَعَرف عليه و علي وظيفته حينما كتبت اسمه للبحث عنه و تنصيبه ! 

ثم أتت القاضية حينما حاولت تنصيب بيئة الـNetbeans التي أستخدمها في البرمجة فلم يتعرف عليها البرنامج من الأصل !

و هنا قررتُ أنه لم يعد في قوس الصبر منزع، و أن اللعنة علي إن ظلت هذه التوزيعة الحمقاء دقيقةً واحدةً علي حاسوبي ^_^

فقمت باستخدام برنامج start up desck creator لوضع توزيعة kubuntu 11.04 علي الفلاشة، و ما إن أتم الأخير مهمته حتي قمت بتنصيب الـkubuntu مع بعض التحديثات، و رقص قلبي فرحاً حينما رأيت شاشة البدء الخاصة بواجهة الـKDE، صحيحٌ أنها (تلك الحمقاء) حيتني بحماسةٍ بإظهار رسالة انهيار ! إلا أن هذا كان الطابع المعتاد علي كل حال.
لكن الأمور لم تسر علي ما أحب بعد ذلك؛ فقد أصاب الـKDE تجمدٌ متكررٌ freezing علي سبيل التحية الزائدة عن الحد لي لعودتي مرةً أخري إليها !
و بينما تتزايد عصبيتي و يتعملق توتري و أنا أحاول إصلاح الأمور، أتت ابنةُ خالٍ لي صغيرةُ السن (9-10 أعوام) لكي أساعدها علي مذاكرة درسها ! فاستعنت بالله تعالي علي نوازل القدر، و أخذت أحاول مساعدتها و أنا أراقب الـKDE بنصف عينٍ و نصف عقلٍ لأري هل عادت إلي السلوك الطبعي أم لا.
و بينما أحاول إفهام الصغيرة بعض السخافات من كتاب ٍ مدرسي، رأيت أخوها الذي يكبرها بعامين أو ثلاثة يدلف إلي حجرتي بدوره، فقلت لنفسي: مرحي يا وائل الآن يبدأ السيرك في العمل :) و سألت الفتي عن سبب تشريفه لي بالزيارة، فطلب مني أن أساعده في البحث عن شيئٍ ما علي الشبكة لواجبٍ مدرسي مطلوبٍ منه، و هكذا تمكنت من ضبط أعصابي بمعجزةٍ حقيقيةٍ لأخرجه و أخته من غرفتي و أنا أتعجب كيف يتحمل الناس سخافات صغارهم؛ فلو كان هذان طفلاي لكنت الآن أحتسي الخمر في خمارةٍ قذرةٍ و أنا أتسلي بتسليك أسناني بمطواة جميلة الشكل و أعد مغانم آخر سطوٍ مسلحٍ لي ^_^
المهم: أنني تمكنت من الرجوع إلي الحاسوب (أخيراً) لمحاولة حل المشاكل التي تنتظرني، و لمحاولة إعادة الأمور إلي سابق عهدها قبل أن أُنَصب ubuntu، و هكذا سيكون علي أن:
أقوم بتنصيب الـfirefox،
و تكملة دعم اللغة العربية،
و تنصيب الـJDK ثم الـnetbeans،
و في النهاية يمكنني أن أمرح قليلاً بضبط إعدادت الـKDE كما كانت عليه من قبل.



أخيراً و بعد هذه التجربة المرهِقة الجيدة: يمكنني أن أُدرج النقاط التالية كأمورٍ مفروغٍ منها بالنسبة لي:
  1. ما يحدث في عالم القنو/لينوكس أمرٌ هزلي بما لا يقاس؛ فكيف أوضع في موقفٍ كالتالي: 
    إذا أردت الجمال و القوة فعليك بالتضحية بالثبات و الاستقرار، و إذا أردت الاستقرار فعليك التعود علي الضعف و البساطة التي تصل إلي حد التفاهة.
    ثم يكون متوقعاً مني أن أترك عالم الويندوز المريح إلي هذه الفوضي !
    صحيحٌ أن نظام الويندوز ضعيفٌ للغاية من الناحية الأمنية، كما أنه غير مجاني بل و باهظ الثمن، و الأغلبية الساحقة من برامجه غير مجانية: و لكن الذي لا يمكن إنكاره أنه أفضل (من ناحية الإمكانيات) من واجهاتٍ مثل الـGnome و الـunity (سواءٌ أكان هذا بسبب البرامج الكثيرة التي تضيف له إمكانياتٍ لم تكن موجودةً من الأصل، أو كان هذا بسببب إمكاناتٍ تُعَد جزءاً أصيلاً منه)، و في نفس الوقت هو أقل من الـKDE من ناحية الإمكانيات و كذلك الناحية الجمالية، و لكنه بالتأكيد أفضل بكثيرٍ من ناحية الاستقرار (و أقول كل هذا عن تجارب لي مع كل ما ذكرت من أنظمةٍ و واجهات).
    و أنا أقول عن اقتناعٍ قويٍ للغاية: لو كان الويندوز مجانياً، أو علي الأقل يباع بثمنٍ في متناول يدي لاشتريته بدون إبطاء، و لسرت معه أينما حلت ركائبه !

  2. بعد التجارب المؤلمة السابقة: أدركت أن ما يفعله كثيرٌ من مستخدمي القنو/لينوكس من التندر علي مستخدمي الويندوز بسبب ضعف إمكاناته و عدم استقراره و إذاعة هذا وسط الجماهير يُعَد إرهاباً فكرياً، و بخاصة إذا ما رأينا أن عالم القنو/لينوكس يعد عالماً كهنوتياً تسيطر عليه أفكارٌ أعدها بحماسٍٍ من الفئة التي تثير جنوني، مثل:
    • استخدام سطر الأوامر command line أمرٌ ممتع و مطلوب في "كل وقت" و في "كل حالة" !
    • الحمقي الذين يحبون تنصيب البرامج بـ(الضغط المزدوج double click علي البرنامج) يجب أن يتعلموا أن هذا هو حال الفتيات المدللات، بينما يجب علي الرجال أن يتعلموا أن ينصبوا البرامج من خلال عمل ترجمة compile لأكوادها، و أنه من العادي جداً أن تجلس أمام الحاسوب ساعةً أو ساعتين لتنصيب برنامجٍ واحدٍ لأن هناك حزمٌ و مكتباتٌ يعتمد عليها البرنامج و يجب أن يتم تثبيتها أولاً
      ثم إنه من تمام الرجولة و الفحولة عند المبرمجين أن تقوم بعمل بريمجات scripts بلغة الـshell script فائقة الجمال و البساطة للتعامل مع أي شيئ تريده في النظام، أما أولئك التافهون الحمقي الذين يصرخون أن مثل هذه الأمور كان يجب أن تكون بسيطةً سلسةً فهم (صدق أو لا تصدق) تافهون حمقي.

    • إن كانت الأمور الطبعية التي فاتت يعجز عنها المستخدم (لأنه أبلهٌ رقيع)، فيمكنه (عليه اللعنة) أن ينصب البرامج باستخدام مدير الحزم package manager، و لكن عليه أن ينتظر أولاً ضَمنَا لذلك البرنامج إلي المستودعات، ثم عليه أن يكون متصلاً بالشبكة طوال الوقت، و كذلك عليه أن يتقبل بصدرٍ رحبٍ (إذا حدث هذا) كون بلاده من البلاد التي تطبق عليها عقوباتٌ دولية (غربيةٌ بالطبع) مما يمنع تنصيبه لبرامجٍ كثيرة.
  3. علي التفكير جدياً في تأجيل مشروع زواجي حتي سن الخمسين: حيث سأكون وقتها (في الغالب) قد وصلت إلي كل ما أتمناه من علم، و أكون قادراً علي التفرغ لرعاية أولئك الأوغاد الصغار بدون المخاطرة بتهشيم رأس أحدهم عند أول حالةٍ من العصبية تسيطر علي ^_^

الاثنين، 28 نوفمبر، 2011

المفاضلة بين لغات البرمجة 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. عندما تبلغ اللغة حد التخمة و يكون هناك مكوناتٌ لابد من وجودها فى لغة البرمجة الجيدة لتلائم الأفكار الجديدة فى العمل البرمجى، أو عندما نحتاج إلى تغيير أحد الأفكار الرئيسة فى لغة البرمجة، أو حتى تكون هناك مكوناتٌ عفى عليها الزمن و يجب التخلص منها، فيجب علينا أن نفكر فى إنتاج لغة برمجةٍ جديدةٍ تستلهم الجيد الذى فى اللغة القديمة و تضع الجديد المرغوب فى ضمه محل القديم المرغوب فى تركه، و هذا يجعل تصميمَ اللغات أسهل، و تطورَها أكثر قابليةً للفهم، كما أنه يعطى للراغبين فى البرمجة باللغة على نفس الشكل القديم لها الفرصة لفعل ذلك، و لا يجبرهم على التغيير للشكل الجديد مادام الشكل الجديد قد صِيغ على شكل لغةٍ برمجيةٍ أخرى مختلفة لهم كل الحق فى التقرير لأنفسهم إن كانوا سيتعلمونها و يستخدمونها أم لا.

الأحد، 27 نوفمبر، 2011

حبيبتي الـKDE: أنتِ طالق ^_^

لمن لا يعرف ما هي الـKDE:

هي واحدةٌ من أشهر الواجهات المرئية لأنظمة التشغيل شبيهة اليونيكس UNIX-like، و هي بحق أجملها و أكثرها قوةً و تميزاً و نضجاً، و أكثرها قابلية للتخصيص و التغيير حسب مزاج المستخدم لها، و نظرةٌ واحدةٌ إلي برنامج متصفح الملفات dolphin يمكن أن تعطينا فكرةً عن قوة و نضج و شمولية برامجها:
 و كذلك اختيارات التعامل مع سطح المكتب:

و هو ما جعلني أحس (و ما زلت) أنها الواجهة التي حلمت بها و التي لا يمكن لغيرها تلبية رغباتي.

و بمقارنة هذا النضج بالواجهات الأخري مثل الـGnome و الـunity و الـLXDE و الـXFCE فسنجد أنه من الحمق أن نزعم أن هناك أي تقاربٍ في القوة و اتساع الاختيارات المتاحة في كل واجهة !
الغريب أنني بعد كل هذا المدح فيها أريد أن أتركها و أستخدم واجهةً أخري غيرها !

و السؤال المنطقي الآن الذي أثق أنكم تصرخون به في وجهي: و لماذا بالله عليك تريد ترك الـKDE أيها الأحمق الرقيع ؟!

حسنٌ: سأتغاضي عن السباب ^_^ و سأمثل لكم المسألة بمثالٍ مُوضحٍ مباشر:

فلنفترض أنك (عزيزي القارئ) متزوجٌ من فتاةٍ: جميلةٍ، رشيقةٍ، متدينةٍ، ودودٍ، ولود، فهل تظن أن مثل هذه الفتاة تُترك ؟

الآن فلنفترض أن لها عيباً واحداً: هو أنها بين لحظةٍ و أخري تقوم بالبصق علي الأرض بنفس احترافية و اعتياد المعلم (جارحي) في وكالة البلح !

في البداية: ستصبر عليها و تنبهها بابتسامةٍ خجلي إلي أن هذا لا يليق بفتاةٍ رقيقة مثلها،

ثم: ستنبهها في ضيقٍ أن الأمر يكاد يخرج عن السيطرة، و أن أرض المنزل توشك أن تصير زلقةً من فرط البصق عليها،

ثم: ستصرخ في وجهها كالمجنون و عيناك جاحظتان: أيتها الحمقاء، ألن تكفي عن هذا العته،

و بعدها: ستهشم رأسها علي أرض المنزل و أنت تضحك بجنون و الزَبَد يتطاير من بين شدقيك ^_^

و أنا أيضاً يحدث لي شيئٌ كهذا: فالعيب الوحيد لواجهة الـKDE هو كثرة حدوث الانهيارات crashes في برامجها، و هو ما ينبئ عن كونها لا تخضع لعملية اختبار test و تنقيح debug مكثفة كما يليق بواجهةٍ لها كل تلك الشعبية و القبول !

و لا يكاد يمر يوم دون أن أري نافذة إبلاغ عن خطأ مثل هذه (هي شبيهةٌ بها و ليست هي بالضبط):


و الغريب أنني أراها أحياناً في أوقات لا يُعقل و لا يُقبل أن يحدث فيها أي خطأ، فمثلاً ظهرت لي مراراً حينما قمت -أنا الآثم الرقيع- بضغط زر (إيقاف التشغيل shutdown) ! و أتذكر أنني في مرةٍ من تلك المرات قمت بضغط زر (إيقاف التشغيل) ثم ذهبت ببراءةٍ الأطفال إلي الحمام، و حينما عدت هالني مرأي تلك النافذة المستفزة، كانت هناك علي شاشة الحاسوب (الذي لم يستطع الإغلاق بسبب أني لم أضغط علي زر إغلاق نافذة التبليغ عن الخطأ) و كأنها تُخرج لي لسانها ^_^

و هكذا قررت أن أترك عالم الـKDE الغالي قبل أن أصل إلي مرحلة وضع الحلة علي رأسي ^_^

و لكن المشكلة الكبري: كيف سأستخدم أي واجهةٍ أخري بينما لا أقبل بنضجٍ أقل مما اعتدت عليه مع الـKDE ؟! و الحل الوحيد الذي أراه مقنعاً: أن أقوم بتنصيب واجهةٍ أخري، ثم أقوم بتنصيب برامج الـKDE التي اعتدت عليها و لا أستطيع تركها، و أهم هذه البرامج (و ربما الوحيد) هو برنامج dolphin، و هكذا أحظي باستقرار الواجهة و قوة و نضج متصفح الملفات.

و أغلب الظن أن الواجهة الجديدة ستكون الـGNOME التي كنت أستخدمها قديماً ثم تركتها لأستخدم الـKDE، و لا أظن أن باقي الواجهات سيكون لها نفس الدرجة من القبول عندي.
نهايةً: حينما أقوم بالتغيير سوف أقوم برفع صورٍ تريكم الناتج إن شاء الله تعالي ^_^

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

الجمعة، 25 نوفمبر، 2011

الفهرست: هل من مكمل له؟

الفهرست: هل من مكمل له؟
 

منذ فترةٍ بعيدة (حينما كنت أستخدم الـwindows)  بدأت كتابة برنامجٍ صغيرٍ أسميته "الفهرست".
 
تعود فكرته إلى محاولتى تقليدَ خاصيةٍ من خواص الواجهة المرئية مفتوحة المصدر (أعني واجهة الـKDE) التى تُنَصَّب على أنظمة التشغيل شبيهة اليونكس unix-like و من أهمها نظام التشغيل الأشهر قنو/لينوكس GNU/linux.

و هذه الخاصية التى حاولت نقلها و إتاحتها لمستخدمى الـwindows هي:

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

و قد كنت فى الغالب مجبراً على أن أكون من بين مستخدمي الـwindows؛ بسبب دراستى و عدم توافر البرامج التى ندرسها و نستخدمها إلا له).


و قد حاولت فى هذا البرنامج أن أجعل الشكل متشابهاً قدر الإمكان حتى لا يحس مستخدموا الـGNU/linux الأعزاء بالفارق إذا ما قرروا استخدام البرنامج مع نظام الـwindows (إذا ما احتاجوا لاستخدام هذا الأخير بأى شكلٍ من الأشكال).

 و بالطبع فإن البرنامج سوف يعمل على جعل قائمة (إرسال إلى) شبيهة بقائمة الـGNU/linux و هو ما سنراه فى الشكل التالى و الناتج عن استخدام البرنامج على حاسوبى الخاص (قديماً ^_^):

و كذلك من الممكن أن يحول قائمة المفضلات favourites إلي شكل شبيه، مما يتيح لي التنقل بحرية و بسرعة علي القرص الصلب الخاص بي. كما في الشكل التالي:
 و لا شك أن هذه القائمةَ قادرةٌ على تسهيل الكثير من الأمور على مستخدمى الـwindows، إذ بدلاً من عملِ نسخٍ للملف أو المجلد المرغوب فى نسخه، ثم فتح المجلد الوجهة و عمل لصق، أو ضغط الرمز الخاص بإرسال إلى في شريط الأداوت، و البحث المجهد عن المجلد الهدف، فسيكون بإمكاننا بمنتهى البساطة نسخ الملفات المرغوب فى نسخها بمجرد تتبع المسار بالفأرة ثم الضغط على اسم المكان الهدف.

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

المهم أنني توقفت عن العمل في المشروع لعدة أسباب:

    انتقالي لنظام الـGNU/linux و بالتالي عدم حاجتي للبرنامج
    انشغالي الشديد بمشروعي الأهم (البرمجة بإبداع).

لذلك فإني أقدم الشفرة المصدرية (source code) الخاصة بالبرنامج لكي يكمل العمل عليه من أراد التكملة، مع العلم بـ:

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

و رابط تحميل البرنامج في إصدارته 3.0 (نسخة غير مستقرة تماماً) هو:

 http://www.mediafire.com/?x3ny6kk30uh4nwj

و في المجلد the Fehrest main program VER 3.0.rar سوف يجد من يفتحه أن به الكود المصدري للبرنامج مع الشرح الخاص باستعماله.

و حتي إن لم تكن تريد العمل علي تطوير البرنامج، فيمكنك تحميل المشروع و قراءة الكود لأجل التعلم.

الأربعاء، 23 نوفمبر، 2011

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

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

السبت، 19 نوفمبر، 2011

قليلٌ من المرح مع الأكواد و الخوارزمات ^_^

أريد في هذه المرة أن نمرح قليلاً مع الأكواد ^_^

حيث سأضرب مثالاً بسيطاً لكيفية اختلاف الخوارزمات algorithms التي تؤدي نفس الوظيفة، و كيف يمكن أن يكون أحدها أفضل من الآخر من حيث السرعة و الكفاءة، و كيفية المقارنة السريعة بين أداء كل الخوارزمات !

المعضلة:
فلنتخيل أن معنا مجموعةً من الأعداد تبدأ بالعدد (min) و تنتهي بالعدد (max)، حيث يزيد كل عددٍ عن سابقه بقيمة (step)، و أن لدينا ملف نصي مساره (path) هو (test_fname)، هذا الملف مخزنٌ فيه مجموعةٌ كبيرة من الأعداد، و هي مرتبةٌ بحيث أن كل عددٍ في سطرٍ بمفرده كما يلي:
و نحن نريد أن نأخذ كل عددٍ من مجموعة الأعداد المحصورة بين (min) و (max) و نعرف كم عدداً في الملف أكبر منه أو يساويه، و كم عدداً أصغر منه.

الحل: 
و قد وجدتُ حينما أردتُ كتابة الدالة function التي تقوم بهذه العملية أن هناك خوارزمين يصلحان لهذا:
  • الأول:
    هو أن نأخذ في كل مرة عدداً من مجموعة الأعداد (فلنطلق عليه "المرجع")، و نقوم بقراءة الملف و نعد الأعداد التي داخله و التي قيمتها أكبر من قيمة "المرجع"، و كذلك الأرقام التي قيمتها أصغر من قيمة "المرجع"، و هكذا حتي تنتهي مجموعة الأعداد.
  • الثاني:
    هو أن نقرأ في كل مرة عدداً واحداً من الأرقام المخزنة في الملف ليكون هو "المرجع" هذه المرة، و نقوم بمقارنته بكل مجموعة الأعداد المحصورة بين (min) و (max)، و هكذا حتي تنتهي الأعداد في الملف.

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