reasons to hate C#

P

PJ6

I want to rant, but I'm too busy at the moment.

Who else hates working in C#? What's your biggest pet peeve?

Paul
 
G

Guest

Who else hates working in C#? What's your biggest pet peeve?

The semicolon ... but that's a personal preference. C# developers probably
have a lot of things that they hate about VB too ;-)
 
S

sdbillsfan

People who hate C# :p

Mythran

I hate how it's so straightforward with its readability and use of
standard object oriented keywords and syntax. I got tired of having to
obfuscate my C# code before deploying so I just started writing in VB
instead.
 
R

rowe_newsgroups

I hate how it's so straightforward with its readability and use of
standard object oriented keywords and syntax. I got tired of having to
obfuscate my C# code before deploying so I just started writing in VB
instead.

:)

Thanks,

Seth Rowe
 
C

Cor Ligthert [MVP]

:)

Cor


I hate how it's so straightforward with its readability and use of
standard object oriented keywords and syntax. I got tired of having to
obfuscate my C# code before deploying so I just started writing in VB
instead.
 
P

PJ6

I hate how it's so straightforward with its readability and use of
standard object oriented keywords and syntax. I got tired of having to
obfuscate my C# code before deploying so I just started writing in VB
instead.

Hmmm. Whose standard would that be? How many languages follow it?
 
M

Mike Hofer

Hmmm. Whose standard would that be? How many languages follow it?

You know, it's funny. I code in VB.NET every day. I love the language.
But I have to say, I love C# as well. Why? Because these guys are
right. It's a fantastic implementation of standard object-oriented
principles. It's OOP on steroids.

Sure, it lacks some of the high-gloss enamel that VB has. But let's be
honest. The high gloss enamel native to VB.NET is intrinsic to Visual
Basic; in its original design, VB.NET was a lot like C#, but certain
decisions were made to placate VB6 developers who couldn't handle
things like declaring arrays with the number of elements instead of
the upper boundary. VB.NET lacks support for operator overloading,
unsigned types (but hey, that's not supported by the CTS, so ixnay on
atthay) and a few other things.

But in the end, you can develop applications with BOTH of them, and
they both get compiled down to IL. They both use the same
Framework(s). It's just a question of syntax. So you have to type a
semicolon. Big whoop-ti-doo.

Use the language that makes you most productive or that your boss
requires. If you can't change it, don't waste your breath or frazzled
nerves complaining about it. It doesn't change anything. Focus your
attention on solving the coding issues, and move on. You're typically
not solving coding problem with a language in .NET; you're typically
solving it with the Framework.

Language wars will rage on for as long as there will be languages and
there are zealots to fuel them. We'll argue back and forth about
things that don't really mean anything, and in the end, the work will
still get done, regardless of the language that's used to do it.

So, in the end, the argument is moot. As Officer Barbrady says, "Move
along people. Nothing to see here."

Move
 
H

Herfried K. Wagner [MVP]

Mike Hofer said:
You know, it's funny. I code in VB.NET every day. I love the language.
But I have to say, I love C# as well. Why? Because these guys are
right. It's a fantastic implementation of standard object-oriented
principles. It's OOP on steroids.

I have to disagree. I consider implicit interface wireing based on equal
member names dangerous and suboptimal.
Sure, it lacks some of the high-gloss enamel that VB has. But let's be
honest. The high gloss enamel native to VB.NET is intrinsic to Visual
Basic; in its original design, VB.NET was a lot like C#, but certain
decisions were made to placate VB6 developers who couldn't handle
things like declaring arrays with the number of elements instead of
the upper boundary.

What's the problem with that?
VB.NET lacks support for operator overloading,
unsigned types (but hey, that's not supported by the CTS, so ixnay on
atthay) and a few other things.

That's wrong. VB 2005 supports operator overloading and unsigned types and
a few other things.
 
M

Mike Hofer

I have to disagree. I consider implicit interface wireing based on equal
member names dangerous and suboptimal.

Visual Basic .NET doesn't use IMPLICIT interface wiring. It uses
EXPLICIT interface wiring through the use of the Handles clause. For
example:

Public Sub SomeRadicallyDifferentFunctionName(ByVal sender As Object,
ByVal e As EventArgs) _
Handles MyButton.Click
End Sub

It's merely a convention to use similarly named functions these days.

What's the problem with that?

There ISN'T anything wrong with that. I don't have anything against VB
or C#. The whole point of my post was that it doesn't make a
difference one way or another.

That's wrong. VB 2005 supports operator overloading and unsigned types and
a few other things.

You got me there. I, unfortunately, am still working in .NET 1.1 (we
haven't embraced VS 2005 or .NET 2.0, thanks to the lack of what the 3-
letter job titles are calling "a compelling need"), so I often forget
to spell that out in my posts. Thanks for reminding me.

I should have made that clear. But my point that the CTS doesn't
support unsigned types remains valid...at least, last time I checked.
They were considered nonportable. And that was why the VB language
designers chose not to support them. I don't believe that the CTS has
been revised to include unsigned types.

Again, I should have made that clear, and for that, I apologize.

Mike
 
H

Herfried K. Wagner [MVP]

Mike,

Mike Hofer said:
Visual Basic .NET doesn't use IMPLICIT interface wiring. It uses
EXPLICIT interface wiring through the use of the Handles clause. For
example:

I was referring to C# because I considered the last sentences after the
rhetorical question in your statement to target C#. With "interface wiring"
I meant implementation of interfaces and connecting methods to the
interfaces' members.
You got me there. I, unfortunately, am still working in .NET 1.1 (we
haven't embraced VS 2005 or .NET 2.0, thanks to the lack of what the 3-
letter job titles are calling "a compelling need"), so I often forget
to spell that out in my posts. Thanks for reminding me.

No problem :).
Again, I should have made that clear, and for that, I apologize.

Again, no problem and no need to apologize.
 
N

Nitin Sharma

Reason for hate to C# can be

Case sensitive language
semicolns
etc....
but i don't think so that anyone can hate c# due to that and in fact
these are not the reasons to hate c#.

So here we go.......

Nitin Sharma NXS
 
N

Nitin Sharma

Reason for hate to C# can be

Case sensitive language
semicolns
etc....
but i don't think so that anyone can hate c# due to that and in fact
these are not the reasons to hate c#.

So here we go.......

Nitin Sharma NXS
 
?

=?ISO-8859-1?Q?G=F6ran_Andersson?=

Mike said:
The high gloss enamel native to VB.NET is intrinsic to Visual
Basic; in its original design, VB.NET was a lot like C#, but certain
decisions were made to placate VB6 developers who couldn't handle
things like declaring arrays with the number of elements instead of
the upper boundary.

Interrestingly enough, some VB programmers can't handle declaring arrays
with the upper boundary, so they consistently dimension arrays with one
item more than they will use.

As this rarely causes any errors, they can continue doing so for a long
time without realising it.

:)
 
M

Mike Hofer

Interrestingly enough, some VB programmers can't handle declaring arrays
with the upper boundary, so they consistently dimension arrays with one
item more than they will use.

As this rarely causes any errors, they can continue doing so for a long
time without realising it.

:)

Heh

I suppose, in a fairly innocuous way, that's a memory leak. Depending
on whether or not it's cleaned up appropriately. Thank the powers that
be for garbage collection.

I shouldn't have said "can't handle." That was needlessly harsh, and
unduly inappropriate on my part. What I was trying to get at was that
the vast majority of languages declare arrays using the number of
elements in them, not by their boundaries. VB is fairly enigmatic that
way. I believe (and this is purely opinion here, so be forewarned)
that it's merely the volume of ardent VB users that made the argument
FOR a upper-bound based declarations compelling.

I'd have preferred the change to "standard" means of array
declarations; but I understand that it would have represented a shift
in thinking, and that it might have produced a lot of defects. It
would have also complicated porting of existing software, and can
empathize with those who didn't want to see it changed. Still, it
would have been nice. But I am not the totality of the universe; it
certainly doesn't revolve around me and my preferences, so I can live
without it.
 
R

Rad [Visual C# MVP]

I want to rant, but I'm too busy at the moment.

Who else hates working in C#? What's your biggest pet peeve?

Paul

If I had a dollar ever time I ran into this debate! After reading thousands
of arguments of why VB is better and thousands others why c# is better I
came to the realization that it is like arguing that calculus is better
than algebra, or that the Beatles are better than the Rolling Stones.

At the end of the day, as long as you get what you want done with your
choice, *it doesn't matter!* Different strokes for different folks
 
B

Branco Medeiros

Göran Andersson wrote:
Interrestingly enough, some VB programmers can't handle declaring arrays
with the upper boundary, so they consistently dimension arrays with one
item more than they will use.

As this rarely causes any errors, they can continue doing so for a long
time without realising it.

:)
<snip>

What amuses me the most is the fact that the vast majority of C/C++
coders never managed to use pointers correctly... Differently from
VB'ers misuse of the upper bound dimmension, that became the source of
so many bugs that they had to create not one but two, mind you, two
new languages (without the pesky pointers) to remedy the situation...

=)))

Branco.
 
J

james

Rad said:
On Thu, 15 Mar 2007 10:19:08 -0400, PJ6 wrote:
If I had a dollar ever time I ran into this debate! After reading
thousands
of arguments of why VB is better and thousands others why c# is better I
came to the realization that it is like arguing that calculus is better
than algebra, or that the Beatles are better than the Rolling Stones.

At the end of the day, as long as you get what you want done with your
choice, *it doesn't matter!* Different strokes for different folks

Best answer of all !
james
 
C

Cor Ligthert [MVP]

Best answer of all !
In my opinion can it not beat this one. The one from Rad I have seen already
in others ways. For me the one bellow from X is unique (if you understand
it) althouhg I don't agree with it..

I hate how it's so straightforward with its readability and use of
standard object oriented keywords and syntax. I got tired of having to
obfuscate my C# code before deploying so I just started writing in VB
instead
 
R

RobinS

Cor Ligthert said:
In my opinion can it not beat this one. The one from Rad I have seen
already in others ways. For me the one bellow from X is unique (if you
understand it) althouhg I don't agree with it..

I hate how it's so straightforward with its readability and use of
standard object oriented keywords and syntax. I got tired of having to
obfuscate my C# code before deploying so I just started writing in VB
instead

Cor,

I thought he was being sarcastic when he said that, since he stated it
backwards.

I'm having to do some C# stuff now, and the case-sensitive
not-fixing-my-typing thing is driving me loco. Not that it's a long trip,
mind you. (The C# people would argue that it is forcing me to be more
precise. :p)

Robin S.
 

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

Top