On 3/14/13 11:05 AM, monarch_dodra wrote:
> Having to instantiate a template just to check to make sure it is
> semantically correct is a huge pain.

I'm not sure about that. The way I see it, no code should be not delivered without being unittested. Ubiquitous unittesting is now mainstream. The way I see it, a type system on top of templates would only help people who don't write unittests.

Andrei

On 3/14/13 11:38 AM, Andrei Alexandrescu wrote:
> On 3/14/13 11:05 AM, monarch_dodra wrote:
>> Having to instantiate a template just to check to make sure it is
>> semantically correct is a huge pain.
>
> I'm not sure about that. The way I see it, no code should be not
> delivered without being unittested. Ubiquitous unittesting is now
> mainstream. The way I see it, a type system on top of templates would
> only help people who don't write unittests.

Uhm sorry for the repetition. Wrote this note in two quanta with a break between them :o).

Andrei

On Thursday, 14 March 2013 at 15:38:53 UTC, Andrei Alexandrescu wrote:
> On 3/14/13 11:05 AM, monarch_dodra wrote:
>> Having to instantiate a template just to check to make sure it is
>> semantically correct is a huge pain.
>
> I'm not sure about that. The way I see it, no code should be not delivered without being unittested. Ubiquitous unittesting is now mainstream. The way I see it, a type system on top of templates would only help people who don't write unittests.
>
> Andrei

The same argument can be made when talking about dynamic vs static typing.

This is usualy much better to have the compiler smash your mistake right into your face than discovering with a unittest much latter.

I don't say that unittest are useless, but why rely on unittest when the machine can do the job for you ?

Andrei Alexandrescu:

> I'm not sure about that. The way I see it, no code should be not delivered without being unittested. Ubiquitous unittesting is now mainstream. The way I see it, a type system on top of templates would only help people who don't write unittests.

This is an invalid argument. You can say the same thing for many (most?) tests done by the compiler. Unit tests can't be sure to verify all code paths inside a function or template. But the tests done by the compiler discussed here are like a type system, that verifies all (or most) code paths at once.

Bye,
bearophile

From http://herbsutter.com/2013/03/14/words-of-wisdom-bjarne-stroustrup/?utm_source=tf&utm_medium=t

Bjarne Stroustrup wrote the following a few minutes ago on the concepts mailing list:

"Let me take this opportunity to remind people that

* "being able to do something is not sufficient reason for doing it" and
* "being able to do every trick is not a feature but a bug"

For the latter, remember Dijkstra’s famous "Goto considered harmful" paper. The point was not that the "new features" (loop constructs) could do every goto trick better/simpler, but that some of those tricks should be avoided to simplify good programming.

Concepts and concepts lite are meant to make good generic programming simpler. They are not meant to be a drop-in substitute for every metaprogramming and macroprogramming trick. If you are an expert, and if in your expert opinion you and your users really need those tricks, you can still use them, but we need to make many (most) uses of templates easier to get right, so that they can become more mainstream. That where concepts and concept lite fits in.

Some of you may find this hard to believe, but "back then" there was quite serious opposition to function declarations because "they restricted the way functions could be used and the way separate compilation could be used" and also serious opposition to virtual functions "because pointers to functions are so much more flexible." I see concepts lite (and concepts) in the same light as goto/for, unchecked-function-arguments/function-declarations, pointers-to-functions/abstract-classes."

On 3/14/13 11:50 AM, deadalnix wrote:
> On Thursday, 14 March 2013 at 15:38:53 UTC, Andrei Alexandrescu wrote:
>> On 3/14/13 11:05 AM, monarch_dodra wrote:
>>> Having to instantiate a template just to check to make sure it is
>>> semantically correct is a huge pain.
>>
>> I'm not sure about that. The way I see it, no code should be not
>> delivered without being unittested. Ubiquitous unittesting is now
>> mainstream. The way I see it, a type system on top of templates would
>> only help people who don't write unittests.
>>
>> Andrei
>
> The same argument can be made when talking about dynamic vs static typing.

And it has been made indeed. The question is on agreeing or not with specifics. The stereotypical argument in favor of dynamic typing goes as follows:

Q: Does static typing detect all bugs?

A: No.

Q: Then unittests are necessary.

A: Correct.

Q: So if static typing is insufficient, why not rely on unittests alone to do all checking? It's also bothersome for some people to obey types, annotate stuff etc.

A: There are still errors that can be better detected with static checking, and many dynamic programs that work by accident etc.

Q: ... I agree or don't agree ...

> This is usualy much better to have the compiler smash your mistake right
> into your face than discovering with a unittest much latter.

I don't think so.

> I don't say that unittest are useless, but why rely on unittest when the
> machine can do the job for you ?

In both cases the machine does the work. My argument is that adding an additional layer of typing on top of templates caters to people who want to ship code that has literally zero testing. That's not a priority as far as I'm concerned.


Andrei

On 3/14/13 12:32 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> I'm not sure about that. The way I see it, no code should be not
>> delivered without being unittested. Ubiquitous unittesting is now
>> mainstream. The way I see it, a type system on top of templates would
>> only help people who don't write unittests.
>
> This is an invalid argument. You can say the same thing for many (most?)
> tests done by the compiler.

No, this is different.

Andrei

Andrei Alexandrescu:

> No, this is different.

Why?

Bye,
bearophile

On Thursday, 14 March 2013 at 16:48:29 UTC, Andrei Alexandrescu wrote:
> And it has been made indeed. The question is on agreeing or not with specifics. The stereotypical argument in favor of dynamic typing goes as follows:
>
> Q: Does static typing detect all bugs?
>
> A: No.
>
> Q: Then unittests are necessary.
>
> A: Correct.
>
> Q: So if static typing is insufficient, why not rely on unittests alone to do all checking? It's also bothersome for some people to obey types, annotate stuff etc.
>
> A: There are still errors that can be better detected with static checking, and many dynamic programs that work by accident etc.
>

I see we agree this is the same problem materialized in another form. I find it rather weird that you conclude different things when the problem is the same in the first place.

>> I don't say that unittest are useless, but why rely on unittest when the
>> machine can do the job for you ?
>
> In both cases the machine does the work. My argument is that adding an additional layer of typing on top of templates caters to people who want to ship code that has literally zero testing. That's not a priority as far as I'm concerned.
>

I have other benefit, as the capability for the compiler to give understandable error message instead of a wall of template errors.

This is clearly not a priority anyway. We should stop building on foundation that aren't solid or everything will collapse.

Andrei Alexandrescu:

>> This is usualy much better to have the compiler smash your mistake right
>> into your face than discovering with a unittest much latter.
>
> I don't think so.

Why?


> My argument is that adding an additional layer of typing on top of templates caters to people who want to ship code that has literally zero testing. That's not a priority as far as I'm concerned.

If those people want yo write zero unit tests, they will write zero unit tests in both cases. I have seen D code like that. Introducing some compiler tests isn't going to make that situation worse and it's able to give better&nicer error messages when you have just written a template and you have not yet written a unittest (assuming you aren't using Test-Driven-Development).

A template unittest often doesn't cover all possible instantiations of a template. So some compiler tests that work on all possible instantiations can help.

You can also look at the situation from the other way: assuming you are correct, what currently present compiler tests do you want to remove?

Bye,
bearophile