I’ve been thinking about something Wes said last week about C# 3.0 and VB 9.0. After viewing my PDC presentation slides, he noted:
The difference in focus between the C# and VB team is becoming much more evident: The VB team is opting for greater relevance and convenience in the short term, while the C# team is trying to avoid creating long-term baggage.
I think this succinctly describes what’s going on in regards to VB’s embrace of XML integration into the language and C#’s cautiousness around it. If you talk to the C# team about this, you get some very explicit concerns about the long-term impact that integrating XML into the language might have. I would characterize these concerns in my own words as:
- It is extremely risky to put some portion of your language design in the hands of another language design team. In other words, if VB integrates XML as it stands today into our language, what happens in the future as the XML standard continues to evolve? What we do today may be sufficient and there may not be any demand for adding any further features the XML standard may add. But maybe not. And those features will not necessarily have been designed with an eye towards whether they’ll work well in VB. Heaven knows we’re going to have enough issues shoehorning XML into the language, what happens if we hit some really sticky issue in the future? What if XML heads in a direction we’re not willing or able to go in?
- It is extremely risky to tie yourself explicitly to a technology that may or may not be here 15 years from now. Right now, XML is king. But what happens if some other technology comes along and knocks it off its perch? What if things radically shift in some other direction and XML suddenly becomes a side track instead of the main line?
In truth, both of these concerns are valid. In fact, VB’s own history has borne them out — all one has to do is replace “XML” with “COM” and you have the whole VB6 to VB.NET question in a nutshell. I mean, it doesn’t seem likely today that XML will ever lose its primacy, but if you could take a time machine and go back to the pre-.NET days and ask Don Box if COM was going to be supplanted in a few years time, what do you think he would have said?
So, if integrating XML is so gosh-darn risky, then why are we doing it? Are we nuts? My answer is: not exactly.
Like so many things in life, it’s all about tradeoffs. The C# team looks at the problem and says, “It’s more important to us that we design a language that is as minimal as possible and whose pieces are guaranteed (as much as anything ever is) to retain relevance for the forseeable future. Therefore, we’re willing to sacrifice some usability and some programmer speed to ensure this goal is reached.” Perfectly valid. The VB team, on the other hand, looks at the problem and says, “It’s more important to use that we design a language that allows people to solve the problems that are confronting them today in as simple and straightforward manner as possible. Therefore, we’re willing to take the chance that some feature that is fantastically useful right now may lose relevance in the future and perhaps even become almost entirely useless (c.f. Gosub, On … Goto, Open/Close, etc.).” Also perfectly valid.
What it boils down to is that we’re willing to make the bet that the overall benefit of integrating XML now is going to, in the long run, outweigh any possible downside. Are there people who are going to say we’re crazy? Of course. How can we tell who’s right? Check back in 15 years. In the meantime, I leave you with the conclusion to Wes’s quote above:
The end result is that Visual Basic is definitely going to be much more fun to program.
See you in 2020…
Whilst i dont disagree with everything you said, i fail to see the XML integration solving much. I may be missing something but ive never had the need for it, sure ive used the XMLTextWriter/XMLDocument to create XML, but thats already so easy i dont see the benefit of integrating it directly into the laguage is, wouldnt it be easier to just have an addin that parses XML and then generates the code neccesary to create the XML document, kinda how there were utilities that converted a block of html in an ASP file into response.writes
I watched the little demo of amanda and yours on channel9 and it got a "huh, neat" out of me, but i dont see any practical use for it. There are a few other things id rather see before xml integration (as i understand it to be).
I teach information systems at the college level and one of the main themes I push is “tradeoffs”. Good decision making involves making intelligent tradeoffs. There is rarely a “right” decision, just one where the tradeoffs make sense. And intelligent decision makers can arrive at different conclusions based one their assessment of the tradeoffs. So Paul has done a very good job of outlining the issues.
From the perspective of someone who has been in this industry since the 1960s, the only constant is change. The real question is the amount of time between changes. For me, I would prefer getting benefits from a language today and risk having to make changes in the future where my definition of the future is around 5-7 years. I guess that’s why my tradeoff system puts me in the VB philosophy camp.
Some people want a result fast, some want a perfect piece of programming. Some want both.
Currently we find the need to clear out our thought patterns and load up a new mindset. (This is neither productive nor conducive to clarity of thought!)
(Programming DOM is fairly easy, going into XSLT and using correlated subqueries takes a re-orientation of the brain, getting your XML out of the programming language is especially annoying…)
Tools that eliminate gratuitous work and thinking and cut to the chase are good for the future of man. It will help make programming a general part of literacy and break down that "programmers are special" idea.
This stuff is only the beginning. There is a lot more to do to get programming up to the speed and succinctness of high quality thought. It’s taken a while for the CLR to begin breaking the barriers, but it’s started. This is great, well done.
There was DAO, ADO and several other approaches. Maybe this road will have analagous iterations.
Paul Vick confirms Wes Moise’s conclusion from the XLinq perspective in his "Integrating XML: Playing with Fire?" item.
VB is the best because it always updates itself.
I think it makes sense to see some real differences between C# and VB.NET. It’s a wise choice to take a chance with VB rather than C# (which I think is going to stick for a longer time than VB).
imho, the overal advantage of increased xml integration is the move toward a more declarative model for programming in general. sure, the current mix is not quite right and offers new challenges. but as more work is done in the declarative sphere, both C# and VB will be offering programmers a head start on switching from the imperitve style to the declarative style of coding.
The argument that in "15 years from now" XML may no longer be king is flawed since by then there will be have been several more releases of VB.Net. They could deprecate XML support in one of the future releases should they choose to.
It’s a good thing c# and vb covering different philosophies. It makes the languages differentiate and that is a good thing. Because why would you want 2 languages when the one is just a one to one mapping of the other? Now we have c# for longevity and vb for quick and easy and when you can take the risk that some feature is not supported anymore in some years. Great!
Instead of XML literals, I think it would be much safer if you were just doing a string literal with data binding syntax. It would look pretty much exactly the same in code, but you would be treating the XML as a string. If you wanted to treat it as XML, you could always do something like:
Dim x as new XElement(
<stuff> <%= myVar > </stuff>
This would also make the syntax much more powerful, as you could create CSV files, html, or any text format.
(BTW, Rocky was the one who really came up with this idea, but I think it would be a fantastic improvement)
Pingback: Doron's .NET Space
The trade off section of the article is so well put in regards to c# & vb. I makes great points on the trade-offs in the two languages, trade off’s that I’ve thought about in the past when choosing one or the other.