Slashdot Mirror
Head First Java
The Good
Of course, you can't learn Java without a good understanding of object-oriented languages. I made fairly heavy going with 'Learning Java' until I decided to dive in head first. Head First Java, that is -- a new book from O'Reilly that has a totally different attitude to teaching than I've seen before in computer books. It also looks like this might be the start of a series from O'Reilly, the website an introduction seem to assume that there will be more 'Head First' titles and I hope so. The style is humorous, full of graphics, cartoons, puzzles, quizzes and crosswords. It reminds me of the textbooks that used to try and teach me geometry and algebra in high school or my daughter's elementary books on Roman and Greek history I purchased for her at the British Museum. The style didn't work to teach me much algebra and geometry, but I wasn't anywhere near as motivated. This time, it worked. In a couple of weeks I worked through the book and finally have Java skills where I can branch off and start coding the projects I had in mind (though something more advanced will be required soon.)
In the introduction the authors examine learning and explain why they designed the book as they did. To quote from one section: "Some of the Head First learning principles. Make it visual. Put the words within or near the graphics. Use a conversational and personalized style. Get the learner to think more deeply. Get -- and keep -- the reader's attention. Touch their emotions." They argue that our brain is tuned to novelty, and that their style provides the novelty to keep your brain turned on. They also provide ten tips for good learning. That's one thing that seems to set this book apart from most other computer books, they say they think of their reader as a learner and indeed that's the way you are treated by the book. You can start to get a feel for their ideas by visiting headfirst.oreilly.com, a site devoted to the series. You can also grab a couple of example chapters from the books web page, which also has the usual marketing info, table of contents and errata.
The BadWhen compared to Learning Java the coverage is not as good. Head First really only covers the basics, up to and including creating a GUI with SWING and then touches a number of others; Learning Java goes on to explore, with a fair depth, network programming, web programming, servlets, applets, Java Beans, XML and other topics that are only touched on briefly in Head First. If the style of learning does not suit you then this will be an incredibly irritating and useless book, I'd give it a try first, though. If it isn't for you then the style of Learning Java might be better.
ConclusionWhen you get down to it, though, the only way to really decide on the worth of a tutorial is to decide how well it teaches. Head First Java excels at teaching. OK, I thought it was silly, I had a hard time making myself do the exercises, fill out the crosswords and solve the puzzles. Then I realized that I was thoroughly learning the topics as I went through the book. Learning Java was doing the same job, but the dry traditional method wasn't doing as well. Both books are well written, designed and constructed -- the style of Headfirst Java just made learning, well, easier.
It would seem to me that the 'Head First' approach is going to work wonderfully for the more 'beginner' topics, books for introducing you to a new style of programming, a new language or a radically different operating system or application. So if you're looking for a book to introduce you to Java then I can recommend Head First Java. Now if I could only find a book as good to introduce me to Common Lisp.
You can purchase Head First Java from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
In the introduction the authors examine learning and explain why they designed the book as they did. To quote from one section: "Some of the Head First learning principles. Make it visual. Put the words within or near the graphics.
"The habit of using pictorial aids, like any habit, is very difficult to get rid of. If, however, we take any responsibility for the effectiveness of our thinking habits, we should try to get rid of the habit as quickly as possibile, for it is a bad habit, confusing and misleading up to the point of being paralysing."
For the web it sucks, requiring extra client software. For standalone programs it sucks, it's impossible to code something lightly in Java--too bulky, slow, bloated.
And yet you don't even mention the area where Java gets the most use... server-side programming.
It has it's problems in that arena, too, but for certain applications, it's far better than the alternatives.
How can Java be slow? It's a language. Languages typically can not be quantified by speed.
;)
Implementations are a different story, however. What you mean to say is that in your non-benchmark toting experience, Sun's Java Runtime Environment, version 1.4.2 is slow. On this, I will agree.
You might want to investigate the other implementations of the JRE out there. IBM has one that is reportedly quite good. (Well, one person has told me it was worth it.) There is also Blackdown.
Regarding licensing, I also agree. It's muddy at best, and akin to selling your first born to Sun at worst. Depending on your vantage point, of course.
There could be a sort of natural progression there, though.
Maybe our reviewer was building, say, a Javascript-based navigation system for a website and decided to do it in Java to avoid cross-browser issues.
Oh, and the W3C never standardized JavaScript. ECMA did with ECMA-262.
--
the strongest word is still the word "free"
Sorry, but I think you are wrong on this one.
.Net framework -will- make money from the Java R&D ;)
There are a LOT of programmers out there with no experience of anything other than C, C++, Visual Basic, Perl etc etc. Just because students are taught Java and industry DEMANDED Java don't blame people for making a lot of money out of it!
Also, why should programming be hard? It shouldn't be. If I can find any tools, languages etc that make my job easier, quicker and less stressful I use them. And if I can be quicker it will be cheaper and if I am quicker and cheaper, I keep my job.
If my boss comes to me with a business problem and it can be solved in a day with Java, as opposed to a couple of days in Perl, VB or whatever then the business will make a decision to go with that.
I agree Sun won't get back it's R&D on Java, but I guess that MS with the
am i the only one getting a distinct "for dummies" vibe off of this book?
no comment on the book itself, it's just that "head-first" seems like it could very easily be the next "complete idiot's guide"...
well, it's nothing one behind the ear wouldn't cure
The dot com years produced millions of Java "programmers" that did not how to do much beyond blindly mimicing the Sun "Pet Store" J2EE example without understanding the fundamental concepts that underpin the technology.
How many other languages can you fill in the blank with? VB? C# (soon?)? Perl?
Sure there are folks who "learned" Java and really don't understand it. And sure, most of them are out of work...but calling it a "glut" is a bit of an overstatement. Most of those people won't find work in the industry. And if you're good a programmer, and work for a good company, you're still making good money these days (at least where I live).
There's a huge glut of programmers on the market with little or no experience using any other programming language other than Java.
So what if that's the only language you know? If you're a good Java programmer, what's the problem? I know a couple guys who just graduated with degrees in computer engineering. They "learned" plenty of languages in 4 years, but they only know one language well enough to use it professionally -- either C or Java.
Whereof we cannot speak, thereof we must be silent. --Ludwig Wittgenstein
I saw some 6-year old kids talking the other day. Kid 1: Have you seen my website lately? Kid 2: no. Kid 1: It has a new layout now. Kid 2: cool!
It's only a matter of time before these kids will want to learn JAVA, and a basic, picture-laden book is sure to attract their attention quicker than a tome that they probably can't even lift.
stuff |
No, he has not fallen under any misconception.
His problem was that he found that he could not achieve what he wanted using a javascript (an arguably limited web-baed scripting language) and decided to move to another language with more powerful features.
"I've been writing software for nigh on twenty years without it - why make life hard? "
I think there is a distinction here that needs to be brought up that I feel many programmers are unaware of. This is aimed for programmers who decided to go out there and learn Java who have never learned an OO language.
I think the goal of programmers should be to learn to code well. Having said that, those who then go on to "learn how to program java" from an instructional book are a bit mistaken in my humble opinion. There is a big distinction between language, which is a tool, and theory. The above analogy would be best explained by saying that you would want to learn how to write good stories and then picking up a bit on the english language. Good stories can be written in any language, pick one. It is the same for programming. Learning a language won't teach you to program well, it will just teach you to program in a different language.
Why learn OO? Let me take the analogy further: scripting languages really only allow you to write short stories. They do things similar to OO programming, but the scope of their use is quite limited and when you attempt to take them out of that realm they become difficult to use and unwieldy. An OO language allows you to write novels. They allow you to program larger programs, with a better underlying structure and more complexity.
"Injustice anywhere is a threat to justice everywhere." - Martin Luther King, Jr.
You must be joking. Please take a look at Smalltalk or Ruby before talking about OO.
I received this book just last week and am slowly working my way through it in-between work and other projects. I and am very pleased with it. The reviewer is correct in that this book makes learning much, much easier. It is, however, a little short on in-depth material, but I feel it can be forgiven for that in light of how well it teaches the basics.
How well does it teach? Through 4 years of a comp-sci degree that taught things using C++, I never understood Object-Oriented design as well as I do after just the first 7 chapters of this book. Hell, I'd recommend the entire book just for the chapter on polymorhism alone.
I won't go into detail since I'm short on time, but basically, if you're new to Java but know how to program in some procedural language already, this book might be what helps you go from writing programs the same way in Java to writing in Java, the way it was designed to be used. If you already know Java, though, you'll probably be bored silly. It's not a reference tome.
Good try - but Dijkstra wasn't talking about education, he was talking about abstraction. Remember his example? - where he mentions drawing an "abstract triangle", and how as soon as you have drawn a specific triangle, then you have made concrete decisions: "does it have an obtuse angle" etc. Dijkstra's point is that when you represent a general concept using a specific example, you get blinded to the possibilities offered by alternative examples. And he's right - to a certain degree.
You see, the counter to this is Richard Feynman. Do you recall in "Surely You're Joking?" when he mentions how he'd try to understand mathematicians by visualizing everything they said? "Take a set (a ball) - disjoint (two balls) - and then add hair, slice them up etc etc". I've used that technique ever since I read about it when I'm following arguments, and it works a beaut. It worked for him, because the mathematicians had probably not got their heads out of the equations to look at what they were doing.
So I think visualization is great (or even essential) for following a line of a complex argument or learning a technique - and that's where diagrams come in. However, unless your visualization is a perfect representation of the thing you're learning, it won't instruct you much about where the process *doesn't* work (unless it fails for your chosen example!). For instance, you won't find many pictures that can show you a nice OO class relationship, whilst simultaneously telling you much about *inappropriate* relationships.
In programming, mathematics, and any other "reason-oriented" activity, it's these negative cases that catch you out: the exception cases and unexpected inputs, the accidental divisions by zero - in short, the assumptions that you build in because you're focusing about the one way it should work, not the ways it won't. And so in practice, good experienced programmers need to clear their mind to see what they've written, not what they *think* they've written, and that, I think is Dijkstra's point.
But it's not got a lot to do with learning a new craft. And that's why good teaching books have good diagrams and plenty of manageable, relevant examples.
BTW - a good case of what Dijkstra is talking about is shown in the ancient search for the truth behind Euclid's 5th Postulate - where people got bogged down for centuries because they thought that the LINES and POINTS in geometry had to correspond to lines and points on a flat surface - plane geometry. But as soon as they abstracted it and stopped visualizing it, and treated LINE and POINT as abstract entities which simply obeyed the Rules, it gave rise to spherical and hyperbolic geometry. "Godel, Escher, Bach" tells the tale nicely!
My way of thinking about objects is to consider them as little people. Each person has a job to do, and does it single-mindedly; but they're simple folk, and so you should never give them more to think about or remember than they need to do their jobs. Each one should be a good team member: they should be polite to the other objects, do exactly what they say they will, as efficiently as they can, tidy up after themselves, be as quiet as possible, and not get in the other objects' way.
This analogy may look strange, but it seems to work for me! Especially when it comes to decomposing a problem into objects and determining their roles and responsibilities. When coding, I just think "If I was this object, what would I do? What would I need to know to do it? How should I communicate with the other objects around me?"
Ceterum censeo subscriptionem esse delendam.