On Sat, Jun 22, 2013 at 06:17:41PM +0200, Andrej Mitrovic wrote:
> I remember just a few years ago I was avoiding learning to use templates, thinking they're super-complicated and that I'd **never** actually need them. I used to read about them in the pages of the language reference, but nothing actually *clicked* while reading those pages.

Funny, templates were one of the main reasons I came to D. C++ templates were (and still are) just so ugly and painful to work with.


> I also remember reading about the `is()` keyword which was the most intriguing but complex thing on the whole website that I just couldn't wrap my head around.

Yeah that one made my eyes glaze over. I still have trouble wrapping my brain around the strange syntax of is(), and why its diverse uses have been shoehorned into deceptively similar syntax.


[...]
> I wonder if newbies still get a little scared when they reach the template section on dlang, and if we can improve this somehow. There *are* tutorials out there, but dlang.org is probably where the user gets his first impression of the language, and it has to be an inviting one.

I like the way Andrei presented templates in TDPL: he just started using them without saying what they are, other than that the function takes "compile-time parameters". By the time you get to the chapter on templates, you've already been using them for a while, so it's not very scary anymore.


> Anyway, what features are you using now that you thought you'd never use when you started out using D?

1) Unittests. :) "Who needs unittests", I told myself, "when I'm obviously smart enough to write code once and have it work the first time?" But they just kept staring at me going "hey we're right here, use us!" until I was shamed into actually writing a few of them. And then I discovered that I *wasn't* the genius programmer I thought I was, and that my code was actually full of bugs, typos, and all sorts of other problems that only show up in corner cases that, of course, I'd failed to test by hand the first time round.

2) Ddoc comments. I'm still not fully sold on ddoc, but I've actually started using it for my personal code libraries, and it's actually quite nice. I don't have to install DOxygen and add a whole bunch of language-external stuff to my projects to actually use ddoc -- another big advantage conferred by having them built into the compiler. The default ddoc macros leave a lot to be desired, but I cooked up a simple set of customized macros to make the output more palatable, and ddoc is actually pleasant to work with now:

<shameless plug>
https://github.com/quickfur/Viola-ddoc-macros
</shameless plug>


T

-- 
Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Michael Beibl

Hi H. S. Teoh, I noticed that when you replied to a post, your
reply usually started a new thread instead of showing in the thread the original post belongs to, this makes readers difficult follow original discussions.

On Saturday, 22 June 2013 at 16:42:24 UTC, H. S. Teoh wrote:
> On Sat, Jun 22, 2013 at 06:17:41PM +0200, Andrej Mitrovic wrote:
>> I remember just a few years ago I was avoiding learning to use
>> templates, thinking they're super-complicated and that I'd **never**
>> actually need them. I used to read about them in the pages of the
>> language reference, but nothing actually *clicked* while reading those
>> pages.
>
> Funny, templates were one of the main reasons I came to D. C++ templates
> were (and still are) just so ugly and painful to work with.
>
>
>> I also remember reading about the `is()` keyword which was the
>> most intriguing but complex thing on the whole website that I just
>> couldn't wrap my head around.
>
> Yeah that one made my eyes glaze over. I still have trouble wrapping my
> brain around the strange syntax of is(), and why its diverse uses have
> been shoehorned into deceptively similar syntax.
>
>
> [...]
>> I wonder if newbies still get a little scared when they reach the
>> template section on dlang, and if we can improve this somehow. There
>> *are* tutorials out there, but dlang.org is probably where the user
>> gets his first impression of the language, and it has to be an
>> inviting one.
>
> I like the way Andrei presented templates in TDPL: he just started using
> them without saying what they are, other than that the function takes
> "compile-time parameters". By the time you get to the chapter on
> templates, you've already been using them for a while, so it's not very
> scary anymore.
>
>
>> Anyway, what features are you using now that you thought you'd never
>> use when you started out using D?
>
> 1) Unittests. :) "Who needs unittests", I told myself, "when I'm
> obviously smart enough to write code once and have it work the first
> time?" But they just kept staring at me going "hey we're right here, use
> us!" until I was shamed into actually writing a few of them. And then I
> discovered that I *wasn't* the genius programmer I thought I was, and
> that my code was actually full of bugs, typos, and all sorts of other
> problems that only show up in corner cases that, of course, I'd failed
> to test by hand the first time round.
>
> 2) Ddoc comments. I'm still not fully sold on ddoc, but I've actually
> started using it for my personal code libraries, and it's actually quite
> nice. I don't have to install DOxygen and add a whole bunch of
> language-external stuff to my projects to actually use ddoc -- another
> big advantage conferred by having them built into the compiler. The
> default ddoc macros leave a lot to be desired, but I cooked up a simple
> set of customized macros to make the output more palatable, and ddoc is
> actually pleasant to work with now:
>
> <shameless plug>
> https://github.com/quickfur/Viola-ddoc-macros
> </shameless plug>
>
>
> T

On 06/22/2013 05:17 PM, Andrej Mitrovic wrote:
> Anyway, what features are you using now that you thought you'd never use when you started out using D?

Ranges, of course :-)

When I was first using D I knew that there were these things called ranges that were supposedly D's superior solution to what C++ did with iterators, but I didn't really understand what they were in practice, beyond the fact that they were these things that one could foreach() over.

It didn't take too long to get the hang of using some of the entities from std.range (iota is a favourite), but what I hadn't imagined was that I'd actually start writing ranges myself as a habitual part of program design. These days I do so all the time.

On Saturday, 22 June 2013 at 19:40:28 UTC, Joseph Rushton Wakeling wrote:
> On 06/22/2013 05:17 PM, Andrej Mitrovic wrote:
>> Anyway, what features are you using now that you thought you'd never
>> use when you started out using D?
>
> Ranges, of course :-)
>
> When I was first using D I knew that there were these things called ranges that
> were supposedly D's superior solution to what C++ did with iterators, but I
> didn't really understand what they were in practice, beyond the fact that they
> were these things that one could foreach() over.
>
> It didn't take too long to get the hang of using some of the entities from
> std.range (iota is a favourite), but what I hadn't imagined was that I'd
> actually start writing ranges myself as a habitual part of program design.
> These days I do so all the time.

Personally, I've found ranges to be a very useful and powerful *high level* abstraction. They lend themselves work very well for adapting and chaining (which iterators don't). However, they do come with *some* downsides (IMO):
#1: Performance issues: No matter how I use them, it seems that I can never get the same raw performance I could get with raw iterator iteration.*
#2: Extremelly bad compatibility with simple no bidir/non-slicing ranges: There is no way to iterate over a specific part of a range, and making a range out of what was just iterated over. For example "Get the beggining of this range until the first x": not possible without slicing.
#3: Take up more room when all you want to do is to keep a reference to a single item.

*Overall*, I think they are win of course, and much easier to use and scale much better than iterators, but iterators *can* do things that ranges can't.

*: #1 is subject to simple iteration: Once things scale in terms of adaptors, ranges win because of the "single item empty" mechanic

On 2013-06-22 18:40, H. S. Teoh wrote:

> Yeah that one made my eyes glaze over. I still have trouble wrapping my
> brain around the strange syntax of is(), and why its diverse uses have
> been shoehorned into deceptively similar syntax.

Isn't quite a lot of the is-expression features undocumented?

-- 
/Jacob Carlborg

On 06/22/2013 09:08 PM, monarch_dodra wrote:
> Personally, I've found ranges to be a very useful and powerful *high level* abstraction. They lend themselves work very well for adapting and chaining (which iterators don't). However, they do come with *some* downsides (IMO): #1: Performance issues: No matter how I use them, it seems that I can never get the same raw performance I could get with raw iterator iteration.*

Do you think that's inevitable?  I'd have thought that this ought to be possible to improve with better compiler optimizations.

> *: #1 is subject to simple iteration: Once things scale in terms of adaptors, ranges win because of the "single item empty" mechanic

Could you explain that in a bit more depth, please?

> #2: Extremelly bad compatibility with simple no bidir/non-slicing ranges: There is no way to iterate over a specific part of a range, and making a range out of what was just iterated over. For example "Get the beggining of this range until the first x": not possible without slicing.

Not sure what you mean here -- doesn't the attached little code example do roughly what you're looking for?  (N.B. it has crap template constraints. Typing this quickly I couldn't work out how to make sure that the second constructor argument matches the type of input.front.)

On Saturday, 22 June 2013 at 21:28:47 UTC, Joseph Rushton Wakeling wrote:
> On 06/22/2013 09:08 PM, monarch_dodra wrote:
>> Personally, I've found ranges to be a very useful and powerful *high level*
>> abstraction. They lend themselves work very well for adapting and chaining
>> (which iterators don't). However, they do come with *some* downsides (IMO):
>> #1: Performance issues: No matter how I use them, it seems that I can never get
>> the same raw performance I could get with raw iterator iteration.*
>
> Do you think that's inevitable?  I'd have thought that this ought to be possible
> to improve with better compiler optimizations.

Yeah, most probably. But as is, the:

for ( ; !r.empty ; r.popFront())
    something with front;

Always seems slower to me, even for arrays.

But this is probably indeed a compiler issue, so yeah, not a real issue.

>> *: #1 is subject to simple iteration: Once things scale in terms of adaptors,
>> ranges win because of the "single item empty" mechanic
>
> Could you explain that in a bit more depth, please?

I mean that once you have an iota=>map=>filter=>whatnot...

This scales well with ranges. With iterators though, you increase the complexity by 2 (front + back iterator) for every level. This ends up making the checks more expensive they they should be, when the iteration scheme doesn't actually need an "end" to know it has already reached it.

Not sure that's very clear...?

>> #2: Extremelly bad compatibility with simple no bidir/non-slicing ranges: There
>> is no way to iterate over a specific part of a range, and making a range out of
>> what was just iterated over. For example "Get the beggining of this range until
>> the first x": not possible without slicing.
>
> Not sure what you mean here -- doesn't the attached little code example do
> roughly what you're looking for?  (N.B. it has crap template constraints.
> Typing this quickly I couldn't work out how to make sure that the second
> constructor argument matches the type of input.front.)

Not sure what example you are referring to, but a more complete thread about it was here:
The rfind challenge
http://forum.dlang.org/thread/kd2qok$16e6$1@digitalmars.com

long story short: we don't have rfind. C++ does.

On 06/22/2013 10:58 PM, monarch_dodra wrote:
> I mean that once you have an iota=>map=>filter=>whatnot...
> 
> This scales well with ranges. With iterators though, you increase the complexity by 2 (front + back iterator) for every level. This ends up making the checks more expensive they they should be, when the iteration scheme doesn't actually need an "end" to know it has already reached it.
> 
> Not sure that's very clear...?

Clear enough :-)

> Not sure what example you are referring to, but a more complete thread about it
> was here:
> The rfind challenge
> http://forum.dlang.org/thread/kd2qok$16e6$1@digitalmars.com
> 
> long story short: we don't have rfind. C++ does.

Oh, I see.  Different problem from what I thought you were asking.  I must have missed that discussion when it came around the first time.

On Sat, Jun 22, 2013 at 07:35:30PM +0200, DLearner wrote:
> Hi H. S. Teoh, I noticed that when you replied to a post, your reply usually started a new thread instead of showing in the thread the original post belongs to, this makes readers difficult follow original discussions.
[...]

I'm using the mailing list interface, that's why.  This is a bug in Mailman; it rewrites message IDs where it should not. Somebody pointed it out already, but apparently nothing has been fixed yet. :-(


T

-- 
Не дорог подарок, дорога любовь.

On Sat, Jun 22, 2013 at 10:57:53PM +0200, Jacob Carlborg wrote:
> On 2013-06-22 18:40, H. S. Teoh wrote:
> 
> >Yeah that one made my eyes glaze over. I still have trouble wrapping my brain around the strange syntax of is(), and why its diverse uses have been shoehorned into deceptively similar syntax.
> 
> Isn't quite a lot of the is-expression features undocumented?
[...]

Really? Well, even if so, the cases that *are* currently documented share a lot of syntax, but aren't necessarily related in a way that the syntax might imply. This is very confusing. One example that comes to mind is using is(T _ == U) instead of is(T == U). I'm guessing most people don't even know what the difference is, or why a dummy identifier _ has to be added.


T

-- 
Let's call it an accidental feature. -- Larry Wall