لعنة الله على الـC و الـC++...

السلام عليكم و رحمة الله

اليوم أدعوكم جميعاً يا من تحبون البرمجة إلى التعبير عن كرهكم للـC و الـ C++ بمنتهى الحرية فأرجوكم المشاركة و لو بتعليق بسيط على اللغتين.

و فى النهاية سنرى من عدد المشاركات هل أنا بمفردى الذى أكرههما أم أن هناك آخرون؟؟؟؟؟؟؟؟؟؟

************

لماذا أكره الC و الـC++:

الحقيقة أن كرهى للغتين يعود لأكثر من سبب، أهمها هو الطريقة التين تنتهجاها حيال الأدوات التى توفرانها للمبرمج، فلغة الـC التى هى الأم للـC++ قد أنتجها السيدان دينس ريتشي و بريان كيرنيجان حينما احتاجا إلى لغة تعطيهما كل القوة التى تعطيها لهما لغات التجميع أو على الأقل أغلبها فى حين تكون لها بساطة لغات المستوى الأعلى و محموليتها و قابلية أكوادها العيش لفترة أطول و الإستفادة المتجددة من التقنيات الجديدة فى برمجة المترجمات.
و كان أمامهما خياران لأسلوب التعامل مع القوة التى تتيحها لهما اللغة، فالأسلوب الأول و هو الأكثر مباشرة أن يضعا كل تلك القوة فى يديهما هما على هيئة أدوات واضحة (مثل المؤشرات pointers و الهياكل structs و الدوال السطرية inline functions) يستخدمانها كما يستخدمان المتغيرات و الدوال، أما الأسلوب الثانى فهو أن يضعا كل تلك القوة فى بنية المترجم ذاته ثم يكيفانها لتنتج لهما المنتجات الأفضل تقنياً بدون أن يضع المبرمج العادى يده فى الأمر على الإطلاق.
و لأن السيدين دينس ريتشي و بريان كيرنيجان كانا معتادين على البرمجة باستخدام الأسلوب الأول و هو توافر كل الأدوات بين يديهما لأنهما عاصرا كل الأجيال الأولى للغات البرمجة منذ لغة الآلة و حتى اللغات عالية المستوى مروراً بلغات التجميع، و لأن الأسلوب الأول هو الأسلوب الأسرع فى بناء المترجم (لأن المترجم سيكون أبسط فى البنية عندئذ) فقد وقع اختيارهما عليه. و لما كان معاصروهما لهم نفس ظروفهما التى دفعتهما إلى اختيار ذلك الأسلوب فقد وافقوهما على ذلك الاختيار أو على الأقل وافقهما معظمهم على اختيارهم هذا.
و لهذا كله فإن الغلطة لم تكن هنا، بل كانت فى اللحظة التى كان بإمكان المبرمجين من الاجيال التالية الاستغناء عن هذا الأسلوب و العودة إلى الأسلوب الأفضل و لكنهم لم يفعلوا، و كان على رأس هذه اللحظات لحظة إنتاج لغة الـC++، فقد أدخلت هذه اللغة إمكانيات البرمجة كائنية المنحى إلى لغة الـC و لكنها احتفظت فى نفس الوقت بكل عيوب الأخيرة التى نجمت عن الأسلوب الأسرع فى التحكم فى القوة البرمجية، و لم يحاول المطور لها التخلص من تلك العيوب بل ربما توسع أكثر من ذلك فى وضع مهام كان يفترض على المترجم القيام بها على كاهل المبرمج العادى.
و بالتالى كان أن توسع المبرمجون فى البرمجة بالـC و كتبوا بها أهم برمجياتهم حتى أصبح لا يمكن تعلم برمجة نظم التشغيل و الأنظمة الرئيسة فى الحاسوب بدون الإحاطة بالـC و الـC++، و رويداً رويداً سيطرتا على كثير من المجالات و أصبح من الهرطقة فى عالم البرمجة ذم اللغتين أو التعرض لهما بالنقد بأى شكل من الأشكال عند التحدث عن البرمجة الاحترافية، و على الرغم من ذلك فأنا أؤكد أن عالماً برمجياً زاهراً سيكون أمامنا إن استطعنا إنتاج لغة برمجية تتغلب على سخافات الـC و الـC++ و تخلصنا من خزعبلات المؤشرات التى تتقافز أمام عينى لعنة الله على الـC و الـC++... Angry

و تشير لكل مكان فى أى برنامج C أتورط فى كتابته و الهياكل و الخلط بينها و بين الأصناف (classes) لعنة الله على الـC و الـC++... Huh

و غيرها من القواعد و الرموز الغريبة التى كان يكفى واحد منها فقط ليحل محل الباقين و يؤدى دورها بكفاءة لعنة الله على الـC و الـC++... Biggrin

. و فيما بعد حينما أستفيض أكثر و أكثر فى بيان الصفات التى ترجح كفة لغة برمجة على كفة لغة أخرى عندى فى موضوع (المفاضلة بين لغات البرمجة) ستكون أسباب كرهى للغتين أوضح أكثر و أكثر...

السلام عليكم ................ بصراحة انا موش متفق معاك 100% فى كرهك الشديد للغة السى و السى ++ (60% بس ) يعنى السى زى اى لغة فيها مميزات و عيوب --مع التفاوت فى حجم و تأثير كل منهم على اللغة طبعا -- و ليها اخطاء وثغرات وادوات بتتفاوت ما بين القوة و الضعف ومين عارف يمكن اللى عملوا اللغة عندهم و جهة نظر صحيحة فى الpointers والحاجات التانية اللى فى اللغة , وفى الاخر هما بشر ممكن يغلطوا ومين عارف (انا حاسس انى كتبت الجملة دى قبل كده ) يمكن فى يوم نقدر نعمل compiler جديد للغة السى نشيل منه كل الحاجات القديمة واللى ملهاش لازمة

من أهم أسباب كرهى للسى و السى بلس بلس احتواء اللغتين على مكونات سيئة للغاية عند النظر إليها و المقارنة بين مميزات وجودها فى لغة البرمجة وبين عيوب ذلك التواجد، و من هذه المكونات ما يلى:
1. المؤشرات pointers
2. الهياكل structs
3. الدامجات unions
و سوف أتطرق إلى سبب كرهى لكل مكون فى الأيام القادمة بعون الله تعالى..
**************************************

الهياكل:

نبذة بسيطة:

هى
مكونات فى الـ(C++) و الـ(C#) تشبه إلى حد
كبير للغاية الأصناف classes، حيث تمثل تجميعة منطقية من المتغيرات و الدوال التى تعمل على
تلك المتغيرات. و على الرغم من هذا فهى تخالف الأصناف فى بعض الخصائص كما سأوضح
فيما يلى.

لا ينبغى أن يسمح بها فى لغات البرمجة الجيدة التصميم للأسباب التالية:

1- تدخل
المبرمج فى تفاصيل يفترض أن تظل مقصورة على المبرمج البانى للمترجم compiler و لا تتاح
لمستخدم اللغة لإنتاج تطبيقاته، فالسبب الرئيس لدعمها فى لغات مثل الـC و الـC++ أنها تعطى المبرمج
القدرة على تحديد ما إذا كان يريد إنشاء الكائن الجديد فى منطقة المكدس stack فى الذاكرة
أم فى منطقة الـheap،
و كما قلنا أن هذا يعد تعدياً واضحاً على السلطات التى يفترض أن تكون للمترجم أو
المفسر مع نظام التشغيل.

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

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

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

و كان أمامهم خياران لأسلوب التعامل
مع القوة التى تتيحها لهم اللغة، فالأسلوب الأول و هو الأكثر مباشرة أن يضعوا كل
تلك القوة فى أيديهم هم على هيئة أدوات واضحة يستخدمونها كما يستخدمون المتغيرات
و الدوال، أما الأسلوب الثانى فهو أن يضعوا كل تلك القوة فى بنية المترجم ذاته ثم
يكيفونها لتنتج لهما المنتجات الأفضل تقنياً.

و لأنهم كانوا معتادين على البرمجة باستخدام الأسلوب الأول و هو
توافر كل الأدوات بين أيديهم لأنهم عاصروا كل الأجيال الأولى للغات البرمجة منذ
لغة الآلة و حتى اللغات عالية المستوى مروراً بلغات التجميع، و لأن الأسلوب الأول
هو الأسلوب الأسرع فى البناء فقد وقع اختيارهم عليه. و لما كان معاصروهما لهم نفس
ظروفهم التى دفعتهم إلى اختيار ذلك الأسلوب فقد وافقوهم أو على الأقل وافقهم
معظمهم على اختيارهم هذا.

و لهذا كله فإن الغلطة لم تكن هنا، بل
كانت فى اللحظة التى كان بإمكان المبرمجين من الاجيال التالية الاستغناء عن هذا
الأسلوب و العودة إلى الأسلوب الأفضل و لكنهم لم يفعلوا، و كان على رأس هذه
اللحظات لحظة إنتاج لغة الـC++،
فقد أدخلت هذه اللغة إمكانيات البرمجة كائنية المنحى إلى لغة الـC و لكنها احتفظت فى نفس الوقت بكل
عيوب الأخيرة التى نجمت عن الأسلوب الأسرع فى التحكم فى القوة البرمجية، و لم
يحاول المطور لها التخلص من تلك العيوب بل ربما توسع أكثر من ذلك فى وضع مهام كان
يفترض على المترجم القيام بها على كاهل المبرمج العادى.

2- تزيد
من قواعد اللغة بدون فائدة. بل إن شبهها قواعدها لقواعد الأصناف يجعلها مصدر بلبلة
للمبرمج و أكثر منه للمتعلمين الجدد للغة التى تدعمها. فعلى المبرمج أن يتذكر أن
الهيكل لا يرث و لا يورث على العكس من الصنف الذى يرث و يورث، و عليه أن يضع فى
ذهنه أن الهيكل و الصنف يشتركان فقط فى الوراثة من الواجهات، هذا بالطبع بجانب
تذكر أن الهيكل حينما ينشأ فأنه ينشأ فى منطقة المكدس فى الذاكرة بينما يوضع الصنف
فى منطقة الـheap. و غيرها من الإختلافات التى لا
سبيل للتخلص منها إلا بالتخلص من التفرقة بين الصنف و الهيكل من الأصل.

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

و لكن ما حدث هو كما قال و نوه عليه
البروفيسور (C.
A. R. HOARE)
فى ورقة علمية ماتعة تحت عنوان (ملاحظات حول تصميم لغات البرمجة) قدمها عام 1973،
حيث قال فيها ما ترجمته:

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

و إذا ما أضيف إلى تعقيد لغة البرمجة
تعقيد بنائها، و تعقيد بيئة عملها و كذا تعقيد المعايير المؤسسية لاستخدامها فأنه
ليس من المفاجئ أنه عند مجابهة مهمة برمجية معقدة فإن العديد من المبرمجين يصبحون
مغمورين.

فقد اعتقد مطوروا معظم اللغات الحالية أنه بإمكان المبرمج إتقان
جزء فقط من اللغة و عدم الحاجة إلى إتقأنها كلها، و لكن الرد عليهم ما قاله العالم
الجليل و أدرجناه فيما سبق.

» لغة الـC كلغة تمثيلٍ وسيط IR
» أسطورة لعنة الفراعنة
» لا إله إلا الله محمد رسول الله ...بقرة تقول الله قبل ذبحها
» لعنة الفراعنه ......... حقيقه ام خيــــال
» رائعة أنيس منصور:(لعنة الفراعنة و شئ وراء العقل) كتاب رائع