Discussing VB, scripting, dynamism and such

As the eagle-eyed may have noticed, I recently added a new post category called “VB/Script.” In it I have collected a number of posts that I’ve written over the years concerning VB, scripting, dynamism and so on. Specifically, I’ve pulled together (in chronological order from earliest to latest):

I’m doing this because I expect that in the coming months/years I’ll be talking more about these kinds of things, and I want to make sure they’re all easily accessible. A couple of quick notes on the category name, though. First, I put that slash in there to emphasize that I am not talking about VBScript, the IActiveScript script engine, per se. I’m just talking about “VB” and “scripting.” And, second, I realize that the term “scripting” is so incredibly overloaded as to be practically meaningless—for example, “scripting” doesn’t necessarily mean “dynamism,” even though I’m lumping them together here. However, I don’t want a category named “VB/Scripting/Dynamism/Etc,” so I’m just going to pick a single term and figure that everyone can figure out what I mean. Hopefully, you all can… <g>

7 thoughts on “Discussing VB, scripting, dynamism and such

  1. Leigh Kendall

    I might consider going back to VBScript from JavaScript for IE client-side use, IF, and only IF MS would add try/catch to the language.

    Any plans to add this?

    Reply
  2. Leigh Kendall

    Sorry, reread you post this morning and can see my post is way off-topic! Sorry…

    If anyone does however know the answer to my question, please reply… 😉

    Reply
  3. Bob Frankston

    Nice to see all these features in VB though I do worry about trying to understand all the interactions.

    One feature that I did not see is one my favorites in C# — lexically scoped variables in anonymous delegates. Or, for that matter, anonymous delegates.

    This turns out to be important when programming threads making it easy to do something like

    return (Font)ctl.Invoke(new GetFont(delegate() { return dgvr.DefaultCellStyle.Font; }));

    Reply
  4. paulvick

    We will support lambda expressions so we can support LINQ, the real question is how they are surfaced above and beyond LINQ expressions. When you say "lexically scoped variables," do you mean the ability to declare new variables in lambda expressions?

    Reply
  5. Roshan James

    Here is one suggestion – please keep VB syntactically clean.

    As much as I like all the goodness they are adding to C#, I wish it were easy to read or write that langauge with all the templating and typing annotations.

    Add a type inferencer if you have to, but still keep the language syntactically tractable. VB is still – or atleast claims to be strongly typed doesnt it? So adding a type inferencer should be viable in the general case.

    I remember watching your C9 video (the one with Meijer) about duck-typing in VB. Maybe you can add a keyword to make duck typing explicit and keep inferencing and strong typing as the default.

    Are either of C# or VB considering a macro language?

    One the topic of new fatures here is one – see if the language can expose a single object for all sorts of things it gets from the OS – COM objects, WMI objects, .Net objects etc. That makes scripting a pleasure.

    Roshan

    Reply
  6. Roshan

    Let me rephrase –

    "One the topic of new fatures here is one – see if the language can expose a single object for all sorts of things it gets from the OS – COM objects, WMI objects, .Net objects etc. That makes scripting a pleasure. "

    I meant to say "expose a single object model for all sort of objects". Keep the underlying underlying object representation transparent when the language goes duck-typed.

    Roshan

    ps. I am sure you guys are already thinking of all of these things 🙂

    Reply
  7. Mike Schinkel

    Uh, let’s revisit this then, okay?:

    http://www.mikeschinkel.com/blog/amodestproposalvbscriptnetakahelpingmortusenet/

    And don’t get TOO bogged down in my specifics. It can be VB.NET instead of VBScript .NET, but address the same issues.

    Oh, and the most critical issue is a simple editor/IDE, and include an interpreter. For the latter I’m envisioning something that works like SQL Server Query Analyzer; highlight code and run it. That would make learning so much easier, especially if you could keep lots of code in the window and only run the highlighted code. Just like in SQL Server Query Analyzer.

    If you haven’t done so yet, look at Boo (http://boo.codehaus.org/). Heck, hire the guy and get him to release Boo for the Morts of the world. And give him someone to build a simple IDE for him.

    You could also do the same for PowerShell. Call the IDE "Power Developer" and target Morts. Let them use it to develop in PowerShell, VBScript .NET, and Boo.

    Reply

Leave a Reply