Sean Kelly wrote:
> 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

Yes, it is in the "The Java Language Specification, Third Edition" at least:

If the value p being boxed is true, false, a byte, a char in the range \u0000 to \u007f, or an int or short number between -128 and 127, then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.

http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.7


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

On 10/21/07, Julio César Carrascal Urquijo <jcarrascal@gmail.com> wrote:
> In C# you can:

I think you can in /every/ language. I only posted that point because I disagreed with Yigal who said that properties were a bad thing.

Julio César Carrascal Urquijo Wrote:

> 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.

I agree that C# is probably a better-designed language (to a rather small extent) than Java, but I think the reason is "hindsight is 20/20". C# aimed basically to be a better version of Java, since the paradigms and ideas work well for large corporate codebases, and to that extent it worked. I've done very little C# coding, but I do remember appreciating closures (it's a shame D doesn't have them), and I never shed a tear for checked exceptions.

I don't agree, however, that "Java-the-language isn't really a great example of language design." For a large codebase, Java is a extremely well-designed language (despite its couple quirks), which is why it has been so successful, and continues to be so successful.

I think a lot of people with C/C++ backgrounds look at Java and cite the numerous problems with it, many of which can be wrapped up into the statement "It takes me two pages of code in Java to do what I can in one in C++" or "the performance sucks". The latter of those issues is mostly a non-issue, since if you're running a company running a large server-side software platform with 300 developers or designing a new cellular phone you want everyone to easily deploy applications on, the software engineering benefits of Java far outweigh the slight additional hardware costs.

The first point (that coding in C/C++ is easier than in Java) is a more interesting one, but I think it stems from this implicit assumption that Java is just C++ with all the low-level, complex, and cool stuff ripped out. However, I think Java is more like Smalltalk with C/C++ syntax forced onto it. You _can_ write Java like you would C++ and end up with a total mess (look at Descent fro a Java port of the DMD front-end... you'll see what I mean), but at it core, Java is meant to be written in a more object-oriented style than even C++, and the "objects-for-everything" idea actually works. It's just something you need to subscribe to pretty completely; if you're complaining about having to type "new" all over the place or the lack of free functions, you are not one with the zen of OO programming.

Of course, I'm a huge Smalltalk fan, and only actually worked to any great extent (more than a few smaller projects) in Java and Perl (the latter of which has scarred me permanently), so I may be a bit biased. In fact, even when I look at D, I'm looking at it from the perspective of a highly OO programming style.

Robert Fraser wrote:
> I agree that C# is probably a better-designed language (to a rather small
> extent) than Java, but I think the reason is "hindsight is 20/20". C# aimed   > basically to be a better version of Java, since the paradigms and 
ideas work
> well for large corporate codebases, and to that extent it worked. I've done very little C# coding, but I do remember appreciating closures (it's a shame 
> D doesn't have them), and I never shed a tear for checked exceptions.

Off course is strange to call Java a bad example of language design in favor of C# but you should note that the reasons I gave (Namely boxing, generics and enums) *where developed first on C#* and then bolted on top of Java. The hindsight argument doesn't apply to these three reasons.

The problem I'm trying to point is that Java-the-language was pretty much dormant since 1995 and then they added these *features* at the same time in Java 1.5 in response to C# 2.0. These leaky abstraction all have broken behavior that they now have to support for, who know how many years.

That's what I call bad language design.


> Of course, I'm a huge Smalltalk fan, and only actually worked to any great extent (more than a few smaller projects) in Java and Perl (the latter of which has scarred me permanently), so I may be a bit biased. In fact, even when I look at D, I'm looking at it from the perspective of a highly OO programming style.

I'm still learning Smalltalk (Squeak). I'm at the point where I can understand what a piece of code does but still don't get what is that I gain by writing code in this style. Any pointers to obtain the Zen experience? :D


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

Janice Caron wrote:
> 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.

you're correct with you comment but that just shows that you're a true c++ programmer and completely missed my point.

I haven't said that fields are better than properties. what i meant was the use of encapsulation from the OOP perspective. In pure OOP, method calls are considered messages to objects and the objects have attached behavior that handles its inner state. if you want to manipulate its inner state, the proper OOP way is to have the object contain such behavior itself and all you need to do is to send the object a message, rather than get its inner state with a getter and perform the action yourself. the latter breaks encapsulation from an OOP perspective.
properties are easy to misuse by a programmer to break said encapsulation and implement the latter instead of the former design.
that's not to say that getters should be avoided, on the contrary, please do use them when _appropriate_.

Janice Caron wrote:
> On 10/21/07, Julio César Carrascal Urquijo <jcarrascal@gmail.com> wrote:
>> In C# you can:
> 
> I think you can in /every/ language. I only posted that point because
> I disagreed with Yigal who said that properties were a bad thing.
> 
I didn't say they are a bad thing, I've said they allow for easy misuse and breaking of OOP encapsulation. therefore they are a useful shortcut for experienced programmers but they don't add new functionality to the language and therefore do not fix anything in the language design.

Mike wrote:
> Hi,
>
> I have some advanced knowledge of programming with C and C++.
> While I like C for its simplicity and speed, it lacks some important functionality (like OO). I'm not very fond of C++, since it is quite clumsy. (But you know all that already)
>
> Anyway, I was looking for a new programming language for little projects. I looked into the specs of the D language and became quite fond of it. Anyway, I hear a lot of good things about C# as well.
> I am not experienced enough to compare the two simply on the basis of their specifications. I tried finding some comparison on the internet but failed to find anything more recent than from 2003.
>
>   
Hi Mike,
both languages and their respective development arsenal are well suited for a specific pool of tasks.

C# has the benefit of a corporate backing with great toolset, vast libraries, good documentation and a large community.
Purely as a language, I consider it as mediocre, a better Java as others put it, but this doesn't necessary subtract the potential value of it when combined with the library, IDE, documentation, community and industry support (jobs...).

D on the other hand is a better,cool language, with some great potential. Even if right now it's library set is not as vast and orthogonal, progress it made every day on improving the situation. IDE's and debuggers are developed (some already usable), packaging, build and distribution solutions are provided. It's community, even if small, packs a lot of smart people, a situation rarely seen on Java or .Net side :) and you learn *a lot* form them.

Now, purely addressing your needs for a language geared towards developing small utilities you have to options(in my opinion of course):
If you are distributing your programs to a limited audience like a corporate department or to an environment you can easily control .net + C# is the easiest and painless way.

On the other hand if you are distributing you apps. to a larger audience, especially if you are doing it for profit, .Net will cost you dollars! Its large framework and sometimes its perceived lack of responsiveness plus the large resource hogging (a common sin of the VM be it Java or .Net), can be roadblocks for attracting potential users. Here D and its compiled nature can help you greatly, the lack of a vast library is an advantage now as you can control what goes in, the performance is better (if you code correctly) and your users are happy. You will be happier as the language puts a smile on your face most of the times :).

That being said I hope I was of some help.

Regards,
Radu