Yigal Chripun wrote:
> David Brown wrote:
>> On Sun, Oct 21, 2007 at 01:25:55AM +0200, Yigal Chripun wrote:
>>
>>> 1) it's a poor imitation of Java. Java may have its cons but at least they try to be consistent with the design of the language - every new feature goes through a JSR. this may make the language to evolve in a slower rate though. compare that to the MS approach of including the kitchen sink. the language has many features meant for corner cases which makes it bloated.
>>> on the other hand other features were discarded like the covariance of return types, which is heavily used in Java land.
>>
>> C# fixes many problems with Java, at least in my opinion.  C# 2.0 adds
>> generics which cover many of the cases of templates.  It has full support
>> of the VM, so executes efficiently and safely.
>>
> 
> What exactly is broken in Java that C# does better, in your opinion?
> from what i see, anything that needs fixing is being fixed within the Java community and I personally trust their decisions a lot more than MS. Adding properties to a languages isn't considered "fixing" it, it's just a convenience feature. On the other hand, removing covariance of return types is a very big mistake. there are others of course, but that one really pissed me off.
> 

C# has lexical closures, operator overloading, structs, and nullable types. I don't feel as dismissive of properties as you do because, in conjunction with operator overloading, they lead to a much cleaner (IMO) code look and feel than Java. Instead of writing

    foo.setAmount(foo.getAmount().add(5));

you get the much cleaner

    foo.Amount = foo.Amount + 5;

which you are in fact allowed to rewrite to

    foo.Amount += 5;

Another nice feature is C#'s System.Reflection.Emit package, which allows you to compile new code at runtime -- a useful optimization which can be used, for instance, for regexes.

    -- Reiner

I don't think the original poster cares about Java though. The question was, D vs C#. Java's not a contender.

I love D. It's getting close to everything I want a language to be. The features it doesn't have now, it might have in the future, because through discussion on this newsgroup, we, the users, get a say. (And that is one thing you absolutely cannot say about C#).

I don't like C#. The name (C sharp) suggests it should be geared toward writing music, but it isn't. That's just pretentious. Seems like just another aspect of Microsoft's attempts at world domination. And certainly, you won't get a say in any decision they make.

Reiner Pope wrote:
> Yigal Chripun wrote:
>> David Brown wrote:
>>> On Sun, Oct 21, 2007 at 01:25:55AM +0200, Yigal Chripun wrote:
>>>
>>>> 1) it's a poor imitation of Java. Java may have its cons but at least they try to be consistent with the design of the language - every new feature goes through a JSR. this may make the language to evolve in a slower rate though. compare that to the MS approach of including the kitchen sink. the language has many features meant for corner cases which makes it bloated.
>>>> on the other hand other features were discarded like the covariance of return types, which is heavily used in Java land.
>>>
>>> C# fixes many problems with Java, at least in my opinion.  C# 2.0 adds
>>> generics which cover many of the cases of templates.  It has full support
>>> of the VM, so executes efficiently and safely.
>>>
>>
>> What exactly is broken in Java that C# does better, in your opinion?
>> from what i see, anything that needs fixing is being fixed within the Java community and I personally trust their decisions a lot more than MS. Adding properties to a languages isn't considered "fixing" it, it's just a convenience feature. On the other hand, removing covariance of return types is a very big mistake. there are others of course, but that one really pissed me off.
>>
> 
> C# has lexical closures, operator overloading, structs, and nullable types. I don't feel as dismissive of properties as you do because, in conjunction with operator overloading, they lead to a much cleaner (IMO) code look and feel than Java. Instead of writing
> 
>     foo.setAmount(foo.getAmount().add(5));
> 
> you get the much cleaner
> 
>     foo.Amount = foo.Amount + 5;
> 
> which you are in fact allowed to rewrite to
> 
>     foo.Amount += 5;
> 
> Another nice feature is C#'s System.Reflection.Emit package, which allows you to compile new code at runtime -- a useful optimization which can be used, for instance, for regexes.
> 
>     -- Reiner
regarding properties - even in D they aren't perfect:
until there's a consistent interface, meaning that there are no differences between a field and a property i would avoid them.
for example you can't do someObject.someProperty++;
I'm sure that this one is on the list though.

generally speaking: I regard properties a a convenience feature because you demonstrated yourself how to implement the same code with Java.
properties also allow for more abuse: in strictly OOP design you should avoid getter/setters for every field. the best way to design OOP is if you want to perform an action on some object, send it a message and it should perform it by itself, rather than providing getter/setter and the action performed outside the object.
example:
---
object.doSomething(params);
---
is more OOP correct than:
---
a = object.getField();
b = doSomthing(a, params);
object.setField(b);
---
also compare D foreach loop with Ruby's: collection.each block
which is much better from an OOP design point of view.

the only place where you _need_ every field to have getter/setter is if you're writing a bean that would be processed by some automated tool like the visual designer of an IDE. properties allow easy misuse of that.

with lexical closures you mean delegates, right?
well, they are expanded in c# to inner classes.
so in fact all the features you've mentioned are either part of the library, or could be part of the library (nullable types) and non provides a true fix for something wrong in Java. all those feature are ways to have shorter syntax than Java. I.E. niceties.
most could be achieved in Java, and some would probably be added to Java  (there's a debate regarding closures). so in fact nothing is broken in Java, it's just has a verbose syntax that frankly i don't like either.
It all come down to prettiness of the syntax, not the design of the semantics of the language itself.
on the flip side, how can I get covariant return types without changing the language? and as Janice already replied, you don't get a say with C#.

Janice Caron wrote:
> I don't think the original poster cares about Java though. The
> question was, D vs C#. Java's not a contender.
> 
> I love D. It's getting close to everything I want a language to be.
> The features it doesn't have now, it might have in the future, because
> through discussion on this newsgroup, we, the users, get a say. (And
> that is one thing you absolutely cannot say about C#).
> 
> I don't like C#. The name (C sharp) suggests it should be geared
> toward writing music, but it isn't. That's just pretentious. Seems
> like just another aspect of Microsoft's attempts at world domination.
> And certainly, you won't get a say in any decision they make.

I completely agree with the above post.
regarding your first point: I've mentioned Java, and also a bunch of other languages because I wanted to list all the possibilities I consider worth checking. I didn't even mentioned functional languages yet... Maybe Scheme is a good candidate? I don't know. Personally I like the way D combines the best practices of all styles in a proper way.

On 10/21/07, Janice Caron <caron800@googlemail.com> wrote:
> On 10/21/07, Yigal Chripun <yigal100@gmail.com> wrote:
> > object.doSomething(params);
> > ---
> > is more OOP correct than:
> > ---
> > a = object.getField();
> > b = doSomthing(a, params);
> > object.setField(b);
>
> I think that's wrong.

Also, the fact that one can write a getter function without a setter function allows one to define properties which are read-only to the outside world, but read-write to the containing object, which again is something you can't do with a plain member variable.

Janice Caron escribió:
> I don't like C#. The name (C sharp) suggests it should be geared
> toward writing music, but it isn't.

I've written a chord-position calculator for a guitar in Java, and I'm sure it would have been much easier in C# because of it's name. At least I wouldn't have to store the string "C#" since I could obtain it by reflection.

Yigal Chripun escribió:
> What exactly is broken in Java that C# does better, in your opinion?

The only thing I don't like about Java is that generics are not true generics. They are lost in runtime, the compiler erases the type before compiling. So, for example:

class Zoo {

  void foo(List<Dog> dogs) {
  }

  void foo(List<Cat> cats) {
  }

}

won't compile, because the method "foo(List)" is duplicated. Also you can't have generics of primitive types...

Yigal Chripun wrote:
> What exactly is broken in Java that C# does better, in your opinion?
> from what i see, anything that needs fixing is being fixed within the Java community and I personally trust their decisions a lot more than MS. Adding properties to a languages isn't considered "fixing" it, it's
> just a convenience feature. On the other hand, removing covariance of return types is a very big mistake. there are others of course, but that one really pissed me off.

Auto-boxing in C# works as expected. In Java you have to take care of implementation details that really don't concern to your code:

C#
	Int32 a1 = 1, a2 = 1;
	Int32 b1 = 128, b2 = 128;
	Console.WriteLine(a1 == a2);	// True
	Console.WriteLine(b1 == b2);	// True

Java-the-language:
	Integer a1 = 1, a2 = 1;
	Integer b1 = 128, b2 = 128;
	System.out.println(a1 == a2);	// true
	System.out.println(b1 == b2);	// false

This is because they cache the first 127 integers as a singleton while you'll get different objects for 128 and up.

Also, Generics don't guarantee that a collection will only contain elements of the same type:

	List<Integer> lint = new ArrayList();
	List lobj = lint;
	lobj.add("hello");	// WTF?


And how come in Java you have to check your enums for null before using them? :D

	void foo(Color c) {
		if (null = c)
			// throw something.
		switch (c) {
			case Color.red: break;
			case Color.green: break;
			case Color.blue: break;
			default: break;
		}
	}

Java-the-vm is a great implementation and I expect with anticipation a lot of useful languages to evolve on top of it, but Java-the-language isn't really a great example of language design.


>>> 2) who needs another proprietary language?? that's the most important issue for me. the mono project is a VERY stupid idea. it's a lost cause and a wasted effort - trying to play catch-up to MS while it constantly introduces breaking changes to the spec.
>>
>> C# is not proprietary.  It is an ECMA and ISO standard.  What makes mono
>> stupid?  I've done development under mono and found it to work quite well.
> 
> well, who is to prevent MS to publish a new "standard" every year? as I 

And who is to prevent SUN from publishing a new "standard" every year? The might have open sourced it's implementation but they still control the certifications that allow you to call your implementation *JAVA*.


> would you call Microsoft's document format standard? being a standard means being accepted as the default by all parties, not just by one.

Do you mean Microsoft's OOXML? Yes, it was accepted by ECMA last December. I think that qualifies as a "standard".

http://www.ecma-international.org/publications/standards/Ecma-376.htm


>> I think for the most part, D is a better language.
> 
> i agree fully with that.
> 
>>
>> David

I'm not defending Microsoft of its monopolistic practices but C# is a very nice language and it has a very comprehensive library with independent implementations. Mono's implementations even has a more liberal license than Java's GPL.

I'd like you to take a closer look at Mono's C# and reconsider your position.

Of course I still prefer D when speed is important but the huge class library in Mono is certainly appealing. Maybe Tango in a couple of years will be there and this conversation can be dropped.

--
Julio César Carrascal Urquijo
http://www.artelogico.com/

Janice Caron wrote:
> Also, the fact that one can write a getter function without a setter
> function allows one to define properties which are read-only to the
> outside world, but read-write to the containing object, which again is
> something you can't do with a plain member variable.

In C# you can:

	class Foo
	{
		public readonly string Bar = "Hello";

		// or
		public string Baz
		{
			get { return m_bar; }
		}
	}

The first one is read-only everywhere. The second is read-only in the outside but member functions can change the value of m_bar. I still miss read-only local variables, though.

--
Julio César Carrascal Urquijo
http://www.artelogico.com/

Julio César Carrascal Urquijo wrote:
> Yigal Chripun wrote:
>> What exactly is broken in Java that C# does better, in your opinion?
>> from what i see, anything that needs fixing is being fixed within the Java community and I personally trust their decisions a lot more than MS. Adding properties to a languages isn't considered "fixing" it, it's
>> just a convenience feature. On the other hand, removing covariance of return types is a very big mistake. there are others of course, but that one really pissed me off.
> 
> Auto-boxing in C# works as expected. In Java you have to take care of implementation details that really don't concern to your code:
> 
> C#
>     Int32 a1 = 1, a2 = 1;
>     Int32 b1 = 128, b2 = 128;
>     Console.WriteLine(a1 == a2);    // True
>     Console.WriteLine(b1 == b2);    // True
> 
> Java-the-language:
>     Integer a1 = 1, a2 = 1;
>     Integer b1 = 128, b2 = 128;
>     System.out.println(a1 == a2);    // true
>     System.out.println(b1 == b2);    // false
> 
> This is because they cache the first 127 integers as a singleton while you'll get different objects for 128 and up.
> 
> Also, Generics don't guarantee that a collection will only contain elements of the same type:
> 
>     List<Integer> lint = new ArrayList();
>     List lobj = lint;
>     lobj.add("hello");    // WTF?
> 
> 
> And how come in Java you have to check your enums for null before using them? :D
> 
>     void foo(Color c) {
>         if (null = c)
>             // throw something.
>         switch (c) {
>             case Color.red: break;
>             case Color.green: break;
>             case Color.blue: break;
>             default: break;
>         }
>     }
> 
> Java-the-vm is a great implementation and I expect with anticipation a lot of useful languages to evolve on top of it, but Java-the-language isn't really a great example of language design.

Technically, the auto-boxing issue is related to the implementation rather than the language design (unless that behavior is actually in the spec).  Generics, however, are utter garbage.  They are useful as a convenience tool for not manually casting and that's about it.  Opinions about MS aside, I think C# is a better designed language than Java.


Sean