Tuesday, January 25, 2011

My Students Laugh, HaHa, Laugh, at the HN Naysayers ;)

I'm gratified by the response my recent article Should I Still Learn Java? has received, especially at sites like Hacker News and DZone.

Among the comments at HN were some folks who felt that Java is a poor choice of language for beginning programmers. There were a number of reasons given, many of those reasons are pretty far removed from the beginner, I feel. Then there were some that trotted out that other old argument, the complexity of the "Hello, world!" program:

class HelloWorld{
public static void main(String[] arg){
System.out.println("Hello, world!");

It's an ugly-looking mouthful, I'll admit. But a complete obstacle to learning Java? Not even close.

If you're studying Java on your own, there's a lot in there that tends to get glossed over in texts on Java. In writing, it's hard to strike a balance between infodumps and magic code when you're trying to maintain a pace to the narrative of the book. I've broken down the elements of the basic program in several articles at my other blog A Beginning Programmer's Guide to Java, including the articles on the Basic Program Skeleton, Code Blocks, and main().

But how long does it take to cover this material in class? Can it be done without sending the students into the Land of Nod?

The Proof is In the Results

Actually, it's far easier to cover in class than it is in print. I teach the basic elements of Java to both my 6th-8th grade classes and my high school classes. Here's how things went today, in my 6th-8th grade class:

I introduced the class to what we were going to do today (write a simple program in Java, compile it and run it.) I had the students open a terminal window and a text editor then started writing out the HelloWorld program pretty much as it appears above. I explained each word as I wrote, as I do in the articles linked above.

Along the way, I got class interaction to make sure they were with me, that I wasn't just talking to the air. It gave some of them the chance to affirm their ideas about what I was telling them, others that had been a bit lost got it when we reviewed it.

I had them enter each line in their editor when I finished writing each line on the board. I explained the value of proper indentation, capitalization and the parens as part of the naming of different elements in Java (class names, method names, constructor methods, member fields.)

The class was able to anticipate the last curly brace in the program, and the lack of any indentation. It's great when they can already see where you're going.

Then I went over how to save and name the file, having them use 'pwd' in their terminal window to make sure they saved the file in that directory from the text editor. After saving, they used 'ls' to see that the file was there (one student caught an error that way.) pwd and ls were commands they were already familiar with, as well as general use of the command line.

Then I had them use 'javac' at the command line to compile the program. A few students had capitalization errors on the class name, and there were some missing semicolons. After a moment, the files had been corrected, saved, and everyone had a successful compile (we reviewed the "no news is good news" rule for the Unix command line.)

We then used 'java' to run our programs.

Elapsed time: 30 minutes.

Did Anything Stick?

Then we reviewed the program, word by word. I pointed at each word (including each part of System.out.println() ), they told me what it meant. I let each student have a go before affirming what it meant. They nailed them all, except for static. That was the only word that they were fuzzy on. In some cases they had a sense, but couldn't express it clearly. In other cases they just plain weren't sure.

So we reviewed what "static" does in the program.

Then I told them to change what the program prints, and add additional program lines to print things of their own.

They went to their editors, I hovered over. A couple of students needed reminders that the program needed to be recompiled once they'd saved an edited version.

Then they all had programs that had been customized, run with no errors.

Total elapsed class time: 40 minutes.

Then we talked about the differences between the source code and byte code files (see The Code Code), looked at the .java and .class files with 'cat' and 'strings' (a new command to them).

After looking at the .class file with 'strings', we talked about where the extra lines like '/java/io/PrintStream' came from and what they did. They nailed it, but then we've talked a lot about I/O in class.

I did a quick review of all the words in HelloWorld.java one more time, then spent the last few minutes of class covering what we'll be doing in future classes.

Finally, I asked them how complicated they thought today's lesson had been. The consensus was "pretty complicated, but not too complicated." I asked for votes for "really complicated" and got none.

Total elapsed class time: 55 minutes.


Part of the reason for getting so much done so quickly comes from the value of face to face interaction between student and instructor. This doesn't happen with books in most circumstances.

Part of the reason for success like this comes from preparation. The students already knew the basic tools of the command line and the text editor. The commands 'javac', 'java', and 'strings' were new in this class.

The students had previously edited HTML by hand. Want to talk complicated? Try this:
<title>Hello, World!</title>
<h1>Hello, World!</h1>
<p>This is my first web page.</p>
We do that in one class in the first semester.
By the end of the class we've had time to either add images or start styling our text. Kinda helps put the whole "boilerplate code" issue of Java into perspective, doesn't it? I seldom hear it claimed that HTML is too complicated for beginners to learn.

We've also done some programming in BASIC this year. The old GWBASIC, in fact. No graphics or sound, but just some simple text and calculation programs (like an insult generator and a die roller) inside the GWBASIC interpreter environment.

I drew on all these things, as well as our other discussions about the internals of the computer system and its OS in the course of this lesson.

Will It Still Be There Next Time?

If I don't follow up with anything else, no, of course it wouldn't stick as anything other than an exposure experience. But there will be follow up.

My 6th-8th grade classes meet once a week. One week is a long time for kids at this age. My high school classes meet twice a week, for 85 minutes per class. I cover a lot more material, faster, with these students.

Based on past experiences teaching this same material, I expect most of the class to remember what the program does, and the meanings of the following words once they see the program again:

void (for some reason this one seems to stick)

About half the class will remember the function of the curly braces versus the parens. About half (usually the other half) will remember the capitalization rules.

One or two will really remember 'static', the rest will need a refresher on that.

Which, for students from 11 to 14 years old, with only one hour a week, is pretty darn good. When I originally designed these lessons, I expected to repeat all the material from the first lesson in a slightly different way in a second lesson to get even half the material to stick.

As it is, the second lesson usually consists of about 10 minutes of review from HelloWorld.java, then we go on to introduce the Scanner and start accepting keyboard input into our programs (see Getting Keyboard Input for Java Apps, we end up with a program pretty close to TrollTalk.java.)

Is Java Too Complicated?

What do my students say to the assertion that Java is too complicated for a beginner to learn?

They laugh at it.

People who assert that the boilerplate in a simple Java application is too much have either had a poor exposure to the language themselves (please check out my other blog at A Beginning Programmer's Guide to Java, I wrote the site just for you), or they're advanced programmers making mountains out of speed bumps as stalking-horse arguments against Java.

Java isn't simple, but it's not too complex for a beginner.

p.s.-I love Hacker News myself, and take all my students there to open it up to them.

Tuesday, January 4, 2011

Games for Christmas

This year our presents were heavy on games. In part, this is because our friendly local game store, Ship It! Games, has closed its doors. A sad event, but we were able to buy a bunch of games at bargain prices before they were gone.

We're really going to miss that store. Fortunately, we're still in contact with Chris Wright, the owner. He's a great guy and everyone here at our house wishes him well in his future endeavors.

Ticket to Ride

The first game that got opened was Ticket to Ride by Days of Wonder. This game has been around for a while and has won many awards. I've heard a lot of good things about it.

We have played it several times now, and we agree. It's a great game.

What's special about the game is that it doesn't take a whole lot of thinking to play. There is a strategic element, but if you're brain-fried after a long day at work, this is a game you can still pull out and enjoy, even with opponents who are at the top of their game. It's fun, easy to concentrate on short term objectives if that's all you're up for, and the set is designed very nicely too. Five stars!

Growing Hunger

Next comes the expansion to Last Night on Earth: The Zombie Game by Flying Frog Games. Growing Hunger adds several new scenarios and heros, as well as new cards, items, and so on. It makes LNOE a much stronger game overall, though the new cards dilute the old cards when added to the decks. The place where this is a problem is mainly with the Zombie Deck. The "Shamble" card, in particular, comes up less often than it should. We may convert a few of the present cards into Shamble cards, or add the Shamble power as a secondary use for one of the other cards to try to rebalance things.

Munchkin Quest

We haven't played this one, yet, but we're really looking forward to it. We really enjoy the Munchkin card game (that's our other "I'm fried and don't want a game that makes me think" game.) Unfortunately, the rules are very poorly written compared to the card game. They're very confusing, poorly organized, and long-winded. This is the opposite of the writing in the card game's rules.

Fortunately, it looks like a lot of the card game is in the board game. But I can tell our first game or two is going to be exploring the rules and trying to get them right. Steve Jackson, get an editor or another writer to redo those rules in a future printing! I was able to play Stellar Conquest properly first try, lo, these many years ago. I can't make heads or tails of a bunch of the rulesheets for Munchkin Quest!

This is another one we haven't played yet but are looking forward to. It looks like a game based on Warcraft II, with some World of Warcraft and Warcraft III elements in it. The pieces are not as nice as we were hoping for, and to be honest we've been pretty spoiled by the fantastic sets that Days of Wonder produces (we've got Small World and, of course, Ticket to Ride from Days of Wonder.) The Warcraft pieces are wood, but they're kinda crude chiaroscuro shapes for different general unit types. But we've enjoyed other games from Fantasy Flight Games (notably Talisman, which they rescued from fading away right after we bought our fourth edition copy, and its expansions.)

Ah, well, the real telling will be in the game itself.

Demented Dungeons

Munchkin is one of our favorite "play me anytime" games. We have the original core set plus the first expansion, Unnatural Axe. And now we have "Demented Dungeons"! We're really looking forward to adding the Dungeon rules to our game. One of the great things about this expansion is that it won't make our door and treasure decks taller, putting off the day when we'll need to build or buy a deck holder for our Munchkin cards.