Re: [LONG] C# too sharp for me
- From: david <david@xxxxxxxxxxxxxxxx>
- Date: Sat, 24 Sep 2005 08:23:34 -0700
On 2005-09-24, arthur.mcginty@xxxxxxxxx <arthur.mcginty@xxxxxxxxx> wrote:
> Man I've grown tired with C#/.NET the last three days I spent trying to
> put a NULL value in a database.
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.
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.
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
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:
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)
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>
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...
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.
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!
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.
>
> Arthur
>
.
- References:
- [LONG] C# too sharp for me
- From: arthur.mcginty@xxxxxxxxx
- [LONG] C# too sharp for me
- Prev by Date: Re: DataSet.Table Question
- Next by Date: Re: Changing case using Visual Studio
- Previous by thread: [LONG] C# too sharp for me
- Next by thread: Re: [LONG] C# too sharp for me
- Index(es):
Relevant Pages
|
