Friday, June 20, 2008

PowerShell and Beyond

I have to admit, I'm still struggling to get my brain around PS. I'm originally a LISP developer and was used to calling CLOS and (stop laughing, please) Visual LISP (aka AutoCAD LISP) a real "interpretive" environment. When I took courses in college on Java (it was the hottest thing going in 1994-1999) I remember saying "LISP already does that" to the point making everyone around me hate my guts.

Then I picked up Kixtart and fell in love with its many tentacles of functionality. The breadth of API accesses that really make it a broad environment to get things done. But then I found VBScript to be "almost" as flexible and capable on the features side, but superior in the availability area. I continued on with both for a long time (and BAT/CMD also), being a typical script-kiddie (I really, really hate that term by the way).

Then Monad/MSH hit the web and I jumped in early, but found myself swimming in the wrong direction. I wasn't seeing it for what it really is. It's not a traditional "scripting" platform or language. It's really a semi-compiled, extensible programming language and runtime environment. A mouthful? Maybe. Something like if there really were a Java-Script (no, not Javascript or JScript), but alas there is/wasn't such a thing. However, somewhat like Kixtart, it suffers from having to deploy a runtime agent/engine somewhere/anywhere if you wish to run it.

Kixtart at least provides a fully portable, self-contained engine that you can invoke remotely, so code can be executed locally via a remote engine bootstrap process. VBScript relies on the ubiquitous WSH (wscript, cscript, etc) components, which are typically present on most Windows machines. PowerShell however falls more into a new realm in that there's no ubiquitous local engine and yet it cannot invoke a remote engine either.

Another oddity is that VBScript is not only commonly useful as a scripting solution, but also as a web development solution (ASP), and a login script. Kixtart is great at login scripting, and very powerful as a dedicated scripting tool, but not at all useful for web applications development. Now, PowerShell is great as a scripting solution, but I have to see an example for using it in the roles of either login script processing or web development. The problem for PS with login scripting is that it would require the PowerShell runtime client on each computer in order to work. The idea of PS as a web scripting solution wouldn't make sense either since it would smack into the goals of ASP.NET and so on.

I guess what I'm trying to understand is what the ultimate goal is for PowerShell. Is it to be relegated to strictly script processing? Will it be expected to assume the role of login script processing? If so, how will that play with Group Policy Preferences (GPP)? It seems that for such a powerful, promising idea, it's already facing some uncertain boundaries. And I haven't even mentioned how it will be expected to supplant BAT/CMD or WSH in future Windows (or mixed?) environments. I have no answers, only questions.

No comments: