Java isn't impossible for students to learn. I suggest, however, that it is not the best choice; because when it comes to learning how to program you want a language which is maximally expressive with a minimal amount of work. It artificially restricts the problem space you can tackle by making simple things more complicated than they need to be.
When you're writing an algorithm to count words in a file, would you prefer
string = File.read 'path'
or
StringBuffer fileData = new StringBuffer(1000);
BufferedReader reader = new BufferedReader(
new FileReader("path"));
char[] buf = new char[1024];
int numRead=0;
while((numRead=reader.read(buf)) != -1){
String readData = String.valueOf(buf, 0, numRead);
fileData.append(readData);
buf = new char[1024];
}
reader.close();
string = fileData.toString();
How about introducing anonymous functions? How much time will it take you to explain the intricacies of creating an anonymous subclass whose only purpose for existence is to encapsulate a single instance with a single method, inside which all variables from the containing scope must be marked as final? Or would you prefer something like Smalltalk?
[ :x | x * x ] value: 2
Sure, students can wrap their heads around both. But the important thing is the concept, not the expression. After all, if they go on to program in the real world, they'll be adapting their knowledge to different languages.
Not to mention that the type system in Java is always surprising. List<Integer> is not a List<Number> but Integer[] is a Number[] (which can throw ArrayStoreException as covariance makes no sense on mutable collections - ref: http://programming-scala.labs.oreilly.com/ch12.html)
And compare smalltalks' (and ruby's and python's) everything is an object to Java's: there are some primtive things, and null is not an object.
Don't get me wrong: java is very taughtable to beginners. The basic usage is ok, while cumbersome. But Java shows its deep issues when you start using it for more serious stuff.
Am I supposed to be impressed by 55 minutes to cover "Hello World"? That proves the point that Java is a bad starter language, it's not evidence against it!
Python would do that in about 5, and then instead of working on the irrelevant details of Java you could be teaching programming. (They will never need to know the other stuff you covered. The soonest the 8th graders could graduate college with a computer science degree is 2019 or 2020 and Java will be far from dominant by then. All irrelevant and not even all that educational.)
Your students have no ability whatsoever to judge complexity. What are they comparing it to? You want to play fair about quoting students and beating "HN" over the head with your students quotes? Next class period, do the Python equivalent, then ask them which is "more complex". Then tell us what happens.
(And if you lead them on enough, you can convince them to say they prefer Java. They aren't stupid, and they'll say whatever you want them to say. By that age they know what to do to get good grades. So I'd ask you that you play it as straight as you can, if you're serious about this.)
They aren't stupid, and they'll say whatever you want them to say.
Indeed. When I was merely nine I had a teacher who got mad at the class for some reason and decided to punish us all by making us memorize a list of all the prepositions in English, to be regurgitated -- in alphabetical order -- on a quiz. So I did. I still remember them all, in alphabetical order, several decades later. [1]
Of course kids can learn things. Those who aren't inclined to just blow school off may well be better at memorizing arbitrary rules than adults are. For one thing, they aren't always experienced enough to tell the difference between a useful educational exercise and a complete waste of time.
---
[1] Actually, I believe my mental list may be missing some prepositions. And that really makes me angry.
I'm not stupid either, and I can tell a response that's intended to please me from one that's sincere. My students are encouraged to tell me when I'm boring them and when something I'm doing in class just plain sucks.
You're missing the point of the question. I don't ask them to compare complexity against other languages they don't know. They were asked whether this was too complex for the class, judging against other subjects we've covered.
Some of my lessons have been too much for them. They've let me know. Others have moved too slowly, or not given them enough credit for being able to take new things on, they've let me know that, too. That evaluation is part of the class, we do it all the time. I experiment with the class, and they enjoy that since they know their feedback is part of what builds the class.
Rather, it appears you're inferring things that you'd like to infer about the class that support your feelings.
As to python, we'll be doing python in May for a short while, as well as C and ruby. And we will be rating each. We'll be re-implementing some things that we implement in Java in those other languages as a way of giving them a test drive, trying out not just the syntactic differences but the differences in approach to solving problems with the different languages. We'll also revisit LOGO (but not LISP, I've gotten clear messages from my students in the past that they don't find that productive to cover, though they appreciate me taking the time to describe it after we've done some LISP-ish things in LOGO.)
You also seem to think I teach Java as the be-all and end-all language. And that I presume it will be the only language they ever learn. In fact, I add a lot of humor to the class by poking fun at Java's problems (you know that humor helps learning, right?) While we spend the most class time with Java of any language (though we just started today), we've had lessons using assembly language, machine language, BASIC, and LOGO already this year, plus an extensive section using HTML. After we finish the section using Java, we'll add more languages as I said above.
OK, so you tell me, what is the hot language of 2019? I'm teaching learning processes, so that my students can learn whatever languages they want. I'm starting a fire under them so that they have enough of an interest to bother.
I am very serious about this. I teach these classes because I want to. I'm not filling time or filling checklists on an academic record. These aren't programming classes. These are general computer classes, which I'm trying to use to get students interested in taking programming classes when they move on to college, so I think you're misjudging my scope and the nature of the students.
The students in my class get good grades whether they agree with me or not. If they go along to get along, it will not get them a good grade, more likely the opposite. I don't need their agreement to stroke my ego. I've got work I've done in outer space as well as in a large fraction of the world's aircraft. I don't teach for egoboo, I teach because I want these kids to learn that they don't have to sit in front of a game console running a controller because that's all they're allowed to access in this world. I want them to learn to take things apart, turn them around, and build their own things. I don't like them being trapped outside the package, stuck behind the UI, cut off from tools.
The programming I teach isn't taught to learn how to create elegant algorithms or to discuss programming paradigms. It's taught as a practical method for putting tools in their hands and helping them make the transition from consumer to creator.
Focusing too heavily on what specific language is used at this level is unproductive. So long as the language used meets some basic constraints that many languages will meet.
I put on some additional constraints. For example, I want to teach a language that's used in the real world, not a packaged educational language licensed with a boxed learning program. I can't control what systems the students have at home. I want a language that works the same way at home as at school. I also want standard graphics and sound libraries since pictures and sounds motivate students as well as being useful to illustrate what's happening with data in programs. I have a number of constraints.
At this point, Java does the job. What I addressed was the assertion that Java is too complex to use in teaching beginners. Not whether there is no simpler language for expressing "Hello, world!"
Your estimate of how long it takes to cover anything, with meaning, in class is pretty optimistic. And as to what they need to know, and why they need to know it, I think you need to approach things from a higher perspective. The point here is not to simply teach mechanics of a particular language. What the computer is up to, why, and what the student can do to control it is the point, not how quickly we can get a few characters on the screen.
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.
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.
> 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.
I think the fact that it took 30 minutes to get through a Hello World program is pretty telling. Here's how I would teach 8th graders using Ruby:
puts "Hello World"
Ok cool, 5 minutes. Now let's learn about loops and conditional statements!
Edit: I absolutely do not think there's anything inherently wrong with Java, or with kids learning Java. I just think it's better to show them why programming is awesome first ("Look, you totally just made the computer do your algebra homework for you!") and THEN get into more complex (i.e. harder to debug) languages once they have a firm grasp of the basics like conditional logic, loops, objects, etc.
I feel that the blog is more about demonstrating against the fact that Java is too complex as a beginner language, not on how Java is the simplest, quickest, or even easiest, because of course it's not. All these comments make valid points, but as a person who has learnt Java as his first language feel that it opened me up to learning other languages quicker because of that fact that I found languages like Python much simpler, whilst I find many 1st-language Python students to be much more defensive and 'clingy' to Python because of its simplicity and directness.
While Python may be an easier language, I find that it is more difficult to debug than Java at times due to incompatible spacing alone, but that's beside the point.
I think that students should be able to decide their first language. I was 'stuck' with Java, but I don't regret it at all. In fact, after having transferred to another university with students having started with Python, I find that I'm ahead in terms of concepts dealing with OOP. I know that Python can do this as well, but Java (for better or for worse) shoves it down your throat.
Karel's great, it's how I first learned Java. Cuts down on all of the unnecessary stuff and boilerplate, and presents an easy way to learn programming logic and theory.
I have no doubt that you can get 11-14 year olds to understand Java's Hello World in a single hour, but understanding a pre-written snippet of code is a wholly different beast from being able to make appropriate predictions and inferences based on knowledge gleaned from that code.
Could your students explain how main() was called? Could they create their own functions and invoke them based on what they had learned? And how forgiving would Java be of minor errors, say, creating class a class named HelloWorld inside a file named Hello.java? Why does the filename even matter, if the class's name is defined right inside the file, or vice versa? And if the class is in a block inside the file, why can't they just create another block like the first one and have two classes in the same file? Why do they type 'javac HelloWorld.java', but not 'java HelloWorld.class'? How can java find the HelloWorld class if you're not pointing it to the class file? Why is 'javac' so damn picky about the file name matching the class name when you don't point 'java' to any files at all?
Seriously, there's a ton of voodoo in there. Things break in surprising ways, and it's hard to synthesize new knowledge based on prior experience.
Take Python, on the other hand. You can address things in a much more controlled order, with each step yielding practical information, starting with
print("Hello, world")
which tells the students how to call a function, and pass it an argument. Every other time they call a function or pass it an argument will look like this. Then you can show them how to make their own function:
def hello():
print("Hello, world")
But nothing gets printed? Hey! You've just explained defining a function, and based on the previous example, they can probably suggest how to invoke hello(). At this point, they can easily make and call new functions of their own. Then you can go on to introduce the basics of OOP:
class Greeter():
def __init__(self, name):
self.name = name
def say_hello(self):
print("Hello, " + self.name)
Sure, the "self" is a little magical there, but hey, you're comparing this to Java. Plus, you've got an interactive console that you can jump into and poke at the darn thing. Hey, what do I get when I say g = Greeter("Saundby")? Oh a "Greeter object". That makes sense. What can I do with it? Well, we made a say_hello, so what's g.say_hello? Oh, a "method Greeter.say_hello of <Greeter object>." And hey, it's the same Greeter object as g!
What if the students want to make a new class? They just put it in the same file, like you would expect. What if they want to rename the class? They just do it.
And you run it with "python filename.py" which appears to work exactly like how every other command that operates on files. There's no explicit compilation step to forget or trip over.
Yes, you can teach kids to read and understand a Java program, but what do you gain by handicapping yourself and foregoing the pedagogical tools, like an interactive console, available elsewhere? Similarly, what do they gain by being deprived of such a wonderful and frictionless means of exploring and experimenting with the language?
Not surprisingly, as a kid my 1st language was BASIC. My second language was 6502 assembly in 6th grade. I can honestly say that things didn't really click until I learned assembly -- things like line numbers bugged me, and some of the syntax in BASIC confused me (why does a function call have the same syntax as an array?). And then I studied digital logic circuits, with a brief diversion into CRT displays and video support in computers (I was really concerned about how did the information go from the computer to the screen) in junior high, and then C in 9th grade.
Python has a lot more vodoo than BASIC did. And whitespace having meaning is truly confusing, especially as a kid when its unclear that there's really a distinction between different types of whitespace (this used to kill me with Makefiles when I first started with those).
I guess my point is is that what a seasoned pro thinks of as voodoo is often very different than what a child just learning to program thinks is voodoo... especially young kids who like to ask lots of questions.
I illustrated the post with Python since it's my language of choice, but honestly, many of Python's benefits as a teaching language apply equally well to other modern languages.
If we can agree that experimentation is one of the most powerful ways to develop an understanding of a system, then by going with Java, you're consciously eschewing languages which support that goal by being:
1. Interpreted. It's hard to overstate the value of an interactive interpreter, which is in many respects akin to having a second instructor available for the students, on-demand. It can instantly answer questions about its environment, it makes exploration and experimentation trivial, and it's great when lecturing, as you can immediately explore any "what-if's" that your students raise.
2. More expressive. Aphyr demonstrated this pretty eloquently in another comment, but the less code that it takes to accomplish a task, the less code you have to understand before you're able to build something useful, and the easier it is to experiment as you go.
3. Multi-paradigm. If you're teaching someone programming, you want to be able to expose them to procedures, functions, objects, methods, recursion, etc. If you can do all of that in one language, you lower the mental barrier that your students must overcome before grasping each successive topic.
I believe that those facilities are great assets for both exposition by the teacher and exploration by the students, and I do not immediately see a compelling argument in Java's favor which sufficiently justifies foregoing the above pedagogic benefits. If the goal is to teach and create understanding, then surely the instructor should employ the tools that most readily support that objective.
Seriously, there's a ton of voodoo in there. Things break in surprising ways, and it's hard to synthesize new knowledge based on prior experience.
I've written a nontrivial amount of Java including a sizable Android app (aside: thanks Dobrow!) and still can't complete basic tasks like mutexing, sockets, or file IO without looking them up on StackOverflow. Eclipse is the only thing that makes that language's rigidity even barely tractable for me.
You're inferring a lot. And overestimating what can be covered in a single period in a room full of 12-14 year old kids, no matter what language is used.
Part of why the class takes so long to cover a HelloWorld program is that I explain each item, provide counter-examples (wrong class name, wrong signatures for main(), multiple main()s, adding other classes and methods to the file, etc. And seeing the error messages that come with different and interpreting them. We're not just copying a canned program off the board into a text editor (even at that, how good a transcriptionist do you think a 13 year old is? They can find _amazing_ new errors in 10 PRINT "HELLO".)
And yeah, there's still a lot of black magic. But I contain it, identify it, and cut away at it through the course of the class. Coming back repeatedly to the same subjects as I do so turns out to be a pretty effective way of fixing concepts in students' minds.
I appreciate that you might do it differently. Python was among the languages I considered for the class, I've blogged my reasons for going to Java. I revisit my choice of language after each school year. Each year so far, I've come back to Java as best serving the purposes of my classes from among the choices I have, warts and all it does the job.
I do expose the students to python, we go out to python.org and spend time on the online interpreter. We also try out ruby and C using online versions.
The sorts of expansions on the basic lesson that you describe are things that I already do. It just doesn't happen in the same class period as the HelloWorld program. There isn't time, and even if I did add more to one period, it then wouldn't stick, at least not in the class format I've got to use.
I also think you have some misapprehensions about how much material you can throw at a classroom full of kids using balky old computers. No matter what language I use, there's a limit to what you can reasonably expect to cover while still providing time for students to go through the mechanical parts of the exercise (typing and running the program, interpreting the results).
So far I haven't found Java to be an obstacle in that regard. And Java allows me to do what I want in class.
You also want to know why I use the tools I do in class. That's a whole different discussion. But the short answer is that we use the tools we already know, to keep the number of new things to a minimum at any one time. We'll be introducing an IDE later (Greenfoot.) I'll be using its facilities to teach object oriented concepts more fully than I can with text, as well. Plus, once we've gotten used to using it as an IDE, we'll be rolling in the elements of the Greenfoot framework. That will give us graphics and sound, which we'll use to get immediate feedback on the operation of our code.
I discuss my use of the command line when introducing programming in another of my posts. The purpose of the class is to know the system as well as they can from as many angles as they can, among them programming. This isn't a programming class, it's a general computers class that I've decided to expand beyond "keyboarding" and MS Office boredom.
>p.s.-I love Hacker News myself, and take all my students there to open it up to them.
I have nothing against middle school students. I like kids. I also think exposing HN to kids at an early age is a great idea. However something about that idea bothers me and makes me feel uneasy. I'm not quite able to put my finger on it. Anyone else feel the same way?
I show HN and YC to my middle school students and tell them a little about it. I just want them to see it. They'd rather spend time reading snopes if that makes you feel any better. ;) The only time I've heard of a middle school kid going back on his own was when one kid showed it to his dad, who was thinking about starting his own business.
I spend more time going over HN and YC with my high school students. I don't have time to teach them how to do their own start-up in class. But I want them to be exposed to the idea, and know some places to go for more info if they take to the idea, want to learn why I've ruined their life by teaching them Java, or whatever. :)
When you're writing an algorithm to count words in a file, would you prefer
or How about introducing anonymous functions? How much time will it take you to explain the intricacies of creating an anonymous subclass whose only purpose for existence is to encapsulate a single instance with a single method, inside which all variables from the containing scope must be marked as final? Or would you prefer something like Smalltalk? Sure, students can wrap their heads around both. But the important thing is the concept, not the expression. After all, if they go on to program in the real world, they'll be adapting their knowledge to different languages.