هل من اهتمام عربي باللغات ال Functional ؟!

Khaled.Alshaya كتب:

رغم أن نقاشنا خرج عن الموضوع الأساسي و لكن لا بأس مادام النقاش ذا فائدة :)

يبدو أن لديك خبرة بـ #C و NET. ,

كما قلت لك نظرياً "المفروض" أن البرامج المكتوبة للـ Virtual Machines و تتبع مفهوم الـ JIT أن تكون أسرع من البرامج المترجمة :)

و لكن الحقيقة هي العكس, و عكس واضح جداً جداً, انظر إلى الفرق بين مترجمات NET. و بين مترجم VC من مايكروسوفت نفسها :)

هناك أمران,

اللغة, و المكتبة,

بالنسبة للغة لايمكن مقارنة ++C لا بـ Java و لا بـ #C فالأولى لغة برمجة عامة, و #C و Java لغات برمجة للـ business...

لغة ++C تختلف اختلافاً جذرياً في مفهومها عن Java و #C,

الشيء الوحيد المتشابه هو الـ Syntax, ليس أكثر و الباقي مختلف حتى النخاع,

بالنسبة للمكتبة, فصحيح أن مكتبة ++C ليست كبيرة, لسببين, الأول أن وراء ++C "متطوعون" حتى Stroustrup نفسه لا يعمل بدوام كامل على اللغة و يمضي وقت فراغه فقط :)

إضافة إلى ذلك فإن المكتبة القياسية, يجب أن توجد حيث توجد اللغة, و لا أعتقد أن NET. Framework يمكن أن يفيد محرك Google أو حتى المسبار الذي حط على المريخ :)

و الـ Reliability هي شيء نظري, فما أراه هو العكس هو أن البرامج المكتوبة بـ C و ++C برامج حقيقية, و لا توجد حتى الآن برامج حقيقية مكتوبة بـ Java أو #C إلا من رحم ربي,

في النهاية, النقطة الوحيدة التي تميز الـ Virtual Machine Approach هو إمكانية عمل الكود على أي منصة,

و تكتب تلك الـ VMs بواسطة ++C كما هو الحال مع الـ Net. و الـ JVM ...

تحياتي ..

برامج حقيقية بال #C

SQL Server Management Studio

Microsoft Visual Studio 2010

Microsoft Expression Studio

Microsoft Office Communicator

Microsoft Share Point Server

Microsoft Dynamicx CRM

و غيرها

أظن خالد يقصد الحوسبة في الزمن الحقيقي أي تتعامل مع الزمن الحقيقي مباشرة.

اقتباس

أظن خالد يقصد الحوسبة في الزمن الحقيقي أي تتعامل مع الزمن الحقيقي مباشرة.

حسناً أخي OMLX هذا واحد من الأمور التي لا تخرج عن لغة ++C/C, ببساطة :)

اقتباس

SQL Server Management Studio

Microsoft Visual Studio 2010

Microsoft Expression Studio

Microsoft Office Communicator

Microsoft Share Point Server

Microsoft Dynamicx CRM

VS على حد علمي مبني بـ ++C, و أما "واجهته" يمكن أن تكون بلغة مختلفة,

مترجمات Microsoft على حد علمي مبينة بلغة ++C,

SQL Server أيضاً مبني بـ ++C و أما الـ Studio فلا أدري عنه,

Office أيضاً مبني بـ ++C على حد علمي, و لا أدري ما هو الـ Office Communicator ؟

يا أخي لم أرد الخروج عن الموضوع, و لكن لا تقارن بين البرامج المكتوبة بـ ++C و البرامج المكتوبة بـ #C :lol:

لا يوجد مجال للمقارنة :)

من محرك google إلى أشهر برامج Microsoft إلى أشهر برامج adobe إلى Oracle إلى Maya إلى إلى إلى إلى ................... إلى أشهر البرامج العالمية في كل المجالات تجدها مكتوبة بـ ++C :)

و حتى مقولتك بأن الـ مكتبات NET. مكتوبة للاستفادة من أقصى Performance فهو شيء غير صحيح,

قارن بين تصميم STL و تصميم أي مكتبة Data Structure في العالم في أي لغة :)

مكتبات الـ Data Structure تأتي بكميات كبيرة من الـ Data Structure الجاهزة للاستخدام,

و لكن ما إن تتعلم STL حتى تعرف أن هناك عمليات سمكرة بشعة للغاية في مكتبات Java او Net. :)

دون ذكر boost في الموضوع....

كل ما في الأمر أن NET. و Java توفر للمبرمجين قاعدة واسعة من المكتبات القياسية لا أكثر و لا أقل, لإنجاز أعمالهم في أقصر وقت و هذا ليس فيه عيب,

و بالمناسبة أيضاً, ماهي المكتبة التي لا تتوفر بـ ++C :lol: ؟

لا أعتقد أن هناك مكتبة تتوفر لـ Java أو #C و لا يتوفر أفضل منها في ++C :)

تحياتي ...

سؤال يا أخ خالد ما هو مدى خبرتك في ال#C أو الJava أو حتى ال++C ؟

اقتباس

سؤال يا أخ خالد ما هو مدى خبرتك في ال#C أو الJava أو حتى ال++C ؟

خبرة طالب في الجامعة, إن كانت تسمى خبرة.

و لكني لم أبرمج بـ #C من قبل و لكن أحب القراءة حول net. بشكل عام :)

يبدو أنك تضايقت من كلامي حول #C, حسناً دعني أعطيك مثالاً حول ما قلته :)

اقتباس

و لكن ما إن تتعلم STL حتى تعرف أن هناك عمليات سمكرة بشعة للغاية في مكتبات Java او Net.

أخبرني مالذي يحصل عندما تقوم بتعريف stack لـ int أو أي built-in type ؟

قارن بين تصميم STL المعتمد على Policies و بين تصميم NET. و JAVA المعتمد على الوراثة و الـ Polymorphism, تصميم STL "أكثر كفاءة بكثير" و "أكثر مرونة"...

نصيحة, تعلمت الكثير من كيفية فصل الـ Algorithms عن الـ Containers في STL و هي فرصة رائعة للتعلم لمن يحب الإطلاع على التصاميم المتقدمة جداً في عالم البرمجيات....

قارن بين مفهوم الـ Iterators في Java و NET. و الذي أعتقد أنه سبب لكتابة أكواد بشعة للغاية عن تجربة مع Java و بين فكرة الـ Iterators في STL,

لا يوجد random iteratorو الـ iterators الخاصة بالـ Lists تعتمد على الـ bidirectional iterators و هذا يعني لكي أصل إلى منتصف الـ list يجب أن أمشي خطوة خطوة حتى أصل إلى المنتصف !!!

كما ترى استخدام واجهة الـ Container في هذه الحالة أفضل بكثير, للتنقل بين عناصر الـ Lists, و هو ما يلغي فائدة الـ Iterators أصلاً, رغم أن STL تعتمد على الـ Iterators أكثر من واجهات الـ Containers نفسها, لتربط بين الـ Generic Algorithms و بين الـ Containers, بغض النظر عن الـ Container نفسه مادام أنه يوفر الـ Iterator المطلوب...

العديد و العديد من عمليات السمكرة البشعة و كلها لحفظ المبرمج من الوقوع من الخطأ ؟!!!!! لا أدري ماهو الخطأ بالضبط,

إن لم يستطيع المبرمج معرفة ما يريد ؟!

لا أتفق لا مع JAVA و لا مع #C و لكن هذا لا يجعلهم لغتان غير جيدتين,

و صدقني مع ظهور مفهوم الـ Concepts (و الذي للأسف لن تدعمه المترجمات في القريب العاجل) ستحصر ++C لغات كـ Java و #C في بناء التطبيقات من أنواع معينة فقط كتطبيقات الويب, (حسب رأيي فقط :lol: )

الـ Concepts ستقضي على أسوأ مافي الـ Templates في ++C, ستحولها من Compile Time Dynamic Type Language إلى Compile Time Static Type Language...

ربما ربما كانت الأسماء صعبة و لكن ببساطة سيصبح هناك Interfaces في ++C كما في #C و JAVA و لكنها ستكون وقت الترجمة :)

لا تفكر في فائدتها لأنك ستراها في الواقع و ليس في لوحات الإعلانات عندما ستطبقها مترجمات ++C :)

تحياتي ....

المشكلة الأساسية كما ذكرت من قبل و سأذكر الان, لغة ال++C تترك كل القرارات سواء مهمة أو تافهة في يد المبرمج و هي في النهاية نقطة قوة في 1% من البرامج و نقطة ضعف في 99% من البرامج, على سبيل المثال, حاول أن تكتب تطبيق يتعامل مع الMultithreading في ال++C بحيث يعمل على كل المترجمات ؟؟؟ الاجابة ببساطة لا يمكن, لأن ال++C لا تعرف معنى الThreading و هذا متروك للمبرمج أن يحله طبقاً لنظام التشغيل الذي يعمل عليه, قلن يجد حلاً قياسياً

أيضاً حاول أن تكتب برنامج بحيث يعطيك القابلية لتحميل Third Party Plugins و في نفس الوقت يكون امناً بحيث أن يعمل الكود داخل الPlugin على سماحيات أقل من التي يعمل عليها البرنامج نفسه.

ثم نأتي الى أسئلتك الSTL مع كل ما فيها من روائع و مع أنها Standard الا أنه ليس من الضروري أن تجدها على كل نظم التشغيل, على سبيل المثال نظام Symbian OS و هو النظام الأكثر انتشاراً على أجهزة المحمول لا يدعم الSTL و يقدم مكتبة أخرى تختلف تماماً عنها.

دعم المترمجمات للغة نفسه يختلف من مترجم لاخر و القاعدة الاساسية هو أنه لا يوجد مترجم يدعم 100% من اللغة و كل المميزات التي ذكرتها

اقتباس

العديد و العديد من عمليات السمكرة البشعة و كلها لحفظ المبرمج من الوقوع من الخطأ ؟!!!!! لا أدري ماهو الخطأ بالضبط,

سمكرة؟ هل رأيت كود ++C لبرنامج حقيقي من قبل؟ اذا رأبت أريدك أن تتكلم عن السمكرة

ما رأيك بال Buffer Overflow أو الMemory Leaks أو ال Diamond Problem أليست كل هذه أخطاء يمكن للغة حلها بدلاً من تترك للبرمج

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

لماذا لا يكون هناك طريقة قياسية لبناء واجهات رسومية نحن الان في عام 2009

هذه هي المشاكل التي تجعل تكلفة بناء البرنامج أكثر من 20 ضعف اذا تم بناؤه بالJava أو ال#C

اقتباس

و صدقني مع ظهور مفهوم الـ Concepts (و الذي للأسف لن تدعمه المترجمات في القريب العاجل) ستحصر ++C لغات كـ Java و #C في بناء التطبيقات من أنواع معينة فقط كتطبيقات الويب, (حسب رأيي فقط )

في القريب العاجل ؟ ده كلام يا راجل, العالم يمشي للأمام و ليس للخلف, نحن الان في زمن نتكلم فيه عن الPython و الRuby و الJavascript و اللغات الFunctional و الDynmic لم يعد هناك مجال للعودة

لا أعتقد أنها مشكلة ++C بقدر ماهي انطباع أولي :)

أرجو أن لا تعتقد للحظة أن ++C هي لغة لبناء تطبيقات بواجهة رسومية كما هو الحال مع #C, هي لغة برمجة عامة حيث يوجد شيء اسمه معالج يوجد مترجم لـ C أو ++C...

الـ Multithreading, لم يكن حتى وقت قريب مهماً على جميع المعالجات و لا حتى لجميع التطبيقات التي تغطيها ++C,

++C لا تعطي أنصاف حلول, و إذا تم إضافة مكون إلى اللغة أو إلى مكتبتها يصبح من شبه المستحيل إزالته حسب أهداف ++C, و حتى فترة قريبة لم يكن هناك ما تقول عليه,

و لكن يبدو أنك لم تلقي نظرة على Boost فيها كل ما تتكلم عنه و زيادة حبتين, و تعمل على جميع ما تعرفه من نظم و ما لا تعرفه :)

هي من ضمن Cpp0x بالمناسبة...

اقتباس

أيضاً حاول أن تكتب برنامج بحيث يعطيك القابلية لتحميل Third Party Plugins و في نفس الوقت يكون امناً بحيث أن يعمل الكود داخل الPlugin على سماحيات أقل من التي يعمل عليها البرنامج نفسه.

لا أدري مالمقصود بهذه النقطة ؟!

هذا يعود لهندسة البرنامج نفسه و ليس للغة حسبما أعرف, VC لديه نظام plugins مالمشكلة فيه ؟ و ++NP لديه واحد أيضاً مالمشكلة فيه ؟

لم أفهم مالخطأ مع ++C نفسها

اقتباس

ثم نأتي الى أسئلتك الSTL مع كل ما فيها من روائع و مع أنها Standard الا أنه ليس من الضروري أن تجدها على كل نظم التشغيل, على سبيل المثال نظام Symbian OS و هو النظام الأكثر انتشاراً على أجهزة المحمول لا يدعم الSTL و يقدم مكتبة أخرى تختلف تماماً عنها.

دعم المترمجمات للغة نفسه يختلف من مترجم لاخر و القاعدة الاساسية هو أنه لا يوجد مترجم يدعم 100% من اللغة و كل المميزات التي ذكرتها

هي صاحبة مترجم, و يمكنك استخدام ماتشاء من مكتبات متخصصة إذا كنت تعتقد أن ذلك مناسب,

أما STL نفسها فهي source code library مبنية بالـ templates و أي مترجم ++C يستطيع ترجمتها :blink: فقط حمل STL port و قم بعمل include و ابدأ البرمجة لا أكثر,

99% من المترجمات تأتي مع STL جاهزة, أما إن كانت شركة لا تريد إلحاق المكتبة بمترجمها فهذا شيء راجع للشركة نفسها,

مالشيء الذي لا تدعمه مترجمات ++C من اللغة نفسها ؟ إلا إذا كنت تتحدث عن مترجمات صناعة 1990!

اقتباس

سمكرة؟ هل رأيت كود ++C لبرنامج حقيقي من قبل؟ اذا رأبت أريدك أن تتكلم عن السمكرة

ما رأيك بال Buffer Overflow أو الMemory Leaks أو ال Diamond Problem أليست كل هذه أخطاء يمكن للغة حلها بدلاً من تترك للبرمج

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

لماذا لا يكون هناك طريقة قياسية لبناء واجهات رسومية نحن الان في عام 2009

هذه هي المشاكل التي تجعل تكلفة بناء البرنامج أكثر من 20 ضعف اذا تم بناؤه بالJava أو ال#C

ههههههه لا لم أرى في حياتي أي برنامج حقيقي :lol:

هل تخاف من ifndef# و أخواتها, هذه سكر البرامج :lol:

أنصحك بأن تلقي نظرة على برامج حقيقية مكتوبة بـ ++C, فأنا لم أرى ما تتحدث عنه,

أكتب برنامجي بـ ++C بسطور أقل من JAVA و بوضوح أكبر و بسرعة أعلى و حجم أقل, مشكلة المبتدئين في ++C أنهم يعيدون اختراع العجلة في كل برنامج.

يا أخي الـ Buffer Overflow ؟!

هل تعرف ماهو الـ Buffer Overflow ؟!

هل تعتقد أنك بتضمين unchecked exception عند "كل" عملية استدعاء لأحد عناصر المصفوفة تكون قد حللت المشكلة ؟!

هل تعلم أن هذا الـ unchecked exception يحتاج إلى ثلاثة أو أربعة أو .... الوقت الذي تحتاجه لاستدعاء العنصر!

أستطيع حل هذه المشكلة في ++C بخمس أسطر من الكود بدلاً من إرهاق معالجي بـ unchecked exception مع كل عملية على كل عنصر في المصفوفة, و لن تكون أسطر الكود تلك في الملف التنفيذي نفسه, عند تأكدي من صحة الكود أستطيع بـ define واحدة أن أتحكم في وجود الـ Exception من عدمه,

و يمكنك تخطي محنة إعادة اختراع العجلة و استعمال vector من STL و لن تعرف أن هناك شيء اسمه Overflow بعد اليوم,

كيف تجعل برنامجك يقوم بالتنظيف وراءه ؟ لا تجعله يوسخ من الأساس :lol:

ماذا تعني بـ Memory Leak... هل تعتقد أنه شيء لازم الحصول ؟

في ++C هناك Design Pattern متبع على نطاق واسع جداً في عالم ++C يسمى RIIA, معاه لا يوجد شيء اسمه Memory Leak,

الـ Memory Leak هي نتيجة لوجود الـ Heap, و التحكم الغير صحيح في الـ heap ينتج Memory Leaks,

و بالطبع المبرمجون الهواة ينتجون كود سيء سواء بلغة تعطيك تحكم بالذاكرة أو حتى بلغة فيها Garbage Collector,

تحتاج إلى مبرمج وليس إلى هاوي برمجة لإنتاج برنامج,

الـ Diamond Problem, ليست مشكلة, هو خطأ في التصميم الذي وضعه المبرمج لا أكثر, و يجب عليك إعادة النظر في تصميمك, أليس هذا من أساسيات OOP :)

اقتباس

ماذا لا يكون هناك طريقة قياسية لبناء واجهات رسومية نحن الان في عام 2009

كما قلت لك منذ البداية, ليست لغة برمجة لبناء تطبيقات الأعمال السريعة,

هناك Qt و التي بدأت تصبح شبه قياسية على أنظمة الـ Desktop و الجوالات .. ليس لي فيها خبرة سوى قراءة بعض المقالات حولها,

اقتباس

هذه هي المشاكل التي تجعل تكلفة بناء البرنامج أكثر من 20 ضعف اذا تم بناؤه بالJava أو ال#C

لماذا إذاً يتم اختيار ++C في معظم المشاريع "الحقيقية" ؟!

عندما ظهرت Java تبناها طلبة الجامعات و حتى الآن لا أدري لماذا تتبناها الجامعات, و بقيت حبيسة الأسوار الأكاديمية بنظريات لا تنم للواقع بشيء,

و #C عندما وعدت بسرقة مبرمجي ++C سرقت مبرمجي Java بدلاً من ذلك :lol:

لأن ++C لا تشبه لا Java و لا #C إلا بالـ Syntax فقط,

بودي أن أسأل Adobe و مايكروسوف و Oracle و حتى مبرمج ++NP لماذا اختار ++C بدلاً من Java أو #C ؟!

انظر إلى العالم حولك, العديد من الشركات فشلت حتى في إعادة كتابة تطبيقاتها بـ Java الشبيهة من حيث الفكرة بـ #C,

اقتباس

في القريب العاجل ؟ ده كلام يا راجل, العالم يمشي للأمام و ليس للخلف, نحن الان في زمن نتكلم فيه عن الPython و الRuby و الJavascript و اللغات الFunctional و الDynmic لم يعد هناك مجال للعودة

عموماً أن أتفق معك في هذا, لم يعد هناك مجال للعودة لأن هذه اللغات بدأت بجذب مبرمجي #C و Java نحوها,

فهم أسهل و الـ dynamic typing فيهم يعطي راحة أكثر للمبرمج,

و بالمناسبة هذه اللغات كما هو الحال مع Java و #C ممتازة جداً في عملية الـ Prototyping,

و الملاحظ تفوق Python على باقي اللغات,

و لذلك تم عمل Integration على مستوى عالي لها في Boost إذا كنت تريد أن تدعم الـ Scripting في برامج بلغة ++C :)

آراء خبراء البرمجة -حسب اطلاعي- تقول بأن الـ Static Typing هو الأفضل في حالة كان المشروع في طور الإنتاج و ليس في طور الـ Prototyping,

لأن ذلك يوفر سرعة للبرنامج و إمكانية اكتشاف معظم الأخطاء مبكراً,

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

و لغة البرمجة يجب أن تعكس حجم البرامج التي تبنى بها,

و إذا كنت تحب المقارنة ليس لدي مانع و لكن في موضوع آخر, و أول ما أقترحه هو الخطأ الشنيع الذي وقعت فيه Java و من بعدها #C بحصر المبرمج في أسلوب البرمجة الكائنية فقط!

تحياتي ....

أنا حاسس اني بنده في مالطة, أنت لازلت طالب و ترى مشاكل اللغة نوع من اللعب الجميل و لم تر العيوب بعد.

Microsoft نفسها التي تنتج Compiler ل++C\C منذ أعوام طويلة تعيد كتابة بعض برامجها مثل الVisual Studio نسخة 2010 باستخدام #C و أيضاً بعض أجزاء Office و أغلب التطبيقات الجديدة مثل عائلة برامج Expression و هي (Blend, Studio, Web, Encoder, Media) و أيضاً Windows Live Mail, Windows Live Writer مبنية من الأساس على #C. و اغلب البرامج حالياً هي مزيج من ال++C و ال#C مثل SQL Server

اقتباس

أما STL نفسها فهي source code library مبنية بالـ templates و أي مترجم ++C يستطيع ترجمتها فقط حمل STL port و قم بعمل include و ابدأ البرمجة لا أكثر,

99% من المترجمات تأتي مع STL جاهزة, أما إن كانت شركة لا تريد إلحاق المكتبة بمترجمها فهذا شيء راجع للشركة نفسها,

مش بقولك انت لم تر عيوب اللغة.

اقتباس

أكتب برنامجي بـ ++C بسطور أقل من JAVA و بوضوح أكبر و بسرعة أعلى و حجم أقل, مشكلة المبتدئين في ++C أنهم يعيدون اختراع العجلة في كل برنامج.

أعطني مثال.

اقتباس

لماذا إذاً يتم اختيار ++C في معظم المشاريع "الحقيقية" ؟!

هذا على أساس أن الJava و ال#C يستخدمان في مشاريع "تخيلية"

اقتباس

لذلك تم عمل Integration على مستوى عالي لها في Boost إذا كنت تريد أن تدعم الـ Scripting في برامج بلغة ++

الScripting مدعوم على منصة الدوت نت منذ سنوات و يمكنك ادماج Iron Python أو Iron Ruby أو JScript في برامجك

و في القريب سيصدر مشروع Dublin و هدفه دعم بناء لغات خاصة Domain Specific Language (DSL على منصة الدوت نت.

اقتباس

و إذا كنت تحب المقارنة ليس لدي مانع و لكن في موضوع آخر, و أول ما أقترحه هو الخطأ الشنيع الذي وقعت فيه Java و من بعدها #C بحصر المبرمج في أسلوب البرمجة الكائنية فقط!

بالطبع أحب المقارنة و أحب أن توضح لي الخطأ الشنيع في البرمجة الكائنية.

اقتباس

أنا حاسس اني بنده في مالطة, أنت لازلت طالب و ترى مشاكل اللغة نوع من اللعب الجميل و لم تر العيوب بعد.

أي عيوب بالضبط ؟!

هل تعتقد أن الـ Syntax إذا كان بشعاً فهذا يعني أن اللغة سيئة!

أنا أقول لك عمليات سمكرة في مفاهيم اللغة نفسها! نقص في المرونة, لغات عجوزة في شبابها!

كما قلت لك في البداية لا مجال للمقارنة!

و أحب أن أقرأ لو سمحت الروابط التي تتحدث عن انتقال برمجة VS إلى #C! لا أتكلم عن الواجهة بل أتكلم عن النظام ككل مع مترجمات VS,

كل ما في الأمر أن واجهة VS ستكتب بـ Net. الذي هو نفسه مكتوب بـ ++C!

و يا أخي هل ستقنعني أن مدير SQL Server يعتبر مشروع بحجم SQL Server نفسه كـمحرك RDBMS!

سأريك إن أحببت أمثلة عن جمال و حلاوة ++C في الغد إن شاء الله بعد الدوام :wacko:

و لا أدري ماهي المشاريع التي هزت تاريخ البرمجة المكتوبة بـ Java و #C ؟!

حتى Implementation هذه اللغات مكتوب بـ ++C!

اقتباس

الScripting مدعوم على منصة الدوت نت منذ سنوات و يمكنك ادماج Iron Python أو Iron Ruby أو JScript في برامجك

و في القريب سيصدر مشروع Dublin و هدفه دعم بناء لغات خاصة Domain Specific Language (DSL على منصة الدوت نت.

يا أخي من عصر جدي و الـ Domain Specific languages يمكنك بناءها بلغة ++C دون حتى دعم من الـ Run-time و لا framework,

ألم أتحدث عن الـ Concepts! هي ما ستجعل إنشاء لغات صغيرة داخل ++C كشرب الماء,

ألم أقل لك بأنها ستغير خريطة البرمجة, صدقني أن لغات الشركات متأخرة بكثير خلف ++C على الأقل بعشرة سنين, كما هو الحال في دعم الـ DSL, و يمكنك الاطلاع على مقالي في نفس القسم هنا حول Spirit!

هل تستطيع لغة البرمجة المفضلة لديك فعل ذلك!

هل تستطيع #C!

اقتباس

بالطبع أحب المقارنة و أحب أن توضح لي الخطأ الشنيع في البرمجة الكائنية.

لم أقل أن هناك خطأً في البرمجة الكائنية فـ ++C تدعم البرمجة الكائنية أفضل من Java و #C,

ارجع إلى ما قلته و تأكد :)

و لا تنسى أن تجيب استفساراتي المتواضعة في مشاركتي رقم 31 إن كان لديك وقت,

تحياتي ....

Khaled.Alshaya كتب:

يبدو أنك تضايقت من كلامي حول #C, حسناً دعني أعطيك مثالاً حول ما قلته :)

أخبرني مالذي يحصل عندما تقوم بتعريف stack لـ int أو أي built-in type ؟

قارن بين تصميم STL المعتمد على Policies و بين تصميم NET. و JAVA المعتمد على الوراثة و الـ Polymorphism, تصميم STL "أكثر كفاءة بكثير" و "أكثر مرونة"...

نصيحة, تعلمت الكثير من كيفية فصل الـ Algorithms عن الـ Containers في STL و هي فرصة رائعة للتعلم لمن يحب الإطلاع على التصاميم المتقدمة جداً في عالم البرمجيات....

قارن بين مفهوم الـ Iterators في Java و NET. و الذي أعتقد أنه سبب لكتابة أكواد بشعة للغاية عن تجربة مع Java و بين فكرة الـ Iterators في STL,

لا يوجد random iteratorو الـ iterators الخاصة بالـ Lists تعتمد على الـ bidirectional iterators و هذا يعني لكي أصل إلى منتصف الـ list يجب أن أمشي خطوة خطوة حتى أصل إلى المنتصف !!!

كما ترى استخدام واجهة الـ Container في هذه الحالة أفضل بكثير, للتنقل بين عناصر الـ Lists, و هو ما يلغي فائدة الـ Iterators أصلاً, رغم أن STL تعتمد على الـ Iterators أكثر من واجهات الـ Containers نفسها, لتربط بين الـ Generic Algorithms و بين الـ Containers, بغض النظر عن الـ Container نفسه مادام أنه يوفر الـ Iterator المطلوب...

العديد و العديد من عمليات السمكرة البشعة و كلها لحفظ المبرمج من الوقوع من الخطأ ؟!!!!! لا أدري ماهو الخطأ بالضبط,

إن لم يستطيع المبرمج معرفة ما يريد ؟!

لا أتفق لا مع JAVA و لا مع #C و لكن هذا لا يجعلهم لغتان غير جيدتين,

و صدقني مع ظهور مفهوم الـ Concepts (و الذي للأسف لن تدعمه المترجمات في القريب العاجل) ستحصر ++C لغات كـ Java و #C في بناء التطبيقات من أنواع معينة فقط كتطبيقات الويب, (حسب رأيي فقط :lol: )

الـ Concepts ستقضي على أسوأ مافي الـ Templates في ++C, ستحولها من Compile Time Dynamic Type Language إلى Compile Time Static Type Language...

ربما ربما كانت الأسماء صعبة و لكن ببساطة سيصبح هناك Interfaces في ++C كما في #C و JAVA و لكنها ستكون وقت الترجمة :)

لا تفكر في فائدتها لأنك ستراها في الواقع و ليس في لوحات الإعلانات عندما ستطبقها مترجمات ++C :)

تحياتي ....

بالنسبة للIterators في الدوت نت فيوجد نوع واحد و هو الForward Only و هو الأكثر شيوعاً و يوجد طريقة أكثر جمالاً في استخدامه و هي ال foreach و هي تجعلك تستخدمه دون الحاجة الى الطريقة البشعة التي تكرهها

أما بالنسبة للcontainers فيوجد الCollections و هي تقدم كل ما تقدمه ال++C و أكثر فهنا

List<T> و هي الأكثر استخداماً لأنها تدعم الاستخدام العشوائي

LinkedList<T> و هي تتميز بالسرعة في الاستخدام المتتالي ثنائي الاتجاه و اضافة عناصر جديدة

SortedList<T> و تتميز بأنها تقوم تلقائياً بترتيب العناصر و يمكنك أيضاً تغيير اسلوب الترتيب

Dictionary<S,T> و تستخدم في تخزين البيانات عن طريق مقتاح و قيمة

SortedDictionary<S,T>

HashSet<T> و هي للعمليات مثل التقاطع و الاتحاد و غيرها

Stack<T>

Queue<T>

BitArray و هي مصممة لل Bitwise Operations

ReadOnlyCollection<T>

كما أن ال#C يوجد بها طرق أخرى للتعامل مع الCollections و الArrays مثل Linq على سبيل المثال

static void Main(string[] args)
{
	int[] myInts = { 2, 3, 2, 56, 78, 3, 67, 2, 78, 3, 78, 34, 8 };

	//find all even integers and sort them descending
	var query = from i in myInts
				where i % 2 == 0
				orderby i descending
				select i;
	foreach (int item in query)
	{
		Console.WriteLine(item );
	}
}

ففي الكود السابق قمت بعمل أكثر من عملية في سطر واحد, مثل البحث عن الأرقام الزوجية و ترتيبها تنازلياً و الكود مفهوم كده و يشرح ذلك

السلام عليكم ....

دعنا ننهي المناقشة هنا :)

كل ما ذكرته موجود في ++C, نظرة على STL و Boost ستجعلك تبتسم بإذن الله :)

أرجوك لا تقل لي بأن منصة Net. أكثر كفاءة من Boost أو STL, كل قطعة في STL و Boost مأخوذة من لحم صاحبها :lol:

هناك Data Structures غير موجودة من الأساس في الـ Collections في Java أو Net. لعدم حاجة برامج المال و الأعمال لها,

كما قلت لك نظرة على Boost ستغير من تفكيرك نحو ++C, انظر إلى مكتبة الـ Graph في Boost على سبيل المثال :)

أيضاً هناك أمور لا يمكن تطبيقها من "الأساس" بلغة #C لقصور اللغة نفسها كما هو الحال مع Java, هل تذكر variant من الأيام الجميلة لـ VB ؟

موجود في ++C.. ابحث عنه في Boost و هو Type Safe إن كان هذا مهماً لك... لا يمكن تطبيقه في #C دون تعديل اللغة نفسها,

كل ما تريده موجود في ++C و بجودة أفضل بكثير,

ماذا تريد ؟

foreach موجودة في Boost و STL هناك اختلاف بسيط من ناحية التصميم, في STL تستقبل مؤشر دالة أو Functor أما في Boost فهي كما تعرفها في #C,

و لكل استخدامه و ليس زيادة عدد,

و سيضاف إلى Cpp0x لأنه حسب Stroustrup بدأت اللغة تخيف المبرمجين :lol: لأنهم يرون "مكتبات" تضيف إمكانيات للغة.

جميع ما قلته لك يوفر عن طريق مكتبات :) و ليس من اللغة نفسها ...

++C لغة برمجة عامة, تقوم ببناء المكتبات و الـ Abstraction الذي تريده ثم تستعمل هذا الـ Abstraction بعد ذلك,

أما اللغة نفسها ليس بها شيء مثير حقيقة, و هذا لسبب بسيط, اللغة لم تعدل منذ ربما عام 1990, فليس هناك شيء للتعديل, هناك "بعض" الإضافات التي ستضاف إلى Cpp0x و لن يزال شيء فعلياً :)

جميع الإضافات أتت إما من كبار مبرمجي Adobe أو من باقي خبراء البرمجة في العالم, لبعد نظرهم و ليس لأن Microsoft أو Sun تعتقد أن إضافة شيء إلى اللغة يجعلها CoOL :lol:

لا أريد إطالة النقاش أكثر من ذلك,

حتى Linq يمكنك بناءها كمكتبة في ++C و لا تحتاج إلى لغة جديدة, انظر إلى Spirit حيث بإمكانك كتابة EBNF مباشرة في ++C دون تعديل المترجم ذرة تعديل,

ليست قصور في ++C, بقدر ماهو عدم الحاجة إلى شيء يشبه Linq في ++C نفسها,

بقي شيء أخير وعدتك بأن أريك شيئاً عن معنى "كفاءة" STL, في المشاركة القادمة كود كتبته لحل سؤال بـ Project Euler,

قم بإعادة كتابته بـ #C و أخبرني كم يأخذ البرنامج من الوقت لكي يعطي النتيجة :)

البرنامج عندي يعطي 309 ثواني تقريباً :)

أتمنى أن ينتهي في أقل من ساعة لديك لكي لا أشغلك كثيراً :)

تحياتي ...

السلام عليكم ...

هل هناك متبرع لكتابة الحل بلغة #C ؟

هذا هو السؤال رقم 92 من Project Euler!

و هذا هو حلي بلغة ++C, إن لم يكن مفهوماً أرحب بالمساعدة بأي شكل و لكن للأسف لا أعرف #C كثيراً :)

inline unsigned int squareOfDigits(unsigned int number)
{
	std::stringstream convertor;
	unsigned int sum = 0;

	convertor << number;

	for(unsigned int i = 0; i < convertor.str().size(); i++)
		sum += (convertor.str() - '0') * (convertor.str() - '0');

	return sum;
}

int main()
{
	boost::progress_timer t;
	const unsigned int max = 10000000;
	std::vector<unsigned int> list(max, 0);

	for(unsigned int i = 1; i <= max; i++)
	{
		if(list[i-1] == 89 || list[i-1] == 1)
			continue;

		unsigned int changer = i;
		std::vector<unsigned int> minList;

		while(true)
		{
			minList.push_back(changer);

			if(changer == 89 || changer == 1)
				break;

			changer = squareOfDigits(changer);
		}

		if(changer == 89)
		{
			for(unsigned int n = 0; n < minList.size(); n++)
				list[minList[n]-1] = 89;
		}
	}

	std::cout << std::count(list.begin(), list.end(), 89) << std::endl;

	return 0;
}

و هذا هو الوقت الذي احتاجه معالجي للحل :)

إذا كتبت الحل بلغة #C, رجاءً قم بترجمته لأجربه على معالجي حتى تكون المقارنة متعادلة, و لا تنسى أن يطبع برنامجك الوقت اللازم بعد الإنتهاء من طباعة الحل ...

بالمناسبة اخترت هذا السؤال بالتحديد حتى تعلم أنه عندما تأتي دعاية من Microsoft أو Sun تقول أخيراً تمت إضافة Automatic Boxing و Automatic Unboxing في كلا اللغتين,

لا تعتقد أنها ميزة,

هي سمكرة و الطلاء غير جيد :lol:

تحياتي ...

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

هذا هو الكود

   class Program
	{
		static int GetSquaredOfDigits(int number)
		{
			string numStr = number.ToString();
			int sum = 0;
			foreach (char digit in numStr)
			{
				int digInt = digit - '0';
				sum += digInt * digInt;
			}
			return sum;
		}

		static void Main()
		{
			int startsArriveAt89 = 0;
			Stopwatch stopwatch = Stopwatch.StartNew();
			List<int> sequence = new List<int>();
			for (int i = 0; i < 10000000; i++)
			{
				sequence.Clear();
				int start = i;
				sequence.Add(start);
				int newNumber, tmp = start;
				while (true)
				{
					newNumber = GetSquaredOfDigits(tmp);
					if (sequence.Contains(newNumber))
						break;
					else
						sequence.Add(newNumber);
					tmp = newNumber;
				}
				if (newNumber == 89)
					startsArriveAt89++;
				//Console.WriteLine("sequence for {0} is", start);
				//sequence.ForEach(Console.WriteLine);
			}
			stopwatch.Stop();
			Console.WriteLine("Starting Numbers count is {0}, {1}", startsArriveAt89, stopwatch.Elapsed.TotalSeconds);

		}
	}

و هو يعمل ال 10,000,000 في 30 ثانية على جهازي

أرفقت البرنامج مع الكود مع الexe

CodeEuler.zip

السلام عليكم ...

عموماً أخي الكريم لا داعي لتجربة حلك لأنه خاطئ :) لا أدري أين الخطأ و لكن الإجابة النهائية غير صحيحة,

لاحظ العدد الصحيح الموجود فوق الوقت في الصورة الأولى,

عموماً عندما تصل للحل الصحيح أتشرف بتجربته :)

إلى ذك الوقت, قمت بإعادة كتابة الدالة الوحيدة في الكود لكي ترى كيف أصبح الوقت لدي....

كل ما في الأمر أني كنت أستخدم الأداة غير الصحيحة للتحويل, stringstream هو لعمل لـ Format في الحقيقة و ليس للتحويل المباشر من عدد إلى نص,

unsigned int squareOfDigits(unsigned int number)
{
	char digits[12] = {0};
	unsigned int sum = 0;

	itoa(number, digits, 10);

	for(unsigned int i = 0; digits != 0; i++)
		sum += (digits - '0') * (digits - '0');

	return sum;
}

int main()
{
	boost::progress_timer t;
	const unsigned int max = 10000000;
	std::vector<unsigned int> list(max, 0);

	for(unsigned int i = 1; i <= max; i++)
	{
		if(list[i-1] == 89 || list[i-1] == 1)
			continue;

		unsigned int changer = i;
		std::vector<unsigned int> minList;

		while(true)
		{
			minList.push_back(changer);

			if(changer == 89 || changer == 1)
				break;

			changer = squareOfDigits(changer);
		}

		if(changer == 89)
		{
			for(unsigned int n = 0; n < minList.size(); n++)
				list[minList[n]-1] = 89;
		}
		else if(changer == 1)
		{
			for(unsigned int n = 0; n < minList.size(); n++)
				list[minList[n]-1] = 1;
		}
	}

	std::cout << std::count(list.begin(), list.end(), 89) << std::endl;

	return 0;
}

و هذا ما تحصل عليه عندما تبرمج بـ ++C مع شوية تفتيح مخ :P , إضافة إلى ذلك لم أقم بعمل أي Optimization للكود الناتج!

Snippet.rar

أخ خالد اسمح لي.

كلامك بدأ يتسم بالتهكم و السخرية البعيدين كل البعد عن النقاش العلمي. القليل من الفكاهة لا بأس به، و لكن ليس كسلاح ضد الطرف الآخر.

أنا شخصياً لا أمانع مثل هذه النقاشات "الحارة" بشرط أن يلتزم جميع الأطراف بآداب المحاورة.

و الآن، القليل من الفكاهة...

#C C++

اقتباس

كلامك بدأ يتسم بالتهكم و السخرية البعيدين كل البعد عن النقاش العلمي. القليل من الفكاهة لا بأس به، و لكن ليس كسلاح ضد الطرف الآخر.

أعتذر للأخ motamayez إن كان فهم هذا خطأ, الأخ عزيز و لا أقبل ذلك على نفسي حتى أقبله عليه :)

كل ما في الأمر لا أحتمل نفسي عندما يتحدث أحد عن ++C :P

بالمناسبة أنا أردت فقط أن أنبهه إلى أن حله خاطئ :huh: و لم أقصد السخرية, كل ما أردت قوله أن لا معنى للوقت في حله لأن الحل ليس صحيحاً :)

عموماً الموضوع خرج من الأساس عن أصله :)

تحياتي ...

بعيداً عن تهكمك, فأحب أن أوضح لك ما فهمته من منطوق السؤال

1- المتسلسلة تبدأ من اي رقم و يتم فصل الرقم الى الأعداد و تربيع كل عدد و جمع كل تربيع الأعداد في الرقم, ثم يتم ادخال الناتح في نفس العملية و هكذا و تنتهي المتسلسلة بأن يظهر أي رقم في السلسلة مرتين

2- المطلوب من المسألة أن نعد عدد الأرقام الذي اذا بدأنا بها ننتهي الى 89 ( و معنى ننتهي هنا هو أن يظهر الرقم 89 مرتين في السلسلة فتنتهي)

اذا كان ما ذكرته غير صحيح فأرجو التصحيح بأدب

ما قمت انت بوضعه في برنامجك أنك كنت تعتبر السلسلة انتهت بظهور رقم 89 سواء ظهر أول مرة أو ثاني مرة, و هنا الاختلاف

لم أتهكم يا أخي العزيز, و لا تعتقد للحظة أني أريد ذلك :)

كل ما في الأمر أني أخذت الأمر بشكل ودي,

ثانياً, السؤال ليس كما تقوله,

السؤال بكل بساطة,

هناك نظرية (لا أعرف ماهي) و لكن تقول بأننا إذا قمنا بتربيع "أرقام" العدد, ثم تربيع أرقام العدد الناتج عن التربيع السابق, فإننا لابد أن نصل إلى إلى العدد 89 أو العدد1 في النهاية مهما كان الرقم الذي بدأنا به,

كم عدد الأرقام التي ستصل إلى 89 فقط (هناك أرقام ستصل إلى 1, و لكن المطلوب الأرقام التي تصل إلى 89) ؟

كما ترى السؤال قد يبدو سهلاً من الوهلة الأولى كما العادة في أسئلة Project Euler, و لكن يحتاج إلى قليل من التركيز لا أكثر :)

لو أننا قمنا بكتابة خوارزمية بسيطة, دالة لتربيع العدد, و مررنا على كل عدد و إذا كان ينتهي عند 89 قمنا بزيادة counter على سبيل المثال, فإن هذا الحل سيأخذ وقتاً طويلاً جداً جداً ربما لن ينتهي برنامجنا قبل عدة أيام,

و Project Euler هناك قاعدة فيه تقول بأن الأسئلة تحل بأقل من دقيقة عادة بواسطة حاسوب متوسط الإمكانيات,

إذاً لابد من وجود حل أفضل,

الحل الذي اقترحته, هو أن ننشئ مصفوفة حجمها 10000000, و نبدأ مع أول عدد, الآن كل الأعداد التي ستتولد من هذا العدد سنمر عليها لاحقاً, صح ؟

ما الفائدة إذاً من إعادة اختبارها ؟ لافائدة و هنا يتم تسريع الحل,

مثلاً لو بدأنا بالعدد 2, و أنتج لنا سلسلة من الأعداد (minList) ثم انتهى عند 89, فإني سأضع في المصفوفة الرئيسية List علامة عند كل عناصر السلسة minList :)

و هكذا,

و كما ترى أول شرط في الحلقة هو ::

		if(list[i-1] == 89 || list[i-1] == 1)
			continue;

و بالتالي إذا كان تم وضع علامة (89 أو 1) في خانة العدد فإننا نتخطى العدد بأمان....

هذا هو الحل الذي اقترحته لا أكثر, و عمل ببساطة في 17 ثانية :)

بالمناسبة هناك الكثير من المعلومات المغلوطة حول ++C ليس هنا لدى العرب فقط, بل لدى الغرب بشكل أكبر :)

====================================

عموماً أنا مازال بودي تجربة برنامج يحل المسألة بلغة #C لأرى الفرق بين اللغتين بالمناسبة.

تحياتي ....

اعذرني فلا أعرف هذه النظرية و لكن بعد بعض البحث و جدت كود بالjava قمت بتعديلة ليعمل على ال#C و النتيجة مساوية لنتيجتك و وقت التنفيذ لم يتعدى ثانية واحدة على جهازي

/* A program to solve Poject Euler problem 92 */
class euler92
{

	/* Calculate the square of the digits of an integer */
	private static int SquareDigits(int i)
	{
		int res = 0;
		int cd;
		while (i > 9)
		{
			cd = i % 10;
			res = res + (cd * cd);
			i = i / 10;
		}
		res = res + (i * i);
		return res;
	}

	/* Determine if an integer culminates in 89 eventually (only other finish
	 * state is 1). */
	private static bool End89(int i)
	{
		i = SquareDigits(i);
		while (!(i == 1))
		{
			i = SquareDigits(i);
			if (i == 89)
			{
				return true;
			}
		}
		return false;
	}

	/* Given an integer, determine the maximum value of it's digits squared. */
	private static int MaxValue(int i)
	{
		int max = 81;
		while (i > 9)
		{
			i = i / 10;
			max = max + 81;
		}
		return max;
	}

	/* An initialise method to set all the values in an array based on a known
	 * size. A shorter lookup as all other values will end up at one of these
	 * so predetermine them all to save recalculation. */
	private static void Init(int tsize, bool[] vals)
	{
		while (tsize > 0)
		{
			vals[tsize - 1] = End89(tsize);
			tsize = tsize - 1;
		}
	}

	/* The main method that does most of the work. */
	public static void Main()
	{
		Stopwatch stopWatch = Stopwatch.StartNew();
		// The limit for the Euler Problem.
		int limit = 9999999;
		// Set the array size to be the maximum value for the square of
		// the number of digits in the limit.
		int arsize = MaxValue(limit);
		// Initialise the count of the ones that end in 89.
		int count = 0;
		// Create the array and then initialise it.
		bool[] vals = new bool[arsize];
		Init(arsize, vals);
		// Count down from the limit and if the number ends in 89 (based on
		// pre-calculated values) then increment the count.
		while (limit > 0)
		{
			if (vals[SquareDigits(limit) - 1])
			{
				count = count + 1;
			}
			limit = limit - 1;
		}
		// Print the result!
		stopWatch.Stop();
		Console.WriteLine("total seconds {0}", stopWatch.Elapsed.TotalSeconds);
		Console.WriteLine("Result is: " + count);
	}

}

و ها هو ناتج التنفيذ

Euler92.zip

يبدوا أنّ الخوارزمية التي اتى بها motamayez افضل من الخوارزمية التي استعملتها اخي خالد لذلك هناك هذا الفرق الكبير في الوقت, لاحظ دائما انّ الفرق الكبير الذي يضيع في وقت تنفيذ شيئ ما هو على الاغلب كيفية كتابة خوارزمية الحل وليس ضعف اللغة او البنية التحتية لها

صورة من جهازي:

motamayez يبدوا انّ جهازك خارق حارق :lol:

أعترف جهازي فوق المتوسط :lol: فعلى حسب Windows Experience Index في Windows Vista فهو 5.1

لاحظ اخي خالد انه في الخوارزمية التي وضعها motamayez انه يستخدم Boolean array ولم يستخدم لا List ولا هم يحزنون, فمن غير المهم تخزين الاعداد التي تنتهي ب 89 و من ثم نقوم بعدها, اخ خالد أعد كتابة الخوارزمية التي جاء بها motamayez بال C++ لنرى الفرق...

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

تعديل لإضافة:

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

دماغى تقومون بالمقارنة على اجهزة مختلفة :D هوووووووووووف

انا لم افهم 90 % من كل هذا ولا احب هذا الصداع لكن شئ واحد فقط هو رجوع التكنولوجيا للوراء

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

وانا اتكلم هنا عن ال Hard ware فى مجالى تطبيقات ال real time تحتاج الى سرعة عالية وحساب الوقت بدقة واتكلم عن معالجات 8 بت ذاكرتها محدودة جدا احيانا السى ++ لا ينفع معها

اما فى ال IT هناك السرعة وهناك الجودة واعتقد ان البرامج المتوسطة التى تأتى بالتعاقد تحتاج فيها الى الانتاجية وهنا الدوت نت من افضل الخيارات ( وانا لم اجربه ) اما فى تطبيقات اخرى فهو من ابشع الخيارات فانا لن افكر ابدا مثلا فى كتابة driver بالدوت نت وهناك برامج اخرى مثلا تستهدف المعالج بدون وجود اى نظام تشغيل مثل برامج الصيانة

هذه من ال 1% التى ذكرتها اخى متميز