"बेकार Ruby sugar": आर्ग्यूमेंट फ़ॉरवर्डिंग
Ruby की नई argument-forwarding syntax `...` डेवलपर्स को दो खेमों में बाँटती है: एक तरफ वे इसे methods को wrap और delegate करने के लिए सुरुचिपूर्ण, कम-मेंटेनेंस sugar मानते हैं, और दूसरी तरफ वे इसे अनावश्यक जटिलता समझते हैं जो readability को नुकसान पहुँचाती है। यह बहस आगे बढ़कर Ruby की समग्र डिज़ाइन—उसकी कई calling conventions, blocks, और बदलती syntax—की आलोचना में बदल जाती है, और JavaScript, Python, Go, तथा Clojure जैसी भाषाओं से तुलना करती है; साथ ही simplicity, “magic,” और एक mature language में syntax कितना बढ़ाया जाना चाहिए, जैसे गहरे सवालों से जुड़ती है। कई टिप्पणीकार optional static typing और type systems (जैसे Sorbet, TypeScript) को robust बनाने का एक वैकल्पिक रास्ता भी मानते हैं, नई syntactic features के बजाय।
लेख और फ़ीचर की समग्र प्रतिक्रिया
- कई टिप्पणीकार इस श्रृंखला का आनंद लेते हैं और आर्ग्यूमेंट-फ़ॉरवर्डिंग
...सिंटैक्स को सुरुचिपूर्ण, अभिव्यंजक, और वास्तविक-जीवन Ruby (जैसे Rails service objects) के लिए उपयोगी मानते हैं। - अन्य लोगों को यह नया sugar बदसूरत, भ्रमित करने वाला, या “बेकार” लगता है, खासकर जब वे पुराने Ruby संस्करणों से आ रहे हों या न्यूनतम, स्पष्ट सिंटैक्स को पसंद करते हों।
एलिप्सिस ... बनाम “code omitted” परंपरा
- कई लोग भ्रम की ओर संकेत करते हैं क्योंकि
...एक वैध Ruby सिंटैक्स भी है और “code omitted” के लिए एक आम परंपरा भी। - कई वैकल्पिक सुझाव दिए जाते हैं:
- स्पेस के साथ
. . ., टिप्पणियाँ, या[..trim..]जैसे पाठ्य संकेतक उपयोग करना। - Rust के
todo!या Python के...जैसे भाषा-फ़ीचर्स पर एक प्लेसहोल्डर के रूप में निर्भर करना।
- स्पेस के साथ
- कई भाषाओं को पहले से ही variadics/spread के लिए
...का उपयोग करते हुए उद्धृत किया जाता है, इसलिए कुछ लोगों का तर्क है कि Ruby किसी “industry standard” को नहीं तोड़ रही।
Ruby का आर्ग्यूमेंट और ब्लॉक मॉडल
- स्पष्टीकरण यह स्पष्ट करते हैं कि Ruby में:
- positional और keyword arguments होते हैं, साथ ही एक वैकल्पिक block भी।
- hashes बनाम keywords के आसपास ऐतिहासिक विचित्रताएँ थीं, जिन्हें Ruby 3 में साफ़ किया गया।
- blocks बनाम procs बनाम lambdas पर चर्चा होती है:
- blocks विशेष return semantics वाले implicit closures हैं।
- procs/lambdas अलग से बनाए गए callable objects हैं, जिनका control-flow व्यवहार अलग होता है।
- कुछ लोगों को function-जैसी तीन abstractions बहुत जटिल लगती हैं; अन्य इन्हें सीख लेने के बाद शक्तिशाली और सहज मानते हैं।
डिज़ाइन गुणवत्ता: Ruby बनाम अन्य भाषाएँ
- एक पक्ष का तर्क है कि Ruby की कई calling conventions और sugars, JavaScript जैसे सरल मॉडलों की तुलना में, एक दोषपूर्ण या बहुत बढ़ चुकी डिज़ाइन को दर्शाते हैं (जैसे “बस objects और functions पास करो”)।
- विरोधी दृष्टिकोण:
- Ruby की syntax और semantics को सावधानी से सोचा हुआ और अत्यंत पठनीय माना जाता है।
- उसी युग की कई भाषाओं ने अजीब निर्णय लिए; Ruby अकेली विशेष रूप से खराब नहीं है।
- Ruby elegant DSL-like code के लिए बहुत ऊँची क्षमता देती है, लेकिन unreadable “magic” के लिए बहुत नीचा स्तर भी।
Static typing और बड़े सिस्टम
- कुछ लोग तर्क देते हैं कि Ruby को optional static typing को प्राथमिकता देनी चाहिए; अन्य कहते हैं कि एक ही भाषा में दो type systems होना खराब engineering है।
- TypeScript और Python के type hints को सफल उदाहरणों के रूप में उद्धृत किया जाता है; Sorbet और अन्य Ruby typing tools को उपयोगी लेकिन कम शक्तिशाली माना जाता है।
- इस बात पर तीखी असहमति है कि क्या static typing बड़े, लंबे समय तक चलने वाले systems के लिए आवश्यक है या एक बढ़ा-चढ़ाकर आँकी गई, धीमी feedback वाली practice है।