რატომ არის Go Design ცუდი ჭკვიანი პროგრამისტებისთვის

ბოლო თვეების განმავლობაში მე ვიყენებდი Go-ს განხორციელებისთვის. Proof of კონცეფცია (დაახლ.: კოდი იდეის ფუნქციონალურობის შესამოწმებლად) თავისუფალ დროს, ნაწილობრივ თავად პროგრამირების ენის შესასწავლად. თავად პროგრამები ძალიან მარტივია და არ არის ამ სტატიის მიზანი, მაგრამ თავად Go-ს გამოყენების გამოცდილება იმსახურებს რამდენიმე სიტყვას ამის შესახებ. მიდი გპირდები იქნება (დაახლ.: სტატია დაწერილი 2015 წელს) პოპულარული ენა სერიოზული მასშტაბირებადი კოდისთვის. ენა შეიქმნა Google-ის მიერ, სადაც ის აქტიურად გამოიყენება. დედააზრი, გულწრფელად ვფიქრობ, რომ Go ენის დიზაინი ცუდია ჭკვიანი პროგრამისტებისთვის.

შექმნილია სუსტი პროგრამისტებისთვის?

Go ძალიან ადვილი სასწავლია, იმდენად მარტივი, რომ შესავალი ერთ საღამოს დამჭირდა, რის შემდეგაც უკვე შემეძლო პროდუქტიული კოდირება. წიგნს, რომელსაც ვისწავლიდი Go, ჰქვია პროგრამირების შესავალი in Go (თარგმანი), ის ხელმისაწვდომია ონლაინ რეჟიმში. წიგნი, ისევე როგორც თავად Go წყაროს კოდი, ადვილად იკითხება, აქვს კარგი კოდის მაგალითები და შეიცავს დაახლოებით 150 გვერდს, რომელთა წაკითხვა შესაძლებელია ერთი ნაბიჯით. ეს სიმარტივე თავიდანვე განაახლებს, განსაკუთრებით პროგრამირების სამყაროში, რომელიც სავსეა ზედმეტად რთული ტექნოლოგიით. მაგრამ საბოლოოდ, ადრე თუ გვიან ჩნდება აზრი: "მართლა ასეა?"

Google ამტკიცებს, რომ Go-ს სიმარტივე არის მისი გაყიდვის წერტილი და ენა შექმნილია დიდი გუნდების მაქსიმალური პროდუქტიულობისთვის, მაგრამ მე მეეჭვება. არის ფუნქციები, რომლებიც ან აკლია ან ზედმეტად დეტალურადაა აღწერილი. და ეს ყველაფერი დეველოპერებისადმი ნდობის ნაკლებობის გამო, იმ ვარაუდით, რომ მათ არ შეუძლიათ არაფრის გაკეთება სწორად. სიმარტივის ეს სურვილი ენის დიზაინერების შეგნებული გადაწყვეტილება იყო და იმისათვის, რომ სრულად გავიგოთ, რატომ იყო ეს საჭირო, უნდა გვესმოდეს დეველოპერების მოტივაცია და რის მიღწევას ცდილობდნენ Go-ში.

რატომ გაკეთდა ასე მარტივი? აქ არის რამდენიმე ციტატა რობ პაიკი (დაახლ.: Go ენის ერთ-ერთი თანაშემქმნელი):

მთავარი აქ არის ის, რომ ჩვენი პროგრამისტები (დაახლ.: გუგლის თანამშრომლები) არ არიან მკვლევარები. ისინი, როგორც წესი, საკმაოდ ახალგაზრდები არიან, ჩვენთან სწავლის შემდეგ მოდიან, ალბათ Java-ს სწავლობდნენ, ან C/C++-ს, ან პითონს. მათ არ ესმით შესანიშნავი ენა, მაგრამ ამავე დროს ჩვენ გვინდა, რომ მათ შექმნან კარგი პროგრამული უზრუნველყოფა. ამიტომ მათი ენა მათთვის ადვილი გასაგები და შესასწავლი უნდა იყოს.
 
ის უნდა იყოს ნაცნობი, უხეშად რომ ვთქვათ 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 იყენებს ბევრად უფრო რთულ ცნებებს (დაახლ.: ალტერნატიული ფუნქციის გამოძახება и თარგები) ვიდრე 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))
}

და ეს მაგალითი ხელმოწერილი ტიპებისთვისაც კი არ მუშაობს. ეს მიდგომა სრულიად არღვევს საკუთარი თავის არ განმეორების პრინციპს (მშრალი), ერთ-ერთი ყველაზე ცნობილი და აშკარა პრინციპია, რომლის იგნორირებაც მრავალი შეცდომის წყაროა. რატომ აკეთებს ამას 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 ინსტრუმენტების გამოყენებით, მაგრამ ვერ მიუთითებთ ვერსიას. და ისევ სიმარტივე სარგებლობის ხარჯზე. მე ვერ გავიგე ასეთი გადაწყვეტილების ლოგიკა.

ამ პრობლემის გადაჭრის შესახებ კითხვების დასმის შემდეგ, Go-ს განვითარების ჯგუფი შეიქმნა ფორუმის თემა, რომელშიც ასახული იყო, თუ როგორ აპირებდნენ ამ საკითხის გადაჭრას. მათი რეკომენდაცია იყო უბრალოდ დააკოპირეთ მთელი საცავი თქვენს პროექტში ერთ დღეს და დატოვეთ ის „როგორც არის“. რა ჯანდაბას ფიქრობენ? ჩვენ გვაქვს საოცარი ვერსიების კონტროლის სისტემები დიდი ტეგებით და ვერსიების მხარდაჭერით, რომლებსაც Go შემქმნელები უგულებელყოფენ და უბრალოდ კოპირებენ წყაროს კოდს.

კულტურული ბარგი Xi-დან

ჩემი აზრით, Go შეიქმნა იმ ადამიანების მიერ, რომლებიც იყენებდნენ C-ს მთელი ცხოვრება და მათ, ვისაც არ სურდა რაიმე ახლის მოსინჯვა. ენა შეიძლება აღწერილი იყოს როგორც C დამატებითი ბორბლებით (წარმოშობის.: სავარჯიშო ბორბლები). მასში ახალი იდეები არ არის, გარდა პარალელიზმის მხარდაჭერისა (რაც, სხვათა შორის, მშვენიერია) და ეს სირცხვილია. შესანიშნავი პარალელიზმი გაქვთ ძლივს გამოსაყენებელ, კოჭლ ენაზე.

კიდევ ერთი საშინელი პრობლემა ის არის, რომ Go არის პროცედურული ენა (როგორც C-ის ჩუმი საშინელება). თქვენ საბოლოოდ წერთ კოდს პროცედურული სტილით, რომელიც იგრძნობა არქაულად და მოძველებულად. მე ვიცი, რომ ობიექტზე ორიენტირებული პროგრამირება არ არის ვერცხლის ტყვია, მაგრამ კარგი იქნებოდა დეტალების ტიპებად აბსტრაქცია და ინკაფსულაციის უზრუნველყოფა.

სიმარტივე საკუთარი სარგებლისთვის

Go შექმნილია იმისათვის, რომ იყოს მარტივი და ის ამ მიზანს აღწევს. ის დაიწერა სუსტი პროგრამისტებისთვის, შაბლონად ძველი ენის გამოყენებით. მას გააჩნია მარტივი ინსტრუმენტები მარტივი საქმეების გასაკეთებლად. ადვილი წასაკითხი და მარტივი გამოსაყენებელია.

ეს ძალიან ვრცელი, შთამბეჭდავი და ცუდია ჭკვიანი პროგრამისტებისთვის.

მადლობა მერსინვალდი რედაქტირებისთვის

წყარო: www.habr.com