On Wednesday, 30 September 2015 at 16:06:59 UTC, Joakim wrote:
> On Wednesday, 30 September 2015 at 01:45:49 UTC, deadalnix wrote:
>> https://www.youtube.com/watch?v=mFUXNMfaciE
>>
>> From
>> http://wiki.dlang.org/Component_programming_with_ranges
>>
>> Congrat H. S. Teoh
>
> Thanks for the link, I watched the whole video today and it was a very good presentation by Niebler.  He mentions D and Teoh's example right at the top and gets an ovation at the 49 minute-mark, once he's gone through his entire C++ version of Teoh's D example.
>
> Interesting that they're using the pipe symbol for chaining, more explicitly mimicking the unix command line.  The fact that scoping meant that views and actions were explicitly labeled could be a nice benefit, though I generally dislike such verbosity normally.  It is amazing how noisy some of the implementation code with templates is in C++: I felt like I was looking at some Haskell variant compared to how clean D would look for the same code.

Another thing I noticed that showed D nice-ness is when he was converting the weeks ranges to a string, the flow of the functions went from the bottom up (he specifically said "start from the bottom").
It looks so weird to me after using UFCS for so long.

On 9/30/15 12:12 PM, wobbles via Digitalmars-d wrote:
> On Wednesday, 30 September 2015 at 16:06:59 UTC, Joakim wrote:
>> On Wednesday, 30 September 2015 at 01:45:49 UTC, deadalnix wrote:
>>> https://www.youtube.com/watch?v=mFUXNMfaciE
>>>
>>> From
>>> http://wiki.dlang.org/Component_programming_with_ranges
>>>
>>> Congrat H. S. Teoh
>>
>> Thanks for the link, I watched the whole video today and it was a very good presentation by
>> Niebler.  He mentions D and Teoh's example right at the top and gets an ovation at the 49
>> minute-mark, once he's gone through his entire C++ version of Teoh's D example.
>>
>> Interesting that they're using the pipe symbol for chaining, more explicitly mimicking the unix
>> command line.  The fact that scoping meant that views and actions were explicitly labeled could be
>> a nice benefit, though I generally dislike such verbosity normally.  It is amazing how noisy some
>> of the implementation code with templates is in C++: I felt like I was looking at some Haskell
>> variant compared to how clean D would look for the same code.
>
> Another thing I noticed that showed D nice-ness is when he was converting the weeks ranges to a
> string, the flow of the functions went from the bottom up (he specifically said "start from the
> bottom").
> It looks so weird to me after using UFCS for so long.

The 'start from the bottom' part of that part of the code was because he wanted to talk about it in that order.  The logic in the code flowed in exactly the order you'd expect it to: leading padding bytes first followed by formatted days.

I haven't watched it yet, but it seems to be similar to this one from NWCPP I watched recently:

https://www.youtube.com/watch?v=8yV2ONeWXyI

On Wednesday, 30 September 2015 at 01:45:49 UTC, deadalnix wrote:
> https://www.youtube.com/watch?v=mFUXNMfaciE
>
> From
> http://wiki.dlang.org/Component_programming_with_ranges
>
> Congrat H. S. Teoh

D's ranges are inarguably the best part of the language and one of the major reasons to use it despite its shortcomings.

On Wed, Sep 30, 2015 at 10:32:16AM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 09/30/2015 09:31 AM, Steven Schveighoffer wrote:
> >On 9/29/15 9:45 PM, deadalnix wrote:
> >>https://www.youtube.com/watch?v=mFUXNMfaciE
> >>
> >>From http://wiki.dlang.org/Component_programming_with_ranges
> >>
> >>Congrat H. S. Teoh
> >
> >Ditto!
> >
> >Here is the link to the video at the time where D is credited, very nice compliment:
> >
> >https://youtu.be/mFUXNMfaciE?t=115
[...]

I watched most of the video (mainly the first half where he goes through the C++ version of the code), and I have to confess I couldn't help noticing just how ugly the C++ syntax is.

I mean, overloading operator|() for chaining, seriously?  UFCS is
superior any day, IMNSHO.

And overloading operator%() for string interpolation, ugh. (Though this
one seems to be a Boost thing, not specific to the ranges proposal.)

And this is on top of the usual ugliness of C++ template syntax. Not to mention the RANGE_FOREACH macro (I assume it's a macro), where D's foreach has supported natively for years now.  (D has seriously ruined my life; I simply can't bring myself to go back to C++ anymore. At least not voluntarily.)

Also, this seems to confirm that C++ is gradually falling to the position where it's playing catch-up with respect to innovations in newer languages like D and Rust. The fact that ranges are being proposed for the C++ standard library is a big endorsement of D, IMO.

It's also clear that the imperative crowd is slowly but surely moving towards a more functional approach to programming. As the presenter said, having mutable state and branching/looping is what makes code explode in combinatorial complexity, making it hard to analyse, hard to prove correct, and more prone to bugs.

I feel like he didn't hit on the central point of my article, though. The whole thrust behind that article was the idea of impedance mismatch between code structure and data structure, an idea I picked up from the Jackson Structured Programming paradigm in my college years.  When code structure and data structure don't map 1-to-1, there's a structure conflict, and the usual response is to invent ad hoc hacks to compensate for the mismatch, usually in the form of boolean flags or other such band-aids. JSP, however, proposes that the *right* way to resolving the conflict is to change the program structure so that it *does* match the structure of the data.  I have applied this in various forms throughout my career, and have found that it works very well not only in solidifying the way I write loops, but it also gives me a tangible handle on how to better shape the large-scale of my programs.

Where ranges come in, is that ranges, due to their modular, encapsulated nature and their standardized API, essentially guides the programmer into the correct data-matching code structure in an unobtrusive, even spontaneous manner.  In order to make range-based code work at all, you pretty much have to write your code in a way that exactly matches your data -- hacks like boolean flags and other such ugliness are spontaneously excluded (unless you deliberately warp your code to bring them back in -- and who in their right mind would want to do that?).  To me, this is what makes ranges such a great innovation: you get the best of JSP (which I suspect almost nobody these days has even heard about!), many of the benefits of pure functional programming, code readability, testability, etc., all in one package. And it's not even hard to use.


> One great action item is to backport some of Eric's ideas to the D example.  Currently Eric's final code looks nicer than the D code. -- Andrei

Do you have a list of ideas that should be backported?

One that I can think of is using transpose() to do the columnar pasting, instead of the more specific function that I wrote specifically for that purpose. That was very clever, since by making all the formatted months exactly the same dimensions, it avoided the need to write a specific function, but can simply use transpose(). Great idea indeed!


T

-- 
VI = Visual Irritation

On Wednesday, 30 September 2015 at 22:51:24 UTC, H. S. Teoh wrote:
> On Wed, Sep 30, 2015 at 10:32:16AM -0400, Andrei Alexandrescu
[...]
>
> I watched most of the video (mainly the first half where he goes through the C++ version of the code), and I have to confess I couldn't help noticing just how ugly the C++ syntax is.

This is a key reason I am using D. I really like C++14+boost  but that syntax brings me back to D every time.

>
> I mean, overloading operator|() for chaining, seriously?  UFCS is
> superior any day, IMNSHO.

I seem to recall that in a previous on ranges Niebler said that operator|() was simply available and had a vague notion of chaining thanks to *nix shell. He went on to say it would probably need to change to get through the ISO committee.

I hope it does. If the current plans for overloading operator.() get up I wonder how well it would fit as a replacement operator.

>
> And overloading operator%() for string interpolation, ugh. (Though this
> one seems to be a Boost thing, not specific to the ranges proposal.)

This is also a Python thing so it's quite prevelant in the wild. I find D's ~ much nicer, although minutely slower to type than %


>
> And this is on top of the usual ugliness of C++ template syntax. Not to mention the RANGE_FOREACH macro (I assume it's a macro), where D's foreach has supported natively for years now.
>  (D has seriously ruined my life; I simply can't bring myself to go back to C++ anymore. At least not voluntarily.)
>
> Also, this seems to confirm that C++ is gradually falling to the position where it's playing catch-up with respect to innovations in newer languages like D and Rust. The fact that ranges are being proposed for the C++ standard library is a big endorsement of D, IMO.

C++ has been playing catchup for the last 10 yrs and it's been an amazing transition for the language.

If ranges are accepted into ISO C++ I can't imagine it would be long before for(auto e:range).

[snip]
>
>> One great action item is to backport some of Eric's ideas to the D example.  Currently Eric's final code looks nicer than the D code. -- Andrei
>
> Do you have a list of ideas that should be backported?
>

I really liked the namespaces view:: and action:: because it is immediately clear just reading the code what was lazy and what was not.

bye,
lobo

On Thursday, 1 October 2015 at 00:42:43 UTC, lobo wrote:
> If ranges are accepted into ISO C++ I can't imagine it would be long before for(auto e:range).


Special features are not necessary to do this. C++ for loop works on anything with begin()/end() functions. Real ranges could just be a pair of iterators, and lazy ranges could give out dummies:

template<class T>
struct iota
{
    T first, last;

    iota(T first, T last)
        : first(first), last(last) {}

    T front() const { return first; }
    void popFront() { ++first; }
    bool empty() const { return first == last; }

    struct iterator {
        iota *_iota;

        bool operator!=(const iterator& that) const {
            assert(_iota == that._iota);
            return !_iota->empty();
        }

        void operator++() {
            _iota->popFront();
        }

        T operator*() const {
            return _iota->front();
        }
    };

    iterator begin() { return iterator{this}; }
    iterator end() { return iterator{this}; }
};

int main(int argc, const char * argv[])
{
    for(int x : iota<int>(0, 5))
        printf("%d ", x);

    return 0;
}

I don't think it would be that hard to make something this possible:

for(int x : iota<int>(0, 5).to<take>(3))
    printf("%d ", x);

The iterator dummy could probably be generalized with a template.

     Bit

On Thursday, 1 October 2015 at 01:32:17 UTC, bitwise wrote:
> I don't think it would be that hard to make something this possible:
>
> for(int x : iota<int>(0, 5).to<take>(3))
>     printf("%d ", x);


Curiosity got the best of me:
http://ideone.com/RoJxLa

output doesn't show up for some reason, but it works.

    Bit

On Thursday, 1 October 2015 at 01:54:22 UTC, bitwise wrote:
> On Thursday, 1 October 2015 at 01:32:17 UTC, bitwise wrote:
>> I don't think it would be that hard to make something this possible:
>>
>> for(int x : iota<int>(0, 5).to<take>(3))
>>     printf("%d ", x);
>
>
> Curiosity got the best of me:
> http://ideone.com/RoJxLa
>
> output doesn't show up for some reason, but it works.
>
>     Bit

Yes, that's what we have always done with iterators. The point is users shouldn't have to write or instantiate iterators explicitly for any custom range.

bye,
lobo

On Thursday, 1 October 2015 at 02:53:25 UTC, lobo wrote:
> On Thursday, 1 October 2015 at 01:54:22 UTC, bitwise wrote:
>> On Thursday, 1 October 2015 at 01:32:17 UTC, bitwise wrote:
>>> I don't think it would be that hard to make something this possible:
>>>
>>> for(int x : iota<int>(0, 5).to<take>(3))
>>>     printf("%d ", x);
>>
>>
>> Curiosity got the best of me:
>> http://ideone.com/RoJxLa
>>
>> output doesn't show up for some reason, but it works.
>>
>>     Bit
>
> Yes, that's what we have always done with iterators. The point is users shouldn't have to write or instantiate iterators explicitly for any custom range.
>
> bye,
> lobo

I understand, but the C++ committee seems very conservative to me, so when it's this easy to add for(:) support by giving ranges begin()/end() functions, it makes me doubt they will actually change the language for it.

    Bit