The "loop and a half"

[Steve D'Aprano]

On Sat, 7 Oct 2017 05:56 am, Chris Angelico wrote:

> On Sat, Oct 7, 2017 at 5:47 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> Chris Angelico <rosuav at gmail.com>:
>>
>>> On Sat, Oct 7, 2017 at 4:55 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>>>> Personally, I think stdin is a bit lame as a stimulus source for an
>>>> interactive program. That's not even what stdin is primarily meant
>>>> for; stdin is meant to be the input data for a job. Similarly, stdout
>>>> is meant to be the result of the computation. Stderr, then, is used
>>>> to deliver optional diagnostic messages, ie, metainfo about the
>>>> computation.
>>>
>>> [...]
>>>
>>> Standard streams exist for a reason.
>>
>> That's exactly what I said.
> 
> And you also described it as "lame" for an interactive program.

I think what Marko meant is that using stdin ALONE, with no prompts, no help,
and no explanation, provides a bare-bones, featureless and underpowered user
interface unsuitable for an interactive program.

Let's come back to sort again: we all agree that sort reading from stdin is
*not* a user-friendly interface suitable for an interactive program. "Lame"
is a good word to describe an interface so bleakly featureless, underpowered
and user-hostile. But that interface wasn't designed for interactive use. It
was designed for passing data in via a file or pipe.

The fact that it happens to work at all is a happy accident, and one which
experienced users can take advantage of, but the primary intention of sort is
that it will read from a pipe or a file, not the keyboard. It works because
that's how Unix works, not because it was intentionally designed that way.

The sorts of games your students write use stdin to get input from the user,
but they don't -- or at least, shouldn't -- merely dump the user at a bare
screen with no prompt and no explanation of what they're supposed to do.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.