SimpleIO in JEP draft 8323335

[Aaron Scott-Boddendijk]

> Scanner has a ton of complexity in it that can easily trip up beginners.

This part should be said again and louder.

As someone who spends a lot of time assisting new programmers online
(mostly Discord/Reddit), this is a multiple-times-a-day, every day of the
week problem (and this is not hyperbole).

This occurs so very often that many such communities have prepared
bot-responses making exactly Brian's point (using `==` with `String` is
probably the other really common one).

`Scanner` is a highly versatile tool for blasting holes in the feet of
beginners. And promoting `Scanner.nextInt()` when you really mean "line of
input that is an int" is aiming the gun.

The individual concepts have to be visible or we'll continue to maim new
programmers.


On Mon, Feb 19, 2024 at 10:44 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> I think you are counting characters and not counting concepts.
>
> Scanner has a ton of complexity in it that can easily trip up
> beginners.  The main sin (though there are others) is that input and
> parsing are complected (e.g., nextInt), which only causes more problems
> (e.g., end of line issues.)   Reading from the console is clearly a ()
> -> String operation.  The input() method does one thing, which is get a
> line of text.  That's simple.
>
> Integer.parseInt (or, soon, patterns that match against string and bind
> an int) also does one thing: convert a string from int.  It may seem
> verbose to have to do both explicitly, but it allows each of these
> operations to be simple, and it is perfectly obvious what is going on.
> On the other hand, Scanner is a world of complexity on its own.
>
> Console::readLine is nice, but first you have to get a Console. ("Why
> can I print something without having to get some magic helper object,
> but I can't do the same for reading?")  What we're optimizing for here
> is conceptual simplicity; the simplest possible input method is the
> inverse of println.  The fact that input has to be validated is a fact
> of life; we can treat validation separately from IO (and we should), and
> it gets simpler when you do.
>
> On 2/18/2024 4:12 PM, Cay Horstmann wrote:
> > I would like to comment on the simplicity of
> > https://openjdk.org/jeps/8323335 for beginning students.
> >
> > I am the author of college texts for introductory programming. Like
> > other authors, I introduce the Scanner class (and not Console) for
> > reading user input. Given that students already know about System.out,
> > it is simpler to call
> >
> > System.out.print("How old are you? ");
> > int x = in.nextInt(); // in is a Scanner
> >
> > than
> >
> > int x = Integer.parseInt(console.readLine("How old are you? "));
> >
> > or with the JEP draft:
> >
> > int x = Integer.parseInt(input("How old are you? "));
> >
> > Then again, having a prompt string is nice too, so I could imagine
> > using the Console API with Integer.parseInt and Double.parseDouble,
> > instead of Scanner.nextInt/nextDouble.
> >
> > But why have a third API, i.e. "input"?
> >
> > I think there are two feasible directions. Either embrace the Scanner
> > API and next/nextInt/nextDouble/nextLine, or the Console API and
> > readLine. Adding "input" into the mix is just clutter, and ambiguous
> > clutter at that. At least readLine makes it clear that the entire line
> > is consumed.
> >
> > Cheers,
> >
> > Cay
> >
> > --
> >
> > Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240219/4b8340d9/attachment.htm>