The big "D"-word

WARNING: This is a speculative post. Caveat emptor.

I know that I’m running a great risk of touching the third rail of the VB community by even speculating about this, but it seems like the right time to have a bit of a conversation about the big “D”-word.

That is, deprecation.

Yes, deprecation. Now before anyone starts freaking out, foaming at the mouth or writing a petition, let me emphasize that my thinking along these lines is entirely within the guidelines discussed in the language specification, which mandates a long and gradual process of deprecation that involves continuing to support the deprecated feature for a reasonable period of time. The guidelines also state in part:

…feedback must be solicited from the user community on deprecation of the feature and full notice given before any final deprecation decision is made. The deprecation process may be reversed or abandoned at any point based on user community feedback.

So I’m really just floating some personal trial balloons here. After all, it’s now been almost three major releases since the big move to .NET, and I think it’s started to become clear that some of the features we carried forward are a bit, uh, underused. In the interest of paring down the language specification just a bit in it’s inevitable march towards more and more pages, I’ve been pondering the question: “If I was going to deprecate parts of the language that don’t seem to be used, what would I deprecate?” I’ve come up with a few candidates that seem pretty safe:

  • Type characters. Yes, we still allow you to say “Dim a$”. So far as I have ever seen, no one uses them anymore. It would be nice to reclaim a bunch of characters at some point in the future, and it would be relatively easy to include error corrections to fix this up.
  • Copying of boxed value types. I’m not even sure I could explain this in a bullet point. If you read section 8.6 of the language spec, Value Type Conversions, it’ll discuss this a little more detail. I think this is counterintuitive behavior for most people and is incomplete in any case. The only real question here is: are there programs that depend on this behavior? We’d need to think/talk a lot more about it before we could even consider this one.
  • Mid$() assignment. Bet you didn’t know you could even do this, did you? See section 10.6.3 in the language spec for more on this.
  • End statement. I’m curious if this one is still used by people, especially now that most frameworks like WinForms and WPF have Application objects that have a proper Exit/End method. If this one is popular, it might not fly as deprecatable.
  • Erase statement. I’ve found that ReDim is actually still fairly useful as a shorthand way to redimension an array. However, Erase is completely useless–you could just replace it with an assignment to Nothing and you’d get the same thing.
  • REM comments. Bet you didn’t know you could even do this one either, did you? There’s something nostalgic about it (Erik Meijer loves them), but, really, who uses them anymore?

You’ll note that I’m only including things here that I think are truly not used much or not useful. There are things I think some people would like to see disappear (like, say, On Error), but are still being used heavily enough to make them be not reasonable candidates.

I’m curious what’s people’s feelings about this are. Does this just bring up bad memories? Are there other candidates you’d throw on the list? As I said, at this point, I’m just talking. Depending on the reaction, the next step would be to look a little more formally at it in the team…

20 thoughts on “The big "D"-word

  1. Christopher

    I didn’t know about the Erase Keyword … so I shouldn’t miss it ; )

    The all pack can be deprecated (IMO), however I still use ‘END’ while debugging the same sequence several times (for instance to not have to close a modal form and then the main form each time).

    Type caracters could be ‘corrected’ by the ide.

  2. LarryBlake

    I like the idea of deprecation. If I’m using a technique that will have people giggling behind my back, I’d like to know. And I certainly want to know if it might not be there in the next release.

    The whole point of deprecation is not to take something away, but to point out that the language has moved on. I like this much better than removing a feature without warning.

    RANT: The change from "classic" VB and (especially) ASP to .NET was a giant replacement of proven techniques, rather than a gradual deprecation. That annoyed a lot of people. Don’t do it again.


  3. Elijah

    I’m very pleased you’re taking a look at deprecating outmoded parts of the language. My first version of VB was .Net (VB 7 to be exact) so many of the legacy features I didn’t learn and therefore don’t use. My friends are in the same boat.

    Your gradual phase out approach is wise.

    Keep up the excellent work. I’m very excited to see what I will be able to do with VB 10 and the DLR! I have dreams of VB being hosted in SQL management studio allowing me to query with LINQ!

  4. BillS

    I also like the idea of cleaning up some of the older seldom used features of the language. I vote yes to all of these.

    I would actually like to see a couple things like On Error deprecated but with a longer lead time for removal. The idea would be to discourage people from using them – but not force them to replace the On Error syntax for a couple releases (as opposed to other items being deprecated and removed.)

  5. Bill

    Note to other commenters – you need to removed the special characters for the quotes from the title of the post to post your feedback…

  6. Another annoying grammer natzee.

    Although I *am* buying into everything you outlined in this post, you probably meant "lector" and not "emptor" in your opening warning.

    Thanks for the ongoing excellent blog content!

  7. Roman

    No, not REM, please! I think it’s nice to have two styles of comments – for example, ‘ can be used for passing remarks, and REM for more thorough explanations. Besides, it looks so oldskool 8=].

    The Mid statement appears useful, too, although it’s a pity that it’s 1-based, though.

  8. Rob

    Tell you what? I’ll give you rem and type characters, if you give me multi-line comments and figure out a way to get line continuation characters out of linq.

  9. Billy Hollis

    Do you mean eliminating both Mid$ assignment and Mid assignment? Being an old timer, I actually use Mid assignment, and the nearest equivlalent using String methods is not particularly elegant. But I dropped the dollar sign years ago, from Mid, Left, Right, etc.

    The other stuff is mostly inconsequential, except End. I’ve been guilty of using End only a few times in demo programs; I wouldn’t sweat the loss. But if I’m using it at all, I’ll bet there are others that come from early Basic versions that use it a lot more.

  10. Jesper

    I abosolutely love what you are doing with VB.

    Type inference is fatastic – and I can’t wait to get REPL back.

    I am fine with all the Ds you suggest – except REM.

    Please don’t remove REM.

    I have been using MS BASIC languages since the mid 1980’s (on TI-99/4A, Commodore 64, Amiga 500 etc.).

    And it just won’t be BASIC no more without REM (and GOTO).

    Don’t forget that is was those early BASIC versions that made Microsoft.

    So please leave just this one tiny thing to remind us where this great programming language comes from.

    Besides – REM just looks better!


  11. Jem

    I’m ok with most of your suggestions, but I would think twice about the "End" statement.

    I actually use it fairly often in the application initializing sequence.

    Say you have a Windows Forms application that has to check for dependencies or settings at startup (valid licence or SQL instance existence comes to mind) and exit on failure.

    If you’re doing it in your main form load event, then you’d call Application.Exit, but wait, the rest of the sub still executes, so I guess an Exit Sub is required. Will it prevent the form from appearing, even briefly ? Seems like not, but Me.Close() is out of question since we are in the middle of the Load event.

    I’m not even raising the issue of error catching or finally statements that might pop up while all you want is closing this damn app.

    So, better just "End" it already.

  12. Steve

    I agree – don’t remove REM!

    I did know about the MID-assignment, and I’m sure I’ve used it before. What makes you think it’s not used anymore?

    It seems a useful statement (even if Mid is a function and not a keyword!), why would you want to remove it? Because it would help the language to have Mid only used as a function?


  13. Kranser

    So the reason for removing the MID-assignment statement is not related to MID-assignment not being useful, or that MID-assignment can be easily done via other methods, but rather just because MID is not a Keyword?!

  14. Jimmy Kreier

    I have to agree with Jem. I use End often during the startup progress of an application. It’s IMO quicker than going through the whole My.Application framework.

    On the other hand a nice solution for dealing with string-constants stretching over multiple lines would be brilliant. Using the low line character ( _ ) over lines and lines for hardcoded string-constants is sometimes a real pain. (And yes i’m aware of using Resources).

    But i think it probably won’t add up to readability of source code itself… Maybe you guys know a better solution.

    Cheers for the nice blog anyways!


  15. Donny

    Please, do net removy type chracters. I personally use only %, $ as use of Short, LOng Double, Single is not very common for me. And you have recently added ? pseudo-type character. Type characters can make code shorter for common types.

    My candidate of teprecation is Call. It looks so old-school, somethink like REM.

    On the other hand I don’t see any reason for removing of anything from VB (with exception of _). As long as it does not blocks somethong kew to come the feaure should be kept.

    You can make IDE not to add (value as …) for setter of property (it is optional).


Leave a Reply

Your email address will not be published. Required fields are marked *