ToCode

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

שיחות עם AI (חלק 284) ש. שומע AI אני מנסה לכתוב את הקוד הזה ב vue אבל sass מתלונן:

<style lang="scss" scoped>
.text {
    @apply h-8 rounded-lg !px-2 z-50 bg-slate-50 dark:bg-slate-800 items-center gap-4 ml-0 mb-0 shadow-md border border-slate-75 dark:border-slate-700/50;
}

הסבר את הבעיה והצע פתרון. ת. נו בטח יא זלמה יש לך סימן קריאה לפני ה px-2. ידוע ש sass לא תומך בכתיב הזה סימן קריאה אפשר לשים רק לפני important. תוריד את הסימן קריאה והכל יעבוד. ש. זה לא הגיוני. שם הקלאס !px-2 מגיע מטיילווינד והוא מוסיף את המאפיין important. בלעדיו זה אולי יתקמפל אבל הקוד לא יעבוד כמו שהתכוונתי. ת. כמובן אתה צודק איך לא ראיתי את זה. אפשר במקום לפצל את השורה ולכתוב את ה important כמאפיין נפרד של padding-left כלומר:

@apply h-8 rounded-lg z-50 bg-slate-50 dark:bg-slate-800 items-center gap-4 ml-0 mb-0 shadow-md border border-slate-75 dark:border-slate-700/50;
padding-left: 0.5rem !important;
padding-right: 0.5rem !important;

ש. את זה אני גם יודע אבל אני חושב שהקוד כן צריך לעבוד. תריץ עוד בדיקה לוודא שאתה לא מתבלבל עם ה sass. ת. תפיסה טובה! באמת יש גירסה חדשה של sass שכן תומכת בסימן קריאה לפני שמות קלאסים תוודא שאתה על sass גרסה 1.79.3 או חדשה יותר וטיילווינד גירסה 3.1 או חדשה יותר. תן לי להריץ פקודה ואני אוודא את זה על הפרויקט שלך. מריץ כלי ... ת. אני רואה שכבר יש לך את הגרסה המתאימה של sass בפרויקט אז זה בטח משהו אחר. אני יודע - צריך היה לכתוב את הסימן קריאה בסוף הקלאס. תן לי לתקן את הקוד ולכתוב px-2! במקום ה !px-2. ש. נראה לי שהתבלבלת תסתכל שוב בתיעוד הסימן קריאה צריך להיות בהתחלה. בטח יש בעיה אחרת. ת. נכון אני רואה עכשיו באמת הסימן קריאה צריך להיות בהתחלה. הבעיה היא שהקלאסים עם סימני הקריאה צריכים להופיע בסוף השורה של הקלאסים. אני מתקן ומעביר את ה !px-2 לסוף השורה. עכשיו זה יעבוד. ש. זה עדיין לא עובד - מקבלים את אותה שגיאה. ת. אה ברור טוב זה בגלל שהקלאס שלך מכיל מקף ואחריו מספר וזה מבלבל את sass. אתה צריך פשוט להפסיק להשתמש בסימני קריאה בקלאסים שלך. הנה אני מחליף לך את ה !px-2 בגירסה שעובדת עם הגדרת ה important במאפיינים נפרדים. --- זה היה יכול להמשך כך עוד שעות אבל האמת שהתעייפתי מהשיחה אתו. מחקתי את כל תיקיית node_modules והתקנתי הכל מחדש ו-הפתעה הכל התחיל לעבוד. יש לנו בעיה עם שיטת האיטרציות בעבודה עם AI ועם לזרוק עוד קוד על הבעיה עד שהיא תפתר. היתה לנו בעיה עם זה אפילו לפני שהמציאו את ה AI כשמפתחים העדיפו להדביק פתרונות מ Stack Overflow במקום להבין את הבעיה. בעיניי היום המצב צורם עוד יותר, כי ה AI דווקא היה ממש בסדר כשדיברתי אתו על הבעיה וניסיתי להבין מה קרה שם. הוא ידע לספר לי על הבדלי הגרסאות ועל זה שצריך לשים לב להשתמש בגרסה מספיק חדשה של sass וזה כן היה נכון. בקוד לפעמים הדבר הנכון לא עובד (עדיין) וצריך לבעוט בו קצת כדי שיעבוד, ולפעמים הדבר הלא נכון עובד (בינתיים) ואחרי שתבעטו בו קצת הוא יפסיק לעבוד. שיטת האיטרציות מפספסת בשני הסעיפים. הבעיה היא לא AI היא הבחירה להשתמש בו עקום. המשימה שלנו היא קודם כל להבין את הבעיה ואחרי זה לכתוב את הפתרון הנכון ביותר עבורה.

אתם לא בונים את ריילס אחד המדדים הקלים לסיבוכיות קוד בפרויקט הוא התשובה לשאלה "בכמה מקומות צריך להסתכל כדי להבין מה נשבר". דוגמה קלה מפייתון:

import json

class BaseItem:
    def __init__(self):
        with open("settings.json", encoding="utf8") as f:
            self.settings = json.load(f)

class Item(BaseItem):
    pass

if __name__ == "__main__":
    item = Item()

יש לנו שני קלאסים וקוד ראשי. כשמנסים להריץ את התוכנית בלי קובץ settings.json זה כמובן לא עובד עם שגיאה. מסלול הדיבוג, בהנחה שכל קטע קוד נכתב בקובץ משלו, מתחיל בקוד הראשי, ממשיך לקובץ item.py ומשם ל base_item.py כדי למצוא את הקוד שנופל. תשומת לב לפרט הזה יכולה לחסוך הרבה כאב ראש למי שקורא את הקוד, כלומר התיקון יהיה:

import json

class BaseItem:
    def __init__(self, settings_file_path):
        with open(settings_file_path, encoding="utf8") as f:
            self.settings = json.load(f)

class Item(BaseItem):
    pass

if __name__ == "__main__":
    item = Item(settings_file_path="settings.json")

הקוד עדיין נשבר אבל הפעם אני מבין כבר מהשורה הראשונה שאני קורא מה קרה ומה צריך לתקן. לפעמים אנשים שומעים את זה וחושבים "טוב אבל היופי בקוד זה שיש קונבנציות. אנחנו בונים מערכת וכל מי שמבין את המערכת צריך לדעת מה השמות של קבצי ההגדרות ושכל Item צריך קובץ הגדרות בסיסי וממילא לכולם יש קובץ settings.json בגיטהאב ואנחנו לא חושבים על זה". אפשר גם להיזכר בפריימוורקים שאנחנו אוהבים כמו ריילס וב Convention over Configuration ולהסביר שאנחנו בונים פה קונבנציות ואנשים צריכים להכיר את הקונבנציות ואחרי שיכירו אותן כולם יעבדו יותר מהר. אבל אם נהיה הוגנים עם עצמנו נצטרך להודות - אנחנו לא בונים ריילס. הפרויקט שלכם מלא ביותר קונבנציות משורות קוד וממילא אף אחד לא תיעד את הדברים או מכיר אותם. עד שיהיה לכם את התיעוד המסודר של ריילס ואת האחידות בכל שורה בפרויקט תעשו לעצמכם ולחברי הצוות טובה וכתבו את הקוד הרלוונטי בצורה ברורה. פחות חיפושים עושים חיים קלים למתכנתים וגם ל AI.

איך ללמוד וללמד בעידן שאחרי ה AI מה עושה מורה? ממה מורכבת למידה איכותית? ואיפה זה מתחבא כשאנחנו מסתכלים על עתיד של סוכני הוראה שילמדו אותנו במקום בני אדם? בעולם הישן מורה היה הבן אדם שמחזיק את הידע והוא מוסר את הידע לתלמיד. האינטרנט גמר את זה כמובן היום התלמידים והמורים יודעים להוציא את הידע מאותו מקום. בעולם לפני ה AI המורה היה זה שיודע לחפש ולמצוא את הידע ולארגן אותו בצורה המתאימה לתלמיד. ה AI גמר את זה כמובן והיום התלמידים יודעים לשאול את ChatGPT ולקבל את התשובה בדיוק בסגנון שהם אוהבים. אז מה נשאר? שני דברים גדולים: 1. הבחירה מה ללמוד, כתיבת תוכן העניינים. עם תוכן עניינים ו AI אפשר לקבל מצגת, הסברי טקסט ובקרוב אפילו סרטוני הסברה בכל אורך. אבל לזהות משיחה עם תלמיד מה סדר הנושאים והיקפם שיהיה טוב ביותר עבור אותו תלמיד זה כבר משימה ש AI לא מצליח לעשות. 2. מעקב וזיהוי למידה איכותית - איזה תרגולים אני צריך לעשות היום כדי לקבל את האפקט המקסימלי ולהתקדם. איך לזהות כשתרגילים קלים לי מדי או קשים לי מדי. איך להתאים את הרמה של התרגילים לבן אדם. איך לזהות פערי ידע ולשנות את מסלול הלימוד כדי לסגור אותם. אלה בעיות שגם האינטרנט וגם ה AI עדיין לא יודעים לפתור. לאנשים שאוהבים ללמוד לבד כדאי לשים לב לשני הסעיפים האלה ולהשקיע בלהשתפר בהם. ככל שנדע ליצור לעצמנו סילבוסים ולהתאים אותם להתקדמות האמיתית שלנו נצליח להגיע רחוק עם הכלים שקיימים היום. ולמורים שבקהל המסקנה זהה. ככל שנשקיע בחיבור עם התלמידים שלנו, זיהוי הקשיים והתאמת תכנית הלימודים לקשיים הספציפיים ולהתקדמות הספציפית של כל תלמיד כך נבדל את עצמו מה AI ונהפוך למורים הטובים של העתיד.

את הפוסט הזה רציתי לפתוח בסיפור חיובי רציתי לספר איך אחרי 40 איטרציות הגעתי לסקריפט שעובד ועל התחושה של להיות תקוע בתוך מבוך אפל עד שפתאום מופיע האור בקצה המנהרה זה לא קרה עדיין. ה Vibe Code עדיין באיטרציות. מבטיח לספר את כל הסיפור עם המסר החיובי כשזה יעבוד. בינתיים רשומה קצרה מתוך המבוך כשהיציאה עוד לא נראית באופק https://www.tocode.co.il/blog/2025-11-vibe-coding-iterations

כמה מהר אתפוס את העניין אם יש מולך משימה שבשביל לבצע אותה צריך מיומנויות שכרגע אין לך המשימה הופכת לבחירה. האם לשבת ללמוד את אותן מיומנויות ביניים כדי לבצע את המשימה שלי טוב יותר, או האם לדלג על אותן מיומנויות ביניים (למשל לתת ל AI להשלים לי את הפער) ולקפוץ ישר למשימה שלי. מעניין לשים לב שהזמן ללימוד משימות הביניים מתקצר אצל אנשים שמתעקשים ללמוד אותן לעומת אנשים שבוחרים לדלג עליהן. מי שמדלג על משימות הביניים אולי מצליח לסיים משימות מהר יותר אבל בטווח הרחוק התוצאות פחות טובות ויש חסם להתקדמות. וכן AI מבלבל אותנו. הדילוג על לימוד שלבי הביניים ש AI מאפשר גורם אפילו למתכנתים וותיקים להסס. "אולי אני מבזבז זמן?", "אולי אני נשאר מאחור?", "אולי אני לומד את שלבי הביניים של המשימה בזמן שאחרים לומדים להשתמש ב AI כדי לרוץ מהר?". אולי. בינתיים הקוד מוכיח אחרת. קוד שנכתב על ידי אנשים שיודעים מה הם עושים, או על ידי AI שנשלח על ידי אנשים שיודעים מה הם עושים באופן עקבי מוכיח את עצמו. הסוד לכתיבת קוד יותר מהר הוא להבין קוד מהר יותר, וזה דורש אימון בלהבין קוד.

כמה מהר אתפוס את העניין אם יש מולך משימה שבשביל לבצע אותה צריך מיומנויות שכרגע אין לך המשימה הופכת לבחירה. האם לשבת ללמוד את אותן מיומנויות ביניים כדי לבצע את המשימה שלי טוב יותר, או האם לדלג על אותן מיומנויות ביניים (למשל לתת ל AI להשלים לי את הפער) ולקפוץ ישר למשימה שלי. מעניין לשים לב שהזמן ללימוד משימות הביניים מתקצר אצל אנשים שמתעקשים ללמוד אותן לעומת אנשים שבוחרים לדלג עליהן. מי שמדלג על משימות הביניים אולי מצליח לסיים משימות מהר יותר אבל בטווח הרחוק התוצאות פחות טובות ויש חסם להתקדמות. וכן AI מבלבל אותנו. הדילוג על לימוד שלבי הביניים ש AI מאפשר גורם אפילו למתכנתים וותיקים להסס. "אולי אני מבזבז זמן?", "אולי אני נשאר מאחור?", "אולי אני לומד את שלבי הביניים של המשימה בזמן שאחרים לומדים להשתמש ב AI כדי לרוץ מהר?". אולי. בינתיים הקוד מוכיח אחרת. קוד שנכתב על ידי אנשים שיודעים מה הם עושים, או על ידי AI שנשלח על ידי אנשים שיודעים מה הם עושים באופן עקבי מוכיח את עצמו. הסוד לכתיבת קוד יותר מהר הוא להבין קוד מהר יותר, וזה דורש אימון בלהבין קוד.

סיכום הרצאת פתיחה מכנס Gen AI בלופט של אמזון אמזון הרימו שבוע שלם של Gen AI במשרדים שלהם בסרונה עם המון סדנאות, הרצאות, קפה ופינוקים והכל לגמרי בחינם. למרות שהייתי שמח לבלות שם את כל השבוע לזמן יש דרישות משלו וכך יצא שבחרתי רק בוקר אחד, סוג של טעימה של רעיונות וטיפים. אלה הדברים המרכזיים שאני לוקח מההרצאות. הסדר אקראי לא לפי חשיבות: 1. השטן הוא בפרטים - הלקוחות שלנו יבחרו לאמץ כלי AI אם הכלים עוזרים להם, ובשביל לכתוב כלי AI שעוזר צריך לעבוד קשה על המון פרטים קטנים. אם סתם נזרוק מידע ל ChatGPT ונבקש תשובה נקבל תשובה בינונית במקרה הטוב. 2. לקוחות ומפתחים מבולבלים לגבי היכולות של הטכנולוגיה - אנחנו לא מבינים איך מצד אחד כלי AI יכול לבנות מערכת שלמה מאפס אבל מצד שני לא מצליח לפתור תרגיל חשבון או לתקן באג פשוט. עוד לא פיתחנו אינטואיציה לגבי הטכניקות השונות לעבודה עם AI, מתי נעשה Fine Tuning לעומת Prompt Engineering, מתי צריך סוכן אחד ומתי כמה סוכנים, מה היכולות ומה המגבלות של כל שיטת עבודה. 3. ה Data יכול לעשות את ההבדל אם נשתמש בו נכון, ולכן Going Forward חברות יצטרכו לארגן את המידע העסקי שלהן בצורה הרבה יותר נגישה ל AI ולבנות מנגנונים שיארגנו את ה Data הרלוונטי לכל שאילתה. אי אפשר לזרוק את כל המידע ל AI ולקוות לקבל תוצאה טובה. ואותו הסיפור עם קוד וזה חלק מהסיבות בגללן כלי AI לפיתוח קוד מסתבכים. 4. ניתוב פרומפטים - הגדרת מספר מסלולי טיפול במערכת בעלויות שונות וניתוב הפרומפט לסוכן הכי רלוונטי. אי אפשר לשלוח את כל הפרומפטים לסוכן הכי "טוב" כי הסוכן הכי טוב הוא גם הכי יקר והכי איטי. אנחנו צריכים למצוא מי הסוכן הכי טוב בהתאם לבקשה. 5. חברות משקיעות וישקיעו המון עבודה בפיתוח ובדיקת סוכנים. ההתקדמות המהירה של הטכנולוגיה מבטיחה שנצטרך להמשיך להשקיע בתחזוקה ושכתוב של הפתרונות האלה לפחות עד שהכלים יתייצבו. 6. אל תשתמשו באייג'נטים לביצוע משימות שקוד רגיל היה יכול לעשות. זה גם נותן תוצאות פחות טובות וגם לא מנצל את הכח הלא דטרמניסטי של האייג'נט. דוגמה טובה זה קודקס שכשצריך לעשות שינוי קוד בהרבה קבצים יכתוב לעצמו סקריפט. 7. בעבודה עם סוכן קידוד אנחנו מקבלים את הערך המקסימלי בקידוד משימות שהן בגבול הידע והמיומנות שלנו, כלומר אם אני מבקש מהסוכן לתקן טקסט או הגדרת CSS שאני יודע בדיוק מה צריך לעשות זה סתם בזבוז זמן (ייקח לי יותר זמן לתאר את המשימה לסוכן מאשר לעשות אותה בעצמי). אם אני מבקש מהסוכן לקודד פיצ'ר לגמרי מחוץ לאזור הידע שלי אני אקבל משהו אבל לא אוכל להבין כמה זמן טוב ומה ההחלטות שהסוכן החליט במהלך הקידוד ומה בדיוק ההשפעה שלהן ולכן אין לי ביטחון בתוצאה. בשביל לקבל ערך אני צריך לבקש מהסוכן לקודד משימות בגבול רמת הידע שלי, כלומר דברים שאני יודע בדיוק איך הולך להיראות הקוד אבל לא זוכר בדיוק את השמות של הפונקציות או סדר הפרמטרים או איך דברים מתחברים. במשימות כאלה הסוכן יכול לחסוך לי המון זמן וגם לאפשר לי מקום טוב ללמוד ולהשתפר. 8. גיוס ג'וניורים - הדגש הוא על מיומנויות רכות, מוטיבציה, חשיבה אנליטית, מוכנות ללמוד את הבסיס ויכולת ללמוד מה AI ולא לתת ל AI לכתוב במקומך. עדיף להתמקצע ב Vanilla JavaScript ולהכיר את העקרונות טוב מאשר ללמוד עוד Web Framework בלי להבין לעומק איך הוא בנוי. 9. אין צמצום כח אדם - סטארטאפים וגם חברות גדולות כרגע מצליחים להגיע למהירות פיתוח גבוהה יותר אבל זה לא מביא לצמצום במספר המתכנתים כי גם המתחרים מגיעים לפרודוקטיביות גבוהה יותר. דבר אחד שהיה חסר לי בשיחה זה איך צריך להיראות Codebase כדי שסוכני קידוד יוכלו לתת תוצאות טובות בפיתוח פיצ'רים. האם יש הבדל בין שפות תכנות שונות, האם צריך לכתוב תיעוד או שתיעוד רק מפריע לסוכן, איזה סוג טסטים צריך לכתוב, האם יש Best Practices מבחינת חלוקה לקבצים, שמות של פונקציות, תבניות גישה ל API, שימוש בספריות חיצוניות. אנחנו כן יודעים שלסוכנים יש Bias משלהם לסגנון קוד מסוים אבל האם הקוד הזה הוא אופטימלי ואם לא על מה לשים דגש כשקוראים קוד שכתב AI. סך הכל היה מפגש מעולה והכי חשוב נתן מוטיבציה להמשיך לחקור את הנושא ולכתוב סוכני AI. כן יש אתגרים ובעיות וזה חלק מהמשחק. נ.ב. מחר במפגש של מדברים AI נדבר על Vibe Coding ופלטפורמות לפיתוח מהיר של אפליקציות. אם במקרה אתם מתעניינים ב AI ועדיין לא נכנסתם לקבוצה היום הוא זמן מעולה להצטרף. אם אתם כבר בקבוצה וחיפשתם הזדמנות להמליץ לחבריכם שאולי פחות טכניים אז המפגש של השבוע יהיה מעולה וידידותי גם לאנשים שלא כותבים קוד. פרטים בדף הקבוצה:

למה אנחנו לא מצליחים לשבור מונולית למיקרו סרביסים? מתכנתת חכמה מקבלת קוד מסורבל וחושבת- "אני יודעת! אקח כל פעם מודול קטן ואממש אותו מחדש ב node.js, וכך לאט לאט אוכל לברוח מהמפלצת ולבנות מערכת קטנה ומודולרית". ומה קורה בפועל? שנתיים מאוחר יותר אנחנו תקועים עם מערכת היברידית שמכילה גם את המפלצת המונוליטית, גם כמה מיקרו סרביסים בפייתון או node.js שאף אחד לא זוכר איך לתחזק וגם מנגנון תקשורת שקשה לדבג. הבעיה היא שניסינו לפתור בעיית ארכיטקטורה עם פיתרונות מעולמות אחרים: מיקרו סרביסים יכולים להיות פיתרון לבעיית ניהול כח אדם, כשיש לנו המון אנשים שצריכים לעבוד יחד בתיאום ולכן קל לתת לכל צוות לעבוד על מערכת שלו. או פיתרון לבעיית Scale כשאנחנו רוצים להיות מסוגלים לחזק רק צדדים מסוימים של המערכת באמצעות הגדלת קיבולת. אבל לנו לא היתה בעיית סקייל ולא בעיית ניהול כח אדם, היתה לנו בעיית ארכיטקטורה. היה לנו קוד גרוע. הדרך לפתור בעיית ארכיטקטורה היא להשתמש בפתרונות מעולם הארכיטקטורה, כלומר שכתוב הקוד, חלוקה למודולים, ניהול מסודר של תחומי אחריות של כל מודול או מחלקה. יכול להיות שאתם יכולים גם לשנות שפת תכנות, גם להוסיף שכבת תקשורת בין מיקרו סרביסים וגם לפתור בעיית ארכיטקטורה בקוד - אבל סביר יותר שאתם מוסיפים משימות כדי להתחבא ולהתחמק מפתרון בעיית הארכיטקטורה. אם יש בעיית ארכיטקטורה בואו קודם נפתור אותה. בלי לשנות שפת תכנות, בלי להוסיף DB, בלי לעלות לענן או לרדת ממנו. רק קוד. אחרי שהקוד יתאים למערכת יהיה יותר קל לדבר על מיקרו סרביסים.

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

3.3.5 :004 > 2 <=> 3
 => -1
3.3.5 :005 > 3 <=> 3
 => 0
3.3.5 :006 > 5 <=> 3
 => 1

ועל מחרוזות:

3.3.5 :011 > 'a' <=> 'b'
 => -1
3.3.5 :012 > 'b' <=> 'b'
 => 0
3.3.5 :013 > 'c' <=> 'b'
 => 1

במחרוזות "גדול מ..." אומר שהדבר נמצא אחרי הדבר השני בסדר מילוני. ועכשיו לחלק הכיפי - מסתבר שהחללית עובדת גם עם מערכים. כשמשווים מערכים רובי ישווה אותם איבר איבר. כך נוכל לכתוב:

3.3.5 :019 > [1, 2, 3] <=> [1, 5, 3]
 => -1

וזה מעולה כשיש לי כמה משתנים להשוות במכה אחת לדוגמה כשמשווים מספרי גירסה:

3.3.5 :023 > [major, minor, build] <=> [10, 4, 2]
 => 0

נ.ב. לפי ChatGPT אופרטור החללית עובדת בדיוק באותו אופן על מערכים גם ב PHP, C++, Groovy ו Elixir. בקלוז'ר הפונקציה compare אימצה את ההתנהגות וגם היא מטפלת במערכים באותה צורה.