7 ms·

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

by 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.
  - crabbone 4y ago
    > Semantics. No. It's not semantics... > Nobody uses bash without those Boy you are so wrong... Of course many do. And those are the people who care the most about what shell can do and how it does it. People you describe are the people who need shell for other reasons, who could probably do away with Perl / Python / Ruby etc. instead. I don't care about that audience. Actually, it would be probably even better if Shell isn't used there at all. Shell has way too many restrictions for that context. > You keep saying that without any evidence whatsoever. Please, read again. I listed the problems earlier: identity (comparison), serialization, methods overload, mutable state, dependency through hierarchies s.a. inheritance. I don't want any of that in a shell, because, someone will definitely use it, and in the most unnecessary place, and it will throw a wrench into the Rube Goldberg machine of Linux shell scripting that's falling apart in many hilarious ways as it is. > It looks to me that you dont actually have programming background Look. An expert! You just discovered my programming backround (or lack of it) by reading a post on the Internet. How quaint! > Your bash scripts the way you described them would probably be heavily reviewed and massaged where I work, for them to be accepted. Lol. You sound like a Web developer with 5 years of experience, who decided that they've seen it all by now, and got a title of "senior developer" which made them feel important and overly confident. Nope. You aren't there yet. The road ahead is long and bumpy. You better curb your enthusiasm of judging others for a while.

by auxym 4y ago

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.
- crabbone 4y ago
  > Semantics. No. It's not semantics... > Nobody uses bash without those Boy you are so wrong... Of course many do. And those are the people who care the most about what shell can do and how it does it. People you describe are the people who need shell for other reasons, who could probably do away with Perl / Python / Ruby etc. instead. I don't care about that audience. Actually, it would be probably even better if Shell isn't used there at all. Shell has way too many restrictions for that context. > You keep saying that without any evidence whatsoever. Please, read again. I listed the problems earlier: identity (comparison), serialization, methods overload, mutable state, dependency through hierarchies s.a. inheritance. I don't want any of that in a shell, because, someone will definitely use it, and in the most unnecessary place, and it will throw a wrench into the Rube Goldberg machine of Linux shell scripting that's falling apart in many hilarious ways as it is. > It looks to me that you dont actually have programming background Look. An expert! You just discovered my programming backround (or lack of it) by reading a post on the Internet. How quaint! > Your bash scripts the way you described them would probably be heavily reviewed and massaged where I work, for them to be accepted. Lol. You sound like a Web developer with 5 years of experience, who decided that they've seen it all by now, and got a title of "senior developer" which made them feel important and overly confident. Nope. You aren't there yet. The road ahead is long and bumpy. You better curb your enthusiasm of judging others for a while.