7 ms·

That is not quite right. At the end of the day it is all about automation. But we took the position that the way Admins automate is by scripting the things th

That is not quite right. At the end of the day it is all about automation. But we took the position that the way Admins automate is by scripting the things that they do in an interactive shell. Bruce Payette had a great way of saying it - he said that the lifecycle of 99% of scripts starts at the prompt and ends at the carriage return. Then, somethings you want to codify things so you put it into a script. Then as the function becomes more used and more important, you want to make it more and more formal without having to throw everything away and start with a new language. So YES and interactive shell is important but it is important as a stepping stone to automation. That is the PowerShell mindset. Jeffrey Snover [MSFT]

lucb1e 10y ago
That is not quite right either. I enter about 200 commands on a normal workday and write maybe two scripts a month in a shell language. A shell language should be a shell language, it's not merely a stepping stone to write a script after using a command just once. If that's what I'm looking for I'll use Python. And from the other side, Python would be a terrible shell (by default), and that's fine because that's not what it's used for. If Powershell is made for both, it has to make compromises both as a shell language and as a scripting language. This is one of the things that annoy me about the Windows ecosystem: it ships with no languages beyond a shell, which makes scripting for it very annoying, and you can't even install a language of choice via a package manager (one has to go find a download somewhere on the web).
- omaranto 10y ago
  I thought Windows shipped with .NET which includes a command line C# compiler, csc.exe.
  - ygra 10y ago
    The current C# compiler is no longer distributed as part of .NET. They're separate again (as is MSBuild).
- aeorgnoieang 10y ago
  Windows did ship with VBScript (and probably does still). You can also install languages via a package manager; an example: - https://chocolatey.org/packages?q=python https://chocolatey.org/packages?q=python
  - lucb1e 10y ago
    After installing a third party bootstrapping program. I suppose that's as close as it gets. Windows still ships with VBScript, but it's not a language I'd want to look into either. Everyone that has worked with it sighs when it comes up and nobody actually uses it for automation as far as I know (everything's either powershell, good old batch scripts, or custom .NET software).
- Jayku1 10y ago
  This is a really strange argument -- he's saying that PowerShell was designed so that you could more easily move from shell to script to library ... Your counter is -- you don't do that? Of course you don't, because your shell is bash. That's exactly the point. If your shell is bash, when you write a script you use a different language. What if there was a shell where you could actually script ... You're absolutely right, PowerShell is made for both, and it has made compromises (like using comparison operators like -eq instead of ==). Compromises are not inherently bad.
  - lucb1e 10y ago
    > Your counter is -- you don't do that? Of course you don't, because your shell is bash. Yeah of course I'd use Bash because Powershell only just became available for other platforms, but that's not my point. I understood his point like this: the grandparent of his post said powershell has some bad things for scripting. Someone responded to that by saying it's not just for scripting. He said something which I understand as 'that's not quite right, I see a command as a stepping stone to writing a script', To which I finally responded 'I enter a lot of commands but rarely write scripts in [my interpreter of choice's language] because that language just isn't that great, and that's fine because the language is great for its purpose: command line usage'. And compromises are inherently bad (in a way), that's the definition of a compromise: there are two or more mutually exclusive options and different parties have different first choices. Since they're mutually exclusive, a compromise must be made which is acceptable for both, but it's the first choice of neither (or at most one of them). Compromises are necessary for a dual-use language, but they don't make it prettier for both usages either.
  - Graphon1 10y ago
    > it has made compromises (like using comparison operators like -eq instead of ==). wat. The use of -eq instead of == is a compromise? I don't get that.
  - dragonwriter 10y ago
    > If your shell is bash, when you write a script you use a different language. The number of bash scripts I see for various -n-x related tasks suggests that this is substantially untrue; people do, in fact, do scripts in bash. > What if there was a shell where you could actually script ... I can't think of any shell that you can't script. OTOH, interactive use and scripting are substantially different use cases, so it really makes sense to have both interactive-optimized languages that may be usable in script and scripting languages that may be usable interactively, but focus use of each in their optimized role.
- blakeyrat 10y ago
  You could just use WSH (Windows Scripting Host) with either VBScript or JScript the way you've always been able to. AFAIK, Windows has shipped with that scripting solution since like Windows 2000 or possibly even earlier.
  - lucb1e 10y ago
    I noticed that on old computers (Windows 95, I think, and certainly 2000 and XP) where it would classify .js files as executables. I was about 11-14 so I didn't understand much of Windows at the time, let alone in a foreign language (I'm Dutch) when I wasn't even allowed to use the Internet (dialing up was expensive per-minute stuff), but yeah I remember that. Still, I've never heard of anyone using Javascript or VBScript to automate anything. It's either powershell (these days), cmd scripts or custom .NET software. I've never even heard anyone mention using javascript in Windows (until apps came around in Windows 8) and vbs is only ever patchwork for legacy third-party software products as far as I've seen in my sysadmin days.
    - blakeyrat 10y ago
      > Still, I've never heard of anyone using Javascript or VBScript to automate anything. Well thousands of companies have done it, so. I don't know what to tell you.
    - Graphon1 10y ago
      > I've never heard of anyone using Javascript or VBScript to automate anything. as just one example, It's common to include JavaScript or VBScript steps in Windows installers. You would never know it, if you ran an installer that used a script to automate a few things.
- brazzledazzle 10y ago
  You're correcting Jeffrey Snover about the point of Powershell. I suspect that the guy that invented it and championed it through years of resistance at Microsoft probably knows what is or isn't intended with Powershell.
  - lucb1e 10y ago
    Besides mirroring the condescending tone, I was mentioning that in my (GNU/Linux) experience -- which is a lot more command-line oriented than Windows -- it's not true what he's saying. I use a lot of commands and very few of them become scripts, thus the conclusion that it's not merely a stepping stone. A command line language can have different features than a good scripting language. Further I was remarking on the limitation of Windows which ships with a "one size must fit all" language: the language used by their shell (and now there's a 2.0 version of that, called powershell). I'm sure he knows a lot more than me about a lot of powershell-related things. Still, beyond him being (according to you) the inventor and "champion" of powershell, there's nothing that tells me they did UX research into this, so I added my experience because it differs from his viewpoint.
    - brazzledazzle 10y ago
      I think you're misreading what was exchanged. That is unless you're arguing with him about the intent behind the design of a product you had no part in creating. He was replying to "The point of PowerShell..." not, "The point of shells...". He was simply correcting someone who misinterpreted the intent. I think you're also reading tone into his message that's not there. He's been very chill and helpful in this thread even in reply to open hostility. I'm not sure what "according to you" means, but you can verify it yourself. Feel free to read Wikipedia or you can probably find one of his talks about it on youtube.
toyg 10y ago
As one of those enterprise pseudo-sysadmin-scripting-guy, I do agree with the sentiment; and I think the fundamental object-ness of PS was nice and the emphasis on docstrings is nice. However, I still think a python-like syntax would have been miles better. As much as I tried, I just can't get into Powershell -- way too many special characters look awfully "dirty", and $vars give me PHP/Perl-induced PTSD. Deployment is also a bit of a pain.

lucb1e 10y ago

That is not quite right either. I enter about 200 commands on a normal workday and write maybe two scripts a month in a shell language. A shell language should be a shell language, it's not merely a stepping stone to write a script after using a command just once. If that's what I'm looking for I'll use Python. And from the other side, Python would be a terrible shell (by default), and that's fine because that's not what it's used for. If Powershell is made for both, it has to make compromises both as a shell language and as a scripting language. This is one of the things that annoy me about the Windows ecosystem: it ships with no languages beyond a shell, which makes scripting for it very annoying, and you can't even install a language of choice via a package manager (one has to go find a download somewhere on the web).

omaranto 10y ago
I thought Windows shipped with .NET which includes a command line C# compiler, csc.exe.
- ygra 10y ago
  The current C# compiler is no longer distributed as part of .NET. They're separate again (as is MSBuild).
aeorgnoieang 10y ago
Windows did ship with VBScript (and probably does still). You can also install languages via a package manager; an example: - https://chocolatey.org/packages?q=python https://chocolatey.org/packages?q=python
- lucb1e 10y ago
  After installing a third party bootstrapping program. I suppose that's as close as it gets. Windows still ships with VBScript, but it's not a language I'd want to look into either. Everyone that has worked with it sighs when it comes up and nobody actually uses it for automation as far as I know (everything's either powershell, good old batch scripts, or custom .NET software).
Jayku1 10y ago
This is a really strange argument -- he's saying that PowerShell was designed so that you could more easily move from shell to script to library ... Your counter is -- you don't do that? Of course you don't, because your shell is bash. That's exactly the point. If your shell is bash, when you write a script you use a different language. What if there was a shell where you could actually script ... You're absolutely right, PowerShell is made for both, and it has made compromises (like using comparison operators like -eq instead of ==). Compromises are not inherently bad.
- lucb1e 10y ago
  > Your counter is -- you don't do that? Of course you don't, because your shell is bash. Yeah of course I'd use Bash because Powershell only just became available for other platforms, but that's not my point. I understood his point like this: the grandparent of his post said powershell has some bad things for scripting. Someone responded to that by saying it's not just for scripting. He said something which I understand as 'that's not quite right, I see a command as a stepping stone to writing a script', To which I finally responded 'I enter a lot of commands but rarely write scripts in [my interpreter of choice's language] because that language just isn't that great, and that's fine because the language is great for its purpose: command line usage'. And compromises are inherently bad (in a way), that's the definition of a compromise: there are two or more mutually exclusive options and different parties have different first choices. Since they're mutually exclusive, a compromise must be made which is acceptable for both, but it's the first choice of neither (or at most one of them). Compromises are necessary for a dual-use language, but they don't make it prettier for both usages either.
- Graphon1 10y ago
  > it has made compromises (like using comparison operators like -eq instead of ==). wat. The use of -eq instead of == is a compromise? I don't get that.
- dragonwriter 10y ago
  > If your shell is bash, when you write a script you use a different language. The number of bash scripts I see for various -n-x related tasks suggests that this is substantially untrue; people do, in fact, do scripts in bash. > What if there was a shell where you could actually script ... I can't think of any shell that you can't script. OTOH, interactive use and scripting are substantially different use cases, so it really makes sense to have both interactive-optimized languages that may be usable in script and scripting languages that may be usable interactively, but focus use of each in their optimized role.
blakeyrat 10y ago
You could just use WSH (Windows Scripting Host) with either VBScript or JScript the way you've always been able to. AFAIK, Windows has shipped with that scripting solution since like Windows 2000 or possibly even earlier.
- lucb1e 10y ago
  I noticed that on old computers (Windows 95, I think, and certainly 2000 and XP) where it would classify .js files as executables. I was about 11-14 so I didn't understand much of Windows at the time, let alone in a foreign language (I'm Dutch) when I wasn't even allowed to use the Internet (dialing up was expensive per-minute stuff), but yeah I remember that. Still, I've never heard of anyone using Javascript or VBScript to automate anything. It's either powershell (these days), cmd scripts or custom .NET software. I've never even heard anyone mention using javascript in Windows (until apps came around in Windows 8) and vbs is only ever patchwork for legacy third-party software products as far as I've seen in my sysadmin days.
  - blakeyrat 10y ago
    > Still, I've never heard of anyone using Javascript or VBScript to automate anything. Well thousands of companies have done it, so. I don't know what to tell you.
  - Graphon1 10y ago
    > I've never heard of anyone using Javascript or VBScript to automate anything. as just one example, It's common to include JavaScript or VBScript steps in Windows installers. You would never know it, if you ran an installer that used a script to automate a few things.
brazzledazzle 10y ago
You're correcting Jeffrey Snover about the point of Powershell. I suspect that the guy that invented it and championed it through years of resistance at Microsoft probably knows what is or isn't intended with Powershell.
- lucb1e 10y ago
  Besides mirroring the condescending tone, I was mentioning that in my (GNU/Linux) experience -- which is a lot more command-line oriented than Windows -- it's not true what he's saying. I use a lot of commands and very few of them become scripts, thus the conclusion that it's not merely a stepping stone. A command line language can have different features than a good scripting language. Further I was remarking on the limitation of Windows which ships with a "one size must fit all" language: the language used by their shell (and now there's a 2.0 version of that, called powershell). I'm sure he knows a lot more than me about a lot of powershell-related things. Still, beyond him being (according to you) the inventor and "champion" of powershell, there's nothing that tells me they did UX research into this, so I added my experience because it differs from his viewpoint.
  - brazzledazzle 10y ago
    I think you're misreading what was exchanged. That is unless you're arguing with him about the intent behind the design of a product you had no part in creating. He was replying to "The point of PowerShell..." not, "The point of shells...". He was simply correcting someone who misinterpreted the intent. I think you're also reading tone into his message that's not there. He's been very chill and helpful in this thread even in reply to open hostility. I'm not sure what "according to you" means, but you can verify it yourself. Feel free to read Wikipedia or you can probably find one of his talks about it on youtube.

toyg 10y ago

As one of those enterprise pseudo-sysadmin-scripting-guy, I do agree with the sentiment; and I think the fundamental object-ness of PS was nice and the emphasis on docstrings is nice. However, I still think a python-like syntax would have been miles better. As much as I tried, I just can't get into Powershell -- way too many special characters look awfully "dirty", and $vars give me PHP/Perl-induced PTSD. Deployment is also a bit of a pain.