5 ms·

IMO PowerShell is horrible. It is it an object, or not an object. You don't know, unless you know. How about operators? They make ZERO sense (-eq). They went su

IMO PowerShell is horrible. It is it an object, or not an object. You don't know, unless you know. How about operators? They make ZERO sense (-eq). They went supreme extreme on namespaces. I could write a paper on how bad PowerShell is. You can keep it. I'll stick with zsh or bash.

metaltyphoon 3y ago
Ehh debatable. Just two different philosophies. I do think objects > text.
delta_p_delta_x 3y ago
> It is it an object, or not an object. It is always an object. Strings, arrays, paths, the registry—everything can be manipulated as an object.
shiroiushi 3y ago
Um, to be fair, "-eq" is also an operator in bash.
Intralexical 3y ago
> How about operators? They make ZERO sense (-eq). […] I'll stick with zsh or bash. Ah yes. Bash, and its highly intuitive `if /usr/bin/\[ 5 -eq "5" ']'; then :; fi` comparison operators.
- deleted 3y ago
  [deleted]
HeavyStorm 3y ago
Huh... Everything is a object. But that object might be a string. And you don't have to know, you can ask. I get that when everything is text, it becomes simpler to reason about. But you also have to do a lot of maneuvering to get information out of it. PS tries to give you more power. My main gripe with ps is command discoverability: I don't know who thought that the "verb-subject" would be a good idea, because if I type "get-" and tab to auto complete, how the hell will I find the command about networking I want? The learning curve also sucks, but I don't think it's worse than bash. I do remember spending six months with a bash manual tab open in my desktop back when I was starting Linux development. There are also other crazy advantages ps have over bash, like the native ability to understand cmdlets and their parameters, powerful scripting capabilities with decent support for loops, conditionals etc. And I don't event know what to tell you about the operators... They were copied from POSIX, so complaing about then is complaing about bash & co. Finally, PowerShell also let's you access all of the dotnet namespace. This allows you to do a lot of stuff, because you would literally be programing instead of scripting.
- datagrimx 3y ago
  Shells on Linux/Unix everything can be accessed as a file. Everything. In PowerShell it is a object, or maybe a file, or maybe a handle, or a resource, or a string. A complete catastrophe is Az PowerShell. Why isn't everything a object? The answer is the origins of how Windows handles everything. It diverged every time a new hire took over a subsystem. "Not invented by me" ran strong in those days.
butlike 3y ago
PowerShell on *nix is a hellscape realm I wasn't previously aware of.
PH95VuimJjqBqy 3y ago
don't even get me started on PS. try this PS script out clear function Get-Strings1 { @('hello') } function Get-Strings2 { @('hello', 'world!') } (Get-Strings1).Length (Get-Strings2).Length OUTPUT: 5 2 You see, PS will strip away the array for 1-element arrays. (Get-Strings1).Length is 5 because you're really calling Length on the string and not the array (the array doesn't exist at that point). As you can see with (Get-Strings2).Length, if there is more than 1 element it will not do this. and you'll watch different features crash into each other in bizarre ways. For example, everything is an object but if that's the case how do you output log statements to the console since it's also a shell? PS is hosted, the default PS host will print out whatever reaches the "top". Think of your PS code as the "first function" with it's own set of returns. The host will print out whatever your code "returns", but this is consistent all the way down the chain. clear function Get-Strings3 { (Do-Stuff) return 'hello' } function Do-Stuff { Write-Output 'haha' } (Get-Strings3).Length OUTPUT: 2 So your returns can be polluted by downstream function calls, including calls into packages that you don't easily have access to the source for. So you'll eventually start writing defensively. (Do-Stuff) | Out-Null # throws away anything coming out of the function call And consider what we've demonstrated here. That PS will happily remove arrays based upon runtime state and happily add them based upon runtime state. If you're confused about why this still happens even though this version uses the return keyword, remember it's PS which means any silly, preconceived notions you have are out the window. returns does two things. 1. Write-Output 2. Ends execution of the function If you remove the return keyword it will have the exact behavior it did previously because it's the last statement in the function. And yes, that's how easy it is to accidentally write something to the output and thus turn your return value into an array. Since I'm on a roll, 1 last example. clear $arr = @($null, 'hello') $isNull = $arr -eq $null $isNull.GetType() OUTPUT: IsPublic IsSerial Name BaseType -------- -------- ---- -------- True True Object[] System.Array How is the equality operator (-eq) returning an array? You see, PS has been lying to you all this time, arrays in PS aren't arrays. They're wrapper objects that pretend to be an array to give all sorts of cool magic. One of those magic things being it's propensity to forward function calls on the array wrapper to the elements themselves. What it's actually doing is calling -eq on each element (think LINQ select) and returning a new array. Which is useful, you can imagine having a list of COM objects with a name property, you can do a select on the name by just doing ".name" on the array wrapper itself. It has its uses. BUT you can't do that for any properties that are on the array (such as Length). Also, PS allows you to attach functions to objects at runtime, if you were truly evil you could attach a myriad of functions to an array object you handed back and laugh as the poor suckers using your code can't understand why calling .Name doesn't forward like it should. ---- I could go on and on and on about PS. I once built a VPS automation solution in PS. My (naive) thinking at the time was that the remoting capabilities for windows was useful so I may as well build it out in powershell. I maintained that solution for 5 years, 4.5 years in and I was _still_ getting surprised by interactions w/i PS. Here's an exercise for the reader. write a function that will successfully test an input parameter against null for everything. There's a solution.
pjmlp 3y ago
You never used Perl I see.

metaltyphoon 3y ago

Ehh debatable. Just two different philosophies. I do think objects > text.

delta_p_delta_x 3y ago

> It is it an object, or not an object. It is always an object. Strings, arrays, paths, the registry—everything can be manipulated as an object.

shiroiushi 3y ago

Um, to be fair, "-eq" is also an operator in bash.

Intralexical 3y ago

> How about operators? They make ZERO sense (-eq). […] I'll stick with zsh or bash. Ah yes. Bash, and its highly intuitive `if /usr/bin/\[ 5 -eq "5" ']'; then :; fi` comparison operators.

deleted 3y ago
[deleted]

HeavyStorm 3y ago

Huh... Everything is a object. But that object might be a string. And you don't have to know, you can ask. I get that when everything is text, it becomes simpler to reason about. But you also have to do a lot of maneuvering to get information out of it. PS tries to give you more power. My main gripe with ps is command discoverability: I don't know who thought that the "verb-subject" would be a good idea, because if I type "get-" and tab to auto complete, how the hell will I find the command about networking I want? The learning curve also sucks, but I don't think it's worse than bash. I do remember spending six months with a bash manual tab open in my desktop back when I was starting Linux development. There are also other crazy advantages ps have over bash, like the native ability to understand cmdlets and their parameters, powerful scripting capabilities with decent support for loops, conditionals etc. And I don't event know what to tell you about the operators... They were copied from POSIX, so complaing about then is complaing about bash & co. Finally, PowerShell also let's you access all of the dotnet namespace. This allows you to do a lot of stuff, because you would literally be programing instead of scripting.

datagrimx 3y ago
Shells on Linux/Unix everything can be accessed as a file. Everything. In PowerShell it is a object, or maybe a file, or maybe a handle, or a resource, or a string. A complete catastrophe is Az PowerShell. Why isn't everything a object? The answer is the origins of how Windows handles everything. It diverged every time a new hire took over a subsystem. "Not invented by me" ran strong in those days.

butlike 3y ago

PowerShell on *nix is a hellscape realm I wasn't previously aware of.

PH95VuimJjqBqy 3y ago

don't even get me started on PS. try this PS script out clear function Get-Strings1 { @('hello') } function Get-Strings2 { @('hello', 'world!') } (Get-Strings1).Length (Get-Strings2).Length OUTPUT: 5 2 You see, PS will strip away the array for 1-element arrays. (Get-Strings1).Length is 5 because you're really calling Length on the string and not the array (the array doesn't exist at that point). As you can see with (Get-Strings2).Length, if there is more than 1 element it will not do this. and you'll watch different features crash into each other in bizarre ways. For example, everything is an object but if that's the case how do you output log statements to the console since it's also a shell? PS is hosted, the default PS host will print out whatever reaches the "top". Think of your PS code as the "first function" with it's own set of returns. The host will print out whatever your code "returns", but this is consistent all the way down the chain. clear function Get-Strings3 { (Do-Stuff) return 'hello' } function Do-Stuff { Write-Output 'haha' } (Get-Strings3).Length OUTPUT: 2 So your returns can be polluted by downstream function calls, including calls into packages that you don't easily have access to the source for. So you'll eventually start writing defensively. (Do-Stuff) | Out-Null # throws away anything coming out of the function call And consider what we've demonstrated here. That PS will happily remove arrays based upon runtime state and happily add them based upon runtime state. If you're confused about why this still happens even though this version uses the return keyword, remember it's PS which means any silly, preconceived notions you have are out the window. returns does two things. 1. Write-Output 2. Ends execution of the function If you remove the return keyword it will have the exact behavior it did previously because it's the last statement in the function. And yes, that's how easy it is to accidentally write something to the output and thus turn your return value into an array. Since I'm on a roll, 1 last example. clear $arr = @($null, 'hello') $isNull = $arr -eq $null $isNull.GetType() OUTPUT: IsPublic IsSerial Name BaseType -------- -------- ---- -------- True True Object[] System.Array How is the equality operator (-eq) returning an array? You see, PS has been lying to you all this time, arrays in PS aren't arrays. They're wrapper objects that pretend to be an array to give all sorts of cool magic. One of those magic things being it's propensity to forward function calls on the array wrapper to the elements themselves. What it's actually doing is calling -eq on each element (think LINQ select) and returning a new array. Which is useful, you can imagine having a list of COM objects with a name property, you can do a select on the name by just doing ".name" on the array wrapper itself. It has its uses. BUT you can't do that for any properties that are on the array (such as Length). Also, PS allows you to attach functions to objects at runtime, if you were truly evil you could attach a myriad of functions to an array object you handed back and laugh as the poor suckers using your code can't understand why calling .Name doesn't forward like it should. ---- I could go on and on and on about PS. I once built a VPS automation solution in PS. My (naive) thinking at the time was that the remoting capabilities for windows was useful so I may as well build it out in powershell. I maintained that solution for 5 years, 4.5 years in and I was _still_ getting surprised by interactions w/i PS. Here's an exercise for the reader. write a function that will successfully test an input parameter against null for everything. There's a solution.

pjmlp 3y ago

You never used Perl I see.