There is negative net benefit to pretty much everyone involved, and for what?
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!
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.
> 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.
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.
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.
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.
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.
> 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?
> 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.
As Brian Goetz would say, this is a classic “why not just” take.
Both suck. In the first case, students are torn away from the mode of thinking that programming thrives in: that everything is made up of simple, understandable pieces, that can be built up into complex solutions. It ends up serving as a trap for the very kind of inquisitive student that is equipped to succeed in programming. In the second case, everyone's bored to tears, and you can be assured that your entire class will be hopelessly lost before they write their first line of code. It's a bad time all around.
Basically, programming wants to be built up with the following concepts, in order:
1. Algorithmic Thinking (solutions can be representing as a series of simple steps)
2. Structured Syntax (these steps can be represented as structured text)
3. Symbolic Reasoning (types, variables, arrays)
4. Control Flow (loops, conditionals)
5. Functions
6. Higher Structures (classes, objects, etc)
Python, IMO, is pretty good pedagogical tool in this regard
print("Hello World")
In contrast, explaining everything going on in the equivalent Java
public class MyFirstClass {
public static void main(String[] args){
System.out.println("Hello World");
}
}
Please see my response to @pgwhalen. In short, the problem has, I think, a much simpler solution.
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.
Perhaps we need to start teaching basic programming with BASIC instead, and graduate to a more complicated platform once the basic concepts have been understood.
But a lot of "universities" treat their "CS" programs as glorified trade schools, and want to focus exclusively on industry-applicable languages, and land on Java because Oracle had a great outreach program. Like it or not, many students will be starting their programming journey in Java, and not fucking it up is probably a good idea.
My approach would have been pretty similar to their listed alternative under "Interpret code units as static members", but that probably comes down to differences over the importance of Object-Oriented principals in beginner programming pedagogy.
Barring that, this proposal really isn't bad. It doesn't break existing code, it does its job well enough. I would have liked there to be support for inline subclasses that can be called from within the same anonymous class environment, but I can see how that would create ambiguity with existing code.
Not sure what you mean by "inline subclasses", but an anonymous main class can contain class declarations -- just as classes, named or anonymous can today. This file would be a complete legal program:
record Foo(int x, int y) {}
class Bar { static void print(Foo f) { System.out.println(f); } }
void main() {
Bar.print(makeFoo());
}
Foo makeFoo() { return new Foo(3, 4); } new Object() {
record Foo(int x, int y) {}
class Bar { static void print(Foo f) { System.out.println(f); } }
void main() {
Bar.print(makeFoo());
}
Foo makeFoo() { return new Foo(3, 4); }
}.main();
1. Anonymous classes
2. Unnamed instances of programming-in-the-large concepts are implicitly provided for you (today this is the case only for packages and modules).
There are no new changes or restrictions to Java syntax in the body of the anonymous class.
The often touted alternative starting language is C and python, and I believe Java is better than both — C’s mentioned advantage is “learning low level details”, but I don’t see it as necessary, plus C can fail at runtime (or worse, at *some runtime on someone else’s machine) in completely cryptic ways, you may not even realize your program is incorrect until you submit an assignment. I have seen even very smart students be puzzled by it. Also, pointers can be learned afterwards easily, I don’t see it problematic at all.
Python’s problem comes mostly from its dynamically typed nature, it is very hard for new programmers to reason about the runtime state of programs, and why might have it failed on the nth cycle of this loop.
Java is a great in-between. It is not perfect (for example arrays having special syntax is not ideal), but not bad and it being an industry language is just a plus.
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.