Time ever marches on…

Now that VB 2005 Beta 1 has shipped, the time has come to start doing some “long lead” work on versions beyond the 2005 release. What this means is that while 98% of the team remains focused full-time on finishing the current product, a few people get to start spending some of (though hardly all of) their time thinking about the kinds of big issues that we might want to solve in the next version(s). A good way of thinking about it is that before a version ships we try to lay some of the groundwork for the next release so that when the rest of the team is ready to engage on the next version down the road, we can hit the ground running. (Other teams are also starting to do some of this work, too.)

At the moment, I’m spending my long lead time thinking about two major things. One is: what can we learn from scripting languages? We sort of discussed this back in March, and now I’m returning to the question, both in terms of the question of development environment and in terms of the question of dynamism. (Which is also interesting given that the CLR hired a scripting language implementer specificially to work on making the CLR better for dynamic languages.) The other is: what can we do to improve data access? This is something that other languages are thinking about as well. My interest stems not just from the fact that people find it difficult at times, but from the fact that my first job at Microsoft involved working a lot with SQL and data access (I worked on the query designer in Access) and I’d like to see us improve in that area.

Those are just the two things that I’ve started with, but there’s certainly room for other things as well. What other things would you like to see? I’m not talking about features (you can go submit those requests here and the product teams will see them), I’m talking about big picture areas like the ones I mentioned above. What areas do you think we could do better in? What areas do you think there is untapped potential? Can’t promise I’ll look at everything, but I’m curious to see what people might be thinking.

(Since we MSFT bloggers often get dinged for talking only about the future and never about the present, I should add the disclaimer that I don’t plan on talking too much about this long lead work for the forseeable future. This blog is still going to properly remain focused on VB 2003 and VB 2005, not on random ideas about the future that may or may not ever come to fruition. There’s been way too much of that at Microsoft in the past.)

16 thoughts on “Time ever marches on…

  1. Robert Conley

    I don’t remember but there was some interesting work done with csharp on making relational databases and list type first class members of the langauge rather than through an api (object oriented or not). This included operators. It would be great if this was done easier in vb.

    I guess the general thing to do for the big picture is to look at the most common programming tasks done today and see if you can come up with a better way through the langauge rather than the API.

    Even tho this may be considered a feature request. We got to have better VB6 compatibility. I maintain a CAD/CAM project that is over 100,000 lines of code and dozens of objects and the poor VB6 compatibility is killing any chance of moving over to VB.NET. It is bad when you can’t move over a CLASS Library without forms without generating tons of errors. (This is mostly due to the lack of support for global multiuse COM DLLs).

    Visual Basic was one of your biggest sellers ever and it still blows my mind how much little compatibility there is. Now I know how all those PB/Quick Basic guys fealt with Visual Basic 1.0. But the thing that saved VB then was the fact Windows exploded in numbers and VB was the way for the common guy write apps for Windows.

    You are not going to see the same Order of magnitude increase this time in programmers for .NET. So many are going to look at alternatives since they have to do a conversion anyway. Like when many PB/QB programmers went with PowerBasic and other alternatives in the early 90′s.

    Reply
  2. Greg

    Refactoring (like or better than in c#’s 2005 IDE)? Please?

    Maybe this isn’t a "long lead" item, but it does seem to me to jive with the "VB’ers Just Want to Get Stuff Done" mindset (The same mindset that brought us the VERY cool MY namespace…?).

    We already do refactor (manually). We do create code that lives a long time. We improve, add to, change this code, etc, etc.

    It would be nice if the IDE could "just get it done" when it comes to refactoring.

    If the term refactor scares people, then call it "Simplify" or "Clean up" or "Uber Search and Replace"… but what ever it’s called, it would be a great time saver…

    Yeah, yeah, yeah… I know this whole refactoring in VB issue has been beaten to death, but you asked for what we wanted to see.

    Thanks for listening. :)

    Reply
  3. Pingback: VS Data Team's WebLog

  4. Fan

    Refactoring is good, but we can go forward. How about design patterns? A tool or some language features for common design patterns are realy considerable. And…how about strings. VB needs something to simplify the operation of strings. For example, match the regex, or something smarter and more convenient. Data access is very important, so keep your mind and improve it. I hope to have a fantastic experance of data access!

    Reply
  5. Alex Kazovic

    I would like to see the ratio of error handling code compared to total code that I write to decrease substantially. In an average production system 99 – 95% of the execution time is spent executing “business logic” code. Therefore, 1 – 5% of the execution time is spent handling errors. I would like to spend only 1 – 5% of development time writing error handling code. Currently I spend approximately 30% of development time writing error handling code. This is too much.

    I realise that this error handling code is necessary, I but I don’t wont to spend time writing it. I’m not sure if the answer is more of a declarative approach or something else.

    Reply
  6. Robert Conley

    Aspect programming specifically the ability to decorate subroutines, and functions with standard entry and exit procedures (i.e. like for error handling).

    So you can mark one or more procedures with an aspect that say "Do this when you enter", "DO this when you exit". Then the code for the entry and exit stuff can be in one spot, and changes can be made to one spot.

    And if you go the full aspect route apparently there are a lot of interesting problems that are easily solved.

    Reply
  7. Alex Kazovic

    As a general point, I think there is a great potential advantage having more than 1 language on .Net. It allows each language team to work on different areas and then leverage the work done by other teams.

    E.g. I believe the VB team were the driving force behind Edit&Continue. The version that is in VB 2005 is the second version. The first version didn’t work too well. Now that the VB (and CLR) team have got it working, the C# team can incorporate it into C# by leveraging on the work already done.

    Similarly, I would be content to let the C# team work on Comega. Once that have got if figured out and working well in C# the VB team can then incorporate the concepts in VB. In the meantime the VB team can focus on different areas.

    I know that this will mean that we will have the Comega stuff in VB latter, but we will also have other stuff earlier.

    Reply
  8. Mike Schinkel

    As for data, I would love to see you handle embedding SQL Statements into code in some better way than current. One method would be something like this:

    DIM strName AS String= "XBOX"

    DIM strSQL AS String

    BEGIN TEXT TO strSQL

    SELECT ID,Name

    FROM Products

    WHERE Name LIKE ‘%{strName}%’

    END TEXT

    Another approach is to actually implement a sublanguage recognizer interface that would allow VB to switch contexts and recognize a sublanguage (could be used to recognize MSIL, for example). That would be a much broader scope but would provide much more overall value. If would also allow the sublanguages to be type and syntax checked. (Paul, your thoughts on that? It that even viable?)

    Reply
  9. Pingback: Anonymous

  10. Pingback: Anonymous

  11. Pingback: VS Data Team's WebLog

Leave a Reply