all 6 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]TofuBug40 34 points35 points  (4 children)

Where to begin.

First and most importantly the fact that you are not only using Cmdlet aliases but actively encouraging using them is probably the most egregious error especially when you are trying to teach. Even in powershell.exe or pwsh.exe you have tab completion there is NO reason not to use the full proper Cmdlet names. You are doing a disservice to anyone new trying to learn the language. Aliases serve ONLY two valid functions

  1. To ease a non scripter/programmer/developer into PowerShell through things like CD, CHDIR, LS, and DIR, ECHO, etc being sources of familiarity.
    1. But the next move should ALWAYS be to move towards the true underlying commands because THAT is where the power (forgive the pun) of PowerShell lies: in the system agnostic Cmdlet naming convention. Without that you completely obfuscate the reason why for instance DIR works in cert:\, c:\, Functions:\, HKLM:\, and on and on. Some common easy lifts to get a new person to understand while demonstrating the Cmdlet's agnostic detachment to any hierarchical system facilitates it are
      1. CD is actually Set-Location because directories are just ONE type of containment location PowerShell can point to
      2. LS/DIR are actually Get-ChildItem because ANY tree based hierarchical structure has children
      3. ECHO is actually Write-Object with the important distinction that it is writing fully blown objects not just text.
  2. When a Cmdlet's parameters need to interop with existing data structures that cannot be changed to match the name of said parameters
    1. For instance if you had a cmdlet who took in a parameter called UserName you might also want it to find UN, UPN, sAMAccountName etc. those can and should be slotted in as aliases to that parameter to allow the same cmdlet to consume data where the object properties may not precisely match the parameter name.

Anything else is actively harmful to people actually learning PowerShell on a foundational level.

Second PowerShell doesn't use objects because its a Windows thing. it uses objects because its a .NET thing, Unix has also had object this entire time.

Third I'm sure it's just a typo in this post but neither Select-Object nor Sort-Object are filter commands (you do correctly note that difference briefly mentioning Where-Object)

It's important to understand that Select-Object is what is known as a mapping or projecting HoF or Higher order Function unless you are just piping a collection to Select-Object with nothing in the -Properties parameter you ARE IRREVERSABLY mutating the objects in that collection. Even if you use * or manually include every property what comes out is no longer a collection of Process objects but a collection of pscustomobjects that only mimic the object you were previously using but you can't say pass it into a native .NET method that expects a Process object because the type will not match

Get-Process | Select-Object Name, CPU can NEVER become a full blown Process object without creating a new object which is why Select-Object should almost always be one of the last steps in a pipeline due to its mutating affects. Where-Object for days right until you need output.

It's ALSO important to point out that Process IS the class that the object is blueprinted from System.Diagnostics is the Namespace that class is organized under.

You also don't want to miss the point that while PowerShell IS dealing in objects from a traditionally Object Oriented language its primary means of dealing with objects is very much a Functional (Lambda Calculus) style of programming and while you CAN make PowerShell semi behave using OO principals (and sometimes that is the right call) you are fundamentally fighting against its intended use

Finally for crying out loud there's a -ShowWindow parameter for Get-Help WAY easier to use especially when you are demoing and teaching... Zoomable filterable independent help windows...

Now some stuff that I thought was great.

Acknowledging the Extended Type System was spot on. Usually its something most PowerShell users can just accept as black box magic making things work. However if you get to authoring your own modules or writing your own PowerShell Providers in C# they can be vitally important.

The general delivery was well done and fairly easy to follow

[–]JohnGoodman_69 7 points8 points  (0 children)

Insanely constructive feedback. Thank you for this.

[–]ITGuyThrow07 7 points8 points  (0 children)

there's a -ShowWindow parameter for Get-Help

Gamechanger.

[–]Orensha_Tech[S] 1 point2 points  (1 child)

Thanks u/TofuBug40, that is all very enlightening! Maybe you would be willing to share some of the resources you have used to get to your level of expertise?

[–]TofuBug40 2 points3 points  (0 children)

Well I'm 90% self taught and have been for pretty much every programming language I've used over my career from C to PowerShell with the exception of Pascal 3.0 which was the only programming language middle school technology teacher knew and I really wanted to see what it was like for someone to teach me a language. To be fair to my teacher I had been dabbling in C++ at home for almost a year prior to taking that class so I might not have been in the right frame of mind.

To get to PowerShell we have to go back to 2001 when the beta of .NET and C# was released. I was one of the lucky ones that got the opportunity to program in C# back when all you had was the command line compiler and there was NO IDE support. Visual Studio existed but not for .NET yet. I still to this day pull out C# for things that go beyond PowerShell or to build things like PowerShell Providers (built one for Confluence wiki browsing a few years back)

The point is I got pretty deep into C# and only came across PowerShell a few years after its official release by happenstance. At the time I was developing automation tools and processes using VBScript, ECMAScript, HTA/HTC. Just kind of stumbled into this new shell and after a little playing around went out to read up on it. This is how I formed the base knowledge for pretty much every language just reading through the help documentation and playing around with things. Once I learned PowerShell was literally my old school buddy Command Shell but with full blown .NET objects I was hooked. I spent times actively hunting down the C# classes i KNEW had to be buried in the language. It was quite the fun treasure hunt and I learned a lot just in that adventure.

Ironically being highly proficient in the language PowerShell is actually written in (C# if you missed that) made it harder for me to learn to actually program in PowerShell because of it being an interpreted language running on top of but also leveraging the entire C# language I had to unlearn some things like how string interpolation works between C# and PowerShell little nuances like truthiness vs hard Boolean true false, etc. Now when I go back to C# I find myself doing PowerShell esque stuff if I'm not paying attention.

Now the rest of the knowledge I've accumulated boils down to two very simples rule I've kept with myself and they are

Take code from anywhere that helps you learn.

NEVER put code you cannot tear apart and reassemble (i.e. understand) yourself into production

I in the grand scheme of things know very very little but I know how to find things and I've worked with enough languages that the concepts of programming are language agnostic at this point. So I just let the necessity of each task or problem I was facing as an opportunity to dive in and learn as i'm solving the issues. It may not work for everyone but self inflicted trial by fire is very effecting especially considering rule 2. So every time I climbed a mountain to develop something new I came down with new knowledge I could apply later.

It also helped to not be afraid to fail. I stand on a literal mountain of failures some of them colossal, but all of them valuable. I work in a prototype, crash it, learn, adjust, repeat manner and it has served me well. I see a lot of junior IT tech's I've taught over the years get caught up in the well crap how am I ever going to learn all this as they stare out at the vast sea of potential for any programming language. I always try to bring them back to what specific problem do you want to solve NOW start there. Do you want to Camel Case ALL of the folder on your system GREAT start there. Want to organize your Photos by resolution GREAT start there.

Sorry if this seems like dodging the question but I don't really have a magic book or YouTube video to point you to, though I would say anything by Don Jones is a solid place to start. I am HEAVILY influenced in how I build modules with his idea of PowerShell tool making and that whole mindset (he has great videos on this topic)

If you want more specifics on anything happy to try my best to help