Microsoft Losing Interest in C#?

[Michael Adams]

I don't know if you have noticed, but it seems like Microsoft is losing
interest in C#, and putting their energy into Visual Basic.NET instead.

For instance, online chats by language since July 1, 2004:

VB.NET 47
C# 6
C++ 8
J# 0

ADO with VB.NET 6
ADO with C# 0
ADO with C++ 0
ADO with J# 0

Windows Forms with VB.NET 2
Windows Forms with C# 0
Windows Forms with C++ 0
Windows Forms with J# 0

If you look at the roadmap Microsoft has laid out for Visual Studio 2005 and
the various languages, it appears almost all of the RAD improvements are for
VB.NET. The only thing I see coming for C# are a few language enhancements,
but really nothing for RAD. Yes, C# programmers want granularity, but we
don't get paid unless the projects go out, too! You have to get it out the
door. When is Microsoft going to wake up to this?

I don't understand why Microsoft doesn't put the same kind of energy into
the languages that start with a "C" as they do a "B"...and then they wonder
why people defect to Java, PHP, or even C++ on other platforms.

Maybe it's time for C# people to speak up.

Michael

[William Stacey [MVP]]

Actually, I think My is a great idea that should be in the framework, not
just vb. It should be in the framework so all .Net langs and MSH could call
on it and leverage the same classes. In "My" mind, my is both a way to
aggregate dispurse namespaces into more natural one and aggregate multiple
apis/classes into fewer. I think there is also more function then just
namespace wrapping..

--
William Stacey, MVP

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .

Drebin wrote:

I'm afraid to say one word, because I get all amped up over this, but what people call "features" of VB.NET (especially 2005) - I call a bad mistake and a concept that "ruins" .NET in my mind. It's one thing to have
language-specific timesavers (like a tertiary expression vs. full-blown
if/then/else) - but did you know they retrofitted "line input"? and this
"My" namespace, which has functionality that is NOT in C# - not cool.
Language features that save time, sure - but actually Framework
functionality that isn't supported in another language? Not cool brother.

erm... all 'My' does is grouping framework methods into a single utility
class. Oh my... :)

Tell me, which feature of My is not in the framework and thus not available to C# developers? No I don't think calling a method in My is saving me time over calling a method on a framework class...

What you are calling "silly features" are the BEDROCK that VB6

developers are counting on.. I can see it clearly right now.. an Excel -> Access ->
VB -> VB.NET developer (you know the kind - a "point and click
duh-veloper") can now use .NET because the language conformed to their
laziness.. so now, you take over their crappy code and it uses these "silly features" that aren't supported in C#!!

I don't get your point. I'm talking about professional software

development. When the words 'professional software development' enter the equation, people who don't know what software development means should step back and get a
coffee or something.

You don't need IDE sugar to create professional software as in: if these
features aren't there, it seems impossible to write professional software. If people can't write professional software without these features, they're IMHO not professionals and why would a professional writing software in C# have to deal with their code?

(for the people ready to butcher me: I think you can also write professional software in VB.NET, the language really isn't important for professional
software development)

And it wasn't until I had a long discussion with one these types of
developers about "line input".. and I gave him a couple alternatives
(basically wrapping various System.IO classes and wrapping functionality) - but he was COMPLETELY turned off by .NET because "I have to write 50 extra lines of code now, and it still does do what I want - it's not 'line
input'!" (although he does have a point!).
no he doesn't have a point. Professional software development isn't about
putting 4 blocks together and a single window with one button which says

"get rich". It's about theory, design, algorithms and what have you. The people
who are turned off because they have to write a couple of lines of code are also the ones who ruin software projecs by dragging/dropping data-adapters on webforms, inserting raw SQL into the webform and then wonder why maintaining the crud they created takes a lot of time and money.

Professional software development is hard work. It's not for people who
think they know the difference between a keyboard and a mouse. I hope for all mankind that the average doctor in an average hospital is more professional than these 'professionals' who apparently are too lazy to think for 2 seconds straight.

Since the very first tidbit I heard about .NET - I've always said that VB will be the contamination in an otherwise FANTASTIC idea!! VB is the cancer that will ruin .NET.
Heh. :). No I won't go that far, it's a decent language and for what's
worth: their editor kicks C#'s editor butt bigtime. I've done a lot of

C# -> VB.NET porting (our templates are first written in C# and then backported to VB.NET) in non-intellisense editors. Trust me, I'm not a fan of the language, to say the least :) (every time I run into an overloads overrides construct because an abstract method is implemented I really wonder what Vick was
thinking). However calling it the thing that will ruin .NET is way too harsh. In fact, I think VB.NET is the savior for .NET, for the sole reason that the vast majority of the developers targeting MS platforms work in VB or VB based languages.

It's not "just another language" - it's already
becoming non-standard and niche, which is what VB's problem has always
been. It's so messed up that it can get a "fresh start" where they didn't need to be backwards compatible, but yet within 2 releases, they are
falling into old habits. This is like when you keep accidentally hooking up with an old girlfriend, you know you shouldn't, but you rationalize it. The steering group for VB need to just make a clean break and stop going back to what's comfortable for once!
I agree with you that they didn't do a good job designing the language.
Whoever decided that On Error Resume Next was necessary in VB.NET should

get fired right there on the spot. Or the fantastic decision of having a single interface implementation per inheritance hierarchy. This means that in VB.NET you can't inherit from DataTable and add your own serialization code. Erm...

Ugh. I knew I shouldn't have started talking about this!
heh :) Well, for kicks you could have crossposted it to the vb.net

newsgroup ;)

FB

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

"Michael Adams" <no****@nomail. com> wrote in message
news:Ue******** ************@sp eakeasy.net...
> That's fine, but why don't they migrate the new features to C#, too?

What features do you mean?
E&C? The team has commited to it, just not in whidbey.
My? Not C# worthy, IMHO.
Silly IDE features? Not really important, honestly.

What is it you feel isn't there?

--
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Frans Bouma [C# MVP]]

William Stacey [MVP] wrote:

Actually, I think My is a great idea that should be in the framework, not
just vb. It should be in the framework so all .Net langs and MSH could call
on it and leverage the same classes. In "My" mind, my is both a way to
aggregate dispurse namespaces into more natural one and aggregate multiple
apis/classes into fewer. I think there is also more function then just
namespace wrapping..

Isn't 'My' in the framework btw? Or is it a native VB.NET keyword? I haven't
checked, but it wouldn't surprise me if it was a class which can be
referenced from C# as well...

FB
--
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Frans Bouma [C# MVP]]

Drebin wrote:

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message

I don't get your point. I'm talking about professional software
development.
When the words 'professional software development' enter the equation,
people
who don't know what software development means should step back and get a
coffee or something.
hahahahahaha :-) oh man.. If only real life were this simple!! I assume
you are either still in an academic setting (university?) or went right to
a strict programming environment (like a hardcore software company?)..

I got my B.sc in 1994, so that leaves me with the second option ;)
but
80% of the "profession al" software developers out there are in NO WAY
professional. I would LOVE an ideal world where everyone I work with is
competent and creative, but it just isn't so. Instead, MOST of the
"regular" developers that work at "regular" companies are lazy,
not-so-bright and/or very unmotivated - and worst of all hate change.
Imagine that? A developer who hates change? Ugh.

Yeah, I've worked among them, for several years actually :) I know they
exist but I don't call them professionals per se.

In fact, I think VB.NET is the savior for .NET, for the sole reason that
the
vast majority of the developers targeting MS platforms work in VB or VB
based languages.

Sadly, this is Microsofts point too - and what you guys are getting is, a
developer is not a developer. As a generalization, VB developers are the
ones I mentioned above. Everyone is so wrapped up in converting VB6
duh-velopers, that no one stopped to realize you're attracting the wrong
kind of people!! Quantity != Quality

But hasn't this always been the case? I'm not against lower skilled people
in the software business, and I really don't care which language they
use/prefer, it's just that not everyone should be seen as a highly
trained/skilled professional because not everyone is a highly trained/skilled
professional. Also, I don't think a platform needs solely those highly
trained professionals as it would result in a lot of people who opt for the
complex tasks but almost no-one who wants to/will do the not so complex tasks
which also have to be done. Not everyone can be a lead-developer in a
project, you need a lot of hands doing the typing too :)

Frans.

--
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Daniel O'Connell [C# MVP]]

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .

William Stacey [MVP] wrote:

Actually, I think My is a great idea that should be in the framework, not
just vb. It should be in the framework so all .Net langs and MSH could
call
on it and leverage the same classes. In "My" mind, my is both a way to
aggregate dispurse namespaces into more natural one and aggregate
multiple
apis/classes into fewer. I think there is also more function then just
namespace wrapping..

Isn't 'My' in the framework btw? Or is it a native VB.NET keyword? I
haven't
checked, but it wouldn't surprise me if it was a class which can be
referenced from C# as well...

My is a combination of a namespace within Microsoft.Visua lBasic.dll and some
code generated by the vb compiler.

The vb compiler\IDE(no t sure of which at this point) generates a set of
partial classes in the my namespace, MySettings, MyResources, MyForms(IIRC,
anyway), which provide convient functinoality via a standard My. interface.
There may also be some compiler based aggregation that allows My. to have
some functionality the compiler divines instead of coming from code
generated by the IDE or written by the user. I am, obviously, not a VB
master, lol. This might be something worth posting to the vb group, however.
I'm sure one of the VB MVP's knows quite precisely how My works.

Because of this, My's functionality isn't *entirely* available in other
languages, but much of it should be via Microsoft.Visua lBasic.dll and the
IDE itself. For example, in whidbey, VC# generates a Settings.cs file using
the new SettingsBase functionality in the framework when you add a setting
in a projects properties. I think it does something similar for resources,
etc.

My in and of itself is not something I would personally like to see in C#.
It just isn't a feature I consider to be particularly valuable to my work,
appropriate within the C# philosophy, and I do worry that it will start to
drive the quality of developer down as he trys to fit everything into the
"My" mold, instead of the framework itself.

I hope VB doesn't have an issue with it, because I do think its a wonderful
feature insofar as the classic VB mindset goes. I suspect it will go easier
for VB devs than it would for C#\C++ ones, at that. Any VB dev who used VB6
or earlier should, by this point, be quite able to recognize the limitations
of the langauge's features and know when its time to step out into the
framework(or even other languages).
I suspect many C# devs would either shun the namespace entirely or not be as
able to stop using it as they would need to be, simply out of lack of
experiance.

[Phill]

> Oh, and about losing interest: .NET is written in C#, .NET is / will be a

cornerstone of MS' activities. I don't think C# will go away anytime soon :)

What do you mean about .NET being written in C#? Are you talking
about The Class Library? Visual studio?

I can't imagine the CLR is written in a .net language. What do you
mean exactly?

And I certainly hope MS decides to make C# the primary language going
into the future. I'm in the processes of switching over to it from C++
and I really like it and happen to really dislike VB.

[Michael Adams]

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .

C# is not getting more RAD than VB.NET for a reason: positioning of
languages. If C# and VB.NET have both the same RAD and other features, users get confused what to use: C# or VB.NET? Now it gets more clear, which IMHO is a good thing.

Oh, and about losing interest: .NET is written in C#, .NET is / will be a
cornerstone of MS' activities. I don't think C# will go away anytime soon :)
FB

While I agree with you that positioning is probably the reason, I think
that is just plain STUPID. Marketing computer language tools, is not like
marketing a car, where one person wants a luxury car, another a sport car,
and they have image to worry about. Computer languages are tools. That's
it - just tools! Why shouldn't those tools have every available
productivity enhancement they can come up with?

Michael

[Michael Adams]

"William Stacey [MVP]" <st***********@ mvps.org> wrote in message
news:ey******** *****@tk2msftng p13.phx.gbl...

is bit different for all three. A c++ programmer, for example, probably is not wishing for some fancy spinning control, but probably some other
advanced language feature, advanced debugger ability, conflict detection,
etc. The really good ideas will roll down hill in time however with help
from the customers. That said, from everything I see, they are investing big time in c#.

--
William Stacey, MVP

This Microsoft mindset on languages does not compute. When the day comes,
when the C++ programmer could use a spinner or (fill in the blank), why
shouldn't it be available, if the company already has it? Are we suppose to
change languages, if we happen to want that for some project? It has
already been developed for the IDE for another language. They have the
technology. They should just put it in there. If you need it, you can use
it. If not, don't. Just because we are programming in C++ (or any language
that starts with a C) doesn't mean we are masochists.

And why wouldn't we want "advanced language feature", "advanced debugger
ability", etc? What, because the language, be it C++ or C#, is based on C,
an old language, we also want old technology?

I'm sorry but I think a lot of people at Microsoft forget we get paid for
program output, not lines of code, or hours spent programming. We don't
care about how our language is positioned at Microsoft marketing. This is
about the same thinking that we should be wood carving with a knife, when a
CNC machine is available.

Michael

[Daniel O'Connell [C# MVP]]

"Michael Adams" <no****@nomail. com> wrote in message
news:lr******** ************@sp eakeasy.net...

"William Stacey [MVP]" <st***********@ mvps.org> wrote in message
news:ey******** *****@tk2msftng p13.phx.gbl...

is bit different for all three. A c++ programmer, for example, probably is

not wishing for some fancy spinning control, but probably some other
advanced language feature, advanced debugger ability, conflict detection,
etc. The really good ideas will roll down hill in time however with help
from the customers. That said, from everything I see, they are investing

big

time in c#.

--
William Stacey, MVP

This Microsoft mindset on languages does not compute. When the day comes,
when the C++ programmer could use a spinner or (fill in the blank), why
shouldn't it be available, if the company already has it? Are we suppose
to
change languages, if we happen to want that for some project? It has
already been developed for the IDE for another language. They have the
technology. They should just put it in there. If you need it, you can
use
it. If not, don't. Just because we are programming in C++ (or any
language
that starts with a C) doesn't mean we are masochists.

A control is a bad example, within the .NET sphere, a control is just a
class which any language can use.
And why wouldn't we want "advanced language feature", "advanced debugger
ability", etc? What, because the language, be it C++ or C#, is based on
C,
an old language, we also want old technology?

I'm sorry but I think a lot of people at Microsoft forget we get paid for
program output, not lines of code, or hours spent programming. We don't
care about how our language is positioned at Microsoft marketing. This is
about the same thinking that we should be wood carving with a knife, when
a
CNC machine is available.

And your stance is that your lawnmower should have a chain saw attachment
just in case you need to cut down a tree some day? Stuffing *EVERYTHING*
into one language is usually a horrible idea. It turns a langauge that is
easy to use and learn into a pile of crap which about 6 people on earth
fully understand(sort a like C++).

Now, currently, MS tools have about a limited dev cycle(and limited
resouces, its not like VB and C# are the sole things MS is working on).
Between 2003 and 2005 the languages gain a good number of common
features(partia l classes, generics, framework additions, etc) and each gains
some differentiaing features that the company feels fits the customer base
better.

You also have to consider the target and the language before adding
features. For example, are anonymous methods a good thing for VB? For that
matter, are they something that syntactically fits within VB? Does C# need
declarative event handlers? What would it cost in clarity? Do either need
the ability to write unmanaged code?

You can't simply just say "Everything has to be everywehre". Doing so
suggests you don't really understand either language.
Michael

[William Stacey [MVP]]

> You can't simply just say "Everything has to be everywehre". Doing so

suggests you don't really understand either language.

I agree with that Daniel. One also has to be realistic. Even MS can not
just make everything just appear on ever language. There is always limited
resources for unlimited customer needs. In all, having everything common
around .net is a huge step forward - I still am amazed they pulled this off
and the result is fantastic imho. Cheers!

--
William Stacey, MVP

[William Stacey [MVP]]

> I can't imagine the CLR is written in a .net language. What do you

mean exactly?
I think the clr and csc compiler are in c and assem. The framework classes
are written in c# (or most of them.)
And I certainly hope MS decides to make C# the primary language going
into the future.

Me too.

--
William Stacey, MVP