3 ms·

My 2¢ is that this will probably do more to confuse than to enlighten students. Getting your "first" program off the ground quickly is good, but only if it doe

My 2¢ is that this will probably do more to confuse than to enlighten students. Getting your "first" program off the ground quickly is good, but only if it doesn't cripple your understanding of what's going on for months later. For me the main thing that confuses the crap out of students is how people who introduce java tend to take "shortcuts" and bundle all functionality under the sun into a single class, which then also has a main method at the end. Presumably this is done so that everything is a single file, or can fit in a single presentation slide. But then suddenly your main looks like it's calling its container class to make objects of "itself" that contain new "mains", at which point your student has lost the plot completely. The simplest thing to keep things clean and self explanatory is to separate everything that isn't "main-related" into its own class (preferably another file if public), and then keep a nice clean public class called "Main" which contains 'only' the main method. Then you get to explain nicely how public classes have their own files, and if you attempt to run this class from the terminal, java will look for the 'main' function, and how this therefore needs to be public, static because you're running it straight from the class, void because you don't depend on it returning a value (which also makes for a nice intermission on how c returns status as an int, but java has a special mechanism instead). I do agree with the end of the JEP though; if you want to teach simple snippets like System.out.println, jshell is a nice way to do this, if you want to delay talking about classes and their methods.

pron 4y ago
> But then suddenly your main looks like it's calling its container class to make objects of "itself" that contain new "mains", at which point your student has lost the plot completely. Exactly. This is one of the problems this JEP attempts to solve. > separate everything that isn't "main-related" into its own class ... and then keep a nice clean public class called "Main" which contains 'only' the main method. Then you get to explain nicely how public classes have their own files, and if you attempt to run this class from the terminal, java will look for the 'main' function, and how this therefore needs to be public, static because you're running it straight from the class, void because you don't depend on it returning a value Only then you've taught a number of programming-in-the-large concepts as well as a bunch of Java technicalities -- all designed for the purpose of building large programs in a team -- before teaching what a computer program is. However, if you use this feature to teach your students and encounter a problem, we would be interested to hear your experience on the amber-dev mailing list.
- tpoacher 4y ago
  Java has had a nice focus on "decluttering" improvements lately; I think it's a nice focus to have (if done carefully), as 'verbosity' has always been one of the supposed pain points of java. I would welcome this JEP in this light. I see this as great for developers already familiar with the language in making code more streamlined. But it's along a similar vein to, say, "anonymous classes can be expressed as lambdas which can in turn be expressed as method references". Or, say, the 'var' keyword as a way to automatically infer the variable type and how memory will be allocated for it, on the basis of the applied constructor. In both cases, the last step may be a nice, simple-looking expression, but it hides a lot of underlying complexity and context, which you need to understand properly to use it effectively. So the part I 'object' to in the wording of the JEP is the educational intent/strategy implied in the summary. For me there is a big difference between something like "introduce complex idea A at a higher level because simpler idea B depends on it", vs "obfuscate the true nature of A to pretend B can be understood in isolation, and deal with the resulting confusion later". Learning works by creating basic blocks of understanding, consolidating them, and then using them to build more complex blocks later on. Relying on a faulty foundation, hoping to come back and re-build it later on is generally not the best educational strategy (in my humble view). So from an educational point of view, for me this does not make my job simpler. If I wanted my students to build a solid foundation of understanding, I would have to first explain what classes are, what static methods are, how methods can NOT in fact live outside a class in java, and only THEN explain that "to make things less verbose, in this VERY specific case, java allows you some syntactic-sugar to hide some of that complexity under a simpler-looking syntax, that would otherwise look weird in standard java". But yes, having said all that, this seems like a nice proposal for the language more generally, that could lead to further similar improvements down the line, and I would be in favour of it! Great work!
  - pron 4y ago
    > obfuscate the true nature of A to pretend B can be understood in isolation, and deal with the resulting confusion later What confusion? All the code in the body of an anonymous class is perfectly valid Java code that you can put in the body of an anonymous class today. There is no new magic here. > I would have to first explain what classes are, what static methods are, how methods can NOT in fact live outside a class in java, and only THEN explain that "to make things less verbose, in this VERY specific case, java allows you some syntactic-sugar to hide some of that complexity under a simpler-looking syntax, that would otherwise look weird in standard java". I don't think you would. There is no syntactic sugar here that Java doesn't already do. The body of an anonymous main class is valid as the body of an anonymous class today -- there is no special magic or any kind of special interpretation of code here -- and the notion of "implicitly supply an unnamed instance of a programming-in-the-large concept" is something Java already does today for packages and modules. Every method lives in a class, every class lives in a package, every package lives in a module. And yet, we don't require you to explicitly declare a package or a module. The current way we treat class declarations is the inconsistent one: it requires a class declaration even when it's not useful. Classes are no more fundamental to how Java "really" works under the covers than modules and class loaders. And yet, Java doesn't force you to learn these concepts before learning what a variable is or what a loop is. There is simply no way to know how Java really works without understanding modules. Modules are what gives actual meaning to access modifiers. Do you teach modules before loops today? Classes (and so static) and access modifiers really are completely meaningless before you have more than one class or more than one object, just as modules are meaningless until you have several of them. We are making Java more consistent in not an explicit invocation of a concept that is only meaningful once you add more context to it.
paulddraper 4y ago
> Presumably this is done so that everything is a single file Putting code in a single file is definitely an asset for instruction, whether Java, C, Python, JavaScript, etc. That said, a Java file can have multiple classes (though just one public class). https://dev.java/learn/single-file-program/ https://dev.java/learn/single-file-program/

pron 4y ago

> But then suddenly your main looks like it's calling its container class to make objects of "itself" that contain new "mains", at which point your student has lost the plot completely. Exactly. This is one of the problems this JEP attempts to solve. > separate everything that isn't "main-related" into its own class ... and then keep a nice clean public class called "Main" which contains 'only' the main method. Then you get to explain nicely how public classes have their own files, and if you attempt to run this class from the terminal, java will look for the 'main' function, and how this therefore needs to be public, static because you're running it straight from the class, void because you don't depend on it returning a value Only then you've taught a number of programming-in-the-large concepts as well as a bunch of Java technicalities -- all designed for the purpose of building large programs in a team -- before teaching what a computer program is. However, if you use this feature to teach your students and encounter a problem, we would be interested to hear your experience on the amber-dev mailing list.

tpoacher 4y ago
Java has had a nice focus on "decluttering" improvements lately; I think it's a nice focus to have (if done carefully), as 'verbosity' has always been one of the supposed pain points of java. I would welcome this JEP in this light. I see this as great for developers already familiar with the language in making code more streamlined. But it's along a similar vein to, say, "anonymous classes can be expressed as lambdas which can in turn be expressed as method references". Or, say, the 'var' keyword as a way to automatically infer the variable type and how memory will be allocated for it, on the basis of the applied constructor. In both cases, the last step may be a nice, simple-looking expression, but it hides a lot of underlying complexity and context, which you need to understand properly to use it effectively. So the part I 'object' to in the wording of the JEP is the educational intent/strategy implied in the summary. For me there is a big difference between something like "introduce complex idea A at a higher level because simpler idea B depends on it", vs "obfuscate the true nature of A to pretend B can be understood in isolation, and deal with the resulting confusion later". Learning works by creating basic blocks of understanding, consolidating them, and then using them to build more complex blocks later on. Relying on a faulty foundation, hoping to come back and re-build it later on is generally not the best educational strategy (in my humble view). So from an educational point of view, for me this does not make my job simpler. If I wanted my students to build a solid foundation of understanding, I would have to first explain what classes are, what static methods are, how methods can NOT in fact live outside a class in java, and only THEN explain that "to make things less verbose, in this VERY specific case, java allows you some syntactic-sugar to hide some of that complexity under a simpler-looking syntax, that would otherwise look weird in standard java". But yes, having said all that, this seems like a nice proposal for the language more generally, that could lead to further similar improvements down the line, and I would be in favour of it! Great work!
- pron 4y ago
  > obfuscate the true nature of A to pretend B can be understood in isolation, and deal with the resulting confusion later What confusion? All the code in the body of an anonymous class is perfectly valid Java code that you can put in the body of an anonymous class today. There is no new magic here. > I would have to first explain what classes are, what static methods are, how methods can NOT in fact live outside a class in java, and only THEN explain that "to make things less verbose, in this VERY specific case, java allows you some syntactic-sugar to hide some of that complexity under a simpler-looking syntax, that would otherwise look weird in standard java". I don't think you would. There is no syntactic sugar here that Java doesn't already do. The body of an anonymous main class is valid as the body of an anonymous class today -- there is no special magic or any kind of special interpretation of code here -- and the notion of "implicitly supply an unnamed instance of a programming-in-the-large concept" is something Java already does today for packages and modules. Every method lives in a class, every class lives in a package, every package lives in a module. And yet, we don't require you to explicitly declare a package or a module. The current way we treat class declarations is the inconsistent one: it requires a class declaration even when it's not useful. Classes are no more fundamental to how Java "really" works under the covers than modules and class loaders. And yet, Java doesn't force you to learn these concepts before learning what a variable is or what a loop is. There is simply no way to know how Java really works without understanding modules. Modules are what gives actual meaning to access modifiers. Do you teach modules before loops today? Classes (and so static) and access modifiers really are completely meaningless before you have more than one class or more than one object, just as modules are meaningless until you have several of them. We are making Java more consistent in not an explicit invocation of a concept that is only meaningful once you add more context to it.

paulddraper 4y ago

> Presumably this is done so that everything is a single file Putting code in a single file is definitely an asset for instruction, whether Java, C, Python, JavaScript, etc. That said, a Java file can have multiple classes (though just one public class). https://dev.java/learn/single-file-program/ https://dev.java/learn/single-file-program/