4 ms·

The word "easier" in your quote is a lie. Working with text output is easier because it's uniform, conceptually simple and easy to debug. Working with hierarc

The word "easier" in your quote is a lie. Working with text output is easier because it's uniform, conceptually simple and easy to debug. Working with hierarchies of objects is a lot more complicated. Comparing things becomes a nightmare. Working with unknown hierarchies becomes a nightmare. It's a lot harder to work with objects. But, in some situations it's more rewarding because it eliminates certain classes of errors. I.e. you put more work in, and get arguably better results. The problem with PowerShell approach is that it's attempting to do it on the wrong level. The operating system and the programs it runs have to understand structured input and produce structured output. The system also needs to provide serialization protocol so that multiple systems can communicate with each other not breaking the illusion that they are using objects. However, object RPC is not a solved problem... In other words, PowerShell is a pretension. It solves some easy problems and if you don't give it enough thought, you may think that it will solve harder problems too... but it turns out there's some fundamental problem with this approach. So, it's OK to use it as a gimmick, but I would never consider using it as a replacement of Unix shell (no matter how much I hate it).

oblio 4y ago
Why are you working with hierarchies of objects? Are we back in 90s C++ land? PowerShell objects are flat, 99.99% of the time. And when you say compare, you don't compare objects, also 99.99% of the time. You compare attributes.
- crabbone 4y ago
  I don't care if they are flat 99.99% of the time. Also, of course your statistic is invented on the spot and not warranted by any kind of research. Even a slight possibility of hierarchy is a no-go. Because someone will use it. And then it will create a new nightmare of dependencies. If I wanted that, I'd be using Java.
AnIdiotOnTheNet 4y ago
> Working with text output is easier because it's uniform If it is so uniform, why does every command need a dozen switches for modifying their output? Why do we need to use complicated tools like awk to reformat it for input into other commands? Everything you cite as a problem with structured IO is a problem with text too, it just happens to also suffer from in-band signaling issues and be human readable. Oh and of course it doesn't have a standardized structure at all.
- crabbone 4y ago
  > If it is so uniform It is uniform. It is an immutable string. > why does every command need a dozen switches for modifying their output? This question is unrelated to uniformity... Depends on the command I guess? Some do, some don't. Another argument is about how much information you want printed... I mean, when you work with SQL clients you don't just select the entire table every time you want to do something with it, but it doesn't mean that tables are unstructured uniform strings... quite the opposite. > Everything you cite as a problem with structured IO is a problem with text too Can you explain this? I don't see the connection. You make no argument to support this what so ever...
  - AnIdiotOnTheNet 4y ago
    > It is uniform. It is an immutable string. PowerShell objects are uniform too then. They're just a blob of binary. > Another argument is about how much information you want printed That's the thing, though, when I'm passing it to another program for further processing that is entirely different than formatting the output. PowerShell has commandlets you tack on the end of a pipeline for formatting the output. In between commands they have standardized objects. > Can you explain this? > Working with hierarchies of objects is a lot more complicated. Hierarchies exist in textural output too! And they are indeed a pain in the ass to deal with. In fact, much more so since they aren't adhering to a standardized structure and use in-band signaling. > The operating system and the programs it runs have to understand structured input and produce structured output. Same with text, it's just that the "structure" is completely ad-hoc with no standardization and using in-band signaling that often requires a lot of error-prone manipulation to adapt between commands.
    - crabbone 4y ago
      No, PowerShell objects have different types. They are not uniform in the way immutable strings are uniform. You can have type errors in PowerShell because of that, but you cannot have type errors in Shell, because, well, everything is the same type. > Hierarchies exist in textural output too! Dealing with immutable strings instead of hierarchies allows you to ignore the fact that there's a hierarchy encoded in text. Maybe it's there, maybe not. I don't care. My tools allow me not to care. Your's don't. That's the point. > Same with text, it's just that the "structure" No, it's not the same. Read again.
auxym 4y ago
When reading a shell script, it's way clearer for me to understand what `$file.LastWriteTime` does, compared to extracting a column by numerical index from the text output of `ls` with cut or awk. Yes, writing powershell tends to be more verbose. But reading scripts is so much better, and from my experience larger scripts are much more maintainable. Powershell can enfore types in function arguments, for example.
- crabbone 4y ago
  You are jumping on a very surface-level simple example. Also, you seem to misunderstand what UNIX Shell does (hint, ls and awk are not part of UNIX Shell, so, forward your complaints about ls and awk to the respective authors of those tools). > But reading scripts is so much better, and from my experience larger scripts are much more maintainable. What kind of experience do you have maintaining shell scripts? I maintain a management product that is installable on systems all the way back to RHEL6 (and family), and similarly SLES12, Ubuntu18. The overall matrix of systems and product versions I have to maintain is 20 different OS x product combinations. Most of my maintenance work goes into things like "the release of system X broke the systemd interface to LVM by means of starting udev service too early, now we need to make an exception for this system by altering its configuration somewhere". In order to reduce the burden of maintenance going forward, I need to write scripts that are as generic as possible. If ntpd service was replace by chrony in some distro, I want to have as little code to modify as possible to adjust to the new reality. I don't want to write adapter and factory and other "architecture" for each such change. If I did that, the product cost would skyrocket, while development time plummeted. This would, basically, spell the end for this product. Customers know the risks and accept them. And that is the unfortunate reality of it... But, if I had to change anything about it, I would never choose objects. This is just replacing one problem with another with very little benefit. What I would like is something like Erlang: records with a handful of predefined atomic types. Objects will bring too much of unnecessary problems with them. > Powershell can enfore types in function arguments, I know. This is awful. Especially for maintenance.
  - majkinetor 4y ago
    > Also, you seem to misunderstand what UNIX Shell does (hint, ls and awk are not part of UNIX Shell, so, forward your complaints about ls and awk to the respective authors of those tools). Semantics. Nobody uses bash without those, and having different variants on them with different variants of regex is most troubling. Contrary to that, in pwsh it is recognized that those should be part of the shell that will behave the same on any OS. U ofcourse left out tone of those that come OTB in pwsh (like html/markdown/json/csv/sql readers and exporters vs jq,pandoc,usql,whatever) > But, if I had to change anything about it, I would never choose objects. This is just replacing one problem with another with very little benefit. You keep saying that without any evidence whatsoever. Its just a personal taste and you should declare it as such. > Powershell can enfore types in function arguments >> I know. This is awful. Especially for maintenance. It looks to me that you dont actually have programming background, and that is the reason you say things like that. Your bash scripts the way you described them would probably be heavily reviewed and massaged where I work, for them to be accepted.
majkinetor 4y ago
> Working with hierarchies of objects is a lot more complicated. Compared to a flat list of related strings? No, its not. Its like saying that categorisation is worst then keeping everything in large bin. > Comparing things becomes a nightmare. Comparing objects deeply can be done in one line. If anything is nightmare, its people who judge without RTFM. > So, it's OK to use it as a gimmick I am amazed about lack of recognition on amount of work that MS and community have put into it (during two decades of gimmicking) :)
- crabbone 4y ago
  > I am amazed about lack of recognition on amount of work that MS and community I'm amazed by how irrelevant all MS products are without a fault when it comes to catering to people who are on the more experienced and knowledgeable end of the spectrum. Their products seem to always completely misunderstand the target audience, but bruteforce their way in nevertheless due to the huge investment in marketing and "grease" to secure deals. In a way, it's very similar to that last showing of Tesla trucks, where it became apparent to truck drivers that whoever designed them simply didn't know what truck drivers value or need. So, Tesla trucks are no joke to design. Definitely, a lot of effort went into making them, and yet they fail on very simple stuff like having enough room to put your dirty shoes away. In a very similar way, every product by MS I ever touched was usually decently invested in (outside of things like MS Outlook, or MS Word original file format etc.), decently tested, decently documented and... completely irrelevant in any context I could think of applying it. I use various shells daily for a huge number of tasks. My shell history just for a single terminal may be couple hundreds lines a day (but usually I have several tmux sessions in several ascii-term buffers in Emacs open with typically 6-10 buffers per tmux session). I do write some reusable Shell code too, but less often. As a general infra / system person I have to touch every aspect of the system, be it storage, virtualization, networking, user management... and there simply isn't any place in any of that where I'd say "well, PowerShell seems like a good fit". There's always an obvious way to do things better without it. That's not to say I don't want my tools to improve -- far from it. There are plenty of things that Unix Shell gets wrong. None of those problems are addressed by PowerShell. Like I said, it's a gimmick for MS Windows users. Maybe it makes the experience of using MS Windows more palatable -- I don't even want to know. On a very rare case, like when a relative asks me to help them with their computer, I see the horror show that MS Windows is, and I want none of that stuff.

oblio 4y ago

Why are you working with hierarchies of objects? Are we back in 90s C++ land? PowerShell objects are flat, 99.99% of the time. And when you say compare, you don't compare objects, also 99.99% of the time. You compare attributes.

crabbone 4y ago
I don't care if they are flat 99.99% of the time. Also, of course your statistic is invented on the spot and not warranted by any kind of research. Even a slight possibility of hierarchy is a no-go. Because someone will use it. And then it will create a new nightmare of dependencies. If I wanted that, I'd be using Java.

AnIdiotOnTheNet 4y ago

> Working with text output is easier because it's uniform If it is so uniform, why does every command need a dozen switches for modifying their output? Why do we need to use complicated tools like awk to reformat it for input into other commands? Everything you cite as a problem with structured IO is a problem with text too, it just happens to also suffer from in-band signaling issues and be human readable. Oh and of course it doesn't have a standardized structure at all.

crabbone 4y ago
> If it is so uniform It is uniform. It is an immutable string. > why does every command need a dozen switches for modifying their output? This question is unrelated to uniformity... Depends on the command I guess? Some do, some don't. Another argument is about how much information you want printed... I mean, when you work with SQL clients you don't just select the entire table every time you want to do something with it, but it doesn't mean that tables are unstructured uniform strings... quite the opposite. > Everything you cite as a problem with structured IO is a problem with text too Can you explain this? I don't see the connection. You make no argument to support this what so ever...
- AnIdiotOnTheNet 4y ago
  > It is uniform. It is an immutable string. PowerShell objects are uniform too then. They're just a blob of binary. > Another argument is about how much information you want printed That's the thing, though, when I'm passing it to another program for further processing that is entirely different than formatting the output. PowerShell has commandlets you tack on the end of a pipeline for formatting the output. In between commands they have standardized objects. > Can you explain this? > Working with hierarchies of objects is a lot more complicated. Hierarchies exist in textural output too! And they are indeed a pain in the ass to deal with. In fact, much more so since they aren't adhering to a standardized structure and use in-band signaling. > The operating system and the programs it runs have to understand structured input and produce structured output. Same with text, it's just that the "structure" is completely ad-hoc with no standardization and using in-band signaling that often requires a lot of error-prone manipulation to adapt between commands.
  - crabbone 4y ago
    No, PowerShell objects have different types. They are not uniform in the way immutable strings are uniform. You can have type errors in PowerShell because of that, but you cannot have type errors in Shell, because, well, everything is the same type. > Hierarchies exist in textural output too! Dealing with immutable strings instead of hierarchies allows you to ignore the fact that there's a hierarchy encoded in text. Maybe it's there, maybe not. I don't care. My tools allow me not to care. Your's don't. That's the point. > Same with text, it's just that the "structure" No, it's not the same. Read again.

auxym 4y ago

When reading a shell script, it's way clearer for me to understand what `$file.LastWriteTime` does, compared to extracting a column by numerical index from the text output of `ls` with cut or awk. Yes, writing powershell tends to be more verbose. But reading scripts is so much better, and from my experience larger scripts are much more maintainable. Powershell can enfore types in function arguments, for example.

crabbone 4y ago
You are jumping on a very surface-level simple example. Also, you seem to misunderstand what UNIX Shell does (hint, ls and awk are not part of UNIX Shell, so, forward your complaints about ls and awk to the respective authors of those tools). > But reading scripts is so much better, and from my experience larger scripts are much more maintainable. What kind of experience do you have maintaining shell scripts? I maintain a management product that is installable on systems all the way back to RHEL6 (and family), and similarly SLES12, Ubuntu18. The overall matrix of systems and product versions I have to maintain is 20 different OS x product combinations. Most of my maintenance work goes into things like "the release of system X broke the systemd interface to LVM by means of starting udev service too early, now we need to make an exception for this system by altering its configuration somewhere". In order to reduce the burden of maintenance going forward, I need to write scripts that are as generic as possible. If ntpd service was replace by chrony in some distro, I want to have as little code to modify as possible to adjust to the new reality. I don't want to write adapter and factory and other "architecture" for each such change. If I did that, the product cost would skyrocket, while development time plummeted. This would, basically, spell the end for this product. Customers know the risks and accept them. And that is the unfortunate reality of it... But, if I had to change anything about it, I would never choose objects. This is just replacing one problem with another with very little benefit. What I would like is something like Erlang: records with a handful of predefined atomic types. Objects will bring too much of unnecessary problems with them. > Powershell can enfore types in function arguments, I know. This is awful. Especially for maintenance.
- majkinetor 4y ago
  > Also, you seem to misunderstand what UNIX Shell does (hint, ls and awk are not part of UNIX Shell, so, forward your complaints about ls and awk to the respective authors of those tools). Semantics. Nobody uses bash without those, and having different variants on them with different variants of regex is most troubling. Contrary to that, in pwsh it is recognized that those should be part of the shell that will behave the same on any OS. U ofcourse left out tone of those that come OTB in pwsh (like html/markdown/json/csv/sql readers and exporters vs jq,pandoc,usql,whatever) > But, if I had to change anything about it, I would never choose objects. This is just replacing one problem with another with very little benefit. You keep saying that without any evidence whatsoever. Its just a personal taste and you should declare it as such. > Powershell can enfore types in function arguments >> I know. This is awful. Especially for maintenance. It looks to me that you dont actually have programming background, and that is the reason you say things like that. Your bash scripts the way you described them would probably be heavily reviewed and massaged where I work, for them to be accepted.

majkinetor 4y ago

> Working with hierarchies of objects is a lot more complicated. Compared to a flat list of related strings? No, its not. Its like saying that categorisation is worst then keeping everything in large bin. > Comparing things becomes a nightmare. Comparing objects deeply can be done in one line. If anything is nightmare, its people who judge without RTFM. > So, it's OK to use it as a gimmick I am amazed about lack of recognition on amount of work that MS and community have put into it (during two decades of gimmicking) :)

crabbone 4y ago
> I am amazed about lack of recognition on amount of work that MS and community I'm amazed by how irrelevant all MS products are without a fault when it comes to catering to people who are on the more experienced and knowledgeable end of the spectrum. Their products seem to always completely misunderstand the target audience, but bruteforce their way in nevertheless due to the huge investment in marketing and "grease" to secure deals. In a way, it's very similar to that last showing of Tesla trucks, where it became apparent to truck drivers that whoever designed them simply didn't know what truck drivers value or need. So, Tesla trucks are no joke to design. Definitely, a lot of effort went into making them, and yet they fail on very simple stuff like having enough room to put your dirty shoes away. In a very similar way, every product by MS I ever touched was usually decently invested in (outside of things like MS Outlook, or MS Word original file format etc.), decently tested, decently documented and... completely irrelevant in any context I could think of applying it. I use various shells daily for a huge number of tasks. My shell history just for a single terminal may be couple hundreds lines a day (but usually I have several tmux sessions in several ascii-term buffers in Emacs open with typically 6-10 buffers per tmux session). I do write some reusable Shell code too, but less often. As a general infra / system person I have to touch every aspect of the system, be it storage, virtualization, networking, user management... and there simply isn't any place in any of that where I'd say "well, PowerShell seems like a good fit". There's always an obvious way to do things better without it. That's not to say I don't want my tools to improve -- far from it. There are plenty of things that Unix Shell gets wrong. None of those problems are addressed by PowerShell. Like I said, it's a gimmick for MS Windows users. Maybe it makes the experience of using MS Windows more palatable -- I don't even want to know. On a very rare case, like when a relative asks me to help them with their computer, I see the horror show that MS Windows is, and I want none of that stuff.