[eropple]

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.

[ntakasaki]

Personal anecdote time.

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.

[eropple]

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.

[Locke1689]

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.

[sudioStudio64]

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.

[eropple]

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.

[sudioStudio64]

I really wasn't trying to be condescending.

Comparing it to zah/bash and ruby illustrates my point. It's got some fundamental differences to those environments. Providing a common argument parser is one. PowerShell is actually more than a Shell. Its an environment that can be hosted in a shell. That's my point. Commands are actually objects that are processed by the environment. If you get passed the "I know how things are supposed to work" attitude and look at how PS is meant to be used to administer a large number of windows systems you would see that it makes quite a bit of sense.

It is different then what you are used to and probably been using since you were in university. I wasn't rude or mean. I certainly can't be as indignant about things as you are while I'm on HN because of the downvote brigade. But hey, like you guys always say...you're right and I'm wrong because you have karma. Honestly, I tend to be pretty sharp when reacting to people as well so I'm trying to not take things as personally.

But your appeal to authority doesn't scare me...I've used stuff for a long time too. I just don't think that I'm better than other people because of it.

[eropple]

Comparing PowerShell to REPL environments that make exploring a problem space easy is illustrating your point? Its differences excuse how tragically bad it is at doing shell things? Maybe I come from a different part of town, but I don't consider that an argument.

The job of "administrator" in an IT shop is a largely make-work one that can be done by automated systems and process-aware developers, and as an infrastructure and automation developer I am working towards that goal. PowerShell makes that harder than it absolutely has to be because of how blindingly difficult it is to actually iterate on a problem in a way that can be factored into a reusable process--the actual hands-on-keyboard experience is so stilted and stupid that finding the solution in the exploratory manner I described is significantly harder than it should be. As I've said elsewhere in this tree, it's easier to just solve a problem in C# than try to explore the space in PowerShell and reify it into a script. That's as scathing an indictment of a programming environment as I can make.

And absolutely nobody says that somebody's right because of karma. I've read through some of your posting history, though, and you go to that well a lot. Consider that maybe nobody likes that you play the oppressed martyr.

[pjmlp]

> Visual Studio, still a considerable distance behind even Linux, to say nothing of OS X.

Which wonderful Linux and OS X tools offer the debugging and profiling capabilities of Visual Studio, specially for multi-threaded code?

Which wonderful Linux and OS X tools offer code navigation across large scale enterprise projects and architecture design?

Which wonderful Linux and OS X tools offer UI tooling like XAML and Blend?

[ska]

Your selective quoting is misleading. The post said:

"...even with the plus that is Visual Studio,... "

And you're touting things you value in VS.

I think that he poster was saying that for them the good parts of VS don't make up for other shortcomings of windows as a workstation...

[eropple]

Precisely. I've been seeing a lot of this mendacious quoting lately, what's with this fad?

[pjmlp]

I find that Windows is closer to the Xerox PARC workstation model than UNIX will ever be.

[rbanffy]

Only if you mean "doesn't play well with the other kids".

I have studied the Alto and Star and I can't imagine why you would think they are similar to Windows except in their insularity.

[pjmlp]

Poweshell playing the same role as the workspace/transcript, which access to the whole system, including libraries and running applications. Specially given it is just yet another .NET programming language.

I am not aware of any UNIX shell that offers a REPL like capability by allowing to interact with system libraries, do IPC with existing applications or system devices.

.NET, COM and WinRT play a similar role as the rich programming frameworks Interlisp-D, Smallatalk and Cedar had.

Focus on a mixture of AOT and JIT code for the programming environments, with memory safe languages. Memory unsafe languages currently used on the lower levels and performance hotspots.

An IDE with graphical debuggers and incremental development support, as the main way to develop applications.

Focus on being a good workstation OS first, with server abilities as second focus.

[anewhnaccount]

Eclipse?

[maccard]

What's wrong with powershell?why can't you substitute it, and why is it inferior?

[eropple]

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.

[useerup]

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.

[cookie-monster]

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.

Cheers!

[UK-AL]

You've given no actual information to why it's inferior, other the fact it's not "exploratory". I don't know what that means.

But personally I find working out command names in powershell much more sane, because of the Verb-Noun pair naming convention.

[eropple]

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.

[useerup]

You were called upon to give some examples. Yet all you offer is more hyperbole. One is beginning to suspect that despite your assertion that you "know" Powershell better than most who use it daily, you are actually just a troll.

Yes, I am calling you out. I am challenging you to provide concrete examples where Powershell has less discoverability than bash or zsh. I am challenging you to explain why ISE - an environment designed specifically to combine REPL with script authoring - is "unacceptable".

And please, no more hyperbole or condescending remarks.

[Amezarak]

I'm not sure what he means by exploratory either.

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.

[rspeer]

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.

[WalterGR]

    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`?

[eropple]

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.

[useerup]

> To be honest: no, PowerShell can't (practically) achieve the same composability

PowerShell is much more composable. Just consider how all nix commands must pack insane numbers of output options. In PowerShell - just because of composability - output formatting is not the responsibility of each command - it has been delegated to a small set of general-purpose output format cmdlets.

[pjc50]

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.

Even the path separator is different.

[sudioStudio64]

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.

[Amezarak]

> (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.