Kisah Jeffrey Snover Mengembangkan PowerShell

 (corecursive.com)
1 poin oleh GN⁺ 2024-07-05 | 1 komentar | Bagikan ke WhatsApp
  • Jeffrey Snover mendorong PowerShell untuk menjadikan Windows sebagai OS server yang dapat dikelola lewat baris perintah, dan harus melewati budaya Microsoft yang berpusat pada GUI serta resistensi organisasi
  • Porting awal alat UNIX tidak menyelesaikan masalah administrasi server karena Windows bergantung pada struktur API seperti Registry, Active Directory, dan WMI, bukan file
  • Setelah membuat 70 perintah berbasis WMI di WMIC, arah pengembangan diubah ke mesin pembangkit perintah berbasis metadata untuk mengurangi bottleneck pengujian dan biaya
  • Pendahulu PowerShell, Monad, dimulai dengan arus .NET dan Longhorn, tetapi tersisih dari Windows setelah reset Longhorn, lalu hidup kembali berkat dukungan tim Exchange dan organisasi Windows Server
  • Snover tetap fokus pada PowerShell 1~4 meski harus menanggung penurunan jabatan dan kompensasi, dan alat ini kemudian menjadi fondasi otomasi administrasi Windows serta transisi Office ke cloud

Windows yang Berpusat pada GUI dan Masalah Pengelolaan Data Center

  • PowerShell adalah alat perintah yang mengubah administrasi sistem Windows, tetapi di dalam Microsoft proyek ini bukan sesuatu yang sejak awal diterima secara alami
  • Budaya Microsoft saat itu berpusat pada GUI, dan antarmuka baris perintah dianggap kuno, sampai muncul anekdot bahwa Bill Gates mengatakan ia akan melihat command.exe untuk terakhir kalinya
  • Titik awal Snover bergabung dengan Microsoft adalah kesadaran bahwa OS berbasis Windows NT harus diubah agar cocok untuk data center dan pasar enterprise
    • Tujuannya adalah bersaing dengan vendor UNIX seperti Sun, IBM, dan HP
    • Intel dan ekosistem perangkat keras terbuka punya keunggulan dari sisi biaya, tetapi perangkat lunak administrasi server belum cukup baik

Model Administrator untuk Mengurangi Ketergantungan pada System Integrator

  • Administrasi server Windows mengharuskan banyak server dikonfigurasi lewat klik, dan karena setiap perusahaan membutuhkan konfigurasi berbeda, ketergantungan pada system integrator bisa membesar
  • Snover melihat bahwa jika biaya integrator membengkak, keunggulan harga Windows akan hilang
    • Sebagai contoh, ia menyebut struktur biaya perangkat keras 10, perangkat lunak 2, dan system integrator 40
    • Perpindahan relasi pelanggan dan nilai ke integrator juga menjadi masalah
  • Alternatifnya adalah model administrator-programmer ala UNIX
    • Caranya adalah menggabungkan alat-alat kecil untuk menyelesaikan masalah unik dan melakukan otomasi
    • Windows juga membutuhkan lapisan administrator profesional yang menangani skrip dan otomasi, bukan hanya “administrator yang tinggal menekan tombol Next”

Mengapa Porting Alat UNIX Tidak Cocok

  • Solusi awalnya adalah menghadirkan shell UNIX dan alat seperti AWK/GREP/SED ke Windows lewat Windows Services for Unix
  • Namun struktur administrasi Windows berbeda dari UNIX
    • UNIX adalah OS yang berpusat pada file, jadi banyak tugas administrasi bisa diselesaikan dengan memanipulasi file dan me-restart proses
    • Windows memiliki struktur di mana fungsi berada di balik API seperti Registry, Active Directory, dan WMI
    • AWK tidak langsung cocok untuk Registry, SED tidak cocok untuk Active Directory, dan GREP tidak cocok untuk WMI
  • WMI memang punya potensi untuk tugas administrasi, tetapi belum banyak dipakai, sehingga tim Snover ingin membuat alat baris perintah yang menangani objek WMI

WMIC dan Mesin Berbasis Metadata

  • Pada era Windows XP, ada batasan hanya 10 minggu jendela pengodean untuk membuat antarmuka baris perintah berbasis WMI
  • Dengan memanfaatkan engineer kontrak, mereka mengimplementasikan 70 tugas, tetapi itu masih sangat kurang untuk cakupan yang dibutuhkan guna mengelola seluruh server Windows
  • Di dalam Microsoft, fitur tidak bisa dirilis jika organisasi pengujian belum menyetujuinya, dan makin banyak perintah berarti bottleneck pengujian juga makin besar
  • Snover mendorong pendekatan seperti hubungan HTML dan browser: melihat perintah individual bukan sebagai kode, melainkan sebagai metadata, lalu hanya menguji mesin umum
    • Mesin akan menghasilkan perintah, dan konfigurasi tiap perintah dinyatakan sebagai metadata dalam format seperti XML
    • Ia menulis metadata selama liburan Natal dan membuat 72 perintah
    • Ia mengenang bahwa 70 perintah sebelumnya menelan biaya sekitar 4 juta dolar, sedangkan mesinnya sekitar 60 ribu dolar
  • Ketika fitur seperti filtering dan formatting ditambahkan ke mesin, semua perintah ikut menjadi lebih baik, dan ini menjadi pertanda penting arsitektur PowerShell

Longhorn, .NET, dan Monad

  • Bill Gates melihat pengguna Windows 98 tidak berpindah dengan baik ke XP, dan ingin menjadikan Longhorn sebagai titik transisi baru seperti Windows 95
    • Longhorn direncanakan mencakup metode pengembangan berbasis .NET, WPF, WCF, dan model penyimpanan baru
  • Snover menilai .NET bisa menjadi sarana untuk memperluas cakupan administrasi Windows
    • Penulisan provider WMI tidak mendapat momentum yang cukup, tetapi Bill Gates sangat mendorong adopsi .NET
    • Ia melihat bahwa utilitas administrasi di atas .NET dapat memberi cakupan yang lebih luas
  • Ketika organisasi lain mencoba mem-porting K-shell untuk membuat shell, Snover menjelaskan pendekatan yang lebih baik, tetapi gagal meyakinkan mereka
  • Ia lalu mengurung diri di ruangan dan membuat prototipe sekitar 10 ribu baris, yang memuat prinsip arsitektur inti PowerShell
    • Setelah demonstrasi, tim tersebut menerima idenya, dan Snover merasa ini mungkin ide terbaiknya
    • Untuk ikut dalam proyek ini, ia melepaskan peran chief architect untuk produk dan layanan dengan skala ratusan hingga seribu orang, dan pada praktiknya menerima penurunan jabatan

Monad Manifesto dan Meyakinkan Tim

  • Tim baru itu menamai proyek tersebut Monad, dan karena kekurangan personel, sebagian pekerjaan dialihdayakan ke India
  • Snover menulis Monad Manifesto untuk menyelaraskan visi proyek dan jalur keberhasilannya
    • Dokumen itu merangkum masalah, pendekatan lama, pendekatan baru, nilai, dan pembeda
    • Dokumen itu juga menjelaskan dengan jelas nilai yang diberikan kepada tiap pemangku kepentingan seperti administrator, provider, dan tim pengembang
  • Setiap tim di Microsoft sudah punya banyak hal untuk dikerjakan, dan mereka tidak akan dipecat jika tidak membuat antarmuka baris perintah, juga tidak otomatis dipromosikan jika membuatnya
  • Usulan Monad adalah agar tiap tim produk hanya menulis kode untuk memanipulasi objek mereka sendiri, sementara sisanya disediakan oleh PowerShell
    • Formatting, sorting, filtering, parser, eksekusi jarak jauh, eskalasi hak akses, dan sebagainya disediakan di sisi PowerShell
    • Tiap tim hanya perlu menjelaskan cara memanipulasi objek domain mereka sendiri
  • Tim Active Directory menginvestasikan beberapa minggu untuk membuat beberapa cmdlet, dan ketika respons kelompok pengguna sangat kuat, mereka melanjutkan lebih banyak pekerjaan

Kembali ke Windows setelah Reset Longhorn

  • Di Longhorn, dorongan adopsi .NET dilakukan terlalu agresif hingga masalahnya membesar
    • Sebagai contoh, dialog Save As di Notepad baru muncul setelah 1 menit 30 detik karena dialog umum berbasis .NET/WCF, dan working set meningkat dari 15KB menjadi 15MB
    • Ada juga kenangan bahwa build malam tidak berjalan selama sekitar 7 bulan
  • Organisasi Windows kemudian melakukan reset dan mengeluarkan kode .NET dari Windows, dan PowerShell juga terdorong keluar dari Windows
  • Setelah itu, PowerShell terus-menerus mendapat tekanan pembatalan karena ia adalah antarmuka baris perintah sekaligus berbasis .NET
    • Bill Gates memahami nilainya, tetapi itu tidak banyak membantu untuk pertahanan sehari-hari
    • Penanggung jawab Windows Server memberi dukungan pada momen-momen penting
    • Tim Exchange berperan mencegah pembatalan dengan menekankan bahwa mereka punya “bisnis bernilai miliaran dolar” yang bergantung pada PowerShell
  • Persyaratan WinArch untuk memasukkan .NET ke Windows sangat ketat, tetapi tim PowerShell bersiap untuk memenuhi semuanya
  • Ketika penanggung jawab Windows meminta agar permintaan ditarik, program manager menuntut penolakan resmi, dan hasilnya proses peninjauan pun dibuka
    • Organisasi Windows Server memegang kewenangan keputusan ini, dan karena menilai PowerShell memenuhi persyaratan, PowerShell akhirnya masuk kembali ke Windows

PowerShell 1~4 dan Dampak Nyatanya

  • PowerShell 1 dirilis sebagai bagian dari Windows Vista
  • Setelah rilis, Snover mendapat saran untuk mengerjakan hal lain dan peringatan soal kerugian karier, tetapi ia tetap fokus pada visi yang sama hingga PowerShell 2, 3, dan 4
    • Ia mengenang bahwa versi 1 mencapai sebagian tujuan, fitur dilengkapi di versi 2 dan 3, dan pada versi 4 visinya hampir sepenuhnya selesai
  • PowerShell membuat administrator Windows mulai menulis skrip dan mengotomatiskan tugas-tugas yang kompleks
    • Muncul kelompok pengguna, tanya-jawab online, berbagi skrip, dan presentasi konferensi
    • Sebagian administrator bahkan menjadi pembicara profesional berkat pengalaman PowerShell
  • Sekitar 5 tahun kemudian, Snover menjadi Distinguished Engineer, lalu menjadi Technical Fellow
  • Penanggung jawab Office mengatakan bahwa tanpa PowerShell, transisi Office ke cloud akan sulit, dan transisi cloud Office kemudian turut memengaruhi transisi cloud Azure
    • Sebelumnya, provisioning server adalah pekerjaan klik yang sulit diulang dan diperbaiki
    • Dengan skrip, proses itu bisa diskalakan, dan ketika ada masalah, tim bisa merespons dengan mengubah skrip

Bacaan terkait

1 komentar

 
GN⁺ 2024-07-05
Komentar Hacker News

  • Dari sudut pandang pembawa acara, PowerShell menghadapi penolakan sangat keras di internal Microsoft, dan pembuatnya, Jeffrey Snover, bahkan sampai diturunkan jabatan karena terus mendorongnya
    Jeffrey awalnya direkrut untuk membantu Microsoft belajar bersaing di pusat data, tetapi budaya saat itu terlalu terikat pada cara pandang yang berpusat pada komputer pribadi, sehingga ia mendapat perlawanan di setiap langkah
    Hal menarik lainnya adalah PowerShell lahir karena Windows tidak berbasis file. Tujuan Jeffrey adalah administrasi server, tetapi di Windows Anda tidak bisa mengelola hanya dengan mengedit file konfigurasi; Anda harus memanggil berbagai API dan bertukar data terstruktur, sehingga model objek yang kaya pada dasarnya menjadi satu-satunya cara
    Transkrip dibuat dengan urutan transkripsi profesional, Descript, perapian tanda baca oleh GPT-4, lalu peninjauan manual, jadi kualitasnya mungkin tidak setinggi yang diharapkan

    • Jika tim MS-PWSH melihat ini, saya berharap mereka menambahkan fitur GUI dasar yang tidak mengharuskan kita menulis banyak kode .NET secara langsung
      Alasan saya menyukai PowerShell adalah karena ia bahasa dinamis yang sederhana dan bisa merangkai perintah yang mudah digunakan, jadi alangkah baiknya ada kumpulan cmdlet baru untuk membuat antarmuka pengguna sederhana dan grafik
      Misalnya, fitur seperti Create-Chart -Type "Bar" -XAxis $Cities -YAxis $GDP -OutputFile "C:/Documents/ProjectAnalysis/CitiesBarGraph.png" sepertinya mudah bagi Microsoft untuk dimasukkan ke produk, dan bisa menghilangkan satu halaman kode boilerplate yang tidak benar-benar saya pahami
      Pasti ada jutaan pengguna yang bisa melakukan pemrograman dasar, tetapi alat seperti Java atau C# tidak cocok untuk pekerjaan mereka. Python biasanya cocok, tetapi saya berharap Microsoft membuat sesuatu yang lebih bisa dipakai bukan hanya oleh admin server atau staf IT, melainkan juga oleh pengguna kerja umum
      Jika Microsoft berinvestasi lebih jauh agar PowerShell tidak lambat untuk tugas seperti parsing file, lalu menambahkan fitur yang disebutkan di atas atau bahkan cmdlet untuk statistik dan sains, ini bisa menjadi alat yang cukup hebat bagi analis bisnis pada umumnya untuk cepat membuat perangkat lunak peningkat pekerjaan atau prototipe yang bisa diteruskan ke tim pengembang
      Microsoft tampaknya melihat pilihannya sebagai tiga hal: pengembang perangkat lunak formal yang memakai C#, pekerjaan IT yang memakai PowerShell, dan Excel untuk pengguna bisnis. Excel memang bagus dalam banyak hal, tetapi cukup terbatas, dan VBA+Excel termasuk salah satu ekosistem paling terbatas yang pernah saya gunakan. Bahasa pihak ketiga seperti Python dan R memang menjadi pilihan keempat, tetapi saya berharap Microsoft mencurahkan lebih banyak waktu ke area ini
    • Melihat para MVP di GitHub mengeluh bahwa investasi tambahan yang dijanjikan Microsoft tidak terwujud, perubahan tidak digabungkan, dan fitur-fitur bagus dibiarkan terbengkalai, tampaknya ini bukan lagi prioritas MSFT
      Saya dulu menyukai PowerShell, termasuk keanehan-keanehannya, tetapi sekarang sudah meninggalkannya
    • Saya penasaran mengapa mereka membangunnya dari nol alih-alih memakai Python atau alat yang sudah ada dan sejenis
    • Saya mencoba membaca transkripnya, tetapi tidak berhasil menyelesaikannya, dan merasa agak sulit dibaca
      Saat membaca, saya menduga ini dihasilkan mesin, tetapi sulit menjelaskan persis mengapa; sepertinya perlu sedikit penyuntingan agar lebih mudah dibaca
      Meski begitu, ini jauh lebih baik daripada tidak ada transkrip sama sekali

  • Sebagai developer yang sudah lama memakai Bash, saat PowerShell muncul saya benar-benar menantikannya
    Saya mengira akhirnya di Windows pun akan bisa memakai shell yang keren untuk pengembangan, tetapi setelah itu saya tetap tidak pernah benar-benar menguasai PowerShell, dan di Windows pun terus memakai Bash yang sudah familiar
    Saya penasaran bagaimana developer yang mahir di kedua shell membandingkannya. Saya ingin tahu apakah PowerShell benar-benar memenuhi janjinya sebagai shell yang lebih efisien dan modern, atau sekadar dipakai karena terpasang secara default dan lebih baik daripada CMD

    • Saya banyak memakai Bash dan juga membaca beberapa buku, tetapi saya sangat yakin bahwa kita tidak boleh menulis skrip Bash yang kompleks
      Kalau kira-kira sudah lebih dari 50 baris, saya menganggapnya sebagai code smell, dan saya menyimpan halaman ini untuk berjaga-jaga saat harus meyakinkan seseorang: http://mywiki.wooledge.org/BashPitfalls
      Setelah belakangan mencoba PowerShell, fakta bahwa command mengembalikan objek, bukan teks, sehingga tidak perlu memaksakan diri memanipulasi teks, terasa jauh lebih mudah baik sebagai bahasa skrip maupun bahasa command-line
      Adanya cara resmi untuk menangani parsing argumen juga sangat bagus. Semuanya seragam, dan di jendela command-line praktis semua opsi bisa di-autocomplete; ini level yang bahkan tidak bisa diimpikan Bash, sehingga produktivitas meningkat besar
      Namun konversi tipe kadang juga menciptakan bug baru yang tidak ada di Bash. Saat ini saya lebih menyukai PWSH, tetapi saya juga tidak sepenuhnya suka keduanya, dan sedang menunggu evolusi alami berikutnya
    • PowerShell lebih verbose daripada Bash, dan punya keanehan seperti otomatis membuka array berisi 0 atau 1 elemen menjadi skalar pada saat yang tidak terduga, tetapi lebih produktif dan lebih mudah dibaca
      Orientasi objek cukup berguna saat membuat pipeline
      Misalnya, untuk mencari kandidat duplikat dengan mengelompokkan file secara rekursif di dalam folder berdasarkan ukuran file, kita bisa menulis Get-ChildItem -File -Recurse | Group-Object -Property Length | Where-Object { $_.Count -gt 1 } | Sort-Object -Property Count
      Tidak perlu mengingat mantra file yang sulit dipahami, dan tidak perlu mem-parsing keluaran teks. Kita menerima objek sungguhan yang memiliki properti, dan autocomplete dengan tab bisa memperlihatkan struktur itu
      Jika perlu mem-parsing JSON, tanpa jq pun bisa langsung diproses dengan Get-Content -Raw whatever.json | ConvertFrom-Json. Untuk mengubah XML menjadi CSV, gunakan ConvertFrom-Xml atau Select-Xml, lakukan pekerjaan yang diperlukan setelahnya, lalu pakai ConvertTo-Csv
      Jika Get-ChildItem terlalu panjang, gunakan gci, dir, atau ls; jika Where-Object terlalu panjang, gunakan where atau ?. Secara default, huruf besar-kecil juga tidak dibedakan
    • Saya memulai karier dengan terminal X pada kotak pizza SunOS, menulis ribuan skrip, dan cukup banyak di antaranya berukuran ribuan baris
      Beberapa tahun lalu saya harus menulis sistem transfer data yang kompleks, tangguh, dan berjalan tanpa pengawasan dengan PowerShell, dan pengalaman itu begitu bagus sampai saya mengganti semua shell di macOS dan Linux menjadi PWSH
      Hal yang paling saya sukai adalah kekuatan meneruskan objek melalui pipeline. Di filter pertama, saya bisa mengekstrak dan memanipulasi sebagian properti objek, namun di filter berikutnya dalam pipeline tetap bisa mengakses properti lain serta properti objek yang dibuat oleh filter pertama
      Konsistensi command, penanganan error, dan properti objek juga sangat baik
      Setelah itu sifat pekerjaan saya berubah, memori otot lama muncul kembali, dan saya mengembalikan semua shell ke Bash. Saat banyak bekerja dan berpikir di ruang itu, PWSH terasa alami sebagai shell, tetapi setelah keluar dari sana, berpikir dengan PWSH terasa lebih sulit daripada kembali ke Bash
      Kadang saya merindukannya. Menurut saya tidak ada yang sedekat itu di ranah shell, setidaknya tidak ada alternatif yang cukup dekat untuk membenarkan upaya beralih
    • Saya bukan ahli di keduanya, tetapi sudah cukup banyak memakainya, dan saya merasa PowerShell menjadi mengerikan untuk digunakan karena beberapa jebakan
      Pertama, upayanya menjadi bahasa .NET. Saya tidak tahu mengapa janji .NET tentang satu runtime dan banyak bahasa justru berkembang di dunia Java tanpa janji semacam itu, tetapi layu di .NET; namun kalau harus menulis kode .NET, menurut saya lebih baik memakai C#
      Kedua, ia tidak benar-benar memantapkan dasar-dasar shell. Detailnya sudah saya kubur sebagai masa lalu sehingga tidak ingat lagi, tetapi penanganan redirection-nya rusak, dan hal yang sepele di Bash hampir mustahil dilakukan di PowerShell. Saya merasa para developer terlalu bersemangat membuat sesuatu yang baru dan kuat sampai mengabaikan hal-hal yang sudah dilakukan dengan baik oleh Bash dan lainnya
      Ketiga, ada obsesi seperti mengharuskan semua nama memakai format Verb-Object. Ini subjektif dan pasti ada pendukungnya, tetapi menurut saya membuat skrip tampak jelek, canggung untuk diketik, dan tidak benar-benar meningkatkan discoverability atau kemudahan mengingat
    • Saya tidak suka PowerShell karena ada begitu banyak titik yang mengejutkan dengan cara yang sangat berbeda dari Bash
      Harus memakai panah kanan alih-alih tab juga membingungkan, dan tidak adanya command yang familiar serta adanya aturan kuat dalam penamaan juga terasa tidak nyaman
      Meski begitu, jika dipahami dengan baik, PowerShell tampak lebih mumpuni daripada Bash. Alasannya, PowerShell memiliki sistem tipe yang lebih baik dan lebih mudah menangani argumen, sedangkan nilai-nilai di Bash lebih dekat ke string tanpa bentuk
      https://github.com/bionicles/tree_plus/blob/main/tests/more_... adalah versi yang agak lama yang saya gunakan saat menyiapkan lingkungan pengujian di mesin Windows, dan cukup menunjukkan apa saja yang mungkin dilakukan

  • Saat memakai PowerShell secara langsung, rasanya tidak mengerikan, tetapi saya tidak pernah paham mengapa array dengan panjang 1 dilepas dari array lalu berubah menjadi tipe di dalamnya
    Karena itu, setiap kali harus memperhatikan berapa banyak item yang mungkin masuk ke array, dan alih-alih menanganinya secara umum, harus mengeceknya setiap kali melakukan perubahan, sehingga muncul bug yang sangat banyak. Saya penasaran apakah ada yang tahu mengapa dibuat seperti ini

    • Alasan bagian seputar array terasa longgar adalah karena API keluaran cmdlet juga longgar terhadap array
      Satu fungsi bernama WriteObject menulis nilai yang diberikan sebagai keluaran cmdlet, dan jika dipanggil sekali, itulah keluarannya. Jika dipanggil beberapa kali, shell tidak punya pilihan selain mengumpulkan semua nilai itu dan menjadikannya array sebagai keluaran
      Jadi jika pada satu eksekusi cmdlet WriteObject hanya dipanggil sekali dan pada eksekusi lain dipanggil dua kali, dalam kasus pertama shell tidak bisa tahu bahwa keluaran tunggal itu pun seharusnya dibungkus sebagai array. Namun jika keluaran cmdlet selalu dibungkus sebagai array, itu akan mengganggu cmdlet yang secara semantik hanya punya satu hasil, seperti Get-Date
      Entah mengapa, tampaknya mereka tidak ingin membuat API menjadi rumit agar cmdlet sendiri dapat menyatakan apakah keluarannya secara semantik tunggal atau jamak, terlepas dari jumlah panggilan WriteObject yang sebenarnya. API seperti ini tidak bisa menjadi properti statis cmdlet karena keluarannya bisa sangat berbeda tergantung parameter, dan overload WriteObject seperti (Object, bool iMightWriteMoreValues) juga bermasalah karena harus tetap bekerja untuk array kosong. Mungkin perlu fungsi terpisah seperti IWillWriteMultipleValues()
      Ini juga dijelaskan di sini: https://news.ycombinator.com/item?id=40874873
    • Ini benar-benar menjengkelkan. Saya mulai memakai comma hack, yaitu menambahkan koma di depan untuk memaksa array
      $Ary = @(, "value")
      Saat membuat array, terutama array besar, performanya lebih baik daripada +=, jadi fitur menetapkan loop for ke array juga cukup bagus. Memang tidak intuitif sebagai cara mengisi array, tetapi jelas berguna
      $Ary = foreach ($Obj in $Objs) { @{ foo = $Obj.foo } }
    • Ini terdengar seperti contoh klasik ketika perangkat lunak gagal karena berusaha terlalu pintar
      Pengembang perangkat lunak harus selalu waspada terhadap godaan untuk membuat perangkat lunaknya terlalu pintar
    • Terasa seperti fitur yang baru setengah matang
      Setengah bagian yang hilang seharusnya adalah kemampuan di sisi penerima untuk otomatis mengubah nilai tunggal menjadi array sepanjang 1 ketika ia mengharapkan array
    • Bahasa niche sepertinya selalu punya keanehan gila seperti ini
      Padahal sudah ada sesuatu seperti Lua; alih-alih memakainya apa adanya atau memodifikasinya sedikit untuk mendapatkan bahasa yang sederhana, kecil, elegan, dan konsisten, orang-orang malah menciptakan ulang roda tetapi tetap gagal membuatnya bulat, seperti tragedi Sisifus

  • Kecuali jika perlu perintah PowerShell tertentu karena harus berinteraksi dengan subsistem Windows, saya jadi berpikir, “kenapa tidak memakai Python?”
    Untuk 90% pekerjaan yang akan dilakukan dengan Bash, ini terlalu bertele-tele dan lambat; begitu juga untuk hal-hal yang dalam kehidupan lain mungkin akan saya lakukan dengan Perl
    Saya sering bertanya-tanya mengapa Microsoft tidak membangunnya di atas sesuatu seperti Python atau Node. Saya tidak ingat kapan PowerShell pertama kali muncul, jadi tidak yakin apa yang saat itu ideal

    • REPL bawaan Python benar-benar buruk
      Selain itu, Python tidak dirancang untuk pekerjaan konsol yang dikuasai PowerShell. Hal yang seharusnya cukup dengan menerima isi file lalu meneruskannya ke perintah lain malah harus dilakukan sendiri dengan mengelola file handle dan semacamnya
      PowerShell bagus karena merupakan pisau Swiss Army dengan REPL hebat yang punya pelengkapan otomatis, tidak ada perilaku whitespace yang aneh, readline[0], dan jika perlu bisa melakukan semua hal yang bisa dilakukan dengan .NET
      Selain itu, karena berorientasi objek, kita bisa fokus pada pekerjaan yang benar-benar perlu dilakukan, alih-alih mencari cara mem-parsing keluaran berbasis teks dari utilitas lama dengan utilitas lama lainnya
      0: https://learn.microsoft.com/en-us/powershell/module/psreadli...
    • Awalnya secara longgar didasarkan pada Perl dan Korn shell
      Edisi pertama “Powershell in Action” karya Bruce Payette memiliki penjelasan sampingan bahwa PowerShell terlihat seperti Perl karena memakai simbol @, variabel bawaan $_, dan operator pemanggilan fungsi &. Disebutkan bahwa pada suatu masa Perl benar-benar dipakai sebagai bahasa akar, dan elemen-elemen ini berasal dari periode itu. Kemudian sintaksnya diubah agar lebih sesuai dengan C#, tetapi elemen-elemen ini dipertahankan karena bekerja dengan baik, dan dalam istilah Perl, sangat berkontribusi pada “whipupitude quotient” bahasa tersebut
      Juga disebutkan bahwa bahasa inti PowerShell didasarkan pada tata bahasa POSIX 1003.2 dari Korn shell, dan bahwa awalnya mereka mengambil idiom Perl untuk konsep tingkat lanjut seperti hash table, tetapi seiring berjalannya proyek menjadi jelas bahwa akan lebih tepat menyelaraskan sintaks PowerShell dengan C#
    • PowerShell muncul 3 tahun sebelum Node
      Kemungkinan besar alasan tidak dibangun di atas sesuatu yang lain adalah karena Microsoft mengendalikan .NET
      Saya tidak berpikir penyebab lambatnya adalah .NET; mungkin lebih karena masalah desain atau kurangnya investasi performa
      Namun itu tergantung versi PS yang dipakai. Seingat saya, versi terbaru cukup cepat

  • Di tempat kerja, saya mendapat “berkah” menangani codebase stored procedure SQL Server yang sudah berumur lebih dari 20 tahun
    Itu sekitar 300 ribu baris kode inti bisnis yang sudah ditempa monkey testing, tetapi tidak punya source control, tidak pernah benar-benar dituning performanya, SQL diedit dan dijalankan dari SSMS lalu dideploy ke environment, dan tentu saja tidak ada automated test
    Perusahaan berpusat pada Windows, pengembangan dilakukan di Mac, dan GitHub Actions memakai Linux
    Kami memilih alat seperti PowerShell Core, sqlcmd, docker untuk menjalankan instance Windows SQL Server, RedGate SQL Compare untuk mengekstrak skema dan kode dari server legacy yang ada, tSQLt untuk unit test, TSqlLint untuk kepatuhan kode, SQLFluff untuk kepatuhan gaya, serta Flyway untuk deployment
    Saat Windows harus menjadi salah satu platform, saya segera tahu bahwa PowerShell Core adalah shell scripting lintas platform dengan interoperabilitas terbaik
    Coding-nya tidak menyenangkan. Mesin regex-nya berasal dari .NET dan punya masalah backtracking yang fatal, perilaku array-nya juga aneh. Menjalankan executable dengan cara yang diinginkan dan menangkap output stream juga tidak konsisten, sehingga sering kali harus menjalankan proses, mengarahkan output ke file sementara, lalu membaca file itu setelah child process selesai. Mem-pipe stdout dari child process ke variabel string juga jauh lebih merepotkan dari yang semestinya
    Namun PowerShell Core cepat dijalankan. Kalau ada satu hal yang Microsoft lakukan dengan baik, itu adalah mikro-optimisasi. Alat untuk berinteraksi dengan pengguna, seperti pemilih daftar ASCII art atau pembuat prompt input yang mudah, juga bagus. Kalau menghindari folder yang berisi file terkunci, sebagian besar keanehan sistem file Windows juga tersembunyi
    Kalau rajin mencari, umumnya hal yang diinginkan bisa dilakukan. Layak direkomendasikan

  • Saya setuju dengan kesan orang lain bahwa setiap kali karier saya mendekati administrasi Windows, saya benar-benar membenci pengalaman itu
    Namun berbeda dengan semua hal lain di Windows yang terasa sangat kaku, PowerShell itu sendiri sebenarnya cukup hebat, dan selalu terasa dirancang dengan hati-hati
    Linux itu bagus dan akan tetap saya pakai sebagai lingkungan kerja sehari-hari, tetapi memakai Bash benar-benar mengerikan. Meski begitu, karena selalu ada di mana-mana, semua orang menyentuhnya lebih dulu, dan mungkin pada tahun 2100 pun kita masih akan terus berurusan dengan skrip Bash yang penuh cacat

  • PowerShell benar-benar terasa seperti produk dari rasa percaya diri monopolistik Microsoft
    Membuat bahasa yang hampir tidak punya kaitan sintaksis untuk orang yang datang dari bahasa lain adalah langkah berani. Perintah, parameter, dan flag tidak bisa ditebak atau diperkirakan. Bahkan dengan ambisi Microsoft sekalipun, mereka seharusnya tahu bahwa pasukan administrator dan programmer harus mempelajari serta memelihara PowerShell bersama skrip Bash setidaknya selama beberapa dekade
    Sintaks yang luar biasa verbose mungkin terlihat bagus dalam presentasi komite, tetapi bila sering dipakai secara nyata, ia berbenturan dengan batasan otak manusia yang sudah banyak diteliti. Ketika ukuran informasi atau latensi melewati tingkat tertentu, flow konsentrasi pecah, dan perlu fokus, hafalan eksplisit, serta pengecekan ulang. Bahkan dengan latihan, sulit mengeksekusi mantra shell umum yang mengubah pikiran menjadi kenyataan dengan cepat; hanya menunggu autocomplete muncul lalu memutuskan apakah akan menerima kata berikutnya dari perintah multi-bagian pun sudah membuat kita bergulat dengan sintaks
    Jika mencari pow.. di Start menu, muncul empat pilihan keren: PowerShell, PowerShell ISE, serta versi normal dan x86 masing-masing. Apa pun pilihannya, ada waktu loading yang memecah flow. ISE menampilkan splash screen kecil lalu melompat ke lokasi lain. Dialog lain memberi tahu bahwa sesi sebelumnya ditutup tanpa menyimpan file skrip tanpa nama, tetapi toh membukanya kembali seperti yang diharapkan. Jadi entah kenapa ia memarahi saya
    Kita bisa mengetik atau menyalin teks dan menjalankan kode berbahaya apa pun, tetapi jika menyimpannya sebagai file lalu ingin menjalankannya sebagai skrip .ps, prosedur execution policy yang konyol pun dimulai. Mungkin itu trauma dari reputasi keamanan buruk Internet Explorer awal dan Windows
    Tetap saja saya mencoba mencintainya, sampai suatu hari sebuah skrip bertemu nama file yang mengandung tanda kurung siku, dan PowerShell secara implisit menafsirkan [1], [2] itu seperti semacam iterator: https://stackoverflow.com/questions/21008180/copy-file-with-...
    Salah satu pekerjaan inti bahasa scripting adalah menangani file, sementara nama file tidak bisa dikendalikan penulis skrip dan ruang nama file yang valid di Windows semestinya diketahui. Peristiwa ini menimbulkan masalah kepercayaan jangka panjang terhadap bahasa itu
    Tim Azure tampaknya punya cukup kekuatan di dalam Microsoft sehingga membuat sintaks terpisah yang waras dan mudah dibaca, seperti az find vm, az account show

    • Tidak begitu. PowerShell terinspirasi dari shell, Perl, dan beberapa bahasa lain, dan jejaknya terlihat dalam desainnya
      Di sisi lain, yang diinginkan adalah konsistensi. Pengetahuan *NIX pada dasarnya cenderung diperoleh dengan menghafal secara brutal. -v umumnya berarti verbose dan -h umumnya help, tetapi kenyataannya tidak ada yang benar-benar bisa dipercaya dan diandalkan

  • Jika melihat ke belakang sekarang, aneh rasanya Microsoft tidak melihat nilai dari membuat semua konfigurasi Windows dan aplikasi enterprise penting seperti Active Directory serta Exchange mudah dikomposisikan dan dapat diprogram
    Gagasan bahwa alternatif yang mereka tawarkan adalah masuk lewat Remote Desktop lalu mengeklik-ngeklik dengan mouse itu absurd. Mengotomatisasi pekerjaan seperti itu, setidaknya dari pengalaman memakai AutoHotkey dan Window Spy, sangat sulit dan menjengkelkan

    • Ada seluruh industri konsultan dan vendor perangkat lunak yang tidak menginginkan hasil berupa konfigurasi Windows yang mudah dikomposisikan dan dapat diprogram
      Cara masuk lewat Remote Desktop lalu mengeklik dengan mouse menghasilkan banyak jam tagihan
      Ironisnya, fakta bahwa hal seperti itu sangat sulit dan menjengkelkan kemungkinan besar adalah alasan utama sistem operasi alternatif ada
    • Yang lebih aneh adalah pola pikir “berkeliling sambil mengeklik” itu juga masuk ke Azure
      Dulu, sejujurnya sekitar 10 tahun lalu, saya pernah mendapat saran serius dari staf dukungan teknis bahwa cara terbaik untuk mengotomatisasi suatu konfigurasi adalah Selenium

  • Saya sudah menggunakan komputer sejak 1982, tetapi benar-benar tidak pernah sekalipun menjadi pengguna Windows.
    Saat Wintel naik daun pada awal 1990-an, saya mengikuti pertumbuhan Linux dan 386BSD; ketika Win95 dan NT mendominasi desktop bisnis pada akhir 1990-an, saya mengungsi ke SPARCStation, Linux, dan perangkat keras NeXT yang sudah dihentikan. Setelah pergantian abad, saya menerima Mac OS yang baru saja menjadi patuh POSIX.
    Selama hampir setengah abad, menghindari produk Microsoft adalah inti kebijakan komputasi saya, dengan pengecualian yang patut dicatat kira-kira hanya Applesoft BASIC.
    Namun PowerShell itu bagus.

    • Sepertinya Anda punya pengalaman panjang dalam komputasi, terutama dalam arus inovasi yang mengubah paradigma.
      Namun paragraf kedua sengaja menghindari ekspektasi yang dibangun paragraf pertama; saya berharap ada penjelasan mengapa PowerShell dianggap “bagus”.
    • Saya penasaran apa yang membuat PowerShell lebih baik daripada Bash.

  • Saat harus menulis sendiri tool command-line dengan bahasa pemrograman yang layak seperti C/C++, perbedaan produktivitas antara membuatnya untuk shell tradisional dan membuatnya untuk PowerShell sering diremehkan.
    Secara umum, saya belum pernah membuat tool CLI yang berguna tanpa ribuan baris kode berantakan atau lebih sedikit. Biasanya harus menangani input pipeline, parameter pilihan, parameter bernilai, nilai default dan override, mode dry run, berbagai kebutuhan format output, dan sebagainya, sehingga 90% hanya boilerplate dan 10% saja yang benar-benar menjalankan fungsi.
    Di PowerShell, modul C# pada dasarnya hanya punya overhead sekitar 20 baris, dan sisanya semuanya adalah perilaku nyata. Produktivitasnya luar biasa.
    Validasi parameter, autocomplete tab untuk nama parameter, input dan output pipeline, pemformatan, strong typing, globbing, dan lain-lain semuanya didapat gratis.

    • Saya belum pernah memakai C#, tetapi saya setuju.
      Untuk pekerjaan pemeliharaan dan administrasi, saya makin beralih dari tool CLI ke bahasa terkompilasi atau bahasa interpreter.