Category Archives: Visual Basic

The Tyranny of the Suite

14 Replies

Another common comment around refactoring has been: why do we have to wait for a whole other release to get refactoring? Why can’t you just do the features and then ship them when they’re ready?

The answer, for the moment, is that we are subject to the “tyranny of the suite.” Which is to say, we are so tightly bound to the rest of the suite of products that we ship with (C#, C++, J#, debugger, IDE, SQL Server, CLR, etc.) that it is extremely difficult for us to ship separately from the rest of them. In effect, it’s like we’re running some freaky twenty person version of a three-legged race. Because all our legs are tied together, nobody can move forward unless we all do, and coordinating everyone to step at the same time is a major undertaking.

This binding was absolutely necessary to ship the initial version of .NET because it was a v1.0 product and we needed every piece of the puzzle in place to make the system work. Now that we’ve moved beyond that, though, it does seem like it should be possible to move more towards a “ship early, ship often” strategy that allows individual pieces to innovate separate from the rest of the suite. Some things, like generics, would still require simultaneous work across the entire stack, but other things, like refactoring, could be done in smaller, incremental releases.

Now, whether this actually happens remains to be seen. A lot of the machinery that goes into release management is shared across the suite, and it’s not clear how possible it is to disentagle it all. Plus, the butterfly effect holds: small, out-of-band releases increase the test matrix and make it more likely that, say, a minor VB release could conflict with a minor ASP.NET release in ways that were very unfortunate.

Anyway, I think what can be said best is that we are always looking to improve our release strategies and get new features into the hands of our users as soon as possible. Time will just tell.

Refactoring and drafting, revisisted

1 Reply

In response to my entry on refactoring in VB 2005, some have asked why VB couldn’t take advantage of C#’s work on refactoring the same way that C# took advantage of VB’s work on Edit and Continue. I anticipated this would come up, and the answer is that some features are subject to drafting at the current time and some aren’t.

Edit and Continue is a feature that spans the compiler, the debugger and the CLR. As such, work done in the latter two areas can be applied across all the languages that want to take advantage of Edit and Continue. Refactoring, on the other hand, is a feature that is currently implemented entirely within the compiler. Thus, there’s no opportunity for taking advantage of the work that other teams have done on the feature.

Now, one could certainly imagine a world where it might be possible to share the work on refactoring across the languages, but we’re just not there yet. Refactoring requires an intimate understanding of the structure and meaning of the code that’s being modified, which is why it’s currently implemented as a part of each language’s IDE component. If there was an abstraction layer, however, that could abstract away the different syntax and semantics of the languages to such a degree that one could manipulate C# and VB code in a language-independent way that preserved semantics, then common refactorings would be possible. At the moment, though, neither VB nor C# is architected in this way.

Given some of my experiences with the CodeDOM and WinForms designer trying to do a much simpler form of this, I’m not entirely sanguine that such an abstraction layer is possible. Perhaps some of the third-party refactoring tools will prove me wrong on this. It’s something that we talk about and will think about as we move past 2005, but for now each language is on it’s own as far as refactorings…

Refactoring: Not for VB 2005 (for the most part)

40 Replies

The problem with making confident predictions about the future is that time has a way of making a liar out of you despite your best intentions. As Steven posted Friday, VB will not have any refactoring features beyond “rename symbol” in VB 2005. This was an extremely painful cut and one that we tried to move heaven and earth to avoid, but in the end we didn’t feel we could get the features into the product in a high-quality way without causing serious risk to our shipping goals. Balacing the cries for refactoring against the cries for us to ship as soon as possible was difficult, and we really regret the fact that it ain’t going to happen this time (for the most part… it’s not like rename symbol is chopped liver or anything!).

On the other hand, it does mean that we get a while longer to have lots of colorful, humorous arguments about whether we should have a “Refactoring” menu in VB or not. Oh, joy… 

VB Parser Beta 2 released.

1 Reply

I’ve updated the GotDotNet workspaces for VBParser [07/12/2014: The sources are now on GitHub.] with what I’m calling “Beta 2” of the parser source. This fixes all the reported bugs as well as includes a small “conformance” application that I wrote to test the parser and allow some ad hoc testing. Probably the biggest change in this release was changing the way comments were parsed to make them actually work (I hope). I’m still trying to find some time to write an interesting sample using the parser… (And, of course, I need to start updating it for VB2005…)

Let me just add something that many people seem to already know: GotDotNet workspaces are, uh, not that wonderful. I’ve had a lot of trouble with it, so I’m considering alternatives. Given that the model so far has been people report bugs and I fix them, I may just go to distributing the sources and binaries as zip files on my website. Anyone care?

Free VB (and a book)!

5 Replies

(For those Aussies among my readers, this is not about free beer. Sorry.)

Someone pointed out to me a new promotion we’re running – if you attend three live or on-demand webcasts at http://www.aspnetwebcasts.com, you can get a free copy of VB Standard edition and an ASP.NET development book. What a deal! This only runs through November 30th, 2004, so hurry and learn something about ASP.NET, quick!

Form constructors and DTEE

1 Reply

Some people were curious what I was getting at with my quick question yesterday, so now that I’ve got a little more time to explain, let me…

The problem that we’re looking at right now has to do with some subtle interactions between several new debugging features in VB 2005. One of the features is what we call Design Time Expression Evalutation (abbreviated to “DTEE”), which is just a fancy way of saying “you can evaluate expressions and call functions from the Immediate window even when your application isn’t running.” This was a nice feature from past versions of VB that we lost in VB 2002 and we’re happy to bring back in VB 2005.

The way DTEE works is that it actually starts up a copy of your application in the background when you try to evaluate something at design time. This background copy of your application is called the vshost process, and what the debugger does is set a breakpoint at the very beginning of the program to prevent the vshost application from actually running and doing things like putting up UI, etc. The vshost process then sits there in a debug break state, waiting for the user to ask to debug the application or do DTEE.

Another feature that I think we introduced in VB 2003 but are extending in VB 2005 is something called “Just My Code.” This is a debugger feature that filters out all the non-user code from places like the callstack window and prevents the application from breaking in non-user code. This means that if you call a .NET Framework API that throws an exception, you’re going to break in your code that called the API rather than way down in the Framework (since you likely don’t have any source code for the Framework). You can always turn off JMC in the options dialog if you want to see non-user code, BTW.

Now, let’s think about a new WinForms project for a moment. A new WinForms project contains no actual user code, because all the code in the hidden partial form class is marked as non-user code. So… can you see the problem? Right. You can’t do DTEE on a new WinForms project because the vshost process tries to put the breakpoint at the beginning of the program, but since the beginning of the program is not user code, JMC prevents the breakpoint from getting hit.

This isn’t a huge, huge deal – there are a couple of ways we can attack this problem. One proposed way would be to make changes to the debugger to recognize this kind of situation and handle it in a different way. Another proposed way was to change the way that we handle Sub New in the hidden partial class, perhaps making it compiler generated (and thus allowing us to fiddle with the way the debugger sees it). This would mean automatically generating the call to InitializeComponent as well, but what happens if the user specifies their own Sub New? Should we still automatically generate the call to InitializeComponent? If so, should it be before or after the user code in Sub New?

So the purpose of my request for feedback was to get a general feel for how we might have to proceed if we went down that path. The most important thing, of course, is to First, do no harm (to mis-quote the Hippocratic Oath). In solving one problem, we don’t want to create more problems for people.

I’ll let you know what we end up doing in the comments here… Thanks for all the quick feedback!

Feedback request: Form constructors?

21 Replies

A quick request for feedback… How often do you:

  • Use Sub New in a form instead of handling the form’s Load event?
  • When you do use Sub New, are there things that you have to do before the call to InitializeComponent, or do things generally go after the call to InitializeComponent?

We’re thinking about how to solve some issues that we’ve uncovered in the beta and this feedback might help in deciding how to deal with them. Thanks!

Dynamic languages/dynamic environments

4 Replies

The .NET Languages blog recently pointed me to an SD Times article by Larry O’Brien entitled “Dynamic Do-Over.” Most of the later part of the article talked about IronPython and Jim Hugunin, but the earlier part touched on something that I’ve discussed earlier: the question of language strictness when it comes to typing. The more I think about it, the more I believe that static typing is a good thing and something that should be encouraged wherever possible. But when I say that, I don’t mean to say that there isn’t something of value in all those scripty-like dynamic languages out there. I think Larry hits the nail on the head in his article: what makes dynamic languages so great is not their loose type systems, but their dynamic environments.

In the end, I think anything that helps the average programmer be more productive is a good thing. By and large, static typing satisfies this dictum: static typing enables all kinds of programmer productivity features like Intellisense, better error messages at compile time, etc. (One could argue, I suppose, that you could lose the static typing and use type inferencing instead, but I wonder whether it would be possible to build a complete enough type inferencing ruleset that: a) was implementable, b) made some kind of sense, and c) could compete with just stating the damn type of your variables.) Dynamic environments also do this: edit and continue (pace Franz et al.), continuable exceptions, being able to call functions at design time, etc. So I think marrying the two worlds has some facinating possibilities.

I should add, though, that I don’t believe loose typing has no use. One application for loose typing that I’m particularly interested in is modeling unstructured or semi-structured data such as XML. I think the work that the E4X group has been doing is particularly interesting…