4 ms·

I don't entirely agree. With traditional shells, you can still use objects, you just have to serialize them to text. jq is perfect for this, you can use it to s

I don't entirely agree. With traditional shells, you can still use objects, you just have to serialize them to text. jq is perfect for this, you can use it to store a serialized object in a variable and then pull things out of it for use with other commands. Example: example="{}" example=$(echo $example | jq .foobar=10) Later on you can pass example.foobar into another program like so: grep $(echo $example | jq .foobar) ... You can write simple helper functions that make this more concise. The beauty of it is that this works with any data format - plaintext, json, csv, etc - you just need a tool to serialize and deserialize it.

kbenson 12y ago
My understanding is that PowerShell is passing around specialized objects that have a few required methods, and some source specific ones. 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). Additionally, dates passed around can be complex types that don't have to lose relevant info such as time zone, regardless of what the default display format is. 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.
- zobzu 12y ago
  powershell is a nice concept and a pretty nice shell, but its also complex due to this. serializing to text just means "everyone must speak the same language" its also complex due to this. And in fact jq does serialize. i'd argue jq is a "one tool, one job" and thus unixy. Its the way the "one job" is seen that differs. After using powershell an bash/etc. for years, i'm still unconvinced which one is the most powerful in the real world. sometimes (most often) its faster/easier to do things with bash, sometimes the convenience of powershell objects is nice (that's where i'd basically use python on linux because of bash limitations). As long as i can parse, grep, etc with jq, and pass it to another tool via a text stream output, im happy. as a human, i find it easy to deal with unstructured or very lightly structured text. Hard to dig through complex structures.
  - kbenson 12y ago
    I understand this, I myself often trade off between bash and Perl. Sometimes I'm using a for loop on a shell expansion to tar directories, sometimes I'm piping an ls to xargs to parellelize a workload, but often I'm piping SQL output to Perl, selecting the records I care about and storing (and/or altering) the relevant fields in a data structure, and outputting the data in a formatted way (such as SQL update/insert statements) or reporting some aggregate information. What I see in PowerShell, which to be truthful I never use (it's not in my common environment), is a less powerful/extensible version of Perl, but optimized for a specific workload, as there's less parsing and manipulation of data required if it's easily available in the formats you need already. Honestly, I still wouldn't use much it if it was installed by default on all UNIX boxes, because Perl fills that need for me, but I recognize what it's trying to do on a conceptual level, and it's similar to what I end up doing every day, so I support that.
    - alttab 12y ago
      You have it backwards. Even though they are similar on a conceptual level to what you do everyday, doing it in Powershell requires buying development tools. And there hasn't been a need to support that monetarily for a while.
      - lmz 12y ago
        What development tools do you need to buy for Powershell? (unless you mean Windows itself).
      - zobzu 12y ago
        hmm i do powershell stuff with "just" windows amd gvim.exe
        alttab 12y ago
        just windows
- useerup 12y ago
  > 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.

kbenson 12y ago

My understanding is that PowerShell is passing around specialized objects that have a few required methods, and some source specific ones. 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). Additionally, dates passed around can be complex types that don't have to lose relevant info such as time zone, regardless of what the default display format is. 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.

zobzu 12y ago
powershell is a nice concept and a pretty nice shell, but its also complex due to this. serializing to text just means "everyone must speak the same language" its also complex due to this. And in fact jq does serialize. i'd argue jq is a "one tool, one job" and thus unixy. Its the way the "one job" is seen that differs. After using powershell an bash/etc. for years, i'm still unconvinced which one is the most powerful in the real world. sometimes (most often) its faster/easier to do things with bash, sometimes the convenience of powershell objects is nice (that's where i'd basically use python on linux because of bash limitations). As long as i can parse, grep, etc with jq, and pass it to another tool via a text stream output, im happy. as a human, i find it easy to deal with unstructured or very lightly structured text. Hard to dig through complex structures.
- kbenson 12y ago
  I understand this, I myself often trade off between bash and Perl. Sometimes I'm using a for loop on a shell expansion to tar directories, sometimes I'm piping an ls to xargs to parellelize a workload, but often I'm piping SQL output to Perl, selecting the records I care about and storing (and/or altering) the relevant fields in a data structure, and outputting the data in a formatted way (such as SQL update/insert statements) or reporting some aggregate information. What I see in PowerShell, which to be truthful I never use (it's not in my common environment), is a less powerful/extensible version of Perl, but optimized for a specific workload, as there's less parsing and manipulation of data required if it's easily available in the formats you need already. Honestly, I still wouldn't use much it if it was installed by default on all UNIX boxes, because Perl fills that need for me, but I recognize what it's trying to do on a conceptual level, and it's similar to what I end up doing every day, so I support that.
  - alttab 12y ago
    You have it backwards. Even though they are similar on a conceptual level to what you do everyday, doing it in Powershell requires buying development tools. And there hasn't been a need to support that monetarily for a while.
    - lmz 12y ago
      What development tools do you need to buy for Powershell? (unless you mean Windows itself).
    - zobzu 12y ago
      hmm i do powershell stuff with "just" windows amd gvim.exe
      - alttab 12y ago
        just windows
useerup 12y ago
> 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.