Jeffrey Snover की PowerShell डेवलपमेंट कहानी

 (corecursive.com)
1 पॉइंट द्वारा GN⁺ 2024-07-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Jeffrey Snover ने Windows को command line से manage किए जा सकने वाले server OS में बदलने के लिए PowerShell को आगे बढ़ाया, और इसके लिए उन्हें GUI-केंद्रित Microsoft culture तथा organizational resistance को पार करना पड़ा
  • शुरुआत में UNIX tools को port करने की कोशिश हुई, लेकिन Windows की संरचना file से ज़्यादा Registry, Active Directory, WMI जैसे API पर निर्भर थी, इसलिए इससे server management की समस्या हल नहीं हुई
  • WMIC में WMI-आधारित 70 commands बनाने के बाद, testing bottleneck और cost issues कम करने के लिए दिशा metadata-आधारित command generation engine की ओर मोड़ी गई
  • PowerShell का पूर्वरूप Monad .NET और Longhorn की लहर के साथ शुरू हुआ, लेकिन Longhorn reset के बाद Windows से बाहर धकेल दिया गया; बाद में Exchange team और Windows Server organization के support से फिर जीवित हुआ
  • Snover ने पद और compensation में नुकसान सहने का जोखिम उठाकर PowerShell 1~4 पर ध्यान केंद्रित किया, और यह tool Windows management automation तथा Office के cloud transition की नींव बना

GUI-केंद्रित Windows और datacenter management की समस्या

  • PowerShell Windows system management को बदलने वाला command tool था, लेकिन Microsoft के भीतर यह शुरू से ही स्वाभाविक रूप से स्वीकार किया गया project नहीं था
  • उस समय Microsoft culture GUI-केंद्रित था, और Bill Gates के इस किस्से तक का ज़िक्र मिलता है कि वे command.exe को आखिरी बार देखने वाले होंगे, यानी command line interface को पुरानी चीज़ माना जाता था
  • Snover के Microsoft में शामिल होने का शुरुआती कारण यह समझ था कि Windows NT-आधारित OS को datacenter और enterprise market के लिए बदलना ज़रूरी है
    • लक्ष्य Sun, IBM, HP जैसे UNIX vendors से प्रतिस्पर्धा करना था
    • Intel और open hardware ecosystem की वजह से cost advantage था, लेकिन server management software पर्याप्त अच्छा नहीं था

system integrators पर निर्भरता घटाने वाला admin model

  • Windows server management में कई servers को clicks से configure करना पड़ता था, और हर enterprise की ज़रूरत अलग होने से system integrators पर निर्भरता बढ़ सकती थी
  • Snover का मानना था कि अगर integrators की cost बढ़ी, तो Windows का price advantage खत्म हो जाएगा
    • उदाहरण के तौर पर उन्होंने hardware 10, software 2, system integrator 40 वाली cost structure बताई
    • यह भी समस्या थी कि customer relationship और value integrators की ओर खिसक जाते थे
  • इसका विकल्प UNIX-शैली का programmer administrator model था
    • यानी छोटे tools को जोड़कर unique problems हल करना और automation करना
    • Windows को भी सिर्फ “Next” button दबाने वाले admins नहीं, बल्कि scripting और automation संभालने वाली expert admin layer की ज़रूरत थी

UNIX tools का port सही समाधान क्यों नहीं था

  • शुरुआती समाधान Windows Services for Unix के जरिए Windows पर UNIX shell और AWK/GREP/SED जैसे tools लाना था
  • लेकिन Windows की management structure UNIX से अलग थी
    • UNIX एक file-केंद्रित OS है, इसलिए files को manipulate करके और process restart करके कई management tasks संभाले जा सकते हैं
    • Windows में Registry, Active Directory, WMI जैसी API के पीछे functionality होती थी
    • AWK सीधे Registry पर, SED सीधे Active Directory पर, और GREP सीधे WMI पर फिट नहीं बैठते थे
  • WMI में management tasks के लिए संभावना थी, लेकिन उसका व्यापक उपयोग नहीं था; Snover की team ने WMI objects को संभालने वाला command line tool बनाने की कोशिश की

WMIC और metadata-आधारित engine

  • Windows XP के समय सिर्फ 10 हफ्तों की coding window में WMI-आधारित command line interface बनाना था
  • contract engineers की मदद से 70 tasks implement किए गए, लेकिन यह Windows server के पूरे management के लिए बहुत कम थे
  • Microsoft के भीतर structure ऐसा था कि testing organization की approval के बिना कोई feature release नहीं हो सकता था, और commands बढ़ने के साथ testing bottleneck भी बढ़ता गया
  • Snover ने HTML और browser के रिश्ते की तरह, individual commands को code नहीं बल्कि metadata मानकर सिर्फ common engine को test करने का तरीका आगे बढ़ाया
    • engine commands generate करता, और हर command की settings XML जैसी metadata format में व्यक्त की जातीं
    • उन्होंने Christmas holiday के दौरान metadata लिखकर 72 commands बना दिए
    • उनकी याद के अनुसार, पहले के 70 commands पर लगभग 4 million dollars लगे थे, जबकि engine पर लगभग 60 thousand dollars लगे
  • जब engine में filtering और formatting जैसी capabilities जोड़ी गईं, तो सभी commands साथ में बेहतर हो गए; यह PowerShell architecture का एक अहम पूर्वसंकेत था

Longhorn, .NET, Monad

  • Bill Gates ने देखा कि Windows 98 users आसानी से XP पर migrate नहीं हो रहे थे, इसलिए वे Longhorn को नए Windows 95 जैसा turning point बनाना चाहते थे
    • Longhorn में .NET-आधारित development model, WPF, WCF, और नया storage model शामिल होने वाला था
  • Snover ने सोचा कि .NET Windows management की reach बढ़ाने का साधन बन सकता है
    • WMI providers लिखवाने की कोशिश को पर्याप्त गति नहीं मिली, लेकिन Bill Gates .NET adoption को बहुत ज़ोर से आगे बढ़ा रहे थे
    • उन्हें लगा कि अगर management utilities को .NET पर बनाया जाए तो ज्यादा broad coverage मिलेगी
  • जब दूसरी organization ने K-shell port करके shell बनाने की कोशिश की, तो Snover ने बेहतर approach समझाई, लेकिन वे उन्हें मना नहीं पाए
  • इसके बाद वे खुद कमरे में बंद होकर लगभग 10,000 lines का prototype बनाने लगे, जिसमें PowerShell के core architectural principles शामिल थे
    • demo के बाद उस team ने यह idea स्वीकार कर लिया, और Snover को लगा कि शायद यही उनका सबसे अच्छा idea है
    • इस project से जुड़ने के लिए उन्होंने सैकड़ों से लेकर हजार लोगों वाले product/service के chief architect की भूमिका छोड़ी, यानी उन्होंने लगभग demotion स्वीकार किया

Monad Manifesto और team persuasion

  • नई team ने project का नाम Monad रखा, और manpower की कमी के कारण कुछ काम India में outsource किया गया
  • Snover ने project vision और success path को align करने के लिए Monad Manifesto लिखा
    • इसमें problem, existing approaches, new approach, value और differentiation को व्यवस्थित किया गया
    • admin, provider, dev team जैसे stakeholders के लिए क्या value है, यह साफ़ बताया गया
  • Microsoft की हर team के पास पहले से बहुत काम था; command line interface न बनाने पर किसी की नौकरी नहीं जाती थी, और बना देने पर भी promotion की गारंटी नहीं थी
  • Monad का प्रस्ताव यह था कि हर product team सिर्फ अपने objects को manipulate करने वाला code लिखे, बाकी सब PowerShell संभाले
    • formatting, sorting, filtering, parser, remote execution, privilege elevation आदि PowerShell उपलब्ध कराए
    • हर team को सिर्फ यह बताना हो कि उसके domain objects को कैसे manipulate किया जाए
  • Active Directory team ने कुछ हफ्तों का निवेश करके कुछ cmdlets बनाए, और user group की मजबूत प्रतिक्रिया मिलने पर उन्होंने काम आगे बढ़ाया

Longhorn reset के बाद Windows में वापसी

  • Longhorn में .NET adoption को जरूरत से ज्यादा aggressively push किया गया, जिससे समस्याएँ बढ़ीं
    • उदाहरण के लिए Notepad का Save As dialog .NET/WCF-आधारित common dialog की वजह से 1 minute 30 seconds बाद खुलता था, और working set 15KB से 15MB तक बढ़ जाता था
    • यह भी याद किया गया कि nightly builds लगभग 7 महीनों तक काम नहीं कर रही थीं
  • Windows organization ने reset करते समय .NET code को Windows से बाहर निकाला, और PowerShell भी Windows के बाहर धकेल दिया गया
  • इसके बाद PowerShell पर बार-बार cancel किए जाने का दबाव आया, क्योंकि वह command line interface भी था और .NET-आधारित भी
    • Bill Gates इसकी value समझते थे, लेकिन रोज़मर्रा की internal defense में यह काफी नहीं था
    • Windows Server के प्रमुख ने महत्वपूर्ण मौकों पर support दिया
    • Exchange team ने PowerShell पर निर्भर “multi-billion-dollar business” का तर्क देकर इसे cancel होने से बचाने में भूमिका निभाई
  • Windows में .NET डालने के लिए WinArch requirements बहुत सख्त थीं, लेकिन PowerShell team ने सभी शर्तें पूरी करने की तैयारी की
  • जब Windows leadership ने request वापस लेने को कहा, तो program manager ने औपचारिक rejection की मांग की, जिसके परिणामस्वरूप review process शुरू हुई
    • Windows Server organization के पास यह authority थी, और उसने माना कि PowerShell requirements पूरी करता है, इसलिए इसे फिर Windows में शामिल किया गया

PowerShell 1~4 और वास्तविक प्रभाव

  • PowerShell 1 को Windows Vista के हिस्से के रूप में release किया गया
  • release के बाद Snover को दूसरा काम करने की सलाह और career downside की चेतावनी दी गई, लेकिन उन्होंने PowerShell 2, 3, 4 तक उसी vision पर ध्यान बनाए रखा
    • उनके अनुसार version 1 कुछ लक्ष्यों तक पहुँचा, version 2 और 3 में capabilities पूरी हुईं, और version 4 तक vision लगभग पूरा हो गया
  • PowerShell ने Windows admins को scripts लिखने और complex tasks automate करने में सक्षम बनाया
    • user groups, online Q&A, script sharing, और conference talks उभरे
    • कुछ admins PowerShell experience के आधार पर professional speakers भी बने
  • लगभग 5 साल बाद Snover Distinguished Engineer बने, और बाद में Technical Fellow बने
  • Office leadership ने कहा कि PowerShell के बिना Office का cloud transition मुश्किल होता, और Office का cloud transition आगे Azure के cloud transition को भी प्रभावित करता
    • पहले server provisioning click-based काम था, इसलिए उसे बार-बार दोहराना या ठीक करना कठिन था
    • scripts की वजह से scale करना संभव हुआ, और समस्या आने पर script बदलकर प्रतिक्रिया दी जा सकती थी

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-07-05
Hacker News की राय

  • संचालक के नज़रिए से देखें तो PowerShell को Microsoft के अंदर बेहद कड़े विरोध का सामना करना पड़ा था, और इसे बनाने वाले Jeffrey Snover को इसे आगे बढ़ाने के कारण पदावनत तक कर दिया गया था
    Jeffrey को मूल रूप से Microsoft को यह सीखने में मदद करने के लिए लाया गया था कि datacenter में प्रतिस्पर्धा कैसे की जाए, लेकिन उस समय की संस्कृति personal computer-केंद्रित विश्वदृष्टि से इतनी बंधी हुई थी कि हर कदम पर उन्हें विरोध झेलना पड़ा
    एक और दिलचस्प बात यह है कि PowerShell इसलिए बना क्योंकि Windows file-based नहीं था। Jeffrey का लक्ष्य server administration था, लेकिन Windows में सिर्फ configuration files edit करके management नहीं किया जा सकता था; कई API call करके structured data भेजना-लेना पड़ता था, इसलिए समृद्ध object model व्यावहारिक रूप से एकमात्र तरीका था
    transcript को professional transcription, फिर Descript, GPT-4 से punctuation cleanup, और अंत में खुद सरसरी जांच के क्रम में बनाया गया था, इसलिए quality उम्मीद जितनी ऊंची न भी हो सकती है

    • अगर MS-PWSH team इसे देखे, तो अच्छा होगा कि वे बुनियादी GUI functionality जोड़ें, ताकि बहुत सारा .NET code खुद न लिखना पड़े
      PowerShell पसंद आने की वजह यह है कि यह एक सरल dynamic language है और इस्तेमाल में आसान commands को pipe करके जोड़ सकता है, इसलिए simple user interface और charts बनाने के लिए cmdlets का नया set अच्छा रहेगा
      उदाहरण के लिए Create-Chart -Type "Bar" -XAxis $Cities -YAxis $GDP -OutputFile "C:/Documents/ProjectAnalysis/CitiesBarGraph.png" जैसी functionality Microsoft के लिए product में डालना आसान लगता है, और यह boilerplate code का एक ऐसा page हटा सकती है जिसे लोग ठीक से समझते भी नहीं
      ऐसे users लाखों में होंगे जिन्हें basic programming आती है, लेकिन Java या C# जैसे tools उनके काम के हिसाब से सही नहीं बैठते। Python आम तौर पर अच्छा fit होता है, लेकिन चाहेंगे कि Microsoft server admins या IT staff ही नहीं, बल्कि सामान्य office users के लिए भी कुछ और बनाए
      अगर PowerShell को file parsing जैसे कामों में slow न रहने देने के लिए और investment की जाए, और ऊपर बताई functionality या statistics/scientific cmdlets भी जोड़े जाएं, तो यह आम business analyst के लिए काम सुधारने वाला software या dev team को देने लायक prototype जल्दी बनाने का काफी शानदार tool बन सकता है
      Microsoft शायद options को तीन हिस्सों में देखता है: C# इस्तेमाल करने वाले full-fledged software developers, PowerShell इस्तेमाल करने वाला IT काम, और business users के लिए Excel। Excel कई मायनों में बेहतरीन है, लेकिन काफी limited भी है, और VBA+Excel उन ecosystems में से है जो मैंने देखे हैं उनमें सबसे ज्यादा सीमित है। Python, R जैसी third-party languages चौथा option जरूर हैं, लेकिन अच्छा होगा कि Microsoft इस क्षेत्र में और समय लगाए
    • GitHub पर MVPs को यह शिकायत करते देखकर कि Microsoft ने जिस अतिरिक्त investment का वादा किया था वह साकार नहीं हुआ, changes merge नहीं हुए, और अच्छे features उपेक्षित पड़े हैं, लगता है कि अब यह MSFT की priority नहीं रहा
      PowerShell की अजीब कमियों समेत मुझे यह पसंद था, लेकिन अब मैं इसे छोड़ चुका हूं
    • उत्सुकता है कि Python या किसी मिलते-जुलते मौजूदा tool के बजाय इसे शुरुआत से नया क्यों बनाया गया
    • transcript पढ़ने की कोशिश की, लेकिन अंत तक नहीं पहुंच पाया; पढ़ना थोड़ा मुश्किल लगा
      पढ़ते समय अंदाजा हुआ कि यह machine-generated है, लेकिन ठीक-ठीक क्यों ऐसा लगा कहना मुश्किल है, और इसे ज्यादा readable बनाने के लिए थोड़ी editing की जरूरत लगती है
      फिर भी transcript न होने से यह कहीं बेहतर है

  • लंबे समय से Bash इस्तेमाल करने वाले developer के तौर पर, जब PowerShell आया था तो मैं सचमुच उत्साहित था
    लगा था कि आखिरकार Windows पर भी development के लिए एक शानदार shell इस्तेमाल कर पाऊंगा, लेकिन बाद में भी PowerShell को ठीक से अपना नहीं पाया और Windows पर भी वही जाना-पहचाना Bash इस्तेमाल करता रहा
    उत्सुकता है कि दोनों shells में माहिर developers इनकी तुलना कैसे करते हैं। जानना चाहता हूं कि क्या PowerShell ने सच में ज्यादा efficient और modern shell होने का अपना वादा पूरा किया, या लोग इसे इसलिए इस्तेमाल करते हैं क्योंकि यह default install होता है और CMD से बेहतर है

    • मैंने Bash काफी इस्तेमाल किया है और कुछ किताबें भी पढ़ी हैं, लेकिन मेरा पक्का मानना है कि complex Bash scripts नहीं लिखनी चाहिए
      लगभग 50 lines से ऊपर जाए तो मैं उसे code smell मानता हूं, और जब किसी को समझाना पड़े तो काम आए इसलिए यह page save करके रखा है: http://mywiki.wooledge.org/BashPitfalls
      हाल में PowerShell इस्तेमाल करके देखा तो commands text नहीं बल्कि objects return करती हैं, इसलिए text को जबरदस्ती manipulate करने की जरूरत नहीं पड़ती—यह बात scripting language और command-line language, दोनों के रूप में इसे कहीं आसान बनाती है
      argument parsing संभालने का official तरीका होना भी शानदार है। सब कुछ unified है और command-line window में लगभग हर option autocomplete हो सकता है, जो Bash में सपने जैसा है, इसलिए productivity बहुत बढ़ जाती है
      हालांकि type conversion ऐसे नए bugs भी पैदा कर देता है जो Bash में नहीं थे। अभी मुझे PWSH ज्यादा पसंद है, लेकिन दोनों से कुछ हद तक चिढ़ भी है, और मैं अगले natural evolution का इंतजार कर रहा हूं
    • PowerShell, Bash से ज्यादा verbose है, और 0 या 1 item वाले arrays को अनपेक्षित समय पर scalar में अपने-आप unwrap कर देने जैसी अजीब बातें भी हैं, लेकिन यह ज्यादा productive और readable है
      object orientation pipelines बनाते समय काफी उपयोगी होती है
      उदाहरण के लिए, किसी folder में recursively file size के आधार पर groups बनाकर duplicate candidates ढूंढने हों तो Get-ChildItem -File -Recurse | Group-Object -Property Length | Where-Object { $_.Count -gt 1 } | Sort-Object -Property Count जैसा लिख सकते हैं
      किसी उलझे हुए file incantation को याद रखने या text output parse करने की जरूरत नहीं। आपको properties वाले असली objects मिलते हैं, और tab autocomplete उस structure को दिखा सकता है
      JSON parse करना हो तो jq के बिना सीधे Get-Content -Raw whatever.json | ConvertFrom-Json से काम हो जाता है। XML को CSV में बदलना हो तो ConvertFrom-Xml या Select-Xml के बाद जरूरी काम करके ConvertTo-Csv इस्तेमाल कर सकते हैं
      Get-ChildItem बहुत लंबा लगे तो gci, dir, ls इस्तेमाल करें, और Where-Object लंबा लगे तो where या ? इस्तेमाल करें। default रूप से यह case-sensitive भी नहीं है
    • मैंने अपना career SunOS pizza box के X terminal से शुरू किया था, हजारों scripts लिखीं, जिनमें से काफी हजारों lines की थीं
      कुछ साल पहले PowerShell में एक complex, unattended और robust data transfer system लिखना पड़ा, और अनुभव इतना अच्छा रहा कि मैंने macOS और Linux के shells भी PWSH में बदल दिए
      सबसे अच्छी बात objects को pipeline से pass करने की ताकत थी। पहले filter में object की कुछ properties extract और manipulate करने के बाद भी, pipeline के आगे के filters में दूसरी properties और पहले filter द्वारा बनाई गई object properties तक पहुंच बनी रहती थी
      commands, error handling और object properties की consistency भी बहुत अच्छी थी
      बाद में काम का स्वरूप बदल गया, तो पुरानी muscle memory लौट आई और मैंने सभी shells फिर से Bash पर वापस कर दिए। उस space में बहुत काम और सोचते समय PWSH shell के तौर पर natural लगता था, लेकिन उससे बाहर आने के बाद PWSH में सोचना Bash पर लौटने से ज्यादा कठिन लगा
      कभी-कभी उसकी याद आती है। shell space में इसके इतना करीब कुछ नहीं है, और कम-से-कम switch करने की मेहनत justify करने लायक कोई करीबी alternative तो नहीं दिखता
    • मैं दोनों में expert नहीं हूं, लेकिन काफी इस्तेमाल किया है, और मुझे लगता है कि PowerShell कुछ traps की वजह से इस्तेमाल में भयानक हो गया
      पहला, इसका .NET language बनने की कोशिश करना। एक runtime और कई languages वाला .NET का वादा Java side में ऐसे वादे के बिना भी क्यों फल-फूल गया, जबकि .NET में मुरझा गया, यह नहीं जानता, लेकिन अगर .NET code लिखना है तो C# लिखना बेहतर लगता है
      दूसरा, इसने shell की basics ठीक से नहीं संभालीं। details अब अतीत में दफन हो चुकी हैं इसलिए याद नहीं, लेकिन redirection handling टूटी हुई थी, और जो चीज Bash में मामूली थी वह PowerShell में लगभग असंभव स्तर की थी। लगा कि developers कुछ नया और powerful बनाने के उत्साह में Bash आदि जिन चीजों में अच्छे थे, उन्हें नजरअंदाज कर गए
      तीसरा, हर name में Verb-Object format मांगने जैसी obsession है। यह subjective है और इसके समर्थक भी होंगे, लेकिन मेरे हिसाब से यह scripts को बदसूरत बनाता है, typing awkward करता है, और discoverability या memorability में असल में कोई सुधार नहीं करता
    • PowerShell मुझे पसंद नहीं है क्योंकि यह Bash से बेहद अलग तरीकों से बार-बार चौंकाता है
      tab की जगह right arrow इस्तेमाल करना भी confusing है, परिचित commands का न होना और naming में कड़े rules होना भी असुविधाजनक है
      फिर भी, अच्छी तरह जानने पर PowerShell, Bash से ज्यादा सक्षम दिखता है। इसमें बेहतर type system है और arguments को संभालना आसान है, जबकि Bash की values लगभग बिना shape वाली strings जैसी हैं
      https://github.com/bionicles/tree_plus/blob/main/tests/more_... Windows machine पर test environment set up करने में इस्तेमाल होने वाला थोड़ा पुराना version है, और यह कुछ हद तक दिखाता है कि क्या संभव है

  • PowerShell को सीधे इस्तेमाल करते समय यह भयानक तो नहीं था, लेकिन यह समझ नहीं आया कि लंबाई 1 वाली array array से unwrap होकर अंदर के type में क्यों बदल जाती है
    इसकी वजह से हर बार यह ध्यान रखना पड़ता था कि array में कितने items आ सकते हैं, और सामान्य तरीके से handle करने के बजाय हर बदलाव पर जांच करनी पड़ती थी, जिससे बहुत बड़े bugs बने। जानना चाहता/चाहती हूं कि क्या किसी को पता है कि ऐसा क्यों किया गया

    • array के आसपास behavior ढीला इसलिए है क्योंकि cmdlet output API भी arrays के मामले में ढीली है
      WriteObject नाम का एक function दिए गए value को cmdlet के output के रूप में लिखता है, और एक बार call करने पर वही output बन जाता है। कई बार call करने पर shell के पास उन सभी values को इकट्ठा करके एक array को output बनाने के अलावा कोई विकल्प नहीं रहता
      इसलिए अगर किसी cmdlet run में WriteObject सिर्फ एक बार call होता है और दूसरे run में दो बार, तो पहले मामले में shell के पास यह जानकारी नहीं हो सकती थी कि उस single output को भी array में wrap करना चाहिए था। लेकिन अगर cmdlet output को हमेशा array में wrap किया जाए, तो Get-Date जैसे cmdlets के लिए बाधा बनेगा जिनका semantic result सिर्फ एक ही होता है
      किसी वजह से ऐसा लगता है कि वे API को इतना जटिल नहीं बनाना चाहते थे कि cmdlet खुद actual WriteObject call count से स्वतंत्र रूप से यह बता सके कि उसका semantic output single है या multiple। ऐसी API cmdlet की static property नहीं हो सकती, क्योंकि output parameters के आधार पर काफी बदल सकता है, और इसे empty array के साथ भी काम करना होगा, इसलिए (Object, bool iMightWriteMoreValues) जैसा WriteObject overload भी मुश्किल है। शायद अलग से IWillWriteMultipleValues() function की जरूरत होती
      यहां भी समझाया गया है: https://news.ycombinator.com/item?id=40874873
    • यह सच में बहुत irritating है। array को force करने के लिए मैंने शुरुआत में comma लगाने वाला comma hack इस्तेमाल करना शुरू किया
      $Ary = @(, "value")
      array बनाते समय, खासकर बड़ी arrays में, यह += से बेहतर performance देता है, इसलिए array को for loop assign करने वाला feature भी काफी अच्छा है। array भरने के तरीके के तौर पर intuitive नहीं था, लेकिन निश्चित रूप से उपयोगी है
      $Ary = foreach ($Obj in $Objs) { @{ foo = $Obj.foo } }
    • यह software के बहुत ज्यादा clever बनने की कोशिश में fail होने का classic example लगता है
      software developers को अपने software को बहुत ज्यादा clever बनाने के temptation से हमेशा सावधान रहना चाहिए
    • यह आधा-अधूरा feature जैसा लगता है
      जो बाकी आधा missing था, वह शायद receiving side के array expect करने पर single value को length-1 array में automatically convert करने की capability होती
    • niche languages में हर बार ऐसी ही अजीब quirks आ जाती हैं, ऐसा लगता है
      Lua जैसी चीज पहले से मौजूद होने के बावजूद उसे वैसे ही इस्तेमाल करने या थोड़ा modify करके सरल, छोटी, elegant और consistent language पाने के बजाय, लोग पहिए को फिर से बनाते हैं और फिर उसे गोल भी नहीं बना पाते—यह Sisyphus जैसी त्रासदी लगती है

  • अगर Windows subsystems के साथ interact करने की जरूरत के कारण कोई specific PowerShell command जरूरी नहीं है, तो मन में आता है, “मैं Python क्यों नहीं इस्तेमाल कर रहा/रही?”
    Bash से किए जाने वाले 90% कामों के लिए यह बहुत verbose और slow है, और उन कामों के लिए भी वैसा ही है जिन्हें किसी और जिंदगी में Perl से किया जाता
    अक्सर सोचता/सोचती हूं कि Microsoft ने इसे Python, Node जैसी चीजों के ऊपर क्यों नहीं बनाया। PowerShell पहली बार कब आया था याद नहीं, इसलिए उस समय क्या ideal होता, यह पक्का नहीं कह सकता/सकती

    • Python का default REPL सच में बहुत खराब है
      साथ ही यह उन console tasks के लिए design नहीं किया गया जिनमें PowerShell अच्छा है। क्योंकि जहां file content लेकर दूसरी command को pass करना काफी होता, वहां file handle manage करने जैसी चीजें खुद करनी पड़ती हैं
      PowerShell अच्छा इसलिए है क्योंकि यह autocomplete वाला शानदार REPL है, अजीब whitespace behavior नहीं है, readline[0] है, और जरूरत पड़ने पर .NET से जो भी किया जा सकता है वह सब कर सकने वाला Swiss Army knife है
      इसके अलावा यह object-oriented है, इसलिए पुराने utilities के text-based output को किसी दूसरे पुराने utility से parse करने का तरीका निकालने के बजाय आप असल काम पर focus कर सकते हैं
      0: https://learn.microsoft.com/en-us/powershell/module/psreadli...
    • मूल रूप से यह loosely Perl और Korn shell पर based था
      Bruce Payette की “Powershell in Action” की पहली edition में एक side note है कि PowerShell Perl जैसा दिखता है क्योंकि यह @ symbol, default variable $_, और function invocation operator & का इस्तेमाल करता है। वास्तव में, एक समय Perl को root language के रूप में इस्तेमाल किया गया था, और ये elements उसी दौर से आए थे। बाद में syntax C# के ज्यादा करीब बदल गया, लेकिन ये elements अच्छे से काम कर रहे थे इसलिए इन्हें रखा गया, और explanation के मुताबिक Perl terminology में इन्होंने language के “whipupitude quotient” में काफी योगदान दिया
      यह भी कहा गया कि PowerShell core language Korn shell के POSIX 1003.2 grammar पर based है, और originally hash tables जैसे advanced concepts के लिए Perl idioms लिए गए थे, लेकिन project आगे बढ़ने पर यह स्पष्ट हो गया कि PowerShell syntax को C# के अनुरूप करना ज्यादा सही रहेगा
    • PowerShell Node से 3 साल पहले आया था
      किसी और चीज पर based न होने की वजह शायद यह थी कि Microsoft .NET को control करता था
      मुझे नहीं लगता कि इसके slow होने की वजह .NET है; यह शायद design issue या performance investment की कमी हो सकती है
      हालांकि यह इस पर निर्भर करता है कि आप PS का कौन-सा version इस्तेमाल कर रहे हैं। याद के मुताबिक latest version काफी fast है

  • काम पर मुझे 20 साल से भी पुराने SQL Server stored procedures वाले codebase से निपटने का सौभाग्य मिला
    यह लगभग 3 लाख लाइनों का, monkey testing से गुजरा हुआ business-critical code था, लेकिन source control नहीं था, performance tuning भी कभी ठीक से नहीं हुई थी, SQL को SSMS में edit/run करके environments में deploy किया जाता था, और जाहिर है automated tests भी नहीं थे
    कंपनी Windows-केंद्रित है, development Mac पर होता है, और GitHub Actions में Linux इस्तेमाल होता है
    हमने PowerShell Core, sqlcmd, Windows SQL Server instance चलाने के लिए docker, पुराने legacy server से schema और code extract करने के लिए RedGate SQL Compare, unit testing के लिए tSQLt, code compliance के लिए TSqlLint, style compliance के लिए SQLFluff, और deployment के लिए Flyway जैसे tools चुने
    जब Windows को platforms में से एक होना ही हो, तो जल्दी ही समझ आ गया कि PowerShell Core सबसे interoperable cross-platform scripting shell है
    Coding मजेदार नहीं थी। regex engine .NET से आता है और उसमें घातक backtracking की समस्या है, और array behavior भी अजीब था। executable को मनचाहे तरीके से launch करना और output streams पकड़ना भी inconsistent था, इसलिए अक्सर process चलाकर output को temporary file में redirect करना पड़ता था, फिर child process खत्म होने पर वह file पढ़नी पड़ती थी। child process के standard output को string variable में pipe करना भी जरूरत से ज्यादा झंझट भरा था
    लेकिन PowerShell Core तेजी से चलता है। Microsoft अगर किसी एक चीज में अच्छा है, तो वह micro-optimization है। ASCII art list selector या आसान input prompt generator जैसे user-interaction tools भी अच्छे हैं। locked files वाले folders से बचें तो Windows filesystem की अजीब quirks भी काफी हद तक छिप जाती हैं
    मेहनत से search करें तो आम तौर पर मनचाहा काम हो जाता है। recommend करने लायक है

  • जब-जब career Windows administration के करीब गया, उस experience से मुझे सचमुच नफरत हुई—इस बात पर बाकी प्रतिक्रियाओं से सहमत हूं
    लेकिन Windows की बाकी हर चीज के बेहद भद्दे होने के उलट, PowerShell खुद असल में काफी अच्छा था, और हमेशा सोच-समझकर design किया हुआ लगा
    Linux शानदार है और आगे भी काम के रोजमर्रा environment के तौर पर इस्तेमाल करूंगा, लेकिन Bash इस्तेमाल करना सच में भयानक है। फिर भी क्योंकि वह हर जगह हमेशा मौजूद रहता है, सब लोग सबसे पहले उसी पर हाथ डालते हैं, और शायद 2100 में भी हम हर तरह की खामियों वाले Bash scripts से जूझते रहेंगे

  • PowerShell सचमुच Microsoft के proprietary confidence से निकला product लगता है
    ऐसी language बनाना साहसी बात है जिसमें दूसरी languages से आने वालों के लिए syntax का लगभग कोई पुल न हो। commands, parameters, flags का अनुमान या अंदाजा नहीं लगाया जा सकता था। Microsoft की महत्वाकांक्षा को देखते हुए भी उन्हें पता होना चाहिए था कि admins और programmers की पूरी फौज को कम-से-कम कई दशकों तक PowerShell और Bash scripts दोनों सीखने और maintain करने होंगे
    बेहद verbose syntax committee presentation में अच्छा लग सकता है, लेकिन जब उसे अक्सर इस्तेमाल करना पड़े तो यह human brain की अच्छी तरह studied सीमाओं से टकराता है। जानकारी का आकार या latency एक स्तर से ऊपर जाते ही flow टूट जाता है, और focus, explicit memorization और दोबारा confirm करने की जरूरत पड़ती है। practice के बाद भी विचारों को reality में बदलने वाले आम shell incantations जल्दी से चलाना मुश्किल होता है, और autocomplete आने का इंतजार करके multi-part command के अगले word को accept करना है या नहीं, यह तय करना भर भी syntax से कुश्ती बन जाता है
    Start menu में pow.. search करने पर PowerShell, PowerShell ISE, और दोनों के normal व x86 versions—कुल चार शानदार विकल्प दिखते हैं। कोई भी चुनें, loading में flow टूटता है। ISE एक छोटा splash screen दिखाता है और दूसरी जगह jump करता है। एक और dialog बताता है कि आपने पिछला session बिना unnamed script file save किए बंद किया था, लेकिन फिर भी उम्मीद के मुताबिक उसे दोबारा खोल देता है। तो फिर डांट क्यों रहा है, समझ नहीं आता
    आप text type या copy करके कोई भी malicious code चला सकते हैं, लेकिन उसे file में save करके .ps script के रूप में चलाना चाहें तो हास्यास्पद execution policy प्रक्रिया शुरू हो जाती है। शायद यह शुरुआती Internet Explorer और Windows की खराब security reputation से आया trauma था
    फिर भी मैंने इसे पसंद करने की कोशिश की, लेकिन एक दिन script को square brackets वाले filename मिले, और PowerShell ने उन [1], [2] को implicit तौर पर किसी iterator जैसी चीज के रूप में interpret कर लिया: https://stackoverflow.com/questions/21008180/copy-file-with-...
    scripting language के core कामों में से एक files को handle करना है, लेकिन filenames script लेखक के control में नहीं होते, और Windows में valid filename space की जानकारी उसे होनी चाहिए। इस घटना ने उस language को लेकर लंबे समय तक रहने वाला trust issue पैदा कर दिया
    लगता है Azure team के पास Microsoft के अंदर पर्याप्त ताकत थी, इसलिए उन्होंने az find vm, az account show जैसी समझदार और पढ़ने में आसान syntax अलग से बना ली

    • ऐसा नहीं है। PowerShell ने shell, Perl और कई दूसरी languages से inspiration ली है, और design में उसके निशान दिखते हैं
      दूसरी तरफ मकसद consistency था। *NIX knowledge असल में काफी हद तक brute-force memorization से मिलती है। -v आम तौर पर verbose और -h आम तौर पर help होता है, लेकिन सच में किसी भी चीज पर भरोसा करके depend नहीं किया जा सकता

  • अब पीछे मुड़कर देखें तो अजीब लगता है कि Microsoft को यह value क्यों नहीं दिखी कि Windows और Active Directory, Exchange जैसे अहम enterprise applications की सारी settings को आसानी से composable और programmable तरीके से configure किया जा सके
    Remote Desktop से connect करके mouse से click करते घूमना alternative के रूप में सुझाना बेतुका है। ऐसे काम को automate करना, कम-से-कम AutoHotkey और Window Spy इस्तेमाल करने के मेरे अनुभव में, बेहद मुश्किल और चिढ़ाने वाला है

    • consultants और software vendors की पूरी industry है जो Windows settings को आसानी से composable और programmable बनाने वाला परिणाम नहीं चाहती
      Remote Desktop से connect करके mouse से click करने वाला तरीका बहुत सारे billable hours पैदा करता है
      irony यह है कि ऐसे काम का बेहद मुश्किल और चिढ़ाने वाला होना ही शायद alternative operating systems के मौजूद होने की मुख्य वजह है
    • और भी अजीब यह है कि वह “click करके घूमने” वाली सोच Azure में भी घुस गई
      पहले, fairness के लिए कहें तो करीब 10 साल पहले, एक support engineer ने सचमुच सुझाव दिया था कि किसी setting को automate करने का सबसे अच्छा तरीका Selenium है

  • 1982 से कंप्यूटर इस्तेमाल कर रहा हूँ, लेकिन सच में Windows यूज़र कभी भी नहीं रहा
    1990 के शुरुआती दशक में जब Wintel उभर रहा था, तब मैं Linux और 386BSD की ग्रोथ के साथ चला; और 1990 के आखिर में जब Win95 और NT बिज़नेस डेस्कटॉप पर छा गए, तब SPARCStation, Linux और बंद हो चुके NeXT hardware की शरण ली। सदी बदलने के बाद मैंने नए POSIX-compliant बने Mac OS को अपनाया
    लगभग आधी सदी तक Microsoft products से बचना मेरी computing policy का मुख्य हिस्सा रहा, एक उल्लेखनीय अपवाद शायद Applesoft BASIC था
    लेकिन PowerShell अच्छा है

    • लगता है computing, खासकर paradigm बदल देने वाली innovation waves का लंबा अनुभव है
      हालांकि पहले paragraph ने जो उम्मीद बनाई थी, दूसरे paragraph ने जानबूझकर उससे हटकर बात की है; काश यह भी समझाते कि PowerShell को “अच्छा” क्यों मानते हैं
    • जानना चाहता हूँ कि PowerShell को Bash से बेहतर क्या बनाता है

  • जब उचित programming language जैसे C/C++ में सीधे command-line tools लिखने पड़ते हैं, तो traditional shell के लिए बनाने और PowerShell के लिए बनाने के बीच productivity का फर्क कम आंका जाता है
    आम तौर पर मैंने कोई useful CLI tool हजारों lines से कम गंदे code के बिना नहीं बनाया। आमतौर पर pipeline input, optional parameters, value वाले parameters, defaults और overrides, dry run mode, अलग-अलग output format requirements वगैरह संभालने पड़ते हैं, इसलिए 90% boilerplate होता है और सिर्फ 10% असली behavior
    PowerShell में C# module में मूल रूप से करीब 20 lines का overhead होता है और बाकी सब actual behavior होता है। productivity हैरान कर देने वाली है
    parameter validation, parameter name tab completion, pipeline input और output, formatting, strong types, globbing—ये सब मुफ्त में मिल जाते हैं

    • मैंने C# इस्तेमाल नहीं किया है, लेकिन सहमत हूँ
      maintenance और admin tasks में हम CLI tools से हटकर compiled languages या interpreted languages की तरफ बढ़ते जा रहे हैं