हमें कोष्ठकों के बारे में बात करनी चाहिए (2020)

मूल लेख ↗ Hacker News चर्चा ↗

प्रोग्रामिंग भाषाओं को कोष्ठकों और ऑपरेटर प्रिसिडेंस पर कितना निर्भर होना चाहिए, इस पर बहस पठनीयता, परिचितता, और metaprogramming शक्ति के बीच गहरे trade-offs उजागर करती है। कुछ योगदानकर्ता कम precedence और अधिक स्पष्ट grouping (या यहाँ तक कि RPN-शैली syntax) की वकालत करते हैं, जबकि अन्य पारंपरिक गणित-जैसे नियमों और Lisp के पूरी तरह कोष्ठकबद्ध S-expressions का बचाव करते हैं, खासकर जब वे अच्छी indentation और editor support के साथ हों। यह चर्चा इस बात को भी छूती है कि syntax tooling, scoping, और code transformation की सरलता को कैसे आकार देता है, और क्यों—Lisp के macro और “code as data” लाभों के बावजूद—अधिकांश मुख्यधारा भाषाएँ अधिक विविध, कम समान syntactic forms को प्राथमिकता देती रहती हैं.

ऑपरेटर प्रिसिडेंस बनाम अनिवार्य कोष्ठक

  • एक पक्ष का तर्क है कि ऑपरेटर प्रिसिडेंस एक डिज़ाइन गलती है; 1 + 1 * 2 या a | b || c >> d & e * f जैसे मिश्रित-ऑपरेटर अभिव्यक्तियाँ, यदि स्पष्ट रूप से कोष्ठक न हों, तो सिंटैक्स त्रुटियाँ होनी चाहिए।
  • दूसरे इससे सख़्त असहमति रखते हैं, वे नोटेशन की सादगी, बीजगणित से समानता, और अत्यधिक कोष्ठक-युक्त कोड के बोझ का हवाला देते हैं।
  • प्रस्तावित समझौता: एक आंशिक प्रिसिडेंस क्रम। सामान्य संयोजन (जैसे * का + पर) स्वीकार किए जाएँ; असामान्य मिश्रण (जैसे * के साथ &) को “ambiguous precedence” के रूप में अस्वीकार किया जाए।
  • बहस गणित तक फैलती है: कुछ कहते हैं प्रिसिडेंस अंतर्निहित है (“order of operations”); अन्य ज़ोर देते हैं कि यह केवल नोटेशन की एक विशेषता है, जिसे अक्सर भिन्न, घातांक, मूल आदि के माध्यम से दृश्य रूप में व्यक्त किया जाता है।

Lisp के कोष्ठक, पठनीयता, और टूलिंग

  • कई लोग नोट करते हैं कि Lisp में, स्वचालित इंडेंटेशन, संरचनात्मक संपादन, और paren-highlighting आवश्यक माने जाते हैं; ये जल्दी ही गायब या गलत जगह लगे कोष्ठकों को उजागर कर देते हैं।
  • कुछ का तर्क है कि Lisp में केवल एक प्रकार के कोष्ठक पढ़ने की क्षमता को नुकसान पहुँचाते हैं, और अलग-अलग सिंटैक्टिक भूमिकाओं के लिए कई ब्रैकेट प्रकार, या यहाँ तक कि केवल दृश्य समूहबद्धता के लिए परस्पर-विनिमेय ब्रैकेट्स, सुझाते हैं।
  • प्रतिवाद: अनुभवी Lisp उपयोगकर्ता अधिकतर “forms” देखते हैं, कोष्ठक नहीं, और ब्रैकेट गिनने के बजाय symbols से शुरू होने वाले पैटर्न पर निर्भर करते हैं।
  • संरचनात्मक संपादन की प्रशंसा की जाती है: स्पष्ट डिलीमीटर और auto-formatting मिलकर कोड संरचना के लिए “double-entry bookkeeping” जैसे काम करते हैं।

सिंटैक्स शैली, whitespace, और scoping

  • कुछ लोग उन भाषाओं की सराहना करते हैं जो if conditions जैसे constructs में अनावश्यक कोष्ठक हटा देती हैं (Go, Scala 3)।
  • significant whitespace को लेकर मतभेद है: कुछ स्पष्ट डिलीमीटर पसंद करते हैं; अन्य indentation-केंद्रित syntax को अधिक पठनीय मानते हैं।
  • scoping पर चर्चा: सघन lexical blocks ({} या let forms) live variables को कम कर सकते हैं, लेकिन सभी lifetimes को छोटा नहीं किया जा सकता; C, Rust (non-lexical lifetimes), और FP/monadic code के उदाहरण tradeoffs दिखाते हैं।

Lisp का code-as-data और metaprogramming

  • कई टिप्पणियाँ इस बात पर ज़ोर देती हैं कि Lisp के कोष्ठक lists को दर्शाते हैं; programs lists हैं, और quoting code को data में बदल देता है।
  • सरल list operations code को रूपांतरित कर सकती हैं (उदा., सभी * को + से बदलकर फिर eval करना), जो शक्तिशाली macros और domain-specific syntaxes की नींव हैं।
  • उत्साही लोग इसे Lisp की मुख्य ताकत मानते हैं; संशयवादी उत्तर देते हैं कि अन्य भाषाएँ अब कम दृश्य-रूप से दोहरावदार syntax के साथ मज़बूत metaprogramming देती हैं, और सवाल उठाते हैं कि क्या कोष्ठक एक अच्छा ergonomic tradeoff हैं।