On Monday, 3 March 2014 at 18:46:24 UTC, Chris wrote:
> On Monday, 3 March 2014 at 18:03:12 UTC, Frustrated wrote:
>> On Sunday, 2 March 2014 at 11:47:39 UTC, Steve Teale wrote:
>>> On Sunday, 2 March 2014 at 10:05:05 UTC, Dicebot wrote:
>>>
>>>>
>>>> There is nothing wrong about not using templates. Almost any compile-time design can be moved to run-time and expressed in more common OOP form. And using tool you have mastery of is usually more beneficial in practice than following the hype.
>>>
>>> Yes DB, we can soldier on happily, but it would not do any harm to understand templates.
>>>
>>> The documentation examples quickly make your eyes glaze over, looking at the code in Phobos is doubtless instructive, but you can wade through a lot of that without finding what you want. Also I discovered an interesting fact today. the word 'mixin' does not appear in the language reference Templates section of dlang.org.
>>>
>>> It should be used in at least one example. I just discovered by trial and error that I could use 'mixin' in Templates (as opposed to Template Mixins), and when you know that it seems likely that you can accomplish lots of stuff you couldn't before.
>>>
>>> While I'm here, has anyone discovered a way to fudge a constructor super(..) call in a mixin template that's included in a class constructor. Since the mixin template is evaluated in the scope of the constructor, it seems like it should be OK.
>>>
>>> I'm sure I'll get there in time ;=)
>>>
>>> Steve
>>
>> You've got to learn to think a bit more abstractly. Templates are generalizations of things.
>
> I think the problem is not that people don't understand templates in the sense that they are abstractions. The question is whether there are loads and loads of use cases for them.

It is irrelevant if there are loads and loads of use cases for them. Just because people don't use something doesn't mean it is useless.

>> Suppose I want to add two numbers using a function.
>>
>> int add(int, int)?
>> double add(double, int)?
>> float add(float, int)?
>> char add(char, double)?
>> etc....
>>
>> which one? Do you want to have to create a function every time for every time?
>
> This is a typical use case and always mentioned in tutorials. The question is how many of these "typical" cases one encounters while writing software.

Look at the STL library if you do't believe templates are useful...

> I think another problem with templates is that it is not always clear what is abstracted. The type or the logic? Both? In the above example the logic remains the same and is reproduced by the compiler for each type. Sometimes the logic can be abstracted for which type independence is important. But I'm not sure if that can be called a template in the purest sense. E.g. an algorithm that finds the first instance of something might be different for each type (string, char, int) and the "abstract" implementation has to differentiate internally (if string > else if int > else if ...). But this is no longer a template, or is it?
>

Both logic and types are abtracted. Even though the template might use the same operator, the compiler must determine which concrete operator to use.

The addition between the two abstract objects also requires an abstract operator.

The great thing is, because the abstract logic is identical("adding two things") makes the template actually useful. If it wasn't we would have to specialize the template for all the different possible binary combinations and then it would defeat the simplification that abstract is suppose to offer.

The the logical process is used when one looks at procedural code and realizes that one can "simplify" it by using oop.

Templates give you the same power over oop that oop gives over non-oop. But just because templates[oop] are available doesn't mean you have to use it or it is always the best solution.

I use templates all the time. I create them to simplify some task then put them in a library. For me, templates allow me to streamline things that I couldn't otherwise do. Any time I feel like something is being repeated a lot I automatically think that a templates will help. I hate "copying and pasting" and so I tend to use templates a lot.

One of the main uses of templates is compile time type safety. This is necessary with oop because oop allows one to create types at compile time. Hence, the need to be able to make your oop "safe" is a natural step and templates help you accomplish that.

e.g., Array's of objects vs Array's of a Type. One is much safer, informs the about what your intentions are so it can make better informed decisions.

e.g., Array!Type allows the Array to determine if the Type supports certain things at **compile time**. Array!Object can't do this at compile time.

If you can't see the benefit of Array!Type vs Array!Object then you are beyond help. (this is not to say Array!Object is always useless, but it is the most generic you can get and the compiler can do little to help the situation)

I'll give you a simple example: One could create an Array type that allows one to traverse the array in a multitude of ways. Suppose the objects stored by the arrays are arrays themselves. If the Array is templated it could easily figure this out and create an iterator that iterates over the sub-array(calling its iterator).

This way one could easily display a flat list of the array [of arrays [of arrays ...]]. Because the Array type could figure out all this at compile time it would be way more efficient than having to use run-time reflection to determine of the object is an array and if it has the iterator. (it would also be easier to code)

Basically you have the choice:

------------ <- "template" way of thinking (more general than oop)
-------- <- Oop way of thinking (more general than procedural)
----- <- procedural way of thinking... "Old School"
- <- Punch Cards

(it's not quite that simple as templates or more of an offshoot of oop)

If you are thinking at the template level then you will know when to use templates. If you are thinking at the oop level, you always go for your oop hammer(duh, cause everything looks like an oop nail). If you are thinking at the procedural level then you always try to solve problems in the procedural way.

I prefer the top-down approach... Call me a racist but I just hate punch cards.

On Monday, 3 March 2014 at 22:50:18 UTC, Frustrated wrote:
> On Monday, 3 March 2014 at 18:46:24 UTC, Chris wrote:

>> I think the problem is not that people don't understand templates in the sense that they are abstractions. The question is whether there are loads and loads of use cases for them.
>
> It is irrelevant if there are loads and loads of use cases for them. Just because people don't use something doesn't mean it is useless.

Nobody ever said this.

to have to create a function every

>> This is a typical use case and always mentioned in tutorials. The question is how many of these "typical" cases one encounters while writing software.
>
> Look at the STL library if you do't believe templates are useful...
>
>> I think another problem with templates is that it is not always clear what is abstracted. The type or the logic? Both? In the above example the logic remains the same and is reproduced by the compiler for each type. Sometimes the logic can be abstracted for which type independence is important. But I'm not sure if that can be called a template in the purest sense. E.g. an algorithm that finds the first instance of something might be different for each type (string, char, int) and the "abstract" implementation has to differentiate internally (if string > else if int > else if ...). But this is no longer a template, or is it?
>>
>
> Both logic and types are abtracted. Even though the template might use the same operator, the compiler must determine which concrete operator to use.
>
> The addition between the two abstract objects also requires an abstract operator.
>
> The great thing is, because the abstract logic is identical("adding two things") makes the template actually useful. If it wasn't we would have to specialize the template for all the different possible binary combinations and then it would defeat the simplification that abstract is suppose to offer.

Purely philosophical remark: You're talking about the level of how the compiler implements it. The logic (a+b) is not abstracted but the same in every case. How the compiler has to deal with it in every case is irrelevant for the concept of templates, because it's the same as writing:

int add(int a, int b) { return a+b;}
int add(double a, double b) { return a+b;}
etc.

> The the logical process is used when one looks at procedural code and realizes that one can "simplify" it by using oop.
>
> Templates give you the same power over oop that oop gives over non-oop. But just because templates[oop] are available doesn't mean you have to use it or it is always the best solution.
>
> I use templates all the time. I create them to simplify some task then put them in a library. For me, templates allow me to streamline things that I couldn't otherwise do. Any time I feel like something is being repeated a lot I automatically think that a templates will help. I hate "copying and pasting" and so I tend to use templates a lot.

I'm starting to do the same thing. But my experience (so far) has been that abstraction goes only so far and a template only covers, say, 2 cases instead of 4 and I have to write 2 separate templates. Granted, in the old days, I would have written a class that handles all four cases, so it saves me some coding. But in may applications, templates are not really necessary. If you write a program that deals with strings, most functions will take a string as an input and return a string (or an array of strings) as an output. This is at least my experience. If code is repeated all over again, you put it into a separate function/method/class/struct anyway. I find myself using ranges quite a lot.

> One of the main uses of templates is compile time type safety. This is necessary with oop because oop allows one to create types at compile time. Hence, the need to be able to make your oop "safe" is a natural step and templates help you accomplish that.
>
> e.g., Array's of objects vs Array's of a Type. One is much safer, informs the about what your intentions are so it can make better informed decisions.
>
> e.g., Array!Type allows the Array to determine if the Type supports certain things at **compile time**. Array!Object can't do this at compile time.

Yes, we have useful template constraints (isInputRange etc).

> If you can't see the benefit of Array!Type vs Array!Object then you are beyond help. (this is not to say Array!Object is always useless, but it is the most generic you can get and the compiler can do little to help the situation)
>
> I'll give you a simple example: One could create an Array type that allows one to traverse the array in a multitude of ways. Suppose the objects stored by the arrays are arrays themselves. If the Array is templated it could easily figure this out and create an iterator that iterates over the sub-array(calling its iterator).
>
> This way one could easily display a flat list of the array [of arrays [of arrays ...]]. Because the Array type could figure out all this at compile time it would be way more efficient than having to use run-time reflection to determine of the object is an array and if it has the iterator. (it would also be easier to code)
>
> Basically you have the choice:
>
> ------------ <- "template" way of thinking (more general than oop)
> -------- <- Oop way of thinking (more general than procedural)
> ----- <- procedural way of thinking... "Old School"
> - <- Punch Cards
>
> (it's not quite that simple as templates or more of an offshoot of oop)

Maybe that's why it is so hard to see the benefits of templates, because many cases (of abstraction) are already covered by OOP. I like templates, but I'm not sure if they are as useful as D's ranges. Ranges and component programming handle the ubiquitous input>filter>output paradigm present in every program and help to break down the program's logic into digestible chunks, a logic you cannot just copy and paste (but you can reuse the chunks). In cases where you use templates, you can also get away with copy and paste and replace "int" with "double".

> If you are thinking at the template level then you will know when to use templates. If you are thinking at the oop level, you always go for your oop hammer(duh, cause everything looks like an oop nail). If you are thinking at the procedural level then you always try to solve problems in the procedural way.
>
> I prefer the top-down approach... Call me a racist but I just hate punch cards.

On Tue, Mar 04, 2014 at 10:32:52AM +0000, Chris wrote: [...]
> Maybe that's why it is so hard to see the benefits of templates, because many cases (of abstraction) are already covered by OOP. I like templates, but I'm not sure if they are as useful as D's ranges. Ranges and component programming handle the ubiquitous input>filter>output paradigm present in every program and help to break down the program's logic into digestible chunks, a logic you cannot just copy and paste (but you can reuse the chunks). In cases where you use templates, you can also get away with copy and paste and replace "int" with "double".
[...]

Ranges in D will be nowhere as convenient as they are today without templates. When you write your own components, you basically have to use templates in order to not incur unacceptable overhead (or impose arbitrary limitations on usage -- such as requiring something to be derived from some chosen base class).


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte

On Tuesday, 4 March 2014 at 15:52:37 UTC, H. S. Teoh wrote:
> On Tue, Mar 04, 2014 at 10:32:52AM +0000, Chris wrote:
> [...]
>> Maybe that's why it is so hard to see the benefits of templates,
>> because many cases (of abstraction) are already covered by OOP. I
>> like templates, but I'm not sure if they are as useful as D's
>> ranges. Ranges and component programming handle the ubiquitous
>> input>filter>output paradigm present in every program and help to
>> break down the program's logic into digestible chunks, a logic you
>> cannot just copy and paste (but you can reuse the chunks). In cases
>> where you use templates, you can also get away with copy and paste
>> and replace "int" with "double".
> [...]
>
> Ranges in D will be nowhere as convenient as they are today without
> templates. When you write your own components, you basically have to use
> templates in order to not incur unacceptable overhead (or impose
> arbitrary limitations on usage -- such as requiring something to be
> derived from some chosen base class).
>
>
> T

True, true. The fact that the compiler can check for the right types is great.

Btw, the quote you have in this post:

Never ascribe to malice that which is adequately explained by
incompetence. -- Napoleon Bonaparte

I'm surprised that Napoleon would say something like this. Malice is often a characteristic of the incompetent. The only way to get the better of their betters. :-)

On Tue, Mar 04, 2014 at 06:19:38PM +0000, Chris wrote:
> On Tuesday, 4 March 2014 at 15:52:37 UTC, H. S. Teoh wrote:
> >On Tue, Mar 04, 2014 at 10:32:52AM +0000, Chris wrote: [...]
> >>Maybe that's why it is so hard to see the benefits of templates, because many cases (of abstraction) are already covered by OOP.  I like templates, but I'm not sure if they are as useful as D's ranges. Ranges and component programming handle the ubiquitous input>filter>output paradigm present in every program and help to break down the program's logic into digestible chunks, a logic you cannot just copy and paste (but you can reuse the chunks). In cases where you use templates, you can also get away with copy and paste and replace "int" with "double".
> >[...]
> >
> >Ranges in D will be nowhere as convenient as they are today without templates. When you write your own components, you basically have to use templates in order to not incur unacceptable overhead (or impose arbitrary limitations on usage -- such as requiring something to be derived from some chosen base class).
> >
> >
> >T
> 
> True, true. The fact that the compiler can check for the right types is great.
> 
> Btw, the quote you have in this post:
> 
> Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte
> 
> I'm surprised that Napoleon would say something like this. Malice is often a characteristic of the incompetent. The only way to get the better of their betters. :-)

I'm not sure if that attribution is accurate. Nick has pointed out to me that he knows the same quote attributed to someone else, so this may be a case of internet misattribution (I picked up that quote from somewhere online, way back when -- no idea if the source was reliable, y'know, being the internet and everything).


T

-- 
I am not young enough to know everything. -- Oscar Wilde

On Tue, 2014-03-04 at 10:27 -0800, H. S. Teoh wrote:
> On Tue, Mar 04, 2014 at 06:19:38PM +0000, Chris wrote:
[…]
> > True, true. The fact that the compiler can check for the right types is great.
> > 
> > Btw, the quote you have in this post:
> > 
> > Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte
> > 
> > I'm surprised that Napoleon would say something like this. Malice is often a characteristic of the incompetent. The only way to get the better of their betters. :-)
> 
> I'm not sure if that attribution is accurate. Nick has pointed out to me that he knows the same quote attributed to someone else, so this may be a case of internet misattribution (I picked up that quote from somewhere online, way back when -- no idea if the source was reliable, y'know, being the internet and everything).

I present you the following, which between then give a good account of the whole situation. Sort of. Possibly.

http://en.wikipedia.org/wiki/Hanlon's_razor https://www.princeton.edu/~achaney/tmve/wiki100k/docs/Hanlon_s_razor.html http://blog.writch.com/2009/04/hanlons-razor-which-i-knew-as-heinleins-razor.html

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sunday, 2 March 2014 at 11:47:39 UTC, Steve Teale wrote:
> I just discovered by trial and error that I could use 'mixin' in Templates (as opposed to Template Mixins), and when you know that it seems likely that you can accomplish lots of stuff you couldn't before.

This was asked about recently.

   mixin template ...

This is the correct way to declare a template to use in mixins, several of us are surprised that you can still mixin a template which wasn't declared in this manner. I've created a bug so an official statement can be made on it:

https://d.puremagic.com/issues/show_bug.cgi?id=12298

On Tue, Mar 04, 2014 at 07:23:49PM +0000, Jesse Phillips wrote:
> On Sunday, 2 March 2014 at 11:47:39 UTC, Steve Teale wrote:
> >I just discovered by trial and error that I could use 'mixin' in Templates (as opposed to Template Mixins), and when you know that it seems likely that you can accomplish lots of stuff you couldn't before.
> 
> This was asked about recently.
> 
>    mixin template ...
> 
> This is the correct way to declare a template to use in mixins, several of us are surprised that you can still mixin a template which wasn't declared in this manner. I've created a bug so an official statement can be made on it:
> 
> https://d.puremagic.com/issues/show_bug.cgi?id=12298

I'm pretty sure that's a bug, since TDPL clearly distinguishes between templates and mixin templates. But if this bug leads to interesting use case, maybe it's a case of an unintentional feature? :-P


T

-- 
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce

On Tuesday, 4 March 2014 at 19:18:28 UTC, Russel Winder wrote:
> On Tue, 2014-03-04 at 10:27 -0800, H. S. Teoh wrote:
>> On Tue, Mar 04, 2014 at 06:19:38PM +0000, Chris wrote:
> […]
>> > True, true. The fact that the compiler can check for the right types
>> > is great.
>> > 
>> > Btw, the quote you have in this post:
>> > 
>> > Never ascribe to malice that which is adequately explained by
>> > incompetence. -- Napoleon Bonaparte
>> > 
>> > I'm surprised that Napoleon would say something like this. Malice is
>> > often a characteristic of the incompetent. The only way to get the
>> > better of their betters. :-)
>> 
>> I'm not sure if that attribution is accurate. Nick has pointed out to me
>> that he knows the same quote attributed to someone else, so this may be
>> a case of internet misattribution (I picked up that quote from somewhere
>> online, way back when -- no idea if the source was reliable, y'know,
>> being the internet and everything).
>
> I present you the following, which between then give a good account of
> the whole situation. Sort of. Possibly.
>
> http://en.wikipedia.org/wiki/Hanlon's_razor
> https://www.princeton.edu/~achaney/tmve/wiki100k/docs/Hanlon_s_razor.html
> http://blog.writch.com/2009/04/hanlons-razor-which-i-knew-as-heinleins-razor.html

This reminds me of Cipolla's laws of human stupidity. Put this into your search engine:

Basic Laws of Human Stupidity, Carlo M. Cipolla

Also: https://en.wikipedia.org/wiki/Carlo_M._Cipolla

Enjoy!

On Tue, Mar 04, 2014 at 07:18:17PM +0000, Russel Winder wrote:
> On Tue, 2014-03-04 at 10:27 -0800, H. S. Teoh wrote:
> > On Tue, Mar 04, 2014 at 06:19:38PM +0000, Chris wrote:
[...]
> > > Btw, the quote you have in this post:
> > > 
> > > Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte
> > > 
> > > I'm surprised that Napoleon would say something like this. Malice is often a characteristic of the incompetent. The only way to get the better of their betters. :-)
> > 
> > I'm not sure if that attribution is accurate. Nick has pointed out to me that he knows the same quote attributed to someone else, so this may be a case of internet misattribution (I picked up that quote from somewhere online, way back when -- no idea if the source was reliable, y'know, being the internet and everything).
> 
> I present you the following, which between then give a good account of the whole situation. Sort of. Possibly.
> 
> http://en.wikipedia.org/wiki/Hanlon's_razor https://www.princeton.edu/~achaney/tmve/wiki100k/docs/Hanlon_s_razor.html http://blog.writch.com/2009/04/hanlons-razor-which-i-knew-as-heinleins-razor.html
[...]

Whoa. So this is one of those things that nobody knows for sure where it
came from? :) My new favorite version of it is (allegedly) Elbert
Hubbard's:

	Genius may have its limitations, but stupidity is not thus
	handicapped.

That's going into my quotes file... :)


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG