Charles D Hixson wrote:

> Which kind of proves what I've been seeing as the point, i.e., D is a complete language, and it's POSSIBLE to do anything computable in it.  That doesn't mean it's easy, or worth doing, if you have to do it within the D syntax.
> 
> The things that people have been saying are all things that are POSSIBLE to do in D...but frequently the techniques for doing them are so cumbersome or error prone that the only reasonable choice is to avoid them.

The things that been been mentioned are also (not) coincidentally the
things that are well supported by either the core language or library.
Numerous other techniques are well supported and not cumbersome or
error-prone.

> If one believes that a particular technique is desirable, then one wishes to have it reasonably easy to use.  Thus, because MANY people have thought that templates are a good idea (esp. Walter), lots of work and improvement has been done on them. Much less work has been done on advanced run-time features, which aren't typically used in, at a guess, embedded systems.

Correct me if I'm wrong, but aren't these complimentory? I mean that
the effort that is going into things like templates is meant to make it
easier to support these 'advanced run-time features'?

> But just contrast D's approach with that of Python.  Python has long boasted "Batteries Included!".  I don't know if it's still on the home web page, but it was for many years.  Or Perl's proclaiming of CPAN.  I've never used it, but I'm still well aware of claims that programs don't need to check that libraries are available locally.  As long as there's a net connection, they'll be downloaded automatically.  (That may be overselling...but that's the way I've heard it advertised.) D, OTOH, is more like Ruby.  Libraries aren't available by default, and lots of the ones that are in the repositories aren't maintained any more and have suffered from bit-rot.  As a result Ruby has Rails programmers, and Python has Python programmers, and Perl has Perl programmers.  (OK.  That statement's a bit too strong.  But that's the tendency.)

Python is around much longer. It's apples and oranges in another
way too, for Python does not have (nor aims to have) the performance
of D. DSSS is supposed to be like CPAN, it is still young but pretty
sweet (if adopted by community).

> P.S.:  Partially this note is due to my current frustration due to the release of Tango, which won't work with Phobos, and therefore means that I can't depend on any particular library being installed with a D compiler...with the libraries being so different that the same code can't be used with both.

I agree. In some other thread someone remarked upon how easy it was
to write Java code because it is so very standardized, that makes it
easy to understand and use existing code. In a way D improves on
C++ in that a lot of stuff is not implementation specific, but on the
library side at the moment the situation is different.
This is not really a fair critique though since this (I would hope) is a
transient state of affairs, Tango is just out.

Lutger wrote:

> The things that been been mentioned are also (not) coincidentally the things that are well supported by either the core language or library.

I meant to write 'are *not*' well supported of course.

BCS wrote:
> To pick at a few:
> Does any language do interators for user type as language features? You have to write them your self in every language I know of. In D, all the types you can get without a lib can be iterated over without a lib.

In C# you have a yield keyword that creates an Enumerable class for you:

class List {
	IEnumerator getEnumerator() {
		for (int i = 0; i < 100; ++i)
			yield return InnerList[i];
	}
}


> And I'll admit that the mult return is a bit of a stretch.

Actually, tuples are one of my favorite language features on both Python and Erlang.


> But *I* don't care if things come from a lib or from a feature, just how well they get the job done. And I would never use a language that doesn't need libs. It would be WAY to big.

Agree

> But that's all just my opinion. Really my point is that for the most part D, in one form or another, has most of the things mentioned .

Agree, but I think that Steve Yegge was actually referring to a future version of ECMAScript.

Julio César Carrascal Urquijo wrote:
> BCS wrote:
>> To pick at a few:
>> Does any language do interators for user type as language features? You have to write them your self in every language I know of. In D, all the types you can get without a lib can be iterated over without a lib.
> 
> In C# you have a yield keyword that creates an Enumerable class for you:
> 
> class List {
>     IEnumerator getEnumerator() {
>         for (int i = 0; i < 100; ++i)
>             yield return InnerList[i];
>     }
> }
> 
> 
>> And I'll admit that the mult return is a bit of a stretch.
> 
> Actually, tuples are one of my favorite language features on both Python and Erlang.
> 
> 
>> But *I* don't care if things come from a lib or from a feature, just how well they get the job done. And I would never use a language that doesn't need libs. It would be WAY to big.
> 
> Agree
> 
>> But that's all just my opinion. Really my point is that for the most part D, in one form or another, has most of the things mentioned .
> 
> Agree, but I think that Steve Yegge was actually referring to a future version of ECMAScript.


Right -- so it's DMDScript and not D he was talking about.  :-)

--bb

> Right -- so it's DMDScript and not D he was talking about.  :-)
I hope so too :)

 - Paul

Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jarrett Billingsley schrieb am 2007-02-13:
>> "BCS" <BCS@pathlink.com> wrote in message news:eqq7nq$2tut$1@digitalmars.com...
>>
>>> Half?, more like one or two hard misses and a few more close calls.
>> Well let's see:
> 
> [snip]
> 
>> 15. Static typing and duck typing
>>
>> Yes.  (Unless some duck typing expert wants to correct me, I _think_ D has it)
> 
> Shouldn't the code below be legal if D supported duck typing?
> #
> # class Cat{
> #    void grow(){}
> # }
> #
> # class Tree{
> #    void grow(){}
> # }
> #
> # void main(){
> #    Tree t = new Cat();
> #    t.grow();
> # }
> 
> Thomas
> 
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iD8DBQFF0eWfLK5blCcjpWoRAhUwAJ9DflOJIIo4wN0FiqBqWl39Y6/cogCfS7Al
> QXsO2nfgt3JzdzkD0nurXPc=
> =oAuz
> -----END PGP SIGNATURE-----

Yup, D doesn't actually support duck typing. Not on the object system method call at least, since in metaprogramming (compile-time) it has something that can be considered duck typing: Using the is-expression to test for features:

template func(T) (T foo) {
  static if(is(foo.grow())) {
    foo.grow();
  } else
    ...
}


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Jarrett Billingsley wrote:
> 
> Basically it's a way of really easily applying functions and such over a list.  They're kind of like array operations (a[] = b[] + c[]), which D doesn't have yet, but more flexible.  You can do stuff like (using very python-like syntax):
> 
> int[] numbers = [1, 2, 3, 4, 5, 6, 7, 8];
> 
> // This loops through numbers, seeing if the condition holds true,
> // and if it does, adds it to a new list, which is eventually assigned
> // to evens.
> int[] evens = [x for x in numbers if !(x & 1)];
> 
> // Square the list
> int[] squares = [x * x for x in numbers];

I'm not sure about these.  The syntax is not much better then a foreach loop.

janderson wrote:

> Jarrett Billingsley wrote:
>> 
>> Basically it's a way of really easily applying functions and such over a list.  They're kind of like array operations (a[] = b[] + c[]), which D doesn't have yet, but more flexible.  You can do stuff like (using very python-like syntax):
>> 
>> int[] numbers = [1, 2, 3, 4, 5, 6, 7, 8];
>> 
>> // This loops through numbers, seeing if the condition holds true,
>> // and if it does, adds it to a new list, which is eventually assigned
>> // to evens.
>> int[] evens = [x for x in numbers if !(x & 1)];
>> 
>> // Square the list
>> int[] squares = [x * x for x in numbers];
> 
> I'm not sure about these.  The syntax is not much better then a foreach loop.

But they are expressions instead of statements which can be important in some situations, and they are probably more limited (no defined ordering) something that could be used in optimizations.

Johan Granberg wrote:
> janderson wrote:
> 
>> Jarrett Billingsley wrote:
>>> Basically it's a way of really easily applying functions and such over a
>>> list.  They're kind of like array operations (a[] = b[] + c[]), which D
>>> doesn't have yet, but more flexible.  You can do stuff like (using very
>>> python-like syntax):
>>>
>>> int[] numbers = [1, 2, 3, 4, 5, 6, 7, 8];
>>>
>>> // This loops through numbers, seeing if the condition holds true,
>>> // and if it does, adds it to a new list, which is eventually assigned
>>> // to evens.
>>> int[] evens = [x for x in numbers if !(x & 1)];
>>>
>>> // Square the list
>>> int[] squares = [x * x for x in numbers];
>> I'm not sure about these.  The syntax is not much better then a foreach
>> loop.
> 
> But they are expressions instead of statements which can be important in
> some situations, and they are probably more limited (no defined ordering)
> something that could be used in optimizations.

About the optimisation part. I think it would be better to be able to specify that a loop's contents are order-independent.

-Joel

janderson Wrote:

> Jarrett Billingsley wrote:
> > 
> > Basically it's a way of really easily applying functions and such over a list.  They're kind of like array operations (a[] = b[] + c[]), which D doesn't have yet, but more flexible.  You can do stuff like (using very python-like syntax):
> > 
> > int[] numbers = [1, 2, 3, 4, 5, 6, 7, 8];
> > 
> > // This loops through numbers, seeing if the condition holds true,
> > // and if it does, adds it to a new list, which is eventually assigned
> > // to evens.
> > int[] evens = [x for x in numbers if !(x & 1)];
> > 
> > // Square the list
> > int[] squares = [x * x for x in numbers];
> 
> I'm not sure about these.  The syntax is not much better then a foreach loop.

We can use "Array operations":

R[] map(T,R)(T[] arr, R delegate(T) dg){
    R[] result = new R[arr.length];
    foreach(i, item; arr)
        result[i] = dg(item);
    return result;
}

void main(){
    int[] numbers = [1, 2, 3, 4, 5, 6, 7, 8];
    int[] squares = numbers.map( delegate int(int x){return x * x;} );
}

I think the syntax of delegate literal should be simplified, like this:
int[] squares = numbers.map( int(int x){return x * x;} );

or ruby-like syntax:
int[] squares = numbers.map( {int|int x| x * x} );