Re: Whidbey - Why is refactoring not in VB.NET?
From: Ed Kaim [MSFT] (edkaim_at_online.microsoft.com)
Date: 03/14/04
- Next message: David Lowndes: "Re: Whidbey - Why is refactoring not in VB.NET?"
- Previous message: Thomas Jespersen: "Re: VS.Net Codebehind location path"
- In reply to: Thomas Jespersen: "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: Sun, 14 Mar 2004 01:47:36 -0800
> I totally agree with you that all productive features should be available
to
> all MS .NET languages.
In a perfect world, every language would get every feature. Unfortunately,
development and testing resources are limited and cuts have to be made. If
the same design philosophy were applied to all languages, then we would end
up with several identical programming experiences that only differed by
punctuation. The goals of each language development team is provide the best
product for their respective customers. Some developers want the tools to do
as much as possible, whereas other developers want the tools to only provide
the minimum they need.
If you take a look at the Java philosophy, you have one language that
doesn't cater to productivity in the same ways that VB does, doesn't provide
the elegance thta C# does, and doesn't provide the flexibility and access
C++ provides. While Java is a good language, it is very much a series of
compromises to appease the varying sets of developers and development styles
out there. This certainly doesn't mean that VB won't have flexibility and
elegance, C# won't have productivity features, etc. It just means that
different types of developers really want different things and one language
and one design philosophy don't fit all of these needs.
Before joining Microsoft, I was a pure C/C++ developer that dropped to
assembly when I worked on drivers. I couldn't understand why people cared
about visual designers. I avoided using the visual MFC form designer because
I wanted to align everything myself (and just didn't trust it). I didn't
like using anything drag & drop because I wanted to understand and customize
(if necessary) every line of code that went into the build. Virtual
machines? Bah--I'll handle my own memory, thank you very much. However,
since coming to Microsoft I've met with thousands of developers worldwide
and have come to realize that I was in the minority by a significant margin.
The majority of developers out there didn't want to deal with the stuff I
insisted on controlling and most of them used VB. As such, I began to
realize that the features they used weren't that valuable to me and the
features I used weren't interesting to them. The most important thing is
that their tool wasn't right for me and mine wasn't right for them. Keeping
this in mind for future generations of Visual Studio design will result in a
set of languages that provide better fits for developers.
I know different people have different opinions, so I'm interested in other
thoughts.
"Thomas Jespersen" <tje@nospam.mentum.dk> wrote in message
news:OY0SJiZCEHA.2256@TK2MSFTNGP12.phx.gbl...
> Hello David
>
> Thanks for supporting me one this one. I guess you vote as a MVP counts
more
> than mine.
>
> And as a C++ developer, you must really suffer form the missing
productivity
> features that VB and C# community developers have. But I'm sure that all
you
> C++ developers don't want those productive features anyway.... not!
>
> I totally agree with you that all productive features should be available
to
> all MS .NET languages. I don't know much about C++ (which is why I only
> speak about C# and VB). In my opinion MS should also has gone all the way
> when redesigning VB -> VB.NET. I mean... with a few additions/twist to the
> VB language syntax, they could have had a VB -> C# source-code converter
and
> use the C# compiler for both VB and C#.
>
> I'm not sure that I share you point of only having only one language. In
> theory you are right, but in real life it is not a matter of which syntax
> one prefer, it is a matter of bringing as many developers to the .NET
> platform as possible. And I'll beet that a lot of VB developers would
never
> take the shift to .NET if the language was C#, and also a C++, J++ or Java
> developer would never accept the VB Syntax. Personally I would not have a
> problem, but everybody else would.
>
> Thomas
>
> "David Lowndes" <davidl@example.invalid> wrote in message
> news:m4i650ho4b737gh3nvolsvon3l97pjhn1h@4ax.com...
> > >I understand what you writing, but I don't agree with the things you
> write.
> >
> > You're not alone Thomas. I seriously disagree with MS's path of
> > productivity feature diversification on a per-language basis. The
> > result I foresee is that projects will be done in multiple languages
> > for the wrong reason, and that'll cause unnecessary code duplication
> > and maintenance nightmares.
> >
> > In my opinion, either all the productivity features should be
> > available to all the MS .Net languages (so it really is a choice of
> > which language you prefer), or MS should stick to a single .Net
> > language (all MS .Net languages are general purpose languages anyway).
> >
> > I think that MS's survey results are biased by making assumptions that
> > there's such an animal as a VB, C++, or C# developer - there is, but
> > that's just the history they've created. In reality there are
> > developers of differing backgrounds and abilities, working in diverse
> > application fields, most of whom will appreciate tools that make their
> > life easier. While a vocal few have very strong opinions of their
> > favourite/most hated languages, I bet that 95% of the silent majority
> > don't mind (within reason) which language syntax they use. They may
> > have horror stories that they associate with a particular language
> > that makes them say they hate it, but I suspect that those stories are
> > not specifically about the language's syntax.
> >
> > Dave
> > --
> > MVP VC++ FAQ: http://www.mvps.org/vcfaq
>
>
- Next message: David Lowndes: "Re: Whidbey - Why is refactoring not in VB.NET?"
- Previous message: Thomas Jespersen: "Re: VS.Net Codebehind location path"
- In reply to: Thomas Jespersen: "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
|