לא מזמן שוב שפכתי אש וגופרית על חבילת תוכנה שבה השתמשתי (במקרה הזה פואטרי) שנשברה אחרי ששידרגתי. מסתבר שמי שמנהל שם את הסיפור חשב שזה יהיה רעיון נפלא בגרסה 2 להוריד את הפקודה השימושית poetry shell ולאפשר אותה רק באמצעות פלגין. אולי זה יותר נכון ויותר ״הוליסטי״ אבל בגדול הוא שבר לי את הבילד והייתי צריך לשבור את הראש שלי על התיקון. גם אם זה תיקון קטן (זה תיקון קטן), זה עדיין עיצבן אותי ממש.
אם ה-poetry לא עובד, ואתה מרוב עצבים מטיח את המחשב ברצפה, זה נחשב פואטרי סלאם? ????
— Ran Shneor (@Ranchook1) January 8, 2025
דיברתי עם הבן שלי, עומרי, שהוא מתכנת מנוסה בפני עצמו ועובד ב-Teads והוא כמובן:
- צחק עלי.
- אמר לי שאני זקן.
אבל אמר לי שזה יהיה רעיון נפלא לדבר על שלושה דברים – הראשון הוא Stability as a feature, והשניים האחרים הם backward compatibility ו forward compatibility. זה פוסט שהוא לא מאד טכני אבל הוא כן חשוב במיוחד בעידן ה-LLMים שמאפשרים לכל אחד לכתוב קוד אבל לא בטוח שקוד נכון.
אז נתחיל עם Stability as a feature. מכירים את ״ישן מפני חדש תוציאו״? אז בדיוק ההיפך. יציבות היא ערך ומה הכוונה ליציבות? זאת אומרת שאם יש לי קוד שעובד עם ממשק מסוים – למשל SDK או API, הוא ימשיך לעבוד עם הממשק. כך שמי שמשתמש בו לא יצטרך לשנות את צורת העבודה שלו. ייתכן ודברים כן ישתנו – ספריות תלויות ישתנו, יש תכונות חדשות שניתן להפעיל בנוסף, אולי יותר יציבות למוצר, אולי מאחורי הקלעים הוא יעבוד באופן שונה לחלוטין – אבל הוא יהיה יציב. זה לא קשור רק לקוד אלא גם לממשק. הממשק של אמזון למשל יציב למדי, הם לא משנים אותו המון וזה מאד מקל לכתוב להם הדרכות וספרים.
האם זה אומר שבעצם המוצר לא משתנה ומתעדכן? בוודאי שלא! אפשר לעדכן ולשנות אותו נונסטופ אבל עם הקפדה על שני דברים עיקריים. הראשון הוא… backward compatibility.
backward compatibility
זו החלטה מוכרת למדי בתוכנה. זה אומר שכל שינוי שאני עושה יהיה תואם ל-API הקודם. זה נשמע קצת אבסטרקטי אז אני אדגים עם ג׳אווהסקריפט. הנה קוד ג׳אווהסקריפט מסוף שנות התשעים שהיה מתאים לתקן אנו באנו:
<script language="JavaScript">
<!-- Hide script from old browsers
function greet() {
var name = prompt("What is your name?", "Guest");
if (name) {
alert("Hello, " + name + "!");
} else {
alert("Hello, Guest!");
}
}
greet();
// End hiding script -->
</script>
יש פה דברים שחלק מכם לא מכירים. קודם כל התגית language וההערה של החבאת הסקריפט, ה-var, פקודת ה-prompt וה-alert שבוא ונגיד שקשה לראות אותם in the wild עדיין עובדות. זה מראה שגם לדפדפן וגם לג׳אווהסקריפט עצמה יש backward compatibility – כלומר קוד בעבר יעבוד גם בהווה. את זה אנחנו מכירים. זה לא אומר שאין פיצ׳רים חדשים – הרי ג׳אווהסקריפט וגם הדפדפנים מוציאים פיצ׳רים חדשים בקצב של מתופף בפסטיבל מטאל – אבל זה אומר שהפיצ׳רים הישנים, טיפשיים ומגוחכים ככל שנחשוב עליהם, עדיין עובדים. זה מאד לא טריוויאלי אבל זה גורם למערכת להיות מאד יציבה.
forward compatibility
אבל יש עוד משהו שמוסיף ליציבות וזה forward compatibility. מה זה אומר? זה אומר תכנון צופה פני עתיד. זה שימושי במיוחד בתוכנות. כאשר יש לך חשד גדול שהתוכנה שלך שנכתבה היום תריץ קוד עתידי שמיועד לגרסה חדשה יותר שלה. בדוגמה שלנו, דפדפן ישן שמריץ ג׳אווהסקריפט מתקן ישן שיכול להריץ קוד של היום. דוגמה טובה לכשלון כזה הוא הקוד הפשוט הזה:
let x = 5;
הקוד הזה, שרץ יפה מאד על כל דפדפן מהעשור האחרון+, ייכשל בצורה מחרידה אם אני אריץ אותו על דפדפן ישן באמת. למה? כי let לא היתה עם משמעות מיוחדת בג׳אווהסקריפט.
דוגמה טובה ל-forward compatibility היא HTML. כן, כן, הסינטקס הישן והטוב מתוכנן לקבל כל תגית גם אם הוא לא מכיר אותה ומטפל בה כתגית inline לא מעוצבת. אם למשל ��יקח דפדפן של היום, ונכניס לו קוד HTML שיש בו אלמנט עתידני כמו תגית ai. בשעת כתיבת שורות אלו אין את זה בכלל אבל… אולי יהיה בשנת 2035? בשנת 2045? נכון. זה עוד עשרים שנה מזמן כתיבת שורות אלו, אבל הבלוג הזה בן 17 שנה (יאוזה!) ועדיין הפוסט הראשון שנכתב בו רלוונטי (!) ודברים יכולים להיות. ואולי הדפדפן שאני משתמש בו עכשיו יותקן גם בצוללת גרעינית ובחיים לא יתעדכן ובעוד עשרים שנה מישהו ייכנס לאתר וייתקל עם הדפדפן של היום בסינטקסט של עוד עשרים שנה? נניח קוד כזה:
<!DOCTYPE html>
<html>
<head>
<title>Future Compatibility Demo with <ai> Tag</title>
<style>
ai {
display: block;
font-size: 1.2em;
color: darkblue;
border: 2px solid gray;
padding: 10px;
margin: 10px 0;
}
</style>
</head>
<body>
<h1>Future Compatibility Demo</h1>
<!-- Custom <ai> tag with hypothetical props -->
<ai name="chatbot" version="1.0" mood="friendly">
Hello! I'm a custom <ai> element!
</ai>
<script>
// Access the custom <ai> tag
var aiElement = document.querySelector("ai");
console.log("AI Element Props:");
console.log("Name:", aiElement.getAttribute("name"));
console.log("Version:", aiElement.getAttribute("version"));
console.log("Mood:", aiElement.getAttribute("mood"));
// Future Compatibility Issue:
// If a future browser introduces a native <ai> tag with its own behavior and attributes,
// this custom implementation might break or behave differently.
</script>
</body>
</html>
אתם יכולים להריץ אותו. הוא יעבוד – למרות שתגית ai לא קיימת והמצאתי אותה, הקוד הזה יעבוד בדפדפן של היום. נכון, הפונקציונליות לא תעבוד בדפדפן של היום, אבל הוא לא יקרוס ויתפוצץ כמו דפדפן של לפני עשרים שנה כשהוא מקבל ג׳אווהסקריפט מודרני. וזה בדיוק forward compatibility.
סיכום
למדנו שלושה מונחים בתחום הנדסת תוכנה. בעידן של LLM בו קל לייצר קוד, לצערי עדיין צריכים את הטאץ׳ האנושי בהדרכה והכוונה של כתיבת הקוד וחלק מהטאץ׳ הזה הוא מחשבה קדימה. איך אנחנו ב��נים קוד שלא נשבר בכל שינוי – בין אם מדובר בתוכנה או מדובר ב-API ואיך אנחנו צופים פני עתיד ובונים קוד שיהיה גמיש גם לשינויים עתידיים. מקווה שהצלחתי לעניין ולסקרן. אולי גם את הקוראים של עוד 17 שנה.
8 תגובות
הכי קטנוני שיש אבל שלושה עקרונות ולא שלוש…..
תיקנתי, תודה! 🙂
אתה משתמש בתג ai במקום בטקסט בתוך תג ה ai.
אתה אמור לכתוב <ai>
לא תכננתי שתעשה לי unescape
זה מה שצריך
<ai>
שורה תחתונה – אתה זקן! והדבר הכי נכון זה להודות בזה.
העולם הוא דבר מתפתח.
פעם פעם בשביל להפעיל מכשיר חשמלי היתה צריך להיות חשמלאי. היום אתה קונה הכל באלי אקספרס.
מה חשבת שעולם התוכנה ישאר מאחור? תם עידן הטאלטים של התוכנה.
חחח עוד רגע תרצה גם לחזור לכתוב בשפת מכונה….
אני מבוגר ולא מתבייש בזה. אבל אני חושב שצריך רקע טכני בשביל להבין את הפוסט שיש פה ובטח ובטח אם מתיימרים לדעת מה יהיה בעתיד. אפילו אם כותבים קוד באמצעות LLM.
וואו, ממש זרקת אותנו אחורה לעידן הדינוזורים עם ה"טאלטים" ושפת המכונה! ???? ברצינות נראה שפספסת לגמרי את העיניין. תאימות לאחור וקדימה זה לא על להשאר מאחור, אלא על לבנות תוכנה ששורדת שינויים בלי להתפרק כמו משלוח זול מאלי אקספרס שמגיע שבור. להשוות את זה לחשמלאות של פעם? זה כמו להגיד שכתיבת קוד מסודר זה "זקן". פשוט חוסר הבנה בסיסי של איך מפתחים משהו שמחזיק מעמד. תכנון מראש זה לא זקנה, זה מה שמפריד בין קוד שרץ לקוד שקרס. ואגב, אם יש לך תקלת חשמל בבית, מקווה שלא תזמיני חשמלאי מאלי אקספרס. קראי שוב את המאמר, אולי תביני יותר טוב בפעם הבאה.
ציטוט מתוך שיחה ארוכה במסטודון
There's a lot to dislike about Perl, but more language designers should consider that "the language has been stable for decades" is a really good feature to have.
Perl's motto is "there's more than one way to do it." Python's motto is, "There's only one RIGHT way to do it, and we'll change it every 37 minutes."