What exactly can you do from your (presumably since it's HN) Mac that you can't do from Windows that's preventing you from switching now?
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.
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?
"...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...
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.
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.
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.
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.
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.
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.
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.
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.
read this: how bout we just disagree and you leave me alone? there's no need to even reply to this. just leave me alone.
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.
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.
Do you mean that PowerShell can't achieve the same composability that can be achieved on Unix, or that PowerShell lacks for example `cut`?
And this is especially egregious with the lack of a Swiss-army-chainsaw scripting language in .NET to begin with.
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.
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.
But personally I find working out command names in powershell much more sane, because of the Verb-Noun pair naming convention.
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.
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.
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.
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!
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.
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.
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.