J
Justin Weinberg
My thoughts on this....
http://msdn.microsoft.com/vbasic/Future/default.aspx?pull=/library/en-us/dnvs05/html/vb9overview.asp
My thoughts:
1. Regarding Implicit types, I don't use type declaration for the benefits
of performance. It's for the benefit of clarity of purpose when reading
code. The first thing I do with neophyte developers is turn Option Strict
On to help them understand why they do what they do. With this, I can't
stop people from writing garbly gook.
2. No conflcit on XLING. I may not use it, but it doesn't hurt anything,
and there could be real beneifts to it.
3. Nullable types. I think this is a really good idea if it integrates
with SQL Server well.
4. I think I will like the Query Comprehension features, because I think it
makes understanding certain intents clearer.
5. "Because extension methods are intended mostly for library designers,
Visual Basic does not offer direct language syntax support for declaring
them." - This kind of comment has always bugged me, and probably rubs all VB
developers who are serious about the language wrong. It reveals a "red
headed stepchild" attitude toward the language, as if C# is the "real
thing". If you really talked to VB developers in the field, I would imagine
what they want more than anything is just a one to one feature set with C#.
But this aside, I don't really like the extension concept because it feels
too much like multiple inheritance and might have similar issues associated
with it in terms of maintainability of code.
6. Nested functions I can see real benefits to, but it does make VB feel
quite a bit like ML. But this could really go along way to making some
things really easy to understand.
7. Relaxed Delgates. Dislike this for the same reason I don't like
implicit type conversion.
8. Dynamic interfaces. Ditto.
9. Dynamic identifiers. More of the same.
I guess my conclusion is I like some, but overall because of the
destruction of clear typing, I have to give it a thumbs down. These sorts
of things should be done sparingly in clear code, so sparingly that
programmers should have to understand the intricacies of reflection before
they are given a license to do them. I feel VB9 legislates bad habits and
practices we gave up prior to VB.NET.
My gut tells me that this is really all about upgrading the tremendous share
of VB5 and VB6 users to .NET who so far not made the transition. I imagine
upgrading a VB6 application to VB9 will be much simpler than any other .NET
upgrade prior. But for those of us who have made the transition, I think
the lack of typing is bad policy. It may simply be time for me to byte the
bullet on curlies and semicolons
http://msdn.microsoft.com/vbasic/Future/default.aspx?pull=/library/en-us/dnvs05/html/vb9overview.asp
My thoughts:
1. Regarding Implicit types, I don't use type declaration for the benefits
of performance. It's for the benefit of clarity of purpose when reading
code. The first thing I do with neophyte developers is turn Option Strict
On to help them understand why they do what they do. With this, I can't
stop people from writing garbly gook.
2. No conflcit on XLING. I may not use it, but it doesn't hurt anything,
and there could be real beneifts to it.
3. Nullable types. I think this is a really good idea if it integrates
with SQL Server well.
4. I think I will like the Query Comprehension features, because I think it
makes understanding certain intents clearer.
5. "Because extension methods are intended mostly for library designers,
Visual Basic does not offer direct language syntax support for declaring
them." - This kind of comment has always bugged me, and probably rubs all VB
developers who are serious about the language wrong. It reveals a "red
headed stepchild" attitude toward the language, as if C# is the "real
thing". If you really talked to VB developers in the field, I would imagine
what they want more than anything is just a one to one feature set with C#.
But this aside, I don't really like the extension concept because it feels
too much like multiple inheritance and might have similar issues associated
with it in terms of maintainability of code.
6. Nested functions I can see real benefits to, but it does make VB feel
quite a bit like ML. But this could really go along way to making some
things really easy to understand.
7. Relaxed Delgates. Dislike this for the same reason I don't like
implicit type conversion.
8. Dynamic interfaces. Ditto.
9. Dynamic identifiers. More of the same.
I guess my conclusion is I like some, but overall because of the
destruction of clear typing, I have to give it a thumbs down. These sorts
of things should be done sparingly in clear code, so sparingly that
programmers should have to understand the intricacies of reflection before
they are given a license to do them. I feel VB9 legislates bad habits and
practices we gave up prior to VB.NET.
My gut tells me that this is really all about upgrading the tremendous share
of VB5 and VB6 users to .NET who so far not made the transition. I imagine
upgrading a VB6 application to VB9 will be much simpler than any other .NET
upgrade prior. But for those of us who have made the transition, I think
the lack of typing is bad policy. It may simply be time for me to byte the
bullet on curlies and semicolons