I have been a good boy the past year and I think I deserve some nice presents. And without further ado, here is my Christmas wish list:
Figure 1: Photo of a Hitachi power drill
PowerShell whish list
Visual Studio Support
Thinking about the 2010 version of Visual Studio and the power of WPF in the text editor, wouldn't it be nice to debug a script and see in little windows the script output inline with the script statements that generated them. It would feel like running the script in the CMD shell: Statement -> output, Statement -> output etc.
Figure 2: CMD output inline with PowerShell statements in Visual Studio
Other features of the Visual Studio support would be:
- Auto back ticking
- Displaying bound parameter names for example as caption when positional parameters are specified
- De-magic-tizing support in an IDE that takes care of the most commonly and expensive mistakes
I am strong believer in Test Driven Development and Unit test harnesses. It would be very nice to have a Unit testing framework for PowerShell scripts. There are two different approaches. First I could imagine using an existing .NET framework like NUnit and test scripts while using the .NET infrastructure that PowerShell is based on. But this doesn't really feel right. It would be more natural, if the scripts are tested and verified using a framework that is completely designed and implemented around and with PowerShell.
ReSheller and CodeRushell
Refactoring and code generation support would also be very nice. VisualStudio has already ReSharper and CodeRush. PowerShell would benefit a lot from these kind of productivity enhancements.
Hash table magic to the power of magic
Hash tables are one of the core data structures of many shell and text processing languages. Unfortunately the way how hash tables are used in PowerShell is in some scenarios completely counter-intuitive and causes me always a lot of grief. Iterating over a hash table should be as auto-magical as iterating over an array. There shouldn't be a need to explicitly call GetEnumerator() or the PSBase property to get the data piped into the pipeline. Another annoyance is the automatic conversion of a hash table into an array or a single instance of DictionaryEntry objects when piped into a where-object operator. It seems like the magic needs to be re-calibrated in the case of the PowerShell hash table.
There are cases where PowerShell seems to be an interesting scripting option, but because XP, Vista and Windows 2003 Server don't have the engine installed by default, it is not seriously considered. Wouldn't it nice to include a PowerShell deployment with the delivery of the next Service Pack for each of these operating systems?
PowerShell and Mono
Mono is the open source reference implementation of the .NET CLR at runs on many different platforms. Mono would be a vehicle to do two very cool things: First the PowerShell engine could run for example from a USB memory stick and doesn't need to be installed. The second cool thing is that with Mono there would be a theoretical possibility to execute PowerShell commands on an IPhone. I always wanted to page through the CMD command history by shaking my phone.
I would like to see a PowerShell category in DZone and DotNetKicks. Also a script repository in the cloud would be nice.
PowerShell In Action, Second Edition
The first edition of PowerShell in Action was very good. I hope Bruce Payette is working on a second edition that includes the new features of PowerShell 2.
PowerShell for Programmers
There are a lot of books out there targeted towards the IT audience. I wished the there would be books about how to write applications with PowerShell or integrating PowerShell support into an existing .Net application. Another cool book idea is to write about Domain Specific Languages (DSL) and how to implement them using first PowerShell and then M.
PowerShell has a great potential, but it needs professional tool support in order for it to mature. The current solutions are far too amateur.