מהדורת ActivePapers ל-Pharo

מהדורת Python מהדורת JVM מהדורת Pharo בלוג … ספרייה —> מהדורת ActivePapers ל-Pharo מאת קונרד הינסן, פורסם ב-10 במאי 2019 למשפחת ActivePapers נוסף חבר חדש: מהדורת ActivePaper ל-Pharo. בניגוד למהדורות ה-Python וה-JVM, המיישמות בעיקר את אותם רעיונות ומושגים על גבי שתי פלטפורמות שונות, מהדורת ה-Pharo שואפת להשיג מטרה אחרת: בחינת ממשק האדם-מחשב עבור מחקר מבוסס-מחשב שהוא ניתן לשחזור, להבנה ולאמות. אחת השאלות הנפוצות ביותר שקיבלתי בנוגע למהדורת ה-Python של ActivePapers הייתה: “האם זה עובד עם מחברות Jupyter?” בתחילה תשובתי הייתה “לא עדיין, אבל אני עובד על זה”. ואכן עבדתי על כך. עם זאת, עבודה זו מעולם לא הובילה לתוצאה מספקת. סיבה אחת היו מכשולים טכניים. ניסיתי לכלול מחברות Jupyter בתוך ActivePaper, אך הדבר התברר כבלתי אפשרי משום שתכנון שני התהליכים של Jupyter (ה-Libבת והעורך של המחברת הם תהליכים נפרדים המחוברים באמצעות פרוטוקול תקשורת) אינו תואם את ההגבלה של ספריית HDF5 הקובעת שרק תהליך אחד יכול לכתוב לקובץ בכל זמן נתון. משמעות הדבר היא שלא ניתן לאחסן מחברת ואת התוצאות שהיא מחשבת בתוך אותו קובץ HDF5. עם זאת, ככל שהעמקתי במחשבה על שילוב בין ActivePapers ל-Jupyter, כך הבנתי יותר שמחברות ליניאריות (רצף של תאי קוד, תיעוד ותוצאות) אינן מותאמות באמת למשימת תיעוד חישוב מדעי, למעט במקרים פשוטים. אם מסתכלים על ה-ActivePapers השונים שפורסמו, כולם ללא יוצא מן הכלל מכילים מספר סקריפטים ועוד כמה מודולי ספרייה. במבט שטחי, עשוי להיראת שמחברות יכולות להחליף את הסקריפטים ובכך לספק תיעוד. עם זאת, תיעוד טוב חייב לתעד את השלם, ולא רק חלקים ממנו. עליו לחבר יחד סקריפטים מרובים וקוד מתוך מודולי הספרייה. בדרך כלל שיטות חישוביות מיושמות במודולי הספרייה, והסקריפטים מיישמים אותן על ערכות נתונים. אם התיעוד נעשה סקריפט אחר סקריפט, כיצד מתעדים את השיטות? כיום ישנם אינספור מחברות Jupyter שפורסמו, אז כיצד הן מתמודדות עם זאת? כמובן שלא בדקתי את כולן, אך עד כה רושמי הוא שישנם שני מקרים. המקרה הנפוץ ביותר הוא מחברות המתעדות ניתוחי נתונים המבוססים על שיטות סטנדרטיות ומוכרות המיושמות בספריות מוכרות. מצופה מקוראי המחברת להיות בקיאים בשיטות, או ללמוד עליהן במקום אחר. המקרה האחר הוא מחברות הכוללות את יישום השיטה המלא. מעבר להיותו מוגבל לשיטות פשוטות, לגישה זו יש יתרון גדול בכך שיישום השיטה אינו ניתן לשימוש חוזר. מכיוון שהמחקר שלי מתמקד בעיקר בפיתוח והערכה של שיטות חישוביות חדשות, הגעתי למסקנה שמחברות אינן מתאימות לעבודתי. למעשה, הגעתי לאותה מסקנה כבר בניסיון המעשי. בכל פעם שהתחלתי פרויקט חדש כמחברת, עברתי במהירות חזרה למודולים וסקריפטים בסגנון הישן, עם תיעוד בקובצי טקסט נפרדים. מצאתי שזו טכניקה טובה דיה לשימושי האישי, אך אוסף של קבצים, אפילו מאורגנים היטב, אינו יוצר משהו שמדען אחר, אפילו שותף למחקר, יהיה נלהב לצלול לתוכו. כאשר לפני כמה חודשים התחלתי להתבונן ב-Pharo, בעיקר במקרה (נרשמתי לקורס MOOC של Pharo כדי לצבור חוויית MOOC מנקודת מבטו של הלומד, לפני שנטלתי את התפקיד של מדריך בקורס MOOC בנושא מחקר ניתן לשחזור), גיליתי סוג שונה מאוד של סביבת מחשוב אינטראקטיבית. למשפחת Smalltalk, ש-Pharo הוא אחד מחבריה הצעירים יותר, יש היסטוריה ארוכה של הערכת יכולת חקירה והבנה (ראו פוסט בלוג זה לפרטים נוספים). אז גיליתי במהירות את Glamorous Toolkit, סביבה אינטראקטיבית חדשה הבנויה על Pharo ושואפת לרמה אף גבוהה יותר של יכולת חקירה באמצעות כלי פיתוח ניתנים לעיצוב (moldable development tools); הרעיון הוא שמפתחים צריכים להיות מסוגלים להרחיב את הסביבה בכלי בדיקה ייעודיים לתחום. הרקע האינטלקטואלי של רעיונות אלו סוכם יפה בפוסט בלוג מאת רפאל לוקה. בהשוואה לסביבות הנוכחיות והעתידיות של יקום ה-Pharo, מחברות חישוביות מרגישות מוגבלות ומעכבות מאוד. וזה לא מפתיע בהתחשב במקורותיהן. ה-Jupyter וה-RMarkdown של היום הם וריאציות קלות על רעיון המחברת שהוצג בתחילת שנות ה-80 על ידי Mathematica. Mathematica בתורה, כמו רוב מערכות האלגברה הממוחשבת האחרות, נשענה על המורשת של Lisp, שבשנות ה-50 הציגה תכונות מהפכניות רבות בעולם המחשוב, ביניהן אינטראקטיביות באמצעות לולאת קריאה-הערכה-הדפסה (REPL), שהייתה דרך טבעית ליישם אינטראקציה במגבלות חומרת ממשק המשתמש של אותה תקופה: מסוף מוכוון-שורות. Smalltalk, לעומת זאת, החלה את דרכה בשנות ה-70 עם צגים גרפיים והתקני הצבעה ממש מההתחלה, במחיר של תלות בחומרה שלמעט אנשים ספורים היה אליה גישה באותה עת. כפי שלימד אותנו מרשל מקלוהן, תחילה אנו מעצבים את הכלים שלנו ואחר כך הכלים שלנו מעצבים אותנו. המסופים מוכווני-השורות של שנות ה-50 הטביעו דרך חשיבה על משתמשי המחשב שאפילו מחברות חישוביות של היום שמרו עליה, למרות שגישה עדיפה קיימת כבר עשרות שנים. והטכנולוגיה העדיפה הזו היא לא רק Smalltalk, שתמיד נשארה מערכת נישה. ממשקי משתמש גרפיים לא-ליניאריים הם מה שכולנו משתמשים בו לעבודה עם קבצי תמונה או קול. משימות אלו כמעט בלתי אפשריות לביצוע שורה אחר שורה, ולכן הן לא באמת התרחשו לפני עידן ה-GUIs. עבור חישובים, ה-GUIs כנראה הגיעו מאוחר מדי: החשיבה הליניארית כבר הפכה לנורמה תרבותית. מהדורת ה-Pharo של ActivePapers שואפת לעצב את סביבת GToolkit לסביבה לביצוע מחקר ממוחשב-עזר, ולא לפיתוח תוכנה. שתי הפעילויות הללו נבדלות זו מזו אך חולקות מאפיינים משותפים רבים. ההבדל העיקרי הוא שמדע מתמקד בנתונים ובמודלים, כאשר התוכנה היא רק אמצעי להשגת מטרה. עם זאת, זהו אמצעי כה חשוב עד שכל השאר מאורגן סביבו. יתר על כן, גם פיתוח תוכנה עוסק בנתונים (אודות תוכנה) ובמודלים (כמפרטים). בסופו של דבר, ההבדלים הם הדרגתיים ולא מהותיים. המסע הזה רק החל, ואני לא באמת יודע לאן הוא יוביל. הישארו מעודכנים! בינתיים, ניתן לצפות בסרטון הדגמה זה. הערות מופעלות על ידי Disqus