On 5/11/2012 12:40 PM, H. S. Teoh wrote:
> Yeah, one of the biggest problems with C++ template syntax is that it
> looks like an alien language. I remember going, "wait, you have to type
> *that* to achieve what can written as a simple loop in normal C++
> code?!"
>
> I couldn't tell you how delighted I was when I saw D's much cleaner and
> clearer template syntax. I mean, it looks just like normal, non-template
> code! Gee, what a concept!

Back when Andrei was writing TDPL, I suggested that he avoid using the word 'template' completely - to simply include type parameters as if they were completely natural. I think this was a very successful approach.

I got the idea after listening to a friend of mine who taught remedial algebra to college students. She said that peoples' brains freeze up when they see "x" in an equation. If she wrote:

   x + 3 = 5

on the board and asked people to "solve for x", they would fail completely. But, if she wrote:

   ( ) + 3 = 5

and asked them to "fill in the circle with the number that makes it work", they all went "of course, it's 2!"


C++ has produced a "gee, templates are hard" mentality, and consequently many people just shut down when they see the word "template".

On Friday, May 11, 2012 20:34:07 Mehrdad wrote:
> On Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:
> >> Actually, that is a WAT even for somebody coming from C/C++.
> > 
> > Really? That's pretty much exactly what I would have expected,
> > and it would
> > really suck if it returned a bool. It's like what you get with
> > find on
> > std::map, only it's a pointer instead of an iterator.
> > 
> > - Jonathan M Davis
> 
> Again, try to see it from the perspective of a Python user, not a C++ user.

Sure, what your used to has a huge effect on what you expect. But I've done very little with python whereas I've done a lot with C++, so my expectations are strongly influenced by C++ but aren't influenced by python at all. I didn't even know that python _had_ an in operator. But when you're dealing with people from a variety of backgrounds, you're invariably going to end up making choices that fit what one set of people expects but confounds another.

- Jonathan M Davis

On Friday, May 11, 2012 21:02:46 Alex Rønne Petersen wrote:
> On 11-05-2012 20:34, Mehrdad wrote:
> > On Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:
> >>> Actually, that is a WAT even for somebody coming from C/C++.
> >> 
> >> Really? That's pretty much exactly what I would have expected, and it
> >> would
> >> really suck if it returned a bool. It's like what you get with find on
> >> std::map, only it's a pointer instead of an iterator.
> >> 
> >> - Jonathan M Davis
> > 
> > Again, try to see it from the perspective of a Python user, not a C++ user.
> 
> Speaking of which, 'in' on arrays.........
> 
> *hint hint*

Except that it would break the generally expected algoritmic complexity of in, so it'll never happen ( O(n) for arrays, whereas the worst case that would be acceptable would be O(lg n) - e.g. what a binary tree could achieve).

- Jonathan M Davis

On 11-05-2012 22:29, Jonathan M Davis wrote:
> On Friday, May 11, 2012 21:02:46 Alex Rønne Petersen wrote:
>> On 11-05-2012 20:34, Mehrdad wrote:
>>> On Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:
>>>>> Actually, that is a WAT even for somebody coming from C/C++.
>>>>
>>>> Really? That's pretty much exactly what I would have expected, and it
>>>> would
>>>> really suck if it returned a bool. It's like what you get with find on
>>>> std::map, only it's a pointer instead of an iterator.
>>>>
>>>> - Jonathan M Davis
>>>
>>> Again, try to see it from the perspective of a Python user, not a
>>> C++ user.
>>
>> Speaking of which, 'in' on arrays.........
>>
>> *hint hint*
>
> Except that it would break the generally expected algoritmic complexity of in,
> so it'll never happen ( O(n) for arrays, whereas the worst case that would be
> acceptable would be O(lg n) - e.g. what a binary tree could achieve).
>
> - Jonathan M Davis

'in' isn't useful in generic code. How it's defined (return type and parameter type) depends entirely on the type being operated on (who says it's an AA? Or a map-like type at all?), so it cannot be used generically in any sensible way.

As such, maintaining any specific algorithmic complexity for it serves no purpose IMHO.

-- 
- Alex

On Friday, 11 May 2012 at 20:20:36 UTC, Jonathan M Davis wrote:
> That's definitely an example of something that depends on your background. std.algorithm.any does _exactly_ what it would do in a functional language.

Well, I know some FP (Scheme/newLISP) but they don't have an "any" function. I don't know about F#, but my guess would be that it would do the same thing as C# would (for obvious reasons).

Are you thinking of a language in particular that has D's behavior? Or is this just a guess?

On Friday, 11 May 2012 at 20:24:40 UTC, Walter Bright wrote:
> C++ has produced a "gee, templates are hard" mentality, and consequently many people just shut down when they see the word "template".

Same thing happens to me when I see a transistor symbol. :P

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.597.1336760569.24740.digitalmars-d@puremagic.com...
>
> Templates are stencils for generating code. There's nothing confusing about that, unless you try to shoehorn them into a preconceived mental model of functions that take parameters and return something.
>
> Granted, proper tutorials need to be written and put in a prominent place so that newbies start on the right footing.
>

https://semitwist.com/articles/article/view/template-primer-in-d

Written. It'd just need to be linked from somewhere, or copied somewhere.

On Friday, 11 May 2012 at 19:02:53 UTC, Mehrdad wrote:
> On Friday, 11 May 2012 at 18:53:57 UTC, H. S. Teoh wrote:
>> On Fri, May 11, 2012 at 08:38:41PM +0200, Mehrdad wrote:
>>> On Friday, 11 May 2012 at 18:21:24 UTC, H. S. Teoh wrote:
>>> >Templates are stencils for generating code. There's nothing
>>> >confusing about that.
>>> 
>>> 
>>> "Stencils for generating code"? _This_??! :O
>>> 
>>>  template hasMember(T, string name)
>>>  { enum hasMember = __traits(hasMember, T, name); }
>>> 
>>> 
>>> Imagine a new user's confusion when seeing something like this.
>>> (Not sure I got it exactly right, but my point is there.)
>>
>> Yes, that's exactly how stencils work. You're essentially generating a declaration of the form:
>>
>> 	enum hasMember = ...;
>>
>> <snip>
>
>
> That's not how you see it when you're learning though.
>
> It's more like, I can imagine someone asking these:
>
> 1. Why the heck do I see "hasMember" twice?
> 2. What does this have to do with enums?
> 3. Where is anything getting "returned"???
> 4. So you mean templates are THINGS?? I thought you needed a template SOMETHING, like a template struct, template function, etc...
> 5. What the heck is TypeTuple!()? Where's the blueprint?
>
>
> etc.

I think TypeTuples originate from Andrei's famous book "Modern C++ Design"(chapter 3: Typelists), so it's essentially known by C++ programmers.
Indeed, it does need some introduction if you haven't been exposed to these before.

On 5/11/12 1:33 PM, Mehrdad wrote:
> On Friday, 11 May 2012 at 18:18:21 UTC, Andrei Alexandrescu wrote:
>> At the same time it clarifies, documents, and statistically verifies
>> that you pass a sorted range. Also, D's binary search works with
>> non-array ranges, but C#'s works only with arrays (which it assumes
>> sorted only by convention).
>>
>> I think we copiously made the right call there.
>>
>> Andrei
>
>
> Right, right, I understand all of that...
>
> But just because the *reasons* are correct that doesn't mean it's more
> intuitive.
>
> ("Intuitive", by definition, means that you have a good chance of
> getting it right without needing to look it up. Binary searching in D
> failed this miserably for me.)

Totally agreed. Intuition is supported by having seen the same or a similar pattern before. In this case D takes an unusual approach, which I think is better than the established approach.

I have added a reference (https://github.com/andralex/phobos/commit/650609be9b4146db3526b50ccfca6776fed73b51) such that searching the page std.algorithm for "binary search" will lead to the correct reference.


Andrei

On Friday, 11 May 2012 at 20:35:53 UTC, Alex Rønne Petersen wrote:
>> Except that it would break the generally expected algoritmic complexity of in,
>> so it'll never happen ( O(n) for arrays, whereas the worst case that would be
>> acceptable would be O(lg n) - e.g. what a binary tree could achieve).
>>
>> - Jonathan M Davis
>
> 'in' isn't useful in generic code. How it's defined (return type and parameter type) depends entirely on the type being operated on (who says it's an AA? Or a map-like type at all?), so it cannot be used generically in any sensible way.
>
> As such, maintaining any specific algorithmic complexity for it serves no purpose IMHO.

I think this has been discussed several times already, and you still haven't convinced any of us.