Captain's log, star date 2856.9.
The Enterprise is trapped in a space-time vortex. As a result, the ship's engine has been malfunctioning. Lieutenant Commander Montgomery Scott, our chief engineer, created a script to re-adjust the engine's parameters and free Enterprise from the vortex. The script didn't produce the expected results.
McCoy: Scotty said that if we don't escape the vortex in the next hour, the Enterprise will spin out of control and we'll be lost in space.
Kirk: Lost In Space?
McCoy: That's what he said, Jim.
Kirk: But that's the wrong TV series!
McCoy: Exactly.
Kirk: Is there anything we can do to avoid this?
McCoy: I don't know, Jim. I'm a doctor, not a systems engineer.
Kirk: Uhura, open a Unified Communications channel with Mr. Scott in the engine room.
Uhura: Unified Communications channel opened, Captain.
Spock: I just returned from the engine room. The VBScript script is behaving erratically, almost illogically.
Kirk: Scotty, how's the situation?
Scott: I have good news, Captain. I found the problem area in my script. I created a smaller proof-of-concept script to demonstrate the problem.
Kirk: Show us this script in our monitors, Scotty.
Scott: Here it is, Captain.
Option Explicit
Dim a, b
a = InputBox("Input an integer value")
b = a + 1
If a < b Then
MsgBox "This message box should always appear"
End If
MsgBox "End of test"
When I run this script, the message box doesn't appear. I'm starting to think there is something wrong not with my script but with VBScript in general.
Chekov: If we change line
If a < b Then
to
If CInt(a) < CInt(b) Then
will the script work?
Scott: Wait a minute... Yes, Mr. Chekov, indeed the script works now!
Uhura: Or, better yet, change the InputBox line to
a = CInt(InputBox("Input an integer value"))
Kirk: Can you show us the final version of the script in our monitors, Scotty?
Scott: Here it is.
Option Explicit
Dim a, b
a = CInt(InputBox("Input an integer value"))
b = a + 1
If a < b Then
MsgBox "This message box should always appear"
End If
MsgBox "End of test"
Kirk: You can use the TypeName function to see what type VBScript assigned for a variable.
Scott: Interesting, Captain. I'm checking this right now. I added the line
MsgBox TypeName(a)
right after the InputBox line in my first script. I see now that TypeName function says the a variable is a string.
McCoy: That's probably because you used the InputBox function to assign a value to the variable. It seems that VBScript will consider anything the InputBox function returns as a string.
Kirk: Maybe you've got a little bit of an engineer in you after all, Bones.
Chekov: Mr. Scott, if you had used PowerShell instead of VBScript, is there a chance that you would've had the same problem? In VBScript, all declared variables are of type variant. But in PowerShell, you don't declare variables explicitly. Variables are implicitly declared when they're first assigned a value.
Scott: Let's see. In PowerShell, the script would be as follows:
Set-PSDebug -Strict
$a = Read-Host "Input an integer value"
$b = $a + 1
if ($a -lt $b) \\{Write-Host "This message should always appear"\\}
Write-Host "End of test"
Let me try it. Well, this script works correctly! PowerShell assigns the correct type to the variables, at least in this case. So, had I used PowerShell, my script would have produced the correct results.
Chekov: You're correct, but it's still better to denote the type, like this:
Set-PSDebug -Strict
\\[int\\]$a = Read-Host "Input an integer value"
\\[int\\]$b = $a + 1
if ($a -lt $b) \\{Write-Host "This message should always appear"\\}
Write-Host "End of test"
Because PowerShell variables aren't declared beforehand, it would be best to cast them to their intended type.
Uhura: Is this like a C-type cast?
Kirk: Yes. As you can see, the only difference is that instead of parentheses, we have brackets here. And these casts are not unlike the typecast effect these roles have had in our acting careers.
Chekov: But we have to be careful, even with PowerShell.
Spock: Indeed. You never know how PowerShell is going to view your variables. The best thing you can do is to explicitly cast them. I've never understood the idea behind scripting environments.
McCoy: Am I on "Punk'd"? What exactly haven't you understood, you emotionless Vulcan?
Spock: Live-long-and-prosper to you, too. And to answer your question, it's illogical to use a weakly typed language instead of a strongly typed one.
McCoy: Scripting and dynamically typed languages provide great ease and convenience.
Spock: Ease? And convenience? At the expense of safety?
McCoy: You should be able to declare the variables you use and their types and not leave it to the compiler or interpreter to decide. I give you that. VBScript has Option Explicit and PowerShell has Strict Mode to enforce variable declaration. To denote the type of a variable, VBScript has type conversion functions such as CInt, and in PowerShell you use square brackets to typecast as we've just seen. And if you want to find a variable's type, you use the TypeName function in VBScript and the GetType method in PowerShell. So we're good to go. What? You don't like it because it's not "pure", right?
Kirk: Enlightening as this may be, it's time to check the results. Scotty, can you run your script with the corrections?
Scott: I have just used type conversion functions wherever I have input boxes, and it seems to work. The results look legitimate now.
Kirk: OK. Now restart the engine with the new parameters.
Scott: Yes, Captain. The engine is now operational. The Enterprise is freed from the vortex!
Kirk: Excellent job, Scotty. You know, this could be as important as moving to syndication. Ahead, warp factor one, Mr. Sulu.
Sulu: Warp factor one, sir. And thank you for my small part in this episode, sir. I had no time to prepare for a bigger part now with my appearances in "Heroes" and all...
THE END
—Dimitrios Kalemis, systems engineer
