लेख को पहले प्रकाशित एक एंटीपोड लेख की प्रतिक्रिया के रूप में लिखा गया है।
पिछले दो से अधिक वर्षों से, मैं एक विशेष बिलिंग सिस्टम के साथ एक विशेष RADIUS सर्वर को लागू करने के लिए गो का उपयोग कर रहा हूं। इस प्रक्रिया में, मैं भाषा की बारीकियों को स्वयं सीखता हूं। कार्यक्रम स्वयं बहुत सरल हैं और एक लेख लिखने का उद्देश्य नहीं है, लेकिन गो का उपयोग करने का अनुभव अपने बचाव में कुछ शब्द कहने के लिए योग्य है। गंभीर, स्केलेबल कोड के लिए गो एक तेजी से लोकप्रिय भाषा बन रही है। भाषा Google में बनाई गई है, जिसमें इसे सक्रिय रूप से उपयोग किया जाता है। रेखा को सारांशित करते हुए, मुझे पूरा विश्वास है कि गो भाषा का डिज़ाइन डंब प्रोग्रामर्स के लिए बुरा है।
कमजोर प्रोग्रामर के लिए बनाया गया है?
कमजोर समस्याओं के बारे में बात करते हैं। विचारों और सपनों के बारे में जोरदार बात ...
सीखने के लिए गो बहुत सरल है, इतना सरल कि आप कोड को बहुत कम या बिना तैयारी के पढ़ सकते हैं। भाषा की यह विशेषता कई विश्व कंपनियों में उपयोग की जाती है जब कोड को गैर-कोर विशेषज्ञों (प्रबंधकों, ग्राहकों, आदि) के साथ पढ़ा जाता है। यह डिज़ाइन किए गए विकास जैसी कार्यप्रणाली के लिए बहुत सुविधाजनक है।
यहां तक कि नौसिखिए प्रोग्रामर एक या दो सप्ताह के बाद काफी सभ्य कोड का उत्पादन करने लगते हैं। मैंने जिस पुस्तक का अध्ययन किया, उसे "गो प्रोग्रामिंग" (मार्क समरफील्ड द्वारा लिखित) कहा जाता है। किताब बहुत अच्छी है, यह भाषा की कई बारीकियों को छूती है। जावा, पीएचपी जैसी अनावश्यक रूप से जटिल भाषाओं के बाद, जादू की कमी ताज़ा है। लेकिन जल्द या बाद में, कई सीमित प्रोग्रामर एक नए क्षेत्र में पुराने तरीकों का उपयोग करने की इच्छा रखते हैं। क्या यह वास्तव में आवश्यक है?
रोब पाइक (भाषा के मुख्य विचारक) ने गो को एक औद्योगिक भाषा के रूप में बनाया जो पढ़ने में आसान है, उपयोग करने के लिए प्रभावी है। भाषा को बड़ी टीमों में अधिकतम उत्पादकता के लिए डिज़ाइन किया गया है और इसमें कोई संदेह नहीं है। कई नौसिखिए प्रोग्रामर शिकायत करते हैं कि कई विशेषताएं हैं जिनमें उनकी कमी है। सादगी की यह इच्छा भाषा डेवलपर्स का एक सचेत निर्णय था, और यह पूरी तरह से समझने के लिए कि यह किस लिए था, हमें डेवलपर्स की प्रेरणा और गो में उन्होंने क्या हासिल किया, यह समझने की जरूरत है।
तो इसे इतना सरल क्यों बनाया गया था? यहां रोब पाइक के कुछ उद्धरण दिए गए हैं:
यहां मुख्य बात यह है कि हमारे प्रोग्रामर शोधकर्ता नहीं हैं। वे आमतौर पर बहुत युवा हैं, स्कूल के बाद हमारे पास आते हैं, शायद उन्होंने जावा, या सी / सी ++, या पायथन का अध्ययन किया। वे एक उत्कृष्ट भाषा को समझने में सक्षम नहीं हैं, लेकिन साथ ही, हम चाहते हैं कि वे अच्छे सॉफ्टवेयर बनाएं। इसीलिए भाषा को समझना और सीखना आसान होना चाहिए।
उसे सी की तरह परिचित, मोटे तौर पर बोलना चाहिए। Google प्रोग्रामर अपने करियर की शुरुआत करते हैं और ज्यादातर प्रक्रियात्मक भाषाओं से परिचित होते हैं, विशेष रूप से सी परिवार। एक नई प्रोग्रामिंग भाषा में त्वरित उत्पादकता की आवश्यकता का मतलब है कि भाषा बहुत अधिक कट्टरपंथी नहीं होनी चाहिए।
समझदार शब्द, सही?
सादगी की कलाकृतियाँ
सुंदर के लिए सादगी एक आवश्यक शर्त है। लियो टॉल्स्टॉय।
सरल होना किसी भी डिजाइन में सबसे महत्वपूर्ण आकांक्षाओं में से एक है। जैसा कि आप जानते हैं, एक सही परियोजना एक ऐसी परियोजना नहीं है जहां जोड़ने के लिए कुछ भी नहीं है, लेकिन एक - जिसमें से निकालने के लिए कुछ भी नहीं है। कई लोग मानते हैं कि जटिल कार्यों को हल करने (या यहां तक कि व्यक्त) करने के लिए, एक जटिल उपकरण की आवश्यकता होती है। हालाँकि, ऐसा नहीं है। उदाहरण के लिए पर्ल भाषा लें। भाषा के विचारकों का मानना था कि एक प्रोग्रामर के पास एक समस्या को हल करने के लिए कम से कम तीन अलग-अलग तरीके होने चाहिए। गो भाषा के विचारक अलग तरीके से चले गए, उन्होंने तय किया कि लक्ष्य को प्राप्त करने के लिए, एक ही रास्ता काफी है, लेकिन वास्तव में अच्छा है। इस दृष्टिकोण की एक गंभीर नींव है: एकमात्र तरीका सीखना आसान है और भूलना मुश्किल है।
कई प्रवासियों की शिकायत है कि भाषा में सुरुचिपूर्ण सार नहीं है। हाँ, यह है, लेकिन यह भाषा के मुख्य लाभों में से एक है। भाषा में न्यूनतम जादू होता है - इसलिए, कार्यक्रम को पढ़ने के लिए कोई गहन ज्ञान की आवश्यकता नहीं होती है। कोड की क्रियाशीलता के लिए, यह एक समस्या नहीं है। एक अच्छी तरह से लिखा गया गोलांग कार्यक्रम बहुत कम या बिना किसी संरचना के साथ लंबवत पढ़ा जाता है। इसके अलावा, किसी कार्यक्रम को पढ़ने की गति कम से कम उसके लेखन की तुलना में तेजी से परिमाण का एक क्रम है। यदि हम मानते हैं कि सभी कोड में एकरूप स्वरूपण (अंतर्निहित गोफमट कमांड का उपयोग करके) किया गया है, तो कुछ अतिरिक्त लाइनों को पढ़ना बिल्कुल भी समस्या नहीं है।
बहुत अभिव्यंजक नहीं है
जब वह अपनी स्वतंत्रता में बाधा डालता है तो कला उसे सहन नहीं करती है। सटीकता उसकी जिम्मेदारी नहीं है।
सादगी की इच्छा के कारण, गो में ऐसे निर्माणों का अभाव है कि अन्य भाषाओं में उनके लिए आदी लोगों के लिए कुछ स्वाभाविक माना जाता है। सबसे पहले, यह कुछ हद तक असुविधाजनक हो सकता है, लेकिन फिर आप नोटिस करते हैं कि कार्यक्रम कई बार आसान और अधिक निश्चित पढ़ा जाता है।
उदाहरण के लिए, एक सांत्वना उपयोगिता जो स्टैडेन पढ़ती है या कमांड लाइन तर्कों से एक फाइल इस तरह दिखाई देगी:
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; }
हालाँकि, यह केवल छोटा है, लेकिन अधिक सही नहीं है, क्योंकि D कार्यान्वयन में त्रुटि से निपटने की समस्या को पूरी तरह से अनदेखा कर दिया गया है।
वास्तविक जीवन में, जब तर्क की जटिलता बढ़ती है, तो अंतर तेजी से कम हो जाता है। इससे भी अधिक तेजी से, अंतर को संकुचित किया जाता है जब एक कार्रवाई की आवश्यकता होती है जिसे मानक भाषा ऑपरेटरों का उपयोग करके नहीं किया जा सकता है।
समर्थन, विस्तार, पठनीयता के संदर्भ में, मेरी राय में, गो भाषा जीतती है, हालांकि यह वाचालता में खो देती है।
कुछ मामलों में सामान्यीकृत प्रोग्रामिंग हमें निर्विवाद लाभ देती है। यह स्पष्ट रूप से सॉर्ट पैकेज दिखाता है। इसलिए, किसी भी सूची को छाँटने के लिए, यह छाँटने के लिए पर्याप्त है। 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 "इंटरफ़ेस {}" -R कमांड चलाते हैं, तो आप देखेंगे कि कितनी बार भ्रमित इंटरफेस का उपयोग किया जाता है। संकीर्ण सोच वाले कामरेड तुरंत कहेंगे कि यह सब जेनरिक की कमी के कारण है। हालांकि, यह हमेशा मामले से दूर है। उदाहरण के लिए DELPHI भाषा को लें। इन समान जेनेरिक होने के बावजूद, इसमें मनमाना डेटा प्रकारों के साथ संचालन के लिए एक विशेष प्रकार VARIANT शामिल है। जाओ वही काम करता है।
गौरैया पर बंदूक से
और एक स्ट्रेटजैकेट को पागलपन के आकार में फिट होना चाहिए। स्टानिस्लाव चलो।
चरम खेलों के कई प्रशंसक कह सकते हैं कि गो में जेनरिक - प्रतिबिंब बनाने के लिए एक और तंत्र है। और वे सही होंगे ... लेकिन केवल दुर्लभ मामलों में।
रोब पाइक हमें चेतावनी देता है:
यह एक शक्तिशाली उपकरण है जिसका उपयोग देखभाल के साथ किया जाना चाहिए। इसे तब तक टाला जाना चाहिए जब तक यह सख्ती से आवश्यक न हो।
विकिपीडिया हमें निम्नलिखित बताता है:
परावर्तन का मतलब एक ऐसी प्रक्रिया है जिसके दौरान कोई प्रोग्राम रनटाइम पर अपनी संरचना और व्यवहार को ट्रैक और संशोधित कर सकता है। प्रोग्रामिंग प्रतिमान अंतर्निहित प्रतिबिंब को रिफ्लेक्सिव प्रोग्रामिंग कहा जाता है। यह एक प्रकार का मेटाप्रोग्रामिंग है।
हालांकि, जैसा कि आप जानते हैं, आपको हर चीज के लिए भुगतान करना होगा। इस मामले में, यह है:
- कार्यक्रम लिखने में कठिनाई
- कार्यक्रम निष्पादन की गति
इसलिए, प्रतिबिंब का उपयोग सावधानी के साथ किया जाना चाहिए, एक बड़े कैलिबर हथियार के रूप में। प्रतिबिंब का विचारहीन उपयोग अपठनीय कार्यक्रमों, निरंतर त्रुटियों और कम गति की ओर जाता है। बस बहुत बात यह है कि स्नोब प्रोग्रामर अपने कोड को अन्य, अधिक व्यावहारिक और विनम्र सहयोगियों के सामने दिखा सकता है।
सी से सांस्कृतिक सामान? नहीं, कई भाषाओं से!
राज्य के साथ, उत्तराधिकारी ऋण के साथ छोड़ दिए जाते हैं।
इस तथ्य के बावजूद कि कई लोग मानते हैं कि भाषा पूरी तरह से सी की विरासत पर आधारित है, ऐसा नहीं है। भाषा ने सर्वश्रेष्ठ प्रोग्रामिंग भाषाओं के कई पहलुओं को शामिल किया है।
वाक्य-विन्यास
सबसे पहले, व्याकरणिक निर्माणों का सिंटैक्स सी भाषा के सिंटैक्स पर आधारित है। हालाँकि, DELPHI भाषा का भी महत्वपूर्ण प्रभाव पड़ा। तो, हम देखते हैं कि अतिरिक्त कोष्ठक पूरी तरह से हटा दिए जाते हैं, इसलिए कार्यक्रम की पठनीयता को बहुत कम कर देता है। साथ ही, भाषा में ऑपरेटर :: = शामिल है, जो DELPHI भाषा में अंतर्निहित है। पैकेज की अवधारणा एडीए जैसी भाषाओं से उधार ली गई है। अप्रयुक्त संस्थाओं की घोषणा PROLOG भाषा से उधार ली गई है।
अर्थ विज्ञान
DELPHI भाषा के शब्दार्थ को संकुल के आधार के रूप में लिया गया। प्रत्येक पैकेज डेटा और कोड को एन्क्रिप्ट करता है और इसमें निजी और सार्वजनिक इकाइयां शामिल हैं। यह आपको पैकेज इंटरफ़ेस को कम से कम करने की अनुमति देता है।
डेलिगेशन विधि द्वारा कार्यान्वयन ऑपरेशन को DELPHI से उधार लिया गया था।
संकलन
कोई आश्चर्य नहीं कि एक मजाक है: गो को विकसित किया गया था जबकि सी कार्यक्रम संकलित किया गया था। भाषा की ताकत में से एक अल्ट्रा-फास्ट संकलन है। यह विचार DELPHI से उधार लिया गया था। इसके अलावा, प्रत्येक गो पैकेज DELPHI मॉड्यूल से मेल खाता है। इन पैकेजों को आवश्यक होने पर ही बदला जाता है। इसलिए, अगले संपादन के बाद, पूरे कार्यक्रम को संकलित करना आवश्यक नहीं है, लेकिन यह केवल इन बदले हुए पैकेजों के आधार पर बदले हुए पैकेजों और पैकेजों को फिर से जोड़ने के लिए पर्याप्त है (और केवल अगर पैकेज इंटरफेस बदल गए हैं)।
उच्च स्तर के डिजाइन
भाषा में कई अलग-अलग उच्च-स्तरीय निर्माण शामिल हैं जो किसी भी तरह से निम्न-स्तरीय भाषाओं से जुड़े नहीं हैं जैसे कि सी।
- पंक्तियां
- टेबल हैश
- स्लाइस
- बतख टाइपिंग को रूबी जैसी भाषाओं से उधार लिया जाता है (जो, दुर्भाग्य से, कई लोग समझते नहीं हैं और अपनी पूरी क्षमता का उपयोग नहीं करते हैं)।
मेमोरी प्रबंधन
मेमोरी प्रबंधन आम तौर पर एक अलग लेख के हकदार हैं। यदि C ++ जैसी भाषाओं में, नियंत्रण पूरी तरह से डेवलपर के लिए छोड़ दिया जाता है, तो बाद में DELPHI जैसी भाषाओं में, एक संदर्भ गिनती मॉडल का उपयोग किया गया था। इस दृष्टिकोण के साथ, चक्रीय लिंक की अनुमति नहीं थी, क्योंकि खोए हुए समूहों का गठन किया गया था, फिर ऐसे समूहों का पता लगाना (जैसा कि C # में) अंतर्निहित गो टू है। इसके अलावा, कचरा संग्रहकर्ता वर्तमान में ज्ञात अधिकांश कार्यान्वयनों से अधिक प्रभावी है और पहले से ही कई वास्तविक समय के कार्यों के लिए उपयोग किया जा सकता है। भाषा स्वयं ही उन स्थितियों को पहचानती है जब किसी चर को संग्रहीत करने के लिए एक मूल्य स्टैक पर आवंटित किया जा सकता है। यह मेमोरी मैनेजर पर लोड को कम करता है और कार्यक्रम की गति बढ़ाता है।
सम्भावना और प्रतियोगिता
भाषा की समानता और प्रतिस्पर्धा प्रशंसा से परे है। कोई भी निम्न-स्तरीय भाषा गो भाषा के साथ दूरस्थ रूप से प्रतिस्पर्धा नहीं कर सकती है। निष्पक्षता में, यह ध्यान देने योग्य है कि मॉडल का आविष्कार भाषा के लेखकों द्वारा नहीं किया गया था, लेकिन केवल अच्छी पुरानी एडीए भाषा से उधार लिया गया था। सभी सीपीयू का उपयोग करते हुए भाषा लाखों समानांतर कनेक्शनों को संसाधित करने में सक्षम है, जबकि डेडलॉक और दौड़ की स्थिति के साथ कोडित जटिल समस्याओं के लिए कम आम परिमाण के आदेश पर है।
अतिरिक्त लाभ
अगर यह फायदेमंद है, तो हर कोई निस्वार्थ हो जाएगा।
भाषा हमें कई लाभ प्रदान करती है:
- परियोजना के निर्माण के बाद एकमात्र निष्पादन योग्य फ़ाइल परिनियोजित अनुप्रयोगों को बहुत सरल बनाती है।
- स्टेटिक टाइपिंग और टाइप इंट्रेंस टेस्ट लिखने के बिना भी कोड में त्रुटियों की संख्या को काफी कम कर सकता है। मैं कुछ ऐसे प्रोग्रामर्स को जानता हूं जो बिना किसी टेस्ट के लिखते हैं और साथ ही उनके कोड की गुणवत्ता में भी कोई कमी नहीं आती है।
- मानक पुस्तकालय का बहुत सरल क्रॉस-संकलन और उत्कृष्ट पोर्टेबिलिटी, जो क्रॉस-प्लेटफ़ॉर्म अनुप्रयोगों के विकास को बहुत सरल करता है।
- RE2 नियमित अभिव्यक्ति थ्रेड सुरक्षित हैं और पूर्वानुमान योग्य रनटाइम हैं।
- एक शक्तिशाली मानक पुस्तकालय, जो अधिकांश परियोजनाओं को तीसरे पक्ष के ढांचे के बिना करने की अनुमति देता है।
- भाषा समस्या पर ध्यान केंद्रित करने के लिए पर्याप्त शक्तिशाली है, और इसे हल करने के तरीकों पर नहीं, और एक ही समय में इतनी कम है कि समस्या को कुशलता से हल किया जा सकता है।
- गो इको सिस्टम में पहले से ही सभी अवसरों के लिए आउट-ऑफ-द-बॉक्स टूल शामिल हैं: परीक्षण, प्रलेखन, पैकेज प्रबंधन, शक्तिशाली लिंटर, कोड पीढ़ी, एक दौड़ की स्थिति डिटेक्टर, आदि।
- गो संस्करण 1.11 में अब लोकप्रिय वीसीएस मेजबानों के शीर्ष पर निर्मित अर्थ-निर्भर निर्भरता प्रबंधन है। गो पारिस्थितिकी तंत्र को बनाने वाले सभी उपकरण इन सेवाओं का उपयोग एक गिरे हुए झपट्टे में उनसे कोड डाउनलोड करने, संकलन करने और स्थापित करने के लिए करते हैं। और वह महान है। संस्करण 1.11 के आगमन के साथ, पैकेज संस्करणकरण की समस्या भी पूरी तरह से हल हो गई थी।
- चूंकि भाषा का मुख्य विचार जादू को कम करना है, भाषा डेवलपर्स को स्पष्ट रूप से त्रुटि से निपटने के लिए प्रोत्साहित करती है। और यह सही है, क्योंकि अन्यथा, वह पूरी तरह से त्रुटि से निपटने के बारे में भूल जाएगा। एक और बात यह है कि अधिकांश डेवलपर्स जानबूझकर त्रुटि से निपटने की उपेक्षा करते हैं, बजाय उन्हें संसाधित करने के केवल त्रुटि को आगे बढ़ाने के लिए प्राथमिकता देते हैं।
- भाषा शास्त्रीय OOP पद्धति को लागू नहीं करती है, क्योंकि गो में अपने शुद्ध रूप में कोई आभासीता नहीं है। हालांकि, इंटरफेस का उपयोग करते समय यह कोई समस्या नहीं है। OOP की अनुपस्थिति शुरुआती लोगों के लिए प्रवेश की बाधा को काफी कम कर देती है।
सामुदायिक लाभ के लिए आसानी
जटिल करना सरल है, सरल करना कठिन है।
गो को सरल और उत्कृष्ट बनाया गया था। यह स्मार्ट प्रोग्रामर्स के लिए लिखा गया था जो टीम वर्क के सभी गुणों को समझते हैं और एंटरप्राइज स्तर की भाषाओं की अंतहीन परिवर्तनशीलता से थक गए हैं। अपने शस्त्रागार में सिंटैक्टिक निर्माणों का एक अपेक्षाकृत छोटा सेट होने के कारण, यह व्यावहारिक रूप से समय के साथ परिवर्तनों के अधीन नहीं है, इसलिए, डेवलपर्स ने विशेष रूप से विकास के लिए बहुत समय मुक्त किया है, और भाषा नवाचारों के अंतहीन अध्ययन के लिए नहीं।
कंपनियों को भी कई लाभ मिलते हैं: एक कम प्रवेश सीमा आपको जल्दी से एक विशेषज्ञ को खोजने की अनुमति देती है, और भाषा की अपरिहार्यता आपको 10 साल बाद उसी कोड का उपयोग करने की अनुमति देती है।
निष्कर्ष
बड़े मस्तिष्क के आकार ने अभी तक एक भी हाथी को नोबेल पुरस्कार विजेता नहीं बनाया है।
उन प्रोग्रामर के लिए जिनका व्यक्तिगत अहंकार टीम भावना पर हावी है, साथ ही सिद्धांतकार जो अकादमिक कार्यों और अंतहीन "आत्म-सुधार" से प्यार करते हैं, भाषा वास्तव में खराब है, क्योंकि यह एक सामान्य प्रयोजन कारीगर भाषा है जो अपने काम के परिणाम से सौंदर्य सुख प्राप्त करने और खुद को दिखाने की अनुमति नहीं देती है। सहकर्मियों के सामने एक पेशेवर (बशर्ते कि हम इन मानदंडों के साथ दिमाग को ठीक से मापें, न कि आईक्यू गुणांक के साथ)। जीवन में सब कुछ की तरह, यह व्यक्तिगत प्राथमिकताओं की बात है। सभी सार्थक नवाचारों की तरह, भाषा पहले से ही सार्वभौमिक इनकार से जन मान्यता तक का लंबा सफर तय कर चुकी है। भाषा अपनी सादगी में सरल है, लेकिन, जैसा कि आप जानते हैं, सरल सब कुछ सरल है!
सारांश
गो में निर्देशित सभी कठोर आलोचनाओं के बीच, निम्नलिखित कथन विशेष रूप से खड़े हैं:
- कोई जेनरिक नहीं। यदि हम सबसे लोकप्रिय भाषाओं के आंकड़ों को देखते हैं, तो हम ध्यान देते हैं कि शीर्ष दस भाषाओं में से आधे में जेनरिक नहीं है। ज्यादातर, जेनरिक की आवश्यकता केवल कंटेनरों में होती है। इसलिए, उनसे लाभ बहुत बड़ा नहीं है।
- अन्य भाषाएं जैसे रस्ट बहुत बेहतर हैं (कम से कम XXX साइट श्रेणियों में)। फिर से, यदि हम सबसे लोकप्रिय भाषाओं के आंकड़ों को देखें , तो हमें सूची में रस्ट बिल्कुल नहीं मिलेगा, या यह रेटिंग के नीचे कहीं होगा। निजी तौर पर, मुझे रस्ट पसंद है, लेकिन मैंने गो को चुना।
- XXX के पास एक ऐसी बान है। यह सादगी के सिक्के का दूसरा पहलू है। यह नुकसान है या नहीं, यह सभी को तय करना है। हालांकि, परियोजना के डेवलपर्स ने सादगी के पक्ष में अपनी प्राथमिकता दी।
- वे गो 2.0 रिलीज करेंगे, फिर हम देखेंगे। यह स्थिति प्रेक्षकों द्वारा ली जाती है, चिकित्सकों द्वारा नहीं।
- पर्याप्त अभिव्यंजक नहीं है। मैं मानता हूं, कुछ क्षेत्रों में अभिव्यक्तता लंगड़ी है, लेकिन सामान्य तौर पर यह एक सरल और सुसंगत भाषा है। इसके अलावा, भाषा की गरीबी के कारण, हम विकसित अनुप्रयोग की वास्तुकला पर अधिक ध्यान देने को मजबूर हैं, जो इसके लचीलेपन को सकारात्मक रूप से प्रभावित करता है।
दरअसल, लेख ने गो भाषा के वाक्यगत लाभों के बारे में नहीं सोचा था, बल्कि टीम वर्क के लिए इसके फायदे और परियोजना के प्रभावी विकास के संक्षिप्त विवरण के रूप में विकसित किया गया था। यह समझा गया कि अधिक विशिष्ट समस्याओं के संबंध में लेख जारी रहेगा। हालांकि, विषय में रुचि की कमी के कारण, सबसे अधिक संभावना नहीं होगी।
एक प्रयोग
शब्दों पर विश्वास न करें - न तो आपका और न ही अजनबियों का, लेकिन कर्मों पर विश्वास करें - आपका और अजनबी दोनों का।
अंतिम भाग विशेष रूप से उन लोगों की श्रेणी के लिए अभिप्रेत है जो स्वयं को रचनात्मक रूप से आशावान आशावादी मानते हैं और जो अपने स्वयं के मामलों की पुष्टि कर सकते हैं। बाकी दर्शकों, कृपया इस भाग को छोड़ दें।
यह प्रयोग उन दोस्तों से प्रेरित था, जिन्होंने दावा किया था कि सभी रचनात्मक दिमाग वाले आशावादी लंबे समय तक (कम से कम वस्तुतः) हमारे देश के विस्तार को छोड़ चुके थे और उदाहरण के लिए, स्टैक ओवरफ्लो पर, और यहाँ ज्यादातर स्नोबॉल बने रहे। लंबे समय तक मैंने उन पर विश्वास नहीं किया, इसलिए मैंने इस प्रयोग को करने का फैसला किया।
कई लेख हब पर पोस्ट किए गए थे, उन टिप्पणियों के विश्लेषण का परिणाम जिनके आधार पर मैं बोली।
- दरअसल, मेरे दोस्तों की परिकल्पना की पुष्टि की गई थी, हालांकि, पर्याप्त लोग अभी भी फेरीवालों के बीच पाए जाते हैं, हालांकि उनका प्रतिशत तेजी से गिर रहा है। यूरी बायकोव ऐसे लोगों को " मूर्ख " कहते हैं, जिन पर पूरा देश टिका है। उनके अनुसार, उनका प्रतिशत छोटा है (लगभग 2%)। मैं इतना निराशावादी नहीं हूं और मुझे लगता है कि उनमें से बहुत कुछ हैं।
- मीडिया का कानून। विध्वंसक जानकारी रचनात्मक जानकारी की तुलना में बहुत अधिक रुचि है।
- भीड़ का मनोविज्ञान। यह एक भयानक बात है, यह एक पर्याप्त व्यक्ति से बाहर एक अपमानजनक भेड़ भी बनाता है। भीड़ में एक आदमी अब एक आदमी नहीं है। किसी भी वस्तुनिष्ठता की बात नहीं हो सकती। कोई तार्किक तर्क, कोई आधिकारिक स्रोत या मिसालें अब उसे प्रभावित नहीं करती हैं।
- जिम्मेदारी और अदूरदर्शिता। लोग खुद को बाहर निकालने के लिए (कम से कम अपनी आंखों में) एक और अपमान करने के लिए तैयार हैं। खासकर यदि आपको इसके लिए जवाब नहीं देना है (जो आसान हो सकता है - माइनस साइन पर क्लिक किया और आपको टिप्पणी लिखने की आवश्यकता नहीं है)। एक चैनल और एक सीवर के बीच शब्दों और कर्मों के बीच समान रूप से बहुत कुछ है।
- वैनिटी। अधिकांश स्नोब किसी भी तरह से बाहर खड़े होने के लिए तैयार हैं। वे किसी भी नैतिक बाधाओं से डरते नहीं हैं।
- निराशावाद। पश्चिमी देशों (और विशेष रूप से अमेरिका) के विपरीत, देश में निराशावादी भावनाएं प्रबल हैं। जैसा कि आप जानते हैं, एक आशावादी कठिनाइयों के बीच में अवसरों की तलाश में है, और एक निराशावादी अवसरों के बीच में कठिनाइयों की तलाश कर रहा है। हमारे देश में, लगभग कोई भी किसी भी चीज़ के सकारात्मक गुणों पर ध्यान नहीं देता है।
- व्यावसायिकता और विश्वदृष्टि। अधिकांश लोग अपने आप में एक अंत के रूप में उपकरण चुनते हैं, और एक अंत के साधन के रूप में नहीं। लोग जानकारी के साथ काम करना भूल गए हैं। लोग पेड़ों के पीछे जंगलों को नहीं देखते हैं। जानकारी की एक सरणी से, वे मुख्य विचारों को निकालने में सक्षम नहीं हैं। कोई भी एक अलग से नहीं देखना चाहता है, अपने लिए मानक नहीं है, दृष्टिकोण। विच्छिन्न दबा हुआ है। यह यहां स्वीकार नहीं है।
- मित्रता और सम्मान। प्रशंसा के अनुकूल समूह केवल शब्दों में मौजूद हैं। चंचल विकास मूल्य केवल कागज पर हैं।
- पाखंड। आप सामान्य रूप से इस बारे में एक अलग लेख लिख सकते हैं।
- वफ़ादारी। ऐसे लोग हैं जो सही सवाल पूछते हैं: “ मैं क्या कर रहा हूँ? ", हालांकि, हर कोई यह नहीं समझता है कि, सिद्धांत की कमी के कारण, हमारे लिए, सभी सिद्धांतों की तुलना में क्षणिक स्वार्थी हित अधिक महत्वपूर्ण है। परिस्थितियों पर सब कुछ दोष देना सबसे आसान है और कहते हैं कि कुछ भी हम पर निर्भर नहीं करता है।
सभी रचनात्मक दिमाग वाले आशावादियों के लिए गहरे सम्मान और सहानुभूति के साथ।
Adverax।