SimpleIO in JEP draft 8323335

[Remi Forax]

I agree with Brian here, 
as a teacher, you have to talk about parsing and formatting, those should not be hidden. 

The classical program is: 
input -> strings -> objects -> strings -> output 

Rémi 

> From: "Tagir Valeev" <amaembo at gmail.com>
> To: "Cay Horstmann" <cay at horstmann.com>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "amber-dev" <amber-dev at openjdk.org>
> Sent: Monday, February 19, 2024 10:09:35 AM
> Subject: Re: SimpleIO in JEP draft 8323335

> 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 < [ mailto:cay at horstmann.com |
> 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
>> >>>> | 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$
>>>>>> |
>>>>>> https://urldefense.com/v3/__http://horstmann.com__;!!ACWV5N9M2RV99hQ!IuXZk_tqIH8rEw1bD3uYb8UcIZF-nnoeFT3UG17pMO5EVXIYVRaAKi7XCq_T02HwnAek1wuV8Wed08w$
>> >>>> ] | mailto: [ mailto:cay at horstmann.com | cay at horstmann.com ]




>> --

>> --

>> Cay S. Horstmann | [ http://horstmann.com/ | http://horstmann.com ] | mailto: [
>> mailto:cay at horstmann.com | cay at horstmann.com ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240219/68f5b67d/attachment-0001.htm>