In the past whatever years I've been developing/writing/hacking/coding or whatever with software programming code, one of the most common questions I hear is this:
How do you know what language to use?
So, what are the forces that most often encompass our decision machinery? Well, they are usually one or more of the following, but may be in any order based on environmental and cultural parameters. Clear as mud? Ok…
- Project Guidelines - These are written by some obnoxious suit-wearing puke that read some IT crap in the seat pocket magazine during his last flight. He/she discusses this with other suits on the golf course or at the cocktail lounge (the rest of drink at bars or at home while watching a sports game). Then they draft up the contract and procedural crap, open your mouth, and insert the spoon repeatedly, until you loudly scream "Mmmmmmmm!" with a smile. This little dish usually goes by another name, maybe you've heard it before: "Contract Requirements"
- Retrofit - A secret truth to the world of programming is that a HUGE portion of all the programming work (again, the work that pays money) involves patching or modifying existing code. You're not likely going to suggest switching to a new language to make some modifications to millions of lines of existing code.
- Resource Availability - You like some programming language called Beatoff, but unfortunately it requires buying some special software or licensing. Or you eat bean sprouts, wear sandals in the Winter, drink herbal tea and espouse the virtues of FOSS (that's "open source" to you Windows and Mac noobs). Unfortunately, the attorney reminds you that indemnity risks, licensing risks, intellectual property risk are simply unknown (or undecided). You shrug that off. Then the CFO or CIO says, calmly: "But then we'd be dependant upon YOU to maintain this. Hiring a replacement will be difficult. Windows programmers are laying around in every alley, and they can easily step into an existing project - this equates to low risk, high affordability." Game over. Just for the record, I have been told this almost verbatim by several CxO types, even while they wore a suit and were absorbing some sort of alcoholic liquid.
- Culture - You get hired into a company with a team of developers that have all synchronized their menstrual cycles. You will synchronize yours as well. It's a fact of life.
There are other forces that come into play even when the obvious, or objective, external forces do not show their face. These are subjective, but no less influenced by prior external experience and external forces. Call it prejudice. Call it habit. Call it preference. Call it Veronica. Whatever, we're human. We all have habits and opinions, formed over time by happenstance situational influences.
For example, you may have worked on a particular project where you were pushed into learning a particular language. That worked perfectly well for that project and you were able to accomplish amazing feats of amazement. Now you come away thinking this language is not only awesome in itself, but awesome enough that it should be used on everything.
Careful.
This is like learning to use a screwdriver, and then thinking (no - wait - BELIEVING) that a screwdriver is the ultimate tool for EVERY task, bar none.
Go ahead and chuckle. In the world of software development: THIS IS THE RULE - NOT THE EXCEPTION. Very few programmers understand the subtle intricacies of what makes one language more viable for a set of tasks than another. Big O factoring. Modularity. Refactorability. OOP and Inheritance, and the like are low-hanging fruit for most coders. But ask them how it actually gets parsed, recoded, digested, processed and reprocessed - even down to machine language, considering compiler and execution derivatives - and well, they're a deer in the headlights.
A classic example of this is to mention FORTRAN to most programmers today and watch them make stupid, anti-get-laid jokes about it, while chuckling and snorting. They'll insist Ruby, Python, C# or F# or even C++ is the way to go. Tell that to the folks crunching 3D seisemology data for oil exploration, or projecting multiple trajectories for interplanetary travel. In case you're lost here: FORTRAN does nothing if not specialize in crunching numbers. It's a math processing idiom. In other words, it is a #2 Philips screwdriver for a #2 Philips screw head. Same goes with AI and LISP or Scheme. You get the picture.
Capabilities vs Ease
I haven't even gotten to the part about what the languages "can do". As if I haven't blabbered enough already? Oh yes. Now comes the esoteric, aesthetic, academic part: comparing the capabilities.
The most classic of classic examples is the following question:
When should I use a BAT or CMD script instead of a VBscript?
I could dive into all sorts of propeller-head, taped-up glasses, stained t-shirt nerdish minutea, but I'll boil it down to the simplest criteria:
- Open and Read the contents of files, especially non-ASCII files, in order to process or analyze specific things inside?
- Read and write to the registry with at least some rudimentary error handling?
- Read and write to the event log with the ability to filter and sort?
- Read and write XML data?
- Interact with relational databases?
- Perform complicated string manipulation operations?
- Offer complicated (or pretty-to-look-at) menus and choices?
If any of the above are true, go with VBScript (or PowerShell, etc.). Before you blow your bongwater through your nose in disagreement, let me say this: Yes, you CAN accomplish these tasks using CMD or BAT code, but it's not as simple or as flexible in most cases as with VBScript (or other languages). I use BAT and CMD all the time. Actually, about half the time, and mainly for situations that only need to do things like:
- Run commands like REG, DIR, DEL, COPY, MD, RD, REGSVR32, ROBOCOPY, FIND, FINDSTR, DSxxx, EVENTTRIGGERS, SC, NET xxx, IPCONFIG, NETSH, SCHTASKS and so on.
- Create text files by redirecting output
- For launching multiple scripts at once (such as multiple VBScripts or PowerShell scripts)
As a basic comparison, look at the code required to create a text file, to document environment variables or directory lists, from VBScript (using the Scripting.FileSystemObject library) as opposed to a simple CMD script. The CMD script is dramatically simpler and easier.
Don't Lose Focus
I will do my best to avoid going off the wagon on another rant about PowerShell qualifying as being a "scripting language". In all the years I studied at a University, and all the years working thereafter, the intention of "scripting" was to save time. SAVE TIME.
Repeat those two words over and over for another five minutes. I'll wait… go ahea…
mmmm, hmmmmm…. hmmmm…. finger's tapping…. hmmmmmm, hmmmmm…
ok, good?
System Administrators are NOT Developers. Developers work with programming languages and write programs and compile them. The focus is on complexity versus processing efficiency. Admins work with scripting languages and write scripts. The focus is on getting a job done quickly and keeping the learning curve short and relatively low.
Which is better? Neither.
Doctors need plumbers. Plumbers need doctors. That's life.
When you're writing scripts, the goal is to accomplish the task in the least amount of time, with the least amount of effort. Your responsibility as an Admin is to backup the databases and files, to keep the servers running, to keep connectivity running, to fix the breaks quickly and ultimately: MINIMIZE DOWN TIME. The goal of Developers is to write programs, usually for other people to use. They make the programs. Admins deploy the programs to users. Or, to put this another way…
Making the tools versus Using or Deploying the tools.
So, going back to the "focus" aspect: The goal for scripting is to solve a problem quickly, so when you have to choose between various languages - choose the one you feel will be the simplest and easiest to work with as it pertains to solving the problem at hand. Never decide on a language because the language itself is comfortable, that should be secondary to matching it with the problem you are trying to solve. You can modify the registry in dozens of ways. But choosing the simplest way that meets the needs of a particular challenge, well, that's the most important perspective.
Choose wisely.
0 comments:
Post a Comment