اريد تعلم لغة برمجة الهدف عمل برامج سطح مكتب كنت اريد ان اتعلم سي شارب لكن ارى جافا افضل لانها تعمل على لينكس ايضا و انا ادرس لينكس
بمادا تنصحوني ماهي الافضل و هل مستوى الغات متشابهان و سهولة التعامل مع الواجهة الرسومية الي في جافا مثل سي شارب ؟
استفسار عن لغة برمجة المناسبة بالنسبة لي c# and java
أرى أن تشاهد درس أو درسان من كل لغة فمن وجدته ميسرا لك تابع به ثم تنتقل إلى الأخرى
يمكنك الاطلاع على هذا الكورس
و لعل الإخوة من لديه رابط لكورس جافا يجده ميسرا
حينها شاهد المقدمات لتحدد الأيسر منهما فتبدأ به.
أفضل نصيحة يمكن تعطى لمثل هذا النوع من الأسئلة.
ما يعجبني في السائل هو تحديد هدف معين و قلل الفرص للغتين يمكن رآها مناسبة. أعمل على الجافا لكن بشكل جدا بسيط و سبب الاستخدام هو الحاجة. لا خبرة لدي بالمقارنة بين اللغتين كمستوى و نواقص و إضافات. لكن اتبع نصيحة الأخ عبدالرحمن، شاهد مجموعة فيدوهات و قد يعجبك شئ يبفقده الآخر. و عامل آخر، هل هدفك ويندوز أو أي شئ؟
عملت على #C تقريبا 3 شهور، لا أرى ذاك الفرق الكبير إذا استخدامك بسيط للغتين.
بالنسبة للفيدوهات، عبدالرحمن طرح موقع فيه دروس #C. و هذه مجموعة دروس عن Java ، الموقع:
ابحث من ضمن القوائم و ستجد مستويات للجافا.
مادامت تسخدم نظام لينكس فاﻷفضل لغة جافا، فهي تعمل في لينكس، ووندوز وماكنتوش، وقد جربت برامج ذات واجهة رسومية وعملت بنجاح في راسبري باي Raspberry PI وهو مبنى على معمارية ARM. كذلك يُمكن استخدامها في برمجة أندرويد
خيار جيد فأحد أصدقائي قام ببرمجة أحد البرامج الكبيرة نوعا ما بلغة الجافا و بعدها تعلم لغة السي شارب و أعاد برمجة نفس البرنامج بالسي شارب وكان أداء البرنامج جيد جدا بل أفضل بكثير من الجافا.
كما أنك إذا كنت تريد إنتاج برامج سطح المكتب فأنصحك بالويندوز لأنه الأكثر إنتشارا أما مستخدمي اللينكس فمعظمهم يحبون سطر الأوامر و لا يحتاجون إلى واجهة رسومية.
توجد منصة للغة C# في نظام لينكس وماكنتوش ووندوز وهي مجانية اسمها mono develop لكنها ليست مشهورة، يمكنك تعلم لغة #C باستخدامها في لينكس.
البرامج المكتوبة بواسطة mono-develop سوف تعمل على لينكس وماكنتوش ووندوز، وهي تستخدم نُسخة دائماً تكون أقدم من نُسخة منصة الدوت نت لميكروسوفت، وفيها كثير من اﻷشياء الناقصة، مثلاً لا تحتوي المكتبة الرسومية WPF تستخدم مكتبة أقدم، لا اذكر اسمها. في الحقيقة لم استخدمها طويلاً فقط قُمت بتجربتها لفترة صغيرة لأغراض التعلم والتجربة. هذا هو موقع هذه اﻷداة والمنصة البرمجية:
لن أناقش التفاصيل التقنية فقد ناقشها أكثر المعلقين،
هل أخذت بعين الاعتبار سوق العمل حيث تريد أن تعمل مستقبلاً؟ أم أنك تريد أن تعمل لنفسك فقط؟
أنا ما وجدته بالنسبة لفرص العمل هنا في تركيا: الشركات التي تعمل على جافا مستواها أعلى ولكن فرص العمل أقل من الفرص المتوفرة بالنسبة لسي شارب،
يمكنك و لكنني لا انصح بذلك تعلم واحدة ثم ابدأ بالاخري
ابحث عن قناة thenewboston في اليوتيوب لديه دروس رائعة للغتان
عمل برامج سطح مكتب
لا هذه ولا تلك. استخدم Qt مع سي++ (البعض يفضل pyside مع بايثون)
جافا ولت أيامها. لكن إن كنت مصر فانظر
أما بخصوص سي# فاهرب منها ما استطعت فهي مجرد فخ vendor lock-in
جافا ولت أيامها. لكن إن كنت مصر فانظر
من أين أتيت بهذه المعلومة؟ جافا موجودة و العمر أمامها طويل. و انظر مثلا إلى قوقل تريند:
.. ما زالت شابة :)
و لو نظرت إلى TIOBE، شخصيا لا أثق كثيرا بهذا الموقع لكن يبدو الكثير مقتنع به، لكن جافا الثانية بعد C: الموقع:
حان دورك بطرح أمثلة تبين لماذا جافا ولت أيامها؟ :)
لاحظ الموقع الذي وضعته أنت حيث وضع سهم لأسفل أمام لغة جافا.
بأي حال إليك تبريري:
جافا لغة مهذارة وملوثة ومنتفخة قليلة الإنتاجية (بمعنى ما يكلف 3 ساعات عمل في بايثون يكلف 3 أسابيع في جافا)
جافا لغة مفضلة لأصحاب الأعمال enterprise لا لشيء إلا ﻷن الموظفين يبدون يعملون (كما يزعم لاري وال) فهي كوبول القرن الواحد والعشرين
المكتبة القياسية قاصرة (مقارنة بلغة بايثون) مما يجعل مشروعك ياعني من تلوث JAR Hell (مثلا لاستخدام مكتبة OAuth لتويتر تحتاج وكيل Http لكن لعمل upload تحتاج ويكيل HTTP آخر)
جافا بدأت بحل مشكلة تعدد المنصات بعبارة write it once run it everywhere لكن على أرض الواقع هي write it once debug it everywhere
شرحت ذلك بالأمثلة في مقالتي
انظر أيضا
بأي حال كانت تلك مجرد نصيحة شخصية وذوق شخصي (وقد أعطيته مقالة عن طريقة البرمجة بلغة جافا وواجهة SWING)
قبل أن أرد، أنا لست متعصبا للغة معينة. لكن أحب البحث و التدقيق فيمن يستخف بلغة لأرى إن كان ما يقوله صحيح. و للأسف، أغلب ما أقرأه آراء شخصية، و قد ذكرت أنت ذلك في نهاية ردك.
لاحظ الموقع الذي وضعته أنت حيث وضع سهم لأسفل أمام لغة جافا.
السهم للأسفل لا يعني أن اللغة في انحدار. السهم للأسفل معناه أن اللغة كانت الأولى و نزلت للمرتبة الثانية. على يسار السهم، ستجد أن لغة جافا كانت الأولى في مثل هذا الشهر السنة الماضية و نزلت للمرتبة الثانبة هذه السنة. لغة جافا و لغة C في تنافس مستمر على المرتبة الأولى
جافا لغة مهذارة وملوثة ومنتفخة قليلة الإنتاجية (بمعنى ما يكلف 3 ساعات عمل في بايثون يكلف 3 أسابيع في جافا)
أف أف أف، تتكلم عنها كأنها قتلت أحد معارفك :) لم تذكر مثال عن تلوثها أو انتفاخها. تكلمت عن سرعة الإنتاجية و ضربت مثال غريب. إذا جافا تأخذ 3 أسابيع، كم تتوقع يأخذ برنامج ++C أو C؟ 6 أسابيع؟
أنواع البرامج تختلف. إذا هدفك النهائي برامج بسيطة و عامل سرعة التنفيذ ليس هدفك النهائي، لغات كـ بايثون أو روبي الحل الأمثل لك بسبب سرعة الإنتاجية. لكن إذا عملك يهتم بالسرعة بشكل رئيسي، ستترك عامل الأريحية جانيا لتطور ما تراه أنسب للتبطيق. في هذه الحالة، استخدام جافا أو سي.
جافا لغة مفضلة لأصحاب الأعمال enterprise لا لشيء إلا ﻷن الموظفين يبدون يعملون (كما يزعم لاري وال) فهي كوبول القرن الواحد والعشرين
جافا بدأت بحل مشكلة تعدد المنصات بعبارة write it once run it everywhere لكن على أرض الواقع هي write it once debug it everywhere
جافا تميّزت بسبب مكتباتها الكثيرة، وجود أطر عمل و محررات لها و تاريخ اللغة. اللغة لديها الكثير و الكثير من المكتبات، و لتطوير منتج في شركة، المكتبات تساعدك و لك حرية الاختيار . write it once debug it everywhere صحيحة و لكن مبدأ write it once run it everywhere ما زال موجود و لا تستطيع إنكاره. ابحث في doc بايثون و ستجد دوال تعمل على نظام تشغيل و لا تعمل على النظام الآخر. هذا الشئ غير موجود في جافا. لماذا الشركات الكبيرة تعشق جافا؟ لأنها تستخدم أكثر من نظام تشغيل واحد. و إذا طورت نظام بالجافا ستضمن عملها على كل الأنظمة بدون تعقيد الكود بشروط في كل مكان للتحقق من نظام التشغيل قبل إجراء أي عملية.
المكتبة القياسية قاصرة (مقارنة بلغة بايثون) مما يجعل مشروعك ياعني من تلوث JAR Hell (مثلا لاستخدام مكتبة OAuth لتويتر تحتاج وكيل Http لكن لعمل upload تحتاج ويكيل HTTP آخر)
من قال لك أن المكتبة قاصرة؟ عدم وجود كلاس لا يلبي طلبك لا يعني نقصان. شخص آخر قد يرى العكس و يقول أن جافا لديها ArrayList و Linked List بينما بايثون فقط list. كما أن جافا لديها عدة تطبيقات للـ map مثل tree map و linkedhash map أما بايثون مربوطة بـ dict فقط. و واجهت شخصيا أكثر من مرة من عدم اتفاقية مكتبة من مكتبات بايثون مع نسختي. لا أستطيع حتى ذكر المرات التي مررت فيها بمواقف شبيهه.
بالنسبة إلى
(مثلا لاستخدام مكتبة OAuth لتويتر تحتاج وكيل Http لكن لعمل upload تحتاج ويكيل HTTP آخر)
لا فكرة لدي عن http في جافا. فلا رد لي على هذه النقطة
انظر أيضا
قرأت المقال بشكل سريع و لم يذكر شئ اقتنعت به. حتى ذكر:
Within the non-script group, the Java programmers tend to be less experienced in their language than the C and
C++ programmers because Java was still a new language in 1997/1998
و هذا غير أن في نفس الدراسة ذكر أن مبرمجي C و جافا كانوا طلاب ماجستير. أما لغات البرمجة مثلا بايثون كانوا ممن أجابوا اعلان جريدة. و ذكر أحتمالية ان من أتى لديه خبرة برمجية أكبر من الطلاب.
لم اقرأ الدراسة كاملة لكن قرأت كم جملة، ذكرت 2، و غيرها من الجمل ما يجعلني أفقد مصداقية الدراسة. و أيضا الدراسة مضى عليها 14 سنة. المقالة أيضا ذكرت الدراسة لكن لم تضع رابط للأكواد المصدرية ليتم مراجعتها.
لو أحببت، هذا رابط
يضع جافا و بايثون تحت المجهر في عدة اختبارات، و الأكواد المصدرية مفتوحة و تستطيع مشاهدتها و تطويرها :). مثلا لو قرأت الجدول بشكل سريع: لا يوجد أي برنامج بايثون ضاهى جافا في السرعة. بعض البرامج أخذت من جافا 5 ثواني بينما في بايثون أكثر من 250 ثانية. صحيح عدد السطور كانت الضعف، لكن مقدار الفائدة، من ناحية السرعة، يضع جافا فوق بايثون
ذكرت في مقالك:
انظر إلى معضلة Apache HTTP client و HttpURLConnection
هذا الرابط للموضوع في مدونة مطوري اندرويد:
. شخصيا، لا أرى المعضلة في الموضوع و الموضوع واضح. قال الكاتب، إذا تطور لنسخة Froyo أو قبل، استخدم Apache HTTP client لأنها أقل مشاكل. أما إذا كنت تطور لشئ أحدث، استخدم httpUrlConnection. لا ارى المعضلة أبدا. هذه صورة توضح عدد مستخدمي كل اصدار اندرويد،
عدد مستخدمي نظام froyo أو قل (معناه من سيواجه مشاكل إذا استخدمت في تطبيقك httpUrlConnection) هو اقل من %5 من كل مستخدمي أندرويد. و هذه نسبة جدا صغيرة و تتضائل كل شهر. بمعنى، تجاهلها و طور برنامجك باستخدام httpUrlConnection
إذا جافا تأخذ 3 أسابيع، كم تتوقع يأخذ برنامج ++C أو C؟ 6 أسابيع؟
نفس الصورة تشير إلى أن إنتاجية سي/سي++ أعلى من تلك في جافا (الوقت الأقل هو الأفضل)
ابحث في doc بايثون و ستجد دوال تعمل على نظام تشغيل و لا تعمل على النظام الآخر. هذا الشئ غير موجود في جافا. لماذا الشركات الكبيرة تعشق جافا؟ لأنها تستخدم أكثر من نظام تشغيل واحد. و إذا طورت نظام بالجافا ستضمن عملها على كل الأنظمة بدون تعقيد الكود بشروط في كل مكان للتحقق من نظام التشغيل قبل إجراء أي عملية.
برنامج بايثون تعمل على كل المنصات لكن الفروقات بين المنصات موثقة. بمعنى بايثون توفر دوال عليا (تعمل بنفس الطريقة على كل المنصات) كما أنها توفر وصول كامل إلى مستويات النظام الدنيا وتوثق ذلك يضا ولا تترك مجال للتخمين. في حين في جافا تحرمك من تلك الدوال. إذا كنت ترى عكس ذلك اطرح سؤال منفصل عن مثال معين "كيف أفعل كذا في بايثون بطريقة متعددة المناصات" وسأجيبك
يقول أن جافا لديها ArrayList و Linked List بينما بايثون فقط list. كما أن جافا لديها عدة تطبيقات للـ map مثل tree map و linkedhash map أما بايثون مربوطة بـ dict فقط
إن كنت لا تعلم ما توفره بايثون هذا لا يعني أنه موجود. لكن قبل أن تسأل ما هو الشيء غير الموجود يجب أن تفهم شيء عن كود بايثون وهو أن الكود يجب أن يكون ذو مستوى عال بمعنى أنا لا يهمني ما هي الخوارزمية المستخدمة لتنفيذ هذا الشيء هل هل Doubly linked lists أم hash أنا يهمني منها business logic بمعنى على مستوى عال هذه توفر وصول بزمن ثابت/خطي لكذا كذا...
في بايثون هناك lists و tuples وهناك set و deque وفي بايثون هناك dict و defaultdict و ordereddict ...إلخ كل هذه الفروقات بينها فروقات ذات مستوى عال. بمعنى هي interfaces يمكنك تخصيصها أو الدمج بينها.
لو أحببت، هذا رابط
يضع جافا و بايثون تحت المجهر في عدة اختبارات
أخي الحبيب تلك اسمها game وفي رأس الصفحة يذكرون أنها لا تصلح كمقياس أو نتيجة معينة. ماذا نستنتج من أن لغة جافا تستطيع اكمال حلقتين تكراريتين متداخلتين لعمل ترتيب فقاعي أسرع من بايثون (دون استعمال دالة الترتيب عالية المستوى في اللغتين). إن كان هناك وظيفة لتلك القياسات فهي المستعدة في تحسين المفسرات مع الزمن (مقارنة مع نفس اللغة)
tl;dr
Measurement is highly specific -- the time taken for this benchmark task, by this toy program, with this programming language implementation, with these options, on this computer, with these workloads.
أما إذا كنت تطور لشئ أحدث
هناك معضلتان. الأولى وجود قصور في المكتبة القياسية استدعت الحاجة لمكون من طرف ثالث. أنه المكونات من طرف ثالث متضاربة بحيث لا يكون الانتقال بينها مجرد تغير سطر واحد (drop in replacement) بسبب ضعف في تصميم الواجهة البرمجية interface وكل الحلول غير شاملة بمعنى الحل الأول يغطي جزء من المشكلة والآخر يغطي جزء آخر.
المشكلة لا تقف هنا المشكلة عندما تحتاج مكون خارجي يستخدم هذه ومكون خارجي آخر يستخدم تلك.
في بايثون مثلا هناك تصميم واع للواجهة البرمجية بحيث يمكنك الإنتقال بين العديد من الحزم دون تغير أي شيء في الكود. مثلا يمكنك تغير خادم الويب الضمن في برنامك من Paste إلى cherrypy. بل يمكنك نقل برنامجك من التعامل مع multiprocess إلى mulithreads أو بالعكس ببساطة لأن لهما نفس الواجهة البرمجية لأن التصميم عالي المستوى لكليهما أتى ليحل نفس المشكلة وهيأني أريد تنفيذ العديد من الأشياء معا.
أخي مؤيد، أنا اتفق معاك في أشياء كثيرة،
أنا ذكرت،
إذا جافا تأخذ 3 أسابيع، كم تتوقع يأخذ برنامج ++C أو C؟ 6 أسابيع؟
أعلم عن هذه المشكلة، و صدقني مررت بمشاكل كثيرة في جافا و سألت نفسي "لماذا جافا ليست كبايثون". أحد الحالات كانت قراءة ملف نصي، قراءة الملف جدا جدا جدا سهلة في بايثون، أما جافا تحتاج إلى 3-4 سطور هذا غير تعريف المتغيرات الطويل، لأنها static.
ما يجعلني أرد عليك هو سبب بسيط، كل لغة لها استخدامات و مزايا تفرق بينها و بين اللغات الأخرى.
مثلا، في رد لك مع الأخ معتز، ذكرت ان تويتر هربت من روبي لجافا. (للتصحيح، و هذا مذكور في رابط المقال الذي أرفقته في ردك للأخ معتز، أن جزء backend هو ما تغير من روبي إلى JVM -سكالا و جافا-). شاهدت قبل فترة فيديو
و ذكر فيها أن لازالوا في عملية النقل من روبي إلى جافا.
برنامج بايثون تعمل على كل المنصات لكن الفروقات بين المنصات موثقة. بمعنى بايثون توفر دوال عليا (تعمل بنفس الطريقة على كل المنصات) كما أنها توفر وصول كامل إلى مستويات النظام الدنيا وتوثق ذلك يضا ولا تترك مجال للتخمين. في حين في جافا تحرمك من تلك الدوال. إذا كنت ترى عكس ذلك اطرح سؤال منفصل عن مثال معين "كيف أفعل كذا في بايثون بطريقة متعددة المناصات" وسأجيبك
آسف لم أكن واضحا. صحيح بايثون يعمل في كل مكان. لكن هل حاولت نقل برنامج مكتوب ببايثون من لينكس إلى ويندوز؟ ستحتاج إلى بندول :) قبل فترة احتجت نقل برنامج، و كان يحتاج numpy. تحميلها في لينكس جدا سهل لكن أتذكر لم أستطع تحميلها بسهولة. بحثت كثيرا و حللت مشكلة مشكلة إلى أن وصلت إلى طريق مسدود. بعدها و بالصدفة اكتشفت موقع يوفر المكتبات المشهورة للبايثون على شكل exe للويندوز
. لكن لو كنت تعمل على الجافا، اسحب ما تسميه JAR HELL إلى class path و انتهينا :)
لكن قبل أن تسأل ما هو الشيء غير الموجود يجب أن تفهم شيء عن كود بايثون وهو أن الكود يجب أن يكون ذو مستوى عال بمعنى أنا لا يهمني ما هي الخوارزمية المستخدمة لتنفيذ هذا الشيء هل هل Doubly linked lists أم hash أنا يهمني منها business logic بمعنى على مستوى عال هذه توفر وصول بزمن ثابت/خطي لكذا كذا...
في بايثون هناك lists و tuples وهناك set و deque وفي بايثون هناك dict و defaultdict و ordereddict ...إلخ كل هذه الفروقات بينها فروقات ذات مستوى عال. بمعنى هي interfaces يمكنك تخصيصها أو الدمج بينها.
وصلنا لشئ مهم، كلمة أنا :). ما تعتبره غير مهم، يعتبره غيرك (بسبب اختلاف الهدف) مهم. قبل فترة اشتهرت لغة Go بشكل جدا غريب. حاول البعض إقناع أنفسهم أنها الأفضل لكل شئ. لكن، سأحاول البحث عن الموضوع، شخص اكتشف أن اللغة تفقد عنصر data structure جدا مهم يحتاجه. و اللغة لا توفر هذا النوع، فكحالة أغلب المبرمجين، قام ببناء مكتبة. اكتشف أن الوقت ضاع في هذه المكتبة، و كانت مبنية على data structure آخر. في النهاية غير اللغة بشكل كامل إلى جافا بحكم خبرته الطويلة فيها. لكل لغة فيها data structure مدمج للأشياء التي تراها مهمة و مناسبة للتطبيقات المبرمجة باللغة.
أخي الحبيب تلك اسمها game وفي رأس الصفحة يذكرون أنها لا تصلح كمقياس أو نتيجة معينة. ماذا نستنتج من أن لغة جافا تستطيع اكمال حلقتين تكراريتين متداخلتين لعمل ترتيب فقاعي أسرع من بايثون (دون استعمال دالة الترتيب عالية المستوى في اللغتين). إن كان هناك وظيفة لتلك القياسات فهي المستعدة في تحسين المفسرات مع الزمن (مقارنة مع نفس اللغة)
الكثير يأخذ البرمجة هواية، و يلقب كل شئ بشئ يحبه. مسميات متغيرات غريبة، مسابقات يسميها ألعاب، و غيرها. المسمى هنا غير مهم. لكن المهم شئ آخر. صحيح ذكر
tl;dr
Measurement is highly specific -- the time taken for this benchmark task, by this toy program, with this programming language implementation, with these options, on this computer, with these workloads.
بمعنى الاختبار تم ببيئة معينة و النتيجة قد تتغير من جهاز إلى آخر. لكن في النهاية ما نطمح إلى معرفته هو مقارنة التنفيذ. لكن في حالة طلب مني عميل برمجة تطبيق real time، لغة بايثون ستكون من أسوأ لغات البرمجة بسب سرعة تنفيذها. مثلا، موقع Quora مبرمج بشكل كامل ببايثون، لكن احتاجوا لمحرك بحث سريع، معناه سرعة تنفيذ. فـ كتبوا محرك البحث بلغة C أو ++C لا أذكر. تصميم الخوارزميات التي تحتاج لسرعة أغلبها يتم بلغات compiled languages و ليست scripting languages. حتى و لو كان عدد سطور scripting أقل بعشرين ضعف، لكن الأداء هو من سيجلب العملاء، العملاء لن يهمهم كم سطر وفرت بل الأداء.
هناك معضلتان. الأولى وجود قصور في المكتبة القياسية استدعت الحاجة لمكون من طرف ثالث.
كما ذكرت سابقا في هذا الرد، كل لغة ترا اللازم و تضعه. (أنا أتكلم من ناحية مكتبات تستفيد منها في تطبيقك) و لكل لغة تستطيع أنت كشخص اقتراح اضافة ما ينقص، و مجتمع اللغة سيقرر حينها.
المشكلة لا تقف هنا المشكلة عندما تحتاج مكون خارجي يستخدم هذه ومكون خارجي آخر يستخدم تلك.
في بايثون مثلا هناك تصميم واع للواجهة البرمجية بحيث يمكنك الإنتقال بين العديد من الحزم دون تغير أي شيء في الكود. مثلا يمكنك تغير خادم الويب الضمن في برنامك من Paste إلى cherrypy. بل يمكنك نقل برنامجك من التعامل مع multiprocess إلى mulithreads أو بالعكس ببساطة لأن لهما نفس الواجهة البرمجية لأن التصميم عالي المستوى لكليهما أتى ليحل نفس المشكلة وهيأني أريد تنفيذ العديد من الأشياء معا.
بصراحة لم أعمل على هذا الشئ فأنت الخبير هنا :)
آسف لم أكن واضحا. صحيح بايثون يعمل في كل مكان. لكن هل حاولت نقل برنامج مكتوب ببايثون من لينكس إلى ويندوز؟ ستحتاج إلى بندول :) قبل فترة احتجت نقل برنامج، و كان يحتاج numpy. تحميلها في لينكس جدا سهل لكن أتذكر لم أستطع تحميلها بسهولة. بحثت كثيرا و حللت مشكلة مشكلة إلى أن وصلت إلى طريق مسدود. بعدها و بالصدفة اكتشفت موقع يوفر المكتبات المشهورة للبايثون على شكل exe للويندوز
هناك pypi و easy_install كل ما عليك هو pypi install numpy
لكن لو كنت تعمل على الجافا، اسحب ما تسميه JAR HELL إلى class path و انتهينا :)
ما عنيته أنه عندما يكبر المشروع ستجد أنك تستخدم الكثير من مكتبات الطرف الثالث (والكثير منها يؤدي نفس الغرض) بسبب قصور المكتبة القياسية.
من الطبيعي أن تحتاج مكتبة من طرف ثالث لتقوم بما تقوم به numpy أو pygame لكن ليس من الطبيعي أن تحتاج مكتبة من طرف ثالث لجلب شيء من الإنترنت أو لعمل خادم http.
لكل لغة فيها data structure مدمج للأشياء التي تراها مهمة و مناسبة للتطبيقات المبرمجة باللغة.
ما قلته أنا يسمى في هندسة البرمجيات باسم least knowledge principle
الكثير يأخذ البرمجة هواية، و يلقب كل شئ بشئ يحبه. مسميات متغيرات غريبة، مسابقات يسميها ألعاب، و غيرها. المسمى هنا غير مهم. لكن المهم شئ آخر. صحيح ذكر
ليس هذا معنى الكلام المقتبس معناه أن تلك الإختبارات هي لبرمجيات دمية غير حقيقية لا تنعكس على الأداء الفعلي في المسائل الحياتية. انظر مثلا لماذا لا يعد glxgear اختبار قياس أداء بين بطاقات الشاشة المختلفة
كُنت استخدم دلفي لفترة طويلة (حوالي ١٤ عاماً) وكنت لا أحب الجافا أو أي لغة تعتمد على مكتبة وسيطة للتشغيل virtual machine لكن تعلمت جافا من ثلاث سنوات ومازلت استخدمها ولم أجد فيها العيوب التي كُنت أسمعها عنها، فقط كثرة استهلاك الذاكرة وأحياناً مشكلة اختيار منصة Java 6 أم Java 7 لكن غير ذلك لم اجد فيها مشاكل، وهي حل جيد لتعدد المعماريات والمنصات، وصحيح إنتاجيتها اقل قليلاً من اللغات اﻷخرى (خصوصاً دلفي) لكن وجدت في سرعة التطوير مشاكل كثيرة في المستقبل، مثلاً طريقة drag-and-drop الموجودة في دلفي وفيجوال بيسك ينتج عنها أجزاء من الكود لا يُمكن اﻹستفادة منها وذلك لإرتباط الـ presentation بالـ business implementation . وعندما أكون مدير لمشروع اُفضل أن يستخدم المبرمجين الجافا لإنتاج كود متقن في وقت متأنى بدلاً من سرعة اﻹنتاجية التي ينتج عنها في النهاية كم هائل من اﻷخطاء وسوء التصميم وينتج عنه تأخير في تسليم المشروع واحياناً ينتج عنها إعادة تصميم الكود مرة أخرى بطريقة أفضل لكن بعد خسائر مادية
كم هائل من اﻷخطاء وسوء التصميم
كلام سليم عندما يتعلق الأمر بلغة بيرل (أعلى إنتاجية من جافا لكنها أقل نظافة ومقروئية) وليس بايثون أو سي/سي++ وكلاهما أعلى إنتاجية من جافا وفي نفس الوقت كلاهما أعلى مقروئية. بايثون هي اللغة رقم واحد من حيث المقروئية وحسن التصميم.
مثلاً طريقة drag-and-drop الموجودة في دلفي وفيجوال بيسك ينتج عنها أجزاء من الكود لا يُمكن اﻹستفادة منها وذلك لإرتباط الـ presentation بالـ business implementation
كلام جميل. لكن في الأمر الذي اقترحته وهو Qt يتم فصل التمثيل presentation حيث يقبع في ملف xml (سواء عبر QML أو عبر ملفات .ui)
فقط كثرة استهلاك الذاكرة وأحياناً مشكلة اختيار منصة Java 6 أم Java 7 لكن غير ذلك لم اجد فيها مشاكل
في عالم الإنتربرايز تلك ليست مشكلة كبيرة ببساطة يتم إنفاق المزيد من المال في الذاكرة والخوادم بالنسبة لهم تلك ليست مشكلة (ربما إلى أن يصل عدد الخوادم إلى رقم فلكي يصبح من شبه المستحيل إدارتها أو يكون أداء البرنامج سيء مهما زدت عدد الخوادم بسبب عبئ إدارة هذا الكم الكبير مثلا عملية البحث عن الخادم الذي يحتوي المفتاح بحد ذاتها تحتاج جهد)
نعم تويتر بدأ يزيد من الاعتماد على جافا (ويهرب من روبي) لأن جافا لغة تكبر معك scale up well
في المقابل لا يمكن أن تقول نفس الشيء عن سي/سي++ ولا عن بايثون (هذه الأخيرة خلفيتها من مراكز الأبحاث العلمية العملاقة وهي السباقة في مجال ال scaling)
لكن هل حقا تريد أن تدخل مجال لغة مبذرة إلى تلك الدرجة حيث تحتاج 30 خادم لعمل شيء بسيط؟ ولأجل ماذا تطبيقات سطح مكتب؟ ماذا ستقول للزبون ضاعف الذاكرة أو اعمل خادم كاش/ذاكرة منفصل واربطه مع جهازك؟
كنت احمل نفس الفكرة عن جافا في أنها تحتاج إلى مزيد من العتاد، لكنها غير الذاكرة لا تحتاج لشيء آخر، قمت بتشغيلها في أجهزة قديمة لنظام كبير وهو يعمل بدون ان يستهلك من موارده الكثير، مخدمات بها ٢ قيقا بايت رام وأخرى ٤ قيقا، بالنسبة للمعالج فهي لم تستهلك كماً كبيراً.
يختلف كل مجال من المجالات اﻷخرى فأنت مثلاً أخ مؤيد بحكم عملك في نظام أعجوبة لينكس، فربما تميل لعمل برامج سطح مكتب ومن شروطها أن تكون قليلة اﻹستهلاك للموارد ولا تعتمد على مكتبات أخرى مثل مكتبة جافا وأن تكون سريعة التشغيل، هذا كله غير متوفر في جافا، أما بالنسبة لي كمبرمج أنظمة اتصالات فمعظم البرامج هي عبارة عن خدمات ويب web services وهي ماتبرع فيه جافا بجدارة وهذا يُعادل تقريباً ٨٠٪ من البرامج التي نتحتاجه. في باقي البرامج اﻷخرى والتي تستخدم سطح المكتب استخدم لغة أوجكت باسكال متمثلة في أداة التطوير لازاراس، فهي أفضل من جافا من حيث استهلاك الموارد والسرعة في اﻹقلاع واحتياجها لموارد بسيطة، وهي ايضاً تستخدم المكتبات المتوفرة في النظام مثل GTK في لينكس و QT أيضاً.
لكن مرة قُمت بعمل تجربة لتشغيل جهاز راسبري باي ذو معالج آرم ٧٠٠ ميغاهيرتز، وذاكرة ٥١٢ ميغا، البرنامج المكتوب بلغة لازاراس لم يعمل حيث أنه كان ذو معمارية I386 ولم استطع إنتاج برنامج لمعمارية ARM فهو يحتاج إلى cross-compliation وهي عملية معقدة قليلاً لم استخدمها في لينكس، فقط في وندوز، لكن برنامج جافا الذي يستخدم مكتبة Swing فقد عمل مباشرة في جهاز راسبري باي ولم يكن فيه بطيء يُذكر، كذ
كذلك قُمت بتشغيل Tomcat7 في الراسبري باي وعليها برنامج ويب Servlet وقد عمل بسرعة واستجابته كانت سريعة، فقط في البداية عند أول استدعاء يكون بطيء.
أما بالنسبة للسرعة فقد قارنت مرة دالة لمعرفة العدد اﻷولي، رقم أكبر من ٢ مليار، اي يحتاج لـ ٢ مليار دورة، كانت سرعة البرنامج المكتوب بدلفي، ولازاراس، وسي++ و جافا متساوية، تقريباً ٦ ثواني في نفس الجهاز على ما اذكر، لكن سي شارب كانت أبطىء حيث بلغت ٩ ثواني، لا اذكر هل هي ثواني أم دقائق، كان هذا من قبل ٣ سنوات.
النظام الذي يعمل على مخدمات والمكتوب بجافا لم يتم عام على بدايته، والمستخدمين في زيادة، سوف أوافيك بتفاصيل أكثر عن تلك الدراسة بعد زيادة المستخدمين وزيادة اﻹستخدام في المستقبل بإذن الله.
بالنسبة للخوادم، فقد قمت بتصميم وتنفيذ مشروع كبير لشركة اتصالات كانت تعتمد على وندوز في مخدماتها، اﻵن هم ينظرون إلى جافا ولينكس على أنهما حل للحد من شراء مخدمات جديدة، حيث إلى اﻵن لم نطلب شراء أي مخدم جديد بل استخدمنا مخدمات كانت في طريقها إلى المخازن في نهاية عمرها، وهي تعمل اﻵن لمدة ١٠ اشهر دون ان يزيد استهلاك المعالج عن ٢٠٪ وعدد المستخدمين لتلك الخدمات يصل إلى اكثر من ٣٠٠٠ ألف عميل في اليوم وهم في زيادة
فأنت مثلاً أخ مؤيد بحكم عملك في نظام أعجوبة لينكس، فربما تميل لعمل برامج سطح مكتب
السؤال عن سطح المكتب. لكن لا تنس أني أيضا أعمل على خوادم شركة جيران (نستعمل جافا في محرك البحث) وكنا في أعجوبة نستعمل جافا في موقع مقولة (قبل نقله إلى PHP) تجربتي مع جافا على الخادم سيئة فهي مناسبة للشركات التي تقبل الحل "حسنا لنطلق 10 خوادم جديدة لتساند ال 20 خادم العاملة". فموقع مقولة على بساطته كان يكبل الخادم ويكاد يقع مع أن مواصفاته فلكية.
لكن مرة قُمت بعمل تجربة لتشغيل جهاز راسبري باي ذو معالج آرم
اللغة المفضلة عند مجتمع raspberrypi هي بايثون أقتبس من
2. Does it have an official programming language?
The Raspberry Pi Foundation recommends Python as a language for learners.
مشروع كبير لشركة اتصالات كانت تعتمد على وندوز في مخدماتها
حبة البطاطا أفضل من ويندوز وتقنياتها على الخوادم لذا بالتأكيد جافا أفضل منها. لكن لا أفضلية للغة جافا على بايثون في هذا المجال سوى نضوج سوق جافا.
اللغة المفضلة عند مجتمع raspberrypi هي بايثون أقتبس من
أنا لم اقل أن جافا لغة مُناسبة مع raspberrypi لكن قصدت أنها عملت في هذا العتاد المتواضع، فمابالك بعتاد افضل منه.
السؤال عن سطح المكتب. لكن لا تنس أني أيضا أعمل على خوادم شركة جيران (نستعمل جافا في محرك البحث) وكنا في أعجوبة نستعمل جافا في موقع مقولة (قبل نقله إلى PHP) تجربتي مع جافا على الخادم سيئة فهي مناسبة للشركات التي تقبل الحل "حسنا لنطلق 10 خوادم جديدة لتساند ال 20 خادم العاملة". فموقع مقولة على بساطته كان يكبل الخادم ويكاد يقع مع أن مواصفاته فلكية.
هذا يعتمد على طريقة البرمجة والخوارزميات نفسها، فيمكن أن لأي شخص حتى لو كان مبرمج محترف أن يُخطيء في كتابة كود بطريقة تجعله يستهلك الموارد ويتسبب في عدم استقرار النظام، حدث معي هذا كثيراً لكن لا نلقي العيب في لغة البرمجة وحدها، بل في المبرمج أولاً. مرة كان لدي برنامج بالجافا يحتوي على scheduled task يعمل على اللابتوب فأصبح اللابتوب بطيء ثم أنطفى، وعندما اعدت تشغيله وجدت أن حرارة المعالج قد وصلت ٨٠ درجة، وهذا بعد أن برد قليلاً، فصرت كلما أقوم بتشغيل هذا البرنامج ترتفع معه حرارة المعالج، قمت بعمل تعديلات وضبط في الـ scheduled task وقمت بتعديل الـ query الذي يحدث في هذا اﻹجراء فرجع الوضع إلى رقم أقل من ١ في uptime في لينكس. اي لم القى اللوم على جافا أنها كادت تتسب في حرق معالج الجهاز، لكن كان اللوم على الخوارزمية.
المواصفات الفلكية التي تتكلم عنها هذا مبالغ فيها. لكن في النهاية تجربتي مع جافا لم تكتمل (٣ سنوات بسيطة) احتاج لوقت اطول حتى يظهر لنا انها لغة مناسبة أم لا، لكن إلى اﻵن كل البرامج التي تعمل بالجافا طوال هذه الفترة ليست فيها أي مشكلة متعلقة باﻷداء.
حبة البطاطا أفضل من ويندوز
عملت على نظام وندوز في مخدمات لفترة طويلة من الزمن، ومازال بعضها يعمل أكثر من ١٠ سنوات بدون دعم يُذكر، فهو ليس بهذا السوء، مع اني لا احب أن استخدمه في المخدمات لكن الكفاءة ليست كل القصة.
شكرا لك. سرني تبادل الخبرات معك وهي في النهاية مجرد أذواق.
لا نلقي العيب في لغة البرمجة وحدها، بل في المبرمج أولاً
نحن لم نكتب كود solr مثلا بل هو من كتابة المحترفين في مؤسسة أباتشي وهي من المؤسسات العريقة في هذا المجال.
عملت على نظام وندوز في مخدمات لفترة طويلة من الزمن، ومازال بعضها يعمل أكثر من ١٠ سنوات بدون دعم يُذكر،
خلال أول شهر من الإنتقال من ويندوز إلى لينكس قمنا بتوفير 90% من كلفة الخوادم.
خلال أول شهر من الإنتقال من ويندوز إلى لينكس قمنا بتوفير 90% من كلفة الخوادم.
هذا رقم كبير
نحن مازلنا في بداية التحول إلى لينكس في المؤسسات التي نعمل معها، واحيانًا نجد المقاومة من مهندسي تقنية المعلومات المتعودين على إدارة مخدمات وندوز، إن شاء الله سوف نستصحب هذا الرقم في مناقشاتي معهم. ومنكم نستفيد وشكراً لك على هذا النقاش.
التعليقات