Hello

The D language looks very interesting. I had also looked at nice (http://nice.sourceforge.net/) and was wondering if anyone had done a comparison. In some ways they seem to have a similar approach, although nice runs on the JVM and aims to be able to use Java libraries. Incidentally nice is listed in the language shootout at http://shootout.alioth.debian.org/ .

Nice permits methods to be defined outside classes, and selects the method to be called at run-time on the basis of the argument types, along the following lines:

class A { ... }
class B { ... }

display (A x)  { ... code to display an instance of A ...}
display (B x)  { ... code to display an instance of B ...}

connection (A x, B y) { ... deal with connections from an A to a B ...}
connection (B x, A y) { ... deal with connections from an B to a A ...}

For methods declared outside any class, the first argument is treated as the class to which the method has been added. So you could either say

A x = new A();
x.display();

or

A x = new A();
display(x);

Where a method is chosen on the basis of its argument types at run-time, you know that the right types have been provided: eg the method for connections from an A to a B can only be called when those are the argument types that were provided in a particular call, so there is no need to check that the second argument really is of class B.

The ability to add methods to a class relates at least slightly to the recent feature request for partial class definitions.

In article <csr550$2mb$1@digitaldaemon.com>, Peri Hankey says...
>
>Hello
>
>The D language looks very interesting. I had also looked at nice (http://nice.sourceforge.net/) and was wondering if anyone had done a comparison. In some ways they seem to have a similar approach, although nice runs on the JVM and aims to be able to use Java libraries.

I don't think so. To me nice looks very much like Dylan with a C-like syntax.



>Nice permits methods to be defined outside classes, and selects the method to be called at run-time on the basis of the argument types,

This is normaly refered to as multi-methods.


>The ability to add methods to a class relates at least slightly to the recent feature request for partial class definitions.

So do you suggest to completely redisign D and make it a different language?


-- Matthias Becker

> Nice permits methods to be defined outside classes, and selects the method to be called at run-time on the basis of the argument types, along the following lines:
>
> class A { ... }
> class B { ... }
>
> display (A x)  { ... code to display an instance of A ...}
> display (B x)  { ... code to display an instance of B ...}

This will work in D too! You can do both:

A a = new A;
display(a);
a.display();

(IF I'm not mistaken)

L.

Peri Hankey wrote:
> Hello
>
> The D language looks very interesting. I had also looked at
> nice (http://nice.sourceforge.net/) and was wondering if
> anyone had done a comparison. In some ways they seem to have a
> similar approach...

I glanced over Nice's manual here:
  http://nice.sourceforge.net/manual.html

D's spec can be found here:
  http://digitalmars.com/d/index.html

The major differences I noticed are:

(1) Nice seems primarily oriented towards OOP but allows structured programming whereas D is the opposite. I should mention Nice seems to support a structed programing style without gotchas wheras OOP in D is riddled with gotchas.

(2) Nice is quite advanced at statically checking null pointers whereas D is not.

(3) Nice compiles to Java bytecode and D compiles to native code with C linkage.

(4) Nice interoperates with Java allowing access to arguably one of the most robust OOP libraries in the world. D interoperates with C allowing access to a massive collection of statically linked libraries and COM compatability.

(5) Nice only has the Java primitive types. D has both signed and unsigned integer types and not just 80-bit floating point support but also the complex and imaginary primitive types.

(6) Nice has no means for users to extend primitive types whereas D is quite advanced and has not one but two means of extending primitive types - typdef/alias. Unlike C/C++ typedef does not just make a new name for a primitive type but creates a whole new primitive type.

(7) Nice has tuples and D has structs. Tuples can be quite useful for multiple assignments (ie swapping x and y as (x,y) = (y,x)). However the benefit of tuples returning multiple values from a function is comparable with D's in, inout and out parameters which are more straightforward than tuples.

(8) Nice seems to allow parametric polymorphic types define their range as the union of any primitive types.

(9) D includes an inline assembler.

(10) D has native data structures. Namely associative arrays and bit arrays.

parabolis <parabolis@softhome.net> schrieb:
> Peri Hankey wrote:
>  > Hello
>  >
>  > The D language looks very interesting. I had also looked at
>  > nice (http://nice.sourceforge.net/) and was wondering if
>  > anyone had done a comparison. In some ways they seem to have a
>  > similar approach...

> (3) Nice compiles to Java bytecode and D compiles to native code
> with C linkage.
This is a (missing) feature of the compiler and not of the language specs.
I am sure you could adapt GDC/GCC/GCJ to emmit Java bytecode for D sources. Most of D's
features should be easy to translate, but maybe the template-mixin pair might pose some
hurdles.

> (10) D has native data structures. Namely associative arrays and
> bit arrays.
Oh those bit arrays ... At first this seems to be realy usefull, but as soon as you start using them you'll notice that the current implementation has lot's of limitations.

e.g.
- no dummy ".sort" property
- concat / shift limitated to byte boundries

Thomas

Thomas Kuehne wrote:

> This is a (missing) feature of the compiler and not of the language specs.
> I am sure you could adapt GDC/GCC/GCJ to emmit Java bytecode for D sources. Most of D's
> features should be easy to translate, but maybe the template-mixin pair might pose some
> hurdles.

That is a good point.

> Oh those bit arrays ... At first this seems to be realy usefull, but as soon as you start
> using them you'll notice that the current implementation has lot's of limitations.

It was my intent to include the things that are expected and/or likely to work for the big 1.0. I did not count against Nice the lack of any typedef/alias as I got the impression the Nice creator has not yet ruled the possibility out. It is rather hard to compare features between two languages that don't officially exist yet.