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

Your facts are true, but I don't agree with your logic.
 
The number of programmers in the industries should not make a difference.
Most of the work to accomplish these things are done by one team or another
why can't they incorporate the facade we use as syntax over these tools.
 
Most VB programmers are not writing large applications because until VB.net
we did not have a good compilation or development environment. The language
is just as good as any other for doing development. But, if the tools by the
compiler writer do not provide sufficient speed and optimization, the
language is unsuitable for large scale development.
 
You should break your analogy of the object oriented design into two
categories, self taught and computer trained (educated if you wish). The
self taught people have trouble in any language with any design concepts. It
takes lots of discipline to learn design methodologies on one's own time.
The people who have degrees in computer software tend to rely less on a
specific language than they do on a proper design.  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. 
 
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#. 
 
I have developed in many languages (16 or so in college and another 6 plus
derivations of those in the last 25 years). Interpreted languages are always
slow. Compiled languages are only as good as the optimizers that work on the
code. Features of any language have been restricted to what is available by
the compiler company and third party add-ins for that particular language.
Now with .Net we can use multiple languages in the same application with
little effort. 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. 
 
I have yet to see any one force MS not to add features. 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. Although
it would be interesting to see an uprising to remove UI features from C#,
heck since VB.Net is for that, C# shouldn't need it, right? I believe that
we should all have the same opportunities to use the same concepts. 
 
 
Ken Pinard

   _____  

From: Stuart Celarier [mailto:stuart@xxxxxxxxxxx] 
Sent: Thursday, January 20, 2005 10:59 PM
To: padnug@xxxxxxxxxxxxxxx
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.

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.

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.

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.

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.

Cheers,
Stuart

Stuart Celarier | Fern Creek | www.ferncrk.com





   _____  

Yahoo! Groups Links


*       To visit your group on the web, go to:
HYPERLINK
"http://groups.yahoo.com/group/padnug/"http://groups.yahoo.com/group/padnug/
  

*       To unsubscribe from this group, send an email to:
HYPERLINK
"mailto:padnug-unsubscribe@xxxxxxxxxxxxxxx?subject=Unsubscribe"padnug-unsubs
cribe@xxxxxxxxxxxxxxx
  

*       Your use of Yahoo! Groups is subject to the HYPERLINK
"http://docs.yahoo.com/info/terms/"Yahoo! Terms of Service. 



--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 1/17/05



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 1/17/05
 


[Non-text portions of this message have been removed]