למה Go Design זה רע עבור מתכנתים חכמים

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

מיועד למתכנתים חלשים?

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

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

אז למה זה נעשה כל כך פשוט? הנה כמה ציטוטים רוב פייק (משוער.: אחד היוצרים השותפים של שפת Go):

נקודת המפתח כאן היא שהמתכנתים שלנו (משוער.: אנשי גוגל) אינם חוקרים. הם, ככלל, די צעירים, מגיעים אלינו לאחר לימודים, אולי הם למדו Java, או C/C++, או Python. הם לא יכולים להבין שפה מצוינת, אבל יחד עם זאת אנחנו רוצים שהם ייצרו תוכנה טובה. לכן השפה שלהם צריכה להיות קלה עבורם להבנה וללמוד.
 
הוא צריך להיות מוכר, בערך בדומה ל-C. מתכנתים העובדים בגוגל מתחילים את הקריירה שלהם מוקדם ומכירים בעיקר שפות פרוצדורליות, במיוחד משפחת C. הדרישה לפרודוקטיביות מהירה בשפת תכנות חדשה פירושה שהשפה לא צריכה להיות רדיקלית מדי.

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

חפצים של פשטות מוגזמת

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

לא מאוד אקספרסיבי

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

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

package main

import (
    "bufio"
    "flag"
    "fmt"
    "log"
    "os"
)

func main() {

    flag.Parse()
    flags := flag.Args()

    var text string
    var scanner *bufio.Scanner
    var err error

    if len(flags) > 0 {

        file, err := os.Open(flags[0])

        if err != nil {
            log.Fatal(err)
        }

        scanner = bufio.NewScanner(file)

    } else {
        scanner = bufio.NewScanner(os.Stdin)
    }

    for scanner.Scan() {
        text += scanner.Text()
    }

    err = scanner.Err()
    if err != nil {
        log.Fatal(err)
    }

    fmt.Println(text)
}

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

הנה, למשל, פתרון לאותה בעיה ב D:

import std.stdio, std.array, std.conv;

void main(string[] args)
{
    try
    {
        auto source = args.length > 1 ? File(args[1], "r") : stdin;
        auto text   = source.byLine.join.to!(string);

        writeln(text);
    }
    catch (Exception ex)
    {
        writeln(ex.msg);
    }
}

ומי יותר קריא עכשיו? אני אתן את הקול שלי ל-D. הקוד שלו הרבה יותר קריא כי הוא מתאר את הפעולות בצורה ברורה יותר. D משתמש במושגים הרבה יותר מורכבים (משוער.: קריאת פונקציה חלופית и תבניות) מאשר בדוגמה של Go, אבל אין באמת שום דבר מסובך בהבנתם.

לעזאזל של העתקה

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

package main

import "fmt"

func int64Sum(list []int64) (uint64) {
    var result int64 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

func int32Sum(list []int32) (uint64) {
    var result int32 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

func int16Sum(list []int16) (uint64) {
    var result int16 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

func int8Sum(list []int8) (uint64) {
    var result int8 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

func main() {

    list8  := []int8 {1, 2, 3, 4, 5}
    list16 := []int16{1, 2, 3, 4, 5}
    list32 := []int32{1, 2, 3, 4, 5}
    list64 := []int64{1, 2, 3, 4, 5}

    fmt.Println(int8Sum(list8))
    fmt.Println(int16Sum(list16))
    fmt.Println(int32Sum(list32))
    fmt.Println(int64Sum(list64))
}

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

אותה דוגמה ב-D:

import std.stdio;
import std.algorithm;

void main(string[] args)
{
    [1, 2, 3, 4, 5].reduce!((a, b) => a + b).writeln;
}

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

מעקף מערכת מסוג פשוט

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

תסתכל על הדוגמה הזו של תיקון שפה טיפשי כדי לעקוף את הבעיה:

package main

import "fmt"
import "reflect"

func Reduce(in interface{}, memo interface{}, fn func(interface{}, interface{}) interface{}) interface{} {
    val := reflect.ValueOf(in)

    for i := 0; i < val.Len(); i++ {
        memo = fn(val.Index(i).Interface(), memo)
    }

    return memo
}

func main() {

    list := []int{1, 2, 3, 4, 5}

    result := Reduce(list, 0, func(val interface{}, memo interface{}) interface{} {
        return memo.(int) + val.(int)
    })

    fmt.Println(result)
}

יישום זה Reduce הושאל מהמאמר גנריות אידיומטיות בגו (משוער.: לא הצלחתי למצוא את התרגום, אשמח אם תעזרו בזה). ובכן, אם זה אידיומטי, אני שונא לראות דוגמה לא אידיומטית. נוֹהָג interface{} - פארסה, ובשפה היא נדרשת רק כדי לעקוף את ההקלדה. זהו ממשק ריק וכל הסוגים מיישמים אותו, ומאפשר חופש מוחלט לכולם. סגנון התכנות הזה נורא מכוער, וזה לא הכל. הישגים אקרובטיים כמו אלה דורשים שימוש בהשתקפות בזמן ריצה. אפילו רוב פייק לא אוהב אנשים שמתעללים בזה, כפי שהוא הזכיר באחד הדיווחים שלו.

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

הייתי לוקח תבניות D במקום השטויות האלה. איך מישהו יכול להגיד את זה interface{} קריא יותר או אפילו הקלד בטוח?

צרותיו של ניהול תלות

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

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

מטען תרבותי משי

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

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

פשטות לטובתך

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

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

תודה mersinvald עבור עריכות

מקור: www.habr.com