The Demise of C#

[Kevin Spencer]

About 2 years ago, and as recently as perhaps 1 year ago, I can recall
seeing many posts about what language to use with ASP.Net. The consensus was
that employers paid more for C# programmers, and it seems that C# became the
darling of the ASP.Net crowd.

In the meantime, I have observed an interesting phenomenon. Originally,
employers hired programmers who used C# because it was based on C, and the
prevailing opinion was (and may still be) that C# developers were better
because they must have known and/or practiced C or C++ at some time, which
would make them better programmers overall. C and C++ are hard-core
programming languages compared to VB.

However, now that nearly everyone has jumped on the C# bandwagon, it seems
to me that the distinction between the languages has nearly disappeared, at
least in terms of evaluating programmers for hire. There seem to be almost
as many clueless C# developers out there as VB.Net developers. Many C#
developers today are basically VB.Net developers using a different syntax. I
wonder if the employers have become aware of this trend?

--

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

[John]

I'm sorry Kevin,

but Option Strict has no bearing on the string concatenation operator in VB,
and the & operator has nothing to do with weak data typing. It is simply a
syntactical convenience that has no implicit effects (it is explicitly
stating that both operands are going to be converted to string as necessary),
and the expression, '123 + 456' in C# is not the same as '123 & 456' in VB.
While I agree with you for the most part about the demise of C#, I found it
pretty odd that you do not understand this distinction.

Any C++ programmer who has a poorer understanding of reusability and generic
design than someone who started on VB or C# should not be calling themselves
C++ programmers, for any moron who even half-understands the STL should know
far more about design patterns than anyone who thinks that the .NET framework
library classes are the epitome of object-oriented design.

- John

"Kevin Spencer" wrote:

For instance, take the string concatenation operator from VB, &, which
automatically converts the left and right operands to strings and returns
a
combined string. Why is there no equivalent in C#?

+

The "ToString() part is simply strong data typing. Try turning Option Strict
ON for a change.

--
*sigh*,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:DA******** *************** ***********@mic rosoft.com...

I personally think there are some really great things in VB.NET and it's a
real crime how C# doesn't implement them. If you ask me, VB.NET is a
better
language for the rapid-application development needs of most .NET
developers.
I still code in C# over VB most of the time, but there are many things I
envy
in VB that I find lacking in C#.

For instance, take the string concatenation operator from VB, &, which
automatically converts the left and right operands to strings and returns
a
combined string. Why is there no equivalent in C#? Sure the '&' character
would conflict with the bitwise and, but there are plenty of other symbols
(ex - Lua's '..') that could be used in place, and it's absolutely silly
that
someone has to write:

some_string_out put_function("B lah blah: " + x.ToString() + ", " +
y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );

when they could have simply wrote something like:

some_string_out put_function("B lah blah: " .. x .. ", " .. y .. " blah blah
"
.. z .. ", " .. q);

There's nothing implicit going on here; the operator has clearly-defined
behavior. It makes little sense to me why C# does not have things like
this
that would do nothing but make the code a little more readable and
convenient
to write.

I can understand many of the reasons for C#'s more explicit nature like
requiring explicit casts (safety) and explicitly indicating where you want
to
use dynamic binding (performance), but it's silly to deprive a language of
something useful just because it isn't characteristic of the language from
which it was modeled.

[John]

Hi Frank,

I agree with many things you've said.

Anyone who hires primarily on the basis of language skills is a fool,
because none of these languages are weak in the hands of a professional.
I have to disagree to some extent here. I work in the 3D graphics industry,
and if I were to choose between a moderately skilled C programmer and a
highly skilled Java programmer for writing our package's core renderer, I
would choose the C programmer. Some tools are just better suited for a
specific purpose.
And on the point of C++ versus C# versus VB.NET: C++ is probably superior in
the sense it is closer to the language of the machine, but it is challenging
to write well, especially in the modern era of two-minute turnaround.
I would say that C++ starts out closer to language of the machine. However,
it provides facilities for achieving higher and higher and higher levels of
abstraction that Java and .NET simply cannot provide. In the hands of a truly
skilled C++ programmer, C++ can become a very high level language that,
unlike other high-level languages out there, preserves the power of low-level
languages through its ability to apply solution patterns at compile-time.
While I agree that a skilled programmer should have no problem adapting to a
new language and doing just as well or even better than the programmers
fluent in that language, I would say that the more experienced a programmer
becomes, the more these language differences start becoming significant in
his work.

While primarily a C++ programmer, I've had to work alongside .NET
enthusiasts, and I managed to pick up C# and VB in a few days to the point
where I was showing my co-workers new things about .NET methods of
implementing callback events, using delegates, the significance of sealed
classes, how to implement a thread pool, etc. Not all C++ programmers are
prone to drown in the .NET framework. However, I do agree that the .NET
framework can be a source of grief for C++ programmers. For me, it is because
I find it to be inferior in many places, and I have a hard time implementing
something with techniques I know to be inferior. Take reverse iteration of a
collection in .NET. It doesn't exist using the enumeration constructs
provided. While the typical C# or VB might happily just reverse a container
and then use forward iteration, it's hard for me, a person who has seen
superior libraries, to simply tuck my tail between my legs and write inferior
code. The drive for superiority that many C++ programmers have can be a fault
when compared to the rapid speed at which many of these VB and C# programmers
develop software.
In the
modern time frames, neither VB.NET nor C# is the better language, because in
professional hands the results are the same, which is a good solution. What
sets the professional apart from the non-professional in the world of .NET
programming is knowledge of the framework.

I absolutely agree here. That is the only thing that should be important to
an employer looking to hire a programmer writing .NET applications.

- John

[Kevin Spencer]

Hello John,

I understand generics fine thank you. Generics have their place. But you
missed my point. And I'm not going to waste anyone's time debating it.

And please point out to me where I called myself a C++ programmer. I am
simply a programmer. I can program in a half-dozen languages, one of which
is C++, although I tend to avoid it. C# is an excellent RAD language, and
when I need to go lower than C# I generally go to C. I can also program in
VB.Net, but tend to avoid it because of the requirements of many of my
applications, which require things not available in VB.Net, like pointers.

No need to get personal, eh?

--

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.
"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:EA******** *************** ***********@mic rosoft.com...

I'm sorry Kevin,

but Option Strict has no bearing on the string concatenation operator in
VB,
and the & operator has nothing to do with weak data typing. It is simply a
syntactical convenience that has no implicit effects (it is explicitly
stating that both operands are going to be converted to string as
necessary),
and the expression, '123 + 456' in C# is not the same as '123 & 456' in
VB.
While I agree with you for the most part about the demise of C#, I found
it
pretty odd that you do not understand this distinction.

Any C++ programmer who has a poorer understanding of reusability and
generic
design than someone who started on VB or C# should not be calling
themselves
C++ programmers, for any moron who even half-understands the STL should
know
far more about design patterns than anyone who thinks that the .NET
framework
library classes are the epitome of object-oriented design.

- John

"Kevin Spencer" wrote:

> For instance, take the string concatenation operator from VB, &, which
> automatically converts the left and right operands to strings and
> returns
> a
> combined string. Why is there no equivalent in C#?

+

The "ToString() part is simply strong data typing. Try turning Option
Strict
ON for a change.

--
*sigh*,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:DA******** *************** ***********@mic rosoft.com...

>I personally think there are some really great things in VB.NET and it's
>a
> real crime how C# doesn't implement them. If you ask me, VB.NET is a
> better
> language for the rapid-application development needs of most .NET
> developers.
> I still code in C# over VB most of the time, but there are many things
> I
> envy
> in VB that I find lacking in C#.
>
> For instance, take the string concatenation operator from VB, &, which
> automatically converts the left and right operands to strings and
> returns
> a
> combined string. Why is there no equivalent in C#? Sure the '&'
> character
> would conflict with the bitwise and, but there are plenty of other
> symbols
> (ex - Lua's '..') that could be used in place, and it's absolutely
> silly
> that
> someone has to write:
>
> some_string_out put_function("B lah blah: " + x.ToString() + ", " +
> y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
>
> when they could have simply wrote something like:
>
> some_string_out put_function("B lah blah: " .. x .. ", " .. y .. " blah
> blah
> "
> .. z .. ", " .. q);
>
> There's nothing implicit going on here; the operator has
> clearly-defined
> behavior. It makes little sense to me why C# does not have things like
> this
> that would do nothing but make the code a little more readable and
> convenient
> to write.
>
> I can understand many of the reasons for C#'s more explicit nature like
> requiring explicit casts (safety) and explicitly indicating where you
> want
> to
> use dynamic binding (performance), but it's silly to deprive a language
> of
> something useful just because it isn't characteristic of the language
> from
> which it was modeled.

[John]

Hi Kevin,

I'm sorry but that second part wasn't directed at you. I was in a hurry and
crammed two messages into one after browsing through the boards - I apologize
about the confusion. The second paragraph was in response to someone writing
about how a .NET developer is more likely to understand object-oriented
design and reusability than a C++ programmer. I would have to disagree, at
least based on my experience. That said, I know plenty of C++ programmers who
shouldn't be calling themselves as such - the kind of C++ programmer that
thinks that templates are only useful for making collections of arbitrary
types, for instance.

As for the first part, syntactic differences aren't going to make or break a
language, but between VB.NET and C#, that's among the most significant
differences between the two. What I would like to see is a hybrid between the
two languages.

There are syntactical conveniences (like the string concatenation operator)
in both languages would be nice to have at once. Global functions may not be
suitable for a large-scale design, but the .NET languages are just as
suitable for rapid application development where globally accessible
functions can be quite suitable. Furthermore, a VB module provides the
ability to declare state variables with private modifiers, and can be
contained within a custom namespace, so as far as I'm concerned, a module is
superior to a class with nothing but static functions, as the members of such
a class cannot be brought into the global namespace.

Operator overloading is another example. It seems like a shame that VB users
must cope without the syntactic convenience simply because operator
overloading isn't 'VB-esque'. Well, neither was inheritance and polymorphism.
Polymorphism to a VB programmer prior to .NET was to use variants.

Syntax and small features like the addition of modules is pretty much all
there is to go by when judging the differences between .NET languages.

- John

"Kevin Spencer" wrote:

Hello John,

I understand generics fine thank you. Generics have their place. But you
missed my point. And I'm not going to waste anyone's time debating it.

And please point out to me where I called myself a C++ programmer. I am
simply a programmer. I can program in a half-dozen languages, one of which
is C++, although I tend to avoid it. C# is an excellent RAD language, and
when I need to go lower than C# I generally go to C. I can also program in
VB.Net, but tend to avoid it because of the requirements of many of my
applications, which require things not available in VB.Net, like pointers.

No need to get personal, eh?

--

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.
"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:EA******** *************** ***********@mic rosoft.com...

I'm sorry Kevin,

but Option Strict has no bearing on the string concatenation operator in
VB,
and the & operator has nothing to do with weak data typing. It is simply a
syntactical convenience that has no implicit effects (it is explicitly
stating that both operands are going to be converted to string as
necessary),
and the expression, '123 + 456' in C# is not the same as '123 & 456' in
VB.
While I agree with you for the most part about the demise of C#, I found
it
pretty odd that you do not understand this distinction.

Any C++ programmer who has a poorer understanding of reusability and
generic
design than someone who started on VB or C# should not be calling
themselves
C++ programmers, for any moron who even half-understands the STL should
know
far more about design patterns than anyone who thinks that the .NET
framework
library classes are the epitome of object-oriented design.

- John

"Kevin Spencer" wrote:

> For instance, take the string concatenation operator from VB, &, which
> automatically converts the left and right operands to strings and
> returns
> a
> combined string. Why is there no equivalent in C#?

+

The "ToString() part is simply strong data typing. Try turning Option
Strict
ON for a change.

--
*sigh*,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:DA******** *************** ***********@mic rosoft.com...
>I personally think there are some really great things in VB.NET and it's
>a
> real crime how C# doesn't implement them. If you ask me, VB.NET is a
> better
> language for the rapid-application development needs of most .NET
> developers.
> I still code in C# over VB most of the time, but there are many things
> I
> envy
> in VB that I find lacking in C#.
>
> For instance, take the string concatenation operator from VB, &, which
> automatically converts the left and right operands to strings and
> returns
> a
> combined string. Why is there no equivalent in C#? Sure the '&'
> character
> would conflict with the bitwise and, but there are plenty of other
> symbols
> (ex - Lua's '..') that could be used in place, and it's absolutely
> silly
> that
> someone has to write:
>
> some_string_out put_function("B lah blah: " + x.ToString() + ", " +
> y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
>
> when they could have simply wrote something like:
>
> some_string_out put_function("B lah blah: " .. x .. ", " .. y .. " blah
> blah
> "
> .. z .. ", " .. q);
>
> There's nothing implicit going on here; the operator has
> clearly-defined
> behavior. It makes little sense to me why C# does not have things like
> this
> that would do nothing but make the code a little more readable and
> convenient
> to write.
>
> I can understand many of the reasons for C#'s more explicit nature like
> requiring explicit casts (safety) and explicitly indicating where you
> want
> to
> use dynamic binding (performance), but it's silly to deprive a language
> of
> something useful just because it isn't characteristic of the language
> from
> which it was modeled.

[Juan T. Llibre]

Is there *any* way to make this thread demise ?

;-)

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:E0******** *************** ***********@mic rosoft.com...

Hi Kevin,

I'm sorry but that second part wasn't directed at you. I was in a hurry and
crammed two messages into one after browsing through the boards - I apologize
about the confusion. The second paragraph was in response to someone writing
about how a .NET developer is more likely to understand object-oriented
design and reusability than a C++ programmer. I would have to disagree, at
least based on my experience. That said, I know plenty of C++ programmers who
shouldn't be calling themselves as such - the kind of C++ programmer that
thinks that templates are only useful for making collections of arbitrary
types, for instance.

As for the first part, syntactic differences aren't going to make or break a
language, but between VB.NET and C#, that's among the most significant
differences between the two. What I would like to see is a hybrid between the
two languages.

There are syntactical conveniences (like the string concatenation operator)
in both languages would be nice to have at once. Global functions may not be
suitable for a large-scale design, but the .NET languages are just as
suitable for rapid application development where globally accessible
functions can be quite suitable. Furthermore, a VB module provides the
ability to declare state variables with private modifiers, and can be
contained within a custom namespace, so as far as I'm concerned, a module is
superior to a class with nothing but static functions, as the members of such
a class cannot be brought into the global namespace.

Operator overloading is another example. It seems like a shame that VB users
must cope without the syntactic convenience simply because operator
overloading isn't 'VB-esque'. Well, neither was inheritance and polymorphism.
Polymorphism to a VB programmer prior to .NET was to use variants.

Syntax and small features like the addition of modules is pretty much all
there is to go by when judging the differences between .NET languages.

- John

"Kevin Spencer" wrote:

Hello John,

I understand generics fine thank you. Generics have their place. But you
missed my point. And I'm not going to waste anyone's time debating it.

And please point out to me where I called myself a C++ programmer. I am
simply a programmer. I can program in a half-dozen languages, one of which
is C++, although I tend to avoid it. C# is an excellent RAD language, and
when I need to go lower than C# I generally go to C. I can also program in
VB.Net, but tend to avoid it because of the requirements of many of my
applications, which require things not available in VB.Net, like pointers.

No need to get personal, eh?

--

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.
"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:EA******** *************** ***********@mic rosoft.com...

> I'm sorry Kevin,
>
> but Option Strict has no bearing on the string concatenation operator in
> VB,
> and the & operator has nothing to do with weak data typing. It is simply a
> syntactical convenience that has no implicit effects (it is explicitly
> stating that both operands are going to be converted to string as
> necessary),
> and the expression, '123 + 456' in C# is not the same as '123 & 456' in
> VB.
> While I agree with you for the most part about the demise of C#, I found
> it
> pretty odd that you do not understand this distinction.
>
> Any C++ programmer who has a poorer understanding of reusability and
> generic
> design than someone who started on VB or C# should not be calling
> themselves
> C++ programmers, for any moron who even half-understands the STL should
> know
> far more about design patterns than anyone who thinks that the .NET
> framework
> library classes are the epitome of object-oriented design.
>
> - John
>
> "Kevin Spencer" wrote:
>
>> > For instance, take the string concatenation operator from VB, &, which
>> > automatically converts the left and right operands to strings and
>> > returns
>> > a
>> > combined string. Why is there no equivalent in C#?
>>
>> +
>>
>> The "ToString() part is simply strong data typing. Try turning Option
>> Strict
>> ON for a change.
>>
>> --
>> *sigh*,
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> What You Seek Is What You Get.
>>
>> "John" <Jo**@discussio ns.microsoft.co m> wrote in message
>> news:DA******** *************** ***********@mic rosoft.com...
>> >I personally think there are some really great things in VB.NET and it's
>> >a
>> > real crime how C# doesn't implement them. If you ask me, VB.NET is a
>> > better
>> > language for the rapid-application development needs of most .NET
>> > developers.
>> > I still code in C# over VB most of the time, but there are many things
>> > I
>> > envy
>> > in VB that I find lacking in C#.
>> >
>> > For instance, take the string concatenation operator from VB, &, which
>> > automatically converts the left and right operands to strings and
>> > returns
>> > a
>> > combined string. Why is there no equivalent in C#? Sure the '&'
>> > character
>> > would conflict with the bitwise and, but there are plenty of other
>> > symbols
>> > (ex - Lua's '..') that could be used in place, and it's absolutely
>> > silly
>> > that
>> > someone has to write:
>> >
>> > some_string_out put_function("B lah blah: " + x.ToString() + ", " +
>> > y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
>> >
>> > when they could have simply wrote something like:
>> >
>> > some_string_out put_function("B lah blah: " .. x .. ", " .. y .. " blah
>> > blah
>> > "
>> > .. z .. ", " .. q);
>> >
>> > There's nothing implicit going on here; the operator has
>> > clearly-defined
>> > behavior. It makes little sense to me why C# does not have things like
>> > this
>> > that would do nothing but make the code a little more readable and
>> > convenient
>> > to write.
>> >
>> > I can understand many of the reasons for C#'s more explicit nature like
>> > requiring explicit casts (safety) and explicitly indicating where you
>> > want
>> > to
>> > use dynamic binding (performance), but it's silly to deprive a language
>> > of
>> > something useful just because it isn't characteristic of the language
>> > from
>> > which it was modeled.
>>
>>
>>

[Kevin Spencer]

Thanks John.

Microsoft reads these newsgroups, and will respond to feature sets that a
large number of people ask for. So, keep your fingers crossed!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:E0******** *************** ***********@mic rosoft.com...

Hi Kevin,

I'm sorry but that second part wasn't directed at you. I was in a hurry
and
crammed two messages into one after browsing through the boards - I
apologize
about the confusion. The second paragraph was in response to someone
writing
about how a .NET developer is more likely to understand object-oriented
design and reusability than a C++ programmer. I would have to disagree, at
least based on my experience. That said, I know plenty of C++ programmers
who
shouldn't be calling themselves as such - the kind of C++ programmer that
thinks that templates are only useful for making collections of arbitrary
types, for instance.

As for the first part, syntactic differences aren't going to make or break
a
language, but between VB.NET and C#, that's among the most significant
differences between the two. What I would like to see is a hybrid between
the
two languages.

There are syntactical conveniences (like the string concatenation
operator)
in both languages would be nice to have at once. Global functions may not
be
suitable for a large-scale design, but the .NET languages are just as
suitable for rapid application development where globally accessible
functions can be quite suitable. Furthermore, a VB module provides the
ability to declare state variables with private modifiers, and can be
contained within a custom namespace, so as far as I'm concerned, a module
is
superior to a class with nothing but static functions, as the members of
such
a class cannot be brought into the global namespace.

Operator overloading is another example. It seems like a shame that VB
users
must cope without the syntactic convenience simply because operator
overloading isn't 'VB-esque'. Well, neither was inheritance and
polymorphism.
Polymorphism to a VB programmer prior to .NET was to use variants.

Syntax and small features like the addition of modules is pretty much all
there is to go by when judging the differences between .NET languages.

- John

"Kevin Spencer" wrote:

Hello John,

I understand generics fine thank you. Generics have their place. But you
missed my point. And I'm not going to waste anyone's time debating it.

And please point out to me where I called myself a C++ programmer. I am
simply a programmer. I can program in a half-dozen languages, one of
which
is C++, although I tend to avoid it. C# is an excellent RAD language, and
when I need to go lower than C# I generally go to C. I can also program
in
VB.Net, but tend to avoid it because of the requirements of many of my
applications, which require things not available in VB.Net, like
pointers.

No need to get personal, eh?

--

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.
"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:EA******** *************** ***********@mic rosoft.com...

> I'm sorry Kevin,
>
> but Option Strict has no bearing on the string concatenation operator
> in
> VB,
> and the & operator has nothing to do with weak data typing. It is
> simply a
> syntactical convenience that has no implicit effects (it is explicitly
> stating that both operands are going to be converted to string as
> necessary),
> and the expression, '123 + 456' in C# is not the same as '123 & 456' in
> VB.
> While I agree with you for the most part about the demise of C#, I
> found
> it
> pretty odd that you do not understand this distinction.
>
> Any C++ programmer who has a poorer understanding of reusability and
> generic
> design than someone who started on VB or C# should not be calling
> themselves
> C++ programmers, for any moron who even half-understands the STL should
> know
> far more about design patterns than anyone who thinks that the .NET
> framework
> library classes are the epitome of object-oriented design.
>
> - John
>
> "Kevin Spencer" wrote:
>
>> > For instance, take the string concatenation operator from VB, &,
>> > which
>> > automatically converts the left and right operands to strings and
>> > returns
>> > a
>> > combined string. Why is there no equivalent in C#?
>>
>> +
>>
>> The "ToString() part is simply strong data typing. Try turning Option
>> Strict
>> ON for a change.
>>
>> --
>> *sigh*,
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> What You Seek Is What You Get.
>>
>> "John" <Jo**@discussio ns.microsoft.co m> wrote in message
>> news:DA******** *************** ***********@mic rosoft.com...
>> >I personally think there are some really great things in VB.NET and
>> >it's
>> >a
>> > real crime how C# doesn't implement them. If you ask me, VB.NET is a
>> > better
>> > language for the rapid-application development needs of most .NET
>> > developers.
>> > I still code in C# over VB most of the time, but there are many
>> > things
>> > I
>> > envy
>> > in VB that I find lacking in C#.
>> >
>> > For instance, take the string concatenation operator from VB, &,
>> > which
>> > automatically converts the left and right operands to strings and
>> > returns
>> > a
>> > combined string. Why is there no equivalent in C#? Sure the '&'
>> > character
>> > would conflict with the bitwise and, but there are plenty of other
>> > symbols
>> > (ex - Lua's '..') that could be used in place, and it's absolutely
>> > silly
>> > that
>> > someone has to write:
>> >
>> > some_string_out put_function("B lah blah: " + x.ToString() + ", " +
>> > y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
>> >
>> > when they could have simply wrote something like:
>> >
>> > some_string_out put_function("B lah blah: " .. x .. ", " .. y .. "
>> > blah
>> > blah
>> > "
>> > .. z .. ", " .. q);
>> >
>> > There's nothing implicit going on here; the operator has
>> > clearly-defined
>> > behavior. It makes little sense to me why C# does not have things
>> > like
>> > this
>> > that would do nothing but make the code a little more readable and
>> > convenient
>> > to write.
>> >
>> > I can understand many of the reasons for C#'s more explicit nature
>> > like
>> > requiring explicit casts (safety) and explicitly indicating where
>> > you
>> > want
>> > to
>> > use dynamic binding (performance), but it's silly to deprive a
>> > language
>> > of
>> > something useful just because it isn't characteristic of the
>> > language
>> > from
>> > which it was modeled.
>>
>>
>>

[Kevin Spencer]

Aw, c'mon, Juan. While some of the replies in this thread have been useless,
I'm happy to note that perhaps it has stimulated some fruitful thought in
many, for the most part. That was the reason I started it. After all, as
Uncle Chutney sez, "Guns don't kill people, and people don't kill people
either. Ideas kill people." And of course, conversely, ideas can save
people! :)

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"Juan T. Llibre" <no***********@ nowhere.com> wrote in message
news:u5******** ******@tk2msftn gp13.phx.gbl...

Is there *any* way to make this thread demise ?

;-)

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:E0******** *************** ***********@mic rosoft.com...

Hi Kevin,

I'm sorry but that second part wasn't directed at you. I was in a hurry
and
crammed two messages into one after browsing through the boards - I
apologize
about the confusion. The second paragraph was in response to someone
writing
about how a .NET developer is more likely to understand object-oriented
design and reusability than a C++ programmer. I would have to disagree,
at
least based on my experience. That said, I know plenty of C++ programmers
who
shouldn't be calling themselves as such - the kind of C++ programmer that
thinks that templates are only useful for making collections of arbitrary
types, for instance.

As for the first part, syntactic differences aren't going to make or
break a
language, but between VB.NET and C#, that's among the most significant
differences between the two. What I would like to see is a hybrid between
the
two languages.

There are syntactical conveniences (like the string concatenation
operator)
in both languages would be nice to have at once. Global functions may not
be
suitable for a large-scale design, but the .NET languages are just as
suitable for rapid application development where globally accessible
functions can be quite suitable. Furthermore, a VB module provides the
ability to declare state variables with private modifiers, and can be
contained within a custom namespace, so as far as I'm concerned, a module
is
superior to a class with nothing but static functions, as the members of
such
a class cannot be brought into the global namespace.

Operator overloading is another example. It seems like a shame that VB
users
must cope without the syntactic convenience simply because operator
overloading isn't 'VB-esque'. Well, neither was inheritance and
polymorphism.
Polymorphism to a VB programmer prior to .NET was to use variants.

Syntax and small features like the addition of modules is pretty much all
there is to go by when judging the differences between .NET languages.

- John

"Kevin Spencer" wrote:

Hello John,

I understand generics fine thank you. Generics have their place. But you
missed my point. And I'm not going to waste anyone's time debating it.

And please point out to me where I called myself a C++ programmer. I am
simply a programmer. I can program in a half-dozen languages, one of
which
is C++, although I tend to avoid it. C# is an excellent RAD language,
and
when I need to go lower than C# I generally go to C. I can also program
in
VB.Net, but tend to avoid it because of the requirements of many of my
applications, which require things not available in VB.Net, like
pointers.

No need to get personal, eh?

--

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.
"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:EA******** *************** ***********@mic rosoft.com...
> I'm sorry Kevin,
>
> but Option Strict has no bearing on the string concatenation operator
> in
> VB,
> and the & operator has nothing to do with weak data typing. It is
> simply a
> syntactical convenience that has no implicit effects (it is explicitly
> stating that both operands are going to be converted to string as
> necessary),
> and the expression, '123 + 456' in C# is not the same as '123 & 456'
> in
> VB.
> While I agree with you for the most part about the demise of C#, I
> found
> it
> pretty odd that you do not understand this distinction.
>
> Any C++ programmer who has a poorer understanding of reusability and
> generic
> design than someone who started on VB or C# should not be calling
> themselves
> C++ programmers, for any moron who even half-understands the STL
> should
> know
> far more about design patterns than anyone who thinks that the .NET
> framework
> library classes are the epitome of object-oriented design.
>
> - John
>
> "Kevin Spencer" wrote:
>
>> > For instance, take the string concatenation operator from VB, &,
>> > which
>> > automatically converts the left and right operands to strings and
>> > returns
>> > a
>> > combined string. Why is there no equivalent in C#?
>>
>> +
>>
>> The "ToString() part is simply strong data typing. Try turning Option
>> Strict
>> ON for a change.
>>
>> --
>> *sigh*,
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> What You Seek Is What You Get.
>>
>> "John" <Jo**@discussio ns.microsoft.co m> wrote in message
>> news:DA******** *************** ***********@mic rosoft.com...
>> >I personally think there are some really great things in VB.NET and
>> >it's
>> >a
>> > real crime how C# doesn't implement them. If you ask me, VB.NET is
>> > a
>> > better
>> > language for the rapid-application development needs of most .NET
>> > developers.
>> > I still code in C# over VB most of the time, but there are many
>> > things
>> > I
>> > envy
>> > in VB that I find lacking in C#.
>> >
>> > For instance, take the string concatenation operator from VB, &,
>> > which
>> > automatically converts the left and right operands to strings and
>> > returns
>> > a
>> > combined string. Why is there no equivalent in C#? Sure the '&'
>> > character
>> > would conflict with the bitwise and, but there are plenty of other
>> > symbols
>> > (ex - Lua's '..') that could be used in place, and it's absolutely
>> > silly
>> > that
>> > someone has to write:
>> >
>> > some_string_out put_function("B lah blah: " + x.ToString() + ", " +
>> > y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
>> >
>> > when they could have simply wrote something like:
>> >
>> > some_string_out put_function("B lah blah: " .. x .. ", " .. y .. "
>> > blah
>> > blah
>> > "
>> > .. z .. ", " .. q);
>> >
>> > There's nothing implicit going on here; the operator has
>> > clearly-defined
>> > behavior. It makes little sense to me why C# does not have things
>> > like
>> > this
>> > that would do nothing but make the code a little more readable and
>> > convenient
>> > to write.
>> >
>> > I can understand many of the reasons for C#'s more explicit nature
>> > like
>> > requiring explicit casts (safety) and explicitly indicating where
>> > you
>> > want
>> > to
>> > use dynamic binding (performance), but it's silly to deprive a
>> > language
>> > of
>> > something useful just because it isn't characteristic of the
>> > language
>> > from
>> > which it was modeled.
>>
>>
>>

[Juan T. Llibre]

That's cool, Kevin.

It's just that it's a very long-running thread... ;-)

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:uh******** ******@TK2MSFTN GP14.phx.gbl...

Aw, c'mon, Juan. While some of the replies in this thread have been useless, I'm happy
to note that perhaps it has stimulated some fruitful thought in many, for the most part.
That was the reason I started it. After all, as Uncle Chutney sez, "Guns don't kill
people, and people don't kill people either. Ideas kill people." And of course,
conversely, ideas can save people! :)

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
What You Seek Is What You Get.

"Juan T. Llibre" <no***********@ nowhere.com> wrote in message
news:u5******** ******@tk2msftn gp13.phx.gbl...

Is there *any* way to make this thread demise ?

;-)

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:E0******** *************** ***********@mic rosoft.com...

Hi Kevin,

I'm sorry but that second part wasn't directed at you. I was in a hurry and
crammed two messages into one after browsing through the boards - I apologize
about the confusion. The second paragraph was in response to someone writing
about how a .NET developer is more likely to understand object-oriented
design and reusability than a C++ programmer. I would have to disagree, at
least based on my experience. That said, I know plenty of C++ programmers who
shouldn't be calling themselves as such - the kind of C++ programmer that
thinks that templates are only useful for making collections of arbitrary
types, for instance.

As for the first part, syntactic differences aren't going to make or break a
language, but between VB.NET and C#, that's among the most significant
differences between the two. What I would like to see is a hybrid between the
two languages.

There are syntactical conveniences (like the string concatenation operator)
in both languages would be nice to have at once. Global functions may not be
suitable for a large-scale design, but the .NET languages are just as
suitable for rapid application development where globally accessible
functions can be quite suitable. Furthermore, a VB module provides the
ability to declare state variables with private modifiers, and can be
contained within a custom namespace, so as far as I'm concerned, a module is
superior to a class with nothing but static functions, as the members of such
a class cannot be brought into the global namespace.

Operator overloading is another example. It seems like a shame that VB users
must cope without the syntactic convenience simply because operator
overloading isn't 'VB-esque'. Well, neither was inheritance and polymorphism.
Polymorphism to a VB programmer prior to .NET was to use variants.

Syntax and small features like the addition of modules is pretty much all
there is to go by when judging the differences between .NET languages.

- John

"Kevin Spencer" wrote:

Hello John,

I understand generics fine thank you. Generics have their place. But you
missed my point. And I'm not going to waste anyone's time debating it.

And please point out to me where I called myself a C++ programmer. I am
simply a programmer. I can program in a half-dozen languages, one of which
is C++, although I tend to avoid it. C# is an excellent RAD language, and
when I need to go lower than C# I generally go to C. I can also program in
VB.Net, but tend to avoid it because of the requirements of many of my
applications, which require things not available in VB.Net, like pointers.

No need to get personal, eh?

--

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.
"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:EA******** *************** ***********@mic rosoft.com...
> I'm sorry Kevin,
>
> but Option Strict has no bearing on the string concatenation operator in
> VB,
> and the & operator has nothing to do with weak data typing. It is simply a
> syntactical convenience that has no implicit effects (it is explicitly
> stating that both operands are going to be converted to string as
> necessary),
> and the expression, '123 + 456' in C# is not the same as '123 & 456' in
> VB.
> While I agree with you for the most part about the demise of C#, I found
> it
> pretty odd that you do not understand this distinction.
>
> Any C++ programmer who has a poorer understanding of reusability and
> generic
> design than someone who started on VB or C# should not be calling
> themselves
> C++ programmers, for any moron who even half-understands the STL should
> know
> far more about design patterns than anyone who thinks that the .NET
> framework
> library classes are the epitome of object-oriented design.
>
> - John
>
> "Kevin Spencer" wrote:
>
>> > For instance, take the string concatenation operator from VB, &, which
>> > automatically converts the left and right operands to strings and
>> > returns
>> > a
>> > combined string. Why is there no equivalent in C#?
>>
>> +
>>
>> The "ToString() part is simply strong data typing. Try turning Option
>> Strict
>> ON for a change.
>>
>> --
>> *sigh*,
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> What You Seek Is What You Get.
>>
>> "John" <Jo**@discussio ns.microsoft.co m> wrote in message
>> news:DA******** *************** ***********@mic rosoft.com...
>> >I personally think there are some really great things in VB.NET and it's
>> >a
>> > real crime how C# doesn't implement them. If you ask me, VB.NET is a
>> > better
>> > language for the rapid-application development needs of most .NET
>> > developers.
>> > I still code in C# over VB most of the time, but there are many things
>> > I
>> > envy
>> > in VB that I find lacking in C#.
>> >
>> > For instance, take the string concatenation operator from VB, &, which
>> > automatically converts the left and right operands to strings and
>> > returns
>> > a
>> > combined string. Why is there no equivalent in C#? Sure the '&'
>> > character
>> > would conflict with the bitwise and, but there are plenty of other
>> > symbols
>> > (ex - Lua's '..') that could be used in place, and it's absolutely
>> > silly
>> > that
>> > someone has to write:
>> >
>> > some_string_out put_function("B lah blah: " + x.ToString() + ", " +
>> > y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
>> >
>> > when they could have simply wrote something like:
>> >
>> > some_string_out put_function("B lah blah: " .. x .. ", " .. y .. " blah
>> > blah
>> > "
>> > .. z .. ", " .. q);
>> >
>> > There's nothing implicit going on here; the operator has
>> > clearly-defined
>> > behavior. It makes little sense to me why C# does not have things like
>> > this
>> > that would do nothing but make the code a little more readable and
>> > convenient
>> > to write.
>> >
>> > I can understand many of the reasons for C#'s more explicit nature like
>> > requiring explicit casts (safety) and explicitly indicating where you
>> > want
>> > to
>> > use dynamic binding (performance), but it's silly to deprive a language
>> > of
>> > something useful just because it isn't characteristic of the language
>> > from
>> > which it was modeled.
>>
>>
>>

[Steve C. Orr [MVP, MCSD]]

I'm sorry John, but I'd have to say Kevin is right. Option Strict does have
an effect on string concatenation in VB.

If Option Strict is off, and you write a line like this: '123 + 456' the IL
will be different than if Option Strict is on because of the type checking
IL code that must be generated.
However, the & operator always works on strings so no type checking is
needed and the IL is more efficient.
If Option Strict is turned on, they both generate the same IL because no
runtime type checking is needed.
It's all about how the compiler sees the code.

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://SteveOrr.net

"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:EA******** *************** ***********@mic rosoft.com...

I'm sorry Kevin,

but Option Strict has no bearing on the string concatenation operator in
VB,
and the & operator has nothing to do with weak data typing. It is simply a
syntactical convenience that has no implicit effects (it is explicitly
stating that both operands are going to be converted to string as
necessary),
and the expression, '123 + 456' in C# is not the same as '123 & 456' in
VB.
While I agree with you for the most part about the demise of C#, I found
it
pretty odd that you do not understand this distinction.

Any C++ programmer who has a poorer understanding of reusability and
generic
design than someone who started on VB or C# should not be calling
themselves
C++ programmers, for any moron who even half-understands the STL should
know
far more about design patterns than anyone who thinks that the .NET
framework
library classes are the epitome of object-oriented design.

- John

"Kevin Spencer" wrote:

> For instance, take the string concatenation operator from VB, &, which
> automatically converts the left and right operands to strings and
> returns
> a
> combined string. Why is there no equivalent in C#?

+

The "ToString() part is simply strong data typing. Try turning Option
Strict
ON for a change.

--
*sigh*,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:DA******** *************** ***********@mic rosoft.com...

>I personally think there are some really great things in VB.NET and it's
>a
> real crime how C# doesn't implement them. If you ask me, VB.NET is a
> better
> language for the rapid-application development needs of most .NET
> developers.
> I still code in C# over VB most of the time, but there are many things
> I
> envy
> in VB that I find lacking in C#.
>
> For instance, take the string concatenation operator from VB, &, which
> automatically converts the left and right operands to strings and
> returns
> a
> combined string. Why is there no equivalent in C#? Sure the '&'
> character
> would conflict with the bitwise and, but there are plenty of other
> symbols
> (ex - Lua's '..') that could be used in place, and it's absolutely
> silly
> that
> someone has to write:
>
> some_string_out put_function("B lah blah: " + x.ToString() + ", " +
> y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
>
> when they could have simply wrote something like:
>
> some_string_out put_function("B lah blah: " .. x .. ", " .. y .. " blah
> blah
> "
> .. z .. ", " .. q);
>
> There's nothing implicit going on here; the operator has
> clearly-defined
> behavior. It makes little sense to me why C# does not have things like
> this
> that would do nothing but make the code a little more readable and
> convenient
> to write.
>
> I can understand many of the reasons for C#'s more explicit nature like
> requiring explicit casts (safety) and explicitly indicating where you
> want
> to
> use dynamic binding (performance), but it's silly to deprive a language
> of
> something useful just because it isn't characteristic of the language
> from
> which it was modeled.

[John]

Hi Steve,

By the string concatentation operator, I was talking about '&', not '+', for
which Option Strict has no bearing on (not to mention that Option Strict is a
VB feature, which completely seems irrelevant to my point about having C#
include a real string concatenation operator - no I don't mean having '+'
allow implicit lexical conversions happening in the background). As I've
said, '123 & 456' is completely different from '123 + 456'. My point was that
there are syntactical conveniences such as this in VB.NET that would be
useful in C# and vice versa. A string concatentation operator would be useful
in C# (naturally you'd have to pick something other than '&' to avoid
conflicts with the bitwise and operator). A power operator would be useful in
C#. Operator overloading would be useful in VB. Modules would be useful in
C#. Increment/decrement operators would be useful in VB. Why did they include
+= and -= but not ++ and --? Seems odd.

Anyway, these are small things, but they're really the only significant
types of features that separate VB from C# in terms of language features.
While primarily a C# programmer, I do admire some of the language features in
VB, though when I move to VB, I end up missing some of the features in C#. I
could go on some more about the differences between the form designer code
and its synchronization with the IDE and the way you implement events and so
forth which are another thing worth looking at, but that's probably best
saved for another thread.

- John

"Steve C. Orr [MVP, MCSD]" wrote:

I'm sorry John, but I'd have to say Kevin is right. Option Strict does have
an effect on string concatenation in VB.

If Option Strict is off, and you write a line like this: '123 + 456' the IL
will be different than if Option Strict is on because of the type checking
IL code that must be generated.
However, the & operator always works on strings so no type checking is
needed and the IL is more efficient.
If Option Strict is turned on, they both generate the same IL because no
runtime type checking is needed.
It's all about how the compiler sees the code.

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://SteveOrr.net

"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:EA******** *************** ***********@mic rosoft.com...

I'm sorry Kevin,

but Option Strict has no bearing on the string concatenation operator in
VB,
and the & operator has nothing to do with weak data typing. It is simply a
syntactical convenience that has no implicit effects (it is explicitly
stating that both operands are going to be converted to string as
necessary),
and the expression, '123 + 456' in C# is not the same as '123 & 456' in
VB.
While I agree with you for the most part about the demise of C#, I found
it
pretty odd that you do not understand this distinction.

Any C++ programmer who has a poorer understanding of reusability and
generic
design than someone who started on VB or C# should not be calling
themselves
C++ programmers, for any moron who even half-understands the STL should
know
far more about design patterns than anyone who thinks that the .NET
framework
library classes are the epitome of object-oriented design.

- John

"Kevin Spencer" wrote:

> For instance, take the string concatenation operator from VB, &, which
> automatically converts the left and right operands to strings and
> returns
> a
> combined string. Why is there no equivalent in C#?

+

The "ToString() part is simply strong data typing. Try turning Option
Strict
ON for a change.

--
*sigh*,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"John" <Jo**@discussio ns.microsoft.co m> wrote in message
news:DA******** *************** ***********@mic rosoft.com...
>I personally think there are some really great things in VB.NET and it's
>a
> real crime how C# doesn't implement them. If you ask me, VB.NET is a
> better
> language for the rapid-application development needs of most .NET
> developers.
> I still code in C# over VB most of the time, but there are many things
> I
> envy
> in VB that I find lacking in C#.
>
> For instance, take the string concatenation operator from VB, &, which
> automatically converts the left and right operands to strings and
> returns
> a
> combined string. Why is there no equivalent in C#? Sure the '&'
> character
> would conflict with the bitwise and, but there are plenty of other
> symbols
> (ex - Lua's '..') that could be used in place, and it's absolutely
> silly
> that
> someone has to write:
>
> some_string_out put_function("B lah blah: " + x.ToString() + ", " +
> y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
>
> when they could have simply wrote something like:
>
> some_string_out put_function("B lah blah: " .. x .. ", " .. y .. " blah
> blah
> "
> .. z .. ", " .. q);
>
> There's nothing implicit going on here; the operator has
> clearly-defined
> behavior. It makes little sense to me why C# does not have things like
> this
> that would do nothing but make the code a little more readable and
> convenient
> to write.
>
> I can understand many of the reasons for C#'s more explicit nature like
> requiring explicit casts (safety) and explicitly indicating where you
> want
> to
> use dynamic binding (performance), but it's silly to deprive a language
> of
> something useful just because it isn't characteristic of the language
> from
> which it was modeled.