“The main theme of the presentation is the same one I've been talking about on and off over the past year or two: moving Visual Basic back towards it's scripting roots. The main thrust of this presentation was the technical side of the story--namely, what we would need to do to the existing Visual Basic compiler to be able to effectively use it as a scripting engine. The presentation talks some about the way the compiler is structured, how it might change and some of the things were thinking about enabling.He also pointed out that language changes (like the XML native stuff in VB9) are necessary too:“all the services that the compiler provides...are available to be used by any program that needs them.”In particular, what we'd like to see is not just that Visual Basic can be embedded anywhere, but that all the services that the compiler provides--parsing, semantic analysis, code generation--are available to be used by any program that needs them. The DLR is a key part of this, but there's a lot of work on top of that.”
“One thing this presentation didn't cover (and which Ted Neward brought up in the Q&A afterward) is what we might do to the language itself to make it more scripting-friendly. That's an area where things are less well-defined and even more speculative than what I talked about, so I left it out for now.”Making the IDE services available to other programs allows a suite of competitors to Visual Studio to open up - so I'm not sure whether that will really fly (unless it's protected by licensing). But it does offer intriguing possibilities for scripting tools for administrators to use (provided they are familiar with VB) and perhaps even the ability to give end-users some access to create code in a Domain Specific Language (DSL) that makes sense to them. It could let you create an online query tool for large XML files. Whether modern systems administrators will welcome this sort functionality is another thing of course - and the security implications could be pretty scary.