SimpleIO in JEP draft 8323335

[Tagir Valeev]

I agree that simple methods to get numeric input are essential for
beginners. They should not be distracted with a complex ceremony. Instead,
they should be able to learn control flow statements and simple algorithms
as soon as possible, having a simple way to get numbers from the user.

With best regards,
Tagir Valeev.

On Mon, Feb 19, 2024 at 9:10 AM Cay Horstmann <cay at horstmann.com> wrote:

> Yes, that's what I am saying. If scanners live in vain, stick with a
> subset of the Console methods. Use its readLine. Make it so that SimpleIO
> uses System.console(). And add print and println to Console.
>
> The JEP talks about being able to start programming without having to know
> about static methods. How does a beginner read a number? With
> Integer.parseInt(readLine(prompt))?
>
> What about locales? Is print/println localized? Console.printf is. If so,
> how are beginners from around the world supposed to read localized numbers?
> With NumberFormat.getInstance().parse(readLine(prompt))?
>
> Adding localized readInt/readDouble to SimpleIO might do the trick. Do
> they consume the trailing newline? (The equivalent Scanner methods don't,
> which is definitely a sharp edge for beginners.)
>
> On 18/02/2024 23.08, Brian Goetz wrote:
> > OK, so is this really just that that you are bikeshedding the name?
> Renaming `input` to `readLine`?
> >
> > This is a perfectly reasonable naming choice, of course, but also, not
> what you suggested the first time around:
> >
> >  > ... "a third API" ...
> >
> >  > ... "there are two feasible directions" ...
> >
> > So what exactly are you suggesting?
> >
> >
> >
> > On 2/18/2024 5:03 PM, Cay Horstmann wrote:
> >> Like I said, either the scanner methods or the console methods are fine.
> >>
> >> I am of course aware of the utility/complexity of Scanner, and can
> understand the motivation to have a simpler/feebler behavior in SimpleIO.
> Like the one in Console.
> >>
> >> You don't have to "get a console". A SimpleIO.readLine method can just
> invoke readLine on the system console.
> >>
> >> My objection is to add yet another "input" method into the mix. "input"
> is weak. Does it read a token or the entire line? Does it consume the
> newline? And if it does just what readLine does, why another method name?
> Because "input" is three characters fewer? Let's not count characters.
> >>
> >> On 18/02/2024 22.43, Brian Goetz 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 |
> https://urldefense.com/v3/__http://horstmann.com__;!!ACWV5N9M2RV99hQ!IuXZk_tqIH8rEw1bD3uYb8UcIZF-nnoeFT3UG17pMO5EVXIYVRaAKi7XCq_T02HwnAek1wuV8Wed08w$
> | mailto:cay at horstmann.com
> >>>
> >>
> >
>
> --
>
> --
>
> 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/22150526/attachment.htm>