The Demise of C#

K

Kevin Spencer

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

Guest

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
 
G

Guest

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
 
K

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

Guest

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
 
K

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

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

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

Guest

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
 
K

Kevin Spencer

Those are not available in VB.Net. The closest you can get to a pointer in
VB.Net is a delegate.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Paranoia is just a state of mind.
 
K

Kevin Spencer

I have to amend my remarks: There are several other ways to obtain
"pointers" in VB.Net, but again, you don't get the raw functionality of a
true pointer using any of them. The most common is the IntPtr, and there are
also some undocumented versions of a couple of the types you mentioned. You
can read about them here:

http://www.codeproject.com/vb/net/Marshal.asp

Again, though, I would stress that you cannot do with them what you can do
with unmanaged pointers, which is accessing and manipulating memory
directly.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Paranoia is just a state of mind.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top