السلام عليكم ..
أنا متقن لـ HTML - Css وأساسيات JS
أريد البدء بتعلم لغة برمجة
هل أتعلم PHP أم Ruby أم Python ولماذا
أم أتوجه لـ إحدى اللغات الجديدة مثل Go
وبالنسلة لقواعد البيانات أيها أفضل Oracle أم Sql ولماذا
أريد تفاصيل كاملة أرجوكم والفروق الفوائد والأضرار لكل تفصيل :] ..
اللغة ليست مهمة يمكنك الذهاب مع php في إطار مثل yii أو بايثون في إطار django.
عنق الزجاجة ليس في اللغة. لغة php "قذرة" (وتدفعك نحو كتابة برامج سيئة) حاول أن تختار إطار عمل نظيف.
ابتعد عن روبي فهي تبدد موارد الجهاز والرام (رأي شخصي عن خبرة)
أم أتوجه لـ إحدى اللغات الجديدة مثل Go
لغة ممتازة وتعطي برامج سريعة جدا مثل لغة سي. اعتبرها مثل إعادة كتابة سي++ بطريقة حديثة. أفضل أن تؤجلها حتى تكتسب خبرة أكبر.
وبالنسلة لقواعد البيانات أيها أفضل Oracle أم Sql ولماذا
تعلم أساسيات sql من خلال sqlite و sqlite manager بعد ذلك كل ال sql ستكون متشابهة بالنسبة لك.
كما أن مجتمع Arabia تمت برمجته بالروبي .. أجده جيد
هل تقصد أنها تبدد موارد الجهاز والرام عند استخدامها مكتبياً أم لكل شخص يتصفح موقع تمت برمجته بها ؟
الأخ مؤيد كما نقول python fanboys , هو يذكر لك مشاكل في اللغات الأخرى لتستنتج أن python هي الأفضل . php ليست قذرة و إطار العمل yii ليس الأفضل ,
وبالنسبة للأخ بلال سامحك الله. ولن أرد عليك.
يا طلال أنا أيضا نصحتكك بها أيضا لكني حذرتك من عيبها. هناك لغات مثل بيرل و php من المتعارف عليه أنها قذرة. ها ليس رأي شخصي هذا حقيقة. مثلا يكون هناك أكثر من طريقة للقيام بالشيء (لأنه لا يوجد تخطيط) هناك أشياء تتم من وراء ظهرك (أشياء ضمنية أو متغيرات عامة مثل $_ و $_GET وهناك مليون احتمال مثلا قيمة ال mbstring.func_overload في php.ini وقيمة error_reporting وقيمة display_errors .... كل هذا ليس جزء من الكود الذي يعيش في git عندما تحدث مشكلة عليك أن تتصيد مليون شيء وتعايره ...) كذلك هناك غباء في تصميم ال OOP وهناك غباء في ال memory management بل إن صاحب لغة php يجاهر علنا بأنه جاهل بهذه الأشياء.
لغة php جيدة لأنها مخدومة (هناك مليون حل خارجي لمشاكلها الداخلية) مثلا موضوع تسريب الذاكرة يمكنك إعداد أباتشي أن تقتل مفسر php بعد 500 معالجة طلب مثلا (فلو كان هناك 500 كيلوبايت تسريب في الذاكرة لكل طلب فإن معالجة 500 طلب تستهلك 250 ميغا كانت ستتظل تتراكم حتى يقضى على النظام لكن عوضا عن حل جذر المشكلة بإنهاء التسريب يتم قتل مفسر php لتحرير الذاكرة وتشغيل واحد جديد) هذا النوع منتشر لكل مشاكل php لأنها لغة قديمة وكل مشاكلها معروفة مدروسة ولها حلول خارجية. بمعنى وإن كنت أنصحك في لغة php هذا لا يعني أني أقر بأنها لغة حسنة التصميم بل هي من تصميم شخص لا يفهم شيء عن البرمجة باعترافه.
بخصوص روبي هي تعاني من مشاكل في ال scalability. لزيادة قدرة روبي على معالجة الطلبات المتزامنة عليك زيادة عدد الخوادم وزيادة الذاكرة. لا يمكن معالجة المزيد من الطلبات بتوزيعها على threads. وهذا كلام موثق سواء من مستخدمي روبي الكبار مثل github ومن مصنعي خوادم روبي ومن خبرتي العملية في أكثر من مشروع يستخدم روبي.
في الكثير من الأحيان تشغيل 30 سيرفر إضافي ليتم توزيع الحمل عليها أسهل وأقل كلفة من إعادة تصنيع المنتج بلغة أخرى. وهذا ما فعلته github. ودعني أخبرك كيف تعمل github. حيث كان هناك سؤال على quora.com عن بنية github وأجاب رئيس لا أذكر ماذا فيه بأن github يتمحور حول الملفات (التي يديرها git) بكلمات أخرى لا يوجد الكثير من الحمل على تطبيق الويب (العمل الحقيقي مثل الفرق بين الملف القديم والجديد ومن عدل ماذا ومتى ... لا يتم في تطبيق الويب بل في git على خوادم الملفات) لكن مع ذلك كان عنق الزجاجة عندهم في خوادم روبي (رابط كورا ليس معي لكن يمكن قراءة ).
ruby و python ليدهم نفس المشكلة .. Global Interpreter Lock
بخصوص '' لا يمكن معالجة المزيد من الطلبات بتوزيعها على threads ''
https://wiki.python.org/moi...
كلامك صحيح ruby تستحدم الذاكرة بشكل اكبر .. لاكن باخر الاصدارات يوجد محاولات لحل المشاكل الذاكرة. بعد اصدار 2.0
وما تتحدث عنه هو المشكلة صحيح لكن ليس لمطور عادي
السؤال الاهم راحة المبرمج انا تعلمت python بالجامعة لكن بعدها لم اكتب شئ. المشكلة ليست باللغة. انا لم ارتح بها :)
نصحية لصحاب الموضوع .. ابحث عن لغتك المفظلة .. وليس على ما يحبه المطورين الاخرين. انت الذي ستكتبت الكود البرمجي وليس هم :).
لا أتحدث عن GIL. يا رجل لا يوجد threading في rails ما قبل 4 بمعنى كل طل طلب في process وبكامل حجم الذاكرة (يبدو أن هناك shared state تمنع من استخدام ال threads). دعني أقتبس http://uwsgi-docs.readthedo...
Starting from 4.0, Rails support multiple threads (only for ruby 2.0):
فيما يتعلق ب GIL هي موجودة في cpython فقط وغير موجودة في jython و pypy (وهو ال JIT compiler) وهو موجود في الأول لأنه أسرع وهو ليس عنق الزجاجة.
بايثون تدعم مليون حل يمكنك من معالجة أشياء متعددة في نفس ال thread و ال process منها gevents و eventlets و asyncio و tulip. والجميل أن جزء كبير يتم دون أي تغيير في كود التطبيق (مثلا من خلال ال monkey patching)
أما روبي فيوجد فايبر fiber ولا يبدو لي أنه يعمل كخيار مجرد زر أضغطه فيتحول برنامجي إلى برنامج async
نصحية لصحاب الموضوع .. ابحث عن لغتك المفظلة .. وليس على ما يحبه المطورين الاخرين. انت الذي ستكتبت الكود البرمجي وليس هم :)
أتفق تماما معك لذا أقول دائما اختيار اللغة ليس عنق الزجاجة.
فيما يتعلق ب GIL هي موجودة في cpython فقط وغير موجودة في jython و pypy (وهو ال JIT compiler) وهو موجود في الأول لأنه أسرع وهو ليس عنق الزجاجة.
ruby لديها ايضا jruby وغيرها بدون GIL
Starting from 4.0, Rails support multiple threads (only for ruby 2.0):
http://tenderlovemaking.com...
بعد الاصدار 4 اصبح يدعم concurrent بشكل افتراضي قبل ذلك يجب عليك تغير الاعدادت.
threading في rails ما قبل 4 بمعنى كل طل طلب في process وبكامل حجم الذاكرة
راجع ايضا thin
gevents و eventlets و asyncio و tulip
eventmachine
وغيرها الكثير ابحث ستجدهم :)
عموما بايثون اجده مدعوم اكثر حتى في النطاق الاكاديمي ... لاكن هذا لا يقلل من شان Ruby
اعتذر لم اشرح شئ ... لدي اختبارات بالجامعة :]
ruby لديها ايضا jruby وغيرها بدون GIL
أنا لم أتحدث عن GIL فهي ليس عائق. هي مجرد "اختيار" عند تصميم اللغة. وفي بايثون تم تجربة عمل CPython بدون GIL ونجحت التجربة لكن كان المفسر أبطأ
بعد الاصدار 4 اصبح يدعم concurrent بشكل افتراضي قبل ذلك يجب عليك تغير الاعدادت.
نعم أنا ذكرت ذلك حرفيا لكن بكلمات اخرى حيث قلت قبل الإصدار الرابع لم يكن هناك threads. لحظة لحظة. كلا أخي الحبيب قبل ذلك لم تكن موضوع إعدادات. روبي 1.8 وريلز قبل 4 لا تدعم ال threads وتفعيله يؤدي إلى مشاكل قولا واحدا.
أقتبس
Starting from 3.0, Rails is fully Rack compliant
Starting from 4.0, Rails support multiple threads (only for ruby 2.0):
بمعنى قبل هذا الإصدار هناك shared state ولا يمكن أن تخديمه في خادم متعدد threads العلة ليست في الخدام فحتى لو دعم puma تعدد الخوادم فإن rails لن تدعمه.
في بايثون هناك شيء اسمه WSGI وهو الشيء الموجود في كل أطر العمل ويمكن كتابة تطبيق ويزجي في سطرين بمجرد أن يدعم أي إطار عمل مثل جانغو ويزجي يمكنك أن تخدمه دون تعديل بأي طريقة تشاء سواء threads أو async io أو green threads ... دون أن يترتب على ذلك تغير في الكود. يمعنى لا نقول جانغو الإصدار الكذا يدعم gevents أما قبل ذلك فلا يدعمه. يمكن تشغيل إصدارات قديمة من جانغو بخوادم تستخدم تقنيات حديثة لم تكن عندما صدر ذلك الإصدار القديم.
التعليقات