كيف تُنفَّذ الشفرة

الحاسوب لا يقرأ نص شفرتك؛ فماذا ينفذ إذن؟

الملف الذي تحفظه نص عادي؛ ومن ناحية القرص لا يختلف عن ملف ملاحظات. والمعالج لا يقرأ ذلك النص. فما ينفذه المعالج مجموعة من التعليمات الرقمية البالغة البساطة: خذ هذا العدد من الذاكرة، واجمع عليه ذاك، وضع النتيجة هناك، وإن كانت صفرا فاقفز إلى تلك النقطة. وهذا يُسمى لغة الآلة ولا أحد يعمل بها مباشرة اليوم.

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

ونقطة تفيدك سريعا جدا: مرحلة الترجمة تفحص النحو قبل كل شيء، أي هل يلتزم نصك بقواعد تلك اللغة أصلا. فإن لم يلتزم توقف العمل عند تلك النقطة ولم يُنفَّذ سطر واحد من برنامجك، ولا حتى سطر كان سليما وسبق موضع الخطأ. والقسم الرابع من هذه الصفحة يعرض ذلك بملفين حقيقيين.

ما الفرق بين الترجمة والتفسير؟

أبسط صياغة: في اللغة المفسَّرة يُسلَّم النص إلى محرك اللغة كما هو ويُنفَّذ من أعلى إلى أسفل؛ وفي اللغة المترجَمة يُحوَّل النص أولا إلى صيغة أخرى وتلك الصيغة هي التي تُنفَّذ. وموزيلا تصوغها بهذه العبارات تماما، إذ تُستلَم الشفرة في اللغات المفسَّرة بصيغتها النصية وتُعالَج منها مباشرة، بينما تُحوَّل اللغات المترجَمة إلى صيغة أخرى قبل تنفيذها.

والآن الجزء المحرج. لم يعد هذا التقسيم خطا واضحا. ففي الصفحة نفسها تضيف موزيلا أن أغلب مفسرات جافاسكريبت الحديثة تستعمل تقنية اسمها الترجمة في الوقت المناسب، فتحوّل المصدر إلى صيغة ثنائية أسرع أثناء استعمال السكربت؛ ومع ذلك تظل تعد جافاسكريبت لغة مفسَّرة، لأن تلك الترجمة تحدث وقت التنفيذ لا قبله.

لذلك بدأ سؤال «أهي مترجَمة أم مفسَّرة» يفقد فائدته. وثمة سؤالان أفضل: متى تحدث الترجمة، وهل تُحفَظ نتيجتها أم تُبنى من جديد في كل مرة؟ وجواب هذين السؤالين يشرح لماذا يحتاج برنامج بلغة سي مرحلة بناء منفصلة قبل التشغيل، ولماذا يبدأ سكربت بايثون الذي يستورد وحدة أسرع قليلا في المرة الثانية.

أين تقع بايثون وجافاسكريبت وPHP من هذه السلسلة؟

يضع الجدول التالي سؤالي القسم السابق أمام أربع لغات. والعمود الثالث هو المهم، لأن اختلاف اللغات الحقيقي هناك لا في تسميتها.

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

ونتيجة عملية تنفعك فورا: في جافاسكريبت وPHP وبايثون تغيّر الملف فترى الأثر في المرة التالية. أما في سي فعليك البناء من جديد. وإن قال لك أحد إنه غيّر الملف ولم يتغير شيء، فالسؤال الأول أي صف من هذا الجدول تقع لغته فيه، والسؤال الثاني هو موضوع القسم الخامس.

لماذا لا يُنفَّذ أي سطر أحيانا وينفَّذ نصف البرنامج أحيانا؟

أنشئ ملفين صغيرين وشغّل كلا منهما وحده. الأول bad.py، وفيه قوس غير مغلق في السطر الثاني:

print("first line")
print("second line"

والمخرج الحقيقي هو:

  File "bad.py", line 2
    print("second line"
         ^
SyntaxError: '(' was never closed

والثاني boom.py، ونحوه سليم لكنه يطلب شيئا غير ممكن:

print("first line")
print(1/0)

ومخرجه:

first line
Traceback (most recent call last):
  File "boom.py", line 2, in <module>
    print(1/0)
          ~^~
ZeroDivisionError: division by zero

انظر إلى الفرق، فهذا الأمر وحده نصف عملية تصحيحك للأخطاء. في الملف الأول لم تُطبَع عبارة first line أبدا، مع أن السطر الأول كان سليما تماما وسبق موضع الخطأ. وفي الملف الثاني طُبعت ثم سقط البرنامج في منتصف الطريق. والسبب هو سلسلة القسم الأول: فحص النحو يجري على الملف كله قبل أي تنفيذ، فقوس غير مغلق في السطر الثاني يُسقط معه السطر الأول. أما القسمة على صفر فلا تُكتشف حتى اللحظة التي نصل فيها إليها فعلا، لأن أحدا قبل ذلك لا يعرف أن المقام صفر.

ولهاتين الحالتين اسمان: خطأ نحوي وخطأ زمن التنفيذ. وفائدتهما العملية أنك تميز بينهما من المخرج وحده، حتى لو لم تكن تعرف اللغة. فإن طُبع شيء قبل رسالة الخطأ فقد بدأ البرنامج بالعمل وأنت أمام خطأ زمن تنفيذ؛ وإن لم يُطبع شيء فالأرجح أنه لم يُنفَّذ أصلا.

الملف الذي حفظته ليس ما يُنفَّذ

والآن الجزء الطريف من السلسلة. نتيجة الترجمة لا تعيش في الذاكرة فحسب؛ بل تُحفَظ في أحيان كثيرة كي لا يلزم بناؤها من جديد في المرة التالية. وبايثون تفعل ذلك أمام عينيك مباشرة. أنشئ ملفين، tools.py وmain.py يستورد الأول، ثم:

python3 main.py
ls __pycache__/

يظهر مجلد اسمه __pycache__ وفيه ملف واحد بالضبط: tools.cpython-312.pyc. ولم يُكتب شيء من أجل main.py. وتوثيق بايثون نفسه يشرح الشقين: بايثون تحفظ النسخة المترجَمة من كل وحدة في مجلد __pycache__، أما الوحدة التي تُحمَّل مباشرة من سطر الأوامر فتعيد ترجمتها دائما ولا تحفظ النتيجة.

وPHP تؤدي العمل نفسه بفارق واحد: لا تضع النتيجة على القرص بل تحفظها في ذاكرة الخادم. واسم هذه الطبقة opcache، ولسلوكها إعداد واحد يصيب المبتدئين بالجنون: كل كم يفحص هل تغيّر الملف على القرص. ودليل PHP نفسه يصف الإعداد بهذه العبارة تحديدا، كم مرة تُفحَص أزمنة تعديل الملفات، بالثواني. أي أن بين حفظ الملف وسريان أثره فجوة، وهذه الفجوة مقصودة.

لذلك فالجملة المألوفة «غيّرت الملف ولم يحدث شيء» لها ثلاثة أجوبة شائعة، وثلاثتها داخل هذه السلسلة: إما أن الملف الذي غيّرته ليس الملف الذي يُنفَّذ، وإما أن نسخة مترجَمة قديمة ما زالت في الذاكرة، وإما أن المخرَج يأتي من طبقة كاش أمامك ولم يصل برنامجك أصلا. وقسم «من عملنا نحن» أسفل هذه الصفحة يعطي رقم ذلك الإعداد على خادمنا نحن.

حين لا يعمل البرنامج، أين تنظر أولا؟

اقرأ رسالة الخطأ من الأسفل لا من الأعلى. فآخر سطر يذكر نوع الخطأ وهو أهم كلمة على الشاشة؛ والسطر الذي فوقه يقول عادة أين. وفي مثال القسم الرابع كان آخر سطر ZeroDivisionError: division by zero، والسطر فوقه يشير إلى التعبير الذي انفجر بالضبط. أما المبتدئون فيبدؤون عادة من الأعلى، حيث لا تُكتب إلا مسارات الملفات، ثم يقولون إن الخطأ غير مفهوم.

وبعد القراءة، سمِّ الطبقة. وهي أربع لا أكثر. النحو: لم يُنفَّذ شيء، وجاءت الرسالة قبل أي مخرَج. زمن التنفيذ: طُبع شيء ثم سقط البرنامج. المحيط: البرنامج سليم لكن شيئا يحتاجه غير مثبَّت، أو نسخته مختلفة، أو لا يُعثر على مساره. المنطق: لا خطأ أصلا، يعمل البرنامج حتى نهايته ويعطي جوابا خاطئا.

وموقفنا هنا بسيط: قبل أن تغيّر حرفا واحدا، قل اسم الطبقة بصوت مسموع. فأغلب الساعات التي يهدرها المبتدئون تذهب في تعديل شفرة داخل طبقة ليست فيها المشكلة، كإعادة كتابة دالة سليمة بينما المكتبة لم تكن مثبَّتة أصلا. والطبقة الرابعة أسوأها، لأنها لا تعطي أي خطأ؛ والسبيل الوحيد لاصطيادها أن تخمّن المخرَج المتوقع قبل التشغيل ثم تقارنه بما خرج فعلا.