यह लेख पहले प्रकाशित लेख की प्रतिक्रिया के रूप में लिखा गया था एंटीपोडियन लेख.

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

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

कमजोर लोग समस्याओं की बात करते हैं। विचारों और सपनों के बारे में जोरदार बातचीत...

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

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

तो इसे इतना सरल क्यों बनाया गया? यहां रोब पाइक के कुछ उद्धरण दिए गए हैं:

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

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

बुद्धिमान शब्द, है ना?

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

सुंदरता के लिए सादगी एक आवश्यक शर्त है। लेव टॉल्स्टॉय.

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

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

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

कला बर्दाश्त नहीं करती जब उसकी स्वतंत्रता बाधित होती है। सटीकता उसकी जिम्मेदारी नहीं है.

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

उदाहरण के लिए, एक कंसोल उपयोगिता जो कमांड लाइन तर्कों से stdin या फ़ाइल को पढ़ती है वह इस तरह दिखेगी:

package main

import (
    "bufio"
    "flag"
    "fmt"
    "log"
    "os"
)

func main() {

    flag.Parse()

    scanner := newScanner(flag.Args())

    var text string
    for scanner.Scan() {
        text += scanner.Text()
    }

    if err := scanner.Err(); err != nil {
        log.Fatal(err)
    }

    fmt.Println(text)
}

func newScanner(flags []string) *bufio.Scanner {
    if len(flags) == 0 {
        return bufio.NewScanner(os.Stdin)
    }

    file, err := os.Open(flags[0])

    if err != nil {
        log.Fatal(err)
    }

    return bufio.NewScanner(file)
}

डी में उसी समस्या का समाधान, हालांकि यह कुछ छोटा दिखता है, पढ़ने में आसान नहीं है

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 main() {

    list32 := []int32{1, 2, 3, 4, 5}
    list64 := []int64{1, 2, 3, 4, 5}

    fmt.Println(int32Sum(list32))
    fmt.Println(int64Sum(list64))
}

ऐसे निर्माणों को कार्यान्वित करने के लिए भाषा के पास पर्याप्त साधन हैं। उदाहरण के लिए, सामान्य प्रोग्रामिंग ठीक रहेगी.

package main

import "fmt"

func Eval32(list []int32, fn func(a, b int32)int32) int32 {
    var res int32
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int32Add(a, b int32) int32 {
    return a + b
}

func int32Sub(a, b int32) int32 {
    return a + b
}

func Eval64(list []int64, fn func(a, b int64)int64) int64 {
    var res int64
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int64Add(a, b int64) int64 {
    return a + b
}

func int64Sub(a, b int64) int64 {
    return a - b
}

func main() {

    list32 := []int32{1, 2, 3, 4, 5}
    list64 := []int64{1, 2, 3, 4, 5}

    fmt.Println(Eval32(list32, int32Add))
    fmt.Println(Eval64(list64, int64Add))
    fmt.Println(Eval64(list64, int64Sub))
}

और, यद्यपि हमारा कोड पिछले मामले की तुलना में कुछ लंबा निकला, यह सामान्यीकृत हो गया है। इसलिए, हमारे लिए सभी अंकगणितीय संक्रियाओं को लागू करना कठिन नहीं होगा।

कई लोग कहेंगे कि डी में एक कार्यक्रम काफी छोटा दिखता है, और वे सही होंगे।

import std.stdio;
import std.algorithm;

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

हालाँकि, यह केवल छोटा है, लेकिन अधिक सही नहीं है, क्योंकि डी कार्यान्वयन त्रुटि प्रबंधन की समस्या को पूरी तरह से अनदेखा करता है।

वास्तविक जीवन में, जैसे-जैसे तर्क की जटिलता बढ़ती है, अंतर तेजी से कम होता जाता है। यह अंतर तब और भी तेजी से समाप्त हो जाता है जब आपको कोई ऐसा कार्य करने की आवश्यकता होती है जो मानक भाषा ऑपरेटरों का उपयोग करके नहीं किया जा सकता है।

रखरखाव, विस्तारशीलता और पठनीयता के मामले में, मेरी राय में, गो भाषा जीतती है, हालांकि यह वाचालता में हार जाती है।

कुछ मामलों में सामान्यीकृत प्रोग्रामिंग हमें निर्विवाद लाभ देती है। यह सॉर्ट पैकेज द्वारा स्पष्ट रूप से दर्शाया गया है। इसलिए, किसी भी सूची को क्रमबद्ध करने के लिए, हमें बस sort.Interface इंटरफ़ेस को लागू करने की आवश्यकता है।

import "sort"

type Names []string

func (ns Names) Len() int {
    return len(ns)
}

func (ns Names) Less(i, j int) bool {
    return ns[i] < ns[j]
}

func (ns Names) Swap(i, j int) {
    ns[i], ns[j] = ns[j], ns[i]
}

func main() {
    names := Names{"London", "Berlin", "Rim"}
    sort.Sort(names)
}

यदि आप कोई ओपन सोर्स प्रोजेक्ट लेते हैं और grep "interface{}" -R कमांड चलाते हैं, तो आप देखेंगे कि कितनी बार भ्रमित करने वाले इंटरफेस का उपयोग किया जाता है। करीबी दिमाग वाले कॉमरेड तुरंत कहेंगे कि यह सब जेनरिक की कमी के कारण है। हालांकि, यह मामला हमेशा नहीं होता है। आइए एक उदाहरण के रूप में डेल्फी को लें। समान जेनेरिक की उपस्थिति के बावजूद, इसमें मनमाने डेटा प्रकारों के साथ संचालन के लिए एक विशेष VARIANT प्रकार शामिल है। गो भाषा भी यही करती है।

तोप से लेकर गौरैया तक

और स्ट्रेटजैकेट को पागलपन के आकार के अनुरूप होना चाहिए। स्टानिस्लाव लेक.

कई चरम प्रशंसक दावा कर सकते हैं कि गो के पास जेनेरिक बनाने के लिए एक और तंत्र है - प्रतिबिंब। और वे सही होंगे... लेकिन केवल दुर्लभ मामलों में।

रोब पाइक ने हमें चेतावनी दी:

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

विकिपीडिया हमें निम्नलिखित बताता है:

रिफ्लेक्शन उस प्रक्रिया को संदर्भित करता है जिसके दौरान एक प्रोग्राम निष्पादन के दौरान अपनी संरचना और व्यवहार की निगरानी और संशोधन कर सकता है। प्रतिबिंब में अंतर्निहित प्रोग्रामिंग प्रतिमान को चिंतनशील प्रोग्रामिंग कहा जाता है। यह एक प्रकार का मेटाप्रोग्रामिंग है।

हालाँकि, जैसा कि आप जानते हैं, आपको हर चीज़ के लिए भुगतान करना होगा। इस मामले में यह है:

प्रोग्राम लिखने में कठिनाई
कार्यक्रम निष्पादन गति

इसलिए, बड़े क्षमता वाले हथियार की तरह, प्रतिबिंब का उपयोग सावधानी से किया जाना चाहिए। प्रतिबिंब के विचारहीन उपयोग से अपठनीय कार्यक्रम, निरंतर त्रुटियां और कम गति होती है। एक दंभी प्रोग्रामर के लिए बस यही बात है कि वह अन्य, अधिक व्यावहारिक और विनम्र सहकर्मियों के सामने अपना कोड दिखाने में सक्षम हो।

शी से सांस्कृतिक बोझ? नहीं, अनेक भाषाओं से!

भाग्य के साथ-साथ उत्तराधिकारियों पर कर्ज भी छोड़ दिया जाता है।

इस तथ्य के बावजूद कि कई लोग मानते हैं कि भाषा पूरी तरह से सी विरासत पर आधारित है, यह मामला नहीं है। यह भाषा सर्वोत्तम प्रोग्रामिंग भाषाओं के कई पहलुओं को शामिल करती है।

वाक्य-विन्यास

सबसे पहले, व्याकरणिक संरचनाओं का वाक्य-विन्यास C भाषा के वाक्य-विन्यास पर आधारित होता है। हालाँकि, डेल्फी भाषा का भी महत्वपूर्ण प्रभाव था। इस प्रकार, हम देखते हैं कि अनावश्यक कोष्ठक, जो प्रोग्राम की पठनीयता को बहुत कम कर देते हैं, पूरी तरह से हटा दिए गए हैं। भाषा में DELPHI भाषा में निहित ":=" ऑपरेटर भी शामिल है। पैकेज की अवधारणा एडीए जैसी भाषाओं से उधार ली गई है। अप्रयुक्त संस्थाओं की घोषणा PROLOG भाषा से ली गई है।

अर्थ विज्ञान

पैकेज डेल्फी भाषा के शब्दार्थ पर आधारित थे। प्रत्येक पैकेज डेटा और कोड को समाहित करता है और इसमें निजी और सार्वजनिक संस्थाएँ शामिल होती हैं। यह आपको पैकेज इंटरफ़ेस को न्यूनतम करने की अनुमति देता है।

प्रतिनिधिमंडल विधि द्वारा कार्यान्वयन संचालन डेल्फी भाषा से उधार लिया गया था।

संकलन

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

उच्च स्तरीय निर्माण

भाषा में कई अलग-अलग उच्च-स्तरीय संरचनाएं शामिल हैं जो किसी भी तरह से सी जैसी निम्न-स्तरीय भाषाओं से संबंधित नहीं हैं।

पंक्तियां
हैश टेबल
स्लाइस
डक टाइपिंग को RUBY जैसी भाषाओं से उधार लिया गया है (जो, दुर्भाग्य से, बहुत से लोग नहीं समझते हैं या इसकी पूरी क्षमता से उपयोग नहीं करते हैं)।

स्मृति प्रबंधन

मेमोरी प्रबंधन आम तौर पर एक अलग लेख का हकदार है। यदि C++ जैसी भाषाओं में, नियंत्रण पूरी तरह से डेवलपर पर छोड़ दिया गया है, तो बाद की भाषाओं जैसे DELPHI में, एक संदर्भ गिनती मॉडल का उपयोग किया गया था। इस दृष्टिकोण के साथ, चक्रीय संदर्भों की अनुमति नहीं थी, क्योंकि अनाथ समूहों का गठन किया गया था, तो गो ने ऐसे समूहों (जैसे सी #) का अंतर्निहित पता लगाया है। इसके अलावा, कचरा संग्रहकर्ता वर्तमान में ज्ञात अधिकांश कार्यान्वयनों की तुलना में अधिक कुशल है और इसका उपयोग पहले से ही कई वास्तविक समय के कार्यों के लिए किया जा सकता है। भाषा स्वयं उन स्थितियों को पहचानती है जब किसी वेरिएबल को स्टोर करने के लिए स्टैक पर मान आवंटित किया जा सकता है। इससे मेमोरी मैनेजर पर लोड कम हो जाता है और प्रोग्राम की गति बढ़ जाती है।

समवर्ती और समवर्ती

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

अतिरिक्त लाभ

लाभ होगा तो सभी निःस्वार्थ हो जायेंगे।

भाषा हमें कई निस्संदेह लाभ भी प्रदान करती है:

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

सामुदायिक लाभ के लिए सरलता

इसे जटिल बनाना आसान है, सरल बनाना कठिन है।

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

कंपनियों को कई फायदे भी मिलते हैं: कम प्रवेश बाधा उन्हें जल्दी से एक विशेषज्ञ ढूंढने की अनुमति देती है, और भाषा की अपरिवर्तनीयता उन्हें 10 वर्षों के बाद भी उसी कोड का उपयोग करने की अनुमति देती है।

निष्कर्ष

मस्तिष्क के बड़े आकार ने कभी किसी हाथी को नोबेल पुरस्कार विजेता नहीं बनाया।

उन प्रोग्रामर के लिए जिनका व्यक्तिगत अहंकार टीम भावना पर प्राथमिकता रखता है, साथ ही सिद्धांतकार जो अकादमिक चुनौतियों और अंतहीन "आत्म-सुधार" को पसंद करते हैं, भाषा वास्तव में खराब है, क्योंकि यह एक सामान्य उद्देश्य वाली कलात्मक भाषा है जो आपको प्राप्त करने की अनुमति नहीं देती है अपने काम के नतीजे से सौंदर्यपूर्ण आनंद लें और सहकर्मियों के सामने खुद को पेशेवर दिखाएं (बशर्ते कि हम बुद्धिमत्ता को इन मानदंडों से मापें, न कि IQ से)। जीवन में हर चीज़ की तरह, यह व्यक्तिगत प्राथमिकताओं का मामला है। सभी सार्थक नवाचारों की तरह, भाषा पहले ही सार्वभौमिक अस्वीकृति से सामूहिक स्वीकृति तक एक लंबा सफर तय कर चुकी है। भाषा अपनी सरलता में सरल है, और, जैसा कि आप जानते हैं, हर सरल चीज़ सरल होती है!

स्रोत: www.habr.com

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