So this is just a sys-admin tool. Not a general purpose scripting language.
It is a general purpose scripting language.
An object-oriented general purpose scripting language with a number of features that makes system administration easier.
One example is DSC. It is a scripting language that can use the DSC *platform* to make sure that target systems are all configured the same way, albeit each with different parameters.
Another example is workflows. Wake me up when bash or python can start a script that can survive system restarts and pick up and continue from where it was when the system restarted, complete with state, variables etc.
Nah. In PowerShell:
iwr "http://server/path/to/file.zip" -outf "${env:TEMP}/file.zip"
You can try to make it look more verbose. But expect to be called out on it.
You can accomplish almost any task with fewer keystrokes in PowerShell compared to bash - and the resulting command will still be more readable.
But if I am going to learn something new, what advantages this powershell has that python does not? Cygwin + bash is cross platform enough for me to switch between ssh windows in linux boxes and my windows desktop.
Desired State Configuration (DSC) that FTFA was about, is definitely one such thing that PowerShell has that python has not. DSC is a *declarative* description of the configuration you want for a target system. You should think more in line of Chef or Puppet than Python. PowerShell DSC for Linux actually *uses* Python.
The idea is that you use PowerShell to define a data structure (much like a Ruby hash) that describes the configuration of the node. DSC will itself resolve dependencies. If you require a feature DSC will ensure that the feature is installed - much like a package manager - but it actually interacts with the package manager. What package managers do not do is to configure the products once they are installed. This could be connection strings, IP addresses, user accounts.
PowerShell DSC for Linux has "resources" for file system, user accounts, text file content, package managers (Yum, Apt, Zypper), scripts, daemons, ssh keys and more. You use those resources to describe how you want a system to look - like a Chef recipe. The resource description can be parameterized (it is just a PowerShell function and can take parameters like PS functions) so that the same resource description can be used for multiple targets with slightly different values.
Once applied, DSC will ensure that the target is set up so that it matches the target. From there on it can also report on drift (e.g. more users created, files deleted/changed etc) and can warn about it and automatically bring the node back to the desired state (undoing the drift).
Wordy is the key issue, look at your average unix app generally all the flags can use a short - or a long -- for the same function.
How about if the unix app allowed only the long form option names - but allowed them to be abbreviated as long as the abbreviation was unambigous? (That's what powershell does)
PS forget that 30+ years of unix shell to near perfection and rolled their own verbose and obtuse creation
That why we still code in assembler and don't use those modern touch screens. Oh wait... (lalalalalalalal! -- fingers in ears, eyes firmly closed)
They will not get bash to work well under windows. The problem is the brain-dead and overcomplicated NTFS permission system. There is no way to get that handled without just as over-complicated and brain-dead "special" tools.
Yes, there is no concept of SUID/setuid on Windows. So there's no sudo "happy go lucky".
1. What is awkward with string parsing? Is this shell aimed at _incompetent_ people?
No, PowerShell is aimed at admins who want *robust* scripts - both the ad-hoc ones they whip up as well as the ones they choose to save. String parsing is extremely brittle, and most bash shell scipters do it the insecure and brittle way because it is easier.
String parsing is often thrown off if presented with unusual characters in file names, if executed in locales where dates and numbers are both generated and parsed different, etc.
2. And that works how on Linux?
OMI is available on Linux. Read the FTFA
3. An IDE in a Shell? Is the syntax so bad that you need an IDE? Or is this another effect of being aimed at incompetents?
You're the incompetent one. There's is no "IDE in a shell". The ISE *is* the shell - much like if you did bash scripting from emacs. The difference is that the ISE will provide you with intellisense (automatic suggestions), help, syntax highlighting, snippets, multiple script panels, integrated source-level debugging (complete with breakpoints, variable inspection etc) and even a command "builder".
4. Aehm, know any mainstream modern shell that does _not_ have excellent documentation?
Most *nix shells have good documentation. PowerShell has good documentation as well. All of the cmdlets have syntax descriptions (automatically generated from metadata), description and multiple examples. In PowerShell even user-defined functions, cmdlets and script files can have the same level of documentation. Comment based help (look it up) makes it super easy to document scripts and functions. And the auto-generated syntax diagrams and parameter descriptions also work for your own script files.
5. Seriously? I found the command syntax exceptionally awkward and badly thought out. I am back to a cygwin console for most things.
PowerShells command syntax is extremely consistent. Cmdlets are *always* of the verb-noun form, and there are only about 40 or so standard "approved" verbs. Parsing of the command parameters is the responsibility of the *shell* not of the commands like in *nix shells. Hence, all commands follow the same convention with no strange outliers like e.g. dd. Parameter names are always "long" - but can be abbreviated as long as the abbreviation is unambigous.
So there could be two groups, those who look to improve their skill, who quickly distance themselves from the group that doesn't. Of course, there will still be wide variance in skill between the members of each group. I'm sure you can think of other ways it could happen.
No, I can't. I started out and I sucked. I got better eventually through experience. In order for it to be truly bimodal, people have to start in either camp A or camp B and end in the same camp they started in. Because if you transition from one to another over time, any point in time will capture a group of people in between the modes. Now, you can argue that people don't spend much time in between those modes but you haven't presented any evidence for that. What's more likely is you have geocities coders on one tail and John Carmack/Linus Torvolds on the other tail. And in between are people like the presenter and I. And since I'm not instantaneously going from bad to good, the reality of the situation is most likely some degree of a normal curve filled with people trying to get better at programming or even just getting better though spending lots of time doing it and learning a little along the way.
For all your attacks on the presenter, your argument of a bi-modal distribution sounds more flawed to me. I would love to see your study and hear your argument.
This guy doesn't know how to measure programming ability, but somehow manages to spend 3000 words writing about it.
To be fair, you can spend a great deal of time talking about something and make progress on the issue without solving it.
For example the current metrics are abysmal so it's worth explaining why they're abysmal. I just was able to delete several thousand lines of JavaScript from one of my projects after a data model change (through code reuse and generalization) -- yet I increased functionality. My manager was confused and thought it was a bad thing to get rid of code like that
Another reason to waste a lot of time talking about a problem without reaching an answer is to elaborate on what the known unknowns are and speculate about the unknown unknowns. Indeed, the point of this article seemed to be to advertise the existence of unknown unknowns to "recruiters, venture capitalists, and others who are actually determining who gets brought into the community."
So he doesn't know......programmer ability might actually be a bi-modal distribution.
Perhaps
If he had collected data to support his hypothesis, then that would have been an interesting article.
But you just said there's no way to measure this
BLISS is ignorance.