Thoughts / Opinions on Scripting??

[KrAzY_NuK]

I don't really have much background with scripting, only a few batch files, little bit of vbs, a hint of javascript, looking over some SQL scripts, and I've gotten my feet wet with Perl (Sounds almost like a recipe...mmmm food).  It seems that I spend most of my *programming* time with C/C++ or Java.

Anyways, at work, apparently we use VBS and Batch files for some basic console-based scripting, including scheduling tablespace checks for Oracle, etc.  I recieved a task saying that "We are potentially looking at adding a powerful scripting environment to our servers to help with administration".  They also mentioned elsewhere that "We've had problems with VBscript in terms of 'real power' - ie) it can't get really low level very easily".  So my job is to do some research, and recommend a possible alternative scripting environment to use.

The researching and reporting shouldn't be too much of a problem (after all, it's just doing a little reading on the net, perhaps a lot of reading...), but before I dive into this too much, I'd like to read some opinions.  The administration would be for w2k and w2k3 servers, usually running either Oracle or IIS.  They've also asked about portability, in case they ever want to run some of these scripts in a UNIX environment.

I apologize for the lack of details, they haven't provided me with too much information.  I figure once I have some higher-level information I could form some more specific questions.  Any suggestions/comments/opinions are warmly welcomed!

Thanks,
KrAzY_NuK

[Kp]

I don't really have much background with scripting, only a few batch files, little bit of vbs, a hint of javascript, looking over some SQL scripts, and I've gotten my feet wet with Perl (Sounds almost like a recipe...mmmm food).  It seems that I spend most of my *programming* time with C/C++ or Java.

Anyways, at work, apparently we use VBS and Batch files for some basic console-based scripting, including scheduling tablespace checks for Oracle, etc.  I recieved a task saying that "We are potentially looking at adding a powerful scripting environment to our servers to help with administration".  They also mentioned elsewhere that "We've had problems with VBscript in terms of 'real power' - ie) it can't get really low level very easily".  So my job is to do some research, and recommend a possible alternative scripting environment to use.

The researching and reporting shouldn't be too much of a problem (after all, it's just doing a little reading on the net, perhaps a lot of reading...), but before I dive into this too much, I'd like to read some opinions.  The administration would be for w2k and w2k3 servers, usually running either Oracle or IIS.  They've also asked about portability, in case they ever want to run some of these scripts in a UNIX environment.

I apologize for the lack of details, they haven't provided me with too much information.  I figure once I have some higher-level information I could form some more specific questions.  Any suggestions/comments/opinions are warmly welcomed!

Thanks,
KrAzY_NuK

I'd suggest inquiring about priorities before you do too much research.  In particular, are they thinking about portability as a curiousity, or are they seriously considering a move?  If it's the former, a more Windows-centric solution is likely in order.  If they're seriously about moving to a Unix backing, greater emphasis should be given to a cross-platform solution.

That said, the next issue is one of "low level."  As you probably know, there's usually a trade-off between getting a low level language and getting one in which you can quickly design a script.  Since this is a business, I'm going to assume they're more interested in quick design than in quick execution, so anything that can make use of the guts of the system would be acceptable to them.  Also, consider whether you want to make an environment comprised of interlocking subcomponents, or one major scripting engine.  As a (silly) example, should the environment natively support compressing files, or would it be ok to execute an outside program (say, pkzip) to do the compression.  An interlocking system will be a bit more trouble to maintain since you have to take along all the component pieces, but it might also let you use a "higher level" language by picking one that can't directly achieve the result (or can't do it easily), but can spawn a subprocess to do the work on its behalf.

Of the languages you explicitly mentioned, Perl is the only scripting language I feel confident in speaking about.  It is extremely useful (and common) on Unix systems, and will provide you with great portability if you don't make Windows specific calls (e.g. the module that lets you access the Windows registry -- the Linux kernel doesn't provide a "registry" service the way Windows does, so there's no equivalent backend for the application to access).  That said, there may be some Windows-specific tasks that your scripters really want to do.  Of course, if such is the case, portability flies out the window until management tells them to find another way.

[Banana fanna fo fanna]

The obvious choices are Perl, Python, and TCL. All three languages are supported on most major microcomputer systems and are almost identical in terms of functionality. I (of course) recommend Python, but Perl is the choice of people too. TCL, IMO, sucks, but that's your call.

www.perl.org
www.python.org
www.scriptics.com

[KrAzY_NuK]

I'd suggest inquiring about priorities before you do too much research.  In particular, are they thinking about portability as a curiousity, or are they seriously considering a move?  If it's the former, a more Windows-centric solution is likely in order.  If they're seriously about moving to a Unix backing, greater emphasis should be given to a cross-platform solution.

Portability would be a curiousity.  If they were to consider a move, (i imagine) it would take at least a year to plan the move, and then much longer to actually perform it.

Since this is a business, I'm going to assume they're more interested in quick design than in quick execution, so anything that can make use of the guts of the system would be acceptable to them.

This is the city government, so things are pretty laid back.  They don't care how long it takes to do something, just as long as it gets done.  Quick execution isn't important either.

Thanks for the reply.  I'm going to have to bug them more about what exactly they want.  When I find out, I can post that here too.

Edit: I recieved an email back today.  They want it to do everything (Yes, very vague), but mainly calling other programs, and parsing files.  But he also said that giving pro's and cons for various languages would be enough, so that's what I'm going to do.

It seems that Ruby, Python, Perl, and Tcl are among the most recommended, so I will do some research on those, and compare them to eachother, and VBScript...

[Banana fanna fo fanna]

Whoops, I forgot Ruby. You might just want to use shellscript, too.

[KrAzY_NuK]

well..Tcl is out.  I very dislike it already.

Ruby seems very nice...
...now for the hard part

Ease of use (a language that its "like" would be good, e.g. VB, C, Pascal, etc), commentability

What languages would you sat Perl, Python, and Ruby are like?

[Adron]

well..Tcl is out.  I very dislike it already.

Ruby seems very nice...
...now for the hard part

Ease of use (a language that its "like" would be good, e.g. VB, C, Pascal, etc), commentability

What languages would you sat Perl, Python, and Ruby are like?

I think Perl is like C, but simpler yet more powerful... It requires less typing to do more things, and it has special syntax that is very very useful for parsing / processing text files. It's not strongly typed, so in that it's more like vbscript.

[iago]

This is a litle off topic, but I use Perl every day at work to do simple file processing.  I nearly always use it from the commandline to do things like convert files to lower case:

rb@celes:~$ cat file.txt | perl -e "print lc foreach(<stdin>);" > file.uc

Perl is extremely handy

[Banana fanna fo fanna]

I forgot awk and sed

I'd say go with Python. It's a dynamically typed language, which usually translates into fast development. It has a clean syntax, yet allows for a ton of functional power in one line. It's totally dynamic and supports generators, closures, and higher-order functions, not to mention it's OOP.

www.diveintopython.org is a free e-book to help you learn it.

It's got:
- all the features you'll ever need
- speed (psyco.sf.net)
- libraries
- user community
- cross-platform support

Perl and Python are pretty similar, except Python has beautiful syntax, while Perl's, IMO, is terrible.

[Mephisto]

Doesn't perl have some sort of built in library for parsing different paterns, data, etc.?

[iago]

Perl has fantastic built-in (not library) support for parsing strings for patterns and such.

In fact, PERL is very Practical for Extraction of data and Reporting on it.  Oh, and it's a Language.

I've never used Python or Ruby or any of them, but I would imagine that they are similarely good in terms of that kind of stuff.

[Mephisto]

Perl has fantastic built-in (not library) support for parsing strings for patterns and such.

In fact, PERL is very Practical for Extraction of data and Reporting on it.  Oh, and it's a Language.

I've never used Python or Ruby or any of them, but I would imagine that they are similarely good in terms of that kind of stuff.

PHP also has support for parsing patterns and expressions.

[MyndFyre]

Perl has fantastic built-in (not library) support for parsing strings for patterns and such.

In fact, PERL is very Practical for Extraction of data and Reporting on it.  Oh, and it's a Language.

I've never used Python or Ruby or any of them, but I would imagine that they are similarely good in terms of that kind of stuff.

PHP also has support for parsing patterns and expressions.

Yes, but PHP is intended specifically for HTML and HTTP.  PHP is a Hypertext Preprocessor.

[TangoFour]

In theory it should be possible to output something other than HTML with PHP, just a matter of rewriting the HTTP headers:

Code Select Expand


header("Content-type: image/jpeg"); // Or something along these lines


Still, in most cases, you ARE limited to HTTP

[Stwong]

PHP is command-line usable.  In fact, they distribute most binary packages with a CLI binary in it.  Which is how I use it most of the time.  If you ran some of my scripts on a webserver, you'd be short one webserver after a few hits ;P