في الأيام القليلة الماضية ، تم نشر عدد من المقالات حول هبريه ، وكان المفهوم العام منها (وخاصة في التعليقات) هو المواجهة بين الأشخاص الصريحين والموجهين - أتباع الجبهة الشعبية لتحرير فلسطين ضد منظمة التحرير الفلسطينية ، على الرغم من أنه تم حثهم على عدم المجادلة. نوقش إرلانج في بعض الأحيان ، وفي ما يتعلق بي ، تذكرت موضوعًا قصيرًا عن موضوع من جو أرمسترونغ ، أحد المبدعين لهذه اللغة ، الذي كتبه في نهاية عام 2018 في منتدى Elixir ردًا على سؤال حول نموذج اللغة. أعتقد أن تعليقه سيكون مثيرا للاهتمام.
جو ارمسترونغ 12 سبتمبر 2018
ترتبط كل الأشياء الجيدة حول Elixir (و Erlang) بالتزامن - فقط قم بإنشاء عمليات مستقلة ومراسلة. وهذا هو بالضبط جوهر البرمجة الموجهة للكائنات ، كما أشار آلان كاي مرارًا وتكرارًا.
OOP مكرس بالكامل للأشياء. تستجيب الكائنات (أو يجب أن تستجيب) للرسائل ، وعندما تريد أن تفعل شيئًا ما ، فأنت ترسل رسالة إلى الكائن ، وكيف أن معالجته غير ذي صلة تمامًا. فكر في الأشياء على أنها "صناديق سوداء" ، وعندما تريد شيئًا منها - فقط أرسل رسائل ، وسوف يرسلون إليك رسائل ردًا.
لا يهم كيف يتم ترتيب كل شيء في الداخل ما إذا كان الكود الموجود داخل الصندوق الأسود وظيفيًا أو ضروريًا - ما يجب فعله بالضبط هو المهم فقط.
لسوء الحظ ، على الرغم من أن أول لغة ناجحة موجهة للكائنات تعتمد على هذا النموذج (Smalltalk) تعمل على مفهومي "الكائن" و "الرسالة" ، فإن الأخير في Smalltalk لم يكن رسائل حقيقية ، ولكن فقط مكالمات دالة متزامنة متخفية. تم تكرار الخطأ نفسه في C ++ ، ثم في Java ، وتقلصت الفكرة الرئيسية لـ OOP إلى نموذج غريب لتنظيم التعليمات البرمجية في فئات وأساليب.
يجعل Erlang و Elixir من السهل إنشاء ملايين العمليات المنعزلة حيث يعمل كل شيء عن طريق إرسال رسائل بينهما. يتم تحديد بنية النظام حسب مستوى التوازي الذي تريده ، مع تخطيطه اللاحق للعمليات مباشرةً.
خادم الويب Elixir لـ 10000 مستخدم ليس "خادم ويب واحد به 10000 مستخدم" (كما هو الحال مع Apache أو Jigsaw وما شابه) ، ولكنه "خادم خوادم الويب لكل مستخدم" - توافق ، جذري الخروج عن النموذج التقليدي.
حقيقة أن لغة وظيفية بسيطة قد استخدمت لوصف نموذج عملية إرلانج / إكسير هي مجرد حادث. بدأ كل شيء بنظام البرمجة المنطقية (Prolog) ، ويمكن كتابة أشياء مثل C-node ، على سبيل المثال ، بأي لغة على الإطلاق. إن الشيء المهم حقًا بالنسبة لـ Elixir (وأي لغة BEAM أخرى) هو قدرة أجهزتهم الافتراضية على العمل مع عدد كبير للغاية من العمليات الموازية.
قلت لوقت طويل أن "إرلانج هي اللغة الحقيقية الوحيدة الموجهة للكائنات". أعتقد الآن أنني يمكن أن أضيف إليها وإكسير.
بالنسبة إلى OOP ، الأشياء الأساسية هي:
- العزلة بين الأشياء (لدينا)
- الربط المتأخر (نقرر ما يجب القيام به فقط عندما تتلقى العملية رسالة)
- تعدد الأشكال (يمكن أن تستجيب جميع الكائنات لرسالة من نفس النوع ، على سبيل المثال ، "تطبع بنفسك" ويمكن لأي كائن معرفة كيفية القيام بذلك)
أقل أهمية بكثير:
- التقسيم إلى فصول وأساليب
- بناء الجملة
- نموذج البرنامج (وظيفي أو ضروري)
بعد أن قسمنا النظام إلى عدد كبير من العمليات الصغيرة التي تتواصل مع بعضها البعض ، يصبح كل شيء آخر سهلاً (نسبيًا) - يجب أن تكون كل عملية بسيطة جدًا وتكون قادرة على القيام ببعض الشيء ، مما يسهل البرمجة إلى حد كبير.
ما جلبه إرلانج (وإكسير) إلى البرمجة هو فكرة الاتصالات (link - approx. Translator). تم اقتراحه مبدئيًا من قبل مايك ويليامز ، وهو يتألف من توسيع نطاق إمكانية معالجة الأخطاء ، مما يتيح القيام به خارج حدود العمليات. بعد ذلك ، حصلنا على جميع الأدوات اللازمة لبناء أشجار المشرفين ، إلخ.
يعد المشرفون و gen_server وكل موسيقى الجاز هذه مجرد مكتبات تخفي بعض التفاصيل عن المستخدم. بسيطة داخل ، مكتوبة باستخدام نفس الأدوات - عمليات موازية والعلاقات بينهما.
لم يتم تطوير Erlang كلغة برمجة وظيفية ، ولكن كأداة لإنشاء أنظمة طويلة الأمد تتحمل الأخطاء.
العنصر الأساسي للتسامح مع الخطأ هو مفهوم معالجة الأخطاء عن بُعد. في حالة فشل النظام بالكامل ، يجب تصحيح الخلل (التعويض) على جهاز آخر ، لأنه من المستحيل بالفعل القيام بذلك محليًا - لا يعمل الكمبيوتر المحلي.
هذا يعني أنه بالنسبة لأنظمة البرمجة التي تتحمل الأخطاء ، نحتاج إلى توزيع (العمليات) والرسائل لتكون أدوات سهلة الاستخدام ، ولهذا السبب ، من حيث المبدأ ، فإن أي بنية تتحمل الأخطاء ستظهر في نهاية المطاف مثل Erlang.
الهدف من إنشاء Erlang هو تبسيط برمجة الأنظمة التي تتحمل الأخطاء ، وكان من الآثار الجانبية لذلك سهولة برمجة الأنظمة القابلة للتطوير.
يكمن الاختلاف بين Erlang و Elixir و "أي شخص آخر" في آليات ضمان التزامن والتسامح مع الخطأ ، وهذا لا يتعلق بالموناد أو بناء الجملة أو "النقاء" في FP.
والسؤال المطروح الآن هو - هل تريد معالجة 10000 مستخدم في مؤشر ترابط واحد ، باستخدام عمليات رد الاتصال لمضاهاة التزامن ، أو هل ما زلت ترغب في إنشاء 10000 عملية متوازية ، كل واحدة منها بسيطة ولا تحتاج إلى عمليات رد اتصال على الإطلاق؟
كل عملية تنتظر الرسالة التي تهتم بها ، ثم تقوم بإجراء العمليات الحسابية وتغفو تحسباً للخطوة التالية.
أعتقد أن المشكلة الكبيرة في تعميم Erlang / Elixir هي أنك تحتاج إلى شرح كيف تساعد الكثير من العمليات الموازية في حل مشكلتك المحددة. نظرًا لعدم وجود لغات مشتركة أخرى كانت تهدف في البداية إلى البرمجة المتوازية ولم تسهلها بأي طريقة مفيدة ، فإن الحاجة إليها من أجل الناس ليست مفهومة ومفهومة بالكامل.
"لكن يمكنني أن أفعل كل شيء على عمليات الاسترجاعات في موضوع واحد" ، سيقولون. ويفعلون ذلك ، وهو أمر صعب للغاية. وأنت تسأل ، "ماذا يحدث إذا حصلت معاودة الاتصال في الحلقة أو ألقت استثناء؟" ، وإذا لم يفهموا السؤال ، فعليك أن تعمل بجد وشرحت المشكلة. ولكن إذا كان السؤال واضحًا ، فأخبرهم أن هناك بلدًا بعيدًا لا يلزم فيه إجراء عمليات رد اتصال لبرمجة التزامن.
يبدو أنه يمكن تخفيض كل ما سبق إلى ما يلي: يرجى عدم الإعلان عن Elixir كلغة برمجة وظيفية - إنها ليست كذلك. إنها لغة برمجة متوازية (CPL ، لغة البرمجة المتزامنة).
لا ترد على حجج مثل "لغتي الوظيفية أكثر وظيفية من لغتك". ولا تهتم حتى بالحديث عن الموناديات ، قم بتغيير الموضوع على الفور.
"- ما هو CPL؟"
"- أنت تعرف ، هذا هو ما صنع WhatsApp على ..."
من المترجم
بادئ ذي بدء ، أود أن أعرب عن أسفي لوفاة جو أرمسترونغ المفاجئ - توفي في 20 أبريل 2019. من الصعب التقليل من شأن مساهمته في تطوير الصناعة ، وكذلك موهبته كشعبية - الكتب والخطب والعمل النشط في مجتمعات إرلانج وإليكسير.
روابط مفيدة: