My experience with IO.print() and IO.println()

[David Alayachew]

Hello @amber-dev <amber-dev at openjdk.org>,

I finally had the chance to tutor a couple kids, this time, using the new
IO class, and I wanted to post my experience about them thus far, in case
it would be useful.

If I had to quantify and compare the friction and trip factor relative to
System.out.println(), it's a fairly noticeable difference.

For example, there are a certain "type" of students that have a brain that
REFUSES to accept new info until they understand ALL details of what's in
front of them. What is System? What is out? Does the dot have meaning? Why
are there 2? What are the parentheses? The more you expose them to, the
more they dig. And while digging seems good at first, they tend to be
mental pack hoarders, carrying around all of these details and
cross-referencing them against any new information that their brain can now
finally accept. Thus, they tend to get overburdened quickly, and that's
assuming that your explanation holds up to scrutiny. Lol, they're like
little detectives. I've had a long list of these type of students for
years, and they are usually the ones bothered by System.out.println() the
most out of any of the students.

Well, explaining IO.println() ended up being a much smoother experience.
For starters, the phrase IO is something most students have "heard of" and
are vaguely familiar with, so to put "face to name" is something they
appreciate. That input/output explanation tends to go a long way for these
kids. A lot easier to explain compared to System, especially for the
students who have an IDE with autocomplete. Furthermore, communicating that
IO is just a bucket for a small handful of simple input/output methods
works well because, the size of the class means that the type of students
that like to dig get to the bottom of the hole very quickly, and thus,
aren't held up for nearly as long. Back when this feature was in preview, I
had my own wants to add to the list of potential methods to IO. Looking at
it now, it's clear that its minimality is a strength.

Then there is the obvious benefit of not having to use Scanner anymore. The
results were exactly as expected here. Nothing to report.

Deferring to things like Integer.parseInt proved to be a mild obstacle, and
one that was easily overcome. Sure, it was an obstacle we previously didn't
have, but the tradeoff is a good one imo.

Finally, I'd like to praise the choice to make IO.println() a static
method. I'm sure that the decision-making was obvious, but I cannot state
enough how much easier it is to teach students the foundational concepts
when working purely with static, stateless, utility/helper functions. And
most importantly, about NOT BEING FORCED TO TEACH THEM CLASS
INSTANCES/IDENTITY. Easily the biggest benefit of having these be static
methods.

All in all, a great success. Thanks again Project Amber team for moving a
mountain out of the way for us!

Thank you for your time and attention.
David Alayachew

Side note -- I know it might seem flippant of me to group students into
"types", but after 13 years of tutoring, I've found it to be an effective
strategy for picking a choice when all else is equal. Not all strategies
work for all students. And while you can pick the least bad, general
solution, you do tend to get forced into specializing your teaching for
each student, case-by-case. That goes beyond programming, but for education
period.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20251125/b3bea7f8/attachment-0001.htm>