سوف أصف بإيجاز المهمة الرئيسية
وهو يتألف من إنشاء لغة برمجة من شأنها أن تكون ملائمة لوصف نموذج المجال والعمل معه. لجعل وصف النموذج طبيعيًا قدر الإمكان ومفهومًا للبشر وقريبًا من مواصفات البرنامج. ولكن في الوقت نفسه ، يجب أن يكون جزءًا من الكود بلغة برمجة كاملة. لهذا ، سيكون للنموذج شكل الأنطولوجيا وسيتكون من حقائق ملموسة ومفاهيم مجردة وعلاقات فيما بينها. ستصف الحقائق المعرفة المباشرة لمجال الموضوع ، والمفاهيم والعلاقات المنطقية بينها - هيكلها.
بالإضافة إلى أدوات النمذجة ، ستحتاج اللغة أيضًا إلى أدوات لإعداد البيانات الأولية للنموذج ، وإنشاء عناصره ديناميكيًا ، ومعالجة نتائج الاستعلامات الخاصة به ، وإنشاء عناصر النموذج الأكثر ملاءمة لوصفها في شكل خوارزمي. كل هذا أكثر ملاءمة للقيام به من خلال وصف تسلسل الحسابات صراحة. على سبيل المثال ، باستخدام OOP أو نهج وظيفي.
وبالطبع ، يجب أن يتفاعل كلا الجزأين من اللغة بشكل وثيق وأن يكمل كل منهما الآخر. بحيث يمكن دمجها بسهولة في تطبيق واحد وحل كل نوع من المشكلات باستخدام الأداة الأكثر ملاءمة.
سأبدأ قصتي بالسؤال عن سبب إنشاء مثل هذه اللغة ، ولماذا اللغة الهجينة وأين يمكن أن تكون مفيدة. في المقالات التالية ، أخطط لإعطاء لمحة موجزة عن التقنيات والأطر التي تسمح لك بدمج أسلوب تعريفي مع أسلوب إلزامي أو وظيفي. علاوة على ذلك ، سيكون من الممكن مراجعة اللغات لوصف الأنطولوجيات ، وصياغة المتطلبات والمبادئ الأساسية للغة هجينة جديدة ، وقبل كل شيء ، مكونها التصريحي. أخيرًا ، صِف مفاهيمه وعناصره الأساسية. بعد ذلك ، سننظر في المشكلات التي تنشأ عند استخدام النماذج التصريحية والإلزامية معًا وكيف يمكن حلها. سنقوم أيضًا بتحليل بعض مشكلات تطبيق اللغة ، على سبيل المثال ، خوارزمية الاستدلال. أخيرًا ، لنلقِ نظرة على أحد الأمثلة على تطبيقه.
يعد اختيار أسلوب لغة البرمجة الصحيح شرطًا مهمًا لجودة الكود
اضطر الكثير منا للتعامل مع دعم المشاريع المعقدة التي أنشأها أشخاص آخرون. من الجيد أن يكون لدى الفريق أشخاص على دراية بكود المشروع ويمكنهم شرح كيفية عمله ، وهناك وثائق ، والرمز نظيف ومفهوم. لكن في الواقع ، غالبًا ما يحدث ذلك بطريقة أخرى - استقال مؤلفو الكود قبل وقت طويل من وصولك إلى هذا المشروع ، لا يوجد توثيق على الإطلاق ، أو أنه مجزأ جدًا وقديم منذ زمن طويل ، وحول منطق الأعمال للمكون المطلوب ، محلل أعمال أو مشروع - يمكن للمدير أن يخبر فقط بعبارات عامة. في هذه الحالة ، تعد نظافة الكود وسهولة فهمه أمرًا بالغ الأهمية.
تتميز جودة الكود بالعديد من الجوانب ، أحدها هو الاختيار الصحيح للغة البرمجة ، والذي يجب أن يتوافق مع المشكلة التي يتم حلها. كلما كان بإمكان المطور تنفيذ أفكاره في الكود أسهل وأكثر طبيعية ، كان بإمكانه حل المشكلة بشكل أسرع وقل عدد الأخطاء التي يرتكبها. لدينا الآن عدد كبير نسبيًا من نماذج البرمجة للاختيار من بينها ، ولكل منها مجال تطبيقه الخاص. على سبيل المثال ، تُفضل البرمجة الوظيفية للتطبيقات التي تركز على الحساب لأنها توفر مزيدًا من المرونة في هيكلة ودمج وإعادة استخدام الوظائف التي تؤدي عمليات على البيانات. البرمجة الشيئيةيبسط إنشاء الهياكل من البيانات والوظائف من خلال التغليف ، والوراثة ، وتعدد الأشكال. OOP مناسب للتطبيقات الموجهة للبيانات. تعد البرمجة المنطقية ملائمة للمشكلات المستندة إلى القواعد التي تتطلب العمل مع أنواع البيانات المعقدة والمحددة بشكل متكرر مثل الأشجار والرسوم البيانية ، وهي مناسبة لحل المشكلات التوافقية. أيضًا ، البرمجة التفاعلية ، المدفوعة بالحدث ، متعددة الوكلاء لها نطاقاتها.
يمكن للغات البرمجة الحديثة للأغراض العامة أن تدعم نماذج متعددة. أصبح الجمع بين النماذج الوظيفية و OOP سائدًا لفترة طويلة.
البرمجة المنطقية الوظيفية الهجينة لها أيضًا تاريخ طويل ، لكنها لم تتجاوز العالم الأكاديمي أبدًا. يتم إيلاء أقل قدر من الاهتمام لمزيج من البرمجة OOP المنطقية والضرورية (أخطط للحديث عنها بمزيد من التفصيل في أحد المنشورات التالية). على الرغم من أنه ، في رأيي ، يمكن أن يكون النهج المنطقي مفيدًا جدًا في المجال التقليدي لـ OOP - تطبيقات الخادم لأنظمة معلومات الشركة. ما عليك سوى النظر إليه من زاوية مختلفة قليلاً.
لماذا أجد أسلوب البرمجة التصريحي أقل من قيمته
سأحاول إثبات وجهة نظري.
للقيام بذلك ، فكر في ما يمكن أن يكون عليه حل البرنامج. مكوناته الرئيسية هي: جانب العميل (سطح المكتب والجوال وتطبيقات الويب) ؛ جانب الخادم (مجموعة من الخدمات المنفصلة أو الخدمات المصغرة أو تطبيق مترابط) ؛ أنظمة إدارة البيانات (العلائقية ، والموجهة للمستندات ، والموجهة للكائنات ، وقواعد بيانات الرسم البياني ، وخدمات التخزين المؤقت ، وفهارس البحث). يجب أن يتفاعل الحل البرمجي مع أكثر من مجرد أشخاص - مستخدمين. يعد التكامل مع الخدمات الخارجية التي توفر المعلومات عبر واجهة برمجة التطبيقات مهمة شائعة. أيضًا ، يمكن أن تكون مصادر البيانات مستندات صوتية ومرئية ، ونصوص لغة طبيعية ، ومحتوى صفحات الويب ، وسجلات الأحداث ، والبيانات الطبية ، وقراءات أجهزة الاستشعار ، إلخ.
من ناحية أخرى ، يقوم تطبيق الخادم بتخزين البيانات في قاعدة بيانات واحدة أو أكثر. من ناحية أخرى ، فإنه يستجيب للطلبات الواردة من نقاط نهاية API ، ويعالج الرسائل الواردة ، ويستجيب للأحداث. لا تتطابق هياكل الرسائل والاستعلامات أبدًا مع الهياكل المخزنة في قواعد البيانات. تم تصميم تنسيقات بيانات الإدخال / الإخراج للاستخدام الخارجي ، وتحسينها للمستهلك لهذه المعلومات وإخفاء تعقيد التطبيق. تم تحسين تنسيقات البيانات المخزنة لنظام التخزين الخاص بها ، على سبيل المثال ، لنموذج البيانات العلائقية. لذلك ، نحتاج إلى طبقة وسيطة من المفاهيم التي ستسمح بدمج إدخال / إخراج التطبيق مع أنظمة تخزين البيانات. عادةً ما تسمى طبقة البرامج الوسيطة هذه طبقة منطق الأعمال وتنفذ القواعد والمبادئ الخاصة بسلوك كائنات المجال.
كما أن مهمة ربط محتوى قاعدة البيانات بكائنات التطبيق ليست سهلة. إذا كانت بنية الجداول في التخزين تتطابق مع بنية المفاهيم على مستوى التطبيق ، فيمكنك استخدام تقنية ORM. ولكن بالنسبة للحالات الأكثر تعقيدًا من الوصول إلى السجلات عن طريق المفتاح الأساسي وعمليات CRUD ، يجب عليك تخصيص طبقة منفصلة من المنطق للعمل مع قاعدة البيانات. عادةً ما يكون مخطط قاعدة البيانات عامًا قدر الإمكان ، بحيث يمكن للخدمات المختلفة العمل معه. كل منها يقوم بتعيين مخطط البيانات هذا إلى نموذج الكائن الخاص به. تصبح بنية التطبيق أكثر إرباكًا إذا كان التطبيق لا يعمل مع مخزن بيانات واحد ، ولكن مع عدة أنواع مختلفة ، يتم تحميل البيانات من مصادر خارجية ، على سبيل المثال ، من خلال واجهة برمجة التطبيقات للخدمات الأخرى.في هذه الحالة ، من الضروري إنشاء نموذج مجال موحد وتعيين بيانات من مصادر مختلفة إليه.
في بعض الحالات ، يمكن أن يحتوي نموذج المجال على بنية معقدة متعددة المستويات. على سبيل المثال ، عند تجميع التقارير التحليلية ، يمكن بناء بعض المؤشرات على أساس مؤشرات أخرى ، والتي بدورها ستكون مصدرًا لإنشاء التقرير الثالث ، إلخ. أيضًا ، يمكن أن يكون لبيانات الإدخال نموذج شبه منظم. لا تحتوي هذه البيانات على مخطط صارم ، على سبيل المثال ، في نموذج البيانات العلائقية ، لكنها لا تزال تحتوي على نوع من الترميز الذي يسمح لك باستخراج معلومات مفيدة منه. من أمثلة هذه البيانات موارد الويب الدلالي ، ونتائج تجريف الويب ، والمستندات ، وسجلات الأحداث ، وقراءات أجهزة الاستشعار ، ونتائج المعالجة المسبقة للبيانات غير المنظمة مثل النصوص ومقاطع الفيديو والصور ، إلخ. سيتم بناء مخطط البيانات لهذه المصادر حصريًا على مستوى التطبيق. سيكون هناك أيضًا رمز ،تحويل البيانات المصدر إلى كائنات منطق الأعمال.
لذلك ، لا يحتوي التطبيق على الخوارزميات والحسابات فحسب ، بل يحتوي أيضًا على قدر كبير من المعلومات حول بنية نموذج المجال - بنية مفاهيمه ، وعلاقاتها ، والتسلسل الهرمي ، وقواعد بناء بعض المفاهيم على أساس أخرى ، وقواعد تحويل المفاهيم بين طبقات التطبيق المختلفة ، إلخ. عندما نضع وثيقة أو مشروعًا ، فإننا نصف هذه المعلومات بشكل تصريحي - في شكل هياكل ، ومخططات ، وبيانات ، وتعريفات ، وقواعد ، وأوصاف بلغة طبيعية. من الملائم لنا أن نفكر بهذه الطريقة. لسوء الحظ ، لا يمكن دائمًا التعبير عن هذه الأوصاف في الكود بنفس الطريقة الطبيعية.
دعنا نفكر في مثال صغير ونتوقع كيف سيبدو تنفيذه باستخدام نماذج برمجة مختلفة
لنفترض أن لدينا ملفين CSV. في الملف الأول:
يحتوي العمود الأول على معرّف العميل.
الثاني يحتوي على التاريخ.
في الثالث - مبلغ الفاتورة ،
والرابع - مبلغ الدفع.
في الملف الثاني:
يخزن العمود الأول معرّف العميل.
في الثانية - الاسم.
الثالث هو عنوان البريد الإلكتروني.
دعنا نقدم بعض التعريفات:
تتضمن الفاتورة معرف العميل والتاريخ ومبلغ الفاتورة ومبلغ الدفع والدين من خلايا سطر واحد من الملف 1.
مبلغ الدين هو الفرق بين مبلغ الفاتورة ومبلغ السداد.
يتم وصف العميل باستخدام معرف العميل والاسم وعنوان البريد الإلكتروني من خلايا سطر واحد في الملف 2.
الفاتورة غير المسددة هي فاتورة دين موجبة.
ترتبط الحسابات بالعميل من خلال قيمة الرقم التعريفي للعميل.
المدين هو عميل لديه فاتورة واحدة على الأقل غير مدفوعة ، يكون تاريخها أقدم من التاريخ الحالي بشهر واحد.
المتخلف الضار هو العميل الذي لديه أكثر من 3 فواتير غير مدفوعة.
علاوة على ذلك ، باستخدام هذه التعريفات ، من الممكن تنفيذ منطق إرسال تذكير إلى جميع المدينين ، ونقل البيانات حول المتخلفين عن السداد إلى المحصلين ، وحساب عقوبة على مبلغ الدين ، وتجميع التقارير المختلفة ، إلخ.
في لغات البرمجة الوظيفيةيتم تنفيذ منطق الأعمال هذا باستخدام مجموعة من هياكل البيانات والوظائف لتحويلها. علاوة على ذلك ، يتم فصل هياكل البيانات بشكل أساسي عن الوظائف. نتيجة لذلك ، يتم إخفاء النموذج ، وخاصة مكوناته مثل العلاقات بين الكيانات ، داخل مجموعة من الوظائف ، ملطخة فوق رمز البرنامج. هذا يخلق فجوة كبيرة بين الوصف التعريفي للنموذج وتنفيذ برمجياته ويعقد فهمه. خاصة إذا كان النموذج يحتوي على حجم كبير.
هيكلة برنامج في وجوه المنحىأسلوب يساعد في تخفيف هذه المشكلة. يتم تمثيل كل كيان مجال بواسطة كائن تتوافق حقول بياناته مع سمات الكيان. ويتم تنفيذ العلاقات بين الكيانات في شكل علاقات بين الكائنات ، تعتمد جزئيًا على مبادئ OOP - الوراثة وتجريد البيانات وتعدد الأشكال ، جزئيًا - باستخدام أنماط التصميم. ولكن في معظم الحالات ، يجب تنفيذ العلاقات عن طريق ترميزها في طرق الكائن. أيضًا ، بالإضافة إلى إنشاء فئات تمثل الكيانات ، ستحتاج أيضًا إلى هياكل بيانات لترتيبها ، وخوارزميات لملء هذه الهياكل والبحث عن المعلومات فيها.
في المثال مع المدينين ، يمكننا وصف الفئات التي تصف هيكل مفهومي "الحساب" و "العميل". ولكن غالبًا ما يتم تنفيذ منطق إنشاء الكائنات وربط الحساب وكائنات العميل ببعضها البعض بشكل منفصل في فئات أو طرق المصنع. بالنسبة لمفاهيم المدينين والفواتير غير المدفوعة ، ليست هناك حاجة إلى فئات منفصلة على الإطلاق ، ويمكن الحصول على أغراضهم عن طريق تصفية العملاء والفواتير عند الحاجة إليها. نتيجة لذلك ، سيتم تنفيذ بعض مفاهيم النموذج في شكل فئات بشكل صريح ، وبعضها - ضمنيًا ، على مستوى الكائن. توجد بعض العلاقات بين المفاهيم في طرق الفئات المقابلة ، وبعضها منفصل. سيتم تلطيخ تنفيذ النموذج عبر الفئات والطرق ، ممزوجًا بالمنطق الإضافي لتخزينه والبحث والمعالجة وتحويل التنسيق. سوف يستغرق الأمر بعض الجهد للعثور على هذا النموذج في التعليمات البرمجية الخاصة بك وفهمه.
سيكون الأقرب إلى الوصف هو تنفيذ النموذج المفاهيمي في لغات تمثيل المعرفة . ومن أمثلة هذه اللغات Prolog و Datalog و OWL و Flora وغيرها. أخطط للحديث عن هذه اللغات في المنشور الثالث. وهي تستند إلى منطق من الدرجة الأولى أو أجزاء منه ، على سبيل المثال ، المنطق الوصفي. تسمح هذه اللغات في شكل إعلاني بتحديد مواصفات حل المشكلة ، لوصف بنية الكائن أو الظاهرة النموذجية والنتيجة المتوقعة. وستجد محركات البحث المدمجة تلقائيًا حلاً يفي بالشروط المحددة. سيكون تنفيذ نموذج المجال بهذه اللغات موجزًا للغاية ومفهومًا وقريبًا من الوصف باللغة الطبيعية.
على سبيل المثال ، سيكون تنفيذ المشكلة مع المدينين في Prolog قريبًا جدًا من التعريفات من المثال. للقيام بذلك ، يجب تمثيل خلايا الجدول كحقائق ، ويجب تقديم التعريفات من المثال كقواعد. لمقارنة الحسابات والعملاء ، يكفي تحديد العلاقة بينهم في القاعدة ، وسيتم عرض قيمهم المحددة تلقائيًا.
أولاً ، نعلن عن الحقائق بمحتويات الجداول بالتنسيق: معرف الجدول ، الصف ، العمود ، القيمة:
cell(“Table1”,1,1,”John”). ثم نعطي أسماء كل عمود:
clientId(Row, Value) :- cell(“Table1”, Row, 1, Value).ثم يمكنك دمج كل الأعمدة في مفهوم واحد:
bill(Row, ClientId, Date, AmountToPay, AmountPaid) :- clientId(Row, ClientId), date(Row, Date), amountToPay(Row, AmountToPay), amountPaid(Row, AmountPaid).
unpaidBill(Row, ClientId, Date, AmountToPay, AmountPaid) :- bill(Row, ClientId, Date, AmountToPay, AmountPaid), AmountToPay > AmountPaid.
debtor(ClientId, Name, Email) :- client(ClientId, Name, Email), unpaidBill(_, ClientId, _, _, _).إلخ.
ستبدأ الصعوبات عند العمل مع النموذج: عند تنفيذ منطق إرسال الرسائل ، ونقل البيانات إلى خدمات أخرى ، وعمليات حسابية معقدة. نقطة الضعف في Prolog هي وصفه لتسلسل الإجراءات. يمكن أن يبدو تنفيذها الإعلاني ، حتى في الحالات البسيطة ، غير طبيعي للغاية ويتطلب جهدًا ومهارة كبيرة. بالإضافة إلى ذلك ، فإن بناء جملة Prolog ليس قريبًا جدًا من النموذج الموجه للكائنات ، وسيكون من الصعب جدًا فهم أوصاف المفاهيم المركبة المعقدة مع عدد كبير من السمات.
كيف يمكننا التوفيق بين لغة التطوير الوظيفية أو الموجهة للكائنات مع الطبيعة التصريحية لنموذج المجال؟
الأسلوب الأكثر شهرة هو التصميم الموجه للكائنات ( تصميم يحركه المجال). تسهل هذه المنهجية إنشاء وتنفيذ نماذج المجال المعقدة. إنه يفرض أن يتم التعبير عن جميع مفاهيم النموذج في رمز صريح في طبقة منطق الأعمال. يجب أن تكون مفاهيم النموذج وعناصر البرنامج التي تنفذها قريبة من بعضها البعض قدر الإمكان وأن تتوافق مع لغة واحدة ، ومفهومة لكل من المبرمجين وخبراء الموضوع.
سيحتوي نموذج المجال الغني للمثال مع المدينين بالإضافة إلى ذلك على فئات لمفهومي "الفاتورة غير المدفوعة" و "المدين" ، وهي فئات مجمعة للجمع بين مفاهيم الحسابات والعملاء ، والمصانع لإنشاء الأشياء. تنفيذ ودعم مثل هذا النموذج يستغرق وقتًا أطول ، والشفرة مرهقة - ما كان يمكن القيام به سابقًا في سطر واحد يتطلب عدة فئات في نموذج غني. نتيجة لذلك ، من الناحية العملية ، يكون هذا النهج منطقيًا فقط عندما تعمل فرق كبيرة على نماذج مقياس معقدة.
في بعض الحالات ، قد يكون الحل عبارة عن مزيج من لغة البرمجة الأساسية الوظيفية أو الموجهة للكائنات ونظام تمثيل المعرفة الخارجي.... يمكن نقل نموذج المجال إلى قاعدة معرفة خارجية ، على سبيل المثال ، في Prolog أو OWL ، وتتم معالجة نتيجة الاستعلامات الخاصة به على مستوى التطبيق. لكن هذا النهج يعقد الحل ، يجب تنفيذ نفس الكيانات باللغتين ، ويجب إعداد التفاعل بينهما عبر واجهة برمجة التطبيقات ، بالإضافة إلى دعمه من خلال نظام تمثيل المعرفة ، إلخ. لذلك ، لا يكون مبررًا إلا إذا كان النموذج كبيرًا ومعقدًا ، ويتطلب استنتاجًا منطقيًا. سيكون هذا مبالغة في معظم المهام. بالإضافة إلى ذلك ، لا يمكن دائمًا فصل هذا النموذج عن التطبيق بدون ألم.
هناك خيار آخر للجمع بين قواعد المعرفة وتطبيقات OOP وهو البرمجة الموجهة للأنطولوجيا.... يعتمد هذا النهج على أوجه التشابه بين أدوات وصف الأنطولوجيا ونموذج برمجة الكائن. يمكن تعيين سمات الفئات والكيانات والأنطولوجيا المكتوبة ، على سبيل المثال ، بلغة OWL ، تلقائيًا إلى الفئات والكائنات ومجالات نموذج الكائن الخاصة بها. وبعد ذلك يمكن استخدام الفئات الناتجة مع فئات أخرى من التطبيق. لسوء الحظ ، سيكون التنفيذ الأساسي لهذه الفكرة محدود النطاق إلى حد ما. تعد لغات علم الوجود معبرة تمامًا ولا يمكن تحويل جميع مكونات الأنطولوجيا إلى فئات OOP بطريقة بسيطة وطبيعية. أيضًا ، لتنفيذ الاستدلال الكامل ، لا يكفي مجرد إنشاء مجموعة من الفئات والكائنات. إنه يحتاج إلى معلومات حول عناصر الأنطولوجيا بشكل واضح ، على سبيل المثال ، في شكل فئات ميتا.أخطط للحديث عن هذا النهج بمزيد من التفصيل في أحد المنشورات التالية.
هناك أيضًا نهج متطرف لتطوير البرامج مثل التطوير المستند إلى النموذج . وفقًا لذلك ، تصبح المهمة الرئيسية للتطوير هي إنشاء نماذج المجال ، والتي يتم من خلالها إنشاء رمز البرنامج تلقائيًا. ولكن في الممارسة العملية ، لا يكون هذا الحل الجذري دائمًا مرنًا بدرجة كافية ، خاصة فيما يتعلق بأداء البرنامج. يجب أن يجمع منشئ مثل هذه النماذج بين أدوار كل من المبرمج ومحلل الأعمال. لذلك ، لا يمكن لهذا النهج مزاحمة الأساليب التقليدية لتنفيذ النموذج في لغات البرمجة للأغراض العامة.
كل هذه الأساليب مرهقة إلى حد ما ولها معنى بالنسبة للنماذج ذات التعقيد الكبير ، وغالبًا ما يتم وصفها بشكل منفصل عن منطق استخدامها. أريد شيئًا أخف وزنًا وأكثر راحة وطبيعيًا. لذلك ، بمساعدة لغة واحدة ، كان من الممكن وصف النموذج في شكل تعريفي وخوارزميات استخدامه. لذلك ، فكرت في كيفية الجمع بين النموذج الموجه للكائنات أو النموذج الوظيفي (دعنا نسميه مكون الحساب ) والنموذج التصريحي (دعنا نسميه مكون النمذجة ) داخل لغة برمجة هجينة واحدة . للوهلة الأولى ، تبدو هذه النماذج معاكسة لبعضها البعض ، ولكن من المثير للاهتمام تجربتها.
لذا ، فإن الهدف هو إنشاء لغة يجب أن تكون ملائمة للنمذجة المفاهيمية بناءً على بيانات شبه منظمة ومجزأة. يجب أن يكون شكل النموذج قريبًا من الأنطولوجيا ويتألف من وصف لكيانات المجال والعلاقات بينها. يجب أن يتم دمج كلا مكوني اللغة بإحكام ، بما في ذلك على المستوى الدلالي.
يجب أن تكون عناصر علم الوجود كيانات من لغة المستوى الأول - يمكن تمريرها إلى وظائف كوسائط ، ومخصصة للمتغيرات ، وما إلى ذلك. نظرًا لأن النموذج - الأنطولوجيا سيصبح أحد العناصر الرئيسية للبرنامج ، فإن هذا النهج في البرمجة يمكن أن يسمى موجهًا وجوديًا. إن الجمع بين وصف النموذج وخوارزميات استخدامه سيجعل رمز البرنامج أكثر قابلية للفهم وطبيعيًا للبشر ، وسيجعله أقرب إلى النموذج المفاهيمي للمجال ، وسيسهل تطوير البرمجيات وصيانتها.
يكفي لأول مرة. في المنشور التالي ، أريد أن أتحدث عن بعض التقنيات الحديثة التي تجمع بين الأنماط الإلزامية والتعليمية - PL / SQL و Microsoft LINQ و GraphQL. بالنسبة لأولئك الذين لا يرغبون في انتظار إصدار جميع المنشورات على Habré ، هناك نص كامل بأسلوب علمي باللغة الإنجليزية ، متاح على الرابط:
Hybrid Ontology-Oriented Programming for Semi-Structured Data Processing .