A little update on VB10 thinking...

<< Did Twitter kill my blog? | Home | Design meeting Channel9 interview... >>

A little update on VB10 thinking...

Friday, July 18, 2008 4:12 PM

WARNING: This is a speculative post. Caveat emptor.

It's been a while since I've had much of anything to say about our thinking about VB10 (well, it's been a while since I've had much of anything to say) and I wanted to give a quick update on our thinking:

Implicit line continuations: we're still considering it.
Automatically implemented properties: we're still considering it.
Implicitly implemented interfaces: we've put this on the back burner. The feedback we got on my post was helpful in identifying problems with the idea and it seems like we have bigger fish to fry.
Collection initializers (and update): we're still considering it.

We also keep getting asked about:

Iterators. This is definitely on our radar but it's a big item. We're considering it, but it hasn't been thought about nearly as much as some of the other things above...

Another thing that is on our radar:

Generic variance. I'm not even going to bother to post our thinking about this, since you can always go over to Eric Lipper's blog and read his extensive discourse on generic variance.

And, of course, other stuff that will be talked about in good time...

Feedback

# re: A little update on VB10 thinking...

I would like to see a lot of time spent on back-filling missing features.

1. Select Case against object
2. Select Case against types
3. Nullable Optional Parameters (really useful for writing functions that map to stored procedures)
4. Real multi-line strings. (Using XML literals doesn't work when you need exact spacing or use a lot of angle brackets.)
5. Support for anonymous subs so we can use Action(of T) methods.
6. Multi-line anonymous functions so we can use Parallel.For
7. The ability to use late binding on a specific variable or region without turning it on for an entire file.

I'm not looking for new features with this release, but rather polishing what we already have. 7/18/2008 4:36 PM | Jonathan Allen

# re: A little update on VB10 thinking...

What about lower-case keywords?

http://www.panopticoncentral.net/archive/2007/07/20/21212.aspx

I really liked the way it looked, and it doesn't seem like it takes much effort, given how fast you came up with a compiler to do it. It also seems like something that would improve readability for those who want it without inconveniencing those who don't. (Perhaps it could be a display-only thing?)

Also, any possibility of making lambda expressions better in VB? It seems like they're awfully inflexible compared with C# lambda expressions, which don't require a return value. In C# I use them all over the place, but in VB I don't find them much use due to their constraints there.

I'm glad to hear that line continuations and auto-properties are still on the table. I will say, though, that the way property and private variable are automatically clumped together in VS 2008 is very elegant, and makes this less urgent (but still *very* nice to have). 7/18/2008 5:38 PM | Kyralessa

# re: A little update on VB10 thinking...

Two that are high on my wish-list:

1. Lambdas with statements

2. Generics classes that can limit by specific value types, such as Integer. (Not just Structure.)

Since Kyralessa brought up about the lower-case keywords, I just wanted to mention that the sample would look a lot different without the colorized keywords.

Try this: highlight and copy both code blocks and paste into Notepad. It's amazing how the perception changes once again.

VB's use of Proper Case is what makes it readable in B&W. C/C# can get away with lower-case because of the use of curly braces and a terse syntax.

I hope the Proper Case stays put. 7/18/2008 11:53 PM | Speednet

# re: A little update on VB10 thinking...

The support for anonymous methods should really be the top priority.
We're stuck two versions behind C# on this one !

Either that or the support for parameterized delegates, which is not likely to happen.

This totally defeats the purpose of List(of T).ForEach/FindAll/RemoveAll/Sort, etc...

(mind you, I still haven't made the switch to VB9 so I don't know to what extent lambdas can make up for this lack) 7/19/2008 4:21 AM | Jem

# re: A little update on VB10 thinking...

The Absolutely Top Priority for me is (agreeing with previous commenters) lambdas with no return value (anonymous subs).

Then multi-line lambdas. Not having these two sorely limits our ability to use the LINQ goodness and other idioms that they have in C#.

Then I'd really like multi-line strings.
7/19/2008 9:46 AM | Joshua Frank

# re: A little update on VB10 thinking...

I'd really like to see "yield return" in VB.NET, I need it quite often.
The line continuations are great and so the automatic properties, I hope they both will be VB10. 7/20/2008 2:36 AM | Tomas Herceg

# re: A little update on VB10 thinking...

here's a big +1 for anonymous methods !

All the rest is fluff compared to that, as far as I'm concerned.
After all, THE next big thing coming (aside from the DLR/VBX stuff which I'm dying to see) is multicore computing (4 is already becoming commonplace).
Surely MS isn't going to keep VB handicapped when it comes to spawning background threads in a convenient way. 7/20/2008 2:44 PM | Sven Devriese

# re: A little update on VB10 thinking...

I confess my ignorance, but can someone explain to me as to exactly how multiline lambdas somehow make multicore computing more accessible?
I've heard this before, mainly from beginner-level C# people. They usually say that their language is more suited for multiple cores than ours. 7/21/2008 2:45 AM | Raj Chaudhuri

# re: A little update on VB10 thinking...

Perhaps the VB and C# teams could use the same case when implementing new method names, keywords, and other syntax?

For those of us who switch back and forth between languages, it would be easier to deal with C#'s (stupid) case-sensitivity if VB defaulted to the same case.
7/21/2008 10:06 AM | Ken Cox [MVP]

# re: A little update on VB10 thinking...

Great news! I really hope to see all of those "still considering" be transformed into "committed to delivering" in the near future!

Once implicit line continuations, multi-line strings and auto-implemented properties are added, there will be only two thing left that REALLY keep bugging me after 8 years of otherwise loving use of the VB language and toolset:

1. The lack of inline control characters in strings!

I would LOVE it if VB could adopt the backslash escape character model for strings. Seriously, having to end a string, concatenate with a 6 letter beast of a constant and concatenate with a new string just to get a new line or a tab into a string is a constant annoyance to me.

"Hello\nWorld!" - 2 characters for the new line.

"Hello" & vbCrLf & "World!" - 14 characters (of which you have to type 10) for the new line! It hurts... please, make it stop!

2. Statement lambdas

Like someone else commented, lamba expressions have very limited use in VB compared to C# because of their VB-specific limitations, the most significant one being that all lambdas are required to return a value.

By the way, I agree that Proper Case should stay in VB!
7/21/2008 2:32 PM | Daniel Stolt

# re: A little update on VB10 thinking...

I definitely agree with Daniel on inline control chars, we would need to have a prefix as not to break existing applications that have a \ in their strings, kind of like the opposite of c# (they have @"This will NOT produce a new line \n" for a literal string), where we would need something like $"This WILL produce a new line \n "or even #" " to mean C# style string. 7/22/2008 12:32 AM | Tim

# re: A little update on VB10 thinking...

Hmm, I like that $ Tim, good reuse of the VB string character - I agree the escape sequence stuff is really limited in VB. Wouldn't take much to put it in, I figure as the CLR supports this natively (in reality VB escapes all the \'s in string literals before embedding them in the assembly).

Combine the escapes with the implicit line continuation characters and
"We\n" &
"Have\n" &
"Multi-Line\tStrings", not that this is much to look at. 7/22/2008 1:03 AM | Anthony D. Green

# please add for productivity

a) Refactor, push variable to innermost scope where it is used

b) Identify common constant expressions (i.e., accessing a read only property) and add Refactor -> Promote duplicate expression to local variable. (For some reason, our ex-vb6 developers like to repeatedly call the same this.propertyx.propertyY.propertyZ.propertyQ over and over again in the same function)

c) Identify functions/subroutines that can be made static at compile time (i.e,. that use no class member variables). This would be a big plus to us given that we try to write side effect free code and the 'static' keyword forces the function (thanks to the compiler) to not use anything that is not passed into it.

d) Identify duplicate code. Simian does this by matching token strings based on token types instead of literal values.

e) Code execution profiler/instrumentation built into the IDE as a standard feature, just like it was with Visual Studo 6.0 (we cannot get a PO approved for TFS).
7/22/2008 1:18 PM | ted

# re: A little update on VB10 thinking...

While the things you've listed would be nice to have, as would the option to change the keyword casing, they all seem to me like window dressing. And I can't even see why collection initialisation would be used that much.

The important stuff is bringing the language up to date with the missing features that C# got, beefing up the anonymous methods as everyone has pointed out is the most important. VB really should be more suited to using LINQ but with the current rather impotent implementation of anonymous methods we're well behind C#.

Iterators are a very powerful feature too, especially when designing frameworks and libraries.

I'd also be really happy with the suggestion of Select Case against Objects and Types, the number of times I want to use that is massive, it would be so much more elegant than using a big ugly IF.

I'd also like to see sting escaping and implicit line continuation your other suggestions. 7/24/2008 8:00 AM | davidG

# re: A little update on VB10 thinking...

Please add support for partial interfaces. 7/24/2008 9:06 AM | J.P. Hamilton

# re: A little update on VB10 thinking...

Just my 2 cents about generic variance: This is a big topic, and a difficult one. However, almost all of the problems that require generic variance could be eliminated quite easily.

In my experience, most situations where you need generic variance can be blamed on bad interfaces, especially the constructors and 'AddRange' methods of the .NET containers. These have the serious problem that a Container(Of T)'s 'AddRange' method requires an argument of type 'IEnumerable(Of T)'. This is, to say the least, bothersome. Just changing this to 'IEnumerable(Of U)' (with 'U' being constrained by 'U As T') would eliminate a host of problems.

I'm not sure if the interface of these existing classes *can* be changed but IMHO this is the way to go. Forget about generic variance, it's not worth the pain.

About iterators (I assume this is what you call the 'yield return' thing), why is this such a problem? I assume that C#'s compiler simply restructures the AST and basically fills a templated code with the necessary parameters. Can't you do the same (or even better, recycle their code)?

Anyway, iterators are very useful as generator functions, especially in combination with Linq and lazy evaluation. 7/24/2008 11:36 AM | Konrad

# Improve usability

Generally, VS, VB.NET and C# need more focus on total developer productivity. The focus of the last few years has been on helping during the inital development of a new project. Post production implementation tools (better refactoring tools, significantly better static analysis of code, etc.) are needed because most of the cost for a production system is after it is put into production.

Preventing bad code from making it to production as well as preventing high cost to maintain code from being production are our two aims. Rectifying those two problem code issues is our second aim.

7/24/2008 5:14 PM | Ted

# re: A little update on VB10 thinking...

Konrad: regarding your suggestion to change the parameter type of the AddRange() method to IEnumerable(Of U) - correct me if I'm wrong, but wouldn't that require making the AddRange() method into a generic method?

Having to supply a type parameter in every call to AddRange() would be rather cumbersome in my opinion. 7/24/2008 6:44 PM | Daniel Stolt

# re: A little update on VB10 thinking...

Daniel,

Generic Methods support inference of type parameters - I'm pretty sure you wouldn't need to specify the type in that scenario 7/24/2008 7:25 PM | Anthony D. Green

# More Metaprgramming

Ted raises some important points. I would like to add to his list that VB should have built in unit tests possibilities. (Sorry to say this, but Cobra has got many things right that I would like to change in VB. See http://cobra-language.com/ )

Further, I would like to see more meta information and better dynamic possibilities in VB:

1. I often end up with code like this in forms:

If devIndex = cAddDeviceIx Then ' new device
_Scale = New SartoriusClass ' Particular code
….
Else ' Exists so use the already existing object
_Scale = CType(Devices(devIndex).Clone, SartoriusClass) ' Particular code, must clone and cast it.
…..
End If

It would be nice if VB had better dynamic capabilities so this general code would be correct:

Dim devType as string = “SartoriusClass”
.....

If devIndex = cAddDeviceIx Then ' new device
_Scale = New devType.AsClass ' now general code
….
Else ' Exists so use the already existing object
_Scale = CType(Devices(devIndex).Clone, devType.AsClass) ' now general code to clone

Or is it just I who don’t know how to do this in .NET with the possibilities available today?

2. A new selection statement, exemplified like
Dim aStr as string = _
if a>5 then
IfReturn “>5”
elseif c=d then
DoALotOfThingsHere
IfReturn “Do it”
elseif d <dfdf
DoSomethingElseHere
IfReturn nothing
else
IfReturn “Yes box”
Endif

Compare this with how this could be implemented using a function with an if statement and global variables.

Function IfFunc as string
If a>5 then
Return “>5”
elseif c=d then
DoALotOfThingsHere
Return “Do it”
elseif d <dfdf
DoSomethingElseHere
Return nothing
Endif
Return “Yes box”
End function

Or can this be elegantly implemented with the new possibilities in VB2008, that I don't realize

Yes I know about the "terniary" if statement in VB2008, but this is more powerful construction.

Yes, I know that this if suggestion can generate really horrible code, if nested.

Anyhow, I do hope VB will evolve!
7/25/2008 3:11 AM | Csaba

# re: A little update on VB10 thinking...

VB.NET anonymous functions are so clunky... I humbly join most of the commenters here and ask for multiline lambdas with a terser syntax than the current one for inline functions.
Please don't let VB slide back into Mort's domain: quickly slapping together CRUD screens using wizards. VB needs all these advanced code features C# has if you want it to be respected. 7/25/2008 11:57 AM | onodera

# re: A little update on VB10 thinking...

I'll pile on: Anonymous methods.

In response to Raj Chaudhuri above, the reason that anonymous methods make it a lot easier to do asynchronous programming is that they allow you to provide a callback method that uses variables in the scope of the code kicking off the async operation. Without that capability, it becomes necessary to create new classes just to hold instance variables (that's what the C# compiler does behind the scenes with anonymous methods). In VB.NET, asynchronous code is harder to write and harder to read than it would be in C#. The only thing that's actually easier to do with async VB code is decompile it.

So it is with iterators (aka the yield keyword). This is a feature that didn't seem all that useful until asynchronous frameworks like the CCR and Jeffrey Richter's AsyncEnumerator came out. Iterators allow you to write code that seems sequential, but under the covers it's really stopping and resuming with a callback. To get similar syntax and functionality in asynchronous programming without iterators, you end up blocking threads, which won't scale well.

7/27/2008 11:24 AM | Matt

# re: A little update on VB10 thinking...

Matt

Thank you very much. That was an excellent description. 7/28/2008 2:28 AM | Raj Chaudhuri

# Lambda expression improvements

7/29/2008 5:59 PM | Panopticon Central

# re: A little update on VB10 thinking...

I've just come across something while reading Eric Lippert's posts:

C# doesn't allow iterator functions to be implemented recursively. For example, consider the following hypothetical implementation of the 'GetEnumerator' function for a (Head, Tail)-'Stack' class that implements 'IEnumerable<T>':

class Stack<T> {
// … details omitted
public Stack<T>Pop() { return m_Tail; }
public T Peek() { return m_Head; }
public virtual IEnumerator<T> GetEnumerator() {
yield return Peek();
return Pop().GetEnumerator();
}
}

Unfortunately, this code does not work. It would be very cool indeed if this code worked in VB. Off the top of my head I see no reason why this shouldn't work (of course, there's a specialization for the above class that handles the empty case, emitting a 'yield break;' as the recursion anchor). 7/31/2008 7:47 AM | Konrad

# re: A little update on VB10 thinking...

Since you are thinking out loud about what to include in VB10, are you at least considering putting the equivalent of C#'s verbatim strings into it? I don't know why this has been overlooked when it shouldn't be too difficult to implement and makes working with strings much easier. 7/31/2008 8:02 AM | Randy Giedrycz

# re: A little update on VB10 thinking...

Okay, perhaps my last idea wasn't that good: you don't want to write code like that, it's very inefficient (lots of instantiated iterators).

@Randy: Well, I believe the main idea of verbatim strings was to work around escape sequences (in paths) which VB doesn't have in the first place. VB strings *are* a weak form of verbatim strings, so to speak.

Large strings don't belong in the source code anyway but in a separate resource file. 8/1/2008 4:31 AM | Konrad

# Lamda and Asynchronous Methods

Can you make winforms GUI calls to update a basic control (add item to listbox, set textbox text string, etc) queue themselves up if they are called from a thread that does not own the winform?

This is the main reason we've seen delegates.

Can this be extended to other class objects that must be called from the owning thread?

There's no real reason to not queue the requests or promote them to the *cough*, like we did in VC++6, a win32 api post message API call.
8/1/2008 10:39 PM | Ted

# re: A little update on VB10 thinking...

I agree with all the folks who mentioned add the C# escape character "\" to VB. I also agree with those that are suggesting VB and C# teams work together to add similarities where possible. But, my one big request would be, don't ask us to type 'Age +=1' when it would be so much easier to adopt the C method - either ++Age or Age++.

And, I've got to mention, I sometimes worry about the future of VB now that Bill Gates has moved on. No matter how you spell it (BASIC or Basic) the language seemed like a child of his. I keep hearing comments from our fellow programmers that state, "Hey, they only want C# developers, now!" Or, okay, so if we hire you will you be able to move up to C#? What are we 'chopped liver'? I think not. 8/9/2008 7:51 PM | Russ

# re: A little update on VB10 thinking...

Another request of mine would be to help the developers of Spec# and Pex come up with VB versions of their software.
A lot of new stuff supports only one .net language (and it's not VB), and this really worries me. 8/10/2008 6:13 AM | onodera

# re: A little update on VB10 thinking...

I aggree with the majority of posts here and would like to see
1) Anonymous methods / multiline lambdas
2) Iterators!!!
3) Inline control chars
4) Implicit line continuations / multiline strings

Since VB is a productivity language, this things would boost productivity most, in my eyes. Other requests, as for example better refactorings, are also important, but can be solved with tools like Refactor today, so you don't need to invent this wheel a second time. 8/15/2008 2:07 PM | Andreas

# re: A little update on VB10 thinking...

what about comments in multiline statements? I appologize for still being with VB 2005, but never heard that it made to VB 2008, so I am surprised to see that nobody asks for comments within long, multiline statements (and that sounds to my nonexpert eyes as a very simple task for the VB.NET team - just chop off everything that looks like coments in the early phases of the entry of the source code into the compiler)? am I wrong with that? thnx 8/17/2008 12:48 AM | pgklada

# C# と VB の言語系の次の 10 での進化を見ておく

C# ? VB ????? ?? 10 ????????? 9/15/2008 12:01 PM | えムナウ Blog

# C# と VB の言語系の次の 10 での進化を見ておく

C# ? VB ????? ?? 10 ????????? 9/15/2008 12:09 PM | えムナウ Blog

# Iterators

With the rest of the list rather underwhelming you would think iterators would be a no brainer for VB 10.

One of the main tennants of LINQ is the ability to stream through large lists of objects. The lack of iterators makes it very difficult to write proper extension methods for IEnumerable(of T) in Visual Basic.

Everything else looks like syntatic sugar wihout adding any real value. Iterators add value! 9/15/2008 8:27 PM | Matthew Doig

# re: A little update on VB10 thinking...

Partial Interfaces is high on my list. I'm trying to use t4 text templates to build our my wcf services, but am finding it very difficult because i can't have interfaces partially generated. 11/4/2008 10:26 AM | ryan

Panopticon Central