4 ms·

I feel like this is introducing a change for the sake of change, solving a problem which does not exist. The price of this change is very real: adding complexi

I feel like this is introducing a change for the sake of change, solving a problem which does not exist. The price of this change is very real: adding complexity and bugs to all the tools, IDEs, code analyzers and the like. There is negative net benefit to pretty much everyone involved, and for what?

Pet_Ant 3y ago
That is literally what is addressed by the first section of the document. Both in "Summary" and in "Goals" > Far from using a separate dialect of Java, students can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow. I remember when I started with Java 20 years we had a special IDE (BlueJ maybe? DrJava?) that wrapped the main class so that <code>System.out.println("Hello world");</code> was a complete program. So that is clearly > Do not introduce a separate beginner's dialect of Java. Perhaps this is in response to Python growing as an initial programming language (IMHO wrongly because types are fundamental to thinking about programming). They also mention: > Reduce the ceremony of writing simple programs such as scripts and command-line utilities. You can question the merits or trade-offs, but it's very clearly spelled out. > Reduce the ceremony of writing simple programs such as scripts and command-line utilities.
- java-man 3y ago
  Is this really what students struggle with? I think it is important to be able to determine the root cause of a problem first. Do students find difficult to write "public static void main(String[] args)" or do they find difficulty understanding the concepts of a public method, a static method, a void method? Perhaps then we should focus on teaching these concepts, which are essential to java, first, instead of undermining the core of the language and the platform. Neither "goals" nor "summary" can explain away why this can solve the problem this JEP purports to solve. This is my opinion, of course.
  - pron 3y ago
    > Perhaps then we should focus on teaching these concepts, which are essential to java, first. As the JEP explains, this change does make the concepts of classes and access modifiers easier to teach by allowing the teacher to postpone their introduction to a point in time when they're actually useful and can be understood. Access control, static, and class declarations are only meaningful once you have other classes and/or objects interacting with your code. We don't want to force teachers to teach programming in the large early because many of them told us they don't do that anyway. > instead of undermining the core of the language and the platform The syntax and concepts of anonymous classes are unchanged. Providing an unnamed class, implicitly, when a class isn't needed is consistent with how we already provide an unnamed package and an unnamed module implicitly when they're not needed.
  - pgwhalen 3y ago
    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 3y 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.
slaymaker1907 3y ago
I've written a ton of Java and I'd find this handy for datetime stuff. Even though I don't use it for my work anymore, I still pull out Java when I need to answer questions like what day is 90 days from now because java.time.* is very well designed. Instead of just using the shell, this makes things a little nicer with less ceremony if I want to do these date calculations in a local file.
ht_th 3y ago
In my experience teaching introductory programming with Java, the problem is very real. For beginning programmers, making sense of the first Java program(s) results too often in misunderstanding of all sorts of concepts. Of course, you can tell students to ignore most of the code until later in the course when they'll learn all about it, but that doesn't work. They'll make sense of the code within their limited understanding of programming and frames of reference. They'll build local theories of how and why these programming elements, like "static", "class", "main", "String[]" etc. fit together, how they relate to error messages they get when their programs don't compile or don't work. Then, when they do reach the place in the course when they're to learn all about these concepts, they have to reconcile their own local theories with the material at hand to create a more thorough and evolved understanding of the concept. That's often not an easy process. In many introductory programming courses, there's not much time for reflection. As a result, their evolving understanding is likely closer to their initial understanding instead of the ones we aim at as teachers. What's not helping here is that as experienced programmers who have developed a deep understanding of these concepts to understand novice's point-of-view and their struggles with the material. Learning and teaching is hard!
- justin_oaks 3y ago
  Thanks for explaining the problem. Do you think the proposed changes will help significantly and will be worth the trouble?
  - ht_th 3y ago
    Yes! The easier it is to get started with a language, the easier it is to learn and teach. Rather than focusing on (fighting) tools, you can focus on developing understanding of the core concepts of (Java) programming with a suitable learning trajectory. That's huge. And a boon to keep a language and community relevant. Once schools and teachers move on to other languages for teaching, you have to fight to win programmers over to use your language. As for the added complexity to the compile or run-time system, that seems mostly an issue for language implementers, not users. It certainly won't be an issue for beginning programmers, so for them and their teachers, there's no tradeoff to pay for.
justin_oaks 3y ago
I do wonder how much benefit will be gained from this. Is the main method really causing beginners that many problems? I'd say beginners are much more likely to trip over other problems with the language like using == with String instances, the differences between primitives and objects (e.g. copy-by-value vs copy-by-reference, no methods on a primitive, etc.), or the unending problems with null. Of course, those may never be resolved, and so we'll have to change something that doesn't really matter instead.
- crummy 3y ago
  Not sure if you're being sarcastic but the solution to some of those things is on the horizon (e.g. null awareness). Seems like a lot of work is necessary to get there though.
easton 3y ago
Why would this cause extreme problems for Java where it didn’t for C# doing the same thing a few years ago? I’m honestly asking not having done Java in a few years, as I remember they both had this “you gotta put all the code in classes” problem.
kaba0 3y ago
It is an ultra minimal change, mostly related to loadclassing, nothing else changes in the language spec.

Pet_Ant 3y ago

That is literally what is addressed by the first section of the document. Both in "Summary" and in "Goals" > Far from using a separate dialect of Java, students can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow. I remember when I started with Java 20 years we had a special IDE (BlueJ maybe? DrJava?) that wrapped the main class so that <code>System.out.println("Hello world");</code> was a complete program. So that is clearly > Do not introduce a separate beginner's dialect of Java. Perhaps this is in response to Python growing as an initial programming language (IMHO wrongly because types are fundamental to thinking about programming). They also mention: > Reduce the ceremony of writing simple programs such as scripts and command-line utilities. You can question the merits or trade-offs, but it's very clearly spelled out. > Reduce the ceremony of writing simple programs such as scripts and command-line utilities.

java-man 3y ago
Is this really what students struggle with? I think it is important to be able to determine the root cause of a problem first. Do students find difficult to write "public static void main(String[] args)" or do they find difficulty understanding the concepts of a public method, a static method, a void method? Perhaps then we should focus on teaching these concepts, which are essential to java, first, instead of undermining the core of the language and the platform. Neither "goals" nor "summary" can explain away why this can solve the problem this JEP purports to solve. This is my opinion, of course.
- pron 3y ago
  > Perhaps then we should focus on teaching these concepts, which are essential to java, first. As the JEP explains, this change does make the concepts of classes and access modifiers easier to teach by allowing the teacher to postpone their introduction to a point in time when they're actually useful and can be understood. Access control, static, and class declarations are only meaningful once you have other classes and/or objects interacting with your code. We don't want to force teachers to teach programming in the large early because many of them told us they don't do that anyway. > instead of undermining the core of the language and the platform The syntax and concepts of anonymous classes are unchanged. Providing an unnamed class, implicitly, when a class isn't needed is consistent with how we already provide an unnamed package and an unnamed module implicitly when they're not needed.
- pgwhalen 3y ago
  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 3y 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.

slaymaker1907 3y ago

I've written a ton of Java and I'd find this handy for datetime stuff. Even though I don't use it for my work anymore, I still pull out Java when I need to answer questions like what day is 90 days from now because java.time.* is very well designed. Instead of just using the shell, this makes things a little nicer with less ceremony if I want to do these date calculations in a local file.

ht_th 3y ago

In my experience teaching introductory programming with Java, the problem is very real. For beginning programmers, making sense of the first Java program(s) results too often in misunderstanding of all sorts of concepts. Of course, you can tell students to ignore most of the code until later in the course when they'll learn all about it, but that doesn't work. They'll make sense of the code within their limited understanding of programming and frames of reference. They'll build local theories of how and why these programming elements, like "static", "class", "main", "String[]" etc. fit together, how they relate to error messages they get when their programs don't compile or don't work. Then, when they do reach the place in the course when they're to learn all about these concepts, they have to reconcile their own local theories with the material at hand to create a more thorough and evolved understanding of the concept. That's often not an easy process. In many introductory programming courses, there's not much time for reflection. As a result, their evolving understanding is likely closer to their initial understanding instead of the ones we aim at as teachers. What's not helping here is that as experienced programmers who have developed a deep understanding of these concepts to understand novice's point-of-view and their struggles with the material. Learning and teaching is hard!

justin_oaks 3y ago
Thanks for explaining the problem. Do you think the proposed changes will help significantly and will be worth the trouble?
- ht_th 3y ago
  Yes! The easier it is to get started with a language, the easier it is to learn and teach. Rather than focusing on (fighting) tools, you can focus on developing understanding of the core concepts of (Java) programming with a suitable learning trajectory. That's huge. And a boon to keep a language and community relevant. Once schools and teachers move on to other languages for teaching, you have to fight to win programmers over to use your language. As for the added complexity to the compile or run-time system, that seems mostly an issue for language implementers, not users. It certainly won't be an issue for beginning programmers, so for them and their teachers, there's no tradeoff to pay for.

justin_oaks 3y ago

I do wonder how much benefit will be gained from this. Is the main method really causing beginners that many problems? I'd say beginners are much more likely to trip over other problems with the language like using == with String instances, the differences between primitives and objects (e.g. copy-by-value vs copy-by-reference, no methods on a primitive, etc.), or the unending problems with null. Of course, those may never be resolved, and so we'll have to change something that doesn't really matter instead.

crummy 3y ago
Not sure if you're being sarcastic but the solution to some of those things is on the horizon (e.g. null awareness). Seems like a lot of work is necessary to get there though.

easton 3y ago

Why would this cause extreme problems for Java where it didn’t for C# doing the same thing a few years ago? I’m honestly asking not having done Java in a few years, as I remember they both had this “you gotta put all the code in classes” problem.

kaba0 3y ago

It is an ultra minimal change, mostly related to loadclassing, nothing else changes in the language spec.