469,646 Members | 1,567 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,646 developers. It's quick & easy.

[LONG] C# too sharp for me

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

Nov 17 '05 #1
23 2112
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/

ar************@gmail.com wrote:
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

Nov 17 '05 #2
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

Nov 17 '05 #3
On 2005-09-24, ar************@gmail.com <ar************@gmail.com> 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

Nov 17 '05 #4
<ar************@gmail.com> ha scritto nel messaggio
news:11**********************@f14g2000cwb.googlegr oups.com...
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!
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.


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. :)
--
- .Net Reporting tool http://www.neodatatype.net
Nov 17 '05 #5
Zanna wrote:
To set a DB field to null just assign DBNull.Value to it!
Without any sort of workaround.


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

Nov 17 '05 #6
<ar************@gmail.com> ha scritto nel messaggio
news:11*********************@g47g2000cwa.googlegro ups.com...

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;
}


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

?

--
..Net Reporting tool: http://www.neodatatype.net
Nov 17 '05 #7
<ar************@gmail.com> wrote:
To set a DB field to null just assign DBNull.Value to it!
Without any sort of workaround.


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


Gee, did you ever consider initialising your variables?

P.
Nov 17 '05 #8

"jeremiah johnson" <na*******@gmail.com> wrote in message
news:eY**************@TK2MSFTNGP09.phx.gbl...
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.
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.


As it also does in C#.net.

DBNull is the value to send to the DB.

/Søren
Nov 17 '05 #9

"Paul E Collins" <fi******************@CL4.org> wrote in message
news:dh**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
<ar************@gmail.com> wrote:
> To set a DB field to null just assign DBNull.Value to it!
> Without any sort of workaround.


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


Gee, did you ever consider initialising your variables?


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
Nov 17 '05 #10
"Bill Butler" <qw****@asdf.com> 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.SqlTypes.

P.
Nov 17 '05 #11
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
Nov 17 '05 #12
eye5600 <ey*****@discussions.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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #13

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
eye5600 <ey*****@discussions.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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Nov 17 '05 #14
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.

Nov 17 '05 #15
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.

Nov 17 '05 #16
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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #17
joe
"Bruce Wood" <br*******@canada.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
Nov 17 '05 #18
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
eye5600 <ey*****@discussions.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.com>
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(MethodImplOptions.Synchronized)]
void Foo()
{
}

Regards

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


Nov 17 '05 #19
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.

Nov 17 '05 #20
<"Richard Blewett [DevelopMentor]" <richard at nospam dotnetconsult
dot co dot uk>> wrote:
You can create synchonrized methods in C#.
Yes - it's not part of the actual language though, which was what I was
comparing. I should have made that clearer though.
I wouldn't recommend it as it
tends too lead to very coarse grained locking


Likewise.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #21
> 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:


I not going to fight a Holy War, although I'm amused to have drawn such a
sharp response. By simpler, I mean easier to learn and use. Obviously, some
added features make a language easier, some have potential to make it harder.
(Is a car with an automatic choke simpler or more complicated than one with a
manual choke?) There is no point is differentiating between complexity in the
language per se and libraries; they are both in the mix. A lot of the
complication in Java is due to the desire for universality over machines and
cultures. So far, I've seen nothing in C# to rival the mysteries of
GridBagLayout, or LayoutManagers, in general. Nor has C# forced me to the
extremity shown below for formatting anumber. And I heard of a Java program
that was found to be spending 60% of its time creating new Gregorian
calendars....

As noted by someone else, you basically cheated on your list. Several of the
entries (properties, attributes, events,...) are things that are also easily
done in Java, perhaps under a different name.

I do find that delegates and events in C# are harder to understand (so far)
than the Listeners in Java. I may catch on eventually. I am amazed that there
isn't a properly defined DateBox control in C# (whine, whine, whine) that
implements a Windows standard date entry. (Data entry people HATE the
DateTimePicker.)

eye

class bcFormat{
DecimalFormat DF0d;
DecimalFormat DF1d;
DecimalFormat DF2d;
DecimalFormat DF3d;
DecimalFormat DF4d;

public bcFormat(){
Locale l = new Locale("en","US");
//Locale l = new Locale("fr","FR");
DecimalFormatSymbols dfs = new DecimalFormatSymbols(l);
DF0d = new DecimalFormat("###,###,###",dfs);
DF1d = new DecimalFormat("###,###,###.0",dfs);
DF2d = new DecimalFormat("###,###,###.00",dfs);
DF3d = new DecimalFormat("###,###,###.000",dfs);
DF4d = new DecimalFormat("###,###,###.0000",dfs);
}// end constructor
}// enc bcFormat

Nov 17 '05 #22

eye5600 wrote:
So far, I've seen nothing in C# to rival the mysteries of
GridBagLayout, or LayoutManagers, in general.


There's noting in Windows Forms with the functionality of GridBadLayout
either. If you want dynamic layouts you have to roll your own.

Nov 17 '05 #23
eye5600 <ey*****@discussions.microsoft.com> wrote:
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:
I not going to fight a Holy War, although I'm amused to have drawn such a
sharp response.


I wouldn't say my response was sharp - just amazed, given how easy it
was for me to compile those two lists.
By simpler, I mean easier to learn and use. Obviously, some
added features make a language easier, some have potential to make it harder.
(Is a car with an automatic choke simpler or more complicated than one with a
manual choke?) There is no point is differentiating between complexity in the
language per se and libraries; they are both in the mix.
I'm afraid I disagree with pretty much all of this. To me, there's more
to learn in C#, therefore it's a less simple language. It's certainly a
joy to use, but I don't think it's simpler.

There's *definitely* a distinction to be drawn between language and
libraries - especially as in both cases multiple languages target the
same libraries. The design of the languages can be discussed entirely
separately from the design of the libraries.
A lot of the complication in Java is due to the desire for
universality over machines and cultures.
I'm not sure I'd agree with that. It has better support for
internationalisation in some respects, and worse in others. Its
encoding support isn't nearly as well thought out as .NET's, but its
date/time handling, while more complex than .NET's (partly due to
having about three goes at it) is definitely better.

I really can't say I find Java complicated - and as a language, I still
believe it to be simpler than C# (pre-1.5, at least; generics bring a
whole different ball-game in there).
So far, I've seen nothing in C# to rival the mysteries of
GridBagLayout, or LayoutManagers, in general.
No, more's the pity. Fortunately, flexible layout management (which is
sorely missing, or at least underplayed)
Nor has C# forced me to the
extremity shown below for formatting anumber.
I can't say I've often had to use five different number formats varying
only by precision in the same program, personally...
And I heard of a Java program that was found to be spending 60% of
its time creating new Gregorian calendars....
Then someone wasn't being careful enough - it's very easy to avoid
that, in almost all situations. It's easy to fall into performance
traps on both platforms.
As noted by someone else, you basically cheated on your list. Several of the
entries (properties, attributes, events,...) are things that are also easily
done in Java, perhaps under a different name.
They're in no way part of the language though. Just because the pattern
can still be followed doesn't make them part of the language. Does C
have namespaces? No. You can follow a pattern of prefixing all function
calls with a namespace, but that's not the same as the language having
a namespace feature.
I do find that delegates and events in C# are harder to understand (so far)
than the Listeners in Java.
Interesting - I find exactly the reverse is true. I love C# events and
delegates. The biggest thing I miss in Java is the "using" statement,
to be honest. I very rarely need explicit try/finally blocks in C# :)
I may catch on eventually. I am amazed that there
isn't a properly defined DateBox control in C# (whine, whine, whine) that
implements a Windows standard date entry. (Data entry people HATE the
DateTimePicker.)


Not being a data entry person, it hasn't bothered me much. Most of what
I miss when writing C# is the excellence of Eclipse in terms of
navigation, refactoring and unit testing. Some of that will change,
with any luck with VS 2005. What won't change (at least for a while) is
C#'s lack of an equivalent to Java 1.5's enums which, while
occasionally a little rough around the edges, are incredibly handy.

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

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by application | last post: by
12 posts views Thread by __frank__ | last post: by
2 posts views Thread by HishHish | last post: by
5 posts views Thread by Alberto | last post: by
69 posts views Thread by fieldfallow | last post: by
22 posts views Thread by Vijay | last post: by
20 posts views Thread by windandwaves | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.