إصدار ActivePapers لـ Pharo

إصدار بايثون إصدار جافا إصدار فارو المدونة … مكتبة —> إصدار ActivePapers لفارو من إعداد كونراد هينسن، نُشر في 10 مايو 2019 اكتسبت عائلة ActivePapers عضوًا جديدًا: إصدار ActivePaper لفارو. وعلى عكس إصداري بايثون وجافا اللذين يطبّقان الأفكار والمفاهيم نفسها تقريبًا على منصتين مختلفتين، فإن إصدار فارو يهدف إلى غاية مغايرة: استكشاف واجهة التفاعل بين الإنسان والحاسوب في بحوث محوسبة قابلة للإعادة والفهم والتحقّق.

من أكثر الأسئلة التي وردتني بشأن إصدار ActivePapers لبايثون: “هل يعمل هذا مع دفاتر ملاحظات Jupyter؟” كانت إجابتي في البداية: “ليس بعد، لكني أعمل على ذلك.” وقد عملت عليه بالفعل. غير أن هذا العمل لم يؤدِّ أبدًا إلى نتيجة مُرضية. أحد الأسباب كان عقبات تقنية. فقد حاولت تضمين دفاتر ملاحظات Jupyter داخل ورقة ActivePaper، لكن تبيّن أن ذلك مستحيل بسبب تصميم Jupyter المعتمد على عمليتين منفصلتين (النواة ومحرّر الدفتر عمليتان منفصلتان متصلتان عبر بروتوكول اتصال)، وهو ما لا يتوافق مع قيود مكتبة HDF5 التي تسمح لعملية واحدة فقط بالكتابة إلى ملف في أي وقت. وهذا يعني أنه لا يمكن تخزين دفتر الملاحظات والنتائج التي يحسّبها في ملف HDF5 نفسه.

غير أنه كلما زاد تفكيري في دمج ActivePapers مع Jupyter، أدركت أكثر أن دفاتر الملاحظات الخطية (سلسلة من خلايا الكود والتوثيق والنتائج) ليست ملائمة حقًا لمهمة توثيق حساب علمي، إلا في الحالات البسيطة. إذا نظرت إلى أوراق ActivePapers المنشورة المختلفة، فستجد أنها تحتوي دائمًا على نصوص برمجية متعددة بالإضافة إلى عدد قليل من وحدات المكتبة. قد يبدو للوهلة الأولى أن دفاتر الملاحظات يمكن أن تحل محل النصوص البرمجية وتوفّر التوثيق. غير أن التوثيق الجيد يجب أن يوثّق الكلّ، لا بعض أجزائه. فهو يجب أن يربط بين نصوص برمجية متعددة وكود من وحدات المكتبة. عادةً ما تُنفَّذ الطرق الحسابية في وحدات المكتبة، بينما تطبّق النصوص البرمجية هذه الطرق على مجموعات البيانات. فإذا كان التوثيق يتم نصًّا برمجيًا تلو الآخر، فكيف تُوثَّق الطرق؟

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

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

عندما بدأتُ بالنظر إلى فارو قبل بضعة أشهر، وكان ذلك إلى حد كبير بالصدفة (اشتركت في دورة فارو المفتوحة عبر الإنترنت MOOC لاكتساب بعض الخبرة من منظور المتعلّم، قبل تولّي دور المدرّس في دورة البحث القابل للإعادة MOOC)، اكتشفتُ نوعًا مختلفًا جدًا من بيئات الحوسبة التفاعلية. فعائلة Smalltalk، التي تُعدّ فارو أحد أعضائها الأصغر سنًا، لها تاريخ طويل في تقدير قابلية الاستكشاف والفهم (راجع منشور المدونة هذا لمزيد من التفاصيل). ثم اكتشفتُ بسرعة أداة Glamorous Toolkit، وهي بيئة تفاعلية جديدة مبنية على فارو وتهدف إلى مستوى أعلى من قابلية الاستكشاف عبر أدوات تطوير قابلة للتشكيل، حيث الفكرة هي أن المطوّرين يجب أن يتمكنوا من توسيع البيئة بأدوات فحص مخصصة للمجال. وقد لخّص رافائيل لوك الخلفية الفكرية لهذه الأفكار بشكل جميل في منشور مدونة.

ذات صلة: Dataquest — مسارات علوم البيانات القائمة على المشاريع مع محطة موجهة ومجموعات بيانات حقيقية.

مقارنةً ببيئات عالم فارو الحالية والمستقبلية، تبدو دفاتر الملاحظات الحسابية محدودة للغاية ومقيّدة. وهذا ليس مفاجئًا حقًا نظرًا لأصولها. فـ Jupyter وRMarkdown اليوم هما مجرد اختلافات طفيفة عن فكرة الدفتر التي قدمتها Mathematica في أوائل الثمانينيات. وبدورها، بنَت Mathematica، مثل معظم أنظمة الجبر الحاسوبي الأخرى، على إرث Lisp، الذي أدخل في الخمسينيات العديد من الميزات الثورية إلى الحوسبة، ومنها التفاعلية عبر حلقة القراءة-التقييم-الطباعة (REPL) التي كانت طريقة طبيعية لتنفيذ التفاعل ضمن قيود عتاد واجهة المستخدم آنذاك: طرفية موجهة نحو السطور.

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

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

يستحق نظرة: Coursera Plus — اشتراك واحد للحصول على شهادات بايثون وعلوم البيانات المدعومة من الجامعة.

هذه الرحلة刚刚开始، ولا أعرف حقًا إلى أين ستقود. ترقّبوا التحديثات! وفي الأثناء، يمكنكم مشاهدة فيديو العرض التوضيحي هذا.

تعليقات مدعومة من Disqus