Comment by Jach | Hacker News Reader

Comment by Jach | Hacker News Reader

Parent Full thread

So I looked at his main() post ( http://beginwithjava.blogspot.com/2008/06/main.html ), and found his explanation for static:

    static says that this is the one and only main() method
    for this entire class (or program). You can't have 
    multiple main()s. If you leave this out, you'll get an 
    error since it could be possible for there to be 
    multiple instances of main() otherwise.

No wonder his students had trouble with it, this is just flat-out wrong (on every claim). I'm not a fan of his explanation about "an array of Strings" (there is none), though perhaps he covers that better in class? The "By the way you can type args[] instead of String[] args" seemed completely unnecessary.

Hello World in Java is brought up as an example of how complicated Java is on the outset, not to say that it's impossible to learn for a beginner. The problem with Java's Hello World is that in order to completely, correctly understand it all you have to know a lot more about Java, OOP, and its interactions with itself and the system.

The HTML strawman doesn't require such outside knowledge to completely understand (and there are people who claim it's verbose, that's why we have templates and HAML and tag-name() functions and so on); the <html> tag, <head> tag, etc. can be explained as helping the browser find information, and if you wanted to start off real simple (if not standard) a modern browser will render simply <h1>Hello world!</h1> by itself, no html, no title, nothing else, just fine, and you can go from there. There is no simpler Hello World in Java.

Yeah, I agree my description of static needs to be changed on that page. It's not what I use in class.

I teach static from a general standpoint of stating belonging to the class rather than an object of that class. For didactic purposes, sometimes you phrase what-ifs in odd ways to get the point across.

Still, wrong on every claim? How many main()s do you put in your classes? Do you leave static out of your main() signature without getting an error in compilation?

I appreciate corrections, but can we avoid hyperbole?

As to the HTML, if I'd used the bare header tags with text the counter argument would be that I'm not teaching proper HTML.

Plus, brevity masquerading as simplicity is not the purpose of the lesson. The point that HTML is seldom treated as too complex for beginners is the real point here. Yet it gets pretty complex pretty quickly. The students handle it.

    static says that this is the one and only main() method
    for this entire class (or program). You can't have 
    multiple main()s. If you leave this out, you'll get an 
    error since it could be possible for there to be 
    multiple instances of main() otherwise.

> one and only main() method...you can't have multiple main()s.

    public class t {
      public static void main(String[] args) { }
      public static void main() { }
      // why is it the one with the args gets called?
    }

Also, that comment leads to the prediction that "If I put static in front of something, I can only have one of it!" (or the converse "If I leave static off, I can have multiples of it") which is false. Avoiding method overloading and making two methods of the same signature, Java will give you a "func() is already defined in t" error regardless of having static or not.

>If you leave this out, you'll get an error

    public class t {
      public void main(String[] args) { }
      // and for good measure
      public static void main() { }
    }

This compiles just fine, however at runtime you'll get the error "Exception in thread "main" java.lang.NoSuchMethodError: main" Very nice for a beginner: "I have a main! It's right there! I have two in fact! ..Oh, it wants the args version."

>I teach static from a general standpoint of stating belonging to the class rather than an object of that class. For didactic purposes, sometimes you phrase what-ifs in odd ways to get the point across.

That's a lot better, but now I'm curious, do you go over creating Objects and the keyword "new" in the first day as well? How do you describe the difference between object methods and static class methods without an object to demonstrate? If you try to make an object method in your hello world program:

    public class t {
      public static void main(String[] args) { hello(); }
      public void hello() { System.out.println("Hi"); }
    }

you get a helpful "non-static method hello() cannot be referenced from a static context". Of course you can always do "new t().hello();" but...

"static" is a complicated keyword, I'm not convinced that saying "You have to have it, treat it like magic for now but we'll cover what it really means later" isn't a fine enough cop-out for HelloWorld.

Perhaps the correct approach with HTML then is to teach XML that happens to render in a browser first, then go on into what makes HTML special. I'm also not convinced that HTML by itself gets very complicated. Sure, bringing in CSS and JavaScript and then dealing with all the issues of different browsers can get as complicated as a Java HelloWorld program, but that's not exactly HelloWorld material for HTML.

I'll agree that young students can handle a lot more complexity than we give them credit for.

Good comments, thanks!

I take on "new" on day 2, when I cover variables.

And static gets revisited several times. I have to be brief with the first class, the main point is that it serves a function, it's not just noise. When we build a class that we use from another class (third or fourth lesson) we use a class method initially, then a non-static method, and get a chance to see the differences in action. This sets us up for static fields in the following class.

Then we talk about how static members relate to classes vs. instantiated objects. Often someone's already encountered the reference from static context problem, so that comes up as an example in the discussion.

Later we go back and look at Hello, World with "new eyes."

At these students' ages a lot of the learning needs to be experience rather than theory.

That sounds a lot better. :)

> At these students' ages a lot of the learning needs to be experience rather than theory.

I think that's true for programming in general regardless of age, unless the person's a genius. I watched a lecture on Skip Lists and totally understood the high-level view, but when it came to implementation it was more challenging than I thought. I likely would have slept through most of my digital electronics course if I didn't know we were doing labs leading to a 4-bit CPU.

Reply on news.ycombinator.com