June 07, 2010
dsimcha wrote:
> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>> D is an extremely powerful language, but when I read complaints and sighs about
>> other languages, few seem to know that these problems are solved with D.
>> Essentially, we have a marketing problem.
>> One great way to address it is by writing articles about various aspects of D
>> and how they solve problems, like
>>
> http://www.reddit.com/r/programming/comments/cb14j/compiletime_function_execution_in_d/
>>   which was well received on reddit.
>> Anyone have good ideas on topics for D articles? And anyone want to stand up and
>> write an article?
>> They don't have to be comprehensive articles (though of course those are
>> better), even blog entries will do.
> 
> This probably won't be replied to because I'm starting a new sub-thread in a mature discussion, but I wonder if we could write about the advantages and disadvantages of duck typing vs. static typing, comparing Python vs. Java at first, then bring D into the picture to show how, to a greater extent than C++ templates or C#/Java generics, it solves may of the problems of static typing without introducing the pitfalls of duck typing.
> 
> Here's a simple example of something that would be awkward to impossible to do efficiently in any other language:
> 
> /**Finds the largest element present in any of the ranges passed in.\
>  */
> CommonType!(staticMap!(ElementType, T)) largestElement(T...)(T args) {
>     // Quick and dirty impl ignoring error checking:
>     typeof(return) ret = args[0].front();
> 
>     foreach(arg; args) {
>         foreach(elem; arg) {
>             ret = max(elem, ret);
>         }
>     }
> 
>     return ret;
> }
> 
> Do this in C++ -> FAIL because there are no variadics.  (Yes, C++1x will have them, but I might die of old age by the time C++1x exists.)
> 
> Do this in any dynamic language -> FAIL because looping is so slow that you might die of old age before it executes.  Besides, who wants to do computationally intensive, multithreaded work in a dynamic language?
> 
	In python: max (map (max, args)) should have reasonable
performances and is *much* more elegant...

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr



June 07, 2010
On 06/07/2010 12:57 PM, "Jérôme M. Berger" wrote:
> dsimcha wrote:
>> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>>> D is an extremely powerful language, but when I read complaints and sighs about
>>> other languages, few seem to know that these problems are solved with D.
>>> Essentially, we have a marketing problem.
>>> One great way to address it is by writing articles about various aspects of D
>>> and how they solve problems, like
>>>
>> http://www.reddit.com/r/programming/comments/cb14j/compiletime_function_execution_in_d/
>>>    which was well received on reddit.
>>> Anyone have good ideas on topics for D articles? And anyone want to stand up and
>>> write an article?
>>> They don't have to be comprehensive articles (though of course those are
>>> better), even blog entries will do.
>>
>> This probably won't be replied to because I'm starting a new sub-thread in a
>> mature discussion, but I wonder if we could write about the advantages and
>> disadvantages of duck typing vs. static typing, comparing Python vs. Java at
>> first, then bring D into the picture to show how, to a greater extent than C++
>> templates or C#/Java generics, it solves may of the problems of static typing
>> without introducing the pitfalls of duck typing.
>>
>> Here's a simple example of something that would be awkward to impossible to do
>> efficiently in any other language:
>>
>> /**Finds the largest element present in any of the ranges passed in.\
>>   */
>> CommonType!(staticMap!(ElementType, T)) largestElement(T...)(T args) {
>>      // Quick and dirty impl ignoring error checking:
>>      typeof(return) ret = args[0].front();
>>
>>      foreach(arg; args) {
>>          foreach(elem; arg) {
>>              ret = max(elem, ret);
>>          }
>>      }
>>
>>      return ret;
>> }
>>
>> Do this in C++ ->  FAIL because there are no variadics.  (Yes, C++1x will have
>> them, but I might die of old age by the time C++1x exists.)
>>
>> Do this in any dynamic language ->  FAIL because looping is so slow that you might
>> die of old age before it executes.  Besides, who wants to do computationally
>> intensive, multithreaded work in a dynamic language?
>>
> 	In python: max (map (max, args)) should have reasonable
> performances and is *much* more elegant...

I very much doubt that.

Andrei
June 07, 2010
""Jérôme M. Berger"" <jeberger@free.fr> wrote in message news:hujboe$tp2$1@digitalmars.com...
>Nick Sabalausky wrote:
>> I actually find that funny. Something in Java that isn't an Object? I remember "Everything's an object!" being paraded around as a selling point.
>>
> Yes, in Java, everything is an object except where that bothered
>the language "designers". There are several such design decisions in Java...

Yea, that's a good example of why I've grown a distaste towards hard-and-fast religious design strategies. The designer inevitably comes across cases where it just doesn't work particularly well, and then they're forced to either stay true to their misguided principles by accepting an awkward problematic design, or contradict their alleged principles and go with a better design. And when they do the latter, that runs the risk of causing problems in other areas that had been relying on the old principle being rigidly followed.

-------------------------------
Not sent from an iPhone.


June 07, 2010
"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:hujc46$v49$1@digitalmars.com...
> On 06/07/2010 12:57 PM, "Jérôme M. Berger" wrote:
>> dsimcha wrote:
>>> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>>>> D is an extremely powerful language, but when I read complaints and
>>>> sighs about
>>>> other languages, few seem to know that these problems are solved with
>>>> D.
>>>> Essentially, we have a marketing problem.
>>>> One great way to address it is by writing articles about various
>>>> aspects of D
>>>> and how they solve problems, like
>>>>
>>> http://www.reddit.com/r/programming/comments/cb14j/compiletime_function_execution_in_d/
>>>>    which was well received on reddit.
>>>> Anyone have good ideas on topics for D articles? And anyone want to
>>>> stand up and
>>>> write an article?
>>>> They don't have to be comprehensive articles (though of course those
>>>> are
>>>> better), even blog entries will do.
>>>
>>> This probably won't be replied to because I'm starting a new sub-thread
>>> in a
>>> mature discussion, but I wonder if we could write about the advantages
>>> and
>>> disadvantages of duck typing vs. static typing, comparing Python vs.
>>> Java at
>>> first, then bring D into the picture to show how, to a greater extent
>>> than C++
>>> templates or C#/Java generics, it solves may of the problems of static
>>> typing
>>> without introducing the pitfalls of duck typing.
>>>
>>> Here's a simple example of something that would be awkward to impossible
>>> to do
>>> efficiently in any other language:
>>>
>>> /**Finds the largest element present in any of the ranges passed in.\
>>>   */
>>> CommonType!(staticMap!(ElementType, T)) largestElement(T...)(T args) {
>>>      // Quick and dirty impl ignoring error checking:
>>>      typeof(return) ret = args[0].front();
>>>
>>>      foreach(arg; args) {
>>>          foreach(elem; arg) {
>>>              ret = max(elem, ret);
>>>          }
>>>      }
>>>
>>>      return ret;
>>> }
>>>
>>> Do this in C++ ->  FAIL because there are no variadics.  (Yes, C++1x
>>> will have
>>> them, but I might die of old age by the time C++1x exists.)
>>>
>>> Do this in any dynamic language ->  FAIL because looping is so slow that
>>> you might
>>> die of old age before it executes.  Besides, who wants to do
>>> computationally
>>> intensive, multithreaded work in a dynamic language?
>>>
>> In python: max (map (max, args)) should have reasonable
>> performances and is *much* more elegant...
>
> I very much doubt that.
>
> Andrei

It might be faster than using nested loops in Python. But yea, seems unlikely it would compare to the D version.

Plus, can't you still do something like this? (I may not have this exactly right)

CommonType!(staticMap!(ElementType, T)) largestElement(T...)(T args)
{
    static assert( !is(typeof(return) == void) );

    return max( map!max(args) );
}

Assuming, of course, a 'max' that works on a range, which would be easy enough to do. Probably something like:

T max(T range)
{
    return reduce!ordinaryMax(range);
    // Or
    return reduce!"a>b?a:b"(range);
}

-------------------------------
Not sent from an iPhone.


June 07, 2010
"Nick Sabalausky" <a@a.a> wrote in message news:hujd6a$11e8$1@digitalmars.com...
>
> Assuming, of course, a 'max' that works on a range, which would be easy enough to do. Probably something like:
>

ElementType!T max(T range)  // Corrected

> {
>    return reduce!ordinaryMax(range);
>    // Or
>    return reduce!"a>b?a:b"(range);
> }
>



June 07, 2010
Nick Sabalausky wrote:
> Yea, that's a good example of why I've grown a distaste towards hard-and-fast religious design strategies. The designer inevitably comes across cases where it just doesn't work particularly well, and then they're forced to either stay true to their misguided principles by accepting an awkward problematic design, or contradict their alleged principles and go with a better design. And when they do the latter, that runs the risk of causing problems in other areas that had been relying on the old principle being rigidly followed.

D has design principles, but those principles are often contradictory. I don't see a good reason to follow a design principle out of principle if it destroys the utility of the language.

For example, consider:

    version (unittest)

'unittest' is a keyword, not an identifier. Making this work requires a special case in the grammar. But the alternatives,

    version (Unittest)
    version (unit_test)
    version (unittests)

etc. are all much worse than simply violating a principle and putting the special case in.
June 07, 2010
"Walter Bright" <newshound1@digitalmars.com> wrote in message news:hujdg6$125b$1@digitalmars.com...
> Nick Sabalausky wrote:
>> Yea, that's a good example of why I've grown a distaste towards hard-and-fast religious design strategies. The designer inevitably comes across cases where it just doesn't work particularly well, and then they're forced to either stay true to their misguided principles by accepting an awkward problematic design, or contradict their alleged principles and go with a better design. And when they do the latter, that runs the risk of causing problems in other areas that had been relying on the old principle being rigidly followed.
>
> D has design principles, but those principles are often contradictory. I don't see a good reason to follow a design principle out of principle if it destroys the utility of the language.
>
> For example, consider:
>
>     version (unittest)
>
> 'unittest' is a keyword, not an identifier. Making this work requires a special case in the grammar. But the alternatives,
>
>     version (Unittest)
>     version (unit_test)
>     version (unittests)
>
> etc. are all much worse than simply violating a principle and putting the special case in.

Great example.

Of course, one could argue that we religiously follow pragmatism ;)

-------------------------------
Not sent from an iPhone.


June 07, 2010
Walter Bright, el  7 de junio a las 11:24 me escribiste:
> Nick Sabalausky wrote:
> >Yea, that's a good example of why I've grown a distaste towards hard-and-fast religious design strategies. The designer inevitably comes across cases where it just doesn't work particularly well, and then they're forced to either stay true to their misguided principles by accepting an awkward problematic design, or contradict their alleged principles and go with a better design. And when they do the latter, that runs the risk of causing problems in other areas that had been relying on the old principle being rigidly followed.
> 
> D has design principles, but those principles are often contradictory. I don't see a good reason to follow a design principle out of principle if it destroys the utility of the language.
> 
> For example, consider:
> 
>     version (unittest)
> 
> 'unittest' is a keyword, not an identifier. Making this work requires a special case in the grammar. But the alternatives,
> 
>     version (Unittest)
>     version (unit_test)
>     version (unittests)
> 
> etc. are all much worse than simply violating a principle and putting the special case in.

Please, document this!

http://d.puremagic.com/issues/show_bug.cgi?id=4230

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
¿Qué será lo que hace que una brújula siempre marque el norte?
- Ser aguja, nada más, y cumplir su misión.
	-- Ricardo Vaporeso
June 07, 2010
Mon, 07 Jun 2010 14:06:24 -0400, Nick Sabalausky wrote:

> ""Jérôme M. Berger"" <jeberger@free.fr> wrote in message news:hujboe$tp2$1@digitalmars.com...
>>Nick Sabalausky wrote:
>>> I actually find that funny. Something in Java that isn't an Object? I remember "Everything's an object!" being paraded around as a selling point.
>>>
>> Yes, in Java, everything is an object except where that bothered
>>the language "designers". There are several such design decisions in Java...
> 
> Yea, that's a good example of why I've grown a distaste towards hard-and-fast religious design strategies. The designer inevitably comes across cases where it just doesn't work particularly well, and then they're forced to either stay true to their misguided principles by accepting an awkward problematic design, or contradict their alleged principles and go with a better design. And when they do the latter, that runs the risk of causing problems in other areas that had been relying on the old principle being rigidly followed.

Part of the "religious" feel of Java comes from the fact that it runs on a VM. The safe memory model imposes some restrictions as you might have noticed in SafeD. The 'everything is an Object' idea is a bit broken, performance-wise. That's why C# added reified types. The reason they added primitive types has a rationale behind it. The decision made the VM a useful tool for real enterprise applications.
June 07, 2010
Andrei Alexandrescu wrote:
> On 06/07/2010 12:57 PM, "Jérôme M. Berger" wrote:
>>> Do this in any dynamic language ->  FAIL because looping is so slow that you might die of old age before it executes.  Besides, who wants to do computationally intensive, multithreaded work in a dynamic language?
>>
>>     In python: max (map (max, args)) should have reasonable
>> performances and is *much* more elegant...
> 
> I very much doubt that.
> 
	What do you doubt? That it has reasonable performance or that it is
more elegant?

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr