JEP 495 Question

[Olexandr Rotan]

Just a remark: python IS typed, and code you have provided will result in
loan being string, unsuitable for numeric operations. Correct input would
be:

loan = float(input(...))

Which starts to look pretty much the same except for absence of classs
qualifier near float()

Dont confuse good languages with js :)

On Thu, Nov 7, 2024, 23:46 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 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 package.
> Any thoughts?
>   --Barry
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241108/9ae1c8a1/attachment.htm>