בתחום שכל יומיים מופיע בו "הדבר הגדול הבא" ואז נעלם באותה מהירות, צריך להתייחס בחשדנות רבה לכל פיתוח מיוחצן חדש. עם זאת, שפת התכנות MicroPython מראה סימנים של עמידוּת, ויש לה תכונות שעשויות להשתלב יפה בנוף המייקינג המודרני, כך שאולי היא כן תצליח במקום שבו כל כך הרבה אחרים נכשלים. בואו נראה במה מדובר.

המפגש הראשון שלי עם גרסה של פייתון שהותאמה למיקרו-בקרים אירע לפני כחמש שנים – עוד לפני ש-MicroPython נולדה בכלל. זה היה במסגרת מערכת שעבדה יפה אבל הייתה קניינית ויקרה, ושמאז לא שמעתי עליה שוב. לפני שנה וקצת, במפגש השני (הפעם עם MicroPython ה"רשמית"), הייתי ארסי יותר אחרי שגיליתי שקוד בסיסי ללוח BBC Micro:bit איטי פי 97 מקוד מקביל בשפה נורמלית. אך עולם המייקינג לא מתפתח לפי הצרכים וההעדפות האישיים שלי, ושפת התכנות הזו ממשיכה להתעדכן ולהופיע בכל מיני מקומות חדשים: בלוחות פיתוח של Adafruit, במודולים מבוססי ESP8266 ועוד.

כזכור, Python ובעקבותיה MicroPython הן במהותן שפות מפורשות (Interpreted) ולא מהודרות (Compiled). כלומר, מה שרץ על הפלטפורמה הוא לא תרגום ישיר של הקוד שכתבנו לקוד מכונה, אלא תוכנת ביניים שלוקחת את הפקודות שלנו, מעבדת אותן תוך כדי ריצה ומבצעת את הפעולות הדרושות. זו הסיבה העיקרית לאיטיות, והשיטה מחייבת גם נפח זיכרון גדול בפלטפורמה, שצריכה "להחזיק" בו-זמנית הן את הקוד המפרש והן את הקוד המתפרש. אלא שבשנים האחרונות הופיעו בשוק עוד ועוד מיקרו-בקרים מהירים, בעלי נפח זיכרון גדול – ומה שהכי חשוב, זולים. הרצה של תוכניות MicroPython עליהם היא עדיין בזבוז משווע של משאבים, אבל היא לפחות מעשית, וזה בעצם כל מה שהמייקר הטיפוסי צריך.

ברמת מתחילים – לדעתי, לפחות – התחביר של שפת פייתון הגיוני או אינטואיטיבי לא יותר מאשר שפה כמו C. היתרון המיידי היחיד שאולי יש לו, שלא צריך להגדיר טיפוסים "קשיחים" למשתנים, הוא למעשה חיסרון בעולם המיקרו-בקרים. עם זאת, MicroPython מגיעה עם ספריות מוכנות-מראש, שמאפשרות ביצוע קל של מטלות שגרתיות עם החומרה ועם מודולים חיצוניים. כמובן, זה בדיוק מה שהפך את ארדואינו להצלחה שכזו: ספריות הליבה והספריות החיצוניות. אז למה לא להישאר עם התכנות של ארדואינו וזהו?

בספרו המפורסם "קיצור תולדות הזמן" הזכיר הפיזיקאי סטיבן הוקינג עצה שקיבל: "כל משוואה שתכתוב בספר תקצץ את מספר הקוראים הפוטנציאליים בחצי". נדמה שאותו הדבר נכון גם לגבי המייקינג: כל שורת קוד נוספת שהמשתמשים צריכים לכתוב מקטינה את קהל היעד של מוצר בחצי. יש המון חובבים שמתעניינים באלקטרוניקה רק בתור לגו, משהו שמרכיבים בלי לחשוב יותר מדי (עדיף עם הוראות מפורטות) ושפשוט פועל. עבור חובבים אלה, גם ההבדל הקטן במורכבות בין קוד פייתון בסיסי לקוד C מקביל הוא משמעותי ביותר. אותם חובבים הם גם הקהל הרווחי ביותר למוצרי מייקינג, והעבודה עם פייתון – שאינה "טבעית" למיקרו-בקרים – כובלת אותם עוד יותר בחוזקה למוצרים האלה, מה שנותן כמובן מוטיבציה גדולה ליצרנים.

מעבר לעניין הביצועים, ל-MicroPython ככלי למייקרים יש שתי נקודות תורפה. ראשית, כיוון שמנסים לממש אותה על פלטפורמות שהן שונות מאוד זו מזו, פשוט אי אפשר להגיע לאחידות מלאה: תמיד יהיו פקודות ופונקציות שיפעלו על X ולא על Y, או יפעלו בצורה שונה. זה קיים גם בארדואינו וגם שם זו בעיה, אבל בעוד שרוב לוחות הארדואינו בשטח עדיין מבוססים על אותו דגם של מיקרו-בקר (ה-ATmega328P), שפת MicroPython מנסה לכבוש שוק מבוזר הרבה יותר, ואין גוף אחד רשמי שקובע סטנדרטים גם לשפה וגם ללוחות הפיתוח.

שנית, מישהו צריך לכתוב את הספריות עבורה. הקוד בספריות האלה יכול להיות כתוב בשפות אחרות, והשילוב עם הקוד הפתוח של MicroPython אמור להיות קל יחסית, אלא שזה רק ישחזר את המצב הבעייתי שקיים בארדואינו – של ספריות לא טובות, לא תואמות, מסובכות לאיתור ולהתקנה וכו'. בג'ונגל המייקינג שקיים כרגע, סיכויי השרידה של השפה הזו לא נראים מזהירים, אבל במערכות סגורות ומנוהלות (כמו ה-BBC Micro:bit) שפת MicroPython משתלבת מעולה, וכאמור יש יסוד להשערה שבעתיד נראה עוד ועוד מערכות כאלה למייקרים.

מה שיכריע בסופו של דבר יהיה, כנראה, הסינים: אם הם יוציאו לשוק לוחות זולים ש-MicroPython מותקנת בהם מראש, ובמיוחד לוחות עם יכולות מורכבות שהפייתון תפשט (למשל תקשורת דרך WiFi או חיישנים מובנים), ייתכן שהשלטון הממושך והכמעט-מוחלט של ארדואינו בנישה שלו יתחיל להתפוגג.

בפוסט הבא בנושא אדגים עבודה עם MicroPython על BBC Micro:bit בעזרת סביבת הפיתוח Mu Editor, ונדבר על קלף מנצח נוסף של הכלים האלה – ה-REPL.