प्रोग्रामर और सॉफ़्टवेयर डेवलपर टूल्स के नामकरण में रास्ता भटक गए हैं

• आधुनिक software development culture में प्रोजेक्ट्स और लाइब्रेरीज़ के नाम उनके फ़ंक्शन से असंबंधित मनमाने शब्दों से भरे जा रहे हैं
• पहले grep, awk, sed, FORTRAN, COBOL जैसे नाम सीधे उनके फ़ंक्शन या उद्देश्य को समझाते थे, लेकिन अब अर्थहीन नामों की भरमार है
• यह प्रवृत्ति GitHub और startup culture के फैलाव के साथ तेज़ हुई, जिससे नाम और फ़ंक्शन का संबंध लगभग पूरी तरह टूट गया
• समझने की लागत और cognitive burden बढ़ जाता है, और डेवलपर्स को हर टूल की भूमिका समझने के लिए बार-बार अनावश्यक खोज करनी पड़ती है
• लेख स्पष्ट और फ़ंक्शन-केंद्रित naming rules की बहाली की मांग करता है और ज़ोर देता है कि तकनीकी टूल्स में branding से अधिक स्पष्टता और पेशेवरिता को प्राथमिकता मिलनी चाहिए

---

सॉफ़्टवेयर naming practices में बदलाव

• Richard Stallman ने 2022 के EmacsConf व्याख्यान में “याद रखने में आसान नाम” के महत्व का उल्लेख करते हुए ज़ोर दिया कि पैकेज का नाम यह दिखाना चाहिए कि वह क्या करता है
  • Emacs ecosystem ने परंपरागत रूप से dired(directory editor), eshell(Emacs shell) जैसे फ़ंक्शन-आधारित naming practices को बनाए रखा है
• लेकिन आधुनिक डेवलपर्स टूल्स को random nouns, पौराणिक जीवों, काल्पनिक पात्रों जैसे नाम देने की प्रवृत्ति दिखाते हैं
  • अन्य तकनीकी क्षेत्रों में इसे पेशेवरिता की कमी माना जाता

अर्थहीन नामों की समस्या

• उदाहरण के तौर पर “Viper”, “Cobra”, “Melody”, “Casbin”, “Asynq” जैसे टूल नामों से उनके फ़ंक्शन का कोई अनुमान नहीं लगाया जा सकता
  • लेखक बताते हैं कि उन्हें एक दोस्त की infrastructure explanation समझने के लिए search तक करनी पड़ी थी
• अन्य engineering क्षेत्रों में नाम संरचना या फ़ंक्शन को समझाते हैं
  • उदाहरण: Golden Gate Bridge, Hoover Dam, I-beam, butterfly valve आदि में उनका रूप या भूमिका स्पष्ट दिखती है
• chemistry में IUPAC nomenclature की तरह, नाम इस तरह तय किए जाते हैं कि वे ठीक एक ही वस्तु की ओर संकेत करें
  • उदाहरण: 2,2,4-trimethylpentane सिर्फ़ एक ही molecule को दर्शाता है, उसे मनमाने ढंग से “Steve” नहीं कहा जाता

पुराने naming rules और आज का विच्छेद

• 1980 के दशक में grep, awk, sed, cat, diff जैसे फ़ंक्शन-आधारित संक्षेप मुख्यधारा में थे
  • FORTRAN, COBOL, BASIC, SQL, Lisp जैसी programming languages के नाम भी उनके उद्देश्य को दर्शाते थे
• 2010 के बाद अर्थहीन नामों का फैलाव शुरू हुआ
  • MongoDB जैसे कुछ नामों का फ़ंक्शन और व्युत्पत्ति से कुछ संबंध था, लेकिन बाद में GitHub और startup culture के बीच निरर्थक नामों में तेज़ वृद्धि हुई
  • Google जैसे brand-centric success cases की नकल करने की प्रवृत्ति को इसका कारण बताया गया है

cognitive cost और development efficiency में गिरावट

• libsodium जैसे नामों से फ़ंक्शन का अनुमान लगाना मुश्किल होता है, और डेवलपर को बार-बार context switching करना पड़ता है
  • “sodium क्यों?” समझने में अनावश्यक समय खर्च होता है
• जितनी अधिक project dependencies हों, यह cognitive tax उतना ही जमा होता जाता है
  • इससे डेवलपर productivity में गिरावट आती है
• लेखक का कहना है कि “Viper, Cobra, Melody…” जैसे वाक्यों को समझते समय अर्थहीन tokens की व्याख्या में मानसिक संसाधन व्यर्थ होते हैं

आम तर्क और उनके जवाब

• “याद रखने में आसान नाम marketing के लिए बेहतर होते हैं” → डेवलपर टूल्स consumer products नहीं हैं, इसलिए फ़ंक्शन की स्पष्टता अधिक महत्वपूर्ण है
• “वर्णनात्मक नाम उबाऊ होते हैं” → उबाऊपन स्पष्टता की कीमत के रूप में स्वीकार्य है, surgical instruments भी उबाऊ होते हैं लेकिन सटीक होते हैं
• “यह मज़े के लिए किया जाता है” → उस ‘मज़े’ की कीमत हर उपयोगकर्ता चुकाता है, और इससे पूरे उद्योग का समय बर्बाद होता है
• “अच्छे नाम पहले ही इस्तेमाल हो चुके हैं” → namespace, prefix, compound words आदि से इसका समाधान संभव है, और कम से कम फ़ंक्शन से जुड़े नाम चुनने चाहिए

आगे की दिशा

• समस्या को दुर्भावना से अधिक सांस्कृतिक बदलाव का परिणाम बताया गया है
  • programming के enterprise-centric माहौल से community-centric माहौल की ओर जाने पर social norms कमज़ोर हुए
• समाधान है naming rules की सांस्कृतिक बहाली
  • regulation से अधिक पेशेवरिता की पुनर्बहाली, शिक्षा और social pressure के ज़रिए सुधार की ज़रूरत है
• लाइब्रेरी के नाम उसके फ़ंक्शन को दर्शाने चाहिए, और ज़रूरत पड़े तो compound words और लंबे expressions भी स्वीकार्य होने चाहिए
  • उदाहरण: “http-request-validator” , “zephyr” की तुलना में कहीं अधिक स्पष्ट है
• mascot और नाम को अलग रखना चाहिए
  • उदाहरण: PostgreSQL Slonik नाम के elephant mascot का उपयोग करता है, लेकिन उसका नाम स्वयं functional meaning बनाए रखता है
• अगर वह branding-प्रधान consumer product नहीं है, तो स्पष्टता और पेशेवरिता को प्राथमिकता देनी चाहिए
  • “अपना पसंदीदा anime character का नाम” देने से पहले यह पूछना चाहिए: “क्या कोई civil engineer किसी bridge system को ऐसा नाम देगा?”
• निष्कर्षतः, निरर्थक नामों की बाढ़ को रोककर स्पष्ट पेशेवर भाषा की ओर लौटना चाहिए
  • स्पष्टता उबाऊपन नहीं, बल्कि उपयोगकर्ता के समय और cognitive resources के प्रति सम्मान है

[roxie]

अगर उदाहरण नहीं लिखा होता, तो शायद मनाने की ताकत 10% बढ़ जाती..

[kandk]

मैं कुछ हद तक सहमत हूँ, लेकिन लगता है कि वे naming के stress से बचना चाहते हैं।

[qpolsa95]

काम का नाम तो पहले ही कोई न कोई इस्तेमाल कर रहा है।

[GN⁺]

Hacker News की रायें

• Yacc के GNU वर्ज़न को Bison कहा जाता है। Pine, “Pine Is Not Elm” का संक्षिप्त रूप था, और UNIX, MULTICS पर एक शब्द-खेल के रूप में UNICS से आया। dd का क्या मतलब है, यह पता नहीं, nano, pico की एक क्लोन कॉपी है, और Postfix, ‘post’ और ‘bug fix’ को मिलाकर बना है। C++ , C का incremented version है, और C, B का उत्तराधिकारी है, जबकि B, BCPL का उत्तराधिकारी है। सच तो यह है कि डेवलपर्स ने ‘नामकरण का दर्शन’ खोया नहीं है — वह शुरू से था ही नहीं। उलटे, मुझे लगता है कि Clang, LLDB, jq, fzf, loc जैसे आधुनिक प्रोजेक्ट अच्छे नामों के उदाहरण हैं। mise-en-place, mise की functionality का बिल्कुल सटीक रूपक है

  • dd, JCL के DD statement से आया है। मूल रूप से यह IBM mainframe की file description पद्धति से लिया गया था, और UNIX का dd command mainframe और files के बीच आदान-प्रदान के लिए बनाया गया था। इसलिए इसमें UNIX जैसा न होकर key=value शैली का syntax है
  • dd को परंपरागत रूप से मज़ाक में “delete disk” या “destroy data” भी कहा जाता था। क्योंकि इसे अक्सर disk blocks को overwrite करने के लिए इस्तेमाल किया जाता था
  • C++ , C के post-increment operator को दर्शाता है। यानी इसका अर्थ है कि इसका मान C जैसा ही है, लेकिन पढ़े जाने के बाद बढ़ता है — यह एकदम सटीक रूपक है
  • GNU और Emacs भी recursive acronyms हैं। Perl, Python, Java, Go, Pascal, Git, Mercurial, CVS आदि नामों के अर्थ भी अलग-अलग तरह के हैं। आख़िरकार, नामों पर बहस मुझे ज़्यादा मायने न रखने वाला शोर लगती है
  • Back Orifice 2000 को देखकर नाम से ही साफ़ समझ आता था कि यह क्या करता है, लेकिन BitchX के साथ ऐसा नहीं था

• grep, awk, sed, cat, diff जैसे UNIX commands के नाम functional या व्यवस्थित थे, लेकिन सच कहें तो diff को छोड़कर शायद ही कोई नाम सहज अनुमान से समझ आता है। awk को अच्छा नाम कहना बढ़ा-चढ़ाकर कहना है

  • ऐसे नाम हमें स्वाभाविक इसलिए लगते हैं क्योंकि यह बस परिचय का भ्रम है। आज utilities और libraries की संख्या बहुत ज़्यादा है, इसलिए नामों में अलग पहचान ज़रूरी है
  • Libiberty सबसे मज़ेदार नामों में से एक था। इसे ऐसा नाम इसलिए दिया गया ताकि -liberty option से link किया जा सके
  • cat, concatenate का छोटा रूप नहीं है, बल्कि catenate से आया है। ‘con’ prefix दोहराव वाला था, इसलिए उसे हटा दिया गया। भाषाविज्ञान की दृष्टि से भी यह दिलचस्प उदाहरण है
  • awk, sed, cat अच्छे नाम नहीं, बल्कि परिचित नाम हैं। grep उलटे एक onomatopoeia जैसा लगता है, जैसे यह patterns को ‘पकड़’ रहा हो
  • ऐसे acronyms या abbreviations, उद्योग-विशेष jargon की तरह होते हैं; एक बार सीख लेने पर स्वाभाविक लगने लगते हैं। पहले typing efficiency ज़्यादा महत्वपूर्ण थी, इसलिए cat बनाम concat जैसा फ़र्क productivity को प्रभावित करता था

• “तकनीकी क्षेत्र में ऐसा नामकरण career suicide है” — इस दावे से असहमति है। अमेरिकी रक्षा विभाग के code names की सूची देखें तो वहाँ उलटे जान-बूझकर अपारदर्शी नाम बहुत मिलते हैं। Hoover Dam को भी शुरुआत में Boulder Canyon Project कहा जाता था, और नाम उसका function नहीं बताता था। क्या Requests से Reitzlib बेहतर नाम होता? आख़िरकार, नाम संदर्भ पर निर्भर करता है

  • chemistry में भी मज़ेदार नाम बहुत हैं। जैसे SHAKE, RATTLE, CHARMm, Amber जैसे algorithms या packages
  • meteorology भी इसका अपवाद नहीं है। STEVE नाम की aurora घटना इसका उदाहरण है
  • military code names को अक्सर जान-बूझकर random रखा जाता है ताकि अर्थ छिपा रहे। कंपनियों के internal projects में भी कभी-कभी यही तरीका अपनाया जाता है
  • biology में भी Sonic hedgehog protein जैसे नाम मिलते हैं
  • astronomy तो खासकर भयंकर acronym names के लिए मशहूर है। उदाहरण इस लिंक में देखे जा सकते हैं

• awk जैसा नाम वास्तव में अच्छा नाम नहीं है। यह बस लेखकों के initials हैं, और function के बारे में कुछ नहीं बताता। आजकल tab auto-completion है, इसलिए हर चीज़ को छोटा करने की ज़रूरत भी नहीं

• मैं इस प्रत्युत्तर लेख से सहमत हूँ। बाहरी identifiers का अर्थ समय के साथ बदल जाता है, इसलिए शुरू से बहुत सटीक descriptive नाम लंबे समय तक टिकते नहीं। ऊपर से “X Manager”, “X Service” जैसे नाम इतने ज़्यादा हैं कि उनमें फर्क करना मुश्किल हो जाता है

  • मुझे चतुर नाम पसंद हैं। अगर नाम रखना मुश्किल हो रहा है, तो यह संकेत हो सकता है कि concept अभी साफ़ नहीं है। आदर्श नाम वह है जो पहले थोड़ा अजीब लगे, लेकिन बाद में उसका अर्थ समझ आने पर याद रह जाए। Spotify की A/B testing टीम ने खुद को “ABBA” कहा — यह उसका बेहतरीन उदाहरण है
  • बेशक यह लक्ष्य पर निर्भर करता है। लेकिन एक काम पर फ़ोकस करना, और उसी को नाम में समेटना भी एक अच्छा सिद्धांत है

• मैं एक auto OEM में engine calibration engineer के रूप में काम करता था, और वहाँ हर variable और function संक्षेपों में था। पहले महीने तो दिमाग़ फटने जैसा लगता था। आख़िर में एक सहकर्मी ने कहा, “यह एक नई भाषा सीखने जैसा है,” और सचमुच वैसा ही था। यानी तकनीकी नामों की अधिकता से cognitive load कम नहीं होता

  • mobile communications में भी यही हाल है। सारे acronyms याद करने बैठो तो उसका अंत नहीं। जैसे AP का मतलब context के अनुसार Application Processor भी हो सकता है और Access Point भी। फिर भी MSISDN से छोटा है, इसलिए इस्तेमाल करना पड़ता है
  • लंदन टैक्सी qualification exam का यह वीडियो दिखाता है कि ऐसी learning fatigue इतनी गहरी होती है कि इंसान के दिमाग़ की संरचना तक बदल सकती है। जटिल नामकरण प्रणालियाँ अपने आप में संज्ञानात्मक बोझ पैदा करती हैं

• “functional names marketing से बेहतर हैं” — इस दावे से सहमत होना कठिन है। function-आधारित नाम आख़िरकार संक्षेपों का अंतहीन समुद्र बना देते हैं। फिर ABDC और ADBC जैसे नामों में भ्रम होने लगता है

  • मैं भी ऐसे संगठन में काम कर चुका हूँ, जहाँ आखिर में CoreMainHttp और MainHttpCore जैसे नाम बन जाते हैं, और यहाँ तक कि एक ही नाम वाले अलग-अलग API भी साथ मौजूद रहते हैं। “DataOrgUtils” जैसे नामों में तो ख़त्म हो चुकी organizations के नाम भी टिके रहते हैं। अंत में cute names भी दोहराव पर आकर टिक जाते हैं। Phoenix, Keymaster, Simpsons, Star Wars जैसे cultural memes बार-बार लौटते हैं
  • लेखक इस बात को नज़रअंदाज़ करता है कि tools प्रतिस्पर्धा से गुजरकर बचे हैं। याद रह जाने वाले नाम उनके survival में मददगार रहे

• HN पर ऐसा लेख आना दिलचस्प है। awk जैसे नामों का उदाहरण देकर यह कहना कि “हम नामकरण का सार खो चुके हैं” अपने आप में विरोधाभास है। आख़िरकार, यह बस cute names के प्रति निजी चिढ़ जैसा लगता है। वैसे, यह टिप्पणी Firefox में लिखी गई है — सिर्फ़ नाम देखकर यह पता नहीं चलता कि यह web browser है

  • awk जैसे नामों का अपने समय में कुछ मतलब था। आधुनिक software को अब कहीं व्यापक user base को ध्यान में रखना पड़ता है, इसलिए विशेषज्ञता और मज़े के बीच संतुलन ज़रूरी है। मुझे cute names से दिक्कत नहीं, लेकिन professional context में सावधानी ज़रूर चाहिए। (यह टिप्पणी msmtp से भेजी गई है — नाम के अनुसार यह एक SMTP client है)

• “descriptive names उबाऊ होते हैं” — इस दावे के जवाब में, operating room के tools भी असल में लोगों के नामों पर रखे गए हैं। Adson, Allis, Babcock, Kocher जैसे नाम function के बारे में कुछ नहीं बताते। आखिरकार, परिचित होने पर ही अर्थ बनता है। awk उतना अच्छा नहीं, लेकिन diff ठीक उदाहरण है

  • जिसने कभी अपने शरीर में Kirchner pin लगवाई हो, वह इस बात से सहमत होगा

• “हमारा क्षेत्र random nouns के zoo जैसा है” — इस दावे पर, मुझे मज़ेदार नाम पसंद हैं। मेरा प्रोजेक्ट Wimsey एक data testing library है, लेकिन नाम से यह पता नहीं चलता। फिर भी Python, Cron, Zellij जैसे प्यार और ह्यूमर से भरे नाम अच्छे लगते हैं। तकनीक आखिर इंसान बनाते हैं, और उसमें आनंद होना चाहिए। “brown-dog-2” से “cookie” ज़्यादा मानवीय लगता है

  • लेकिन “data-testing-library” जैसा नाम दूसरी ऐसी चीज़ आते ही अपना अर्थ खो देता है
  • .NET में Project.Parser.Pcapng जैसे संरचित नाम प्रोजेक्ट के अंदर तो अच्छे हैं, लेकिन स्वतंत्र संदर्भ में बेकार हैं
  • दूसरी ओर, कुछ लोग पेशेवर गंभीरता में ही आनंद महसूस करते हैं, और cute names को भटकाने वाला मानते हैं। उनके लिए craftsmanship से मिलने वाली संतुष्टि ही असली आनंद है

[epdlemflaj]

Awk भी फ़ंक्शन-आधारित नाम कहने लायक तो नहीं है....

[khris]

क्या किसी को पता है कि emacs का मतलब क्या है? मतलब तो है, लेकिन ऐसे acronym वाले नाम एक नज़र में समझ भी नहीं आते, और आखिरकार यह एक नाम ही है… और अब सिर्फ़ फ़ंक्शन के आधार पर नाम रखने के लिए प्रोजेक्ट्स की संख्या भी बहुत ज़्यादा हो चुकी है।

[cgl00]

GitHub को दोष देते देखो तो यह बस RMS-स्टाइल की बेवजह की आलोचना लगती है lol