Go デザインが賢いプログラマーにとって悪い理由

ここ数か月間、私は実装に Go を使用してきました。 コンセプトの証明 (約。: アイデアの機能をテストするためのコード) を自由時間に作成し、一部はプログラミング言語自体を勉強することも目的でした。 プログラム自体は非常に単純であり、この記事の目的ではありませんが、Go 自体の使用体験については少し説明する価値があります。 ゴーは (約。: 2015 年に書かれた記事) 本格的なスケーラブルなコードに人気の言語。 この言語は Google によって作成され、積極的に使用されています。 結論から言えば、私は正直に言って、Go 言語の設計は賢明なプログラマーにとって悪いものだと考えています。

弱いプログラマー向けに設計されていますか?

Go は非常に簡単に学ぶことができるので、導入に一晩かかったほどで、その後はすでに生産的にコーディングできるようになりました。 私が Go を学ぶために使用した本は次のとおりです Go でのプログラミングの概要 (翻訳）、オンラインで入手できます。 この本は、Go のソース コード自体と同様に、読みやすく、優れたコード例があり、約 150 ページで一気に読むことができます。 このシンプルさは、特に複雑すぎるテクノロジーに満ちたプログラミングの世界では、最初は新鮮に感じられます。 しかし、最終的には、遅かれ早かれ、「本当にそうなのか？」という考えが生まれます。

Googleは、Goのシンプルさがセールスポイントであり、この言語は大規模なチームで最大限の生産性を発揮できるように設計されていると主張しているが、私はそれを疑っている。 欠落している機能、または過度に詳細な機能があります。 それはすべて、開発者に対する信頼の欠如が原因であり、開発者は何も正しく行うことができないという思い込みが原因です。 この単純さへの欲求は、言語の設計者による意識的な決定であり、なぜそれが必要なのかを完全に理解するには、開発者の動機と、開発者が Go で何を達成しようとしていたのかを理解する必要があります。

では、なぜこれほどシンプルになったのでしょうか? ここにいくつかの引用があります ロブ・パイク (約。: Go 言語の共同作成者の XNUMX 人):

ここで重要な点は、プログラマー (約。: Google 社員）は研究者ではありません。 彼らは通常、非常に若く、おそらく Java、C/C++、または Python を勉強した後、私たちのところに来ます。 彼らは優れた言語を理解することはできませんが、同時に私たちは彼らに良いソフトウェアを作ってもらいたいと考えています。 だからこそ、彼らの言語は彼らにとって理解しやすく、学びやすいものでなければなりません。
 
彼はよく知られているはずで、大まかに言えば C に似ています。 Google で働くプログラマーはキャリアを早くからスタートしており、手続き型言語、特に C ファミリに精通していることがほとんどです。 新しいプログラミング言語で迅速な生産性が求められるということは、言語が過激になりすぎてはいけないことを意味します。

何？ つまり、ロブ・パイクは基本的に、Google の開発者はそれほど優秀ではない、だから彼らは愚か者向けの言語を作成したと言っているのです (約。: 唖然とする) それで彼らは何かをできるようになります。 自分の同僚に対してどんな傲慢な見方をするのでしょうか？ 私はいつも、Google の開発者は地球上で最も聡明で優秀な人材から厳選されていると信じてきました。 彼らはもっと難しいことにも対処できるだろうか？

過度のシンプルさの成果物

シンプルであることは、どんなデザインにおいても価値のある目標ですが、何かをシンプルにしようとするのは難しいことです。 ただし、複雑な問題を解決しようとする (または表現しようとする) 場合、複雑なツールが必要になる場合があります。 複雑さと緻密さはプログラミング言語の最良の特徴ではありませんが、理解しやすく使いやすいエレガントな抽象化を言語が作成できる中間点があります。

あまり表現力が無い

Go はシンプルさを重視するため、他の言語では自然と認識される構造が欠けています。 これは最初は良いアイデアのように思えるかもしれませんが、実際には冗長なコードになります。 この理由は明白です。開発者が他の人のコードを読みやすくする必要がありますが、実際には、これらの単純化は読みやすさを損なうだけです。 Go には略語はありません。「たくさん」または「何もなし」のどちらかです。

たとえば、標準入力またはコマンド ライン引数からファイルを読み取るコンソール ユーティリティは次のようになります。

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)、最も有名で明白な原則の XNUMX つですが、これが多くのエラーの原因であることを無視しています。 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{} - 茶番であり、この言語では入力を回避するためにのみ必要です。 これは空のインターフェイスであり、すべてのタイプがそれを実装しているため、誰でも完全に自由に使用できます。 このスタイルのプログラミングは非常に醜いですが、それだけではありません。 このようなアクロバティックな技には、ランタイム リフレクションを使用する必要があります。 ロブ・パイクでさえ、彼のレポートのXNUMXつで述べたように、これを悪用する個人は好きではありません。

これは強力なツールであるため、使用には注意が必要です。 厳密に必要な場合を除き、これは避けるべきです。

私なら、このナンセンスの代わりに D テンプレートを採用します。 どうしてそんなことが言えるんだろう interface{} 読みやすくなったのか、あるいはタイプセーフになったのか?

依存関係管理の問題点

Go には、人気のあるホスティング プロバイダー上に構築された依存関係システムが組み込まれています。 VCS。 Go に付属のツールはこれらのサービスを認識しており、そこからコードを一度にダウンロード、ビルド、インストールできます。 これは素晴らしいことですが、バージョン管理には大きな欠陥があります。 はい、確かに Go ツールを使用して github や bitbucket などのサービスからソース コードを取得できますが、バージョンを指定することはできません。 そしてまたもや使いやすさを犠牲にしたシンプルさ。 私にはそのような決定の論理が理解できません。

この問題の解決策について質問した後、Go 開発チームは フォーラムのスレッド、この問題をどのように回避するかを概説しました。 彼らの推奨事項は、ある日、リポジトリ全体をプロジェクトにコピーし、それを「そのまま」にしておくというものでした。 彼らは一体何を考えているのでしょうか？ 私たちは優れたタグ付けとバージョンサポートを備えた素晴らしいバージョン管理システムを持っていますが、Go 作成者はそれを無視してソースコードをコピーするだけです。

習近平からの文化的な荷物

私の意見では、Go は C をずっと使ってきた人たちと、新しいことを試したくない人たちによって開発されました。 この言語は、追加のホイールを備えた C として記述することができます(オリジナル。: 補助輪）。 並列処理のサポート (ちなみに、これは素晴らしいことです) を除いて、新しいアイデアはありませんが、これは残念です。 かろうじて使える、不自由な言語で優れた並列性を備えています。

もう XNUMX つの厄介な問題は、Go が手続き型言語 (C の静かな恐怖のようなもの) であることです。 結局、古風で時代遅れに感じる手続き型スタイルでコードを書くことになります。 オブジェクト指向プログラミングが特効薬ではないことは承知していますが、詳細を型に抽象化し、カプセル化を提供できれば素晴らしいと思います。

自分自身の利益のためのシンプルさ

Go はシンプルになるように設計されており、その目標は達成できています。 これは、古い言語をテンプレートとして使用して、弱いプログラマー向けに書かれました。 簡単な作業を行うためのシンプルなツールが付属しています。 読みやすく、使いやすいです。

これは非常に冗長で印象に残らず、賢明なプログラマーにとっては好ましくありません。

感謝 マーシンヴァルド 編集用

出所： habr.com