>I may be a square head, but I still don't understand where's the advantage of using script languages instead of
>non-script languages.
>
>What can be done with a script language and cannot be done otherwise?
>

Nothing, other than build and execute code on the fly in situations where a native programming language environment is not otherwise available. I like having a set of common tools avaialble to me across all of the working environments I deal with, that have more expressive power than a straight sequential batch of commands, or even one with some simple branching capabilities.

I want to be able to control my environment. We can discuss the psychological aspects of this at another time. I'd like to be able to use a common syntax and grammar in a cross-level, and preferably cross-platform environment. The shell environments from ?nix, which can admittedly be grafted onto Windows at least at the command line level made my life very, very easy. Bith there are a whole lot more competent WIndows users than people who could make an intelligent rgument for the advantages of one shell environment over another under BSD...

The fact that it's a scripting language in and of itself is not the attraction of VBScript. I can get that with Jscript, or a dozen others. The value of VBScript and VB syntax is that it crosses product boundaries well in the Wintel environment, and you can leverage the knowledge of the basic syntax and grammar when moving into another environment. If the automation language behind Office, and the WMI, were Java-derivative, we'd be singing the praises of Jscript as the savior of sanity in the Wintel platform.

>It looks to me that all this scripting mania is similar to all those "cool" batch (.bat) programs... that (with very rare >examples) I've never understood their power.
>

Wold you rather use TECO or emacs? The base batch language at the DOS prompt is, IMO, inadequate to the task of directing job streams. That's where an appropriate application of scripting language comes in and makes life easy. Being able to build COMponents with the same language and incorporate them into other work environments easily, conveniently and consistently is what makes VBScript compelling. If it were not for the added leverage of other tools like VBA, there'd be little to recommend VBScript over Jscript over Python, other than it's there, we already pay for the overhead of supporting it in the platform, and I'm lazy enough to want to solve the same basic problem in the same fashion. And with the same language skills. Otherwise, we are more likely to make the same sort of mistake that made Preseidnet John F Kennedy proudly proclaim "I am a jelly doughnut" to a crowd of awestruck Germans who were too polite to fall over and laugh their asses off...

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.

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.

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.

>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.

>So, I understand that scripting languages evolve more and more and, more and more, they can be used to
>accomplish tasks that could be accomplished only with non-scripting languages.
>
>Can anyone explain to me where's the advantage in using scripting languages vs. the old way? What does this "new
>technology" brings new? What's that problem that couldn't be solved before and it can be solved now with scripting languages?
>
It's not a "brave new world" - scripting and job streams and the like predate the PC by lots. We just haven't had it available to the common clay of the WIn User populace before.

Nothing inherent in a scripting language makes it "superior" to a "Real Programming Lanuguage" (insert appropriate beating of shields against breatplates, helmet butting sounds and the heady smell of codemonkey testosterone; after all, real men toggle in the binary instructions for apps on the front panel display) - it just makes the number of players capable of doing it that much larger, and provides some extra hooks for users and programmers to extend things on the fly. The script language adds a layer of functionality that we can exploit now, and that others can reexploit later after we ship. Just like we can change a .BAT file or .INF file or any of the other wonderous programming tools that are essentially text-based, interpretive environments that can adapt without re-submitting the basic platform for revision.

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...