स्मार्ट प्रोग्रामर्स के लिए गो डिज़ाइन खराब क्यों है?

पिछले महीनों से मैं कार्यान्वयन के लिए गो का उपयोग कर रहा हूं। अवधारणा के सुबूत (लगभग।: किसी विचार की कार्यक्षमता का परीक्षण करने के लिए कोड) अपने खाली समय में, आंशिक रूप से प्रोग्रामिंग भाषा का अध्ययन करने के लिए। प्रोग्राम स्वयं बहुत सरल हैं और इस लेख का उद्देश्य नहीं हैं, लेकिन गो का उपयोग करने का अनुभव स्वयं इसके बारे में कुछ शब्दों का हकदार है। गो होने का वादा करता है (लगभग।: 2015 में लिखा गया लेख) गंभीर स्केलेबल कोड के लिए एक लोकप्रिय भाषा। यह भाषा Google द्वारा बनाई गई थी, जहाँ इसका सक्रिय रूप से उपयोग किया जाता है। निचली पंक्ति, मैं ईमानदारी से सोचता हूं कि गो भाषा का डिज़ाइन स्मार्ट प्रोग्रामर के लिए खराब है।

कमजोर प्रोग्रामर के लिए डिज़ाइन किया गया?

गो सीखना बहुत आसान है, इतना आसान कि परिचय देने में मुझे एक शाम लग गई, जिसके बाद मैं पहले से ही उत्पादक रूप से कोड कर सकता था। गो सीखने के लिए मैंने जिस पुस्तक का उपयोग किया उसे कहा जाता है गो में प्रोग्रामिंग का एक परिचय (अनुवाद), यह ऑनलाइन उपलब्ध है। पुस्तक, गो स्रोत कोड की तरह, पढ़ने में आसान है, इसमें अच्छे कोड उदाहरण हैं, और इसमें लगभग 150 पृष्ठ हैं जिन्हें एक बार में पढ़ा जा सकता है। यह सरलता पहली बार में ताज़ा है, खासकर अत्यधिक जटिल तकनीक से भरी प्रोग्रामिंग दुनिया में। लेकिन अंत में, देर-सबेर विचार उठता है: "क्या सचमुच ऐसा है?"

Google का दावा है कि गो की सरलता उसका विक्रय बिंदु है और भाषा बड़ी टीमों में अधिकतम उत्पादकता के लिए डिज़ाइन की गई है, लेकिन मुझे इसमें संदेह है। ऐसी विशेषताएं हैं जो या तो गायब हैं या अत्यधिक विस्तृत हैं। और यह सब डेवलपर्स में विश्वास की कमी के कारण है, इस धारणा के साथ कि वे कुछ भी सही करने में सक्षम नहीं हैं। सरलता की यह इच्छा भाषा के डिजाइनरों द्वारा एक सचेत निर्णय था, और पूरी तरह से यह समझने के लिए कि इसकी आवश्यकता क्यों थी, हमें डेवलपर्स की प्रेरणा को समझना चाहिए और वे गो में क्या हासिल करने की कोशिश कर रहे थे।

तो इसे इतना सरल क्यों बनाया गया? यहां कुछ उद्धरण दिए गए हैं रोब पाइक (लगभग।: गो भाषा के सह-निर्माताओं में से एक):

यहां मुख्य बात यह है कि हमारे प्रोग्रामर (लगभग।: Googlers के) शोधकर्ता नहीं हैं। वे, एक नियम के रूप में, काफी युवा हैं, अध्ययन करने के बाद हमारे पास आते हैं, शायद उन्होंने जावा, या सी/सी++, या पायथन का अध्ययन किया है। वे कोई बढ़िया भाषा नहीं समझ सकते, लेकिन साथ ही हम चाहते हैं कि वे अच्छा सॉफ़्टवेयर बनाएं। इसलिए उनकी भाषा उनके लिए समझने और सीखने में आसान होनी चाहिए।
 
उसे परिचित होना चाहिए, मोटे तौर पर सी के समान बोलना चाहिए। Google में काम करने वाले प्रोग्रामर अपना करियर जल्दी शुरू करते हैं और ज्यादातर प्रक्रियात्मक भाषाओं, विशेष रूप से सी परिवार से परिचित होते हैं। एक नई प्रोग्रामिंग भाषा में त्वरित उत्पादकता की आवश्यकता का मतलब है कि भाषा बहुत अधिक कट्टरपंथी नहीं होनी चाहिए।

क्या? तो रॉब पाइक मूल रूप से कह रहा है कि Google के डेवलपर उतने अच्छे नहीं हैं, इसीलिए उन्होंने बेवकूफों के लिए एक भाषा बनाई है (लगभग।: गूंगा हो गया) ताकि वे कुछ करने में सक्षम हों। अपने ही सहकर्मियों को कैसी अहंकार भरी नजर से देखना? मेरा हमेशा से मानना ​​रहा है कि Google के डेवलपर्स दुनिया के सबसे प्रतिभाशाली और सर्वश्रेष्ठ लोगों में से चुने गए हैं। निश्चित रूप से वे कुछ अधिक कठिन कार्य संभाल सकते हैं?

अत्यधिक सादगी की कलाकृतियाँ

किसी भी डिज़ाइन में सरल होना एक योग्य लक्ष्य है, और किसी चीज़ को सरल बनाने का प्रयास करना कठिन है। हालाँकि, जटिल समस्याओं को हल करने (या यहाँ तक कि व्यक्त करने) का प्रयास करते समय, कभी-कभी एक जटिल उपकरण की आवश्यकता होती है। जटिलता और पेचीदगी किसी प्रोग्रामिंग भाषा की सबसे अच्छी विशेषताएं नहीं हैं, लेकिन एक बीच का रास्ता है जिसमें भाषा सुरुचिपूर्ण अमूर्तताएं बना सकती है जो समझने और उपयोग करने में आसान हैं।

बहुत अभिव्यंजक नहीं

सादगी के प्रति अपनी प्रतिबद्धता के कारण, गो में ऐसी संरचनाओं का अभाव है जिन्हें अन्य भाषाओं में स्वाभाविक माना जाता है। यह पहली बार में एक अच्छा विचार लग सकता है, लेकिन व्यवहार में इसका परिणाम वर्बोज़ कोड में होता है। इसका कारण स्पष्ट होना चाहिए - डेवलपर्स के लिए अन्य लोगों के कोड को पढ़ना आसान होना चाहिए, लेकिन वास्तव में ये सरलीकरण केवल पठनीयता को नुकसान पहुंचाते हैं। गो में कोई संक्षिप्ताक्षर नहीं हैं: या तो बहुत या कुछ भी नहीं।

उदाहरण के लिए, एक कंसोल उपयोगिता जो कमांड लाइन तर्कों से 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)
}

हालाँकि यह कोड यथासंभव सामान्य होने का भी प्रयास करता है, लेकिन गो की मजबूर शब्दाडंबरता रास्ते में आ जाती है, और परिणामस्वरूप, एक साधारण समस्या को हल करने से बड़ी मात्रा में कोड प्राप्त होता है।

उदाहरण के लिए, यहाँ उसी समस्या का समाधान है 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);
    }
}

और अब कौन अधिक पठनीय है? मैं अपना वोट डी को दूंगा। उसका कोड अधिक पठनीय है क्योंकि वह कार्यों का अधिक स्पष्ट रूप से वर्णन करता है। डी बहुत अधिक जटिल अवधारणाओं का उपयोग करता है (लगभग।: वैकल्पिक फ़ंक्शन कॉल и टेम्पलेट्स) गो उदाहरण की तुलना में, लेकिन उन्हें समझने में वास्तव में कुछ भी जटिल नहीं है।

नक़ल का नर्क

गो में सुधार के लिए एक लोकप्रिय सुझाव व्यापकता है। इससे कम से कम सभी डेटा प्रकारों का समर्थन करने के लिए कोड की अनावश्यक प्रतिलिपि बनाने से बचने में मदद मिलेगी। उदाहरण के लिए, पूर्णांकों की सूची को संक्षेप में प्रस्तुत करने के लिए एक फ़ंक्शन को प्रत्येक पूर्णांक प्रकार के लिए इसके मूल फ़ंक्शन को कॉपी-पेस्ट करने के अलावा किसी अन्य तरीके से कार्यान्वित नहीं किया जा सकता है; कोई अन्य तरीका नहीं है:

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))
}

और यह उदाहरण हस्ताक्षरित प्रकारों के लिए भी काम नहीं करता है। यह दृष्टिकोण पूरी तरह से खुद को न दोहराने के सिद्धांत का उल्लंघन करता है (सूखी), सबसे प्रसिद्ध और स्पष्ट सिद्धांतों में से एक, जिसकी अनदेखी कई त्रुटियों का स्रोत है। गो ऐसा क्यों करता है? यह भाषा का एक भयानक पहलू है.

डी पर वही उदाहरण:

import std.stdio;
import std.algorithm;

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

सरल, सुरुचिपूर्ण और सीधे मुद्दे पर। यहाँ प्रयुक्त फ़ंक्शन है reduce टेम्पलेट प्रकार और विधेय के लिए। हां, यह फिर से गो संस्करण की तुलना में अधिक जटिल है, लेकिन स्मार्ट प्रोग्रामर के लिए इसे समझना उतना मुश्किल नहीं है। कौन सा उदाहरण बनाए रखना आसान है और पढ़ना आसान है?

सरल प्रकार का सिस्टम बायपास

मैं कल्पना करता हूं कि इसे पढ़कर गो प्रोग्रामर के मुंह से झाग निकल रहा होगा और चिल्ला रहे होंगे, "आप यह गलत कर रहे हैं!" खैर, सामान्य फ़ंक्शन और प्रकार बनाने का एक और तरीका है, लेकिन यह प्रकार प्रणाली को पूरी तरह से तोड़ देता है!

समस्या से निपटने के लिए मूर्खतापूर्ण भाषा समाधान के इस उदाहरण पर एक नज़र डालें:

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{} - एक तमाशा, और भाषा में इसकी आवश्यकता केवल टाइपिंग को बायपास करने के लिए होती है। यह एक खाली इंटरफ़ेस है और सभी प्रकार इसे लागू करते हैं, जिससे सभी को पूर्ण स्वतंत्रता मिलती है। प्रोग्रामिंग की यह शैली बेहद बदसूरत है, और इतना ही नहीं। इस तरह की कलाबाजियों के लिए रनटाइम प्रतिबिंब के उपयोग की आवश्यकता होती है। यहां तक ​​कि रॉब पाइक को भी ऐसे व्यक्ति पसंद नहीं हैं जो इसका दुरुपयोग करते हैं, जैसा कि उन्होंने अपनी एक रिपोर्ट में उल्लेख किया है।

यह एक शक्तिशाली उपकरण है जिसका उपयोग सावधानी से किया जाना चाहिए। जब तक अत्यंत आवश्यक न हो, इससे बचना चाहिए।

मैं इस बकवास के बजाय डी टेम्प्लेट लूंगा। ऐसा कोई कैसे कह सकता है interface{} अधिक पठनीय या यहां तक ​​कि सुरक्षित टाइप?

निर्भरता प्रबंधन के संकट

गो में लोकप्रिय होस्टिंग प्रदाताओं के शीर्ष पर एक अंतर्निहित निर्भरता प्रणाली है कुलपतियों. गो के साथ आने वाले उपकरण इन सेवाओं के बारे में जानते हैं और एक झटके में उनसे कोड डाउनलोड, निर्माण और इंस्टॉल कर सकते हैं। हालाँकि यह बहुत अच्छा है, संस्करणीकरण में एक बड़ी खामी है! हां, यह सच है कि आप गो टूल्स का उपयोग करके जीथब या बिटबकेट जैसी सेवाओं से स्रोत कोड प्राप्त कर सकते हैं, लेकिन आप संस्करण निर्दिष्ट नहीं कर सकते। और फिर उपयोगिता की कीमत पर सरलता। मैं ऐसे फैसले का तर्क समझ नहीं पा रहा हूं.'

इस समस्या के समाधान के बारे में प्रश्न पूछने के बाद, गो विकास टीम ने बनाया मंच सूत्र, जिसमें बताया गया कि वे इस मुद्दे से कैसे निपटेंगे। उनकी सिफ़ारिश थी कि एक दिन पूरी रिपॉजिटरी को अपने प्रोजेक्ट में कॉपी कर लें और इसे "जैसा है" छोड़ दें। आखिर वे क्या सोच रहे हैं? हमारे पास बेहतरीन टैगिंग और संस्करण समर्थन के साथ अद्भुत संस्करण नियंत्रण प्रणालियाँ हैं जिन्हें गो निर्माता अनदेखा करते हैं और केवल स्रोत कोड की प्रतिलिपि बनाते हैं।

शी से सांस्कृतिक सामान

मेरी राय में, गो का विकास उन लोगों द्वारा किया गया था जिन्होंने अपने पूरे जीवन में सी का उपयोग किया था और उन लोगों द्वारा जो कुछ नया आज़माना नहीं चाहते थे। भाषा को अतिरिक्त पहियों के साथ C के रूप में वर्णित किया जा सकता है(मूल.: प्ररीक्षण के पहियों). इसमें कोई नया विचार नहीं है, सिवाय समानता के समर्थन के (जो, वैसे, अद्भुत है) और यह शर्म की बात है। बमुश्किल प्रयोग योग्य, लचर भाषा में आपके पास उत्कृष्ट समानता है।

एक और गंभीर समस्या यह है कि गो एक प्रक्रियात्मक भाषा है (सी की मूक डरावनी भाषा की तरह)। आप एक ऐसी प्रक्रियात्मक शैली में कोड लिखते हैं जो पुरातन और पुरानी लगती है। मैं जानता हूं कि ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग कोई सिल्वर बुलेट नहीं है, लेकिन विवरणों को प्रकारों में विभाजित करने और एनकैप्सुलेशन प्रदान करने में सक्षम होना बहुत अच्छा होगा।

अपने फायदे के लिए सादगी

गो को सरल बनाने के लिए डिज़ाइन किया गया था और यह उस लक्ष्य पर सफल होता है। यह कमजोर प्रोग्रामर्स के लिए एक पुरानी भाषा को टेम्पलेट के रूप में उपयोग करके लिखा गया था। यह सरल कार्य करने के लिए सरल उपकरणों के साथ आता है। इसे पढ़ना और उपयोग करना आसान है।

यह बेहद वाचाल, अप्रभावी और स्मार्ट प्रोग्रामर के लिए ख़राब है।

धन्यवाद मेर्सिनवाल्ड संपादन के लिए

स्रोत: www.habr.com