Защо Go Design е лош за интелигентните програмисти

През последните месеци използвах Go за внедрявания. Доказване на концепцията (прибл.: код за тестване на функционалността на идея) в свободното си време, отчасти за изучаване на самия език за програмиране. Самите програми са много прости и не са целта на тази статия, но самото изживяване от използването на Go заслужава няколко думи за него. Go обещава да бъде (прибл.: статия, написана през 2015 г.) популярен език за сериозен мащабируем код. Езикът е създаден от Google, където се използва активно. В крайна сметка, честно казано смятам, че дизайнът на езика Go е лош за интелигентните програмисти.

Предназначен за слаби програмисти?

Go е много лесен за научаване, толкова лесен, че въвеждането ми отне една вечер, след което вече можех да кодирам продуктивно. Книгата, която използвах, за да науча Го, се казва Въведение в програмирането в Go (превод), той е достъпен онлайн. Книгата, подобно на самия изходен код на Go, е лесна за четене, има добри примери за код и съдържа около 150 страници, които могат да се прочетат наведнъж. Тази простота е освежаваща в началото, особено в свят на програмиране, пълен с прекалено сложна технология. Но в крайна сметка рано или късно възниква мисълта: „Наистина ли е така?“

Google твърди, че простотата на Go е неговата търговска точка и езикът е проектиран за максимална производителност в големи екипи, но аз се съмнявам. Има функции, които или липсват, или са твърде подробни. И всичко това поради липса на доверие в разработчиците, с предположението, че те не могат да направят нищо правилно. Това желание за простота беше съзнателно решение на дизайнерите на езика и за да разберем напълно защо е необходимо, трябва да разберем мотивацията на разработчиците и какво се опитваха да постигнат в Go.

Така че защо беше направено толкова просто? Ето няколко цитата Роб Пайк (прибл.: един от създателите на езика Go):

Ключовият момент тук е, че нашите програмисти (прибл.: служители на Google) не са изследователи. Те, като правило, са доста млади, идват при нас след обучение, може би са учили Java, или C/C++, или Python. Те не могат да разберат страхотен език, но в същото време искаме да създават добър софтуер. Ето защо техният език трябва да бъде лесен за разбиране и учене.
 
Той трябва да е познат, грубо казано подобен на C. Програмистите, работещи в Google, започват кариерата си рано и са запознати предимно с процедурните езици, по-специално семейството C. Изискването за бърза производителност в нов език за програмиране означава, че езикът не трябва да бъде твърде радикален.

Какво? Така че Роб Пайк всъщност казва, че разработчиците в Google не са толкова добри, затова са създали език за идиоти (прибл.: глупав), за да могат да направят нещо. Какъв арогантен поглед към собствените си колеги? Винаги съм вярвал, че разработчиците на Google са ръчно подбрани от най-умните и най-добрите на Земята. Сигурно могат да се справят с нещо по-трудно?

Артефакти с прекомерна простота

Да бъдеш прост е достойна цел във всеки дизайн и да се опитваш да направиш нещо просто е трудно. Въпреки това, когато се опитвате да решите (или дори да изразите) сложни проблеми, понякога е необходим сложен инструмент. Сложността и сложността не са най-добрите характеристики на езика за програмиране, но има средно положение, в което езикът може да създаде елегантни абстракции, които са лесни за разбиране и използване.

Не много изразителен

Поради ангажимента си към простотата, на Go липсват конструкции, които се възприемат като естествени в други езици. Това може да изглежда като добра идея в началото, но на практика води до многословен код. Причината за това трябва да е очевидна - трябва да е лесно за разработчиците да четат кода на други хора, но всъщност тези опростявания само вредят на четливостта. В 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 използва много по-сложни концепции (прибл.: извикване на алтернативна функция и Templates), отколкото в примера с 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), един от най-известните и очевидни принципи, чието игнориране е източник на много грешки. Защо Go прави това? Това е ужасен аспект на езика.

Същият пример на 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 е заимствано от статията Идиоматични генерични думи в Go (прибл.: Не можах да намеря превода, ще се радвам, ако помогнете с това). Е, ако е идиоматичен, не бих искал да видя неидиоматичен пример. Използване interface{} - фарс, а на езика е необходим само за заобикаляне на писане. Това е празен интерфейс и всички видове го прилагат, позволявайки пълна свобода за всеки. Този стил на програмиране е ужасно грозен и това не е всичко. Акробатични подвизи като тези изискват използването на отражение по време на изпълнение. Дори Роб Пайк не харесва хора, които злоупотребяват с това, както той спомена в един от докладите си.

Това е мощен инструмент, който трябва да се използва с повишено внимание. Трябва да се избягва, освен ако не е строго необходимо.

Бих взел D шаблони вместо тези глупости. Как може някой да каже това interface{} по-четлив или дори безопасен за писане?

Неволите на управлението на зависимостите

Go има вградена система за зависимост, изградена върху популярни хостинг доставчици VCS. Инструментите, които идват с Go знаят за тези услуги и могат да изтеглят, създават и инсталират код от тях с един замах. Въпреки че това е страхотно, има основен недостатък с версиите! Да, вярно е, че можете да получите изходния код от услуги като github или bitbucket с помощта на Go tools, но не можете да посочите версията. И пак простотия за сметка на полезността. Не мога да разбера логиката на такова решение.

След като зададе въпроси относно решение на този проблем, екипът за разработка на Go създаде нишка във форума, който очертава как ще заобиколят този проблем. Тяхната препоръка беше просто да копирате цялото хранилище в проекта си един ден и да го оставите „както е“. Какво, по дяволите, си мислят? Имаме невероятни системи за контрол на версиите със страхотно маркиране и поддръжка на версии, които създателите на Go игнорират и просто копират изходния код.

Културен багаж от Xi

Според мен Go е разработен от хора, които са използвали C през целия си живот и от такива, които не искат да опитат нещо ново. Езикът може да бъде описан като C с допълнителни колела (ориг.: тренировъчни колела). В него няма нови идеи, с изключение на подкрепата за паралелизъм (което, между другото, е прекрасно) и това е жалко. Имате отличен паралелизъм на едва използваем, куц език.

Друг скърцащ проблем е, че Go е процедурен език (като тихия ужас на C). В крайна сметка пишете код в процедурен стил, който изглежда архаичен и остарял. Знам, че обектно-ориентираното програмиране не е сребърен куршум, но би било чудесно да можем да абстрахираме детайлите в типове и да осигурим капсулиране.

Простота за ваша собствена полза

Go е проектиран да бъде прост и успява в тази цел. Написан е за слаби програмисти, използвайки стар език като шаблон. Той идва в комплект с прости инструменти за извършване на прости неща. Той е лесен за четене и лесен за използване.

Това е изключително многословно, невпечатляващо и лошо за умните програмисти.

Благодаря Мерсинвалд за редакции

Източник: www.habr.com