[u-u] jobs @ rakuten/kobo

[David Collier-Brown]

If it doesn't skew the process of teaching the language, I'd try using 
it in one of your labs.

Writing the man page first is an Unix-ism from way back, and writing the 
success-path test first is a modern way of making sure you're 
implementing what the man page says.

I'd personally say write the perldoc first, then the test that proves 
you did the right thing, then the code that does it right, in a lab that 
has them writing a function (that could perhaps live in a library for 
them to re-use after the course).

--dave

On 05/08/17 01:27 PM, arocker at Vex.Net wrote:
>> I tell my software engineers: you ARE going to write test cases and you
>> ARE going to write documentation so the smart thing to do is document
> first,
>> test second and implement last
> Treating documentation as the first level of specification and writing a
> set of tests to break anything defined (until it's doing the right thing)
> seems a good way of developing a specification for desired code. (Though
> in the past, the "write tests first idea" has met a good deal of
> derision.)
>
> I'm drafting a training course for Perl 6, and I'm seriously thinking of
> making commenting the first topic, before introducing any actual commands.
> Then create no-op scripts that are merely a plan for the desired
> processes, and proceed to fill out the functions underneath the comments
> describing them.
>
> Does that sound like too much of a departure from the traditional sequence
> of a language course, or otherwise weird, to be accepted?
>
> _______________________________________________
> u-u mailing list
> u-u at unixunanimous.org
> https://unixunanimous.org/mailman/listinfo/u-u
>

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net           |                      -- Mark Twain