तुम ऐसा नहीं कर सकते क्योंकि मैं तुमसे नफ़रत करता हूँ

Python REPL exit व्यवहार

• बहस exit बनाम exit() को Python REPL में टाइप करने को लेकर केंद्रित है।
• कुछ लोग मौजूदा व्यवहार (repr(exit) के जरिए एक hint string प्रिंट करना) को संरक्षक-सा और उपदेशात्मक मानते हैं: interpreter इरादा पहचानता है लेकिन बाहर नहीं निकलता।
• दूसरे इसे एक उचित समझौता मानते हैं:
  • semantics को सुसंगत रखता है (functions बिना () के नहीं चलतीं)।
  • ऐसे special-casing से बचाता है जो REPL consistency या repr() के side-effect free होने पर निर्भर tooling को तोड़ सकता है।
• सुझाए गए विकल्प:
  • केवल REPL में exit के लिए special-casing।
  • function repr के साथ एक hint दोनों प्रिंट करना।
  • __repr__ बदलने के बजाय warnings या REPL-specific hints।
• ipython का अधिक friendly handling (exit बस काम करता है) इस बात के प्रमाण के रूप में उद्धृत है कि बेहतर UX संभव है।

---

“Do What I Mean” बनाम कठोरता

• एक पक्ष: tools को स्पष्ट रूप से असंदिग्ध इरादे पर काम करना चाहिए (जैसे exit, मदद के लिए -?, जब --foo मौजूद हो तो -foo)। स्पष्ट इरादे को अनदेखा करना शत्रुतापूर्ण लगता है और समय बर्बाद करता है।
• दूसरा पक्ष: DWIM व्यवहार spec का हिस्सा बन जाता है, अस्पष्टता लाता है, और जब अनुमान गलत हों तो बदतर failures पैदा कर सकता है (जैसे semicolon insertion, browsers का permissive HTML)।
• कई लोग मानते हैं कि automatic fixes की बजाय hints और स्पष्ट errors बेहतर हैं।

---

Rust Tooling और Unstable Features

• rustfmt का wrap_comments और cargo vendor का हटाया गया --no-merge-sources flag विवाद के केंद्र हैं।
• आलोचक: सरल, स्पष्ट रूप से उपयोगी features को nightly के पीछे gate करना या flags को बिना सहायक संदेशों के हटाना ऐसा लगता है जैसे “tool जानता है मैं क्या चाहता हूँ लेकिन मना कर देता है।”
• समर्थक: formatting और vendor behavior में पेचीदा edge cases हैं; “unstable” mass churn को diffs और CI में रोकता है, और implementation trivial नहीं है। backlogs और prioritization सीमाएँ हैं, खासकर volunteer projects में।
• कुछ लोगों को nightly/stable विभाजन बहुत मोटा लगता है: छोटे utility functions या formatter options के लिए nightly की आवश्यकता नहीं होनी चाहिए।

---

CLI Ergonomics और Help Flags

• उन tools पर बार-बार नाराज़गी जो:
  • -? या -h को अस्वीकार करते हैं जबकि किसी और help flag का सुझाव देते हैं।
  • सख्त option ordering लागू करते हैं (git log --stat directory)।
• बहुत से लोग multiple help invocations को स्वीकार करने और अधिक forgiving parsing के पक्ष में हैं, खासकर help-संबंधी actions के लिए।

---

Defaults, “Don’t Suck” Buttons, और सहानुभूति

• “Don’t suck” buttons: ऐसे off-by-default विकल्प जो software को अधिकांश users की अपेक्षा के अनुसार behave करने देते हैं, बिना किसी स्पष्ट नुकसान के।
• तनाव इनके बीच है:
  • बेहतर defaults और messages के साथ नए/आम users के लिए UX सुधारना।
  • मौजूदा या power users के workflows को न तोड़ना, और implementation को अनावश्यक रूप से जटिल न बनाना।
• कई टिप्पणियाँ अधिक empathy, यह स्पष्ट बताने की मांग करती हैं कि निर्णय “क्यों” लिए गए, और CLIs तथा APIs के interaction design पर बेहतर ध्यान देने की।