Microsoft Losing Interest in C#?

[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]]

No way losing interest. In fact, most .net programming at MS is done with
c# only or c# first, then VB ports and samples after. It is the bulldog
method. The first bulldog to get lipstick is VB as it has more
"end-user-GUI" appeal. Then c#, then c++. Also remember that the customer
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#.

 

[Nick Malik]

They say that there are more lines of VB code in existence than all other
programming languages combined...

Hi Mark,

Like Bob, I doubt your statistic. As a consultant and an App Architect,
I've been very frequently called upon to interface an application with
COBOL/CICS applications using IMS or VSAM storage mechanisms. If you
realize that COBOL was the de-facto sole language standard for business for
over 25 years, and is still probably number two or three in terms of "new
lines generated," then you'd see that VB couldn't possibly catch up.

On the other hand, it is possibly true that there were, at one time, more VB
programmers than COBOL, C++, and Java programmers combined. (About 1997,
that was probably true). Now, after the waves of developers learning Java
and then C#, I'm not so sure any more.

--- Nick

 

[James Curran]

I do not post "answers" here because I am new to C#. I am, however,
a bit of a computer history buff. I would doubt that the lines of VB
code has even passed COBOL, let alone "all other programming
languages combined."

I think you're forgetting to factor in the growth of the computer
programming industry since the heyday of COBOL. There is probably 100X more
working programmers today than there was in 1980. They probably cranked out
more code in 2003 than existed at all in 1980. (As a friend commented --
about 7 years ago -- on seeing an MSDN Universal binder full of CDROMs :
"That's more DASD space than existed in the world when I was born" (he was
born c1960))

Much of Object Orientated Programming is done by setting properties
in the IDE rather than in code.

Actually, that RAD programming, not OO. And RAD tools just generate
lines of code behind the scenes.

 

[James Curran]

What are these features? The only one I'm aware of is Edit and
Continue, and that seems to be a feature mostly desired by the
die-hard VB6 developers.

Um... Speaking as an erstwhile C++ programmer (where we'd have E&C for a
while), it's desired mostly by anyone who's ever used it.

 

[Michael C]

We could probably start a *huge* argument over whether MS has ever invented
anything from scratch. But hey, why build it from scratch when you can
"Embrace and Extend", right?

Thanks,
Michael C., MCDBA

 

[Joerg Jooss]

Um... Speaking as an erstwhile C++ programmer (where we'd have E&C
for a while), it's desired mostly by anyone who's ever used it.

But isn't that true mostly because the usual turn-around times for compiling
and linking native code are much higher than compiling CIL?

IMHO it is a feature mostly geared to VB6 developers, because they have it
now in VB6, and not having it in VB.NET is a reason not to upgrade to .NET.
I think the C++ crowd is a little more flexible than that ;-)

Cheers,

 

[Drebin]

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?).. but 80%
of the "professional" 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.

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.

I COMPLETELY agree!! But that has absolutely no bearing on how it is in the
private sector for non-software companies. You would not BELIEVE how many
ASP or VB projects have nothing but select statements.. even worse "select
*" everywhere..

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

 

[Michael C]

VB Programmer numbers may be up there pretty high still, if you're counting
all the various flavors of VB (VB.NET, VB6, VBA, VBScript).

Thanks,
Michael C., MCDBA

 

[Frans Bouma [C# 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..

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

 

[Frans Bouma [C# MVP]]

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 "professional" 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.

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.

 

[Daniel O'Connell [C# MVP]]

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.VisualBasic.dll and some
code generated by the vb compiler.

The vb compiler\IDE(not 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.VisualBasic.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]

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]

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#.

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]]

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(sorta 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(partial 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.

 

[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]]

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]]

Why shouldn't those tools have every available
productivity enhancement they can come up with?

Nobody is saying they should not I don't think. However you can't just snap
your fingers and make it so. Things have to be created and tested - that
takes time. Do you think they stand around thinking of ways to slow the
process down? Give them a break, c# 2.0 is still in beta. I think it is
pretty darn good for 1.0 so far. Cheers.

 

[Mike Schilling]

I think the clr and csc compiler are in c and assem. The framework
classes
are written in c# (or most of them.)

The compiler is not in C#? Odd; it's actually quite common for a compiler
to be written in the language it compiles; javac, for instance, is in Java,
most C compilers are in C, etc. There's obviously some bootstrapping
involved, but once that's done, there are many advantages, e.g. when trying
to improve the generated code, you have an instant test case: the compiler
itself.