• Do you use .NET from VBScript?
  
• Where can I get more information?

quote:


"Microsoft is fully committed to evolving implementations of both JScript and VBScript to a level where each language is functionally equivalent. So don't feel that you need to commit to one just to ensure that you are investing in a language that has a future."

If that statement is true, Microsoft is keeping the future of VBScript well-hidden. The most telling stroke against VBScript is that with two cumulative releases of the .NET framework and Visual Studio now behind us, there's still no sign of a VBScript.NET. There's a JScript.NET—has been since the early beta releases—but no VBScript.NET.

Does VBScript Have a Future?
I once believed that VBScript would rapidly become the script lingua franca of the Internet. After all, VBA, another cut-down version of Visual Basic, found its way not only into the Microsoft Office suite as the primary macro language, but also into a host of other commercial products. Because VBA and VBScript are fundamentally similar and therefore attractive to the same large universe of developers, one might rationally assume that VBScript would make an equally successful transition into Web products as VBA did in desktop products. But that didn't happen. If functional equivalence with JScript were a goal, Microsoft could have created a VBScript.NET. At one point, they had a third-party company create a proof-of-concept VBScript.NET, according to David Simmons of SmallScript Corp.—but Microsoft has apparently made a unilateral decision not to bring the language along into the .NET family. Unless rectified quickly, that omission represents a hard stop for VBScript, whereas VBA's future looks a bit more stable for the short term, if not for the long term.
From all appearances, VBScript is on a path to extinction. And with all due respect to VBScript, that's probably a good thing. In spite of the broad industry support for JavaScript, Microsoft probably could have garnered equally wide support for VBScript if it had ported the language to other platforms early in its lifecycle. However, as that didn't happen, there's little reason now for Microsoft (or its customers) to maintain the fiction that VBScript has any serious future as a Web language. I interpret VBScript's absence from .NET as Microsoft's tacit agreement that VBScript has no future. In my opinion, the lack of client-side support and the absence of VBScript.NET should serve as warning signs to developers or organizations using or planning to use VBScript.
Of course, VBScript aficionados are perfectly free to ignore these warning signs and continue to use this familiar language; but unless Microsoft has some sudden radical VBScript epiphany, those who do should be prepared for heartache and frustration down the road. By the way, if you want to buy the domain name VBScript.NET, it's for sale.

quote:


 Back then I spent a lot of time working with the VB .NET language designers to see if these ideas from VBScript would work in VB .NET, thereby giving VB .NET a better backwards compatibility story with VBScript.



Regrettably, by and large, they don't.  (I may go into details in future blogs as to some of the crazy ideas we had for making VBScript work in the .NET world.) Based on that experience, I absolutely 100% disagree that fracturing VB into a FOURTH variant -- VB6, VBScript, VB.NET and the proposed VBScript.NET -- is a good way to achieve the laudable goal of lessening the VB learning curve.  We can improve VB without fracturing it into yet another variant. 

quote:

ORIGINAL Marvels of COM .NET interop @ Compact Framework Musings. Alex Feinman's web log
[...]
From the System.Collections namespace we have:

• Queue
  
• Stack
  
• ArrayList
  
• SortedList
  
• Hashtable

I'd say it makes a rather nice addition to the existing VB script (and javascript as well) toolset. But wait, there is more...
System.IO namespace is represented by two useful classes:

• StringWriter
  
• MemoryStream

Finally, there are System.Text.StringBuilder and System.Random classes.
Why would I be interested in StringWriter (or StringBuilder)? Because frankly, VBScript memory allocator sucks. Anyone who ever tried to build a large string concatenating small ones knows that after 65536 characters performance drops drastically. Concatenating first 65536 characters one by one takes about 1.5 sec on my 3.5 GHz machine. Appending the next 65536 takes about 4 sec. The following 65536 characters take 33 sec. And you don't want to know what happens after that. Well, in case you do, appending together the string representations of numbers 1 through 100000 takes over 2 minutes.
Of course I decided to check if I could do it faster with StringWriter. But there was a catch. If you check the lsit of methods of the StringWriter class in the Visual Studio object browser, or rather the TextWriter class, from which StringWriter derives all of the Write methods, you would notice that Write() has 17 overloads, and WriteLine() has 18. Obviously you would want to use a particlular overload. How do you choose one. As it happens, the .NET framework deals with this problem in a straightforward, if inelegant way. If you have 18 overloaded methods called Write, they are exposed as Write, Write_2, Write_3 ... Write_18. How do you find out which one is which? If you look into the class browser (or Ildasm), the order of the overloads is reverse to what you see. E.g. for StringWriter we have:

• System.IO.TextWriter.Write(string, params object[]) // Invoke as Write_17
  
• System.IO.TextWriter.Write(string, object, obejct, object) // Invoke as Write_16
  
• System.IO.TextWriter.Write(string, object,object) // Invoke as Write_15
  
• System.IO.TextWriter.Write(string, object) // Invoke as Write_14
  
• System.IO.TextWriter.Write(object) // Invoke as Write_13
  
• System.IO.TextWriter.Write(string) // Invoke as Write_12
  
• System.IO.TextWriter.Write(decimal) // Invoke as Write_11
  
• System.IO.TextWriter.Write(double) // Invoke as Write_10
  
• System.IO.TextWriter.Write(float) // Invoke as Write_9
  
• System.IO.TextWriter.Write(ulong) // Invoke as Write_8
  
• System.IO.TextWriter.Write(long) // Invoke as Write_7
  
• System.IO.TextWriter.Write(uint) // Invoke as Write_6
  
• System.IO.TextWriter.Write(int) // Invoke as Write_5
  
• System.IO.TextWriter.Write(bool) // Invoke as Write_4
  
• System.IO.TextWriter.Write(char[], int, int) // Invoke as Write_3
  
• System.IO.TextWriter.Write(char[]) // Invoke as Write_2
  
• System.IO.TextWriter.Write(char) // Invoke as Write

This means that if we want to write a string into a stringwriter, we would call:
s = “Bob“
Set wrt = CreateObject("System.IO.StringWriter")
wrt.Write_12 s
To test the performance of a StringWriter as compared to concatenating a VB string I ran the following script:
'stringtest.vbs
WScript.Echo Now
s = ""
for i = 1 to 100000
s = s & CStr(i)
next
WScript.Echo Now

set wrt = CreateObject("System.IO.StringWriter")
for i = 1 to 100000
s = CStr(i)
wrt.Write_12 s
next
s = wrt.GetStringBuilder().ToString()
WScript.Echo Now
And here are the results:
8/28/2005 1:02:14 AM
8/28/2005 1:04:07 AM
8/28/2005 1:04:08 AM
As you can see, concatenating a VB string took nearly 2 minutes, while .NET string was only a second.
But wait, there is more...
Let's take a look at the StringBuilder class. The most important feature of it (at least in the context of what we are doing here) is formatting. There are 5 AppendFormat methods:

AppendFormat ( System.IFormatProvider provider , System.String format , params object[] args )
AppendFormat ( System.String format , params object[] args )
AppendFormat ( System.String format , System.Object arg0 , System.Object arg1 , System.Object arg2 )
AppendFormat ( System.String format , System.Object arg0 , System.Object arg1 )
AppendFormat ( System.String format , System.Object arg0 )

Let's see if we could easily use one of them:
'sbtest.vbs
set sb = CreateObject("System.Text.StringBuilder")
sb.AppendFormat_5 Nothing, "{0} is a {1} number" & vbCrLf, Array(1, "loneliest")
sb.AppendFormat_5 Nothing, "{0} is a {1} number" & vbCrLf, Array(2, "happiest")
WScript.Echo sb.ToString()
Prints:
1 is a loneliest number
2 is a happiest number

We have formatting! In VBScript.
[...]

quote:

Get name of the next property of [the object] that doesn't have the DontEnum attribute. If there is no such property, go to [the end]