> My understanding is that PowerShell is passing around specialized objects that have a few required methods, and some source specific ones.
I don't believe that PS objects need to have any specific methods. Maybe only ToString() - but that is always auto implemented.
> The beauty of this is that you can pass massive amounts of data without serializing and unserializing it at every step, and also that they can contain links to other information, such as links to parent objects which may or may not be part of the same list (I have no idea if this is allowed, but it seems a logical extension of the concept).
Well, that's part of it. The fact that there is no need for serialization/deserialization between the commands has some obvious performance benefits (and a few drawbacks). But it is also what enables the perhaps most overlooked but most important characteristics of PowerShell: You can use it in-process to manipulate in-memory objects of the hosting process. This means that you can implement the management functions as PS cmdlets, and still build an admin GUI using those cmdlets but where the GUI is a rich process with in-memory objects that is just passed to cmdlets. Think how a task manager could be written to list the processes on the machine by invoking Get-Process. The objects returned represent the actual processes - complete with methods and properties. The GUI can hold on to those objects, and when you pick one and choose the "Stop" action (for instance) it could pass it as input to Stop-Process (kill). This is actually what a number of product-specific GUIs from Microsoft do, e.g. Exchange.
> The downside is that tools need to buy into this and work with this data stream rather than text, which makes the set of available tools necessarily much smaller.
Yes - it is a new model, and the commands need to support it to take full advantage. There is a "bridge" from the old world to the new in that the "old" command types are simply seen as commands that consume and produce sequences of strings. But yes - there still is some friction. The model works at it best when you can do all of your tasks using cmdlets.
At some level I suspect that PowerShell has been blessed with a rather poor CLI ecosystem on Windows preceding it. It didn't have to knock anything existing from the throne; rather it hit a vacuum and was almost immediately adopted. The same wouldn't have been the case on Linux/Unix.
There is an impressive number of cmdlets available now, however. On my machine "gcm|measure" tells me that there are 1484 commands available. Those are only those distributed from Microsoft, and the cover all sort of administration, firewall, sqlserver, file transfer, disk management, low level network managent, print management, start screen, user management etc. I don't think it is on par with what the Linux/Unix community has available now, but it is getting there, quickly.
I don't believe that PS objects need to have any specific methods. Maybe only ToString() - but that is always auto implemented.
> The beauty of this is that you can pass massive amounts of data without serializing and unserializing it at every step, and also that they can contain links to other information, such as links to parent objects which may or may not be part of the same list (I have no idea if this is allowed, but it seems a logical extension of the concept).
Well, that's part of it. The fact that there is no need for serialization/deserialization between the commands has some obvious performance benefits (and a few drawbacks). But it is also what enables the perhaps most overlooked but most important characteristics of PowerShell: You can use it in-process to manipulate in-memory objects of the hosting process. This means that you can implement the management functions as PS cmdlets, and still build an admin GUI using those cmdlets but where the GUI is a rich process with in-memory objects that is just passed to cmdlets. Think how a task manager could be written to list the processes on the machine by invoking Get-Process. The objects returned represent the actual processes - complete with methods and properties. The GUI can hold on to those objects, and when you pick one and choose the "Stop" action (for instance) it could pass it as input to Stop-Process (kill). This is actually what a number of product-specific GUIs from Microsoft do, e.g. Exchange.
> The downside is that tools need to buy into this and work with this data stream rather than text, which makes the set of available tools necessarily much smaller.
Yes - it is a new model, and the commands need to support it to take full advantage. There is a "bridge" from the old world to the new in that the "old" command types are simply seen as commands that consume and produce sequences of strings. But yes - there still is some friction. The model works at it best when you can do all of your tasks using cmdlets.
At some level I suspect that PowerShell has been blessed with a rather poor CLI ecosystem on Windows preceding it. It didn't have to knock anything existing from the throne; rather it hit a vacuum and was almost immediately adopted. The same wouldn't have been the case on Linux/Unix.
There is an impressive number of cmdlets available now, however. On my machine "gcm|measure" tells me that there are 1484 commands available. Those are only those distributed from Microsoft, and the cover all sort of administration, firewall, sqlserver, file transfer, disk management, low level network managent, print management, start screen, user management etc. I don't think it is on par with what the Linux/Unix community has available now, but it is getting there, quickly.