but why does anyone want to write hybrids in the first place? i don't understand.
1) makes code uneasy to read and troubleshoot
2) have to take care of different syntax between vbscript and batch.
3) creation of temp files everytime the batch is run. why not just write one vbscript and run it instead.
I make no great claims for this, I just present it as a curiosity. There are other ways of doing this.
1) makes code uneasy to read and troubleshoot
As opposed to, of course, the perfectly easy to read perl.
2) have to take care of different syntax between vbscript and batch.
perl programmers have no problem taking care of the different syntax between perl and Regular Expressions. .NET programmers have no problem differentiating language constructs from those provided by LINQ, and I hardly see batch+VBS as a exceptional case.
3) creation of temp files everytime the batch is run. why not just write one vbscript and run it instead.
As surprising as this may sound there is a lot of functionality in batch (particularly in the various NT extensions) that, while doable in VBScript, are far more verbose. also, we cannot forget that a a good number of the very tools you recommend (sed, gawk, and a few others) are at their best when combined with the shell in which they run- piping output to and from SED is it's very purpose, just like find and sort, both of which have functionality that is verbose and prone to errors when attempting to duplicate in VBScript. also, this allows one to combine Batch with SED and other tools of that nature with VBScript.
There is a rather large downside, and that is the extraneous use of find in order to "extract" the vbscript, but one can generally assume that a batch files run-time is far less important then it's results, and unless it is run extensively and/or with a large batch file it's usually of little consequence.
The concept is by no means new. Some COBOL Programs had FORTRAN embedded in the source code. There was COBOL statement to invoke the FORTRAN compiler for some calculations.
I embed machine code instructions in my Visual basic programs in the form of a string variable or constant, and then use that as a Window Procedure for subclassing; The Machine Code is given access to the Vtable of a specific Interface and calls the methods on that interface, which I implement elsewhere. (in a class module, for example).
VB6 of course has built-in "support" for callback routines (in the form of the addressof Operator) however, one can only use addressof on functions/routines in public modules; managing and dispatching each callback to the appropriate object that is to receive it is nothing short of difficult. Also, it means that using the debugging tools (break, stop, breakpoints, etc) will cause a instant Fault and VB will crash. Using a String variable containing Machine code has two advantages- first, it can be used without a module (meaning each class is self-contained) and second, since the string pointer remains valid, it doesn't crash the IDE when the break/end etc. buttons are used. My first concern using this technique was that it might somehow trigger DEP (data execution) but it didn't, and it's worked fine so far.
A prime example of this facility in use was a class I wrote for better control of window sizing- namely, to allow for the handling of the WM_GETMINMAXINFO; the class itself simply needs to be instantiated, given a form/hwnd, and it does the rest; allowing the use of properties to control the minimum and maximum size of the form/window. I've used this mechanism extensively in a number of classes designed for various features, They generally implement a particular feature, such as, for example, handling combobox histories, or listview sorting messages, etc.
Of course newer languages (such as .NET) have most of these features built in, (namely, I speak of the ability to handle WndProc for nearly any hWnd) but such luxuries come at a price- the installation of the framework, which is not always quick, small, or always error-free.
I'm not sure about Python, But I do know that Perl was intentionally designed in a way dissimilar to most languages. Most languages make you think of your problem in terms of the language, Perl is designed to allow you to think of your problem and code your solution to the problem.
it's not about what language you use, it's about solving the problem. Wether a batch file, a python script, a perl script, VBScript, or even a batch file with VBS inside solves it is completely irrelevant.