The Expressiveness of D

[Michael Stover]

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 at 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 at 1f18cd5, C at 154f6ff)
> >
> > scala> val b = Map(1 -> new B, 2 -> new C)
> > b: scala.collection.immutable.Map[Int,A] = Map((1,B at 14512e),
> (2,C at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101102/5cc1c924/attachment.html>