Visual Studio Code 1.9

I assumed the idea was also to eventually to get some users to move to the "real" visual studio, which I ended up doing at least to debug C++, except the vs editor is so much worse!

For example, I use Ctrl+D for multiple editing all the time and I converted other people to vscode based on that feature alone, yet it does not exist in visual studio...

I find Powershell non intuitive to learn honestly, Bash just clicks with me way more for some reason.

Two things to add:

The settings files now have intellisense in them so you don't have to lookup each option.

You can also have a separate settings.json file for that project and check it into git inside the .vscode folder and make those same settings available to your entire team.

We use that in every project and it is great.

If you mostly just want the memorized shortcuts to work, they tend to work OK in VSCode, Atom, IntelliJ and even Emacs - Spacemacs is even a better ViM for some.

I had been a full-time Linux (desktop) user for more than 10 years, and only recently made a transition to Windows. As I'm nowhere proficient at using PowerShell I might be overrating it a bit, as the grass is always greener on the other side. Anyways, what I found to be satisfying while using PS were:

1. The input/output is done using objects. I know that "inter-process communication should be done with text" is the UNIX philosophy, and I appreciated that when using Linux, but after using PS I started to have mixed feelings about that. When using bash/zsh, I typically used awk to extract the data I wanted from the text emitted by an external process. Doing so isn't hard, mostly as simple as using `awk {print $3}` or something like that, but it is still a bit annoyance and more importantly, vulnerable to the changes in the output format.

PS cmdlets communicate with themselves using objects, so it is very easy to extract some columns out of the command results. For example, when I query about a process in PS:

  PS> Get-Process -Name chrome
  
  Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
  -------  ------    -----      -----     ------     --  -- -----------
      362      80   169636     109896  36,411.16    484   1 chrome
      497     113   274988     132544   5,161.00    656   1 chrome
      404      84    87444      55356     303.56    764   1 chrome

If I want to extract CPU time and process ID:

  PS> Get-Process -Name chrome | Format-Table -Property cpu,id
  
           CPU    Id
           ---    --
  36441.265625   484
    5163.09375   656
      303.5625   764

Let's see what processes consumed the CPU most!

  PS> ps chrome | sort cpu -descending | select -first 3
  
  Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
  -------  ------    -----      -----     ------     --  -- -----------
     1186     317  1876160    1055016  88,462.64  10524   1 chrome
     1023      88  1825008     668684  37,740.92   6128   1 chrome
      362      80   155776      64560  36,848.00    484   1 chrome

As you can see, I can simply specify the column name(s).

This is probably why many Linux commands have detailed options to limit displayed information. For example, `uname` has -s, -r, -m, -p, and many others that are just portions of -a. If it were in PS there would be no other options than -a and users could utilize it accordingly. Likewise `ps` has many options just to control the output which is again not necessary in the PS's side.

Also due to the probable scripts that may be reliant on the column orders (e.g. my script assumes the third column to be always the one I wanted, because I hard-coded `awk {print $3}` in there), it is very hard to change the layout of the output in Linux commands. In PS there is no layout in the first place, so this backward compatibility concern doesn't exist.

2. Command names are much clearer. Many names are pretty descriptive so I don't have to remember the exact abbreviated forms, but at the same time they provide shorter aliases. For example `Get-Process` can also be called `ps`. bash/zsh can also benefit from this by manually assisning aliases, but I believe "sane defaults" should be long-descriptive names first, and abbreviated forms later.

3. Much more objected-oriented design. Say for example you want to get the last modified date of a file. In Linux I'd use `stat` and somehow extract information from it. Or, `stat` may have some option to print mtime so I may have to google for it. In PowerShell, I can use this instead:

  $file = Get-Item C:\Windows\notepad.exe
  $file.LastWriteTime

This also applies to the process example above:

  $processes = Get-Process -Name chrome
  $processes[0].CPU

All of these are benefited by tab completion, so you can easily find what properties any object has. This greatly improves discoverability, so that I don't need to rely on documentations (man pages on Linux, MSDN on Windows).

Not only that, but PS is much closer to a general-purpose programming language than bash/zsh. It has built-in calculations (no need to rely on expr/bc), and it even has some basic type safety, such as:

  PS> 1 + 2
  3
  PS> 1 + "a"
  Cannot convert value "a" to type "System.Int32". Error: "Input string was not in a correct format."
  + 1 + "a"
  + ~~~~~~~
      + CategoryInfo          : InvalidArgument: (:) [], RuntimeException
      + FullyQualifiedErrorId : InvalidCastFromStringToInteger

which might be silently ignored in bash/zsh in most cases. As you can see it even has fixed-width integer types (Int32), which is rarely seen in dynamic languages!

When the logic of my scripts got complicated, I tended to abandon shell scripts and start programming in Python. But after learning PowerShell I'm starting to have a confidence that typical workflows can be implemented in PowerShell, in a readable way. I even think that PS can be utilized as a general-purpose programming language, like, "Python without dependencies", because PS is installed by default on Windows nowadays.

Whoa, my response got unintentionally huge O.o. Hope this helps anyone.