למה שפות תכנות אינן מספיקות

שפות תכנות מתארות פרוצדורות. הן אינן מסוגלות לתאר את העולם.

שפות תכנות הן אחד ההמצאות הגדולות של האנושות

שפות תכנות הן חד-משמעיות. x = 3 + 4 נותן 7 ללא קשר למתי ואיפה זה מורץ. אין מקום לפרשנות.

שפות תכנות ניתנות לאימות. שגיאות תחביר נתפסות לפני הקומפילציה. שגיאות טיפוסים נתפסות לפני ההרצה. כשבדיקות רצות, התוצאה היא עבר או נכשל.

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

כל מה שסדרה זו זיהתה כמגבלות של שפה טבעית — עמימות, חוסר יכולת אימות, חוסר מבנה — שפות תכנות פתרו לחלוטין.

אז למה לא להשתמש בשפת תכנות כדי לייצג את ההקשר של בינה מלאכותית?

זה לא עובד.

שפות תכנות מתארות פרוצדורות

הקוד הבא הוא קוד Python תקף.

def calculate_revenue(units_sold, unit_price):
    return units_sold * unit_price

הקוד הזה ברור, ניתן לאימות וניתן להרצה. אבל מה הוא מבטא?

“הכפל את מספר היחידות שנמכרו במחיר ליחידה כדי לקבל הכנסות.”

זו פרוצדורה. שיטה. ה-HOW (איך). היא מתארת מה לעשות כשהקלט מגיע.

עכשיו ננסה לבטא את הבא.

“ההכנסות של סמסונג אלקטרוניקס ברבעון השלישי של 2024 היו 79 טריליון וון.”

זו לא פרוצדורה. זו עובדה. ה-WHAT (מה). שום דבר לא מבוצע. זה מתאר את מצב העולם.

איך מבטאים את זה ב-Python?

samsung_revenue_2024_q3 = 79_000_000_000_000

מספר הושם למשתנה. זה עובד. אבל זה לא תיאור. זה אחסון. הקוד הזה לא יודע:

• מאיזה סוג ישות היא “סמסונג אלקטרוניקס”.
• מה המשמעות של “הכנסות”. האם זה מדד פיננסי? גודל פיזיקלי?
• האם “Q3 2024” הוא זמן, גרסה או תווית.
• מה המקור של נתון 79 טריליון וון.
• עד כמה ערך זה ודאי.

שם המשתנה samsung_revenue_2024_q3 מאפשר לאדם לנחש את המשמעות. עבור המכונה, זה מחרוזת שרירותית. שנה את שמו ל-xyzzy_42 ותוצאת ההרצה תהיה זהה.

בשפות תכנות, שמות משתנים אינם נושאים משמעות. המשמעות חיה מחוץ לקוד, בראש של המתכנת.

תחכום נוסף אינו עוזר

מה אם ניצור מחלקה (class)?

class FinancialReport:
    def __init__(self, company, metric, period, value, currency):
        self.company = company
        self.metric = metric
        self.period = period
        self.value = value
        self.currency = currency

report = FinancialReport("삼성전자", "매출", "2024-Q3", 79_000_000_000_000, "KRW")

יותר טוב. יש מבנה עכשיו. אבל הבעיות נשארות.

company הוא המחרוזת “삼성전자” (סמסונג אלקטרוניקס). “Samsung Electronics”, “SEC” ו-“005930” כולם מתייחסים לאותה חברה. האם הקוד יודע את זה? לא. הוא יכול רק להשוות אם מחרוזות שוות או לא.

metric הוא המחרוזת “매출” (הכנסות). האם “매출”, “매출액” ו-“revenue” הם אותו דבר או דברים שונים? הקוד לא יודע. המחרוזות שונות, אז הן דברים שונים.

מה אם נגדיר סכמה? לנהל רשימת חברות עם Enum, לנהל רשימת מדדים. בטח. זה עובד.

אז ננסה לבטא את הבא.

“יי סון-שין היה גדול.”

opinion = Opinion("이순신", "was", "위대했다")

מה זה? מחרוזת “이순신” (יי סון-שין) מקושרת למחרוזת “위대했다” (היה גדול). זה לא מבטא “יי סון-שין היה גדול”. זה מאחסן “이순신” ו-“위대했다”.

הקוד לא מכיר את המשמעות של “위대했다” (היה גדול). האם “위대했다” (היה גדול) ו-“훌륭했다” (היה נפלא) דומים, האם “비겁했다” (היה פחדן) הוא ההפך — הקוד אינו מסוגל לדעת.

עובדות מובנות כמו נתונים פיננסיים ניתנות לטיפול במידה מסוימת. הערכות, הקשר, יחסים, תיאורים מופשטים — אלה מעבר לטווח הביטוי של שפות תכנות.

קוד לא יודע מה הוא עושה

def process(data):
    result = []
    for item in data:
        if item["value"] > threshold:
            result.append(transform(item))
    return result

הקוד הזה רץ בצורה מושלמת. אבל מה הוא עושה?

האם הוא מסנן נתוני הכנסות? סוקר רשומות מטופלים? מנקה נתוני חיישנים?

הקוד עצמו לא יודע. data, value, threshold, transform — הכול שמות מופשטים. האם הקוד הזה שייך למערכת פיננסית או למערכת רפואית תלוי בהקשר מחוץ לקוד.

אפשר לכתוב הערות. אבל הערות הן שפה טבעית. מכונות לא מבינות אותן. אם הערה סותרת את הקוד, הקומפיילר לא שם לב. הערות הן לבני אדם, לא למכונות.

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

הסיבה הבסיסית

העובדה ששפות תכנות אינן מסוגלות לתאר את העולם אינה פגם בתכנון. המטרה שונה.

מטרתה של שפת תכנות היא להורות למכונה על פרוצדורות. “כשהקלט הזה מגיע, בצע את הפעולה הזו.” הסמנטיקה של שפת תכנות היא סמנטיקה של ביצוע. כל מבנה מפורש כ"מה המכונה עושה".

x = 3 היא ההוראה “אחסן 3 במיקום הזיכרון בשם x”. if x > 0 היא ההוראה “אם x גדול מ-0, הרץ את הבלוק הבא”. return x היא ההוראה “החזר את ערכו של x לקורא”.

הכול פעלים. הכול פעולות. הכול פרוצדורות.

“סמסונג אלקטרוניקס היא חברה קוריאנית” אינו פועל. לא פעולה. לא פרוצדורה. זה מתאר באיזה מצב נמצא העולם.

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

מה לגבי JSON, YAML, XML?

אם לא שפות תכנות, מה לגבי פורמטים של נתונים?

{
  "company": "삼성전자",
  "metric": "매출",
  "period": "2024-Q3",
  "value": 79000000000000,
  "currency": "KRW"
}

יש מבנה. השדות מפורשים. אבל אין משמעות.

האם “company” פירושו תאגיד — JSON לא יודע. האם “삼성전자” זהה ל-“Samsung Electronics” במקום אחר — JSON לא יודע. האם אובייקט JSON זה ואובייקט JSON אחר מתארים את אותה ישות — JSON לא יודע.

JSON מספק מבנה אך לא משמעות. אלה זוגות מפתח-ערך, לא ישות-יחס-תכונה.

הגדרת סכמות עוזרת. JSON Schema, Protocol Buffers, GraphQL. טיפוסי שדות מוגדרים, שדות חובה מוגדרים, הפניות מוגדרות.

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

סכמה נפרדת לכל תחום. כלי נפרד לכל סכמה. ללא יכולת פעולה הדדית בין סכמות.

מגבלה זו נדונה ביתר פירוט ב-למה MD/JSON/XML לא מספיקים.

מה לגבי LISP?

חלק מהקוראים אולי חשבו על דוגמה נגדית.

LISP.

(is 삼성전자 (company korea))
(revenue 삼성전자 2024-Q3 79000000000000)
(great 이순신)

S-expressions הם מבני עץ, וקוד הוא נתונים ונתונים הם קוד. הומואיקוניות (homoiconicity).

למעשה, בינה מלאכותית מוקדמת הייתה כולה מבוססת LISP. SHRDLU, CYC, מערכות מומחה. ידע יוצג ב-LISP, ומנועי הסקה רצו עליו. נראה כאילו יש הפרכה היסטורית לטענה ש"שפות תכנות אינן מסוגלות לתאר את העולם".

אבל הדוגמה הנגדית נכשלת משלוש סיבות.

מה ש-LISP יודעת לעומת מה שהמתכנת החליט

ב-(is 삼성전자 company), LISP אינה יודעת ש-is פירושו היחס “הוא”. המתכנת הוא שהחליט כך.

החלף את is ב-zzz ו-LISP אדישה. (zzz 삼성전자 company) הוא ביטוי תקף לחלוטין עבור LISP.

LISP מספקת מבנה. עץ הנקרא S-expression. אבל המשמעות בתוך המבנה הזה הוקצתה על ידי המתכנת, לא על ידי השפה. זה ביסודו אותו דבר כמו JSON שאינו יודע את המשמעות של המפתחות שלו.

לספק מבנה ולשלב משמעות הם שני דברים שונים.

30 השנים של CYC

הניסיון השאפתני ביותר היה CYC.

התחיל ב-1984. ניסה לייצג ידע כללי באמצעות LISP. מיליוני כללים הוזנו ידנית.

מה ש-30 שנה הוכיחו לא היה היתכנות אלא מגבלות.

אונטולוגיות היו צריכות להיות מתוכננות ידנית לכל תחום. יכולת פעולה הדדית בין תחומים לא עבדה. היא לא יכלה לעמוד בקצב הגמישות של שפה טבעית. ככל שהגודל גדל, שמירה על עקביות הפכה לכמעט בלתי אפשרית.

שייצוג ידע “ניתן לביצוע” ב-LISP הוא נכון. שזה “עובד היטב” — זה מה ש-30 שנות תוצאות מפריכות.

אם לא מתכוונים לעשות eval, אין סיבה להשתמש ב-LISP

הבעיה הבסיסית ביותר.

הכוח של LISP הוא eval. מכיוון שקוד הוא נתונים, ניתן להריץ נתונים. מטא-תכנות, מאקרו, יצירת קוד בזמן ריצה. זה מה שהופך את LISP ל-LISP.

אבל מה קורה כשמבצעים eval על (is 삼성전자 company)?

זה הופך לקריאת פונקציה המעבירה את 삼성전자 ו-company כארגומנטים לפונקציה בשם is. לא תיאור — ביצוע.

כדי להשתמש בזה לייצוג ידע, אסור לעשות eval. אם לא עושים eval, לא משתמשים בסמנטיקה של LISP. רק שואלים את התחביר של S-expressions.

זה לא “לתאר את העולם ב-LISP”. זה “לאחסן נתונים באמצעות סימון הסוגריים של LISP”.

הסמנטיקה של LISP כשפת תכנות — סמנטיקה של ביצוע — עדיין מתוכננת לתיאור פרוצדורות. שאילת תחביר אינה משנה את הסמנטיקה.

מה נדרש משפה לתיאור העולם

שפות תכנות מתארות פרוצדורות. פורמטי נתונים מספקים מבנה אך ללא משמעות. אפילו LISP רק שואלת תחביר ללא סמנטיקה של תיאור.

מה נדרש משפה לתיאור העולם?

זהות ישויות. “סמסונג אלקטרוניקס” חייבת לקבל מזהה ייחודי. המכונה חייבת לדעת שזה אותו דבר כמו “삼성전자”. לא השוואת מחרוזות, אלא שוויון זהות.

ביטוי יחסים. ב"סמסונג אלקטרוניקס היא חברה קוריאנית", צריך להיות אפשרי לבטא את היחס “חברה קוריאנית”. לא השמה למשתנה, אלא תיאור של יחסים.

תיאורים מתארים את עצמם. על מה התיאור, מי אמר אותו, מאיזה מועד, ועד כמה הוא ודאי — הכול חייב להיכלל בתיאור עצמו. בתוך הקוד, לא מחוצה לו.

עצמאות תחומית. נתונים פיננסיים, עובדות היסטוריות, הערכות סובייקטיביות, יחסים מופשטים — הכול חייב להיות ניתן לביטוי באותו פורמט. לא סכמה נפרדת לכל תחום, אלא מבנה אוניברסלי אחד.

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

שפה טבעית יכולה לעשות את כל הארבע. באופן עמום. מה שנדרש הוא שילוב של טווח הביטוי של שפה טבעית עם הדיוק של שפות תכנות.

סיכום

שפות תכנות הן חד-משמעיות, ניתנות לאימות ושלמות-טיורינג. אבל הן אינן מסוגלות לתאר את העולם.

שפות תכנות מתארות פרוצדורות. “כשהקלט הזה מגיע, עשה את זה.” הכול פעלים, הכול פעולות. “סמסונג אלקטרוניקס היא חברה קוריאנית” אינה פעולה. לשפות תכנות אין מקום לזה.

קוד לא מכיר את זהותו. לאיזה תחום הוא שייך, איזו מטרה הוא משרת — שום דבר מזה אינו רשום בתוך הקוד.

פורמטי נתונים כמו JSON ו-YAML מספקים מבנה אך ללא משמעות. LISP יכולה לשאול תחביר, אבל חסרה לה סמנטיקה של תיאור. CYC הקדיש 30 שנה לניסיון ייצוג ידע מבוסס LISP, ומה שהוכח היה המגבלה.

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