In the comments to my previous entry on partial types, mustTryHarder comments:
If C# always uses the partial keyword (and presumably went through the same level of debate) then why did the VB team approach it differently? I assume you guys talk to each other. I can’t see how Microsoft can justify a difference. While virtually everyone agrees that separation of designer code is desirable, it would appear that only the VB team feel the Partial keyword is optional. IMHO the VB team would do well to listen to feedback on syntax in order to avoid the same back-tracking in future that happened with areas such as properties which are now once again able to specify different accessibility levels for Get/Set. So far your private debates have got it wrong!
mustTryHarder’s comments are contradictory, although there was no way for him to know that ahead of time. You see, the reason why VB didn’t support properties with different levels of accessibility in VB 2002 and VB 2003 is because the C# team didn’t want to support them. Our original plan was to include them just the way they were in VB6 but the C# design team was very definite that they thought they were a bad idea and that they weren’t going to include them in their language. As a result, when the C# compiler came across a property with different levels of accessibility, they would consider the property’s accessibility to be the more restrictive of the two. So if we’d gone ahead and implemented the feature anyway, a property with a Public Get and a Private Set would have been considered Private by C#, which would have looked a lot like a bug to most people. So we made the decision to not implement the feature in the interest of playing well on the .NET platform. Fortunately, everyone’s come around in VS 2005, so the feature is going to appear in both languages and there aren’t going to be any difficulties.
So, ironically, in this case we’re getting simulateously criticized for not doing the same thing as C# is doing and for doing the same thing as C# did. Welcome to the world of multi-language programming on the .NET platform, folks. We’re not in Kansas anymore.
The truth is, we have a lot of regular contact with the C# team about design decisions and feature choices and, where it makes sense, we try and be harmonious. However, each language’s design team has distinct visions for their language and that is inevitably going to cause divergence. For example, I know that more than a few people on the C# team (and more than a few C# users) think that our generics syntax is stupid. I can see where they might be coming from in having that opinion, but I disagree with it… and that’s the way it goes. Should VB users not get Edit and Continue because the C# team doesn’t think that it’s important enough to ship in VS 2005? Should C# users not get iterators because VB doesn’t think that it’s important enough to ship in VS 2005? Who gets to decide which vision is the “right“ one? Who’s even to say that there is a single “right“ vision for the millions and millions of developers out there in the world?
I should be clear that what I’m not saying is that people shouldn’t feel free to complain loudly about things that they don’t like about VB. That feedback is invaluable and helps guide the future direction of the language. What I am saying, though, is that one argument that is never going to work with us is “But C# does it differently and you both should do everything the same way!” If there are concrete reasons why you think the C# design is better, then let’s hear them and we can have a good discussion about the merits and demerits of the VB approach. Otherwise…
"Who gets to decide which vision is the “right” one?"
Maybe the point mustTryHarder was making is that there ought to be such a person or group.
When things don’t come down to core language decision, consistency seems to make a lot more sense over "judgment calls". That isn’t to say vb.net should always bend to C# though.
VB has a lot of features that C# doesn’t have. for example, optional parameters, propertys with parameters, late binding, MyClass, With, When, Module and many many more. But there is few C# developers urge to look for these features. C# only has a few feature that VB doesn’t have such as volatile, event propertys, XML comments, operator overloading. However, It seems that VB developers are eager for those features. It was a problem, isn’t it?
it’s funny, but Vb has event properties…
Indeed, it’s undocumented features. Why?
Back when the NGWS bits were released at the PDC 2000, I was then a Senior Consultant with MCS in Redmond. I was so incensed that one couldn’t declare different accessibility levels for properties in VB.NET as could be done in VB5 & VB6. At that time, Paul explained that this was done because C# wouldn’t support it. I recall really taking him and the VB.NET team to task over this.
You see, I believe that the VB.NET team is the ONLY team at Microsoft that has the right to determine what gets put in VB.NET. Why? Because this is the core team that spends its time working and dreaming about keeping VB users happy; this is the team that cares more about keeping with the spirit of Visual Basic, which is “readability” and “expressiveness”.
As Paul pointed out, any VB.NET user or fan should offer opinions, with reasons, why a feature implementation or syntax sucks or is fantastic. But those reasons should never be based on how or why C# does it because the C# team has a totally different mindset about language syntax design. And, so far, the VB.NET team gets it in my books!
Lan: event properties were a late-breaking feature. They’ll be documented by the time we release!
Taiwo: Thanks! We do think in terms of "VB," but we do have to be mindful of the fact that people work in both languages and think about how the two interact…
Here’s a thought…
Is it possible to specify an interop level for each framework version that all teams would agree on, and then allow each team to diverge but allow compiler options to disable all options that do not allow pure interop? And futher any DLLs compiled without pure interop would emit metadata so that when other tools load them the incompatible methods and properties are mapped and specified as incompatible?
This would be the best of all worlds, I think?
Paul:> Lan: event properties were a late-breaking feature. They’ll be documented by the time we release!
Event properties? What exactly are those? what’s the syntax for them?
Glad to hear the VB team talks to the C# team – thought you did. Sorry to hear you caved in to the C# way of doing things regarding properties. Still all is forgiven now, even in Kansas.
My point was regarding consistency of the partial keyword, not language harmony. I’m all for language innovation and some of the new features in 2005 are certainly cool (although the emphasis on their importance is over stated). I imagine you’ll implement some pascal syntax in Orcas.
Please innovate as much as you like but try not to break our existing code too much. Forward compatibility is a massive incentive to upgrade. Microsoft built its empire on backward compatibility until .NET and we are still finding it difficult to justify the move.
Eric: you need to add magic word "Event" to name of event.
you have event "blabla", for getting properties of "blabla" you must used object with name "blablaEvent"
Mike: The Common Language Subset (CLS) is exactly what you describe. It defines the things that languages must do to be understandable by other languages, but allows languages to diverge from the subset if they so wish. The difficult part is that when cross-language problems happen because of non-CLS features, people tend to get cranky. A good example is the fact that in VS 2002/2003, C# allows you to define attributes that take Object or 1D array parameters, both of which are not CLS-compliant. When VB barfs on those attributes, we get bug reports and the response "but it’s not CLS compliant" is, understandably, not what they really want to hear. (It didn’t help that C#’s CLS compliance checking didn’t catch this problem.) So it’s a balancing act, although the CLS is still a valuable thing to have.
mustTryHarder: Breaking source compatibility between VB6 and VB 2003 was a difficult decision for us to make and one that we would much rather not have had to make. It’s one that we’re working hard to ensure doesn’t happen again.
What I particularly like about VB.NET is its support for modules. People who created Java, C# and UML completely neglected that the "old fashioned" world of modules and data flow diagrams still exists and has a right to exist. There are systems for which the OO approach is completely inadequate. These are networks of procedures, which transform input data into output data. Inputs are distinct from outputs. Variables are set only once and keep their value. Just refer to Yourdon, Constantine, Myers and DeMarco for the business applications and to "functional programming" in the strict academic sense. The full fledged functional programming has never made it into the business world, just because it is too academic. Perhaps it is coming slowly, look at Haskell.
A sound mixture of procedural, modular, functional and object oriented is the OCaml language. In this language, you can mix the procedural style (loops etc.) purely functional style and OOP as you desire. The object orientation does not get into you way if you do not need it.
OOP has been created for objects which change their state and interact with each other, to handle the complexity. It is a great idea, but it does not work for every thing.
For a functional programming language out of the Microsoft labs look at F# for dotNET. It is based on OCaml.