RE: VB vs C# is there a auto documenting feature in C#

Ken wrote:
>The number of programmers in the industries should not make a difference.

Agreed. The point I had intended to make is that VB developers are a huge
market and have to be taken seriously. Sorry I didn't make that clear.

>As a long time developer I have never thought that reuse was just cut and
paste. Neither do any of the VB programmers I associate with.

That's great, and all power to you. I am saying that, judging from the
features being added to VB in Visual Studio 2005, features that were highly
influenced by VB developers, you are in a minority among VB developers. That
doesn't invalidate or impugn anything about your work or the company you
keep. Rock on, man.

But there are a lot more VB.NET developers who think that the current VB.NET
is too hard, and even more VB6 developers who haven't moved to .NET because
they know VB.NET is too hard. In Whidbey, many of the VB features are
designed to meet the needs of this group, since it is the majority of the
market they are trying to hit with this language.
 
>C# developers should be outraged that they do not get some features that
are provided to VB.Net developers. But, that should hold true for VB.Net
developers that are not provided features for C#. 
 
Quick reality check: different languages are developed by different teams at
Microsoft. That's just how Microsoft is structured. Different teams set
their priorities and objectives with a fair degree of independence. And so
the languages and features will diverge as each seeks to address the needs
of their audiences. The development teams have limited budgets and
resources, and they look to their audiences, their current and potential
customers, to determine the feature sets and prioritize them. So it is not
surprising that the different language teams come up with different sets of
features to work on.

>Tools for one language can be used in another. Controls created in one can
be used by others. Is that not what MS has been tooting. But, they continue
to not do that themselves.

You're mixing apples and oranges here. Calling code in one managed language
from any other managed language is a feature of the CLR. Debugging, code
access security, etc., all work cross-language because those are features
designed into the runtime, not the languages. And the CLR has fundamentally
nothing to do with the language-specific development tools. Take a tool like
code refactoring: it is highly language-specific, and would have to be
entirely different in COBOL.NET, right? I don't see the inconsistency you
are trying to point out.

No, tools for one language cannot be used in another. And why shouldn't
different product teams cater to the specific needs of their customers? In
fact, I wonder why there isn't more differentiation between languages or
more managed languages in mainstream use. Maybe IronPython
(www.ironpython.com) is leading a trend in that direction.

>I have yet to see any one force MS not to add features.

The one that stands out in my mind is the lack of multiple inheritance (MI)
in the CLR. It wasn't a question of whether MI was good or bad (there are
valid arguments on both sides of that aisle.) It boiled down to this: if the
CLR supported MI, then either all languages would have to support MI or
you'd create a tier of second-class languages. MI was judged to be too big a
conceptual burden particularly for VB developers for the benefit. As a
result, there is no MI in C# either. Eiffel.NET employs an impressive
language-level workaround to create MI, which is essential in the model for
that language.

>I still say that when they are "forced" to add a feature, especially in
.NET, why not make it work in C# and VB.Net regardless of which consumer
group wanted it. 

Pure business decisions. What business value is there (e.g., to Microsoft)
in requiring the developer experience to be identical in every language?
There is greater value (so they obviously think) in letting the different
language teams innovate and set their priorities independently.

I think the lesson of the language wars of the 80s and 90s is there is no
one universal language that solves the needs of all developers in all
domains. Specialization in languages is a good thing. That same logic
applies to the development experience using different languages.

Cheers,
Stuart

Stuart Celarier | Fern Creek | www.ferncrk.com