On 04/14/2011 02:56 AM, bearophile wrote:
> Andrei:
>
>> I disagree. I find examples that use assert() much clearer than examples
>> that print something to the console and then explain in a comment what
>> you ought to be seeing.
>
> I don't understand why you say that. Isn't learning and understanding based on feedback? If all the examples do is to show the same "assert passed" message, then what's the point in running the examples? Just reading a static page gives the same insight. You are able to modify them, of course, and see the modified asserts fail, and you may add a writeln statement yourself, but... having to modify each example to see some feedback is not a good default. I'd like to know if other people agree with you on this.

I more or less agree with both of you. My problem with using asserts in code samples is:
* It's not a feature all languages have, thus readers may not know it (well).
* Asserts in sample is clever "highjacking" of a language feature for a clever side-effect.

The point of assert in true code is to catch a potential bug. The point of assert in sample code is to bring information to the reader, like if saying "this predicate holds here":
   assert(3/2 == 1);
Maybe an alias of assert for such use would help? (but I cannot find one) Or a simple comment would do the job better:
   // 3/2 == 1

I long for a different assert that would take one expression and a result, and writse out when 'assertMode' is 'verbose':
   assert(3/2, &);
   // outputs "3/2 : 1"
Then, we get both silent and verbose asserts in one go; the former for regression testing, the latter mode for diagnose or examples.

I currently do it that way:
    auto n = 3/2;
    writefln("3/2: %s, n);	// commented out for regression test
    assert(n == 1);

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 04/14/2011 03:04 AM, Adam D. Ruppe wrote:
> bearophile wrote:
>> >  This is a problem. Unittest code is not meant to produce an output,
>> >  while online snippets to try are meant to nearly always produce a
>> >  meaningful output.
> I don't know - I like the approach Andrei took in the docs, writing
> a series of true assertations.
>
> assert(sort([4, 2]) == [2, 4]);
>
> does look pretty neat. I guess the alternative is:
>
> writeln(sort[4, 2]); // prints "[2, 4]"

What about

   // sort([4, 2]) == [2, 4])

? Looks to me both simpler & clearer.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 04/14/2011 06:32 AM, Walter Bright wrote:
> On 4/13/2011 6:04 PM, Adam D. Ruppe wrote:
>> I don't know - I like the approach Andrei took in the docs, writing
>> a series of true assertations.
>>
>> assert(sort([4, 2]) == [2, 4]);
>>
>> does look pretty neat. I guess the alternative is:
>>
>> writeln(sort[4, 2]); // prints "[2, 4]"
>>
>> but it's not as compact with some examples and it doesn't quite
>> show the same thing - writeln's implementation could change things
>> there and those details are really beside the point of the example.
>>
>> On the other hand, having output there might be more interesting
>> to look at than "yay the asserts all passed!".
>>
>> I could go either way.
>
> One advantage of the assert() approach is you won't have to over and over again
> add in the import std.stdio;
>
> Not having any imports makes for a faster compile, too.

... and helps in having safe sandboxes. This holds for simple comments as well:

    assert(3/2 == 1);
vs
    // 3/2 == 1

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 4/14/11 2:26 PM, spir wrote:
>> Not having any imports makes for a faster compile, too.
>
> ... and helps in having safe sandboxes.

In which way exactly do I need an import to write »extern(C) int system(in char *); system(…);«?

David

On 04/14/2011 02:40 PM, David Nadlinger wrote:
> On 4/14/11 2:26 PM, spir wrote:
>>> Not having any imports makes for a faster compile, too.
>>
>> ... and helps in having safe sandboxes.
>
> In which way exactly do I need an import to write »extern(C) int system(in char
> *); system(…);«?

Did I write "it provides safe sandboxes"?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 4/14/11 3:44 PM, spir wrote:
> On 04/14/2011 02:40 PM, David Nadlinger wrote:
>> On 4/14/11 2:26 PM, spir wrote:
>>>> Not having any imports makes for a faster compile, too.
>>>
>>> ... and helps in having safe sandboxes.
>>
>> In which way exactly do I need an import to write »extern(C) int
>> system(in char
>> *); system(…);«?
>
> Did I write "it provides safe sandboxes"?
>
> Denis

No, but you wrote that it »helps in having safe sandboxes«, and I'm curious how you think it would.

David

On Wed, 13 Apr 2011 21:04:25 -0400, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On the other hand, having output there might be more interesting
> to look at than "yay the asserts all passed!".

I think this is a good point.  Someone playing with a language might type in the example, and do:

/home/steves> dmd example.d
/home/steves> ./example
/home/steves> (ok... I guess that worked, but I'm not sure what happened)

In other words, there is a benefit to the interaction with the learner.  In other words, you get to "see it working", rather than only see when it fails.  You also get a confirmation that the compiler is actually building something.  For the above code, all one really knows is that the compiler made an executable.  There's no confirmation that the code being run is actually what you typed in.

Sometimes, I worry that my unit tests or asserts aren't running.  Every once in a while, I have to change one to fail to make sure that code is compiling (this is especially true when I'm doing version statements or templates).  It would be nice if there was a -assertprint mode which showed asserts actually running (only for the module compiled with that switch, of course).

-Steve

On 4/14/11 4:03 PM, Steven Schveighoffer wrote:
> Sometimes, I worry that my unit tests or asserts aren't running. Every
> once in a while, I have to change one to fail to make sure that code is
> compiling (this is especially true when I'm doing version statements or
> templates). It would be nice if there was a -assertprint mode which
> showed asserts actually running (only for the module compiled with that
> switch, of course).

You are not the only one, I can't resist to do this quite often when I work with template-heavy code, or compiler bugs come into play.

At least for the unit tests, this could probably be integrated with a test harness (and named tests), which would have a verbose mode which logs each completed unittest block.

David

On 4/14/11 6:52 AM, spir wrote:
> On 04/14/2011 01:11 AM, bearophile wrote:
>>> * Since most of them don't actually output anything, the program
>>> > now detects output.length == 0 and says "Program run
>>> > successfully." upon completion to give some feedback.
>> This is a problem. Unittest code is not meant to produce an output,
>> while online snippets to try are meant to nearly always produce a
>> meaningful output.
>
> All my unittest blocks produce meaningful output; there exist firstly
> for that. Am I an heretic?

No, you're just doing it wrong. Heretic might be sometimes good.

http://www.linfo.org/rule_of_silence.html

Andrei

On 4/14/11 7:25 AM, spir wrote:
> On 04/14/2011 03:04 AM, Adam D. Ruppe wrote:
>> bearophile wrote:
>>> > This is a problem. Unittest code is not meant to produce an output,
>>> > while online snippets to try are meant to nearly always produce a
>>> > meaningful output.
>> I don't know - I like the approach Andrei took in the docs, writing
>> a series of true assertations.
>>
>> assert(sort([4, 2]) == [2, 4]);
>>
>> does look pretty neat. I guess the alternative is:
>>
>> writeln(sort[4, 2]); // prints "[2, 4]"
>
> What about
>
> // sort([4, 2]) == [2, 4])
>
> ? Looks to me both simpler & clearer.
>
> Denis

I don't like that one bit. What is it trying to achieve or improve?

Andrei