स्मार्ट प्रोग्रामरसाठी गो डिझाइन वाईट का आहे

गेल्या काही महिन्यांपासून मी अंमलबजावणीसाठी गो वापरत आहे. संकल्पनेचा पुरावा (अंदाजे: एखाद्या कल्पनेच्या कार्यक्षमतेची चाचणी घेण्यासाठी कोड) त्याच्या मोकळ्या वेळेत, अंशतः प्रोग्रामिंग भाषेचा अभ्यास करण्यासाठी. प्रोग्राम स्वतः खूप सोपे आहेत आणि या लेखाचा उद्देश नाही, परंतु गो वापरण्याचा अनुभव त्याबद्दल काही शब्दांना पात्र आहे. जाण्याचे वचन देतो (अंदाजे: 2015 मध्ये लिहिलेला लेख) गंभीर स्केलेबल कोडसाठी लोकप्रिय भाषा. भाषा Google द्वारे तयार केली गेली आहे, जिथे ती सक्रियपणे वापरली जाते. तळ ओळ, मला प्रामाणिकपणे वाटते की गो भाषेची रचना स्मार्ट प्रोग्रामरसाठी वाईट आहे.

कमकुवत प्रोग्रामरसाठी डिझाइन केलेले?

गो शिकणे खूप सोपे आहे, इतके सोपे आहे की परिचय मला एका संध्याकाळी घेऊन गेला, त्यानंतर मी आधीच उत्पादकपणे कोड करू शकलो. मी गो शिकायचे ते पुस्तक म्हणतात गो मधील प्रोग्रामिंगचा परिचय (हस्तांतरण), ते ऑनलाइन उपलब्ध आहे. गो सोर्स कोड प्रमाणेच हे पुस्तक वाचण्यास सोपे आहे, चांगले कोड उदाहरणे आहेत आणि त्यात सुमारे 150 पृष्ठे आहेत जी एकाच वेळी वाचता येतात. ही साधेपणा सुरुवातीला ताजेतवाने आहे, विशेषत: अति-जटिल तंत्रज्ञानाने भरलेल्या प्रोग्रामिंग जगात. पण शेवटी, लवकरच किंवा नंतर विचार उद्भवतो: "हे खरोखर असे आहे का?"

गुगलचा दावा आहे की गो ची साधेपणा हा त्याचा विक्री बिंदू आहे आणि भाषा मोठ्या संघांमध्ये जास्तीत जास्त उत्पादनासाठी डिझाइन केली गेली आहे, परंतु मला शंका आहे. अशी वैशिष्ट्ये आहेत जी एकतर गहाळ आहेत किंवा जास्त तपशीलवार आहेत. आणि हे सर्व विकासकांवर विश्वास नसल्यामुळे, ते काही योग्य करू शकत नाहीत या गृहीतकाने. साधेपणाची ही इच्छा हा भाषेच्या डिझाइनरचा जाणीवपूर्वक घेतलेला निर्णय होता आणि त्याची गरज का आहे हे पूर्णपणे समजून घेण्यासाठी, विकासकांची प्रेरणा आणि ते Go मध्ये काय साध्य करण्याचा प्रयत्न करत होते हे आपण समजून घेतले पाहिजे.

मग ते इतके सोपे का केले गेले? येथे काही कोट आहेत रॉब पाईक (अंदाजे: गो भाषेच्या सह-निर्मात्यांपैकी एक):

येथे मुख्य मुद्दा असा आहे की आमचे प्रोग्रामर (अंदाजे: Googlers) संशोधक नाहीत. ते, नियमानुसार, अगदी तरुण आहेत, अभ्यास केल्यानंतर आमच्याकडे येतात, कदाचित त्यांनी Java, किंवा C/C++, किंवा Python चा अभ्यास केला असेल. त्यांना उत्तम भाषा समजू शकत नाही, परंतु त्याच वेळी त्यांनी चांगले सॉफ्टवेअर तयार करावे अशी आमची इच्छा आहे. म्हणूनच त्यांची भाषा त्यांना समजण्यास व शिकण्यास सोपी असावी.
 
तो परिचित असावा, अंदाजे सी सारखाच बोलतो. Google वर काम करणारे प्रोग्रामर त्यांचे करिअर लवकर सुरू करतात आणि त्यांना मुख्यतः प्रक्रियात्मक भाषा, विशेषतः C कुटुंबाशी परिचित असतात. नवीन प्रोग्रॅमिंग भाषेत जलद उत्पादनक्षमतेची आवश्यकता म्हणजे भाषा खूप मूलगामी असू नये.

काय? त्यामुळे रॉब पाईक मुळात असे म्हणत आहेत की Google मधील विकसक इतके चांगले नाहीत, म्हणूनच त्यांनी मूर्खांसाठी एक भाषा तयार केली (अंदाजे: डंब डाउन) जेणेकरून ते काहीतरी करू शकतील. आपल्याच सहकाऱ्यांकडे कसले उद्धट नजरेने बघायचे? माझा नेहमीच विश्वास आहे की Google चे डेव्हलपर हे पृथ्वीवरील सर्वात तेजस्वी आणि सर्वोत्तम लोकांमधून निवडलेले आहेत. नक्कीच ते काहीतरी अधिक कठीण हाताळू शकतात?

अत्याधिक साधेपणाची कलाकृती

कोणत्याही डिझाइनमध्ये साधे असणे हे एक योग्य ध्येय आहे आणि काहीतरी सोपे करण्याचा प्रयत्न करणे कठीण आहे. तथापि, जटिल समस्या सोडवण्याचा (किंवा अगदी व्यक्त) करण्याचा प्रयत्न करताना, कधीकधी एक जटिल साधन आवश्यक असते. जटिलता आणि गुंतागुंत ही प्रोग्रामिंग भाषेची सर्वोत्कृष्ट वैशिष्ट्ये नाहीत, परंतु एक मध्यम मैदान आहे ज्यामध्ये भाषा समजण्यास आणि वापरण्यास सुलभ असलेल्या मोहक अमूर्तता तयार करू शकते.

फार व्यक्त नाही

त्याच्या साधेपणाच्या बांधिलकीमुळे, 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);
    }
}

आणि आता कोण जास्त वाचनीय आहे? मी माझे मत डी ला देईन. त्याचा कोड अधिक वाचनीय आहे कारण तो क्रियांचे अधिक स्पष्टपणे वर्णन करतो. डी अधिक जटिल संकल्पना वापरते (अंदाजे: पर्यायी फंक्शन कॉल и नमुने) गो उदाहरणापेक्षा, परंतु त्यांना समजून घेण्यात खरोखर काहीही क्लिष्ट नाही.

कॉपी करण्याचा नरक

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

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{} अधिक वाचनीय किंवा अगदी सुरक्षित टाइप करा?

अवलंबित्व व्यवस्थापनाचे संकट

Go मध्ये लोकप्रिय होस्टिंग प्रदात्यांच्या शीर्षस्थानी अंगभूत अवलंबन प्रणाली आहे व्हीसीएस. Go सोबत आलेल्या टूल्सना या सेवांबद्दल माहिती असते आणि ते त्यांच्याकडून कोड डाउनलोड, बिल्ड आणि इन्स्टॉल करू शकतात. हे छान असले तरी, व्हर्जनिंगमध्ये एक मोठी त्रुटी आहे! होय, हे खरे आहे की तुम्ही गो टूल्स वापरून गिथब किंवा बिटबकेट सारख्या सेवांमधून स्त्रोत कोड मिळवू शकता, परंतु तुम्ही आवृत्ती निर्दिष्ट करू शकत नाही. आणि उपयुक्ततेच्या खर्चावर पुन्हा साधेपणा. अशा निर्णयाचे तर्क मला समजत नाहीत.

या समस्येचे निराकरण करण्यासाठी प्रश्न विचारल्यानंतर, गो डेव्हलपमेंट टीम तयार केली मंच धागा, ज्याने ते या समस्येवर कसे जायचे हे स्पष्ट केले. त्यांची शिफारस अशी होती की एका दिवसात संपूर्ण रेपॉजिटरी तुमच्या प्रोजेक्टमध्ये कॉपी करा आणि "जसे आहे तसे" ठेवा. ते काय विचार करत आहेत? आमच्याकडे उत्कृष्ट टॅगिंग आणि आवृत्ती समर्थनासह आश्चर्यकारक आवृत्ती नियंत्रण प्रणाली आहेत ज्याकडे Go निर्माते दुर्लक्ष करतात आणि फक्त स्त्रोत कोड कॉपी करतात.

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

माझ्या मते, ज्यांनी आयुष्यभर C चा वापर केला आणि ज्यांना काहीतरी नवीन करून पहायचे नव्हते अशा लोकांद्वारे Go विकसित केले गेले. भाषेचे अतिरिक्त चाकांसह C असे वर्णन केले जाऊ शकते(मूळ: प्रशिक्षण चाके). त्यात समांतरतेच्या समर्थनाशिवाय कोणत्याही नवीन कल्पना नाहीत (जे, तसे, आश्चर्यकारक आहे) आणि ही लाजिरवाणी गोष्ट आहे. केवळ वापरण्यायोग्य, लंगड्या भाषेत तुमच्याकडे उत्कृष्ट समांतरता आहे.

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

आपल्या स्वतःच्या फायद्यासाठी साधेपणा

Go ची रचना सोपी करण्यासाठी केली गेली होती आणि ती त्या ध्येयात यशस्वी होते. हे टेम्प्लेट म्हणून जुनी भाषा वापरून कमकुवत प्रोग्रामरसाठी लिहिले होते. सोप्या गोष्टी करण्यासाठी हे साध्या साधनांसह पूर्ण होते. हे वाचण्यास सोपे आणि वापरण्यास सोपे आहे.

हे अत्यंत शब्दशः, अप्रभावी आणि स्मार्ट प्रोग्रामरसाठी वाईट आहे.

Спасибо mersinvald संपादनांसाठी

स्त्रोत: www.habr.com