It's absolutelly amazing to see, how MS is evolving. Few more steps like that and I really might consider switching back to Windows and giving WinPhone a try...
I did some basic WinPhone development (i'm mostly on linux/unix) and was pleasantly surprised by the smoothness of the tools. I recommend to check it out by building some simple stuff.
I like how management is going, but as someone who fled Windows 8 to Mac OS X (10.9), I couldn't disagree more. I feel like a huge thorn has been removed from my foot and I can now walk normally, after a couple of decades of limping. Of course, I used Cygwin to make Windows seem more like Linux (what I use for server stuff at home and work). Mac OS X for a desktop is still far better than Windows.
Given the direction of MS, I'm hopeful that they'll do some real change under the UI hood of Windows, making it a real alternative to Mac OS X. Some of the apps I need to run (e.g., Lightroom) only work on Windows and Mac.
Not the OP, but for me: use Unix. Cygwin is not a sufficient alternative to having an actual, working Unix that works as I expect it to when I use it, with a decent terminal emulator on top of it. (PowerShell is both non-substitutable and inferior.)
Windows-the-desktop is fine, though I don't like it. Windows-the-workstation is, even with the plus that is Visual Studio, still a considerable distance behind even Linux, to say nothing of OS X.
Have been using Linux off and on since 2000. Later my job required .NET, so got into the MS stack but still kept playing around with Linux for things like IRC bots etc.
Then at work there was a major open source push, and we did a big project using Drupal. Used Eclipse and Netbeans(mostly this), deployed to Ubuntu server for dev and RHEL/CentOS for prod. I can sling Vim but never like Emacs(you need a second nose to type some of the shortcuts!)
I was DevOps because only I in the team had Linux experience beforehand. There were some good things but C# vs. PHP was no contest as was VS vs. Netbeans/Eclipse.
Ubuntu vs. CentOS/RHEL was quite annoying because there were small meaningless fragmentation differences like Apache daemon as httpd in one and apache2 in the other. Really? Why? I found myself raging at them sometimes.
After doing that for a year, back to VS and .NET and it felt like a relief. I liked the power of nginx though which we used as a reverse proxy for the Drupal project.
So you don't like PHP and Eclipse. Sure. Neither do I. I write Scala in IntelliJ, or Ruby in Sublime Text, or even C# deployed on Linux with CoreCLR or Mono. And you're not "DevOps" when you have a little Linux experience, and mixing Ubuntu and CentOS without thinking about the consequences thereof is...well, it's your own bad decision. Historical reasons drive the behaviors of one versus the other. (You should know about historical reasons for things. They're much of why Windows is incoherent, too.)
But, more to my original point: I like .NET. I've been using it since 2005. I have Visual Studio open in Parallels right now. But I do recognize that the environment is a trash fire the moment you consider doing anything remotely outside the lines, and the lack of a serious, user-focused glue system (PowerShell ain't it, it's obviously not designed as a REPL language from the jump) is crippling. Peter Bright over at Ars has suggested reviving the subsystem model for Windows and incorporating a FreeBSD layer, and I'm all for that. Because I don't dislike Windows. I just can't get things done in it.
Working at Microsoft on C# but being a Unix programmer at heart I know what you mean. I'm not of the mind that Unix is strictly superior -- I think most of the operating systems just involve which tradeoffs you want to make -- but I happen to like a fair amount of the Unix tradeoffs and I think that the programmer ecosystem is really valuable.
Which is why I think it's unfortunate that I don't really but that a Unix subsystem is the way to make programming on Windows better. All my problems with Cygwin or git bash all lie on the boundaries of interactions. The most annoying things are when you can't run a batch file in bash or when you launch a Windows program with a Unix-style path and ends up with garbage because no file actually exists with that path on NTFS. Adding transparent proxying or something similar just ends up being more of a pain because now its really difficult to debug when something inevitably goes wrong. Perhaps more importantly, even if you solve the filesystem issues you're still stuck with things like /proc.
Overall, I think I'd rather just have really lightweight and transparent VM access.
PowerShell is fantastic. I get what you are saying, though. You know UNIX at a very deep level and you don't have time to stop and learn how PowerShell works. (its different and has a different model for getting things done. That's all I'm saying.)
If you could stop and take the time to learn the prescribed PowerShell way of doing things... its really very good. I used to be a VMS admin in another life and I've worked with free and commercial *nix and I love it.
Your condescension is unwelcome and wrong besides. I've been using PowerShell since it was called Monad. I am a former Mono contributor and have been using .NET for about a decade--I understand both the APIs and the underlying runtimes, not quite as well as I know the JVM, but close. Despite a strong understanding of both the underlying architecture and the language in question, every time I am forced into using it I have the sinking feeling that my hands are being made stupid in comparison to the ease of exploration of other REPL-based systems, be they zsh/bash/whatever or even just Ruby.
I wouldn't dislike PowerShell as intensely as I do if I didn't know it. It's a convergence of bad design in the small--the grammar and the syntax--and in the large--how exploratory programming at a REPL is actually done. Maybe it's great for sysadmin work where something's on fire and must be addressed right-then-and-there, but I'm a programmer and I work to eliminate the need for sysadmin anythings. A shell is literally just a REPL for recording tasks for automation and desperately needs to not suck at that job.
As for inferior, for what's wrong with it--well, let's start with the easy stuff. The language is not designed to be exploratory and is really hard to write off-the-cuff even when you know it cold. It inherits from .NET in ways that make it actively difficult to type on a REPL (as that's all a shell is). I like .NET, but the BCL is not the right tool for the job and none of the tooling built around PowerShell can compensate for just not being easily written out when I'm exploring a problem by hand. I know PowerShell probably better than most people who use it every day--I'm not an expert but I've studied it at length and used it on the regular for nontrivial tasks--and I can't think in it on the fly. It's a worse solution to a solved problem, for my money, and I'm fairly convinced it was designed to be an RPC layer for GUI apps rather than a way for a skilled and knowledgeable user to interface one's brain with the metal with as little trouble as possible. And that's fine, but that's worse with regards to the things that I care about.
As for substitutability: this should be obvious. I can't substitute it because it isn't interoperable with literally everything else in the stack. It is Microsoft for Microsoft's sake and incompatible with the rest of the non-Microsoft universe in ways that, it must be noted, Apple did not do; while they have proprietary tools in their environments I can still use it with the bog-standard tools that exist on every other Unix machine I ever touch.
PowerShell is supremely explorable. All you need to get started is knowledge about a few cmdlets. Get-Help, Get-Member, Get-Command and Get-Alias then you are in business.
There is nothing about PowerShell that cannot be discovered through those 4 cmdlets.
If you frequently need to dig down to .NET you are doing it wrong.
Contrary to your previous assertions, PowerShell was designed for REPL from the outset, and it achieves that much better than any Unix/Linux shell, bar perhaps fish.
PowerShells commands (cmdlets) are inherently rich on metadata. You cannot create a cmdlet without exposing metadata which is then used by the shell to drive automatic type coercion, syntax charts in help as well as tab completion.
It is so intrinsic to the concept, that you'll automatically get tab completion for your own functions, and even for your own script files.
PowerShell was definitively NOT designed as an RPC layer. You claim to "know PowerShell probably better than most people", and yet you are unaware that PowerShell was specifically designed as a hostable engine.
It is hostable precisely because Microsoft wanted to have reusable script engine which could be used in-process (!) in administrative GUIs.
Unlike traditional shells, PowerShells cmdlets share memory space with the host (the shell when used as REPL) because it SHOULD NOT use RPC to manipulate objects.
You frequently use "appeal to authority" arguments, but the substance of your posts gives you away. You are certainly no expert on PowerShell.
What does 'not designed to be exploratory' mean? How many scripting and shell languages have the introspection that comes with PowerShell, from .NET reflection to simple abstractions like 'Get-Member'? How common is a prescribed and thus simple to discover naming convention such as verb-noun?
I would love to see it in other ecosystems, and the prediction that PS could go open source, along with the recent open sourcing of .NET core and CoreCLR gives me hope.
It's not about the commands. Names, whatever. I learned GNU and BSD command sets cold, names and obscura are not a problem. It's about the experience of using the thing. Everything is so insanely verbose, except when line-noise symbols are injected to break up the monotony, and the editing environment for actually using it is absolute garbage compared to either bash or zsh's emacs/vim modes. You are stuck writing long, complex (not complicated, but complex) commands that can't be easily factored down, with an interface that isn't doing much to help you (and isn't good at the little things besides, ISE is unacceptable compared to a decent terminal emulator like iTerm2). And so iterating--exploring your problem space is unreasonably difficult compared to everybody else in the same space.
A shell is a REPL. If your language makes actually writing things in that REPL hard, it is definitionally bad at Shell Stuff. I find it significantly easier to write code in C# and then transliterate it to PowerShell than to actually write PowerShell. That's a disastrously bad situation for a shell.
I learned Powershell mostly from Get-Help. I can usually figure out where to look for a command based on the naming conventions - essentially (one of x verbs)-(one of x nouns). They aren't always fantastic, but for example, Select-String is a little more obvious than grep.
Are you really asking why you can't substitute PowerShell for a UNIX shell? There is basically no way in which they are compatible.
Even if you decided to re-invent all your UNIX scripts and tools on PowerShell, you'd be missing most of the composable tools that make UNIX what it is.
And PowerShell as a user interface is quite poor compared to, say, a 15-year-old version of GNOME Terminal.
Even if you decided to re-invent all your UNIX scripts and tools
on PowerShell, you'd be missing most of the composable tools
that make UNIX what it is.
PowerShell's composability is based on piping objects rather than piping text.
Do you mean that PowerShell can't achieve the same composability that can be achieved on Unix, or that PowerShell lacks for example `cut`?
To be honest: no, PowerShell can't (practically) achieve the same composability that can be achieved on Windows. Both because of the aforementioned general malaise of writing it throwing up very real roadblocks, but also because not everything under the sun is a .NET application. You get "hack together a text pipeline and hope all your objects implement ToString in a meaningful way" or "break out Visual Studio and write some converters", which is, by my lights, significantly worse than just "hey, everything starts and ends as a stream of bytes, deal with it using the tools we know you have and work with every application you're going to use."
And this is especially egregious with the lack of a Swiss-army-chainsaw scripting language in .NET to begin with.
This is like asking why you can't just run your PHP scripts in Python; they're different languages.
PS is interesting and powerful, but tends to fall at the last hurdle in annoying ways (eg truncate text to window even when diverted into file), and doesn't have the same user community.
Its just not. The problem is that experienced UNIX admins get frustrated when it doesn't work like UNIX. If you take the time to learn how it works it amazing.
> (PowerShell is both non-substitutable and inferior.)
Powershell is certainly not a substitutable shell, but as a terminal emulator, what does it lack that you need as of Windows 10? My only real complaint is the lack of tabbed windows.
Though I am much more experienced with bash than Powershell, everything I've seen indicates that Powershell is anything but inferior. You have to learn new things (the built-in aliases help a little) but throwing around objects instead of text makes so many things less painful. SSH would be nice (I think the closest thing would be WinRM?) but that's coming now too.
I don't think everything needs to be Unix. Unix is great but it's showing its age.
I'm Rails developer - so this all comes to mentioned Unix and set of console tools. Ok, there are workarounds, one can use docker, vagrant, or whatever. I like to work in console as well - and as for now, this is a deal breaker for me.