"Plainbook" يعيد تصميم دفتر الأبحاث العلمية... لمن لا يكتبون الكود

ظهر دفتر أبحاث جديد يحمل اسم "Plainbook" لينسف فكرة مترسخة منذ سنوات: أن علم البيانات (Data Science) حكر على من يعرفون البرمجة. فبدلاً من أن يكون الكود هو العنصر الأساسي في العمل العلمي، يجعل هذا النظام الوصف باللغة الطبيعية هو المرجع الحقيقي، ويترك للكود مهمة تنفيذ ما يُطلب منه في الخلفية.

النظام، الذي تم تفصيله في ورقة بحثية قُدّمت إلى أرشيف الأبحاث المفتوحة (arXiv) في 7 يوليو 2026، يعالج ثغرة قديمة في الحوسبة العلمية: باحثون يفهمون تخصصهم بعمق، لكنهم لا يمتلكون الخلفية البرمجية اللازمة للتعامل مع أدوات مثل "جوبيتر" (Jupyter). بدلاً من إجبار المستخدم على كتابة وصيانة أكواد بلغة "بايثون" (Python) أو "آر" (R)، يعتمد Plainbook مبدأً مختلفاً تماماً: وصف الخلية بلغة طبيعية هو "مصدر الحقيقة" (Source of Truth)، والنظام هو من يولّد الكود المطلوب في كل مرة من جديد. النتيجة أن الوصف، لا الكود الناتج عنه، هو ما يُحفظ ويُعدَّل مع مرور الوقت.

هذا القرار التصميمي يقلب العلاقة التقليدية بين النص والكود في دفاتر الحوسبة رأساً على عقب. في أغلب البيئات المعروفة، تُعامل التعليقات وملفات "ماركداون" (Markdown) كملاحظات هامشية توضع فوق العنصر "الحقيقي"، وهو الكود. أما Plainbook فيعكس المعادلة تماماً: يصبح الكود بنية مؤقتة قابلة لإعادة التوليد، تُستمد كل مرة من الصياغة اللغوية التي كتبها الباحث بلغته العادية. هذا يفتح الباب أمام كل من يفكر بمنطق الفرضيات وتحويلات البيانات، لا بمنطق قواعد الصياغة البرمجية (Syntax).

حل مشكلة الموثوقية في "جوبيتر"

لا يقف أثر Plainbook عند تسهيل الوصول فحسب، بل يعالج أيضاً معضلة معروفة في عالم دفاتر الحوسبة: عدم استقرار الحالة (State). تسمح دفاتر "جوبيتر" بتنفيذ الخلايا بترتيب غير متسلسل، وهو ما يخلق أحياناً متغيرات مخفية وحالات قديمة تفسد النتائج بصمت، دون أي تحذير ظاهر. يقضي Plainbook على هذه المشكلة جذرياً عبر فرض تنفيذ خطي صارم (Linear Execution)، حيث تُشغَّل الخلايا بالترتيب الذي تظهر به على الصفحة تماماً. هذا القيد يستبعد إمكانية وجود حالة مخفية بشكل كامل، ما يجعل سلوك الدفتر أكثر قابلية للتنبؤ والتدقيق، وهو أمر بالغ الأهمية في العمل العلمي حيث تكرار النتائج (Reproducibility) ليس أمراً قابلاً للتفاوض.

ولضمان ثقة الباحثين بأن الكود المولَّد يؤدي فعلاً ما يقصده الوصف، بُنيت داخل Plainbook آليات تحقق (Verification) تركز على فحص القيم الفعلية للنتائج، لا على مجرد التأكد من أن الكود يعمل دون أخطاء. تعمل هذه الآليات على مستويين: تحقق على مستوى الخلية الواحدة، يشبه في وظيفته اختبارات الوحدة (Unit Tests)، للتأكد من أن خطوة معينة تنتج المخرج المتوقع، وتحقق عام يفحص الاتساق عبر الدفتر بأكمله. هذا يمنح المستخدمين وسيلة لرصد الأخطاء الدقيقة في الكود المولَّد آلياً قبل أن تتسرب وتؤثر على نتائج التحليل كاملة.

أما مسألة الأداء، فتُعالَج من خلال ما تسميه الورقة البحثية "نواة اللقطات" (Snapshot Kernel)، وهي آلية تخزين مؤقت (Caching) تحفظ حالات التنفيذ السابقة، بحيث لا يحتاج الدفتر لإعادة تشغيل كل شيء من الصفر في كل مرة يتغير فيها الوصف أو تُفعَّل عملية تحقق. وبالجمع بين هذا التخزين المؤقت والتنفيذ الخطي، يحافظ النظام على استجابة سريعة حتى مع إعادة توليد الكود بشكل متكرر في الخلفية.

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