[LONG] C# too sharp for me

  • Thread starter Thread starter arthur.mcginty
  • Start date Start date
A

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
 
Not to be too harsh, but bye.

You should give Perl a shot. Its the fastest most wonderful language
for small little utility programs. It is a non-typed, procedural
easy-to-read, easy-to-write (if you know what you're doing) language.

give it a try. 'null' means something there.

http://www.activestate.com/
 
I would like to see those components with transaction support, with
object pooling support and an event mechanism that are built in ruby
and perl

Regards
 
Man I've grown tired with C#/.NET the last three days I spent trying to
put a NULL value in a database.
Click to expand...

IMHO, spending three days on a fairly simple procedure like that says
much more about you than the language.
C# initializes all uninitialized
properties to 0 (for numeric types) and didn't have until C# 2 any
concept of NULLs.
Click to expand...

The existence of value types is essentially a performance vs. ease of
use issue. As with most trade-offs in programming, the choice that was
made is a good choice for some problem domains and not the optimal
choice for other problem domains.

There's nothing wrong with disagreeing with the choices C# made here.
However, the tone of your post implies that you don't understand the
choices, or that you think the language designers didn't understand
them. Most C# programmers, and certainly the language designers, do
understand the choices made and why they were made, understand many
of the benefits and detriments of those choices, and prefer the C#
way of doing things.
I keep wondering how you guys built all these .NET
apps on the top of a database.
Click to expand...

You special-case the null type, and encapsulate the special cases..
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
Click to expand...

You did something wrong and instead of silently doing the wrong thing
the system loudly proclaimed the error. That's a Good Thing.
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:
Click to expand...

Python is a very nice language.
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)
Click to expand...

Properties aren't fields, they're syntactic sugar over functions. Most
C# developers understand this. I must admit, I distrust a design that
would want to pass a field by reference. However, once you do understand
that they're functions, it may be that a simple interface would do what
you want.
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>
Click to expand...

Closures are very, very powerful and very, very complex. That's another
natural trade-off.
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...
Click to expand...

Static vs. dynamic typing is a fascinating subject, and one that is the
subject of much debate. Intelligent forms of the debate run along the
lines of "I find the solution to x more elegant in language y because
of dynamic typing". Less intelligent forms of the debate run along the
lines of "I can't figure out how to do x in a statically-typed language,
I'd prefer to turn off compiler checks".
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.
Click to expand...

This is pretty interesting to me. Personally, the only time I've used
reflection in .Net is when I'm either explicitly doing some kind of
assembly/code analysis (FxCop-type stuff) or when dynamically loading
assemblies at runtime. For ordinary tasks, I could do without it.

OTOH, I do a lot of VB.Net work, and VB programmers are always asking me
about reflection because they've got a design that requires some type
of late binding. These designs aren't *necessarily* worse, but they
don't fit the toolset well, and IMHO the chosen toolset is going to
have to have some sort of effect on the design process.

OK, actually these designs are usually pretty bad. But I think that's
because programmers who can't adapt to new environments tend to be
bad code designers as well.
Well, I'm done... this morning I bought a copy of Programming Ruby!
Click to expand...

Ruby is a very nice language as well, and may fit your style a bit
better. However, being able to understand the C# way of doing things
will benefit you even as a Ruby developer, just as understanding the
Ruby way of doing things would benefit C# programmers. Accepting the
mindset of "I just couldn't understand the way language X does things"
is a dangerous mindset if you're truly interested in improving your
development skills.
 
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!
Click to expand...

To set a DB field to null just assign DBNull.Value to it!
Without any sort of workaround.
For the date, you cannot pretend that the managing of a date in a language
is the same in an arbitrary DB engine!
And it's a bad practice to assign values in a db field without knowing what
you are assigning.
Nullable types are all another sort of things and nothing to do with DB.

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.
Click to expand...

C# (and .Net in general) is really well structured OOP language.
If you try to force it to do things the way you want to, and not the way
them should be done, you can't pretend to get the goal.
You should think that something is prohibited, most probably it's because it
makes no sense, it is thinked/designed in a wrong way, it can be done in
another way.

Reflection is really usefull if you need to know the structure of a class
(i.e. I used it to serialize classes in a really "zero effords" way, against
the standard .Net serialization that need really much code).
Since I develop in .Net I don't remember a single case in wich I needed to
pass a parameter "by ref", because in OOP it is quite useless and
symptomatic.

Maybe you prefere Phyton or Ruby because their "compilers" do not complaint
about "dog food programming techniques", but all the things the compiler
can't filter are all yours. :)
 
Zanna said:
To set a DB field to null just assign DBNull.Value to it!
Without any sort of workaround.
Click to expand...

Yeah, rright! Try testing for NULLs when the runtime already assigned a
0 to your uninitialized property. You would probably write something
like:

if(User.Age == 0)
{
Parameter.Value == DBNull.Value;
}

the above code wouldn't make sense to me because Age can't be 0, but
can be null. Therefore you DO need a workaround here which could be
Nullable types or something else. And, worst, this is not a corner
case. As someone pointed out why would you want Nullable types if not
for dealing with databases or anyway cases (there are many in my
experience) where you could legally have a NULL value.

Think at an overload for a User constructor which is tailored for
processing data from a registration form and therefore only asks for
FirstName, LastName, Email and Password when the User table could
include far more details such as Age which you would want to leave NULL
at the time of the user registration but available for him/her to fill
in in his User Profile page. This is a very common scenario. The same
problem you could have with the DateOfBirth field in the db which you
would have to implement a workaround for, for the reason stated in my
first post.

Arthur
 
<[email protected]> ha scritto nel messaggio

Yeah, rright! Try testing for NULLs when the runtime already assigned a
0 to your uninitialized property. You would probably write something
like:

if(User.Age == 0)
{
Parameter.Value == DBNull.Value;
}
Click to expand...

You can't pretend that DB engine and programming languages manage data in
the same way!

If some languages do it it's a collateral effect, not a feature.

The same thing can appear in different scenario, such as the string: many DB
have different type of strings (SQL has text, ntext, char, varchar,
nvarchar...) with different max lengths.
It's sure you have to check the string length when you assign it.

What's wrong with

if(User.Age == 0)
{
Parameter.Value == DBNull.Value;
}

or

Parameter.Value = (User.Age == 0) ? DBNull.Value : User.Age

?
 
Yeah, rright! Try testing for NULLs when the runtime
already assigned a 0 to your uninitialized property.
Click to expand...

Gee, did you ever consider initialising your variables?

P.
 
jeremiah johnson said:
Not to be too harsh, but bye.

You should give Perl a shot. Its the fastest most wonderful language for
small little utility programs. It is a non-typed, procedural
easy-to-read, easy-to-write (if you know what you're doing) language.
Click to expand...

Haha that was a good one :)

Never seen any 'easy to read' perl script yet' okay maybe a 'hello world'.

Perl is not and has never been easy to read, and easy to write, hmm that
goes for every language you know.
MC68000 Assembler is very easy to write as well (for me)
give it a try. 'null' means something there.
Click to expand...

As it also does in C#.net.

DBNull is the value to send to the DB.

/Søren
 
Paul E Collins said:
Gee, did you ever consider initialising your variables?
Click to expand...

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.

Thus you are left doing the if(age == DEFAULT_AGE) thing.

In some ways there is an impedance mismatch between DB data and dotnet Data

Bill
 
Bill Butler said:
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.
Click to expand...

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

P.
 
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
 
I've described C# in the past as a simplified Java, which I think is fair
within the limits of a two word description.
Click to expand...

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 said:
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:
Click to expand...

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
Click to expand...

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).
 
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.
 
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.
 
Chance Hopkins said:
It's been a while, but I think I've done all these in Java:


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).
Click to expand...

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).
 
Bruce Wood said:
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.
Click to expand...

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
 
Jon Skeet said:
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.
Click to expand...

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(MethodImplOptions.Synchronized)]
void Foo()
{
}

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk
 
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.
 
Back
Top