4 ms·

What makes you say PS is horribly implemented ?

skrebbel 12y ago
Just a bunch: Doing really common things, such as "find the directory of the currently executing script" can only by done by copy-pasting a non-trivial 3-line function from Stack Overflow. In batch (of all scripting languages), it's "%~dp0". Cryptic, yes, but at least it's in there. Similarly, the internet is full of blog posts with 1000-word articles explain how "easy" it is to do something in PowerShell that should've been a one liner to begin with. Basically, the builtins just suck. Batteries included? No way. Someone at the MS marketing department decided that, in order to make PowerShell popular, it has to be cool. As a result, the above-mentioned blog posts contain example code like `echo "I Love PowerShell"`, making it sound amazing that should-be trivial stuff is only a matter of copying five lines of code [0]. In general, writing PS scripts is a really odd mishmash of bash-isms, batch-isms and .NET-isms. Because PS is such a weird mismash of things, the ecosystem generally consists of people who don't even try to understand what's going on, but just hack some stuff together until it kind of works. This makes online resources, well, less useful than they could be. Writing stuff that works like native Cmdlets is weird. You can make functions, but they're not entirely the same, and if you really want Cmdlets, you have to use a .NET language. I really wonder why the hell there's such a fundamental difference between functions and Cmdlets, they could just be the same thing. I also wonder why PowerShell can't just be a real .NET language just like all the others. It's a weird half-assed-in-the-middle thing. [0] http://blogs.msdn.com/b/powershell/archive/2007/06/19/get-scriptdirectory.aspx http://blogs.msdn.com/b/powershell/archive/2007/06/19/get-sc...
- Already__Taken 12y ago
  > "find the directory of the currently executing script" Did you miss `$PSScriptRoot` ? Can piping that to split-path help you out? Since PS 2.0 you got to write completely equal cmdlets in PS or .NET there's no different at all anymore. Your link is dated 19 Jun 2007 which would be PS 1.0, 2 years before windows 7 came out. Were on 4.0 now 6 years later maybe it's time for another look. I feel your reference experience with PS is out of date. You get to grips with how the get-help platform works PS is amazingly consistent. Where it isn't is busting out .NET.
  - skrebbel 12y ago
    Hmmm, cool! Indeed my experience is 3-ish years old. I'll give it another chance next time I need something like it! Thanks for pointing this out.
- bkeroack 12y ago
  Here's the thing about PowerShell: the community is not nearly as strong as bash/linux/unix. There's also been a substantial amount of churn between versions. These two things (combined with the insanity that is Technet) result in frequently less-than-helpful Google results when researching a particular problem. More often than not the first Stackoverflow result is either flat out wrong or non-idiomatic. It doesn't help that (as you mentioned) you can do straight .NET stuff in Powershell also, so even if there is a cleaner, native cmdlet available half the Google results for a given problem will be some weird .NET mashup. Also, Windows has it's own bizarre legacy command line tools ("net", "sc", etc.) which predate PS and further convolute any attempt to find the "right" solution to any given problem. In general, if you're using Windows 2012+, 95% of systems administration and programming tasks now have native Powershell cmdlets. There is very little need to dive into .NET or WMI crap anymore, thank God.
  - xorcist 12y ago
    Yeah, I think what you call legacy command line tools are the biggest part of the problem, but the mere fact that there are new and old ways to do things _will_ be a problem in the future. In general, Windows tends to give you an API whereas UNIX historically is data centric. My experience is that I prefer the latter. Greatly. For example, to get change stuff in the AD environment at work, the local windowshead wants me to send the changeset in a home cooked format for his horrible PS muck to parse. Integration with configuration management systems is spotty at best, and if I in two years time need to revisit the change I have to pray that particular backend still exists. If I did it in UNIX I would just accept standard diff:s, keep data version controlled, and be done with it.

Just a bunch: Doing really common things, such as "find the directory of the currently executing script" can only by done by copy-pasting a non-trivial 3-line function from Stack Overflow. In batch (of all scripting languages), it's "%~dp0". Cryptic, yes, but at least it's in there. Similarly, the internet is full of blog posts with 1000-word articles explain how "easy" it is to do something in PowerShell that should've been a one liner to begin with. Basically, the builtins just suck. Batteries included? No way. Someone at the MS marketing department decided that, in order to make PowerShell popular, it has to be cool. As a result, the above-mentioned blog posts contain example code like `echo "I Love PowerShell"`, making it sound amazing that should-be trivial stuff is only a matter of copying five lines of code [0]. In general, writing PS scripts is a really odd mishmash of bash-isms, batch-isms and .NET-isms. Because PS is such a weird mismash of things, the ecosystem generally consists of people who don't even try to understand what's going on, but just hack some stuff together until it kind of works. This makes online resources, well, less useful than they could be. Writing stuff that works like native Cmdlets is weird. You can make functions, but they're not entirely the same, and if you really want Cmdlets, you have to use a .NET language. I really wonder why the hell there's such a fundamental difference between functions and Cmdlets, they could just be the same thing. I also wonder why PowerShell can't just be a real .NET language just like all the others. It's a weird half-assed-in-the-middle thing. [0] http://blogs.msdn.com/b/powershell/archive/2007/06/19/get-scriptdirectory.aspx http://blogs.msdn.com/b/powershell/archive/2007/06/19/get-sc...

Already__Taken 12y ago
> "find the directory of the currently executing script" Did you miss `$PSScriptRoot` ? Can piping that to split-path help you out? Since PS 2.0 you got to write completely equal cmdlets in PS or .NET there's no different at all anymore. Your link is dated 19 Jun 2007 which would be PS 1.0, 2 years before windows 7 came out. Were on 4.0 now 6 years later maybe it's time for another look. I feel your reference experience with PS is out of date. You get to grips with how the get-help platform works PS is amazingly consistent. Where it isn't is busting out .NET.
- skrebbel 12y ago
  Hmmm, cool! Indeed my experience is 3-ish years old. I'll give it another chance next time I need something like it! Thanks for pointing this out.
bkeroack 12y ago
Here's the thing about PowerShell: the community is not nearly as strong as bash/linux/unix. There's also been a substantial amount of churn between versions. These two things (combined with the insanity that is Technet) result in frequently less-than-helpful Google results when researching a particular problem. More often than not the first Stackoverflow result is either flat out wrong or non-idiomatic. It doesn't help that (as you mentioned) you can do straight .NET stuff in Powershell also, so even if there is a cleaner, native cmdlet available half the Google results for a given problem will be some weird .NET mashup. Also, Windows has it's own bizarre legacy command line tools ("net", "sc", etc.) which predate PS and further convolute any attempt to find the "right" solution to any given problem. In general, if you're using Windows 2012+, 95% of systems administration and programming tasks now have native Powershell cmdlets. There is very little need to dive into .NET or WMI crap anymore, thank God.
- xorcist 12y ago
  Yeah, I think what you call legacy command line tools are the biggest part of the problem, but the mere fact that there are new and old ways to do things _will_ be a problem in the future. In general, Windows tends to give you an API whereas UNIX historically is data centric. My experience is that I prefer the latter. Greatly. For example, to get change stuff in the AD environment at work, the local windowshead wants me to send the changeset in a home cooked format for his horrible PS muck to parse. Integration with configuration management systems is spotty at best, and if I in two years time need to revisit the change I have to pray that particular backend still exists. If I did it in UNIX I would just accept standard diff:s, keep data version controlled, and be done with it.