Showing posts with label HTML. Show all posts
Showing posts with label HTML. Show all posts

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.

Preparation

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:
<html>
<head>
<title>Hello, World!</title>
</head>
<body>
<h1>Hello, World!</h1>
<p>This is my first web page.</p>
</body>
</html>
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:

public
class
void (for some reason this one seems to stick)
System
out
println

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.

Wednesday, August 4, 2010

Java, Javascript, and the Installation Hurdle

For the past three years I've been teaching high school computer classes while using Java to teach the basics of programming in class. My usual routine is to teach HTML and CSS in the first semester, which provides the students with many of the basic skills of programming. Then in the second semester we start actually programming with Java.

The past two years I've taken advantage of the Greenfoot framework for Java. It eases the use of graphics and sound in Java programs, but more importantly it provides a visual representation of classes and objects. This greatly eases the burden of teaching what object oriented programming is all about, as well as demonstrating its advantages.

My reasons for using Java are several. Briefly, it's multi-platform. It's a "real" language, in that it is used outside the school and professionals are employed to use it. It incorporates the available facilities of the system, including graphics and sound, natively.

One of my hopes for my students is that after using Java in class, at least some of them will use it outside class as well. Unfortunately, for many of them the installation process has been a roadblock to doing this. Particularly in Windows, where an extra step has to be performed to add the Java SDK to the system's path. The students with Mac OS X at home are lucky, they don't have to install the SDK, it comes with the OS. The Linux users are usually capable of managing it for themselves. But about 80% of my students are under Windows outside of class. And the Java SDK install isn't what they're used to.

One potential solution to this would be moving to Javascript. There's no installation barrier there. One reason I've not used Javascript in class is that graphics subsystems like Canvas and SVG are not uniformly available. Even when IE9 comes out as a regular product next year, those students with Windows XP systems at home (about 75% of the Windows-only homes are running only XP, based on my surveys in class), this problem won't be entirely solved. The difference here is that the install of a second browser is a lot easier than a Java SDK install.

The installation barrier won't be the only thing my choice of language in class hinges on, but it's certainly a significant factor. Exactly why the Java SDK install has remained so hostile to Windows users is unclear to me. It smacks of elitism on the part of Sun/Oracle (if you can't hack the install process, we don't want you using it), but then the old saw about not ascribing evil intent where simple incompetence will suffice comes in. Maybe they just don't think it's a problem.

I expect to at least introduce Javascript this year as part of the HTML/CSS segment. Whether I do so and how deep we'll get into it will depend heavily on the character of the class--the chemistry of the students in any given class can make things vary a lot from class to class. Sometimes it's a struggle to get past <html><head><title><body>, other times I find them getting ahead of my lecture by several classes during one open work period.

Another factor in my willingness to consider using Javascript as the primary language in class is the advances the language has made recently. The ECMAScript Edition 5 specification is a big improvement on earlier specifications for the language. Likewise, the viewpoints of Douglas Crockford have influenced my impression of the language and its use.

If you're interested in Javascript, I highly recommend his book: JavaScript: The Good Parts.

Friday, July 25, 2008

IDEs for Class: Arachnophilia

Arachnophilia is a simple IDE that works with a variety of programming languages. It's got a simple, but highly configurable, interface.

Arachnophilia is the primary IDE that I use in my classes. After starting my students at the command line, and after introducing them to other IDEs, about 80% of my students use Arachnophilia by choice, and are very productive with it. The other 20% usually choose to use the command line as their primary development environment, though they will usually use Arachnophilia as an adjunct, for example as a code beautifier.

I teach in a multi-platform computer lab. While this is a challenge, I mostly consider it an excellent opportunity for making a point to the students. The real world is a multi-platform environment. Since Arachnophilia is written in Java, it runs on all the lab's systems and behaves the same way on all of them. Arachnophilia includes a special install for Windows that makes getting it going on that OS easy. It even includes a nice icon. (To get an icon on OS X and other Unix systems, I get the favicon.ico file from Arachnophilia's web site and make that the program's icon.)

Arachnophilia is syntax-aware for many programming languages, including HTML/CSS (its original purpose), C, C++, python, PHP, JavaScript, and Java. In a class where multiple programming languages are introduced (like mine) it's nice to have one IDE that works with all of them. I usually introduce Arachnophilia about halfway through our HTML/CSS unit, and continue using it in the Java programming portion of the class.

While I don't teach that Arachnophilia's interface is configurable, about one third of the class usually discovers this on their own and figures it out. They rapidly share this with the rest of the class, configuring their own build settings, customizing toolbars, and so on.

Arachnophilia behaves exactly the same on all platforms. This is a plus when you're calling out keystrokes in class, but it can be a problem for Mac users who are used to keyboard shortcuts that employ the Apple/Command key rather than the Control key. Moving back and forth between Arachnophilia and other apps on the Mac in the same session can be a bit disorienting as a result.

The interface the program provides is clean and easily accessible. I usually spend only about 10-15 minutes of class time getting students started with it, and another 10 minutes or so going into more advanced features later. Arachnophilia doesn't require any configuration to use before class (other than installation), unlike more advanced IDEs like Eclipse or Netbeans. Unlike Amaya, which is a nice IDE focused on HTML/CSS, we can keep using it when we move on to Java programming.

While I also like BlueJ a lot for class use, it is Java-specific, so I don't have an opportunity to introduce it during the HTML/CSS unit that I use as an introduction to programming concepts.

For my class, the ease of use and flexibility of Arachnophilia has made it the winner among a strong contingent of IDEs available.

Monday, July 21, 2008

HTML/CSS as a Prelude to Programming

In my high school Computer Applications class I divide the class in two. The first semester is spent on introductory level subjects, the second semester covers a more in-depth subject, usually programming. To prepare the students for the second semester, I use web page design as an important part of the first semester.

We don't use any high level design tools. Rather, we start with the low level elements. We use HTML and CSS. We start with a simple text editor, and migrate to a simple IDE about halfway through the unit (usually at least three weeks in.) By the time we change to the IDE about half the class is ready to revolt over the fussiness of dealing with the code in a bare text editor. It's interesting, though, that even after we've been using the IDE long enough to become competant, about 20% of students still prefer using a bare text editor for most coding tasks.

Creating web pages has a tremendous appeal for the students, so this is a popular unit in the class. When we're getting started, there are sometimes complaints about how we're going about things from students who have already used site-building tools. Sometimes this is a response to the unfamiliarity of the command line and a general feeling that we're doing things the hard way for no good reason. Within a few classes these complaints usually end as these students see the value of learning things from the bottom up. If they've had a chance to use high level tools, they've also had the chance to be frustrated by them. As we get to where we're expanding on the tags and styles we're using, rather than just learning the process and tools, they begin to see how they can do things they couldn't do with the high level tools, or get a better understanding of why the high level tools behave as they do.

Before we get started with HTML and CSS, we've had a short segment on command line use. We cover both Windows and Unix command lines with the basic commands for directory navigation and file manipulation. Usually the information hasn't really sunk in yet. But when we start using the command line for practical purposes in the HTML/CSS unit, it sticks and makes sense. This prepares the students for performing the same tasks when we get to programming in the second semester in a way that the command line segment alone would not.

We also get everyone familiar with using a simple text editor. I allow everyone to choose whether they use a command line editor (like Windows' edit) or a graphical editor (like Notepad or TextEdit.) If I had more time I'd have everyone spend a week on vi, but there isn't time enough (I do allow the use of vi or emacs, if the student wants to take it on on their own.)

Using a basic editor like this not only brings a high degree of concentration on the syntax of the language being programmed, but it also forces awareness of other items like where files are being saved, when they were most recently saved, and so on. If we skip this step and go straight to an IDE with autosave features and project management features like project directory management, I find that the students often don't get what's going on, and if something goes odd with the IDE they're left flat-footed wondering what to do. If they start with the simple editors, I notice they watch the autobackup notices and likewise pay attention to the directory structure created and maintained by the IDE.

Working with HTML/CSS itself teaches a good array of basic programming concepts:
  • dealing with syntax
  • using and remembering command names and keywords
  • developing a conceptual design
  • implementing to that design
  • comparing the implementation against the design
  • correcting problems (debugging)
  • iterative design refinement
  • dealing with "platform" issues (browser differences)
  • interdependencies between different code sections
HTML/CSS also has a lot going for it:
  • low barriers to entry
  • familiar concepts
  • fast turnaround
  • browser "test environment" is already familiar
  • complexity can be added incrementally, with good results available at all levels
  • no extra cost for tools--editors and browsers are already there, many IDEs are free
And there's a really big bonus to using HTML/CSS in class; the results are something that the student's parents and other teachers can see and appreciate. That's not always the case with programming. A printout from a command line program that demonstrates simple iteration doesn't always impress someone who's been watching their kid sweat over a textbook for a week. But a webpage is something they get.