4 ms·

I’m curious about the scenarios that Powershell used to work for you in, and what tooling you’ve moved on to. Do you use something else for Write-Once-Run-(Near

by JoBrad 2y ago

I’m curious about the scenarios that Powershell used to work for you in, and what tooling you’ve moved on to. Do you use something else for Write-Once-Run-(Nearly)Anywhere type scripts? I primarily write Powershell Core scripts for scenarios where I need to execute the same commands on a variety of operating systems, and I know that the script is likely to be maintained by your “typical” sysadmin (highly technical, but not a programmer)in an environment where installing runtimes for programming languages is discouraged. I switched to macOS as my daily driver about 2 years ago, so PS fits these scenarios pretty well, and Powershell Core updated fairly regularly. Sure there are annoying bugs and misses with the built-in and add-on MS modules: networking cmdlets are an almost total miss, Get-LocalGroup (and maybe other commands?) is totally broken on some AzureAD-joined machines, and the Azure and MgGraph Powershell modules still don’t have enough coverage to move on from the legacy Windows Powershell modules (or even to rely on just one of them, for areas they supposedly cover). But overall I’ve been pretty happy that 99% of the time I can write a powershell script once, and it will run on any machine with Powershell Core, in a consistent way.

hobs 2y ago
Don't do as much "local" sysadmin stuff as most of the workloads moved to the cloud and containers, and that's all automateable via APIs which are much nicer to work with in python with its useful library support. (one of the biggest misses in powershell) There's still a lot of good stuff wrt powershell maintainability by normal humans (though the entire mental model of object output usually throws them for a loop for years) managing local stuff.
- pjmlp 2y ago
  PowerShell has the whole Windows OS libraries, COM and .NET available, without additional installation, a bit more than just Python.
  - hobs 2y ago
    Absolutely, and the calling conventions for all those pieces of code make no sense to powershell folks :) If you have a background in windows dev or any of those tools then yeah, easy mode go grab your tools, but for most people doing system automation the calling conventions and complete lack of discoverability within the powershell ecosystem (and their tools in no way helping out) made this not a realistic use case. Shoot I have seen some powershell modules that have to embed string C#s and eval thing just to have basic performance or other basic use cases.
    - pjmlp 2y ago
      The same challenge with calling conventions happens with Python calling into Windows APIs, moreso since there aren't that many wrappers available, other than installing something like ActiveState Python.
      - hobs 2y ago
        Right, but it isn't really a core benefit of using PS is my point.
        pjmlp 2y ago
        It actually is, as it provides scripting across the whole OS stack and applications, closer to Xerox, Lisp Machines and Smalltalk REPL, something that no UNIX has ever offered, with exception of outliers like NeXTSTEP and OS X.
        nrr 2y ago
        This is all technically true, but the thesis is that PowerShell makes it all horribly clumsy to use. From the perspective of the Lisp Machine or, hell, even the AS/400, PowerShell (and, while we're here, the CLR) doesn't quite go deeply enough, pervasively enough, across the system to make it truly useful in the same way.
        hobs 2y ago
  - mycall 2y ago
    IronPython also exists, although an older version of python.
    - pjmlp 2y ago
      For all practical purposes it is a dead project, sadly.
- dh2022 2y ago
  IMO PowerShell is very well integrated with Microsoft Azure cloud. Every Azure resource I work with (Storage, VM, Kusto, EventHub, Service Fabric, AAD, Networking) has tons of PowerShell support. I never set time to use Python with Azure Cloud - and this is only because PowerShell is so good at Azure.
- vips7L 2y ago
  How is having the entire C# ecosystem a big miss?
  - jodrellblank 2y ago
    It's a big miss for the casual convenience of a scripter/non-programmer. A Pythonic way to do a remote procedure call is XMLRPC (pseudocode): import xmlrpc svr = xmlrpc.connect('http://remote/') result = svr.add(1, 2) The C# way is to use the Microsoft Windows Communication Foundation (WFC) Client Proxy using the Service Model Metadata Utility Tool and the Web Services Description Language (WSDL) and XML Schema Definition Language (XSD) files from the remote server, declare a public interface attributed as a Service Contract referencing a namespace, generate a class which inherits from the generic ClientBase<TChannel> and implements the new interface, create an instance of said WCF client and call its methods. (Or rely on Visual Studio magic to hide all that) - https://learn.microsoft.com/en-us/dotnet/framework/wcf/accessing-services-using-a-wcf-client?source=recommendations https://learn.microsoft.com/en-us/dotnet/framework/wcf/acces... In any decision, Python goes for "What would Guido do?" and C# gets some union of "what would a committee of Microsoft, IBM, Oracle do?", "What would impress Gartner?", "What is Microsoft legally obliged to do, and backwards-compatibly required to do?", "What would we do if we tried to do everything everyone needs all in one?", "What would Java do?", "What would a large team need to design and maintain a stable, typed, large system for years?". PowerShell is on top of that; there's no simple included graphing and drawing, no simple hooks into Windows own voice recognition and OCR, and definitely not into whatever magically good ones newer Office / Cloud is using, no casual email or spreadsheet handling, no Visual Basic style form building, no simple data science; there's a few things you can do or download, generally less convenient than a Python equivalent. And Microsoft are leaving it all 'to the community' but the community is using Python so that's where the Excel power-user who wants to script a couple of things will go.
    - vips7L 2y ago
      I don’t think Python, a general purpose scripting language; and PowerShell, a shell, are going for the same things. They have different goals and by your definition every other tool is a “big miss” because they are not Python. I have never desired to do xmlrpc, ocr, voice recognition, or gui building from my shell (and if I did I still don’t see how importing a C# library would be a big miss). What I do desire to do is open files, read their contents and pipe them into other programs, something that Python makes a pain to do with all the file handling. Powershell definitely excels at this, does that make Python a big miss?
- JoBrad 2y ago
  I use Python for AWS, a lot. Last I checked, to use the Azure Python module you have to setup an Enterprise app, which seemed like overkill to me, and not something I think most of our sys admins would want to do. Maybe I’m wrong?
okaram 2y ago
> I primarily write Powershell Core scripts for scenarios ... in an environment where installing runtimes for programming languages is discouraged. But PS Core is a programming language, right? And only installed by default on Windows? I'm assuming there's other constraints on your system that make it preferable to installing bash or python on your Windows boxes?

by JoBrad 2y ago

hobs 2y ago

Don't do as much "local" sysadmin stuff as most of the workloads moved to the cloud and containers, and that's all automateable via APIs which are much nicer to work with in python with its useful library support. (one of the biggest misses in powershell) There's still a lot of good stuff wrt powershell maintainability by normal humans (though the entire mental model of object output usually throws them for a loop for years) managing local stuff.

pjmlp 2y ago
PowerShell has the whole Windows OS libraries, COM and .NET available, without additional installation, a bit more than just Python.
- hobs 2y ago
  Absolutely, and the calling conventions for all those pieces of code make no sense to powershell folks :) If you have a background in windows dev or any of those tools then yeah, easy mode go grab your tools, but for most people doing system automation the calling conventions and complete lack of discoverability within the powershell ecosystem (and their tools in no way helping out) made this not a realistic use case. Shoot I have seen some powershell modules that have to embed string C#s and eval thing just to have basic performance or other basic use cases.
  - pjmlp 2y ago
    The same challenge with calling conventions happens with Python calling into Windows APIs, moreso since there aren't that many wrappers available, other than installing something like ActiveState Python.
    - hobs 2y ago
      Right, but it isn't really a core benefit of using PS is my point.
      - pjmlp 2y ago
        It actually is, as it provides scripting across the whole OS stack and applications, closer to Xerox, Lisp Machines and Smalltalk REPL, something that no UNIX has ever offered, with exception of outliers like NeXTSTEP and OS X.
        nrr 2y ago
        This is all technically true, but the thesis is that PowerShell makes it all horribly clumsy to use. From the perspective of the Lisp Machine or, hell, even the AS/400, PowerShell (and, while we're here, the CLR) doesn't quite go deeply enough, pervasively enough, across the system to make it truly useful in the same way.
        hobs 2y ago
- mycall 2y ago
  IronPython also exists, although an older version of python.
  - pjmlp 2y ago
    For all practical purposes it is a dead project, sadly.
dh2022 2y ago
IMO PowerShell is very well integrated with Microsoft Azure cloud. Every Azure resource I work with (Storage, VM, Kusto, EventHub, Service Fabric, AAD, Networking) has tons of PowerShell support. I never set time to use Python with Azure Cloud - and this is only because PowerShell is so good at Azure.
vips7L 2y ago
How is having the entire C# ecosystem a big miss?
- jodrellblank 2y ago
  It's a big miss for the casual convenience of a scripter/non-programmer. A Pythonic way to do a remote procedure call is XMLRPC (pseudocode): import xmlrpc svr = xmlrpc.connect('http://remote/') result = svr.add(1, 2) The C# way is to use the Microsoft Windows Communication Foundation (WFC) Client Proxy using the Service Model Metadata Utility Tool and the Web Services Description Language (WSDL) and XML Schema Definition Language (XSD) files from the remote server, declare a public interface attributed as a Service Contract referencing a namespace, generate a class which inherits from the generic ClientBase<TChannel> and implements the new interface, create an instance of said WCF client and call its methods. (Or rely on Visual Studio magic to hide all that) - https://learn.microsoft.com/en-us/dotnet/framework/wcf/accessing-services-using-a-wcf-client?source=recommendations https://learn.microsoft.com/en-us/dotnet/framework/wcf/acces... In any decision, Python goes for "What would Guido do?" and C# gets some union of "what would a committee of Microsoft, IBM, Oracle do?", "What would impress Gartner?", "What is Microsoft legally obliged to do, and backwards-compatibly required to do?", "What would we do if we tried to do everything everyone needs all in one?", "What would Java do?", "What would a large team need to design and maintain a stable, typed, large system for years?". PowerShell is on top of that; there's no simple included graphing and drawing, no simple hooks into Windows own voice recognition and OCR, and definitely not into whatever magically good ones newer Office / Cloud is using, no casual email or spreadsheet handling, no Visual Basic style form building, no simple data science; there's a few things you can do or download, generally less convenient than a Python equivalent. And Microsoft are leaving it all 'to the community' but the community is using Python so that's where the Excel power-user who wants to script a couple of things will go.
  - vips7L 2y ago
    I don’t think Python, a general purpose scripting language; and PowerShell, a shell, are going for the same things. They have different goals and by your definition every other tool is a “big miss” because they are not Python. I have never desired to do xmlrpc, ocr, voice recognition, or gui building from my shell (and if I did I still don’t see how importing a C# library would be a big miss). What I do desire to do is open files, read their contents and pipe them into other programs, something that Python makes a pain to do with all the file handling. Powershell definitely excels at this, does that make Python a big miss?
JoBrad 2y ago
I use Python for AWS, a lot. Last I checked, to use the Azure Python module you have to setup an Enterprise app, which seemed like overkill to me, and not something I think most of our sys admins would want to do. Maybe I’m wrong?

okaram 2y ago

> I primarily write Powershell Core scripts for scenarios ... in an environment where installing runtimes for programming languages is discouraged. But PS Core is a programming language, right? And only installed by default on Windows? I'm assuming there's other constraints on your system that make it preferable to installing bash or python on your Windows boxes?