3 ms·

It sounds like you haven't taught or taken an intro to programming course using Java before. In that situation, instructors might spend weeks trying to get the

It sounds like you haven't taught or taken an intro to programming course using Java before. In that situation, instructors might spend weeks trying to get their students to understand variables or control flow concepts. Visibility may be a core concern for you, as a (presumably) professional Java programmer, but it's not at all to programming novices.

java-man 4y ago
This particular problem, in my opinion, has a much simpler solution: a special educational environment. A sort of mini-IDE where two things happen: 1. code written by a student gets inserted into a top-level class's main() method (has to be smart enough to deal with imports, inner classes etc.) 2. the top level class might declar certain utility functions such as print() instead of System.out.println(), and possibly others. Bingo. No need to mess with something that works just fine for 99.99% of the professional users. edit, in response to @crummy (as we reached the maximum depth it seems): Some people commented that it might be beneficial to delay introduction of more complex concepts until the basic ones are digested. So hiding the class/main method would help with that (similar to jshell, I might add). And keep in mid this is an IDE and not java-lite.
- crummy 4y ago
  In your other comment you said: > What I really dislike about this JEP is not only that it tries to solve the educational problem in a worst possible manner (my opinion), but it also risks creating a generation of students who don't really understand the fundamental concepts that allow us to write reliable code. How would your special IDE/forked Java-lite prevent creating a generation of students who don't really understand the fundamental concepts that allow us to write reliable code?
- djur 4y ago
  Such an environment already exists, and the JEP rejects it as an option: > Evolving a batch of working declarations in JShell into a real Java program leads to a non-idiomatic style of code because it declares each method, class, and variable as static... it is not the on-ramp programming model we are looking for.
- pgwhalen 4y ago
  Even as you outline your “simple” solution, you acknowledge in parentheses all of its hidden complexities. As Brian Goetz would say, this is a classic “why not just” take.

java-man 4y ago

This particular problem, in my opinion, has a much simpler solution: a special educational environment. A sort of mini-IDE where two things happen: 1. code written by a student gets inserted into a top-level class's main() method (has to be smart enough to deal with imports, inner classes etc.) 2. the top level class might declar certain utility functions such as print() instead of System.out.println(), and possibly others. Bingo. No need to mess with something that works just fine for 99.99% of the professional users. edit, in response to @crummy (as we reached the maximum depth it seems): Some people commented that it might be beneficial to delay introduction of more complex concepts until the basic ones are digested. So hiding the class/main method would help with that (similar to jshell, I might add). And keep in mid this is an IDE and not java-lite.

crummy 4y ago
In your other comment you said: > What I really dislike about this JEP is not only that it tries to solve the educational problem in a worst possible manner (my opinion), but it also risks creating a generation of students who don't really understand the fundamental concepts that allow us to write reliable code. How would your special IDE/forked Java-lite prevent creating a generation of students who don't really understand the fundamental concepts that allow us to write reliable code?
djur 4y ago
Such an environment already exists, and the JEP rejects it as an option: > Evolving a batch of working declarations in JShell into a real Java program leads to a non-idiomatic style of code because it declares each method, class, and variable as static... it is not the on-ramp programming model we are looking for.
pgwhalen 4y ago
Even as you outline your “simple” solution, you acknowledge in parentheses all of its hidden complexities. As Brian Goetz would say, this is a classic “why not just” take.