هل يمكن ل Go أو Rust أن تتفوق على ++C في المستقبل ؟

مجهول

1
فادى نبيل

لا أعتقد,

ماذا تقدم Rust او Go من ميزة نوعية للانتقال اليها؟

بضعة مكتبات لأشياء بسيطة أصلا يمكن كتابتها بنفسك فى ساعة عمل؟! و ببحث بسيط على google قد تجد الالاف من مكتبات سى++,

سى++ تتمتع بدعم أكبر, و هى ليست مرتبطة بشركة أو مؤسسة معينة (و هذا شىء مهم للغاية) عكس Go مثلا.

سى++ سوف تجدها على كل منصة و كل شركة و مؤسسة لديها مترجم سى++ و معظمها standardized بشكل جيد, فغالبا يمكن اعادة ترجمة الكود هنا و هناك.

بضعة مكتبات بسيطة لا تغرينى (و لا الملايين غيرى) للانتقال الى Go, او Rust, الا اننى معجب كون هذين اللغتين native و هذا مؤشر جيد بدلا من لغات السلحفائية مثل جافا و بايثون و كل هذه الاشياء.

3
سالم يسلم

نفس المنطق بالامكان تطبيقة على C++ يمل ان هذه الاضافات لا فائدة منها هل بإمكانك ترك C++ والعودة للغة C لان بإمكانك انجاز العمل بها دون الحاجة الى اضافات الموجودة في لغة C++؟

2
فادى نبيل

سى++ هى سى مع البرمجة الكائنية,

تقريبا انا لا استخدم عبارات سى++ الا قليلا, و البرمجة الكائنية استخدمها غالبا فقط للواجهة الرسومية (و هى أساسا الغرض الرئيسى منها). لذا بشكل أساسى فان معظم أكواد سى++ هى أكواد سى.

0
معتز عبدالعظيم

الغرض من البرمجة الكائنية ليس الواجهة الرسومية يا فادي

الغرض منها تحقيق هذه المبادئ في هندسة البرمجيات:

  1. Abstraction

  2. Reusability

  3. Infromation hiding عن طريق الـ Encapsulation

  4. Open close principle عن طريق الوراثة والـ Molyporphism

  5. Depenancy Inversion عن طريق الوراثة والـ abstraction

0
فادى نبيل

كل شىء فى البرمجة الكائنية يمكن استبداله ببساطة بواسطة Structure و Handle,

كمثال,

CATObject cat(......)

Cat::Walk()

Cat::Stop()

هى نفسها

CatStruct *cat;

cat-> = .......

cat=Walk(void *cat)

cat=Stop(void *cat)

لا فارق على الاطلاق, سوى ان الكود الثانى سوف ينفذ بشكل أسرع.

وحدها فى حالة الواجهة الرسومية, تتعقد الكائنات بشكل كبير, و يصبح الأمر مزعجا و مربكا بطريقة الhandle, لذا تسهل البرمجة الكائنية الأمر. و سوف تجد ان هذا هو الهدف من مكتبات مثل VCL, و MFC , هى عبارة عن غلاف رقيق من الكائنات يغلف الWindows API

لذا فى العالم الواقعى, لا يوجد استخدام حقيقى للبرمجة الكائنية سوى الواجهة الرسومية.

0
معتز عبدالعظيم

بالنسبة للقواعد اﻷولى يمكن من 1 إلى 3

أما 4 و 5: Open Close Principle و Depenancy Inversion فلا يمكن

وإذا كان لديك رأي غير ذلك فأثبت لي بمثال بتنفيذ هذه القواعد بطريقة غير كائنية

0
فادى نبيل

Open/Close Principle :

void *cat=CreateCat();

SetCatAge(10)

SetCatName(....)

cat=Walk(cat);

cat=Stop(cat);

Clear(cat);

هنا لا يمكن لمستخدم المكتبة Cat أن يقوم بالتعديل فى منشأة البيانات, طالما هو لا يرى الstructure CatStruct, انما هو بالنسبة له عبارة عن Handle فقط. (هكذا تعمل Windows API مثلا)

0
معتز عبدالعظيم

ليس هذا التطبيق الصحيح للمبدأ،

التطبيق الصحيح يتم عن طريق استخدام Molyporphism حيث يقوم المستخدم النهائي (المبرمج) الذي يستخدم المكتبة بحقن دالة قامة بكتابتها داخل الكائن الذي ورث منه، أي هي وراثة عكسية.

مثلاً فئة كائن لإدارة معلومات المستخدم والدخول TUsers، يمكننا أن نجعلها abstract ومن يرثها يقوم بكتابة دالة لقراءة كلمة المرور checkPass من قاعدة البيانات لأن كل نظام لديه طريقة مختلفة في تخزين كلمات المرور وإسم جدول مختلف وحقول مختلفة، ثم يقوم بوراثة هذا الكائن في كائن جديد TAccountingUser ثم يقوم بحقن إجراء التأكد من كلمة المرور ليقوم الكائن اﻷصلي بتشغيلها:

0
معتز عبدالعظيم

ما رأيك يا فادي أن نقوم بعمل مقارنة لقياس السرعة بين ++C السريعة جداً ولغة جافا البطيئة جداً

مثلاً لإنجاز مهمة معينة، مثلاً لحساب هل الرقم x هو عدد أولي أم لا ويكون رقم كبير جداً يحتاج لدقائق حتى يعطي النتيجة.

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

أقترح أن يكون موضوع جديد فيه هذه المقارنة

هل أنت جاهز!

0
فادى نبيل

نعم أنا جاهز,

رغم ان ذلك لا يحتاج الى اثبات. لا تنسى يجب ان يتم حساب x دون استخدام اى مكتبة من جافا.

الJava هى virtual machine و بالتالى كل شىء فيها أبطأ,

و نظرة بسيطة لأى برنامج مكتوب بالجافا كفيلة بذلك.

0
معتز عبدالعظيم

هُناك نظرية أحاول إثباتها أو نفيها عن جافا في آلية الـ JIT Engine والتي تقوم بترجمة الكود وقت التشغيل وتحويله إلى كود ثنائي Binary بحيث يكون سريع مثل برامج السي.

النظرية تقول أن مترجم لغة سي وغيرها من اللغات المترجمة تقوم بتحديد الـ Optimization أثناء الترجمة و ينتج عنها برنامج تنفيذي يعمل بأداء متوافق مع عدد من المعالجات، مثلاً إذا كان الناتج AMD64 فيعمل البرنامج مع كل المعالجات المتوافقة أي أنه يقوم باستخدام العامل المشترك اﻷدنى في الـ Optimization

أما الـ JIT Engine فتقوم بتحديد نوع المعالج أثناء تشغيل الكود، فتجد مثلاً معالج Core I7 به ميزات معينة لا توجد في معالج آخر، فتقوم بإنتاج كود تنفيذي Optimized مع هذا النوع من المعالج بالذات، فيكون الناتج تنفيذ أسرع من لغة سي.

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

0
فادى نبيل

لا أعتقد ان الJIT Engine بهذا التقدم,

أعتقد ان هناك overestimation كبير جدا لمثل هذه البرامج.

حتى مايكروسوفت الأكثر قربا من انتل لا تستخدم كل الoptimization الموجودة.

هذا جهد كبير و خاصة ان العلاقة بين Oracle و انتل ليست بمثل هذا القرب من مايكروسوفت.

0
معتز عبدالعظيم

أنا أيضاً اعتقد أن هذا الكلام مبالغ فيه،

لكن دعنا نجرب.

سوف أقوم ببداية موضوع جديد.

اﻵن كتبت برنامج جافا لحساب الرقم الأولي

0
فادى نبيل

اريدك أن تستخدم مثال فيه Garbage collection و threads و الكثير من الmemory handling,

العمليات الحسابية هى شىء بسيط حاليا بالنسبة لأى حاسوب حاليا.

0
معتز عبدالعظيم

لا لا هذا مثال معقد.

يمكن أن نبدأ بمعادلات حسابية بسيطة، على اﻷقل نتأكد من أن الكود المكتوب بجافا والكود المكتوب بلغة سي++ مطابق. بعد ذلك يمكننا أن ننتقل إلى مرحلة فيها thread و Garbage collection

كذلك يمكن عمل خدمة ويب ثم تشغيل برنامج HTTP Tester لعمل عدد من الـ Threads وسوف يكون فيها garbage collection لمعرفة السرعة والتحمل، لكن نتائجها سوف لن تكون دقيقة.

لكني أميل للتجربة البسيطة في البداية ثم ننتقل إلى مرحلة أخرى.

ما رأيك؟

0
فادى نبيل

لا مشكلة لدى على الاطلاق.

انا منفتح على التجربة بالطبع.

0
معتز عبدالعظيم

هذا هو رابط التجربة:

0
Volteccer Dax

ما مشكلة بايثون؟

1
فادى نبيل

انها Scripting Language! بطيئة.


برمجة

المواضيع والنقاشات المتعلقة بالبرمجة بشكل عام او لغات البرمجة التي لايوجد لها مجتمعات فرعية.

24.6 ألف متابع