JEP 495 Question

Thu Nov 7 21:13:32 UTC 2024

Well, it took years to convince you to add Stream.toList(), and the
reasoning against this method was also very strong. We can wait ;⁠-⁠)

Tagir

On Thu, Nov 7, 2024, 22:09 Brian Goetz <brian.goetz at oracle.com> wrote:

> Here's the bar we're envisioning: methods that are automatically imported
> in this way _effectively become part of the langauge_.  The bar for that is
> very high.
>
> println(String) clears that bar; a language without console output is
> pretty suspect.
> readSomeCharsAndParseThemAsAnIntegerAndLeaveTheInputInSomeUnspecifiedState()
> does not.
>
> This doesn't mean there can't be something _elsewhere in the JDK_ for this
> purpose, or even many somethings.  But if you couldn't credibly say "this
> should be part of every language", then it almost surely does not meet the
> bar for IO.
>
> But these methods are so flawed that they obviously fail this bar.  (And,
> they also serve as great "my first method" examples, for students learning
> simple abstraction!)
>
>
>
>
>
> On 11/7/2024 4:00 PM, Tagir Valeev wrote:
>
> Hello!
>
> I agree that methods like readInt and readDouble should be added, if we
> really want to make Java appealing for beginners who try to write console
> applications. It looks to me that sometimes we think too much and avoid
> making decisions and taking responsibility if there's no single obviously
> good way to solve the problem. Here any decent solution would be good
> enough, were it just a shortcut to parseDouble(readln()) or having a
> Scanner.nextDouble under the hood. Either way is much better than having no
> solution at all. Students will get used to it, and we can easily ignore
> nitpickers who would criticize it and insist that the opposite solution
> should be implemented. Because nitpickers will do this in any case.
>
> I personally would prefer even more beginner-friendly solution, like
> repeatedly asking for a number and displaying a friendly error message if
> the user types something different (without throwing an exception). Sure,
> this is not flexible and should not be used in production-quality
> applications. But this is what would be the least scary for beginners.
>
> I also see the desire to keep the API surface not bloated, but you can see
> how many people connected to education actually requested methods to read
> numbers in this mailing list. Do you remember them requesting anything
> else? To me it's clear that reading numbers in a one method call is a
> single most wanted addition to IO. You'll see many more such requests after
> the feature is graduated (well, unless every single student moves to
> Python).
>
> With best regards,
> Tagir Valeev
>
> On Thu, Nov 7, 2024 at 9:47 PM Kenneth Fogel <kfogel at dawsoncollege.qc.ca>
> wrote:
>
>> I understand your position and ten years ago I would agree with it
>> wholeheartedly but not anymore. I am excited about JEP 445 and how it might
>> bring more students and self learners to Java. Today’s learners want fast
>> results. It is why I believe so many are hooked on Python. I dislike Python
>> because it is an untyped language, but we cannot ignore that:
>>
>>
>>
>> Python: loan = input("Loan: ")
>>
>> makes more sense to those starting out than:
>>
>> Java: var loan = Double.parseDouble(readln("Loan: "));
>>
>>
>>
>> Both will throw exceptions if you enter “bob” for the value, just at
>> different points in the execution.
>>
>>
>>
>> I feel that any language should evolve not only with new features but in
>> new ways to learn that match how people learn today. I do agree that there
>> can easily be a flood of requests that could probably make Java look like
>> GW-BASIC.
>>
>>
>>
>> Thank you, Brian, for providing the summary of why you and the Java team
>> decided not to have a numeric read. As they say, we will have to agree to
>> disagree.
>>
>>
>>
>> Ken
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* amber-dev <amber-dev-retn at openjdk.org> *On Behalf Of *Brian Goetz
>> *Sent:* November 7, 2024 2:41 PM
>> *To:* Barry Burd <bburd at drew.edu>; amber-dev at openjdk.org
>> *Subject:* Re: JEP 495 Question
>>
>>
>>
>> Yes, these were considered, and dismissed with prejudice, in part because
>> the model implied by readInt and readDouble is a problematic one, because
>> it greatly complicates the "reading state" that has to be understood by the
>> user (e.g., what if there's no digits on the line, does it read another
>> line?  what if the digits end mid-line, does it leave the cursor there?
>> what if it consumes all the characters on the line, and then you read a
>> string?)  These are issues that invariably trip up beginners and
>> experienced users alike.
>>
>> The locution you suggest, which is to use readln() to read a line into a
>> String, then parseInt() to convert to an int, is more wordy than some of
>> the alternatives, but much clearer and simpler as to what is going on,
>> because it composes two simple functions (read a string, convert a string
>> to an int).  This is good for beginners, because they can see that there
>> are steps here to get the data into the form they want.  The readInt()
>> method provides the illusion of simplicity, but ends up moving significant
>> complexity to where we are more likely to trip over it in the dark.
>>
>> I'm not saying there will never be a richer way to do this, but readInt()
>> and friends are definitely not it.
>>
>> More generally, one of the worst things about creating an IO class is
>> that it immediately becomes  target for a flood of "can you just add my one
>> favorite method" requests.  We might add a few more methods to it in the
>> next decade.  But we also might not; less is more.
>>
>> On 11/7/2024 12:06 PM, Barry Burd wrote:
>>
>> I see that parameterless println() and readln() methods are being added
>> to java.io.IO
>> <https://urldefense.com/v3/__http://java.io.IO__;!!ACWV5N9M2RV99hQ!MJpHobvTKPnFT329pXDoV-I9JfQsit7ze1tw661KBZ8lDiF51A0FsvGAY09VGmeRu2tKtLPzDUKSvyjI$>
>> in JEP 495. I'm still wondering if there's been any thought to including
>> methods like readInt and readDouble. In the early stage of an introduction
>> to Java, it's common to have the student input int values and double values
>> for simple examples. With the current spec, the best way to do this (as far
>> as I can see) is
>>
>>       var n = Integer.parseInt(readln("Enter a number"));
>>
>> It seems natural to simplify this with a readInt method, and the addition
>> of such a method wouldn't weigh heavily on the java.io.IO
>> <https://urldefense.com/v3/__http://java.io.IO__;!!ACWV5N9M2RV99hQ!MJpHobvTKPnFT329pXDoV-I9JfQsit7ze1tw661KBZ8lDiF51A0FsvGAY09VGmeRu2tKtLPzDUKSvyjI$>
>> package.
>> Any thoughts?
>>   --Barry
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241107/660d326d/attachment.htm>