I don't see how compiling to native prevents the source code from expressing high-level concepts in a reasonable way.  Lisp is compiled to naitve code.  Even Java can be compiled to native code.  And frankly, that has little to do with speed and memory usage.  The memory usage is largely from the garbage collector, and thus is still there even when compiling to native.  I imagine D has that issue too.

-Mike

On Tue, Nov 2, 2010 at 9:27 AM, Gary Whatmore <no@spam.sp> wrote:
%u Wrote:

> %u Wrote:
>
> > I found a slideshow called 'The Expressiveness of Go' recently. The conclusions are:
> >
> > * Go is not a small language but it is an expressive and comprehensible one.
> >
> > * Expressiveness comes from orthogonal composition of constructs.
> >
> > * Comprehensibility comes from simple constructs that interact in easily understood ways.
> >
> > * Build a language from simple orthogonal constructs and you have a language that will be easy and productive to use.
> >
> > * The surprises you discover will be pleasant ones.
> >
> > ----
> >
> > Is D orthogonal? Could it be more orthogonal? Two things come to my mind: removing special cases and making widely used things first class. For data types this means that they have literals, can be given to functions and returned from functions. I made a small test and found that the discoveries aren't pleasant to me:
> >
> >
> > class A {}
> > class B : A {}
> > class C : A {}
> >
> > template T(A...) { alias A T; }
> >
> > void main() {
> >   auto a = true ? new B : new C;
> > // these don't work - why?
> > //  auto b = [new B, new C];
> > //  auto c = { return [1: new B,2: new C]; };
> >
> >   T!(int,int) e = (1,2);
> >   e = T!(3,4);
> >
> > // ah - so (1,2) syntax on initialization, T!(1,2) when assigning!
> >   T!(int,int) d = T!(1,2);
> >
> >   e = d;
> >
> > // tuples aren't first class, why?
> > //  auto f = { return e; };
> > }
>
> I then test this in Scala REPL:
>
> scala> class A; class B extends A; class C extends A
> defined class A
> defined class B
> defined class C
>
> scala> val a = List(new B,new C)
> a: List[A] = List(B@1f18cd5, C@154f6ff)
>
> scala> val b = Map(1 -> new B, 2 -> new C)
> b: scala.collection.immutable.Map[Int,A] = Map((1,B@14512e), (2,C@1ddbcb1))
>
> scala> var e = (1,2)
> e: (Int, Int) = (1,2)
>
> scala> e = (3,4)
> e: (Int, Int) = (3,4)
>
> scala> val d = (1,2)
> d: (Int, Int) = (1,2)
>
> scala> e = d
> e: (Int, Int) = (1,2)
>
> scala> val f = () => e
> f: () => (Int, Int) = <function0>
>
> scala> f()
> res0: (Int, Int) = (1,2)

My eyes radiate red light of hate every time I see these comparisons between D and some slower virtual machine language. Of course the virtual machine languages are simpler to use and look nice. That's their way to lure you into using them. Boom! Suddenly 200% larger memory usage and 50% to 90% of the processing power is lost. Building a native language doesn't have all mumbo jumbo JIT daemons running there. Thus the code has to optimized at compile time and that's why those codes above are more complex in D and don't work.

 - G.W.