لماذا لغات البرمجة غير كافية

لغات البرمجة تصف الإجراءات. لا تستطيع وصف العالم.

لغات البرمجة من أعظم اختراعات البشرية

لغات البرمجة لا لبس فيها. x = 3 + 4 تعطي 7 بغض النظر عن زمان أو مكان التنفيذ. لا مجال للتأويل.

لغات البرمجة قابلة للتحقق. الأخطاء النحوية تُكتشف قبل الترجمة. أخطاء الأنواع تُكتشف قبل التنفيذ. عند تشغيل الاختبارات، تكون النتيجة إما نجاح أو فشل.

لغات البرمجة كاملة تورنغ. تستطيع التعبير عن كل ما هو قابل للحساب. مع وقت وذاكرة كافيين، يمكن وصف أي إجراء.

كل ما حددته هذه السلسلة كقيود على اللغة الطبيعية — الغموض وعدم القابلية للتحقق وغياب البنية — حلّته لغات البرمجة بالكامل.

إذن، لماذا لا نستخدم لغة برمجة لتمثيل سياق الذكاء الاصطناعي؟

لا يمكن ذلك.

لغات البرمجة تصف الإجراءات

الكود التالي هو كود Python صالح.

def calculate_revenue(units_sold, unit_price):
    return units_sold * unit_price

هذا الكود واضح وقابل للتحقق وقابل للتنفيذ. لكن ما الذي يعبّر عنه؟

“اضرب عدد الوحدات المباعة في سعر الوحدة للحصول على الإيرادات.”

هذا إجراء. طريقة. هو الـ HOW (كيف). يصف ما يجب فعله عند وصول المدخلات.

الآن لنحاول التعبير عما يلي.

“بلغت إيرادات سامسونج إلكترونيكس في الربع الثالث من 2024 نحو 79 تريليون وون.”

هذا ليس إجراءً. إنه حقيقة. هو الـ WHAT (ماذا). لا يُنفَّذ شيء. إنه يصف حالة العالم.

كيف نعبّر عن هذا بلغة Python؟

samsung_revenue_2024_q3 = 79_000_000_000_000

أُسند رقم إلى متغير. يعمل. لكنه ليس وصفاً. إنه تخزين. هذا الكود لا يعرف:

• ما نوع الكيان الذي تمثله “سامسونج إلكترونيكس”.
• ما معنى “الإيرادات”. هل هي مؤشر مالي أم كمية فيزيائية؟
• هل “الربع الثالث 2024” زمن أم إصدار أم تسمية؟
• ما مصدر رقم 79 تريليون وون؟
• ما مدى يقينية هذه القيمة؟

اسم المتغير samsung_revenue_2024_q3 يسمح للإنسان بتخمين المعنى. بالنسبة للآلة، هو مجرد سلسلة أحرف عشوائية. غيّره إلى xyzzy_42 وستبقى نتيجة التنفيذ كما هي.

في لغات البرمجة، أسماء المتغيرات لا تحمل معنى. المعنى يقبع خارج الكود، في ذهن المبرمج.

مزيد من التطوير لا يُجدي

ماذا لو أنشأنا صنفاً (class)؟

class FinancialReport:
    def __init__(self, company, metric, period, value, currency):
        self.company = company
        self.metric = metric
        self.period = period
        self.value = value
        self.currency = currency

report = FinancialReport("삼성전자", "매출", "2024-Q3", 79_000_000_000_000, "KRW")

أفضل. ظهرت بنية. لكن المشاكل لا تزال قائمة.

company هي السلسلة النصية “삼성전자” (سامسونج إلكترونيكس). “Samsung Electronics” و"SEC" و"005930" كلها تشير إلى نفس الشركة. هل يعرف الكود ذلك؟ لا. يمكنه فقط مقارنة ما إذا كانت السلاسل متطابقة أم لا.

metric هي السلسلة النصية “매출” (الإيرادات). هل “매출” و"매출액" و"revenue" هي الشيء نفسه أم أشياء مختلفة؟ الكود لا يعرف. السلاسل مختلفة، إذن هي أشياء مختلفة.

ماذا لو عرّفنا مخططاً (schema)؟ إدارة قائمة الشركات بالتعدادات (Enum)، وإدارة قائمة المؤشرات. بالتأكيد. يعمل.

فلنحاول الآن التعبير عما يلي.

“كان الأدميرال يي سون شين عظيماً.”

opinion = Opinion("이순신", "was", "위대했다")

ما هذا؟ سلسلة نصية “이순신” (يي سون شين) مرتبطة بسلسلة “위대했다” (كان عظيماً). هذا لا يعبّر عن “يي سون شين كان عظيماً”. إنه يخزّن “이순신” و"위대했다".

الكود لا يعرف معنى “위대했다” (كان عظيماً). هل “위대했다” (كان عظيماً) و"훌륭했다" (كان ممتازاً) متقاربان في المعنى، وهل “비겁했다” (كان جباناً) هو النقيض — الكود لا يستطيع معرفة ذلك.

الحقائق المنظمة كالبيانات المالية يمكن التعامل معها إلى حد ما. التقييمات والسياق والعلاقات والأوصاف المجردة تقع خارج نطاق التعبير في لغات البرمجة.

الكود لا يعرف ما يفعله

def process(data):
    result = []
    for item in data:
        if item["value"] > threshold:
            result.append(transform(item))
    return result

هذا الكود يُنفَّذ بشكل مثالي. لكن ما الذي يفعله؟

هل يُصفّي بيانات الإيرادات؟ هل يُنقّي سجلات المرضى؟ هل يُنظّف بيانات المستشعرات؟

الكود نفسه لا يعرف. data وvalue وthreshold وtransform — كلها أسماء مجردة. هل هذا الكود جزء من نظام مالي أو نظام طبي يعتمد على السياق خارج الكود.

يمكن كتابة تعليقات. لكن التعليقات لغة طبيعية. الآلات لا تفهمها. إذا تناقض التعليق مع الكود، فالمترجم لا يلاحظ. التعليقات للبشر، لا للآلات.

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

السبب الجوهري

أن لغات البرمجة لا تستطيع وصف العالم ليس عيباً في التصميم. الغرض مختلف.

الغرض من لغة البرمجة هو إعطاء تعليمات إجرائية للآلة. “عندما يصل هذا المدخل، نفّذ هذه العملية.” دلالات لغة البرمجة هي دلالات التنفيذ. كل بنية تُفسَّر على أنها “ماذا تفعل الآلة”.

x = 3 هي التعليمة “خزّن 3 في موقع الذاكرة المسمى x”. if x > 0 هي التعليمة “إذا كان x أكبر من 0، نفّذ الكتلة التالية”. return x هي التعليمة “أعد قيمة x إلى المُستدعي”.

كلها أفعال. كلها أعمال. كلها إجراءات.

“سامسونج إلكترونيكس شركة كورية” ليست فعلاً. ليست عملاً. ليست إجراءً. إنها تصف الحالة التي يكون عليها العالم.

لغات البرمجة لا تملك مكاناً لهذا. يمكن تخزينه في متغير، لكن ذلك تخزين وليس وصفاً. معنى القيمة المخزنة ليس من اختصاص الكود.

ماذا عن JSON وYAML وXML؟

إن لم تكن لغات البرمجة، فماذا عن صيغ البيانات؟

{
  "company": "삼성전자",
  "metric": "매출",
  "period": "2024-Q3",
  "value": 79000000000000,
  "currency": "KRW"
}

هناك بنية. الحقول صريحة. لكن لا يوجد معنى.

هل “company” تعني شركة؟ JSON لا يعرف. هل “삼성전자” هي نفسها “Samsung Electronics” في مكان آخر؟ JSON لا يعرف. هل هذا الكائن JSON وذاك يصفان نفس الكيان؟ JSON لا يعرف.

JSON يوفر البنية لكنه لا يوفر المعنى. إنه أزواج مفتاح-قيمة، وليس كيان-علاقة-خاصية.

تعريف المخططات يُحسّن الأمور. JSON Schema وProtocol Buffers وGraphQL. أنواع الحقول مُعرَّفة، والحقول المطلوبة مُعرَّفة، والمراجع مُعرَّفة.

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

مخطط مستقل لكل مجال. أداة مستقلة لكل مخطط. لا قابلية للتشغيل البيني بين المخططات.

تُناقش هذه القيود بمزيد من التفصيل في لماذا MD/JSON/XML غير كافية.

ماذا عن LISP؟

ربما فكّر بعض القراء في مثال مضاد.

LISP.

(is 삼성전자 (company korea))
(revenue 삼성전자 2024-Q3 79000000000000)
(great 이순신)

تعبيرات S هي بنى شجرية، والكود بيانات والبيانات كود. التماثل البنيوي (homoiconicity).

في الواقع، كان الذكاء الاصطناعي المبكر بأكمله مبنياً على LISP. SHRDLU وCYC والأنظمة الخبيرة. مُثّلت المعرفة بلغة LISP، وعملت محركات الاستدلال عليها. يبدو كأن هناك دليلاً تاريخياً مضاداً لمقولة “لغات البرمجة لا تستطيع وصف العالم”.

لكن المثال المضاد يفشل لثلاثة أسباب.

ما تعرفه LISP مقابل ما قرره المبرمج

في (is 삼성전자 company)، لا تعرف LISP أن is تعني علاقة “هو/هي”. المبرمج هو من قرر ذلك.

استبدل is بـ zzz ولن تكترث LISP. (zzz 삼성전자 company) هي تعبير صالح تماماً بالنسبة لـ LISP.

LISP توفر البنية. شجرة تُسمى S-expression. لكن المعنى داخل تلك البنية أسنده المبرمج، لا اللغة. هذا في جوهره مماثل لكون JSON لا يعرف معنى مفاتيحه.

توفير البنية وتضمين المعنى شيئان مختلفان.

ثلاثون عاماً من CYC

المحاولة الأكثر طموحاً كانت CYC.

بدأ في 1984. حاول تمثيل المعرفة العامة باستخدام LISP. أُدخلت ملايين القواعد يدوياً.

ما أثبته ثلاثون عاماً لم يكن الجدوى بل القيود.

كان يجب تصميم الأنطولوجيات يدوياً لكل مجال. التشغيل البيني بين المجالات لم ينجح. لم يستطع مواكبة مرونة اللغة الطبيعية. كلما كبر الحجم، أصبح الحفاظ على الاتساق شبه مستحيل.

أن تمثيل المعرفة “يمكن القيام به” بلغة LISP صحيح. أنه “يعمل جيداً” — هذا ما تدحضه نتائج 30 عاماً.

إذا لم تستخدم eval، فلا سبب لاستخدام LISP

المشكلة الأكثر جوهرية.

قوة LISP تكمن في eval. لأن الكود بيانات، يمكن تنفيذ البيانات. البرمجة الوصفية، الماكرو، توليد الكود أثناء التشغيل. هذا ما يجعل LISP هي LISP.

لكن ماذا يحدث عند تطبيق eval على (is 삼성전자 company)؟

يصبح استدعاء دالة تمرّر 삼성전자 وcompany كمعاملات لدالة اسمها is. ليس وصفاً — بل تنفيذاً.

لاستخدامها في تمثيل المعرفة، يجب ألا تستخدم eval. إذا لم تستخدم eval، فأنت لا تستخدم دلالات LISP. أنت تستعير صياغة تعبيرات S فحسب.

هذا ليس “وصف العالم بلغة LISP”. إنه “تخزين البيانات باستخدام تدوين الأقواس الخاص بـ LISP”.

دلالات LISP كلغة برمجة — دلالات التنفيذ — لا تزال مصممة لوصف الإجراءات. استعارة الصياغة لا تغيّر الدلالات.

ما الذي تحتاجه لغة لوصف العالم

لغات البرمجة تصف الإجراءات. صيغ البيانات توفر البنية لكن بلا معنى. حتى LISP تستعير الصياغة فحسب دون دلالات الوصف.

ما الذي تحتاجه لغة لوصف العالم؟

هوية الكيان. يجب أن يكون لـ “سامسونج إلكترونيكس” معرّف فريد. يجب أن تعرف الآلة أنها نفس “삼성전자”. ليس مقارنة سلاسل نصية، بل تطابق الهوية.

التعبير عن العلاقات. في “سامسونج إلكترونيكس شركة كورية”، يجب أن يكون ممكناً التعبير عن علاقة “شركة كورية”. ليس إسناد متغيرات، بل وصف العلاقات.

الأوصاف الذاتية الوصف. عمّ يتحدث هذا الوصف، ومن قاله، ومتى كان صالحاً، وما مدى يقينيته — كل ذلك يجب أن يكون مُضمَّناً في الوصف ذاته. داخل الكود، لا خارجه.

استقلالية المجال. البيانات المالية والحقائق التاريخية والتقييمات الذاتية والعلاقات المجردة — يجب أن تكون جميعها قابلة للتعبير بنفس الصيغة. ليس مخططاً مستقلاً لكل مجال، بل بنية واحدة شاملة.

لغات البرمجة لا تمتلك أياً من هذه الخصائص الأربع. لأن لغات البرمجة لم تُبنَ لهذا الغرض. بُنيت لوصف الإجراءات.

اللغة الطبيعية تستطيع فعل الأربعة. لكن بغموض. ما نحتاجه هو الجمع بين نطاق التعبير في اللغة الطبيعية ودقة لغات البرمجة.

خلاصة

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

لغات البرمجة تصف الإجراءات. “عندما يصل هذا المدخل، افعل هذا.” كلها أفعال وأعمال. “سامسونج إلكترونيكس شركة كورية” ليست عملاً. لغات البرمجة لا تملك مكاناً لذلك.

الكود لا يعرف هويته. إلى أي مجال ينتمي، وأي غرض يخدم — لا شيء من ذلك مسجل داخل الكود.

صيغ البيانات مثل JSON وYAML توفر البنية لكن بلا معنى. LISP تستطيع استعارة الصياغة، لكنها تفتقر إلى دلالات الوصف. أمضى مشروع CYC ثلاثين عاماً في محاولة تمثيل المعرفة بناءً على LISP، وما أثبته كان القيود.

وصف العالم يتطلب هوية الكيان والتعبير عن العلاقات والأوصاف الذاتية الوصف واستقلالية المجال. لغات البرمجة لم تُبنَ لهذا. اللغة الطبيعية تستطيع ذلك، لكن بغموض. ما نحتاجه يقع في مكان ما بين الاثنين.