>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).
>
We agree completely here; the choice of the scripting syntax and grammar
>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.
>
Absolutely. THE IS NO MAGIC IN THE COM OBJECT CALLED Scripting.whatever, or Wscript.whatever. You are 100% correct it's COM that makes it work. there's is no magic in VBScript vs JScript vs Perl vs Python vs whatever I can think up and implement.
Whay makes the Scripting. and Wscript. family of COM objects interesting is that they made their way into our development environments priamrily through the logical enhancements to process control that are repressented by scripting languages. If VFP, and early COM player, had brought us VFP.Network and VFP.ShellObject, then I'd be fanatical about those COM Objects that make the underbelly of Windows and process control in the Windows environment great tools. Not that they're script, but that MS made the decision to introduce them to us in the Scripting environment. The COM technolgy is the magic here.
>>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.
>
Exactly. But the idea of Scripting, and Script Components, a separate issue from these neat COM thingies, is important in the evolution of the platform. I'm not advocating going out and replacing parts of my VFP code with VBScript - I'm saying I want the COM that MS gave us via this technology. And the strategy behind MS using the Script platform to bring COM into the user environment in a big way is significant.
>>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.
>
Again, no argument, other than VBScript is a purely interpretive environment - I can build and fire it on the fly. Just like JScript. Or perl. Or whatever user command level integrated language is used in this fashion.
The magic here is that MS put together VB to, IMO, give a wide range of developers a toolset that gave quick and easy gratification. Everyone (including me) made lots of fun of it, but a ton of semi-competent and demi-compentent people got a lot of QUAD stuff churned out, with much less learning curve than VFP, or Java, or any of the platforms that other people offered where MS kept their hand in. Java, VFP, C++, etc. all have loyal followings. The average level of competence among developers using these tools is higher than the average VB programmmer. But you've got a small ocean of codemonkeys who can accomplish something in VB, and they serve as an anchor point for the application market.
MS could have picked
any of the languages mentioned above as the basis for automation for Office and other products. Beyond the idea that VB is 'their' product, the language that had the broadest market and the quickest return on personal investment got used, because it gave them a base of people who already had the skills to use VB to get something discrete done. They taught more people and MS made it easier and easier to leverage what skills had already been developed. If VFP had been easier than falling off a log, then I have no doubt that we'd be the subject of scorn from the VB elite...
Now, the weakest part of the platform, the basis of process control and discrete functionality leverages all the skills from VB, and VBA to teach end users and make that the better batch language. That's freaking brilliant strategy. Couple that with ASP and you can now leverage the only real market that VB had not really made a dent in - outside of Wintel. I'll be premature and bet on the winner in 5 years at relatively short odds.
Add to that the idea of a script component, to make it possible for anyone who learns much beyond the basic batch language to create and leverage COM, regardless of the development platform, using VB. MBASIC meets the Shell. And swamps the established tools from other platforms by sheer magnitude of people who can use it.
Bill Gates is a whole lot smarter than I am, if he really saw this coming back when MS committed their resources to VB. Seems he's got a couple of gigabucks in the bank, not me...
>>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.
Because to anyone who's grown up in fear, awe and frustration dealing with programmers now can do it. OK it ain't the bestest fastest most elite, optimal, erudite thing to develop things. It doesn't matter. They're programming, doing things that (we always knew were easy) they thought were tough and required special skills, and making it more attractive to leverage what the user already knows when we go to offer our next product.
If you accept that the premise I state here is the reality behind VBScript and VBA and VB, then I think you have to hand game, set and match to MS here. I wanna be a smart as the people who came up with this strategy 10-15 years ago and made it work.
