[LONG] C# too sharp for me

[arthur.mcginty]

Man I've grown tired with C#/.NET the last three days I spent trying to
put a NULL value in a database. C# initializes all uninitialized
properties to 0 (for numeric types) and didn't have until C# 2 any
concept of NULLs. I keep wondering how you guys built all these .NET
apps on the top of a database. And guess what? If you fail to
initialize a DateTime (maybe because you just don't want to touch it!)
you get it infact initialized to {01/01/0001 0.00.00} but of course
when you try to put it in a SQLServer db you get this error in return:

SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and
12/31/9999 11:59:59 PM

Now in C# 2 you have the option to choose to declare something as a
Nullable... but it's just a hack (even if builtin the language) and
using Nullables prevents you from doing all sort of things, and strings
cannot be declared as Nullable but at least they are initialized
correctly if you don't touch them!

I understood just yesterday what's all the buzz around dynamic
languages since, even being a Python amateur, I still didn't get it
fully: I wanted to pass a property like Foo.Number as a parameter to a
method and I would have to use a delegate or an anonymous method
(another new feature... and, yeah, you cannot pass a property by ref
http://msdn2.microsoft.com/en-us/library/w86s7x04) which they tell you
that you can use it everywhere you would use a delegate but no, not
there, not where you need it the most or maybe with odd consequences.
Quoting from Jesse Liberty "Visual C# 2005 a Developer's Notebook"
published by O'Reilly:

<quote>
....what happens if I reference local variables in my anonymous block?
Good question. This can cause quite a bit of confusion and is a natural
trap to fall into, especially if you don't fully understand the
consequences.
C# allows local variables to be captured in the scope of the
anonymous code block, and then they are accessed when the code block
is executed. This can create some odd side effects, such as keeping
objects around after they might otherwise have been collected.
</quote>

Ok properties are not fields/variables but pardon me if I was looking
to implement yet another workaround to my problem.

And you now what: how about not knowing the type of a property you pass
to this function, well, you gotta use a generic (another new feature of
C#2)... and all this for doing somethinig that in Python and Ruby is
not even a problem... ah and did I tell you the best thing? ADO.NET
which is your only chance to talk to a database in the .NET managed
world doesn't support Nullable types: I found maybe by chance or
because, after all, god still loves me, a workaround since as Microsoft
confirmed there are no solutions, only workarounds if you want to pass
a NULL value to a SqlParameter. BTW I thought that using SqlClient you
would just bypass ADO.NET and talk directly to SqlServer if you didn't
mind tying you hands and foots to SqlServer. A guy had to write
Nullable types himself to use NULL values in C# v. 1
(http://nullabletypes.sourceforge.net/)

The only kinda dynamic feature of C# is Reflection which is another
way to say introspection which is one of those features I thought I
would never need even to learn in the C# "we give you everything out
of-the-box world" but actually comes handy in many places due to the
_limitations_ of the .NET platform.

Well, I'm done... this morning I bought a copy of Programming Ruby!

Arthur

[Paul E Collins]

"Bill Butler" <qw****@asdf.co m> wrote:

Stop for a second and listen to his point, because it is valid.
If AGE is an optional DB field, then you may not have a value
to initialize it with. You can pick some DEFAULT age to stand
for the case of no age entered, but that is EXACTLY the age
== 0 thing.

True, but if that's a problem for his SQL Server app, he should be
using System.Data.Sql Types.

P.

[eye5600]

Mr. McGinty,

As is often the case with computer snafu's, you are confusing one thing with
another, an easy type of mistake to make when using one thing to display
another thing which is a copy of a third, i.e. using a DateTimePicker to
display a value in your program which is a copy of a database value. You had
the misfortune of using the DateTimePicker which is a) ideosyncratic, and b)
flawed. The ideosyncracy is that it does not handle null values, so while it
is easy to insert a null into a database, it is impossible to use a stock
version of the DateTimePicker to do so. The DateTimePicker also misbehaves if
there is a null in your datatable; perhaps even if the field is merely
nullable.

I've described C# in the past as a simplified Java, which I think is fair
within the limits of a two word description. Many of the differences between
C# and, say, C++ are designed to avoid common mistakes made by non-experts.
This includes requiring variable declarations, initializing all variables,
not using (explicit) pointers, etc.

eye

[Jon Skeet [C# MVP]]

eye5600 <ey*****@discus sions.microsoft .com> wrote:

<snip>

I've described C# in the past as a simplified Java, which I think is fair
within the limits of a two word description.

In what way is C# *simpler* than Java? The way I see it, it's more
complicated than Java, as a language. If we consider Java 1.4 vs C# 1.0
(which is roughly fair, as would be Java 1.5 vs C# 2.0) then:

Things in Java but not in C#:
1) Inner/nested classes
2) Checked exceptions
3) Synchronized methods

Things in C# but not Java:
1) Properties
2) Events
3) Delegates
4) Explicit interface implementation
5) Marking of methods as override/new
6) Attributes
7) Enums
8) User-defined value types
9) Indexers
10) Pre-processor directives
11) Boxing and unboxing
12) out/ref parameters
13) Parameter arrays
14) Operator overloading
15) The "as" operator
16) Switching on strings
17) foreach
18) checked/unchecked contexts
19) Unsafe code/pointers
20) The "using" statement

I may well have missed things on both lists, but I don't think I've
missed nearly enough to make C# a "simplified " Java.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Chance Hopkins]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

eye5600 <ey*****@discus sions.microsoft .com> wrote:

<snip>

I've described C# in the past as a simplified Java, which I think is fair
within the limits of a two word description.
In what way is C# *simpler* than Java? The way I see it, it's more
complicated than Java, as a language. If we consider Java 1.4 vs C# 1.0
(which is roughly fair, as would be Java 1.5 vs C# 2.0) then:

Things in Java but not in C#:
1) Inner/nested classes
2) Checked exceptions
3) Synchronized methods

Things in C# but not Java:

It's been a while, but I think I've done all these in Java:
1) Properties
2) Events
3) Delegates
4) Explicit interface implementation
5) Marking of methods as override/new
7) Enums
8) User-defined value types
9) Indexers
12) out/ref parameters
16) Switching on strings
I actually have a couple classes I can copy into J++,J# or c# and recompile
with almost no changes (none if I recall correctly).


I may well have missed things on both lists, but I don't think I've
missed nearly enough to make C# a "simplified " Java.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[kevin cline]

Unfortunately, C# mostly gives the appearance of preventing mistakes.
It's still possible to leak memory, access disposed objects, lose
resources like file handles, but unlike C++ it's harder to spot the
offending code.

[Bruce Wood]

Entirely true: in C++ it's much easier to spot the offending code,
because it's all over the frickin' place. Memory leaks are the #1
bugbear of C++ programming. While you are correct that it's possible to
effectively leak memory in a C# application, it's not nearly as common.

[Jon Skeet [C# MVP]]

Chance Hopkins <ch************ @hotmail.com> wrote:

Things in Java but not in C#:
1) Inner/nested classes
2) Checked exceptions
3) Synchronized methods

Things in C# but not Java:

It's been a while, but I think I've done all these in Java:

1) Properties
2) Events
3) Delegates
4) Explicit interface implementation
5) Marking of methods as override/new
7) Enums
8) User-defined value types
9) Indexers
12) out/ref parameters
16) Switching on strings

I actually have a couple classes I can copy into J++,J# or c# and recompile
with almost no changes (none if I recall correctly).

Trust me, you haven't. Java 1.5 has enums (which you can switch on),
the @Override attribute (which isn't mandatory, and there's no
"opposite" to shadow a virtuial method). It doesn't have any of the
rest (in the language - there are method naming conventions for
properties, but that's not part of the language itself).

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[joe]

"Bruce Wood" <br*******@cana da.com> writes:

Entirely true: in C++ it's much easier to spot the offending code,
because it's all over the frickin' place. Memory leaks are the #1
bugbear of C++ programming. While you are correct that it's possible
to effectively leak memory in a C# application, it's not nearly as
common.

What's the source of these comments? It might have been true that C++
was more prone to memory leaks than C# since it first came out
(modulo when C# first came out). The C++ standard was a moving target
for some years, so many programmers continued to use C++ as a "better
C", which meant doing their own allocations of C strings, using stdio
functions that should have been at least deprecated by now, etc.

Current compilers which implement the standard C++ library are much
less prone to memory problems, because the standard library takes care
or most allocations that are needed for a "typical" app (whatever that
is). If programmers continue to write C idioms for memory access
and get them wrong, that's hardly the language's fault.

C# does have advantages other than the fact that it came along after
most of the problems you mention were effectively solved. I'm still
learning it, so I might regret my comments here later, but at the
moment it strikes me that the .NET stuff is pretty well thought out
and easy to use. I don't know how much of that is due to the fact that
it's so much like Java, but I don't care at the moment, I'm just
trying to learn it.

Joe
--
Gort, klatu barada nikto

[Richard Blewett [DevelopMentor]]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

eye5600 <ey*****@discus sions.microsoft .com> wrote:

<snip>

I've described C# in the past as a simplified Java, which I think is fair
within the limits of a two word description.

In what way is C# *simpler* than Java? The way I see it, it's more
complicated than Java, as a language. If we consider Java 1.4 vs C# 1.0
(which is roughly fair, as would be Java 1.5 vs C# 2.0) then:

Things in Java but not in C#:
1) Inner/nested classes
2) Checked exceptions
3) Synchronized methods

Things in C# but not Java:
1) Properties
2) Events
3) Delegates
4) Explicit interface implementation
5) Marking of methods as override/new
6) Attributes
7) Enums
8) User-defined value types
9) Indexers
10) Pre-processor directives
11) Boxing and unboxing
12) out/ref parameters
13) Parameter arrays
14) Operator overloading
15) The "as" operator
16) Switching on strings
17) foreach
18) checked/unchecked contexts
19) Unsafe code/pointers
20) The "using" statement

I may well have missed things on both lists, but I don't think I've
missed nearly enough to make C# a "simplified " Java.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

You can create synchonrized methods in C#. I wouldn't recommend it as it
tends too lead to very coarse grained locking, but you can
[MethodImpl(Meth odImplOptions.S ynchronized)]
void Foo()
{
}

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

[SerpentMage]

You can shoot yourself in the foot whatever language you choose. I can
leak memory in Java very easily, just like I can leak memory in C#.

However, getting to the question of the user in the original post, was
that not the reason why Nullable types in .NET 2.0 were introduced?

I had a discussion once with one of the Gang of Four authors on C# and
Java. And he said to me its the eternal debate between features vs
libraries. Java is a simple language, but its complexity are the
libraries (eg Swing). Whereas C# as a language is more complex, but
the libraries are simpler (sometimes too simpleminded IMHO). Then as
we kept discussing things the answer was that there is no answer. Just
like how some people like coffee and other people like tea! Yet both
give you a jolt from the caffein.