Hacker News Reader

Comment by integraton | Hacker News Reader

> cmdlets are NOT just .Net classes

Yes they are.

The fact that you (and others I've seen here and elsewhere) continue to believe otherwise further demonstrates how deceptive PowerShell's design is.

What's interesting is that the cmdlet documentation is very clear:

"Cmdlets differ from commands in other command-shell environments in the following ways:

"Cmdlets are instances of .NET Framework classes; they are not stand-alone executables....

"Cmdlets do not generally do their own parsing, error presentation, or output formatting. Parsing, error presentation, and output formatting are handled by the Windows PowerShell runtime."

https://msdn.microsoft.com/en-us/library/ms714395%28v=vs.85%...

View on HN

> Yes they are.

I literally just spoon fed you exactly how to go look for yourself about how cmdlets work and how they're distinct from the .Net classes they represent. I honestly don't know what more I can do.

> The fact that you (and others I've seen here and elsewhere) continue to believe otherwise further demonstrates how deceptive PowerShell's design is.

You realise I understand how Powershell works top to bottom, right? Where are they "deceiving me?" You can yourself can go learn about Powershell's artitecture (you have the tools, I've given them to you, and you clearly have access to the documentation).

> What's interesting is that the cmdlet documentation is very clear:

Wait is your biggest issue that cmdlets are held within DLLs of classes instead of standalone binaries? Because based on the snippets you posted I can only assume that is what your issue is.

Wait, but hold on, how many internal commands do most UNIX shells have? Dozens? Hundreds? Here's a list of them for bash: http://www.gnu.org/software/bash/manual/html_node/Bash-Built...

So why one rule for UNIX and another for Powershell? Why does it matter that you can store multiple commands (cmdlets) inside of a single DLL?

I'm only passingly familiar with PowerShell but really, it's Microsoft, in the bloody documentation, that literally states precisely that cmdlets are instances of .NET Framework classes:

"Cmdlets differ from commands in other command-shell environments in the following ways:

Cmdlets are instances of .NET Framework classes; they are not stand-alone executables.

https://msdn.microsoft.com/en-us/library/ms714395%28v=vs.85%...

We can have an ontological debate about how an instance of an-object-as-a-concept is different from an instance of an-object-as-memory-content but I think that's best left to amateur philosophers.

You're right with the caveat that they can also be powershell scripts.

Anyone arguing that PS isn't really just 'scriptable .Net' is unfamiliar with the more advanced ideas of PS.

PS is different things to different people, but from a pure tech perspective the above is an apt description of PS.

edit:

I should also mention I find the idea of using PS as an example of an easy, intuitive shell to be laughable at best. Anyone who believes that has definitely tried to do much more than simply Get-Item, New-Item, type things. Once you start getting into more advanced things it becomes a hairy mess.

Reply on news.ycombinator.com