JEP 495 Question

[Matt Pavlovich]

The dots are a real thing. New coders are often also new to computers. One thing that is different about middle school age learners is that they have grown up with computers (phones and tablets) that work correctly (for the most part) *all* the time. They don’t have to compile a kernel, install a bunch of packages, fix defaults for their use case, or dive into a config.sys or autoexec.bat or a reg edit — let alone even peak at a file system. I was surprised by how many kids don’t really know how images are stored on a drive— they’ve only known thumbnails, not filenames.
 
Most things are a black box of “it just works”. The first introduction of “dots” is in filenames. There is a heavy context switch to figure “ok .. this thing we are doing with a ‘dot' is not about a file .. it is some sort of way to have the computer do a thing”

That being said, I don’t think the import static is that big of a deal. As a student builds up from console to file to socket, the imports become a conversation about learning to troubleshoot. Things start to click once they try to use a class or method that is imported in the example source file in the instruction book, but not their source file. Students learn to eye scan the "import area of the file” and start to remember that they need to add that “magic line" and then it compiles and runs without changing any other ‘code’. Python has the same thing— you can't do hashes or networking without the proper headers (and corresponding libraries installed).

Cautiously peeking back at my previous suggestion ;-) — I think having the step-up be *same* in terms of words and characters on the screen is super valuable in getting the lightbulb to go off that reading and writing to things with a computer is all the same— console, file, network, properties file, etc. It’s how computers work and the next generation of coder has never had to learn *how* computers work.

Having different method names and handles adds a divergence that doesn’t connect back to the reality that it’s all the same under the covers.

Thanks,
Matt


How’s this for a Mr Pav’s Java 101?

Lesson 1:

import static Console.*;

void main() {
    String name = readln("Please enter your name: ");
    write("Pleased to meet you, ");
    writeln(name);
}

Lesson 2: (Introduce types other than text)

import static Console.*;

void main() {
    int age = readInt("Please enter your age: ");
    write(“Your age is, “);
    writeInt(age);
}

Lesson 3: (qualify read/write methods)

import java.io.Console;

void main() {
    int age = Console.readInt("Please enter your age: ");
    Console.write(“Your age is, “);
    Console.writeIntln(age);
}

Lesson 4: (add a file)

import java.io.Console;
import java.io.File;

void main() {
    int age = Console.readInt("Please enter your age: ");
    Console.write(“Writing age to file, “);
    Console.writeIntln(age);
    File file = new File(“age.txt”);
    file.writeIntln(age); // now go inspect age.txt
}

Lesson 5: (replace file with a network socket)

import java.io.Console;
import java.net.Socket;

void main() {

    int age = Console.readInt("Please enter your age: ");
    Console.write(“Sending age to server, “);
    Console.writeIntln(age);

    Socket socket = new Socket(“127.0.01”, 4321);
    socket.writeIntln(age); // now go inspect server-side
}


> On Nov 21, 2024, at 6:19 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> You pass the "only respond if you are an instructor" test, but I was asking a very specific question: what can we say about the relative learnability of `IO.println` vs `println`?
> 
> There's infinite room to design new APIs but we're looking for feedback on a specific question.
> 
> 
> On 11/21/2024 7:14 PM, Matt Pavlovich wrote:
>> Hello-
>> 
>> How about a series of classes that provide the same I/O methods (and behavior!) across the spectrum of I/O types? 
>> 
>> This would allow:
>> 1. New coders to learn on the console, which provides the benefit of immediate feedback loop
>> 2. Allow new coders to transition from Console to File to Socket by changing only a single word in the source code
>> 
>> Console.readInt
>> Console.readIntln
>> Console.writeInt
>> Console.writeIntln
>> 
>> Socket.readInt
>> Socket.writeInt
>> ..
>> 
>> File.readInt
>> File.writeInt
>> ,,,
>> 
>> Properties.readInt
>> Properties.writeInt
>> ,,,
>> 
>> 
>> Thanks,
>> Matt Pavlovich
>> 
>> Instructor: 1,000+ hours of classroom
>> Teacher: 8th grade robotics/engineering/programming
>> 
>>> On Nov 21, 2024, at 12:45 PM, Brian Goetz <brian.goetz at oracle.com> <mailto:brian.goetz at oracle.com> wrote:
>>> 
>>> I'd like to validate this further, but I'd like to seek feedback _from educators only_.  (Please include in your answer how long you've been teaching Java *formally*.)
>>> 
>>>> I am with Stephen here.
>>>> 
>>>> For effective learning, the gating factor is complexity, not verbosity. The regularity of IO.println wins over the implicit import.
>>> 
>>> I would like to assess how broadly this opinion is held _by educators_.  The three positions that have been espoused by various proponents are:
>>> 
>>>  - println is simpler for learners, and so the speed bump of going from there to IO.println when going to non-simple compilation units is worth it.
>>>  - IO.println is equally simple for learners, and has the benefit of uniformity, no need for static import.
>>>  - IO.println is actually *simpler* for learners, because the IO provides context to what comes after the dot.
>>> 
>>> It is easily imaginable for experienced developers to hold any of these views; consider all of those as having been read into the record.  I want to hear _from educators_ about which they would be more comfortable teaching, and why.
>>> 
>>> Thanks in advance for keeping this channel clear for the experienced educators to speak.
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241121/8c2d08f8/attachment-0001.htm>