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

Comments inserted below:

----- Original Message ----- 
From: "Stuart Celarier" <stuart@xxxxxxxxxxx>
To: <padnug@xxxxxxxxxxxxxxx>
Sent: Thursday, January 20, 2005 10:59 PM
Subject: RE: [padnug] VB vs C# is there a auto documenting feature in C#


> Ken wrote:
> > My problem isn't with C# developers at all, it is with the way MS forces
> them to be different.
>
> Well I see it completely the other way around. Users of different
languages
> provide very different feedback have they have very different priorities.
> Microsoft responds. I see plenty of evidence of this throughout the
Whidbey
> development process. Ponder these aspects of software development in .NET
> today.
>
> Fact: the total number of VB and VB.NET programmers of the world dwarfs
the
> number of C / C++ / C# programmers of the world, like by an order of
> magnitude.

Absolutly true, which means there is a much larger pool of VB programmers
than Cx programmers.

>
> Fact: all those VB (.NET) programmers are not writing large, complex
> enterprise-level middle tier goo. They tend to write small to modest size
> applications that solve a problem they have today.

Totaly False.  There are large, mission critical, multi-teir, enterprise
applications written in VB6.
I just finished a 7 month contract working on one for the state of Oregon.

Of course, there are also a lot of hobiest programmers doing smaller
projects.

>
> Fact: in the grand tradition of object-oriented systems, C# programmers
tend
> to think of code reuse as being based on aggregation and inheritance. VB
> programmers tend to think of code reuse as based on cut-and-paste. You
doubt
> me? Look at one of the premier VB features in VS2005: code snippets. A
> couple of hundred nearly correct code samples that you can simply paste
into
> your code.

Not True.  VB programmers origially thought of VBX controls as the main
method of code reuse, a whole industry of third party component vendors grew
from this market.
VB didn't have inheritance until .Net, but it started getting object
oriented back in version 4.
Version 5 introduced the ability to write AxtiveX controls, DLLs and EXEs,
for reuse.
Systems I have worked on use classes and objects extensively, even without
inheritance.

>
> Fact: these audiences want to differentiate themselves. VB6 programmers,
by
> and large, hated having object-orientation forced on them in VB.NET, an so
> enter the My class and other facades designed to ease the pain of thinking
> too hard when all you are trying to do is solve today's problem. These are
> the people who previously *consumed* COM components. C# programmers, who
in
> large part came from C++ and Java, are the populations who previously
> *wrote* COM (or J2EE or CORBA) components.

Mostly True.  VB programmers also resent having their language of choice
phased out.  Unlike C++, VB was a user friendly, RAD language and IDE.  By
version 6, we had a very mature, stable, and full featured IDE that became
the model for the VS.Net IDE.
The move to .Net broke our language, it broke our developer community, it
changed our favorite magazine (VB Developers Journal) into the watered down
compromise of VS mag.
VB didn't need huge changes to become great, it already was great, C++
needed huge changes.
The C++ community has reaped great rewards in this upgrade, C# is a huge
improvement.
And VB finally gets inheritance and polymorphism, but we pay a big price for
it.

>
> It's not so much the languages that are different: after all, all managed
> languages just surface the CLR in different ways. It is the audiences for
> those languages that are different.
>
> Microsoft did a lot of study and soliciting feedback from different
> audiences in deciding what to focus on in Whidbey. VB.NET folks
prioritized
> Edit-and-Continue (E&C) very high on the list; C# developers put E&C much
> lower down. Then a strange thing happened: some C# developers were
outraged
> (circa PDC 2003) that VB was getting E&C and they weren't. It turns out
that
> the VB team solved a lot of problems to make E&C works, which made it much
> easier for E&C to be implemented in C# than they had originally
anticipated.
> So now E&C will be available in both VB and C#. I offer this little story
as
> one example that it is not Microsoft "forcing them to be different;" it is
> different developer audiences forcing Microsoft to meet their own distinct
> needs.

Unfortunatly, differentiating the two languages is not good for anyone from
this point forward.
It would be realy advantages if the only difference was the syntax.  But
Microsoft has already screwed up by makeing too many things different.
Array size being declared differently, etc.  VB programmers already have to
learn a new language, and their old code is not convertable, so why not make
these details consistent accross .Net languages?
What I mean is that VB.Net should be made to conform to the C# standards on
these differences (they should have done this from the beginning like they
said they were going to).  Why futz around with two standards?  If the code
was 100% convertable it truly wouldn't mater what language you used.

On the other hand, I have given much effort to learning both VB.Net and C#.
I wish empolyers saw my experience as being 100% convertable between these
languages, but I am positive that they don't.

>
> Cheers,
> Stuart
>
> Stuart Celarier | Fern Creek | www.ferncrk.com
>