Absolutely, and the calling conventions for all those pieces of code make no sense to powershell folks :)
If you have a background in windows dev or any of those tools then yeah, easy mode go grab your tools, but for most people doing system automation the calling conventions and complete lack of discoverability within the powershell ecosystem (and their tools in no way helping out) made this not a realistic use case.
Shoot I have seen some powershell modules that have to embed string C#s and eval thing just to have basic performance or other basic use cases.
The same challenge with calling conventions happens with Python calling into Windows APIs, moreso since there aren't that many wrappers available, other than installing something like ActiveState Python.
It actually is, as it provides scripting across the whole OS stack and applications, closer to Xerox, Lisp Machines and Smalltalk REPL, something that no UNIX has ever offered, with exception of outliers like NeXTSTEP and OS X.
This is all technically true, but the thesis is that PowerShell makes it all horribly clumsy to use.
From the perspective of the Lisp Machine or, hell, even the AS/400, PowerShell (and, while we're here, the CLR) doesn't quite go deeply enough, pervasively enough, across the system to make it truly useful in the same way.
Extremely clumsy, yes. And not idiomatic - a vanishingly small people learning PS will be able to usefully discover, use, or troubleshoot this utilization.
At the very least they could have helped with the discovery/usage problem, but that would probably have been a really tall order for one little language to do.
Not quite. What I'm more alluding to is something like, say, rewriting smss.exe and csrss.exe to be CLR programs (along with the implication of porting the CLR to the Native API) and giving PowerShell access to their internals directly.
If you have a background in windows dev or any of those tools then yeah, easy mode go grab your tools, but for most people doing system automation the calling conventions and complete lack of discoverability within the powershell ecosystem (and their tools in no way helping out) made this not a realistic use case.
Shoot I have seen some powershell modules that have to embed string C#s and eval thing just to have basic performance or other basic use cases.