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

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

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

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

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

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

אז למה זה נעשה כל כך פשוט? הנה כמה ציטוטים של רוב פייק:

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

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

מילים נבונות, לא?

חפצים של פשטות

פשטות היא תנאי הכרחי ליופי. לב טולסטוי.

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

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

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

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

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

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

package main

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

func main() {

    flag.Parse()

    scanner := newScanner(flag.Args())

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

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

    fmt.Println(text)
}

func newScanner(flags []string) *bufio.Scanner {
    if len(flags) == 0 {
        return bufio.NewScanner(os.Stdin)
    }

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

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

    return bufio.NewScanner(file)
}

הפתרון לאותה בעיה ב-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);
    }
}

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

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

מתחילים מתלוננים כל הזמן על 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 main() {

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

    fmt.Println(int32Sum(list32))
    fmt.Println(int64Sum(list64))
}

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

package main

import "fmt"

func Eval32(list []int32, fn func(a, b int32)int32) int32 {
    var res int32
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int32Add(a, b int32) int32 {
    return a + b
}

func int32Sub(a, b int32) int32 {
    return a + b
}

func Eval64(list []int64, fn func(a, b int64)int64) int64 {
    var res int64
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int64Add(a, b int64) int64 {
    return a + b
}

func int64Sub(a, b int64) int64 {
    return a - b
}

func main() {

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

    fmt.Println(Eval32(list32, int32Add))
    fmt.Println(Eval64(list64, int64Add))
    fmt.Println(Eval64(list64, int64Sub))
}

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

רבים יגידו שתוכנית ב-D נראית קצרה משמעותית, והם יהיו צודקים.

import std.stdio;
import std.algorithm;

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

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

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

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

תכנות כללי בחלק מהמקרים נותן לנו יתרונות שאין להכחישה. זה מומחש בבירור על ידי חבילת המיון. אז, כדי למיין כל רשימה, אנחנו רק צריכים ליישם את ממשק sort.Interface.

import "sort"

type Names []string

func (ns Names) Len() int {
    return len(ns)
}

func (ns Names) Less(i, j int) bool {
    return ns[i] < ns[j]
}

func (ns Names) Swap(i, j int) {
    ns[i], ns[j] = ns[j], ns[i]
}

func main() {
    names := Names{"London", "Berlin", "Rim"}
    sort.Sort(names)
}

אם תיקח פרויקט קוד פתוח כלשהו ותפעיל את הפקודה grep "interface{}" -R, תראה באיזו תדירות נעשה שימוש בממשקים מבלבלים. חברים קרובים יגידו מיד שכל זה נובע מהיעדר גנריות. עם זאת, זה לא תמיד המצב. ניקח את DELPHI כדוגמה. למרות הנוכחות של אותן גנריות, הוא מכיל סוג VARIANT מיוחד לפעולות עם סוגי נתונים שרירותיים. שפת Go עושה את אותו הדבר.

מתותח ועד דרורים

והחולצה חייבת להתאים לגודל הטירוף. סטניסלב לק.

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

רוב פייק מזהיר אותנו:

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

ויקיפדיה מספרת לנו את הדברים הבאים:

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

עם זאת, כפי שאתה יודע, אתה צריך לשלם על הכל. במקרה הזה זה:

• קושי בכתיבת תוכניות
• מהירות ביצוע התוכנית

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

מטען תרבותי משי? לא, ממספר שפות!

לצד ההון נותרים גם חובות ליורשים.

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

תחביר

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

סֵמַנטִיקָה

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

פעולת היישום לפי האצלה הושאלה משפת DELPHI.

קומפילציה

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

מבנים ברמה גבוהה

השפה מכילה מבנים רבים ושונים ברמה גבוהה שאינם קשורים בשום אופן לשפות ברמה נמוכה כמו C.

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

ניהול זיכרון

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

במקביל ובמקביל

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

הטבות נוספות

אם זה רווחי, כולם יהפכו להיות חסרי אנוכיות.

השפה גם מספקת לנו מספר יתרונות ללא ספק:

• קובץ הפעלה בודד לאחר בניית הפרויקט מפשט מאוד את פריסת האפליקציות.
• הקלדה סטטית והסקת סוג יכולים להפחית באופן משמעותי את מספר השגיאות בקוד שלך, אפילו ללא כתיבת מבחנים. אני מכיר כמה מתכנתים שעושים בלי לכתוב מבחנים בכלל ואיכות הקוד שלהם לא נפגעת משמעותית.
• קומפילציה צולבת פשוטה מאוד וניידות מעולה של הספרייה הסטנדרטית, מה שמקל מאוד על פיתוח אפליקציות חוצות פלטפורמות.
• ביטויים רגולריים של RE2 הם בטוחים לשרשור ויש להם זמני ביצוע צפויים.
• ספרייה סטנדרטית רבת עוצמה המאפשרת לרוב הפרויקטים להסתדר ללא מסגרות של צד שלישי.
• השפה חזקה מספיק כדי להתמקד בבעיה ולא איך לפתור אותה, אך ברמה נמוכה מספיק כדי שניתן יהיה לפתור את הבעיה ביעילות.
• מערכת ה-Go eco כבר מכילה כלים שפותחו מחוץ לקופסה לכל אירוע: בדיקות, תיעוד, ניהול חבילות, linters עוצמתיים, יצירת קוד, גלאי תנאי מרוץ וכו'.
• Go גרסה 1.11 הציגה ניהול תלות סמנטי מובנה, שנבנה על גבי אירוח VCS פופולרי. כל הכלים המרכיבים את מערכת האקולוגית של Go משתמשים בשירותים האלה כדי להוריד, לבנות ולהתקין מהם קוד במכה אחת. וזה נהדר. עם הגעת גרסה 1.11, גם הבעיה בגירסאות החבילה נפתרה לחלוטין.
• מכיוון שרעיון הליבה של השפה הוא להפחית את הקסם, השפה מעודדת מפתחים לטפל בשגיאות באופן מפורש. וזה נכון, כי אחרת, הוא פשוט ישכח לגמרי מהטיפול בשגיאות. דבר נוסף הוא שרוב המפתחים מתעלמים בכוונה מטיפול בשגיאות, ומעדיפים במקום לעבד אותן פשוט להעביר את השגיאה כלפי מעלה.
• השפה אינה מיישמת את מתודולוגיית OOP הקלאסית, שכן בצורתה הטהורה אין וירטואליות ב-Go. עם זאת, זו אינה בעיה בעת שימוש בממשקים. היעדר OOP מקטין משמעותית את מחסום הכניסה למתחילים.

פשטות לטובת הקהילה

קל לסבך, קשה לפשט.

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

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

מסקנה

גודל מוח גדול מעולם לא הפך אף פיל לזוכה פרס נובל.

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

מקור: www.habr.com