Re: Whidbey - Why is refactoring not in VB.NET?
From: Thomas Jespersen (tje_at_nospam.mentum.dk)
Date: 03/13/04
- Next message: Keith: "Re: File Associations"
- Previous message: Steven Cheng[MSFT]: "RE: where does VS look for a certificate"
- In reply to: Ed Kaim [MSFT]: "Re: Whidbey - Why is refactoring not in VB.NET?"
- Next in thread: David Lowndes: "Re: Whidbey - Why is refactoring not in VB.NET?"
- Reply: David Lowndes: "Re: Whidbey - Why is refactoring not in VB.NET?"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 13 Mar 2004 11:53:42 +0100
Hello Ed
Thanks for you comprehensive and serious answer. I'm glad that you take the
feedback serious. Also would like to apologize for the flame in the start of
my post (I thought that I removed that part ;-).
I understand what you writing, but I don't agree with the things you write.
You basic point is that one should pick the language which one is most
familiar with, when changing to .NET. That we did, and because we used to
work in VB, Access and VBA, we chose VB.NET.
Now that we have several years of work done in VB.NET, we need more and more
of the advance features. Refactoring is one very important thing. For us
VB.NET made us professional developers, using OO Programming, UML,
Refactoring, Design Patterns etc. But Microsoft decided that ex..
refactoring is not of much use for VB developers, so these feature is only
implement in C# (and maybe J# and C++ ?). So now we are in a situation where
it is very unlikely that we will change to C#, and our first choice of using
VB.NET is catching up un us. As I wrote in my first post Microsoft was very
ambitious when introducing VB.NET and said that it was a first class
language, and if you refer to the knowledgebase article I mentioned one can
read that indeed there is not much difference between C# and VB.NET.
You write that each language team has to take a hard decisions on what
features to implement. But as I see it 95+ % of all features goes into both
C# and VB.NET. And I find it very hard to believe that ex. refactoring is
very hard to implement in VB.NET opposed to C#. I mean, the C# team has
obviously done all the ground work, so implementing the same features in
VB.NET couldn't be that hard.
I know that what I'm arguing for is that VB.NET and C# is basically two of a
kind... and I think that it would be the right to make it stay that way. Or
maybe you could consider making a VB.NET <-> C# upgrading tool... this would
be much easier than the VB6 -> VB.NET tool you wrote, and you recommendation
of choosing the language one is most familiar with, would be a decision with
almost no trade offs. There are already free tool for C# -> VB:
http://www.kamalpatel.net/ConvertCSharp2VB.aspx and
http://authors.aspalliance.com/aldotnet/examples/translate.aspx
I can live with C# being able to do low level stuff like writing unmanaged
code, but I can't live with C# being able to do high-level productive
features like refactoring which is not possible in VB.NET. And also the lack
of XML comments in VB.NET 1.0 meant that it was not possible to make
third-party tools with intellisence/tool tip documentation in VB.NET 1.0.
PS: I'm glad to hear that C# gets Edit & Continue... otherwise a lot of
people would be tempted to make the same wrong decision that we did...that
is choosing VB.NET.
Thomas
"Ed Kaim [MSFT]" <edkaim@online.microsoft.com> wrote in message
news:%23e6U0AMCEHA.140@TK2MSFTNGP09.phx.gbl...
> We do appreciate the feedback, but please keep in mind that the early
> releases of Whidbey aren't even Betas yet. For example, Edit & Continue
will
> be available to C# developers, but it just didn't make the PDC build.
You'll
> see other features make the Beta that weren't in the PDC build as well.
>
> Regarding the future of each language, there will be a noticeable
divergence
> between the design goals of C#, Visual Basic, C++, and J#. Each language
> will still have full access to the .NET Framework, and therefore the same
> potential capabilities, but the prioritization of tools features will be
> based on those different goals.
>
> C++ and Visual Basic, for example, have always had pretty different design
> goals. C++ provided the deepest, most flexible access to Windows, whereas
> Visual Basic provided the easiest, most productive way to build
> applications. You could still build most applications using either
language,
> but Visual Basic focused on the types of apps Visual Basic developers
built,
> whereas C++ focused on the types of apps C++ developers built.
>
> The introductions of C# and J# have added more potential differentiation
> points in Microsoft programming language offerings. However, there really
> hasn't been that much differentiation so far. In the first two releases,
all
> of the languages have been focused on just providing an easy way to access
> the .NET Framework. However, as time goes on, each language will take a
> slightly different path with different goals of different types of
> development.
>
> First of all, each of these languages has the primary goal of enabling
> developers to make the most of Windows and the .NET Framework. However,
> sometimes there are so many potential features to implement that the
> development teams have to make hard decisions on what to keep and what to
> cut. If every language team had the same philosophy, then we would end up
> with identical support for every language (kind of like the first two
> releases of Visual Studio .NET). By having different philosophy, we're
> really providing the opportunity to make languages with unique identities.
>
> Let's take "edit and continue" and "refactoring" as examples. I think
> everyone would agree that these are both useful features that lots of
> developers would use. Odds are that E&C would be considered more important
> if you polled a sample of developers. However, in the case of different
> philosophies, polling only C# developers may actually end up showing that
> they prefer refactoring to E&C because they build apps in a different way.
>
> In the future, Visual Basic will prioritize features based on how they
> improve productivity, C++ will focus on flexibility, C# will provide a
> balance between the productivity and flexibility, and J# will focus on the
> features Java-language developers need. This isn't to say that each
language
> won't have access to the underlying platform (that is goal #1), but they
> will have it in different ways.
>
> For a lot of developers, this leads to the question, "what language should
I
> use?". The answers varies for every developer and every company. One way
to
> think about it is like this:
> - If you already use Visual Basic, then Visual Basic .NET is the best
> starting point. You may want to evaluate the syntax of each other
language,
> but odds are the Visual Basic will be the most familiar and the upcoming
> tools support will best fit your development style. In the long run,
Visual
> Basic developers will be able to complete 80% of application scenarios
> faster than any other language developer.
> - If you're using C++, then C++ is the best starting point. Once again,
> evaluating the other languages will be useful, but it's likely that the
apps
> you're familiar building will have the best support in upcoming tool
> releases. In the long run, C++ will provide the best support for accessing
> every managed and unmanaged spot on the platform.
> - If you're using the Java-language, then J# is the best starting point.
As
> always, it's worthwhile to evaluate other languages because one of the
> others may be a better fit. In the long run, J# will be the best
environment
> for developers committed to the Java-language syntax.
> - Who should use C#? In theory, anyone could. However, there is no set of
> developers who should automatically feel required to adopt its syntax.
Many
> developers from VB, C++, and Java have adopted C# because it provides the
> different perspective they look for when developing. At the same time,
there
> are developers from each language who are better of remaining with the
> language they are familiar with. In the long run, C# will be more flexible
> than Visual Basic, but not as productive. On the other hand, it will be
more
> productive than C++, but not as flexible.
>
> The key thing to remember is that each language will have the same
> *potential*, but will strive to *excel in different scenarios*. You will
be
> able to accomplish almost every task from any of the languages, but the
> tools support and effort required will vary.
>
> I hope this helps.
>
> "Thomas Jespersen" <tje@nospam.mentum.dk> wrote in message
> news:%231$CZMGCEHA.1560@TK2MSFTNGP12.phx.gbl...
> > Hello
> >
> > I guess this has been discussed a million times. But I just want MS to
> know
> > (again) that it sucks that the VS.NET Whidbey doesn't treat C# an VB.NET
> as
> > equals.
> >
> > As I understand C# has a bunch of refactoring extensions.... but VB.NET
> > doesn't.
> >
> > VB.NET has real Edit & Continue... but C# doesn't.
> >
> > This means that we are back in the good old days, where C# is for
> > professional developers and VB.NET is for armatures.
> >
> > *I* know this is not true, but "none VB Developers" doesn't. I still
meet
> > the attitude form C# developers, who thinks that C# is cable of hole lot
> > more that VB.NET. For those who still thinks so please read:
> > http://support.microsoft.com/default.aspx?scid=kb;en-us;308470
> >
> > However I'm afraid that this will change in Whidbey.
> >
> > However... my company uses VB.NET, and I'm not able to convince them to
> use
> > C#. And now that the Whidbey version of C# doesn't have Edit &
Continue...
> I
> > will never be able to convince them to make the VB->C# shift.
> >
> > I heard Jon Box say that when Microsoft developed .NET they had a "...
> From
> > VB" surfix joke. Ex. if someone said: "It would be cool if .NET
supported
> > real OO development, and you could create anonyms methods and
generics"...
> > another could add "... From VB". Microsoft why don't you considered VB
as
> a
> > first class language anymore !?!?!?!?
> >
> > If I was I C# developer I would also be very disappointed that C#
doesn't
> > get Edit & Continue.
> >
> > arghhh?!?!?!
> >
> > I would rather wait awhile until you get it all right. Or at least
> consider
> > making a Service Release which implements all this before the VS.NET for
> > Longhorn. At least I guess it will be easier for a third party company
to
> > make the refactoring things for web, than it will be for them to
implement
> > Edit & Continue in C#.
> >
> > Thomas
> >
> >
>
>
- Next message: Keith: "Re: File Associations"
- Previous message: Steven Cheng[MSFT]: "RE: where does VS look for a certificate"
- In reply to: Ed Kaim [MSFT]: "Re: Whidbey - Why is refactoring not in VB.NET?"
- Next in thread: David Lowndes: "Re: Whidbey - Why is refactoring not in VB.NET?"
- Reply: David Lowndes: "Re: Whidbey - Why is refactoring not in VB.NET?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
