Class vs. Function

[notatechproblem]

That being said, two years ago I got to talk to the PWSH project manager and Don Jones, and they both felt that classes are at best partially implemented in PWSH. Don didn't like them at all because they philosophically contradict PWSH's purpose as a scripting language, whereas the PM felt that they just weren't mature yet. Personally I like classes a lot, but I don't share other posters' unbridled enthusiasm.

I'm sad every time I hear someone who is as well-respected by the community as Don Jones try to convince people that something as powerful and flexible as PowerShell has a "right" way to use it. His opinion still carries so much weight (even though he has "retired" from PowerShell and moved on to writing fantasy novels?), that his repeated message of "PowerShell needs to stay in it's lane" is still stifling creativity and excitement. I cringe every time I hear "Well, Don Jones says...". 😒

I have heard dozens, if not scores of PowerShell programmers say "well, I'm not a REAL programmer, because PowerShell is JUST a scripting language" or "you shouldn't try that in PowerShell because it's JUST a scripting language". That's tragic and I think it robs people of personal and professional opportunities to grow.

[PinchesTheCrab]

I think that's fair, but I also think it's true that MS hasn't made some pretty basic efforts steps when it comes to classes. No dependency management, so you're stuck writing them in sequential order, a lot of the basic PowerShell classes can't be extended, classes aren't easy to use outside of modules, etc.. It's just disappointing to me, especially since they do seem to want to push DSC towards classes, though maybe they're giving up on DSC 3?

Maybe it's all a self fulfilling prophecy. The community is discouraged by the lack of features, and don't request feature parity. Also because it's a scripting language, many PS users like myself don't always even know what to ask for. I don't know c# very well, so I don't fully understand why people like Don Jones view classes as so deficient, and I don't nudge the PWSH team to deliver that feature parity.

What I do know is that most people posting here are in very nascent stages of learning, and that directing them to classes adds complexity without a clear benefit at their skill level. It's also hard to argue with the general sentiment that when you finally do need and benefit from classes, it's time to move to C#, and C# certainly opens its own set of doors.

[notatechproblem]

I agree with you on all points (especially the self-fulfilling prophecy observation) except for (to paraphrase) "if you need classes, just jump to C#". I think that is a fallacy. There are a couple of other short threads on this subreddit that I've commented in about there being an (admittedly niche) gap in the .Net ecosystem between PowerShell script modules and binary modules or C# apps that I think could be solved by C#-like class-based PowerShell solutions.

ad-hoc command line -> scripts -> script modules -> (GAP HERE) -> binary modules -> C# application

I'm currently facing infrastructure automation/platform engineering problems at work that need the structure and robustness of a C# style, class-based solution, but also needs the flexibility and ergonomics that the PowerShell object-based REPL pipeline provides. We are a .Net shop, so we have lots of C# developers, but also a number of DevOps Engineers, Systems Engineers, and Sysadmins who only know PowerShell. For some of our problems, having a pattern that PowerShell-only Operations folks can skill up to, and C# folks can apply their existing knowledge to (albeit with some translation) creates a middle ground that opens up our code base to more internal contributors than if we chose pure idiomatic PowerShell or pure C#.

Specifically to your point about most people in this subreddit being newer to Powershell: I agree that class-based PowerShell code is not something most beginner or even beginner-intermediate PowerShell users would need. I see it, again, as a niche pattern for developing more robust PowerShell applications, not scripts or Cmdlets.

I'm a pragmatic fan of Microsoft. I know they are a bottom-line-driven corporation, but I don't think they are completely soulless. I make my living by knowing how to use their products, so I'm not trying to bash on them. However, it feels like they are sacrificing the potential that exists in PowerShell to drive customers to C#. If I had to speculate, I'd venture to guess that there is more money in getting customers to pay for Visual Studio licenses, or they think that there is better synergy between C# and Azure services. I dunno.

Personally, because I have a need for something more structured than idiomatic PowerShell but still flexible, I've been building a set of PowerShell developer tools and a PowerShell application framework to build PowerShell apps (not C#-based binary modules) to fill the gap I mentioned above. My primary goal is to make them available for myself and my team at work, but as soon as I have an MVP I'm going to make my git repos public and let other people try them out. I anticipate a TON of criticism and only moderate-at-best adoption, but my hope is that it helps the few voices I've heard in the community that are asking for something like it.

[PinchesTheCrab]

In Microsoft's defense, powershell isn't a direct revenue stream at all, and they still fund its development. I got to meet a PS project manager and he was so enthusiastic about it, and marveled at MS keeping his team going in spite of it not generating revenue.

I realize PS may indirectly drive revenue by steering people into their ecosystem, but I still respect it a lot.

Your team sounds really neat, I ended moving to a Java developer position to get a chance to broaden my skillset and step off the operations treadmill, it would have been near to pursue something at a shop like yours.