Thanks for the thoughtful feedback - it was precise and helpful.
> 1. Consistency: Powershell was built to be consistent and yet object property names are often not. The process object uses processname but company not companyname, i.e. some properties have name in them and some don't. This happens with many objects and not only that. It seems to me that object properties could be made more consistent.
Absolutely correct. While .NET is substantially more consistent than previous efforts, it still has inconsistencies such as this. This is one of the reasons that PowerShell extends the .NET type system. Look what happens when you ask for the names on Processes:
PS> get-process |Get-Member *Name*
TypeName: System.Diagnostics.Process
Name MemberType Definition
---- ---------- ----------
Name AliasProperty Name = ProcessName
...
ProcessName Property System.String ProcessName ...
We have produced a property alias which maps Name to ProcessName. This allows us to address the inconsistencies of .NET. As a user, you can take advantage of this feature yourself adding additional properties, methods, etc to objects and object types. It is an incredibly powerful aspect of PowerShell.
> 2. What you think you type? Think again. Powershell was built to simplify management by the use of a set of similarly named objects using a verb-noun pattern. And yet in Powershell many management tasks require using WMI and COM and etc which is a mess and not at all "what you think is what you get". If WMI is needed for everything, then we lose the easy syntax of Powershell.
This is a coverage issue. Cmdlets represent the best user experience but we knew that it would take years before we had complete coverage. We decided to provide access to things like COM, WMI, ADSI, .NET, etc even though they did not provide the level of abstarction we wanted to provide our users. What they do is 1) ensure that you can always do what you need to do and 2) allows you to create the right level of abstractions for others using Scripts.
> 3. COM clean-up: Create a COM object in Powershell such as Internet Explorer or Word. How do you clean it up. The COM reference is not released and setting the variable equal to $NULL does not change anything
Setting it to $NULL deferences it but the object will continue to exist until the garbage collector (GC) disposes it. You can control this yourself but as a general rule, it is best to let the GC handle it.
> 4. Language documentation is not adequate: When do you use square brackets and when round ones in variables? When a comma, etc? Why does where require a script block? Why was the pipeline object named $_ which is difficult to type instead of $$ which would have been easier? Why do I need to specify $_ in a where script block anyway? Can't it be assumed? And many more. There are many language design questions are not answered in the documentation and some language featured are not clearly explained.
Yup. There are a number of books now available on PowerShell that fill this gap. Bruce Payette, the developement lead on the language, as a great book focused on the language coming out this month. It is called PowerShell In Action.
Jeffrey Snover [MSFT]
Windows PowerShell/MMC Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
