JEP 477 Interacting with the Console

[Brian Goetz]

The rationale should be obvious: System.out.println is not going away, 
nor are the several billion uses of println in existing Java code.  Were 
we to choose another name "because its better", then people have to 
learn two names, and learn that they do the same thing.  In this, we 
chose familarity / minimal hamming distance over finding the "best" name 
as if it were a clean-slate exercise (because it is not a clean slate 
exercise.)

(I'll also point out that had we done as you suggest, mirror-universe 
Ethan would be asking the exact same question (e.g., "what is the 
rationale behind picking something that is gratuitously different from 
how it is done today"))





On 7/16/2024 1:11 PM, Ethan McCue wrote:
> I still am not for importing java.base, for the reasons I think I 
> talked to death in that other thread.
>
> I guess while we are on the topic, what is the rationale behind naming 
> the method println?
>
> The current draft on github has println, print, and readln. But 
> printing isn't the inverse of reading - writing is the inverse of 
> reading. I agree that the metaphor of "printing to the screen" is used 
> widely, but I don't see why we would pick that given a blank slate.
>
> Then also readln over readLine strikes me as a strange tradeoff. 
> That's the kind of thing that helps someone who already knows that 
> "ln" is an abbreviation for "line" write code - i.e. the group Cay 
> identified as "authors of small programs." For beginners it's one more 
> non-obvious thing that needs to be explained.
>
> On Tue, Jul 16, 2024 at 12:43 PM <forax at univ-mlv.fr> wrote:
>
>     ----- Original Message -----
>     > From: "Cay Horstmann" <cay at horstmann.com>
>     > To: "Remi Forax" <forax at univ-mlv.fr>
>     > Cc: "amber-dev" <amber-dev at openjdk.org>
>     > Sent: Tuesday, July 16, 2024 9:15:30 AM
>     > Subject: Re: JEP 477 Interacting with the Console
>
>     > On 16/07/2024 08.41, Remi Forax wrote:
>     >>> In general, the needs of beginners and authors of small
>     programs are not the
>     >>> same. The JEP bounces between the needs of the two. Implicit
>     classes are useful
>     >>> for both, but magic imports will add puzzlement for beginners.
>     >>
>     >> I disagree, this is only an issue if you talk about "import",
>     seing println as a
>     >> shorcut for IO.println is not a real problem.
>     >>
>     >> The notion of "import" in Java is tricky anyway especially
>     because most of my
>     >> students know Python so you need a full lesson about the
>     difference between
>     >> Java import and Python import,
>     >> but that lesson can be taught in the second part of the
>     semester when you need
>     >> "package".
>     >>
>     >
>     > Hi Rémi,
>     >
>     > I agree that not having to talk about imports right away is a
>     win. I am all for
>     > importing java.base.
>     >
>     > I am not sure I get your point about shortcuts, though. I
>     wouldn't want to talk
>     > about shortcuts any more than about imports. I would not want to
>     discuss why
>     > there is a println shortcut but not parseInt or pow.
>
>     Shorcuts is not the right term, convenient is a better term.
>     This is the word we use to explain "var" too.
>
>     >
>     > Really, how painful is IO.println? (If that's too long, call it
>     IO.out.) And it
>     > is consistent. IO.println. Integer.parseInt. Math.pow.
>     Consistent is good for
>     > beginners. If further brevity is desired, there is an existing
>     > mechanism--static imports. Which can wait.
>
>     I think this is perfectly fine to not use "println" but
>     "IO.println" instead and mention later that it can be abbreviated
>     to "println".
>
>     >
>     > The alternative is to go big, and to provide "shortcuts" for all
>     beginner
>     > methods. println, parseInt, pow. Consistent and not puzzling.
>     But of course the
>     > rub is, what are all beginner methods ?
>
>     and the fact that all these names polute the scope.
>
>     We have exercises where students rewrite simple functions like pow
>     or parseInt, it would be sad if IO.parseInt is called instead of
>     the method "parseint" defined by a student because the method call
>     is written "parseInt(...)".
>
>     >
>     > Cheers,
>     >
>     > Cay
>
>     regards,
>     Rémi
>
>     >
>     > --
>     >
>     > Cay S. Horstmann | https://horstmann.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240728/70643575/attachment.htm>