That's the other thing that helped. See, Unix system administrators don't program exactly. We (they) write 'scripts.' Like I said, just think of DOS BATch files on steroids. A Unix box boots into a single program, init, that then goes and searches for what scripts it is to run to do everything else, including starting up the program that lets people log in.

If you're a Unix sysadmin, you script. Yes, it's programming, but it's not the same. A program is compiled. It's translated from something (supposedly) human-readable into something only the machine can understand. Well, the machine and serious deep-magic gurus. This is so it runs faster.

See, scripts are interpreted. Programs are executed. A script is read, line-by-line, by the interpreter which then does what the script says to do. Programs talk at a more intimate level ("Yeah, baby...") to the computer, without the need for an interpreter.

Programs run faster. They can do more, because the system API (application programming interface) is usually richer and more full-featured than what the interpreter gives. (Perl comes close, but Perl technically isn't an interpreted language. It's also oft-times not human-readable.)

Real Users write programs. Sys Admins write scripts. That's like the difference between the race car driver and the pit crew chief. Do you even know Mario Andretti's crew chief? See?

In my work, we live and die by C# and compilers. But someone pointed out a C# interpreter. Performance takes a hit, but that's a fact of life with scripting.

So why script a compiled language?

Firstly, it's closer to my innate mindset. Even if my scripts are the object-oriented flow of "define your object, instantiate it, then interact with it," there's something reassuring about not having to compile it. Even if the compiler is so fast that it's done in a blink.

Secondly, it's easier-maintained. A common problem with any executable is, "Okay, you now own the upkeep of this program. We don't know where the source code is..." A script's source code is the script itself. Yes, you can embed the program's source as a resource, but that's not commonly done (nor is it something I know how to do.)

Thirdly, it's just neat. Yes, C# is a crummy scripting language. I can't simply "run this external program, then redirect it's output into a string." In Bourne Shell scripting (and Perl) that's simple. But usually in a script, you do that because you don't have the means to do what you really want, so you're serializing the data to text and then munging it into what you want.

I still write infrastructure code, and compile it. Those are the object models and test methods that our test harness uses. It expects compiled code, and that's what I give it.

But for me, much of my testing is stuff like, "It'd be nice to make sure that the key components of these two XML files are roughly equivalent," or, "Let's see how many error messages out of the error catalog I've hit so far." My choices for one-off scripts like that are JScript or VBScript. I like JScript more, but no one on the team knows it. Not many people on the team know VBScript, either, but there's at least more a chance.

Both JScript and VBScript were born from Dynamic HTML. They are both meant to be embedded in a web page and interpreted by the user's browser. This means that they have rather limited featureset. For example, they can't even open a file on the local machine. To do that, they have to instantiate system objects.

This means I have to learn (at least) two mindsets: VBScript itself, to do the control logic, looping, etc., and then the API to the system object to get at the useful stuff, such as "open this file" or "parse that XML snippet in memory."

And VBScript's syntax is just ugly. Who ever thought a single quote makes a good comment delimiter? (Actually, a single hash character is no better, but at least it's ubiquitous across all Unix shells and many/most scripting languages.)

So, discovering this way to program helped me feel much better. I can now work with my code at the level I'm used to, but I can still hand it off to my team and have them compile it. I actually do as well, and set breakpoints, use the object browser, etc. But there's something reassuring about thinking about it as a script.

Oh, and I finally wrote an options parser I like. I've been trying to write a decent C# command line option parser, sort of like Perl's GetOpt::Long. Actually, my undoing was that I was trying to write GetOpt::Long for C#.

DOS (and descendants) have a much different mindset for command line arguments. Firstly, they're called parameters. Secondly, the specifier that differentiates a switch from a value is "/" in DOS and "-" (or "--" or "+" if you're talking GNU) in Unix. Lastly, if the parameter takes a value, it's not space-delimited. To run program "foo" with a value of "baz" for switch "bar" in Unix is "foo -bar baz". In DOS, it's "foo /bar:baz". Colon-delimted.

This means that I was over-complicating myself with GetOpt::Long's command line prototypes. (You know, "input=s" for "-input requires a string" sort of thing?)

My C# parser doesn't do error checking. That's up to the calling method(s). All it does is instantiate an object and snags every parameter on the command line that begins with "/". If the parameter has a ":", then the parameter name is everything before the ":" and the value is everything after it. If the parameter doesn't have a ":" the value is "1" (string, not int.) If the parameter is set multiple times, the last one wins.

Any parameter on the command line that doesn't start with "/" it returns on the array of strings that is what's left of args after parsing (think "use GetOpt::Long qw(:config permute);" if that helps any.) Then, the user queries the object, either for parser.keys(), or to use a key as an indexer, such as parser[key]. If the indexer's value doesn't exist, it returns "" (string, not null.) If it does exist, it returns the value as string.

Thus /foo and /foo:1 are the same. Braindead, simple, and flexible.

A decent command line parser is key to how I program. Script. Whatever. I generally design fairly flexible command line UIs so I can drive the various parts of the code. This parser is very small and finite so I will likely just embed it in all code I use. (No, no DLLs for me. Not for something so small and simple.)

Yay, me.