מדוע תמיד נצטרך שפות תכנות חדשות

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

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

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

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

מהי שפת תכנות?

ראה את הפונקציה הבאה:

fun square(a: Int) = a * a
// Usageprint(square(10) + square(20))

מה הפירוש squareשמוגדר?

מנקודת מבט טכנית, זה רק פשט והגוף יכול להחליף את כל השיחות:

// Kotlinprint(10 * 10 + 20 * 20)

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

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

אבולוציה של שפות תכנות

תעשיית התכנות מתפתחת, וכך גם שפות התכנות. חשוב על ה- for-loop. בתחילה, היה רק ​​לולאת מתי.

עד מהרה המתכנתים הבחינו בדפוס נפוץ:

// Cint i = 0;while(i < n) { i++; // ...} 

whileהביטוי שימש שוב ושוב כדי לחזר על משהו - בעיקר מספרים, כתובות, או iterators.

אז הצגנו לולאות:

// C++for (int i = 0; i < n; i++) { // ...}

עד מהרה התעשייה הבחינה כי ה- for-loop משמש בעיקר כדי לחזור על אלמנטים מתוך רשימה.

זו הסיבה ששפות הציגו גרסה חדשה של for-loop שנועדה לחזור על list:

// Kotlinfor(e in list) { // ...}

אז אנחנו צריכים תכונות חדשות

אבל שפות מתפתחות, מדוע לא לדבוק בהן?

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

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

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

שפת התכנות Go בנתה את הפופולריות שלה על פשטות. זה לא קשור למספר התכונות שיש לשפות מסוימות, אלא לקבוצת התכונות המושלמת.

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

יש לכך סיבות חזקות:

  • זה היה בגרסת בטא במשך 6 שנים וזה התפתח איטרטיבי לאורך כל אותו זמן
  • הוא תוכנן על ידי JetBrains ששולטים בהבנתם את שפות התכנות וכיצד אנשים משתמשים בהן במשך שנים

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

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

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

אז אם יש לנו שפות חדשות מעוצבות היטב, האם הן השפות האחרונות?

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

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

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

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

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

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

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

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

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

סְגִירָה

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

שניים פלוס שלושה שווים לחמש

למרות שזה משהו אחר לגמרי מאשר לבטא אותו באמצעות הסימון המתמטי:

2 + 3 = 5

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

אם זה לא היה חשוב, היינו מפעילים Assembler במקום Java, JavaScript, Python או Kotlin. אבל זה חשוב. זו הסיבה שאנחנו צריכים ביטוי טוב יותר ויותר, ואנחנו זקוקים לשפות תכנות חדשות.

על הסופר

מרקין מוסקאלה (@marcinmoskala) הוא מאמן ויועץ, המתמקד כיום בהענקת קוטלין בסדנאות אנדרואיד וסדנאות קוטלין מתקדמות (לפרטים נוספים, הגש כאן) הוא גם דובר, מחבר מאמרים וספר על פיתוח אנדרואיד בקוטלין.