>Aside from process control and automation through VBA/ASP etc. there are things that we inherit from the scripting environment, like the Wscript and Scripting family of automation objects. I like having a base tool like VBScript with an internal RegExpn object, so that when I need the functionality of a regular expression handler and don't need the raw performance available from building a better implementation for use in my app, it's there for the asking. Would you rather explain the details behind attaching resources via the API and using moderately obtuse structures that admittedly give you a better handle on what happens beneath the hood, or say - create this object and call this method. if you want more details or need more performance, you can get there, but this will minimally and efficiently accomplish the task.

First, I want to say that I don't want to compare C++, VFP, VB or Java, individually, with VBScript or JScript individually.

I am more interested in what does a scripting language (it doesn't matter which one) brings new vs. compiled languages (it doesn't
matter which one).

No, I don't prefer raw API (with all its structures) over COM objects. But this is like discussing assembler vs. high level languages.
Basically, one can use the same COM objects from a scripting languages or from a compiled language. The usage is the
same.

>An example of where the convenience and clarity of some thigns we inherit from the script environment might make my position clearer. VFP's interface to the file system is not complete or well-defined. The Scripting.FileSystemObject is a cleaner reflection of the file system under Win32 than the native VFP constructs. You can get at least the same functionality from the Win32API - you just have to work harder to get to the point of being able to use it.

Just because that library of objects is called Scripting.SomeObject doesn't mean it has something to do with scripting only.
The same objects can be used from any languages that handles COM objects. That library could be called
Windows Helper Objects (or anything else), and the "scripting" idea disappears without losing any functionality.

>Scriptability of environments - the capability to customize behaviors and deploy capabilities not originally internalized to the environment that you work in on a day to day basis, and even more so, to let the semi-sophisitcated user customize and deploy after the fact are compelling reasons for scripting languages. Not that "It's VB" or "It's Java". It's a customization tool that leverges what you've learned across products.

I agree. But in this case it's more about the large spectrum of applications that use/accept VB/VBA/VBScript as a common
language. It doesn't mean VBScript is better than VB, so, there's nothing magic in VBScript vs. VB.

>>Or, more precisily, reinventing the wheel. But not a better wheel.
>>
>Or in the case of VFP and Scripting.FileSystemObject, making the wheel circular rather than hexagonal.

Again, if we change the "Scripting" name into anything else... it's the same old COM technology, so, we discuss the advantages
of COM, not the advantages of scripting.

>Face it, would you rather write a .BAT file or write a custom C program to run a series of processes? If you say "I'd write a C program that read a text file and executed the stream of instructions" then you're writing YASL (Yet Another Scripting Language) for no apparent reason...

Sure, for simple tasks, scripting tools are great. What I don't understand is why I hear so much about the amazing new features
available in VBScript. The new amazing features are not new at all in almost any other serious language and the implementation
is usually better in compiled languages.

Vlad