There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things. Because the innovator has for enemies all those who have done well under the old conditions and lukewarm defenders in those who may do well under the new.
PowerShell is the next-generation platform for distributed automation in the Microsoft Windows environment. It provides significant benefits to developers, testers, power users, and administrators. PowerShell works by leveraging the .NET Framework, and provides significant benefits to developers, testers, power users, and administrators. PowerShell leverages .NET to provide a powerful, consistent, intuitive, extensible, and useful set of tools that drive down costs, and make it easier to program for and automate Windows.
PowerShell was developed in 2002 under the code name Monad. In 2006, Microsoft published Release Candidate 1 of the platform, simultaneously announcing its new name, Windows PowerShell. Today PowerShell v3 is being delivered with Windows 8 and Windows Server 2012 and is available for Windows 7.
For a slightly reworked version of inventor Jeffrey Snover’s opening to the Monad Manifesto whitepaper, which outlined the core ideas behind what would eventually become PowerShell, see http://bit.ly/n68k1X.
New PowerShell developers can often create timesaving scripts after just a few hours of learning. There are numerous accounts of people seeing huge reductions in time spent solving problems using PowerShell, compared to traditional system programming languages.
Another distinguishing feature of PowerShell is the fact that you can embed it into .NET applications. Adding the PowerShell scripting engine to a Windows .NET application allows you to provide a full-featured configuration and macro language to that application. This is roughly analogous to adding Visual Basic for Applications (VBA) to automate your work in Microsoft Excel.
Once you learn PowerShell, you’ll be able to write scripts for any PowerShell-enabled system. Windows Server 2012 is shipping with over 2,300 cmdlets (the basic unit of PowerShell functionality), up from the 400 cmdlets that shipped with Windows 2008 R2.
On top of this, the number of PowerShell solutions provided from third parties and the user community is growing by leaps and bounds. To get an idea of what PowerShell’s future might hold, check out the sidebar “PowerShell Score Card, Ten Years On” to see what it has accomplished already in its 10-year history.
I use PowerShell for a number of reasons. It makes me fast, it’s easy to use, and it’s comprehensive. While PowerShell will never win a race with compiled .NET code, it’s fast enough.
You can include .NET code directly in a PowerShell script and compile it on the fly.
PowerShell is an astonishing glue language because it is rooted in .NET. The .NET Framework, and the applications built on it, provides a set of powerful components that PowerShell can connect together. This includes the .NET applications I am building today. PowerShell pipes objects—not text—across the pipeline, enabling programming scenarios, in few lines of code, that were not possible before.
PowerShell is easy to learn and extremely powerful. It has all the elements you’d expect in a systems language—variables, loops, data structures, file I/O—and more. In addition, it has complete access to the .NET Framework, and the ability to seamlessly load .NET DLLs, instantiate objects, and retrieve metadata—either on your local box or via PowerShell remoting.
Finally, PowerShell is fun, satisfying, and rewarding to use. Whether you’re using it to automate a tedious task, to simplify an implementation complicated by traditional means, or to create GUIs (WPF or WinForms based), PowerShell reduces both the effort and time you spend to get to a completed program.
Think of PowerShell as a new pinball game. We can continue to play the old one—we know how to jiggle the machine just right so as not to tilt it, we understand all the ins and outs, and we know the tricks to get extra plays—but this new game has great potential.
But there is a wrinkle here: in order to get good at PowerShell, you need to experience a short, frustrating period of being bad at it (i.e., the valley of the s-curve shown in Figure 1-1). That means you’ll be looking things up, wrapping your head around new ideas, and getting comfortable with the fact that when you jiggle PowerShell, sometimes it’s going to tilt.
Usually you see declines in performance before significant improvements.
Scripted versions of applications require less code, effort, and development time compared to traditional approaches. The interesting discussion is not static languages versus dynamic languages, but rather when and where to use both for delivering solutions. As John Ousterhout, creator of Tcl/Tk, put it:
Scripting languages are higher level than system programming languages in the sense that a single statement does more work on average. A typical statement in a scripting language executes hundreds or thousands of machine instructions, whereas a typical statement in a system programming language executes about five machine instructions.
In summary, you owe it to yourself to try out this new pinball machine.