I have a theory:
Any new technology that seeks to improve upon, or supercede, any existing technology, should NEVER take any steps backwards. In the worst-case scenario, it should match the existing technology, and then provide improvement from that point onward.
That theory blows chunks and doesn't hold water.
How often do we all see "new" or "new and improved" crap that, at least in some way, doesn't hold up to something already in existence? Cars are a great example. Sure, they get better gas mileage and have a bitchin stereo and fo-shizzle paint and detailing. But the trade-offs are a-plenty. Plastic has replaced metal. Vinyl-ish surfaces replace what was once inhabited by Leather. Wing windows are gone. Overall body styles are bland and communist looking. Not to digress too much farther, but let's face it: In the 1960's and 1970's, you could instantly name the car from a half-mile away speeding past. I dare anyone to name 4 out of 5 cookie-cutter vehicles passing them on any given day, even within a few yards of you.
Sorry, I digressed again. Where was I? Oh yeah, NOT going backwards with new technology.
So, KiXtart began life sometime in the early-mid 1990's. Then came Windows Scripting Host and Visual Basic(R) Scripting or "VBScript" sometime around 1996. It added some new features not found in BAT/CMD script, and a few not found in KiXtart as well, such as DateDiff, DateAdd, and so on. Some could argue it lacked features found in KiXtart, and I wouldn't argue with them either. Now we have PowerShell, and you would think it should be a "best-of-breed" language. In some respect it very much is. Object oriented, pipelining, tracing, well-structured API and consistent syntax (for the most part). But even with version 2.0 CTP it lacks some very esoteric features found in VBscript and KiXtart, among others. I'm a bit confused.
Examples?
$a = "abc,def,ghi,jkl"
$b = $a.Split(",")
Now, I assumed I could do the following, but I was wrong...
$c = $b.Join(",")
The "correct" way is as follows...
$c = [string]::Join(",", $b)
Other examples would be InputBox() and MsgBox(), which are heavily used in VBScript files these days. You end up doing the duct-tape dance with a COM interface (yep, the ScriptControl object). Here's my version of the two functions in case you care to play with them...
#check-out: http://www.microsoft.com/technet/scriptcenter/topics/winpsh/convert/inputbox.mspx
function InputBox($p, $t) {
$a = New-Object -ComObject MSScriptControl.ScriptControl
$a.Language = "VBScript"
$a.AddCode("Function getInput() getInput = InputBox(`"$p`",`"$t`") End Function" )
$b = $a.Eval("getInput")
$b
}
InputBox "Test msg" "Test Title"
And here's one for the MsgBox() function, which actually invokes the PopUp() function via the ScriptControl object. I defined some standard enumerations to make things a little more familiar...
#check-out: http://www.microsoft.com/technet/scriptcenter/topics/winpsh/convert/msgbox.mspx
$vbOkOnly = 0
$vbOkCancel = 1
$vbAbortRetryIgnore = 2
$vbYesNoCancel = 3
$vbYesNo = 4
$vbRetryCancel = 5
$vbCritical = 16
$vbQuestion = 32
$vbExclamation = 48
$vbInformation = 64
$vbYes = 1
$vbCancel = 2
$vbAbort = 3
$vbRetry = 4
$vbIgnore = 5
$vbNo = 7
function MsgBox {
param(
[string]$p = "Message text",
[string]$t = "Caption Title",
[int]$delay = 0,
[int]$btn = 0
)
$a = new-object -comobject wscript.shell
$b = $a.popup($p, $delay, $t, $btn)
$b
}
MsgBox "Select an option" "MsgBox Test" 0 ($vbOkCancel+$vbQuestion)
My question is simply: why?
Especially with version 2.0 in the doorstep, wasn't more time taken to review what the predecessor's have and ensure those were not only rolled into the new version, but done so in a consistent manner? I'm not a compiler builder or language architect. I'm certainly not on the same level as Jeff Snover, Don Hite, Don Jones and the other wunderkind brains we all love to read about (and I do, trust me). I'm just voicing an arguable trivial concern as a developer and professional nobody.
I should be able to invoke a messagebox or inputbox like this...
$x = get-input -prompt "" -caption "" -buttons 2 -style 32 ...
I'm sure I could spend a few hours building my own cmdlet to do this, but why should I?
I should be able to test if an object holds a numeric value like this:
$a -is [numeric]
rather than like this...
[reflection.assembly]::LoadWithPartialName("'Microsoft.VisualBasic")
$b = [Microsoft.VisualBasic.Information]::isnumeric($a)
Then again, maybe I'm being an ass and shooting from the hip with half-loaded gun (which I probably do more often than I admit).
Now, before you start blasting me with "Oh sure. Easy enough for Mr. Blowhard here to bitch about something like this. I'd like to see him build PowerShell from scratch like these guys did." And that would be an absolutely valid comment. I applaud the genius, the daring, the time, sweat and tears that has gone into dreaming, designing, building, testing, refining, and giving birth to this amazing thing. Not to mention putting it out into the open world and sharing a conversation with developers everywhere about how it evolves and grows. I can't take anything away from that, and I wouldn't want to. I'm just making a comment because, well, I'm eating a sub and have time to kill and it's been on my mind today. I've also been listening to Adam Carolla most of the day and it gets me in a spunky mood sometimes. Anyhow, I'll shut up for a while. Cheers.
