Head First Java

honestpuck writes "Earlier this year I decided to learn Java. I'd spent some time using JavaScript without really getting my hands too dirty but I'd pushed it way to far and realized I needed a bigger hammer. Grabbing a copy of Learning Java, 2nd Edition from O'Reilly I started learning. First problem, I have to admit I've stayed away from object-oriented programming; after all, I've been writing software for nigh on twenty years without it - why make life hard? Sure, I understood the concepts and I'd done a little but never in a language so strongly committed to OO as Java." Read on for honestpuck's review of Head First Java, which he compares in style and content to Learning Java. Head First Java author Bert Bates, Kathy sierra pages 650 publisher O'Reilly rating 8 reviewer Tony Williams ISBN 0596004656 summary Good, offbeat Java tutorial with new approach to learning computer topics

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 Bad

When 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.

Conclusion

When 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.

Comments

Tremendous books

[mao che minh]

I found the book Learning Java, 2nd Edition to be a tremendous and rewarding enrichment to my object oriented programming repetoire. Head First Java was an amazing suplement to my studies, as it was thoroughly well written and could double as much as a reference for a seasoned pro as it could for a rank amatuer (such as myself).

The highlight of my reading would have to have been the erotic imagery left behind by some Barnes and Nobles passer-by (the previous reader of the book left some provacative, awe inspiring bra-busting imagery of his former girlfriend - a little note that accompanied the images detailed a narrative of how these images came to be).

I'm not sure if it's normal to get that excited when reading about an object oriented programming langauge, but I have to say, it was certainly the greatest computer science book that I have ever read in my 35 years.

Re:Tremendous books

[ERJ]

Only on slashdot would a post about finding an exotic picture of someones girlfriend in a java book be rated +5 Insightful.

Re:Tremendous books

[Anonymous Coward]

Wow, this has to be the best karma whore troll I have ever read. Good work.

Re:Tremendous books

[scorp1us]

This thread is worthless without pics!

Re:Tremendous books

[Scaba]

Thank goodness for Python.

Amen, my brother.

JavaScript != Java

[Anonymous Coward]

When will people start understanding this !!!

Re:JavaScript != Java

[Anonymous Coward]

!= means "Really really is equivalent to", right?

Re:JavaScript != Java

[Anonymous Coward]

When we rename them back to Livescript and Elm. And even then, doubtful.

Re:JavaScript != Java

[gekka]

He figured he needed Java as a bigger hammer to do DHTML.

Re:JavaScript != Java

[Anonymous Coward]

Oak, not Elm.

Re:JavaScript != Java

[Anonymous Coward]

Pine Is Not Elm.

EWD 696

[pheared]

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."

Re:EWD 696

[Anonymous Coward]

What is that a quote from? As a technical trainer we are taught that there are different types of learners and one of those types is visual. They learn best by seeing examples and graphics. That quote sounds like elitist bullshit that makes it seem like all learning should be done with dry imageless textbooks.

Re:EWD 696

[pheared]

http://www.cs.utexas.edu/users/EWD/ewd06xx/EWD696. PDF

Re:EWD 696

[binaryslave]

Is Dijkstra talking about education here or is he talking about memory. Or are those two concepts so intertwined that he was talking about both.

Re:EWD 696

[pokeyburro]

Dijkstra was talking about cognition in general. His thesis, as I always interpreted it, was that every concept should be dealt with solely in terms of language; the best language in this case would be mathematical symbols.

EWD 696 does give some good points supporting this. If you illustrate something with a picture, there's a risk that the picture will trick the viewer into considering only a subset of the cases possible. For example, you might be doing some trigonometric proof, and to help yourself through it, you draw a simple triangle to stare at. You try to be careful, and not make it equilateral, or isoceles, so you move the top vertex over a bit to the right so it's scalene, and as a result you figure that anything you try on that triangle ought to work on any possible triangle. But perhaps you've now tricked yourself into assuming that any triangle's height segment (by which I mean the segment intersecting the top vertex and perpendicular to the base) is contained entirely within that triangle, and divides it into two smaller triangles. It shouldn't be hard to imagine a counterexample, which might not be covered by the "proof" you end up with.

However, as deep as is my respect for Dr. Dijkstra, this was one belief with which I could never fully agree. I would say that every important scientific or logical argument certainly should be expressible as pure math. I would also agree with EWD that the graphical approach is not "more natural". Rather, it's the other way around. One might say that God made the universe out of math; the nice view was just a pleasant outcome.

But I do not believe in forcing oneself to deal solely in terms of the math, though it's surely a worthwhile and underused exercise. I believe the mind's eye for visual patterns can sometimes spark an idea for solving a problem, that would never have been thought of by considering the equations alone. (The Tufte quote is relevant here, btw; there are good illustrations and bad illustrations, and sometimes a good illustration is just fun!)

To me, the optimal approach to thought should be look at the equations (or description, or spec, or what have you), think really hard, and if nothing comes from that after a while, see if the picture helps. Heed EWD 696, though, and don't let yourself be tricked! When you finally arrive at what you think is an answer, express it solely in terms of the math. Only then will it be truly solid.

More to the point, don't get too deeply into the habit of relying on pictures to learn. EWD would say don't do it at all; I think it's fine, but always remember that they're illustrative. They're like analogies. They may help you with a new concept, but you can only take an analogy so far. Always do the math in the end.

Re:EWD 696

[TheWanderingHermit]

"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."

Anyone who would say that obviously has no knowledge of how people learn and how different people learn with different styles.

As someone who spent 10 years with learning disabled and emotionally disturbed students, I can say one of the most effective teaching aids for ANYONE is finding out how they learn and presenting material in the style in which they absorb it the best. Since I worked with those who had the most difficulty learning, I had to learn as much as possible about how we ALL -- disabled, "normal", or gifted learn.

In a nutshell, anyone who can make a statement like the one above is ignorant. It has the sound of someone who is so busy showing off how intelligent he or she is that he has yet to realize how little he knows about people.

Perhaps it was written by someone who does well with the style of learning he describes because he spends all his time in books and on the web and has not yet learned how to deal with the real world yet.

Re:EWD 696

[jcast]

Learning is one thing, but thinking/reasoning is another. Dijkstra's point is that, however you learn a concept, relying on graphical `reasoning' to find out new ideas/theorems is a tragically bad idea.

Re:EWD 696

[jcast]

No, it was written by someone with a clue what mathematics is and how the underlying reasoning works. Pictorial reasoning is not reliable; if you try to use it because you're a ``visual learner'', you will fail.

Re:EWD 696

[logpoacher]

Hi WanderingHermit,

It was written by Edsger Dijkstra (one of the most influential thinkers in software design). A great guy. Died last year, I think.

But he wasn't talking about teaching - he was talking about conceptualizing - in particular, about reasoning in software development and mathematics. He argued that visual design tools in programming made you focus on the thing that was made visible, (which is usually the easy bit), rather than the hoards of less visible possibilities, wherein lie bugs, limitations and assumptions.

He's probably right - although I know enough programmers who have problems expressing the basic requirements to suggest that a bit of vision can upgrade a hopeless programmer into a fairly hopeless one. It may be that his reasoning explains why visual programming tools have never replaced the text editor for anything other than very simple software development, just as graph plotters haven't replaced equations for mathematicians!

But this has nothing - much - to do with teaching or learning....well, judge for yourself, here's the original:

http://www.cs.utexas.edu/users/EWD/ewd06xx/EWD696. PDF

To be honest, I don't think the parent post is relevant - the quote is selective and out of place. Interesting to be forced to become aware of that, though: it's a non-obvious subtlety about progression from novice to expert.

Cheers.

Re:EWD 696

[lightspawn]

"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."

"Some quotes apply to some situations, but not others; trying to apply their ideas indiscriminantly leads to dismissal of truths and acceptance of untruths. Caution and care must always be used, and once one takes the time to do that, one may well find the quotes themselves meaningless".

Re:EWD 696

[TheWanderingHermit]

You make some excellent points. The strongest of these is "the quote is selective and out of place." I would strongly agree with you there. I don't think this quotation should be at all directly applied to learning/teaching. I can see where visualization might be a problem with some types of programming, but I have also found that "visual" thinkers often do very well by creating their own ways to visualize abstract ideas.

Thanks for the URL. I'll check into it in the next day or two, when I expect to have more time.

Overall, with what I've seen about how people learn, I would never feel safe teaching anything to any group of people and insisting on using only one method of presentation.

Re:EWD 696

[TheWanderingHermit]

Actually, I did quite well in my math classes, when I was still seriously considering and working towards a Master's (until I decided to focus more on people and teaching instead). While there are a lot of situations where an actual picture won't work, you'd be surprised at how well visual learners can adapt and can create "visualizations" of abstract concepts in their heads. In order to grasp something, I often had two or three or more related visualizations in my head, overlapping, to avoid "contradictions."

Another point, one I should have mentioned earler: research has shown (and my experience backs this up 100%) that while it is possible for "visual" (not the best term, but let's stick with it for consistency) to sometimes understand how the more "concrete" learners perceive or learn, it is basically impossible for a "concrete" learner to understand a "visual" learner and see why there might be any advantage to that learning style.

Re:EWD 696

[be-fan]

One more reason I hate mathematicians.

Re:EWD 696

[jcast]

No, you don't hate mathematicians---you hate mathematics. Unfortunately, I will not enjoy watching you burn in hell; I wish I could.

Re:EWD 696

[be-fan]

I have nothing against mathematics. Its the "our school of thought is the only one" arrogance that I can't stand.

Re:EWD 696

[jcast]

I'm sorry; how is it arrogant to understand what mathematics is?

Re:EWD 696

[be-fan]

Pictorial reasoning is not reliable; if you try to use it because you're a ``visual learner'', you will fail.
>>>>>>>>>
I take that as an insult to visual learners (largely because of the quotes). If that's not what you meant, you should have structured your *language* such that you didn't come across as a jerk.

Re:EWD 696

[jcast]

Here's a hint, buddy: grow a damn thicker skin when you're talking to fucking trolls.

Now tell me you thought my quotes were insulting.

Re:EWD 696

[be-fan]

This has nothing to do with my skin. I'm not a visual learner, but a verbal one. I'm reacting to the attitude I see among a lot of smart math-types on Slashdot.

Re:EWD 696

[kasperd]

Died last year, I think.

That is correct.

I await a review of...

[PHAEDRU5]

..."Mr Bunny's First Cup o' Java"

Re:I await a review of...

[Anonymous Coward]

Careful...I'm not sure Slashdot readers are as experienced in enterprise development as Famer Jake.

Misconception

[shaldannon]

It appears our reviewer has fallen under a common misconception.

Java != JavaScript

The two are not even related. Yes, you can use them together, but the only thing they have in common are the four letters "J-a-v-a". It's bad enough when normal people fall under this misconception. We don't need supposedly technically savvy people succumbing to the same thing.

JavaScript was developed by Netscape as a dynamic browser language, and "extended" by Microsoft. The W3C "standardized" it, and then both Netscape and Microsoft went about with their own proprietary versions.

Java is owned by Sun Microsystems and was originally an embedded systems language. Sun took the language, renamed it "Java", and added web functionality.

Re:Misconception

[Anonymous Coward]

It is almost like somebody saying - I wanted to study cartography because I already know something about cars.

Re:Misconception

[M-2]

The current W3C approved release of it is, I believe, currently referred to as ECMAScript, in an attempt to separate the two. (The ECMA is a European governing body on standards, and I do not recall what it stands for at this time).

I wouldn't mind seeing them separated like that - it would make more sense and minimize confusion, as well as the interleaving of books in bookstores. "Java... Javascript... hell, they must be the same thing!"

Re:Misconception

[shaldannon]

I believe you are correct on the name, and I think it's an excellent idea. Unfortunately, the confusion has been going on so long that I think we're stuck with it :(

Re:Misconception

[Ranx]

The W3C "standardized" it, and then both Netscape and Microsoft went about with their own proprietary versions.

The W3C has not much to do with JavaScript.

ECMA is the organization who made JavaScript into an independent standard (ECMAScript).

Re:Misconception

[SweetAndSourJesus]

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.

Re:Misconception

[M-2]

It is almost like somebody saying - I wanted to study cartography because I already know something about cars.

Bloody hell. That's the most perfect metaphor I've ever heard for it. Brilliant!

Re:Misconception

[$lacker1]

first, you're absolutely right. java and javascript are different, and good explaination of the differences. i couldn't agree more.
in addition to the 4 letters, they do also have a similar syntax....pretty cosmetic similarity, not enough think you could learn one from the other, but i think it adds to the confusion.

Re:Misconception

[stratjakt]

A better metaphor is C the language and the C shell.

People who use the tools know that, even if syntactically close, they're different tools for different tasks.

And noone else gives a shit.

Re:Misconception

[Paul Bain]

It appears our reviewer has fallen under a common misconception.

Java != JavaScript

Right. And the presence of that misconception suggests that the reveiwer is not well informed. If you want an informed review of this book, you should probably look elsewhere.

Re:Misconception

[sokeeffe]

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.

Re:Misconception

[Waffle Iron]

Another misconception he seems to have is that JavaScript isn't object oriented. It actually uses an interesting object system that uses "prototypes" rather than classes. This system, while somewhat strange, is actually more flexible than a lot of class-based systems. (IIRC, one of the more extreme examples of a prototype-based language is "self". It's worth checking out if just to help you understand by counterexample exactly what's going on when you use classes in a normal OO langague.)

Re:Misconception

[baldass_newbie]

If you want an informed review of this book, you should probably look elsewhere.

You could say that about half the book reviews (maybe more as I rarely read them anymore). I only checked out this one because of the first sentence, I knew the comments would be far more interesting than the review.

Re:Misconception

[Saucepan]

It would be nice, but "ECMAScript" has to be tied with the late, unlamented "PCMCIA" for Ugliest Name in the Galaxy. It has zero probability of ever displacing the highly buzz-friendly term "JavaScript" in common usage.

Re:Misconception

[Malc]

They're not completely separate. I remember seeing Java objects being instanciated in JavaScript embedded in pages destined for Netscape. The stuff never worked in IE.

Re:Misconception

[HenryFlower]

They're not completely separate. I remember seeing Java objects being instanciated in JavaScript embedded in pages destined for Netscape.

Right, and by that logic Python is related to Java 'cause you can instantiate Java objects in Jython. And C is nearly the same as lotsa languages, 'cause lotsa languages have C extensions which allow you to instantiate C objects in the language. Javascript and Java have only the notion of being roughly C-looking languages which came out at roughly the same time, and were both championed by Netscape.

Re:Misconception

[haystor]

If you people would actually read the review its quite clear that he had outgrown JavaScript and was moving on to Java (Java being a bigger hammer than JavaScript).

He also never staid that JavaScript has not object system, just that he's never done much with objects. Thus he needed a good basis in how to programm OO, something you don't have to have to use JavaScript.

Re:Misconception

[Anonymous Coward]

I think the parent poster was commenting on the fact that the two have absolutely nothing to do with each other beyond an unfortunate marketing decision (renaming ECMAScript to JavaScript.) The reviewer could just as easily said:

"I'd played around with a paint brush before, but found it couldn't do what I wanted it to do, so I decided to learn how to use a hammer."

Re:Misconception

[Malc]

Instead of being a prick, you could have just reminded me that what I'm remembering is actually a feature of LiveConnect.

Re:Misconception

[Pinky]

Yes, indeed. Someone who already knows Java should be reviewing it. They should also have 5 years experince with OO design principles. These are the perfect people to review entry level books.

Re:Misconception

[(a*2) (ron)]

If you are interested in prototype base languages, make sure to check out Io as well.

And if you are interested in functional programming with javascript, go here.

Re:Misconception

[mindstrm]

Although it may be innocent, the fact is, the average person thinks javascript is a simplified version of java. So it's best not to ever mention them together.

Two languages with separate domains, separate syntax, that are totally different in basically every possible way, except for the name.. why conclusion is someone supposed to develop other than the implied relationship between them?

Re:Misconception

[Merk]

Waitasec, C has objects??

Re:Misconception

[baldass_newbie]

Earlier this year I decided to learn Java. I'd spent some time using JavaScript without really getting my hands too dirty but I'd pushed it way to far and realized I needed a bigger hammer.

The first sentence seems to indict the dude. This is mostly because the wording was not well chosen. Nevertheless, when someone says they're deciding to 'learn Java' because they've used JavaScript without getting their 'hands too dirty', the following analysis will be suspect, if not for the possible confusion between technologies than because of the inability to communicate effectively.
I don't know about you, but I don't have the time or patience to read crap. And I'm pretty sure that was my whole point, if you read my post, that is.

Re:Misconception

[AlanS2002]

Goody, someone who can comprehend simple english sentances. `bout time.

Re:Misconception

[Your Pal Dave]

It appears our reviewer has fallen under a common misconception.

Nothing in the review implies to me that the reviewer was equating javascript with java, other than the fact that those words appeared in adjacent sentences. Try substituting 'BASIC' for 'javascript' in the first sentence -- the reviewer's general implication is unchanged: language A was inadequate for his work so he decided to study B, not that language B is any way related to language A.

Re:Misconception

[yomegaman]

At least "ECMAScript" is pronounceable, but I agree that it sounds more like a horrid skin condition than a programming language.

Re:Misconception

[Anonymous Coward]

I guess there could be a couple applications for Java that could replace a JavaScript implementation. Some type of client-side dynamic graphing in the browser, for instance. You could do it in Javascript using the DOM, but it may be nicer to do in in an Applet.

Somehow I don't think this reviewer is doing this though.

Re:Misconception

[hellswraith]

Yes, it is funny how people get them confused. I had a Java class in College, all the HTML people that just finished the course thought that Java would be cool to take (thinking that they could do some cool tricks on their HTML page). Not knowing that they were actually thinking of JavaScript, not Java. Out of 40 people that took the class, only 6 of us finished it. I would say 30 of those 40 thought that it was JavaScript and quit. The others just sucked at programming.

Re:Misconception

[Anonymous Coward]

Java has now been renamed to ECMA so we are back at square one.

Re:Misconception

[Anonymous Coward]

Avoid cross-browser issues by using Java applets? Are you insane? The only thing that avoids cross browser issues is HTML 1.0. Anything else just screws some users. Java with its different VMs and its need to be installed on IE, and its bloated size is a poor candidate for a cross browser technology, especially for any GUI work (no Swing in 95% of the VMs out there)

Re:Misconception

[ClosedSource]

I think calling their scripting language JavaScript was the first of Netscape's mistakes in accomodating Sun. The biggest mistake, of course, was wasting time rewriting Navigator in Java instead of concentrating on competing with IE.

It reminds me of the old Borland that got the C++ religion and thought they had to write all their Windows apps in C++. They did some nice work, but it delayed their entry into Windows and was a significant step toward the dominance of MS Office.

Re:Misconception

[Anonymous Coward]

> Waitasec, C has objects??

Ok, now we know you know the difference between C++ and C. Are u happy now?

The guy just didn't put the "++" in the name but any retard can figure out that he is referring to "C++".

Re:Misconception

[Performer Guy]

You seem to be under the misconception that you don't need to read what he wrote carefully before criticizing. The reviewer did not think they were the same thing, he clearly says he "needed a bigger hammer".

Re:Misconception

[chef_raekwon]

I don't know about you, but I don't have the time or patience to read crap. And I'm pretty sure that was my whole point, if you read my pos

and yet, you manage to find time to read SLashdot...... ;)

Re:Misconception

[Anonymous Coward]

Actually, the most ridiculous thing I hear is that Java is like c -- that always makes me want to puke.

Re:Misconception

[Anonymous Coward]

except a paint bush is for painting and a hammer is for hammering.

javascript is for coding and java is for coding.

Re:Misconception

[Anonymous Coward]

people can't see past the {curly braces}

Re:Misconception

[logpoacher]

Remember this?

Java is like the Taj Mahal.

JavaScript is like the Taj Mahal Tandoori Restaurant, New Orleans.

Or something like that :-)

Re:Misconception

[Darren.Moffat]

There never was an effort to re-write Netscape Navigator in Java. Some version of Netscape Naviagtor had a Java VM embedded inside them so they could run Java Applets.

Re:Misconception

[baldass_newbie]

and yet, you manage to find time to read SLashdot...... ;)

With a setup line like that, I was wondering how long it would take.

Re:Misconception

[ClosedSource]

See the following reference:

Yoffie, D.B. and M.A. Cusumano. "What Netscape Learned From Cross-Platform Software Development." Communications of the ACM, Vol. 42, No. 10 (October 1999): 72-78.

Re:Misconception

[kubrick]

I think calling their scripting language JavaScript was the first of Netscape's mistakes in accomodating Sun.

I always thought they were just trying to cash in on all the Java hype, and they called it JavaScript because they started shipping a VM with the browser at the same time. Did Sun get much of a say in this?

Also, why were Sun and Netscape so friendly? Didn't Sun pick up Netscape's web server from AOL during one re-organisation?

Re:Misconception

[ClosedSource]

"Did Sun get much of a say in this?"

It's only speculation on my part, but I think Sun would have sued Netscape over JavaScript if it didn't like it. I suspect they thought it was another way to keep the Java hype going.

Re:Misconception

[ClosedSource]

Don't leave the bathroom just yet.

Java has what I would call hidebound compatibility with C. That is it uses much of C's syntax in order to overcome C programmers fear of learning something new (this attitude is not limited to C programmers, of course). Any language that uses operators like "++" or "+=" is similiar to C.

Don't know about Head First Java, but ...

[UTaimSRC]

The Java Cookbook is the way to go for beginners.

http://www.oreilly.com/catalog/javacook/

Re:Don't know about Head First Java, but ...

[BFKrew]

The Cookbook is a great little book, but it only really provides snippets of code and little examples of how to achieve basic tasks. It does not teach you about Java, about OOP, how to build programs or anything about the differences in things like Applications, Applets or Server Applications etc.

Re:Don't know about Head First Java, but ...

[UTaimSRC]

I used that book plus the Java in a Nutshell and together they make a good combination.

The Cookbook is not really an "introductory" book per-se but it still helps out while the Java in a Nutshell is more of the generic intro to Java book.

Re:Don't know about Head First Java, but ...

[MAXOMENOS]

The Cookbook is good for snippets of code. To really learn Java, though, you need to read complete examples. That's where Java Examples in a Nutshell comes in.

Re:Don't know about Head First Java, but ...

[Rudeboy777]

Java Cookbook is indeed an excellent book, but I don't think I would recommend it for beginners. I find case study books to be a much better way for an experienced programmer to see how an unfamiliar language works.

New Riders' XML, XSLT, Java, and JSP: A Case Study in Developing a Web Application is a fine example of a case study book that I recommend.

Followed closely by...

[BiggerIsBetter]

..."Mr Bunny's First Hit o' Crack"

Re:Followed closely by...

[Anonymous Coward]

ha ha. ha.

Re:I'd like to take this oppertunity..

[Anonymous Coward]

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.

Yes.

[Anonymous Coward]

See you at the next GNAA convention...

Re:I'd like to take this oppertunity..

[dood]

Oh, for fuck's sake... Nothing like a little slashdot FUD.

Malocchio, people like you really need to invest some time into *learning* about Java before you just rehash the same old TIRED and incorrect comments about the language.

Belvue languages.

[Anonymous Coward]

"Sure, I understood the concepts and I'd done a little but never in a language so strongly committed to OO as Java."

Objective-C is more commited.
Eiffel is more commited.
Smalltalk is more commited.

Re:I'd like to take this oppertunity..

[pheared]

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. ;)

Re:I'd like to take this oppertunity..

[malocchio]

would you like to see a scan of my Java cert? :P

Seems like a Good Thing(tm)

[StringBlade]

Hopefully O'Reilly will continue in this vein of beginner books - the Head First series - as an educational and fun way of jump-starting the reader into the subject matter.

Once the reader has absorbed the introductory material in the Head First book, he/she is ready and more able to delve deeper into the subject with a 'heavier' book -- in this case, Learning Java.

Java what?

[Anonymous Coward]

...a language so strongly committed to OO as Java...

Hahahahahhhahahahaha... wait .. hahahaahaha... okay I hahahahhahhahahaah... shit, sorry.. ahahahahahahahaha... what were you saying?

Re:I'd like to take this oppertunity..

[DarkBronzePlant]

I used to whine and make excuses like that too, while I was frustrated and struggling to learn Java and OO.

Get the Tremendous books Free

[MarkWPiper]

I agree, Thinking in Java is a great book. Check it, and Bruce Eckel's other works out for free at:

mindview.net/Books

You'll be glad you did!

Try Thinking in Java 3rd Edition

[nih]

best book on java imo, and its free to try out
http://mindview.net/Books/DownloadSites

Re:Try Thinking in Java 3rd Edition

[crwfrd]

I too am a fan of Eckel's books. They emphasize the big picture that leads you to thinking in the language's "paradigm" while still fully covering the details.

It's true that Eckel's books are less than ideal as reference texts -- he's too conversational. But in introducing not only 1) the semantics of a language and 2) its syntax, his strength best lies in 3) teaching the way the language expresses programming design concepts -- helping the reader to appreciate that language's fundamental design patterns.

And of course, his books are FREE. What more could you ask for?

Re:Try Thinking in Java 3rd Edition

[sal]

I happen to like it as well. It's one part tutorial, one part reference and one part cookbook. The biggest issue I have with it are his use of his own custom unit testing framework (he does cover JUnit later on in the book) that most of the example source uses. There are plenty of example code snippets, most illustrate one and only one point. Unfortunately, many of those examples are less readable than they would be if Mr Eckel left out the references to his monitor unit test class. I would recommend this as a second Java book, not a first. Once you make your way through an introductory text, Thinking in Java would be a good book to keep around to refresh your memory on lesser known or forgotten bits of knowledge.

Re:I'd like to take this oppertunity..

[Anonymous Coward]

I'll give anyone on slashdot 1 million dollars if they can write a software application in the language of their choice consisting of less than 100 lines that is faster than the equivalent java application that I would then write. Any takers?

Re:I'd like to take this oppertunity..

[nekosej]

Don't bother. It's obvious that you are certifiable.

Re:I'd like to take this oppertunity..

[Alkonaut]

As it was pointed out earlier javascript!=java, so if we disregard applets then java does certainly not need any extra software on the client side. It's like just like php, only prettier. Actually the only thing I've seen that's prettier for web applications is... here we go: c# :)

Re:I'd like to take this oppertunity..

[almiki]

Java is only slow because it runs on top of a virtual machine, where programs from something like C get translated into machine code that runs on our physical machines. I think some years back, there was actually an effort to produce a real Java machine that could run the Java-produced code without the extra layer in between, but I guess that never quite got finished.

I actually really like Java for programming when I'm not so concerned about speed.

Re:Java ain't really OO

[Tumbleweed]

And if you want a C-like language with real OO aspects (ala Smalltalk), then you should be checking out Objective-C, which is completely implemented by gcc, nicely enough.

Re:Java ain't really OO

[Anonymous Coward]

but java only uses that subset of OO that's actually useful. How often does one need to differentiate (using C++) between virtual and non-virtual methods? (I cant say how long I've pulled my hair out figuring out one of those such problems) How about how many if not all books about OO say dont do multiple inheritance? Java simply doesnt allow it. It's API is far simpler and easier to use than any STL library. Templates are coming with Java 1.5, but they're being called generics.

also, try upgrading. you may find more modern JVMs (like IBM's) more speedy and efficient.

Re:Java is bad for our industry

[BFKrew]

Sorry, but I think you are wrong on this one.

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 .Net framework -will- make money from the Java R&D ;)

Re:I'd like to take this oppertunity..

[Anonymous Coward]

it's impossible to code something lightly in Java

because it was made for large, robust, easy-to-maintain-because-the-language-is-readable (meaning it's not write-only-code, like C++ or complex Perl code) systems, not quick 10-line throwaway scripts that you appear to think so.

OOP for the procedural programmer

[djrisk]

I too had some problems w/understanding object-oriented programming. I was strong w/procedural languages, and your standard top-down programming style, but I struggled grasping the concepts of OOP.

I found "The Object-Oriented Thought Process" to be a great jumping-off point in helping me familiarize myself with how to think in-terms of OOP.

The intro to OOP chapters that are in most introductory books are OK, but they just didn't do enough for me.

Re:OOP for the procedural programmer

[Jucius Maximus]

"I too had some problems w/understanding object-oriented programming. I was strong w/procedural languages, and your standard top-down programming style, but I struggled grasping the concepts of OOP. I found "The Object-Oriented Thought Process" [amazon.com] to be a great jumping-off point in helping me familiarize myself with how to think in-terms of OOP."

If you're going to do Java, OOP is essential IMO.

I'm working on a project right now at work (in MSAccess VBA, ugh) where Java would be a godsend. Using overloaded constructors for objects, polymorphic programming and OO techniques would probably reduce the quantity of code for this project by a factor of 10.

So if you're learning java, make a point of learning how to build those basic abstractions like nodes, linked lists, stacks, queues, binary trees, AVL trees, etc as object oriented structures. IMO it's way easier than doing it in C with structs and pointers to the moon and back. (Don't get me wrong, C has its strong suits. For example you get to create a celebration dance to perform when you eliminate all memory leaks.) In the end, however, if you build the basic abstractions it will help you both in creating efficient alogrithms in all languages and in learning how OOP really should work.

Re:OOP for the procedural programmer

[Tablizer]

I'm working on a project right now at work (in MSAccess VBA, ugh) where Java would be a godsend. Using overloaded constructors for objects, polymorphic programming and OO techniques would probably reduce the quantity of code for this project by a factor of 10.

I realize that you are comparing to Microsoft languages, but I am skeptical of your claim of 10. Reducing code size is not one of the top OO claims. Then again, there is no top claim that I can find. It used to be "reuse", but that fell out of style as a selling point.

-Your Neighborhood OO Skeptic-

Re:OOP for the procedural programmer

[Jucius Maximus]

"I realize that you are comparing to Microsoft languages, but I am skeptical of your claim of 10. Reducing code size is not one of the top OO claims. Then again, there is no top claim that I can find. It used to be "reuse", but that fell out of style as a selling point."

The part about reducing code length was mainly in reference to polymorphic code. OOP helps and I you can't really do poly without it, but it's mainly the polymorphic references that do the most toward reducing code size in this case.

Re:OOP for the procedural programmer

[Tablizer]

but it's mainly the polymorphic references that do the most toward reducing code size in this case.

I am still skeptical. I would like to see a fairly realistic code example for typical biz apps, not shape and animal textbook examples.

The best way to learn Java...

[barcodez]

if you want to learn a particular Java aspect look at Sun Java Tutorials. (they are excellent a free).
If you want to leatn OO programming and Java I would suggest Think In Java (it's the best and it's free).

Re:The best way to learn Java...

[FortKnox]

I have to second the 'thinking in java' suggestion, by Bruce Eckels. I learned java by that book, even though I already knew OOP. If you want a good C++ book, "Thinking in C++" by the same guy is the way to go.

In fact, any book by Bruce Eckels is a great read. It reads like a book, and teaches you in easy terms. It isn't like reading a math book, which most programming books tend to do.

Re:I'd like to take this oppertunity..

[sahala]

You, sir are 100% correct.

I'm going to send a memo to the top 300 US companies (any index, take your pick) and inform them that all this time they were wrong about implementing business solutions in Java. Why? Because you (mallocchio) took the "oppertunity" to say that it "sux". Instead they should be using something light, like C, or maybe even assembly if they're hardcore enough. I mean, all these hundreds of corporations can't possibly be right. Their projects obviously have all failed because they used Java.

I mean the only reason Java is popular in the enterprise world is because of Sun's wonderful marketing department. Those sneaky bastard marketers ... they got the best of us. I mean they totally did their jedi mind trick on me -- I'm gonna have to cut off my head now because it's now known after your esteemed declaration that "Java sux".

P.S. I know you're trolling.

Re:Java is good but slow

[Blitzshlag]

Uhhh, talking out of your ass? Have you ever programmed?
Congrats on choosing Java, its a great language, and far better than javascript which is more like assembly than anything else.

The two aren't even comparable. JavaScript is a web scripting language, and nothing at all like assembly.

Further examination showed that C could do the job as it was significantly faster due to being more object oriented and using a just in time compiler.

C is not OO at all! Assuming you meant C++, you're still wrong!

YHBT YHL HAND

[Anonymous Coward]

Common Lisp

[Lemmy Caution]

Now if I could only find a book as good to introduce me to Common Lisp.

What's wrong with the Paul Graham books on LISP? On Lisp can even be downloaded for free, and ANSI Common Lisp is a great introduction to the language.

Re:Common Lisp

[ctrimble]

On Lisp and ANSI Common Lisp are pretty advanced. I'd probably recommend the Winston and Horn book, instead.

Re:Common Lisp

[William Tanksley]

How about "The Little Lisper"? That book's got pictures, puzzles, cute excercises, is reasonably interactive... Sounds similar to this.

And it takes you all the way up to Y-combinators. Whew.

-Billy

Re:Common Lisp

[uncadonna]

The Little Lisper is a wonderful book, but it's dramatically different in style and approach from the head-first stuff.

Those who find it brilliant rather than bizarre may also be interested in also be interested in The little Schemer, The Little MLer and A Little Java, A Few Patterns by the same authors, all MIT Press.

Re:I'd like to take this oppertunity..

[wik]

Most modern JVMs compile Java bytecode to optimized native machine code. If you spend most of your execution time in your application (not the JVM), Java is quite competitive with C.

If you're interested in seeing how this really works, I'd suggest downloading the IBM Jikes RVM (Research Virtual Machine), which is a JVM/JIT compiler that is almost completely written in Java (it actually can recompile itself at runtime, in addition to your application). Since it's written to be a platform for compiler research, it's not the fastest JVM on the planet, but it has reasonably well-documented code and it certainly does what you described.

Re:I'd like to take this oppertunity..

[Anonymous Coward]

would you like to see a scan of my Java cert?

would you like to see a scan of my penis?

Best Series For Learning Java

[jyuter]

Has got to be the Core Java Series. Between the fundamentals and the advanced books, I haven't found anything as complete and as clear as this.

Re:Best Series For Learning Java

[JoeWalsh]

I'd tried Java back in the 1.1 days, but had no real use for the language at that time so I let it drop. Earlier this year, though, a project dropped in my lap that really needed what Java provides, so I started looking for good books on the subject. After browsing through the tremendous amount of Java books at my local bookstore, I settled on the Core Java series.

By reading the two volumes you mention, I was able to come up to speed quickly. In fact, I finished the project just one month after buying those books.

I highly recommend the Core Java series to anyone who wants to learn the Java programming language.

Re:Java is good but slow

[butane_bob2003]

... C could do the job as it was significantly faster due to being more object oriented and using a just in time compiler.
Um.. I don't think you are talking about plain old C there. (Or maybe this is a grammatical problem) I dont know how even significantly faster code could keep up with things happening at the sub-particle level (but then, I know very little about particle physics). I dont see how this could be just a software speed issue. Maybe Java is not the tool for the job, but most of the time it is a matter of preference. (unless the need for realtime measurements come into play)

question...

[inkedmn]

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"...

Viewing at level 5

[955301]

This is the first time I've tried to look at a story with 63 comments with my threshold set to 5, no comments showed up!

Somehow I knew though, when the article starts with I decided to learn Java because Javascript wasn't good enough., that there would be trouble!

Begun, the Javascript != Java flamewars have.

Re:Viewing at level 5

[Anonymous Coward]

Read more closely; the article could just have well said "VBScript wasn't up to the task, so I decided to try Java." The comments about Java!=Javascript seem to be knee-jerk reactions to seeing the two in the same paragraph; the author makes perfect sense if you read the whole context.

Re:Viewing at level 5

[Anonymous Coward]

I won't bother to read the article. The problem is that Java and Javascript are suited for two totally different platforms. A proper implementation of either won't compete with the other, mainly because they won't ever run on the same platform unless some horrible mistake was made.

Running Javascript on the server is pointless, as is running Java applets on the client.

(there may be one or two obscure uses for running Java on the client - but 99% of the time this decision is a bad one).

Re:Viewing at level 5

[Anonymous Coward]

(there may be one or two obscure uses for running Java on the client - but 99% of the time this decision is a bad one).

Shit, I'd better look for a new job then.

Re:Java is bad for our industry

[bmj]

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.

Tufte

[Tripp Lilley]

I beg to differ, and I'm not the only one:

Assessments of change, dynamics, and cause and effect are at the heart of thinking and explanation. To understand is to know what cause provokes what effect, by what means, at what rate. How then is such knowledge to be represented?

This book describes design strategies--the proper arrangement in space and time of images, words, and numbers--for presenting information about motion, process, mechanism, cause and effect. These strategies are found again and again in portrayals of explanations, quite independent of the particular substantive ocntent of display.

And we also enter the cognitive paradiese of explanation, a sparkling and exuberant world, intensely relevant to the design of information. Those who discover an explanation are often those who construct its representation. [...] All these quick-qitted creators and discoverers demonstrate methods by which to represent, describe, illustrate, and, indeed, construct knowledge.

Many of our examples suggest that clarity and excellence in thinking is very much like clarity and excellence in the display of data. When the principles of design replicate principles of thought, the act of arranging information becomes an act of insight.

[...]

The idea is to make designs that enhance the richness, complexity, resolution, dimensionality, and clarity of the content. By extending the visual capacities of paper, video, and computer screen, we are able to extend the depth of our own knowledge and experience. [...]

-- Edward R. Tufte, Visual Explanations (Introduction)

Learning Java

[StarCat76]

I read O'Reilly's Learning Java (1st Edition) and really liked the way the book is written. Its no-bs way of shwoing the concepts is useful for beginners who want to learn the structure of the language, and for experts, who use it as a reference for the advanced concepts. All in all, I'd recommend it thoroughly. -Neil

Re:Learning Java

[Rick BigNail]

I second your choice. One of the author is the creator of beanshell. He knows Java very well.

it's inevitably necessary to have simpler books

[192939495969798999]

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.

Re:it's inevitably necessary to have simpler books

[Anonymous Coward]

Kid 1: Whos that guy in the bushes staring at us?

Kid 2: I think hes touching his weiner

Kid 1: Yeah grosss

Kid 2: He's waving a candy bar at you

Kid 1: Naw he's waving it at you

Kid 2: Lets go find mommy or a policeman

Re:I'd like to take this oppertunity..

[sahala]

Actually the only thing I've seen that's prettier for web applications is... here we go: c# :)

I actually don't doubt it. Unfortunately hardly anyone else on /. knows this because "php and mysql is all you need".

Re:I'd like to take this oppertunity..

[baldass_newbie]

Actually the only thing I've seen that's prettier for web applications is... here we go: c# :)

I see you're wearing your flame-proof suit.
That's nice.

Re:I'd like to take this oppertunity..

[malocchio]

hah, i haven't read a reply that funny in months.

It's slashdot's fault for my trolling, there were no good articles to argue about, so trolling was my last resort for entertainment at work. I do suppose I could actually work, too....

Re:I'd like to take this oppertunity..

[mydigitalself]

well considering you opted for the coward route, how is anyone going to take you up on that one!

plus, i entirely disagree with you, i have php applications that pull data from mysql faster than an equivalent java application.

the JAVA advantages, for me, are:
- OO through and through
- scalability in the form of J2EE
- well writen java is a pleasure to read and understand
- cross-platform
- fantastic package library and 3rd party packages
- sun screwed up and gave it away!

Re:I'd like to take this oppertunity..

[Anonymous Coward]

The answer is: "It won't compile unless you define a class called ing"

Strongly committed to OO

[kahei]

...a language so strongly committed to OO as Java...

Mmmmmm.

Something to ponder

[Anonymous Coward]

Is there a glut of Java programmers or are you a slut of a Java programmer? There's not much difference. Pet Store make boom boom go. I are a compuder programer.

Re:Java is good but slow

[The Mayor]

I think you're confusing latency with speed. They are very different.

In tight loops, I've found Java to be just fine, speedwise. Bounds checking on array access can cause slowdowns, but with HotSpot this usually doesn't affect things too badly.

Latency, on the other hand, is awful with Java. Java makes zero problems with thread latency, and this is the most probable cause for your issues. For best results, use a native language on a real-time OS. The new O(1) schedulers available to Linux can work pretty well. But something like QNX is best.

Re:I'd like to take this oppertunity..

[halofan_sd]

trick question huh? it has syntax error of course.

Re:I'd like to take this oppertunity..

[kahei]

Well, it wouldn't be very difficult to win, but I do have a few doubts as to whether you've really got the money :)

Re:I'd like to take this oppertunity..

[malocchio]

one word: heh.

well, maybe 2: idiot.

Re:I'd like to take this oppertunity..

[sahala]

I do suppose I could actually work, too....

Shut the hell up! You don't see anyone else "working" do you? Stop being so damn selfish and get back to posting.

Re:I'd like to take this oppertunity..

[955301]

I'd like to take this opportunity to point you to IBM's SWT if you still think Java is slow as a client side app.

Just because Swing got into a politically driven quagmire, doesn't mean the language or runtime itself is hosed.

It's just a matter of your choice of libraries.

Re:I'd like to take this oppertunity..

[eggsurplus]

Think about it for a second. He said no one could write a program in under 100 lines that could run as fast as his. He is the one deciding the task and he'll pick on that Java is meant for that no other language handles nicely. Meaning you'll be the one losing money. Now if it was any task in general then you have a case.

Java tutorial anyone?

[cpn2000]

When I first learnt Java (6 years ago ... JDK 1.0.2), I went with the Java tutorial. Considering that there were not too many books written on the subject at the time that was not a hard choice to make.

My verdict is that the tutorial is not a bad way to learn Java programming at all. The trick is to read every line (dont skip anything), and try every example in there, and in addition try your own variations. Worked for me, but needless to add ... your mileage may vary

Re:Java tutorial anyone?

[Dan-DAFC]

And here's the link. Also Roedy Green maintains a pretty extensive Java Glossary.

Re:I'd like to take this oppertunity..

[malocchio]

fine then, but when I'm fired i will show my boss this thread, which by Slashdot's merritable reputation for increasing productivity, will excuse my slacking off.

Perhaps i will respond to that challenge with the undefined class.. :)

Them Java Coders

[inertia187]

About them Java Coders,
codin' here and there.
Just like Gosling's Keynote said,
Java's Everywhere!
Them platform neutral Java Coders,
runnin' hotspot mode.
Keep them classes nice and neat,
'til it turns bytecode.
Multi-threaded Runnables,
and Serialization,
keeps those members all in line,
avoiding race condition.
How to be a Java Coder,
here's thee easy way:
Go to sun.com's web site
and get the SDK.

Re:Them Java Coders

[Anonymous Coward]

coding, that is

Re:Java is bad for our industry

[forgetmenot]

Java is just an OO-Language so I don't see how you can say it is "bad" for the industry. And personally, I get tired of seeing the same negative criticism being leveled time and time again as if the thing has never progressed in the last 5 years. I work with Java everyday and have watched it improved dramatically with each new release. But I'm meandering..back to the original point. Java is just a language. Your effectiveness with Java is only as good as your understaning of the OO principles that it is built upon, and THAT is where I see problems. It sounds like what you're really biting at is that you've seen a lot of people, rushed into the market, who *surprise surprise* can't code their way out if a paper bag. How is that Java's fault? Are you suggesting they would have been better programmers had they been rushed through C++ instead? Dot com boom/bust had nothing to do with Java. If you want to blame anyone, blame the VCs. They're the ones who spoon fed money into dumb projects creating the market for overpaid poorly trained programmers in the first place. The fact many of them may have learned Java is beside the point.

As far as good or bad for the industry... well.. you don't really define what your industry is. Software house for the most part don't use Java. I personally feel it's an "IT" language, and the IT shops/people that I've been involved with LOVE Java for its productivity and cross-platform compatibility.

Re:Stay away from it.....

[botzi]

This is far, far, too far away from being the best book on Java.

I'll even argue that this is not a good book at all. As always Mr. Eckel is going on and on with a 2-3 pages of reflections and a small piece of programming practices(everyone who've tried to read the C++ thinking, know for what I'me talking about), so my point is :

1) The book will be confusing for a beginner programmer.

2) It'll be useless for the most part to a person with some general programming culture.

Anyway, the best book to start with java is "On to Java", I don't even remember the authors but it's everything: Short, explicit and well structured. A problem may be that it should be a bit outdated.......

Of course, all one really need to start programming in Java is here

Re:Java is bad for our industry

[hoggoth]

> 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

If you can solve any problem in a day with Java that would take a couple of days in Perl or VB I want to know what parallel dimension you are living in.

Perhaps you could argue that Java could solve a two year problem that would take three years in Perl or VB. But one day problems are pretty much ALWAYS faster in Perl or VB. Of course, generalizations are always wrong.

I have found Java to be incredibly time consuming to write compared to Perl. Yeah the Java may be 'better architected' or 'more maintainable', but if speed to completion is my priority it's going to be Perl not Java.

Bates and Sierra also have a good cert book

[jtotheh]

The authors of Head First (which I've never looked at) also have an excellent book for preparing for the 1.4 Programmer (and Developer but I can't speak to that part) Exam. It just helped me pass the test.

Get head?

[The_Shadows]

If you don't know Java, get head.

Ladies, for the geek in your life, give them head.

Too... many... bad puns!

Re:I'd like to take this oppertunity..

[sahala]

damn right you're responding to that question. Priorities!!!

Re:I'd like to take this oppertunity..

[jeffy124]

then I take it you dont understand a damn thing about Java, otherwise you would actually answer. then again, you probably wouldn't have made the post that started this whole thread if you knew Java. my guess is your so called "certification" came from a coffee shop frequent visiter card.

Learning the language is one thing...

[fmedio]

... but achieving clean, efficient object-oriented design is another one.

Transforming the buzzwords of "encapsulation", "reusability", "modularity" into workable and efficient solutions requires way more work than strictly learning the language.

Also, a common pitfall is to believe that you can do whatever because some garbage collector is taking care of memory management.

Before even reading whatever about java, I'd strongly recommend :

- of course, Design Patterns, by Erich Gamma et al;

- Principles of Object-Oriented Software Design, by Anton Eliëns (online version here).

Re:Learning the language is one thing...

[Anonymous Coward]

Recommending the GoF book as an alternative to a Head-First is laughable. GoF is a great book, but it's not readable. Head-First books are going to be books for beginners, and they're going to be blown away by GoF. Not a good thing.

server-side wora

[Anonymous Coward]

I'd rather go for a server-side platform with less uncertain licensing/legal issues, thanks.

like python

Re:server-side wora

[Anonymous Coward]

Uncertain in what way?

Re:I'd like to take this oppertunity..

[The Mayor]

On the J2EE side, they also make extensive use of object pooling (for servlets, DB connections, etc etc). This makes Java on the server-side much faster than naive implementations written in native languages (for the record, ASP is a naive implementation, whereas ASP.NET is not....ASP.NET is able to handle similar loads to JSP/Servlet solutions, whereas ASP is about 5x-10x slower).

Throw in dynamic runtime optimizations offered by HotSpot-type JITs and you end up with a server-side solution that bests most other solutions in terms of speed. Server-side Java is quite nice.

Take a look at the Resin web server/servlet engine, if you're interested in seeing how good server-side Java can be. This thing can serve static content faster than Apache!

JavaScript

[bigredswitch]

"I'd spent some time using JavaScript without really getting my hands too dirty but I'd pushed it way to far and realized I needed a bigger hammer"JavaScript is a great deal more capable than most people think...

<shameless_plug>Just take a look at my Manic Miner conversion, a 20 level game entirely in JavaScript - it works in most browsers.</shameless_plug> Then take a look over at JavaScript Games.

MOD DOWN AS REDUDANT

[Anonymous Coward]

look at the time stamps moderators.

Well, to be pedantic about it...

[PHAEDRU5]

!"JavaScript".equals("Java")

Re:Java is bad for our industry

[bc8o8]

There's a huge glut of programmers on the market with little or no experience using any other programming language other than Java.

I for one know that MANY major universities are now requiring ONLY Java programming courses in order to gain a Computer Science degree.

As a CS student at a university that does NOT follow this practice (in fact we only have one Java class, and that's really enough) I think this is a terrible way of training future developers. How can a graduate who has NEVER had any experience in any sort of low (or even middle) level language possibly hope to develop anything other than a pretty GUI with some network support.

Don't get me wrong, Java does have it's place. It's great for developing GUI applications, or applications where speed and efficiency is not an issue. But a primary language to teach computer science fundamentals, it is not.

Re:Java is bad for our industry

[Troll_Kamikaze]

So what if that's the only language you know? If you're a good Java programmer, what's the problem?

The problem is that if you learn only one language (or one operating system, or one religion, ...), you are blind to its flaws.

You warp your behavior to fit the tool, rather than choosing the most appropriate from a diverse set of tools.

Just look at the huge majority of web surfers that use Internet Explorer. Instead of exploring alternative web browsers and settling on one that prevents pop-ups from arising, they become whack-a-mole experts. This is directly analagous to programmers who only know one language, or only languages from a single family.

Re:Java is bad for our industry

[sahala]

So what if that's the only language you know? If you're a good Java programmer, what's the problem?

I agree. I've actually noticed a trend between age/experience and the way people write resumes. Developers with less experience tend to put every single language/technology they know on their resume, and when asked, claim expert proficiency even if they have no significant project experience. More mature developers tend to only put a handful of languages that are relevant to the job they seek, even if they know dozens more. Furthermore, they show deep experience with each technology.

Tech recruiter friends of mine also mention how much they HATE it when people put down every single technology in their resume. It's also frustrating when a resume is longer than a page and is way too detailed. Apparently such resumes end up being tossed in a "read later if I have endless amounts of time" pile, which inevitably means it'll get tossed in the trash.

Re:I'd like to take this oppertunity..

[Camel Pilot]

Uh sure let start with a standard spelling checker :) mr. oppertunity

1 million dollars eh? That is a pretty large sum for an AC - is this monopoly money or what?

O.K. since the application is of my choice here is my entry

#!/bin/tcsh
echo "hello world"

Re:Java ain't really OO

[Nick of NSTime]

Java is really just a cleaned-up version of C++...

Someone who knows best may disagree with you on that statement.

Re:Java ain't really OO

[Anonymous Coward]

I would say Java like Objective-C is an Object "based" language.

At the risk of sounding offtopic..

[Cassanova]

I think of this many times and I laugh...

I moved into Silicon Valley in 2001, the time when the dot-coms were beginning to go bust...

I started working on Java in my own spare time to get to know the language better (I had worked on C++ for several years in the past and used to suffer the same "hmph, Java? So what's new in there that isnt in C++? bah, I dont need to learn another OO language.." syndrome) - again this was in 2001 - the year the dot coms were beginning to go bust...

I landed a job in Silicon Valley during the time most programmers were making their exit out of Silicon Valley, in 2001, during the time the dot-coms were beginning to go bust...

And surprisingly enough (not?) the job I got involved programming in Java for a good two years, and still continuing, and the funny part is (drum roll....) the company Im working for has nothing to do with dot com...

Java only = Dot com? nah, I dont think so.

Re:At the risk of sounding offtopic..

[bmj]

Exactly. The biggest Java employer in my region isn't doing primarily web work (though it is a facet ). I think the introduction of the SWT will only make this sort thing continue, as people realize they _can_ make desktop apps with Java that aren't slow and look like crap.

Re:Java is bad for our industry

[Anonymous Coward]

As much as Java professes to create the "best of breed" systems, it attracts the "worst of breed" programmers. Most programmers today have only used Java in their careers and have no basis of comparison to make an educated statement about technology. As result, they flog Java as THE SOLUTION to all of businesses' problems even when the result is a hodge-podge system of Java acronyms used for their own sake. Sure, whatever, banks and websites love Java because it keeps their costs dirt cheap since all their programmers are now commodities. Roof repairmen now make more money than the average Java programmer.

OO techniques are seldom fully understood

[boster]

The majority of developers do NOT fully understand OO principles. There is a difference between learning the syntax and the basic features and understanding how to leverage them. Most OO developers can write and use simple classes, use inheritance and basic polymorphism. This is generally all that is taught in courses and language books. This is also sufficient to get most things done. :) However, most people this level of knowledge do not understand just how much more can be done. A good example of more powerful OO programming is in the Gang of Four book. The conceptual leap from procedural to basic OO programming is but the first step. I guess what I'm getting at is that once you're at this point where you're using basic OO techniques, then there's still a lot more you can learn (even if you know each and every language feature and its syntax). Just be aware of that and look into it someday.

Re: OO techniques are seldom fully understood

[gidds]

Very true. OO isn't just a way of programming, it's a way of thinking about problem-solving and about complex systems. Java's good for it not just because it has a good implementation of OO principles, but also because the (huge) standard library is generally well thought out, and some parts are a masterclass in good OO design. Using it introduces you to some powerful OO techniques, and encourages you to use them yourself.

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?"

Re:Java is bad for our industry

[el-spectre]

I don't think this applies to Perl very much. In my experience, folks either love it or hate it, due to its quirkiness. Those who love it continue to use it and advance their skills beyond cut 'n paste.

Thanks ORA: a primer series w/o an insulting title

[Dammital]

I'll gladly spend money on a "Head First..." or "... for Novices" series. But it'll be a cold day in Hell before I buy anything designated for Dummies or Idiots.

Kudos to O'Reilly for titling their primers with some dignity.

Re:I'd like to take this oppertunity..

[kahei]

You didn't read it properly. But even if he gets to pick the task, I can think of a very easy proof that the challenger can (theoretically) always win...

Sadly, I still don't think money will change hands here :)

Alternative to books

[Anonymous Coward]

Check out some university CS websites for the basics of a new language. You should usually be able to find some free lecture notes written for a course dealing with your language of interest. As they are written for students, they're "dumbed down" enough to make learning the language simple, but at the same time often contain conceptual backgrounds as well. In a series of Java notes, like these at Stanford, for example, you will find all sorts of information not only about Java itself, but also object-oriented programming in general. Another advantage is that it's easier to find information about less-commonly-used languages. For example, the University of Illinois produces a wonderful resource book for x86 assembly (NASM).

Once you understand the basics behind the language, then go ahead and buy a book for the kinds of applications you need.

Re:I'd like to take this oppertunity..

[TheLastUser]

You can do a static compile of java into machine dependant bytecode using gcj if you are into that.

I do a lot of server side Java and I have never had a speed issue. Its much more likely to be a database issue that slows up the app than the execution of actual byte code. Remember that web/app servers ALWAYS top out on io before cpu anyway, so the fact that the Java server is running at, say, 40% cpu instead of 20% doesn't mean a heck of a lot.

Yeah, great review not...

[Dj]

HFJ is a great idea, but this edition is laden with errors in examples which are a minefield for a person who's trying to learn the language.

I tested this book by handing it to my other half; she figured out at least 3 serious errors and put in errata for them; you'll find the errata at O'Reilly.

It'll be a much better book, and recommedable for beginners in the second printing/edition when these are fixed.

Re:Java ain't really OO

[Abcd1234]

I prefer the phrase object-supporting language. An object-based language, in my mind, would be somthing like Self or Smalltalk... the very basic building block of the language is the object (heck, in the two aforementioned languages, many of the language constructs are implemented using objects), as opposed to languages which have built-in support for objects but are really fundamentally procedural.

For your next book...

[RevMike]

I highly recommend Design Patterns Java Workbook by John Metsker as your second Java/OO book. It also takes an "interactive" approach to learning, developing a number of key GoF patterns in Java.This book is a practical way to learn not just Java syntax, but real design skills in Java.

After that read Java Development With Ant by Hatcher and Loughran for good info about how to set up real java development environments. Ant is a tool that fits a similar ecological niche as make, but has tons of extra features particularly useful to Java developers.

Oh, and don't bother with an ide. Real men use vim.

Re:For your next book...

[Thuktun]

Oh, and don't bother with an ide. Real men use vim.

I used to think like that. Auto-completion, real-time error highlighting, and automated source refactoring save me time and let me get more done. (Eclipse has all of these and is a wonderful IDE.)

HEY!! Possible licensing violation

[MemeRot]

The licensing for Java CLEARLY states that it cannot be used to control nuclear reactors, pacemakers, suborbital rockets, and particle physics experiments.

2 of these are real licensing requirements by the way.

Re:I'd like to take this oppertunity..

[mark_lybarger]

java is slow because of the layers and layers of standard classes out there for java. of course that increases development time and also increases reliability.

Boing!

[Anonymous Coward]

You've been trolled!

Re:Java ain't really OO

[Merk]

Knows best, maybe. Is objective about the differences? Definitely not. While Java isn't what the creator of C++ might have done to clean up C++ it's pretty clear that the people who designed Java based it on C++. Sadly, that FAQ entry sounds like a grumpy old man who's tired of hearing about the newfangled thing all the kids are talking about.

Languages versus Programming

[FreshFunk510]

"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.

Re:I'd like to take this oppertunity..

[pheared]

Right. The slowness that most people are concerned with is the client side since that's where the JVM is most visible. Client-side apps take a measurable amount of time to startup and do not normally persist making that startup time rather wasteful. It's a poor use of the technology.

To add to the pain, Mozilla does inteligent things like keeping the monster running. On one hand, sure that speeds up startup time of the next app, but it eats a way at your computer's memory. I prefer Konquerer's approach, where it will kill the JVM if no Java applets have been loaded recently.

Why does this "review" read like an ad?

[Anonymous Coward]

So nice and formatted, with little "bad" things about the book that end up being good things.

WARNING: THIS IS A PAID ADVERTISEMENT MASQUERADING AS A REVIEW!!!!

Re:Java is bad for our industry

[Abcd1234]

But a primary language to teach computer science fundamentals, it is not.

Hah, this is hilarious. I think what you meant to say was "a primary language to teach software engineering fundamentals, it is not.". Java is a perfectly valid language to teach computing *science*... ie, the science of information processing, algorithms, computability, etc, etc. In fact, any language would suffice for this... as long as it's Turing complete, anyway. Although, admittedly, some languages are better than others.

In fact, even in the realm of software engineering, Java is a perfectly useful tool for teaching these concepts. The problem is that you assume University exists to teach people all the practical skills necessary to succeed in the IT industry. However, I believe many Universities look at their courses as a means to teach students the fundamental concepts of software design, from which a student should be able to migrate to any other language with ease... after all, design patterns learned in Java should translate just as well to, say, C++, assuming you understand the concepts underpinning them.

In fact, IMHO, your assertion that "a graduate who has NEVER had any experience in any sort of low (or even middle) level language [cannot] possibly hope to develop anything other than a pretty GUI with some network support" is overly simplistic. After all, if all you can get out of a University course is how to code a pretty GUI, you've missed a LOT. University is there to teach high level concepts... concepts which, in the end, are language agnostic. If you miss out on those concepts, it's your own damn fault, and you should have probably gone to a technical college.

Writing Learning Java...

[patniemeyer]

Hi, I'm Pat Niemeyer, the author of Learning Java. As I sat down this morning to begin work on the fifth edition of the book for Java 1.5 I was
pleasantly surprised to see this item on Slashdot (my first stop of the day). So I thought I'd chime in with a little bit about what it's been like working on this book over the years and ask for you help in making it better.

The short story is that trying to authoritatively cover a topic as broad as the Java language and libraries and to do so without simply producing a giant shelf-filling reference tome or dry as toast text book is a very difficult challenge. I think there are parts of the book that have met this challenge and parts that can be better in the future.

Now, I consider myself to be a relatively funny and creative person (also sexy, and other adjectives as well) and I think if someone had asked me back in 1995 what my first book would have been like I might have imagined something a bit lighter and breezier than an 800 page book about a programming language. But I think that the Slashdot audience in particular will appreciate that despite its size and some obligatory coverage, this is a book written by someone who has a passion for software and architecture and that I have tried to pour my creativity and time into crafting elegant, insightful, and *minimalist* examples. I wrote this book for people who think and learn the way that I do and that may not appeal to everyone.

I think the strongest parts of the book are in the most exciting and difficult areas of Java - topics such as advanced networking, multi-threaded
programming, and XML. IMHO Learning Java's coverage of these topics is deeper than some single topic books in their entirety.

The Java language is a moving target and one that gets more moving parts every day. The greatest challenge in writing about it now is not what to cover, but what to leave out. I have spent many many hours on the phone with my editor (Mike Loukides) over the years debating about what we need to include and what we need to cut. In recent editions which have included a CD in the jacket (yah, I know... book CDs are normally useless) I have started moving the old, less relevant material (such as some of the original AWT API stuff) to the CD.

I have also experimented with the introductory tutorial chapter - trying to give a broad overview of the whole language in one chapter before diving into details. Some people may see that and be turned off. I hope they'll dig a little deeper.

I am very interested in what Slashdot readers have to say about how to make the book better. Your comments would be very well timed right now as I am updating the book for Java 1.5 as we speak.

I hope you'll check out my book if you need to learn (or learn more about) Java. If you have already mastered Java then I hope you'll buy a copy of my book and give it to a homeless person ;);)

Thanks,
Pat Niemeyer
Author of Learning Java, O'Reilly & Associates and the BeanShell Java scripting language (www.beanshell.org).

Re:Writing Learning Java...

[CrackHappy]

Pat,

Personally, I am grateful to authors such as yourself who take the time and effort to put thought and creativity into your book projects. I have not read Learning Java, but when the time comes, it will certainly be on my list of "Must Haves".

Keep it up!

Re:Writing Learning Java...

[pileated]

I tried to read the old version of Learning Java, called Exploring Java, and then the 2000 version of Learning Java. Both times I just got bogged down and quit.

I can understand the dilemma that you mention in covering such a huge topic as Java. I've read many, many O'Reilly books and many of them manage to do a wonderful job of clearly exlaining very complex subjects. Though they can require concentration it often pays off. But I didn't find that it helped me with these books, even though I read rave reviews of them elsewhere. My final conclusion on them was that they really were a bit too advanced for me, even though they were supposed to be introductions.

The books that got me to understand Java and eventually get SCJP certification were Bruce Eckel's Thinking in Java (I believe I read both first and second editions), and probably most importantly: A Programmer's Guide to Java Certification by Mughal and Rasmussen. Though neither of these are all that simple they seem to begin from a theoretical viewpoint that I found myself comfortable with.

I suppose this all goes to prove that, just as the authors of Head First Java state, people learn in different ways. For me I've found that a theoretical bent is always what I like best. Others will find Learning Java perfect for them and others will find the same with Head First Java.

Like movie reviews I guess you just have to learn whose opinion you've learned to trust over time then follow their recommendations.

Re:Writing Learning Java...

[javajonathan]

Hi Pat,

You are sexy. And other adjectives.

Good luck with Java 1.5.1.

Regards,
Jonathan

btw...

[Antilles]

javascript also supports OOP and stuff of that nature, just most people never know about it. It's quite a robust little language.

Re:Java is bad for our industry

[Dan-DAFC]

But a primary language to teach computer science fundamentals, it is not.

Correct, in as far as you can't really learn computer science fundamentals by focusing on only one language. A CS degree should introduce you to various programming disciplines, of which OO is just one. For example, on my BSc course, I learned OOP, functional programming, assembly, Prolog and Occam.

Clearly Java is useless for teaching low-level coding or functional programming, but as a language for teaching OOP, Java is a good choice. Certainly better than C++ in that it was designed as an OO language from the beginning and lacks many of the gotchas that trip up the beginner in C++. The Smalltalk crowd may argue that their language would be even more suitable, and they may be right, though perhaps you can forgive the educational institutions for allowing some degree of pragmatism in their choice (Java will be of more immediate use to a graduate than Smalltalk, though - as you alluded to - an understanding of the underlying concepts, independent of the particular language, is the most important thing).

Re:I'd like to take this oppertunity..

[Anonymous Coward]

You might want to investigate the other implementations of the JRE out there. . . . There is also Blackdown.

The Blackdown JRE is a just a port of Sun's JRE. That is, they don't contribute (much) new code; they just build it on a different platform. It was (and is) helpful in getting Java on Linux, but it is not intended to be a new and different implementation.

Got a great title suggestion...

[Black Jack Hyde]

Java: Write Once, Debug Anywhere

Re:Got a great title suggestion...

[Dan-DAFC]

I liked The Register's take on it:

"Java: Write once, wrong somewhere else."

Grammer Lesson

[Bill, Shooter of Bul]

Dude, he was making a comparision. Like when you compare something to something else. As in "I've never seen a mountain as big as pike's peak" does not mean that pike's peak is the highest mountain. It just means that of all of the mountains he has seen, pikes peak is the tallest. He is correct because he hasn't used Objective c, eiffel, or smalltalk.
And they all said ...
You insensitive Clod.

I love this book

[gnurb]

I recently bought this book, and I've made my way through about chapter 4. I've laughed out loud at the goofiness several times, and have learned a great deal.

It's really an enjoyable read, and after I complete this I can't wait to try some of the other books coming out in the head first series.

The next one is head first ejb, in august, according to headfirstjava.com

Another thing is that all the examples featured OS X as the operating language, but it's completely independent. I was considering buying the other O'Reilly book Java and Mac OS X, but I'm really glad I got this one instead.

Check out some of the amazon customer reviews for a generally glowing recommendation.

want to give head? learn java first!

[Anonymous Coward]

want to give head? learn java first!

give head the slow way. cuz givin head in java.speed=utterlyslow is the best way

Not features of OO

[MemeRot]

"encapsulation", "reusability", "modularity" all features of good coding, whether the coding is procedural or object-oriented.

Probably even more important for good coding is EXTENSIVE comments and self-documenting variable names. If I never see the variables 'x', 'y', 'i', etc. again in my life I'd be a happy man. For god's sake tell me what you're counting and why.

Time and again I've seen how writing easy to maintain code is SO much more important than writing 'optimized' code. You can't pre-optimize for speed to any great extent, you first need numbers showing where the bottlenecks are. You CAN pre-optimize for modularity/extensibility which is much more important IMHO.

Re:Not features of OO

[fmedio]

Totally agreed. Code is meant to be read by humans in the first place, not by compilers.

Re:Java is bad for our industry

[Zorkerman]

Java is good....
very good...
when you hear java think happy thoughts....
Everyone should use java for everything....
now sing with me "We love java, yes we do..."
Java its not just programming its life.

Online docs

[Hard_Code]

Don't forget that Sun has a excellent set of Java tutorials online for free:

Tutorials & Short Courses

These are essentially the contents of the Sun press line of books.

Re:Java is bad for our industry

[Anonymous Coward]

Funny that you didn't mention the name of the university. You know it's all about Java.. just love it ;)

Actually gcc C++ and wxWindows together seem like a good combination. You still get the OO benefits (decent string handling for example), with portability and a speed bonus. Only problem might be with licensing issues.

Neither as good as Thinking in Java

[ry4an]

Neither of the books mentioned are as good a learning book as Thinking in Java by Bruce Eckle. Which has the benifit of being free as in beer: http://www.mindview.net/Books/TIJ/.

Re:Neither as good as Thinking in Java

[pcause]

I'm also a fan of Thining in Java. The author, Bruce Eckel, also is working on a J2EE book and has a book on Design Patterns. Eckel also wrote Thinking in C++, which has to be the best book for someone trying to transition from C to C++.

By the way, if you are just trying to learn Java, I'd recommend that you grab a copy of DrJava to use as an IDE to try various examples from whichever book you pick. This IDE was built for teaching by some folks at Rice. It includes an editor, syntax coloring/highlighting, compilation, and built in debugger. It also has a interactive shel that lets you try things in Java without having to create a program.

Re:Neither as good as Thinking in Java

[mindmaster064]

Depends on your perspective.. I find the "Thinking" books an annoying read mostly because a lot of what is common sense kind of stuff is methodically plodded through and explained (when it doesn't need to be). If you weren't a programmer at all (not even BASIC) then maybe you would enjoy this book because it would all be fresh. For me, it was mind-numbing and very hard to get throught the first half of it (in an attempt to give it a fair try).

If you've ever done any kind of programming don't even bother with this, it will insult your intelligence and patience. If you're the type that learns by form and function this one is rather a bore.

-Mind

A lot of people seem to be adamant against Java

[jkauzlar]

I've noticed on Slashdot particularly that many programmers, even the ./ editors, seem a little, if not a lot, biased against Java. As someone who has been productive and happy with the language this doesn't make sense to me unless it has something to do with the corporate stigma surrounding the language. And I know its not great for desktop apps either... but come on-- cross-platform, vendor-neutral, tons of open-source support, development tools through the nose, all the apis you could ask for.

Alright, so I'm not trying to, uh, bait flame, but provided that Java works best for client-server applications, or just server-side apps, what are the major problems with Java as a platform? Or is it that Sun is not being open enough with the specifications?

Re:A lot of people seem to be adamant against Java

[MemeRot]

A lot of people don't like sun's licensing.

I don't like OOP.

Example of why:

//---- Fat Wire Approach ----
module taxPerson_A( aperson: personClass)
declare taxable: decimal
taxable = aperson.income
if aperson.filing = "w2"
taxable = taxable * 0.8
else
taxable = taxable * 0.9
end if
taxable = taxable - (2000 * aperson.dependants)
aperson.tax = taxable
end module

//------- Thin Wire Approach --------
module taxPerson_B(income: decimal, _
filing: string, _
dependants: int) // income: gross income // filing: filing status, "w2" or "1099" // dependants: number of dependants
declare taxable: decimal
taxable = income
if filing = "w2"
taxable = taxable * 0.8
else
taxable = taxable * 0.9
end if
taxable = taxable - (2000 * dependants)
return taxable
end module

In the first approach, we pass an object of type personClass. (The names are only illustrative, and not meant to demonstrate good nomenclature.) The taxPerson_A module presumes that the passed object will have certain interfaces. In this case these interfaces include "income", "filing", and "dependants". (In some OO languages, responding to these protocol names is sufficient. In others, the inheritance tree is checked to make sure the passed object is of the proper pedigree.)
If personClass is changed such that "income" is removed and replaced with "netIncome" (because gross can be calculated rather than explicitly stored), then module taxPerson_A will not work without modification. However, taxPerson_B will continue to work without internal modification. (Perhaps some of the calls to taxPersion_B may need to be altered, but no changes are needed to the module itself.)

taxPerson_B can also be reused in a different application with more ease. If we copied/moved taxPerson_A, we would have to re-create personClass on the new system also. This may not be desirable. For example, the new system may already have it's version of personClass that has different names mapped in different ways. For example, the new system may store/reference the filing type in a completely different class.

Thus, the fat wire approach has coupled two modules together in ways that the skinny wire approach has

... from http://www.geocities.com/SiliconValley/Lab/6888/mi scoop.htm

Re:A lot of people seem to be adamant against Java

[jkauzlar]

A think that's a valid criticism as far as something that can go wrong in OOP, but yours is more an example of bad design. The method would best be either placed inside the person class (since it depends only on values from person) or the thin-wire approach would be used.

I think many OOP developers, maybe even experienced ones, would be tempted to use the fat-wire approach in this example, or they might do it by accident at first, only to change it when they want to use taxPerson in other programs.

This is just a way of thinking that OOP programmers must learn, but I wouldn't consider it to be a detriment to the language, as it forces developers to do more planning. In fact, most Java programs have their complete set of interfaces designed before development even begins.

Re:A lot of people seem to be adamant against Java

[MemeRot]

I develop business applications on a small to medium scale with constant refinement of requirements throughout the process. I cannot imagine how I could define interfaces completely before beginning development. Small to medium custom business apps seems to be one problem area where OOP offers little or no advantage.

One other valid criticism of OOP in my book is that it deals too much with data in the programming language rather than stored in a table. I wouldn't solve the above problem with a procedural function in real life, everything would be in tables - the person's income, the tax rate for that income level, conditions that justify exceptions to the rules, additional formulas to be applied, etc and I'd put my logic into the SQL joins between them. So, I see a common underuse of relational databases abilities in the OOP paradigm - just a thought. You pick the right tools/methodologies for the job.

Re:A lot of people seem to be adamant against Java

[jkauzlar]

I cannot imagine how I could define interfaces completely before beginning development.

This is what thousands of people are using UML for! Then there are tools to translate the UML directly to Java. Of course, this doesn't exactly put an end to the constant refinement (but perhaps slows it down). It does let you beat your head against the wall over a much simpler code structure, rather than piles of implemented code. And without grouping your code and data into objects, I think the planning stages would become exponentially more complex.

You might be right about your 2nd point. Objects don't normally map well to relational db tables and the object-relational mapping solutions are awkward and difficult to use. In fact, since I started using OOP, I've almost stopped using more complex SQL completely.

Java proponents might say that to rely to greatly on SQL may compromise platform independence, but I don't know about that. Perhaps its just that people are scared to learn SQL.

Re:A lot of people seem to be adamant against Java

[MemeRot]

Odd, I have found time and again that having things stored in the database allows applications on multiple platforms in different languages to work together beautifully. Everyone writes drivers for connecting to the major databases, so all apps that can connect to a database can work on a common set of info. It's probably that when you're good with a tool, whether it's the perfect tool or not, it's often a better tool than the 'perfect tool' you don't know, and I've been doing complex SQL for years so it's just how I think about the problems.

Re:A lot of people seem to be adamant against Java

[Decaff]

Yes, but *what* complex SQL are you using? Its all very dependent on the Database. Such dependency is very bad practice. Databases, like hardware platforms, should be able to be freely chosen, and switched, at any point, otherwise all your projects go belly-up because the management decide they don't want to renew your Oracle licences.

Use something modern and sensible - write your business model and data structures in Java + JDO, and you will not care about whether the underlying store is a database, a filesystem or a phone SIM.

Writing everything in SQL was out of date and unsupportable a decade ago.

Re:A lot of people seem to be adamant against Java

[The Mayor]

Well, if you would keep your data members protected or private, as most experts recommend, you'd never expose the data member "income". Then, you'd have a method getGrossIncome(), which with an object that stores net income would calculate gross income on the fly and return it.

This approach towards programming is called "design by interface". You want gross income? Don't make it a data member. Make it a method. Hide the data members. Then, if you want a flyweight class that stores only the most basic data, you can calculate all of the complex data with methods. If you want a heavyweight class that is faster than the flyweight class, then store all of the complex data as data members.

Exposing implementation details is a big No-no in OO programming. You can do it. But then you are implementing procedural programming in an OO language. In those cases, you're probably better off using a scripting language. But, then again, you can design poorly in any language.

Re:A lot of people seem to be adamant against Java

[MemeRot]

very good point.

i wouldn't do the above in a procedural language anyway, i'd normally put all the data in rdbms tables and access it with stored procs - sort of the same thing I guess, even if the table structure changes the proc can still have the same inputs and outputs so the interface remains the same. storing the data in a database just seems most natural for the sorts of problems i work on.

Re:A lot of people seem to be adamant against Java

[Anonymous Coward]

It's the advocacy and marketing crap that is probably the main issue.

Saying that known issues and faults do not exist, and the tons of rationalization and denial that goes on to defend them:
the main one being the speed issue.

Bashing other languages:
primarily c++ even though they are two totally different languages with a totally different focus.
(c++ has a primary focus on creating useful libraries/components/frameworks for others to use, while java has a primary focus on using useful libraries/components/frameworks -- one wouldn't in their right mind create them in java)

lies:
telling c users that java is just like c.
or that java is more like c than c++

Other lies:
saying that java is a standard, which it is not.
saying that java is truly open, which it is not.

Without the opinionated marketing bullshit and advocacy crap, java would probably have had better reception.

Not to mention, valid issues would probably have been addressed much earlier than they have been.

If one lesson could be learned from the java fiasco, it is that advocacy and marketing do more harm than good, and if your language can't back up the lies told by marketing and advocacy morons, your language is headed for the trash can.

The stupid thing, though, is that there was no reason to lie in the first place. java is a fine language without all the bullshit lies. It would have been much better had sun focused on java's strengths, let us know about its weaknesses, and worked on improving those weaknesses.

Re:I'd like to take this oppertunity..

[Dan-DAFC]

It's not just a straight port (there is also a Sun-branded Linux JVM) but includes various patches that improve performance over Sun's offering. I can't find the figures at the moment, but in my testing (with JBoss) Blackdown was approx. 15-20% faster than Sun on Linux.

Sun's performance traditionally improves with every release, the recent 1.4.2 made noticeable advances in start-up times (which along with memory footprint is one of the two most significant remaining performance problems in client-side Java).

There also Linux JVMs available from GNU and BEA.

Strongly committed to OO? Java?

[stesch]

You must be joking. Please take a look at Smalltalk or Ruby before talking about OO.

Re:Java is bad for our industry

[bmj]

I agree, and I guess my reference is a bit dated. I've had to maintain and port legacy Perl cgi code that was obviously done by folks who learned Perl via WWW script archives.

Re:Java ain't really OO

[Ivan the Terrible]

Last year I taught a language-agnostic Introduction to Object-Oriented Programming course at Cal State Hayward using Timothy Budd's book of the same name. He uses C++, C#, Java, Smalltalk, Apple's Object Pascal, Delphi Pascal, Ruby, and Objective-C for examples, with many examples presented in several languages.

One of the strong impressions that has remained with me is just how many of the language decisions the developers of Java got right, and conversely, how many were gotten wrong by the designers of C++.

-- Vladimir

P.S. I took the time to look up the first posting in this thread which has been modded down -2 as a troll.

It really ticks me off to see a reasonable posting modded down as a troll for God knows what reason. So much so that whenever I tell someone about Slashdot, I also mention that the moderators frequently have their heads up their asses, impose their personal views on everyone by modding down postings with which they disagree, and generally treat readers as children. Thank you, but we can think for ourselves. (Sorry about the language, but, in fact, I'm restraining myself.)

Scripting + component/subs beats OO

[MemeRot]

http://www.softpanorama.org/People/scripting_guant s.shtml

There are many well-reasoned articles defending scripting as superior to OO, this is just one I could find in a few seconds on google.

The author has a link to many more:
http://www.softpanorama.org/SE/anti_oo.shtml
And of course this has been discussed on slashdot before too:
http://slashdot.org/articles/01/01/09/1420258.shtm l

Clear, readable structure and flow is vital to the maintainability of a body of code, and in my opinion is better expressed with procedural script calling powerful compiled code than with the morass OO too often becomes. You don't write the NOVEL in script, you write the table of contents and the general narrative - the individual chapters and footnotes you write in C, use a C++ dll, use a Java object, whatever the most appropriate technology is. Any other procedural/scripting programmers out there that agree? Some quotes for all the OOP CS-propagandized out there:

"In other words, the needs of '"infrastructure components" and of business software modeling are sufficiently different that the best techniques for one may not apply to the other. The longer-term patterns of change are just different for each."

The pre-OO thinking was that a system should be a series of black boxes with clearly defined inputs and outputs ("wires"). These wires carried relatively simple signals between the various black boxes of the system. The complexity was in the black boxes, not in the wires. However, OO thinking tends to complicate the wires. In fact in OO the wires themselves tend to become black boxes. In pre-OO thinking the wires were usually simple data like numbers, strings, and occasionally arrays and tables (or handles/pointers to them). In OO the inputs and outputs are often complex OO classes which often have complex behavior attached to them. Thus, the wires in OO are actually no different from black boxes themselves. But why is a bunch of tightly interconnected boxes bad? Mostly because it is tougher to comprehend each black box in isolation. A given black box will often depend on the behavior of one or more of it's inputs and outputs (parameters) in OO thinking. Although OOP's version of black boxes may still be black to the user of them (programmer), they are essentially gray boxes to *other* boxes, and thus the programmer is forced to consider the *combined* behavior. You may have to even follow a long chain of classes to sufficiently understand the original module or method. It is perhaps possible that you may have to understand an entire OO system just to fully comprehend the behavior (or results) of a single piece of code. OO may give the illusion of simple, independent pieces; but is actually building one or a few very large, complicated black boxes instead.

Re:Scripting + component/subs beats OO

[William Tanksley]

Sounds like you're saying that it's possible to write code that's strongly coupled using OO. That's true. But it's the wrong thing to do, and most importantly it's possible to not do it, and possible to measure how you're doing at avoiding it.

Nothing's wrong with procedural programming, but OO isn't evil either. And I think you're just confused about scripting.

-Billy

Re:Scripting + component/subs beats OO

[MemeRot]

When I mentioned scripting I was mainly thinking of Tcl acting as the glue for C. Procedural programming in a, to me, nice form where you ignore the contents of the black boxes. Also of course works for VBScript calling COM objects, etc.

I had to work on a site with 43 separate com objects controlling the shopping cart, and each object always called at least 3, and up to 8 different other com objects each time it was called. The problem was all the 'glue' logic being embedded in the black boxes, and it still makes me shiver to think of how bad it was. I essentially don't care what's in a black box - if it's an object, a stored procedure, whatever, I just don't like to see application logic embedded at that level.

Re:Scripting + component/subs beats OO

[sbszine]

Sounds like a top level design problem rather than a failing of OO. But I agree with most of what you say -- even when writing something in pure Java the main method (or whatever contains the top level logic) should be as brief and readable as a script.

Re:Java is bad for our industry

[el-spectre]

That's always fun... maintaining code used by someone who didn't know what it did anyway...

(Off topic): we had a guy here who had a DHTML snowflake thing for Xmas. He borrowed the code, and didn't know what it did. When I told him to 'slow that thing down', by changing the delay variable (as in, setTimeout delay), he changed it from 200 (ms) to 20, thinking this would slow it down. I _told_ him not to publish code when he didn't speak the language, but...

Within 30 minutes he had crashed 500 machines on out corp. intranet and the only thing stopping more damage was a brief shutdown of the webserver and remove the offending code.

We're not allowed snowflakes anymore :)

Re:Java is bad for our industry

[Anonymous Coward]

Speaking as someone who somewhat recently graduated from a university that standardized on Java, I think it's possible you've slightly misunderstood what that means.

I majored in CS at the University of Texas (twice actually, once starting in 1989 and once starting in 2000, when I actually finished). During my second period there, they were standardized on Java. What this meant is that, in any situation where a generic high-level language was needed, people (profs and students) were encouraged to use Java. For writing a toy web server, we used Java. For learning about data structures and a whole bunch of generic algorithms, they used Java. For writing a toy compiler, we used Java.

BUT, when it came down to a situation where it made sense to use another language, we used something else. The projects for the operating systems course were all done in C++. "Computer organization" (i.e. what's an interrupt, what's a register, etc.) was done mostly in MIPS assembly and occasionally in C++. Naturally, the programming languages class covered a wide variety of languages. (Haskell was a cool and fun language, despite its attempts to "cure" us of syntax "problems". When language designers do stunts like replacing "!=" with "/=" because "/=" is supposedly better -- despite the fact that the world has already standardized on "!=" and it's ARBITRARY ANYWAY -- they lose some credibility...)

My point is that standardizing on Java isn't really a bad thing. There are lots of times when you're developing pretty generic code, and any pretty generic language will do the trick. Picking Java as that language works well (esp. b/c you can develop on Windows or whatever and then the TA can test your code on his Linux or Solaris system). In fact, I'd argue that it's really a good thing because Java has a thoroughly OO standard API; this gives students lots of practice in thinking in OO terms, and practice is what's needed to come up with good OO designs.

Also, if you're concerned about students graduating who don't have much of a clue, you can blame on that on the dot-com boom as much as anything. Because I went to school at two different points (long before the boom and during the boom), I saw a dramatic difference in the average CS student. In the early 1990's, CS students were there because they loved computers. In 2000, some were there for that reason, but others didn't care about computers at all -- they were there because they didn't know what to major in, so they picked CS as the best path to a high-paying career!!!! The best the university can hope to do is weed some of those people out, and believe me it tried, but some of them persisted because they are very success-oriented. Scaaaaa-ry!

Yes!

[Hawkins]

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.

Re:Thanks ORA: a primer series w/o an insulting ti

[iantri]

Relax.. it's humour. "For dummies" or "Idiots' guide" suggests to me that I should have no trouble with the book if an idiot can figure it out.

That said, I think most "for dummies" books are way below the level of most Slashdot readers.

Just Java

[Anonymous Coward]

My favorite Java book is "Just Java". I also took Sun's introductory Java class (not cheap but my company paid), and surprisingly enough, I learned quite a bit in five days from an excellent instructor.

most misunderstoof language in the world

[MemeRot]

JavaScript's prototyping is great in my opinion.

And the conception that you can't have private members in Javascript is just wrong.

Re:most misunderstoof language in the world

[2short]

"And the conception that you can't have private members in Javascript is just wrong"

Uh, that was certainly my perception. Not that you need private members in any language, they just protect you from doing things you shouldn't in the future. Javascript is not generally bug on features to protect you from yourself, so it never occurred to me to wonder why it didn't appear to have private members. But anyway, do tell, how do you do a private member in javascript???

Re:most misunderstoof language in the world

[MemeRot]

From here: http://www.crockford.com/javascript/private.html

Private
Private members are made by the constructor. Ordinary vars and parameters of the constructor becomes the private members.

function Container(param) {
this.member = param;
var secret = 3;
var self = this;
}
This constructor makes three private instance variables: param, secret, and self. They are attached to the object, but they are not accessible to the outside, nor are they accessible to the object's own public methods. They are accessible to private methods. Private methods are inner functions of the constructor.

function Container(param) {

function dec() {
if (secret > 0) {
secret -= 1;
return true;
} else {
return false;
}
}


this.member = param;
var secret = 3;
var self = this;
}
The private method dec examines the secret instance variable. If it is greater than zero, it decrements secret and returns true. Otherwise it returns false. It can be used to make this object limited to three uses.

By convention, we make a private self parameter. This is used to make the object available to the private methods. This is a workaround for an error in the ECMAScript Language Specification which causes this to be set incorrectly for inner functions.

Private methods cannot be called by public methods. To make private methods useful, we need to introduce a privileged method.

Re:Java is bad for our industry

[bc8o8]

Part of what I was including in "Computer Science Fundamentals" is the way the language itself implements the various features that are offered. In order to make Java platform independent, these features are so abstracted from the surface that it is difficult to actually study how they are implemented. In languages like C, C++, Lisp, Scheme, etc the implementations are easy to see and study.

I do agree with you that University does NOT exist to teach people all the practical skills necessary, if this was the case your education would be outdated by the time you graduate. It IS however important for students in their final years in school to learn the details, and gain valuable experience in applying these concepts and learning which tools/languages are most appropriate for the job. This is not possible of your only learning one language.

My main concern is not specifically that the students are being taught Java, but they are being taught nothing but Java. Since Java is such a high level language, you miss out on many of the low-level concepts that are needed in the industry. Sure if you went through and read Java's source code and delve down into the innermost corners of the language you MAY be able to locate the implementations of these concepts, but that's obviously not the best way to go about it.

And I agree that if students miss out on those concepts it is their own damn fault, unfortunately many of them do. And since they end up graduating with the same diploma as those who actually made the extra effort and learned the underlying details, they become a bad reflection of the school and the school's curriculum.

I personally have done some Java programming, I can see the power the language has and I do respect that. However, I do NOT feel the language is appropriate to teach students the innermost functionality of how a computer works.

Why you should generally hire young coders

[AstroPup]

I have to admit I've stayed away from object-oriented programming; after all, I've been writing software for nigh on twenty years without it - why make life hard?

Here is exactly why managers go for the young coders! Too many old farts that think their way is good enough versus a bunch of young ones willing to learn new ideas and tools. (I'm one of the old ones but not stuck in the past)

Re:Why you should generally hire young coders

[forgetmenot]

Actually, I have doubts about the truth to this. I've heard it said a lot, but I never actually seen it in practice and I'm not exactly a skinny pimply teenager anymore. Anybody and their dog can make the claim of knowing 200+ programming languages and able to learn more real fast. That doesn't catch anyone's eye. Young programmer's might be preferred by some operations because they are CHEAPER! But willing to try new things? I seriously doubt that. Younger also means less experience with any one thing.. and as I said, just about anybody in this industry (and certianly the types that read slashdot) can make the claim of knowing a lot and able to learn more regardless of their age. What makes someone an attractive hire for a serious employer is specific knowledge of specific toolsets. Mind yo, I can only speak for the IT industry. Most IT shops and the like don't have every programming tool at their disposal or are reluctant to bring in extra tools even if free because of training/research costs. It's usually a significant investment in a small set of technologies and ideally they want people who already knows those tools (= lower training costs or downtime for familiarization). That's why in the IT world you often see really obscure job requirements or 2+ years of experience in tools that came out only in the last month.

nontraditional approach to LISP

[Anonymous Coward]

The book you are looking for is The Little Lisper.

http://www.amazon.com/exec/obidos/tg/detail/-/00 23 397632/104-0234325-8731900?v=glance

A prof of mine in college wrote it, along with The Little Schemer.

Re:Java is bad for our industry

[bc8o8]

I didn't mention the school's name because I didn't want it to end up becomming a "I just graduated from there, and the education is MUCH better than at YOUR school!" type debate.

I haven't done much research in wxWindows, but I've been meaning to.

I actually do like coding in Java when it's appropriate. I haven't found much better for GUI-type applications (although maybe once I do some research into wxWin I will ;-)

The moderator replies

[Anonymous Coward]

i liek poo

Re:I'd like to take this oppertunity..

[Q Who]

How can Java be slow? It's a language. Languages typically can not be quantified by speed.

Unless the language assumes garbage collection. Not precisely "slow", but pretty much ruled out from real-time applications...

Re:Java is bad for our industry

[Abcd1234]

Part of what I was including in "Computer Science Fundamentals" is the way the language itself implements the various features that are offered. In order to make Java platform independent, these features are so abstracted from the surface that it is difficult to actually study how they are implemented. In languages like C, C++, Lisp, Scheme, etc the implementations are easy to see and study.

Yes, but that's a very small part of the whole of computing science. Moreover, there are specialized classes for teaching this sort of thing (at least at my school). For example, you can take the Compilers course to understand how a C/C++ compiler works. And you can take a course in non-procedural programming languages to learn how Lisp does it's thing. But I see nothing wrong in teaching, say, a software engineering course, or a UI design course, or even a basic programming class in Java. Those courses aren't concerned with these low-level details you speak of, nor should they be.

Frankly, I have no idea why you'd ever use a programming language to "teach students the innermost functionality of how a computer works"... that's what a course in computer architectures is for. And as for teaching the fundamentals about *computing*, like I said, any language will do. About the only benefit I can think of to using C is to teach students the concepts of memory management, pointers, and so forth which, admittedly, is incredibly important. (although, even in the days of C, very few students fully understood pointers). Although, a good course in, say, assembly programming, with a smattering of C, on some sort of embedded device would be sufficient in teaching these concepts... we had a course something like this when I went through school. We did M68k assembly coding on little embedded boxes... you'd be amazed how many people understood pointers after a class like that. :) Nowadays they do it all in MIPS simulators, but the effect is the same...

Basically, my point is that Java is a perfectly useful teaching tool. It ain't perfect. It's not ideal for teaching all concepts, but it's certainly sufficient for the vast majority of classes the average CS grad will take. And if a student chooses to coast through the program, only ever learning Java, again, that's their problem.

And as for the rep of the University, I highly doubt companies base their opinions about a CS program solely on the quality of the crappiest grads... after all, I'm sure MIT has it's fair share of slackers, too.

Review is okay

[wcbrown]

Your review is okay but it's really superficial. The teaching style is not the focus of the book, teaching Java is. The authors go to extraordinary lengths to make the teaching as easygoing as possible.

You didn't even touch on their emphasis on test-driven development. This, in my mind, is the highlight of the book. They not only explain it well, but they show it in every example they produce. They also make the tests before they start development, which is a good practice that they do consistently.

They also devote an entire chapter to exception handling. Too many books I've read omit it entirely or deal with it in a very casual way. By focusing on it, they really make the reader realize the value in thinking through the possibilities of what could happen.

Finally, they devote an entire chapter to packaging up your Java code for release. Other Java books I've read brush this matter aside, assuming it to be a triviality that should be self-evident to everyone. It's not and doing a proper release is critical to any software application.

Re:Java is bad for our industry

[bc8o8]

Again, I'm not saying anything negative about teaching Java to students for topics on UI, Software Engineering, etc. In fact I took a project sequence on GUI design, most of which concentrated around Java. I just think it's extremely dangerous and is an injustice to the students if the school concentrates SOLELY on Java and leaves out the other important concepts that are best studied in some other language, and there are schools out there doing this.

When programming is incorportated into an architecture course it provides the students with a level of understanding that would otherwise be impossible. In my architecture course we wrote programs that would simulate different architectures (x86, Sparc, etc). In doing this I learned FAR more than I ever could have chugging through facts in a textbook and being quizzed on it. To be effective, these simulators had to be very low-level though (written in C) so they could access hardware, deal with registers, etc.

The curriculum you described sounds similar to the curriculum I am currently involved in, which exposes the students to a broad range of different languages and techniques. This is the type of program needed. I'm not claiming my school has a perfect education, because believe me... I would change a few things if I could. The schools I am referring to are the ones that are essentially teaching the students nothing more than how to write code in Java and passing this as an education in Computer Science.

Head First Java?

[Anonymous Coward]

As opposed to what? Butt-First Java? What gives with these stupid titles?

Eckels' Books are Downloadable

[goodviking]

Here here to the Bruce Eckels sugesstion. He is far and away one of the best authors on the topic of OOP. Further, he does a lot of training, etc... and has made most/all of his books freely downloadable.

Re:Java is bad for our industry

[Abcd1234]

I would change a few things if I could. The schools I am referring to are the ones that are essentially teaching the students nothing more than how to write code in Java and passing this as an education in Computer Science.

Ahh... glorified technical colleges. I conceed the point, in this case. Then again, if I was aware of a school like this, I'd probably never consider hiring them in the first place. :)

Re:I'd like to take this oppertunity..

[sahala]

Take a look at the Resin web server/servlet engine, if you're interested in seeing how good server-side Java can be. This thing can serve static content faster than Apache!

Not to be nitpicky, but resin being speedy at delivering static content can most likely be attributed to the developers doing great native code optimizations for each OS platform supported by resion. A better measure would be how well it does with dynamic content, which it happens to do quite well.

Just to get even more offtopic, I actually highly recommend Resin as an application server for both learning JSP/Servlets, development, AND production. It's simple to install, configure, and on top of that is small and blazingly fast.

Now, if you're interested in implementation "correctness" Tomcat is probably a better choice, since it's the standard reference implementation endorsed by Sun for the servlet and jsp spec. Tomcat is a bit of a pain to configure (although much easier nowadays) and is more sluggish. Resin goes very far down the optimization path and is very aggressive on how resources are used. While still supporting the spec, sometimes you'll come across odd behavior, particularly with things like pooled objects.

All in all though, go crazy with Resin.

Richard Feynman might not agree!

[logpoacher]

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!

Re:I'd like to take this oppertunity..

[swillden]

Good GC implementations are actually significantly faster than hand memory management (malloc/free) in terms of total CPU time consumed by memory management, particularly in multi-threaded applications (since a thread-aware 'free' has to do locking for every block freed). As far as real-time stuff goes, there are also GCs designed for real-time use that provide hard guarantees on GC times, though most do not in the interest of optimizing overall performance at the expense of an occasional pause.

Then again, it's good to keep in mind that most malloc/free implementations don't provide any maximum latency guarantees, either (though average latencies do tend to be less than with GC).

There is at least one feature of Java-the-language that tends to make it inherently slower than C or C++, though, and that's the profusion of pointers. Since Java manages all but primitive types via pointers there's a lot of unnecessary indirection in a typical Java program.

Quit It!

[Anonymous Coward]

YOU'RE my hero. After being fired from you aol tech support job, having the roof of your trailer park ripped off by the hurricane, having your son cut you off until you buy better lube, and walking in on your white trash wife being porked by the black mailman and yet you STILL find time and joy in consistently posting the same lame troll? you amaze me.
[ Reply to This | Parent ]

You used (t)csh, you lose.

[Anonymous Coward]

(t)csh sucks. Use a real shell.

I have read it

[codemother]

And it is very good at explaining the oo 'stuff'.

NO! NO! NO!

[Anonymous Coward]

JavaScript != Java
Javascript, is actually a very useful and original domain-specific language -- not as powerful as other general languages, but it does what it was designed to do, and it does it well.

Java is "wrapper language" which attempts to duplicate the features of the most popular languages -- at the time of it's creation -- (c, c++) and operating systems (unix/windows) in an attempt to achieve cross-platform portability.

Unfortunately, some of the most powerful features of c and c++ were taken out to simplify the language, and unfortunately as well, it's speed of execution never quite met the expectations of those used to the speed of similar windows-based applications (primarily in the gui department) -- although some performance improvements have finally arrived, some believe that it just may be too little, too late -- especially with the advent of c#.

It seems that contrary to the popular opinion of software developers, the popular opinion of the customer is that speed matters.

On the other hand, some amazing work on creating cross-platform wrappers has been done in the ACE and TAO projects with none of the performance penalties.

Looks like in the "evolution" of programming languages the unexpected may occur:
pascal -> c -> c++ -> java/c# -> c++
much to the chagrin of college board testmakers and
highschool teachers who just spent their summers learning java.

Re:Java is good but slow

[panaceaa]

C is not OO at all!

Writing in OO is more about your design and process, not about the language. With structs and proper design patterns, lots of object-oriented programs have been written with C. Many object-oriented concepts, such as information hiding and protected class members, can be put in place with programming practices and styles. They don't have to be enforced by the compiler.

(And in fact, even with C++ you can access private members of classes by using pointer offsets.)

Re:I'd like to take this oppertunity..

[p2sam]

There is nothing stopping you from pre-allocating a pool of objects to work with. This *is* one of the standard way of avoiding dynamic allocation in C right?

I never get sick of hearing that...

[the-build-chicken]

I decided to learn Java. I'd spent some time using JavaScript

ok...they're really nothing alike, except for the word 'java'. By the way, if you want to learn anything java, why waste cash on books...just head over to java.sun.com and go through their doco section...they have full documentation on almost every api, and have been keeping it up to date for as long as I can remember (the java trail is an excellent peice of work)

True....

[Anonymous Coward]

That's what I used... A WELL WORN copy still sits on my desk, although I now know the contents of every page. It sits next to "Design Patterns"...

Re:Java is bad for our industry

[DavidNWelton]

The problem with Java is that it is impossible to judge it for what it's truly worth because of the marketing dollars behind it. It's good for some things, not so good for others, but to look at the industry today, you would think that it's the only thing you could use, which can't be right.

Any competent programmer can program in a variety of languages, so I don't see why we should have just one stuffed down our throats by corporations.

Re:I'd like to take this oppertunity..

[Q Who]

There is nothing stopping you from pre-allocating a pool of objects to work with.

I prefer using languages which don't require workarounds.

Re:I'd like to take this oppertunity..

[soppyfrog]

You idiot. I am sick of hearing people say how slow Java is, I've had enough. Look here (a repeat of benchmarking done 2 years ago found here) to find benchmarks showing some Java code (using jdk1.4.1) running faster then C++ code compiled with GCC. I'm not saying Java is faster then C++, what I am saying is that Java is not slow, the difference is small and getting smaller, and I think it speaks directly to the intellect of "malocchio" when he bases his opinions on what may have been the case SEVERAL years ago. But that's just me.

Let Me Get This Straight...

[Anonymous Coward]

So I haven't been able to get a job for the last 2 years after getting a BS in Computer Science because I have no experience. Yet this guy, with "20 years experience" as a "programmer" is just now just taking his first furtive into the brave new world of Object Oriented Programming in Java.

I wouldn't be surprised if his Javascript experience is more like wondering around blindly in the fog.

God, when I read this kind of stuff I feel like ending it all right now. There is so much of this deadweight hanging around that people who find it easy to learn multiple languages and actually have some potential to make a contribution to this world will never get the chance. To some recruiter this "programmer" with "20 years of experience" seems a lot more impressive than someone who might actually have a clue. I mean, what the hell does a recruiter know about anything.

Are things going to change, or should I just give up all hope for the future?

And here

[gidds]

Another recommendation here, too. Thinking in Java is by someone who really seems to understand the language. It doesn't just explain the syntax, like so many others; it explains the philosophy, the concepts, the whys of the language (after which the syntax is relatively easy).

After working through it, you'll be able to write true Java programs, rather than just writing C (or whatever) programs in Java.

I'm torn....

[Hecatonchires]

On the one hand, I'm jumping up and down going "An author spoke on slashdot! And not in a planned interview!" Its the same sort of feeling I get when I read a Carmack or Wil Wheaton post here.

On the other hand, I'm hearing "Aooga; Aooga; Blatant Self Promotion Alert. Aooga; Aooga"

Hmm. I'm sure I'd be more appreciative if I'd been able to afford the book when it was reccomended as a course text. I ended up reading online examples and keeping the documentation open in another window.

Check your reality at the door.

[Anonymous Coward]

" 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!"

Until the bottom falls out of the market, and people come running to Slashdot. Complaining about the glut of "in it for the money" (HTML, MSCE, whatever) monkeys clogging the system, and how the honest, for the love of it [insert poster's fav. skill here] can't get a job.

"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."

How about because the problems that programmers are asked to solve correctly are hard.

"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. "

Just make certain that your time savings isn't because you took shortcuts. You will need to maintain the code, as well as comment correctly.

OO techniques are seldom fully understood-maxis

[Anonymous Coward]

"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."

Hehe. The Sims do OO.

Re:I'd like to take this oppertunity..

[The Mayor]

I find this unlikely, since Resin claims to use native code only for grabbing CPU stats and to use the suid flag. Resin's serving of static content is attributable to Java code alone, as far as I am aware.

Re:Java is bad for our industry

[Tablizer]

and the IT shops/people that I've been involved with LOVE Java for its productivity and cross-platform compatibility.

I am skeptical of those claims. I have never seen a good demonstration on how Java improves productivity. It takes MORE code than many of its alternatives. If you want productivity, try a dynamic language like LISP or Smalltalk. The most productive programmers usually use dynamic languages. This has been true for a long time. Ask Paul Graham.

As for cross-platform, most places run it on one brand. For server-side, Java is no more cross-platform than say Perl or LISP.

OO is for yankers and Enron conslutants

[Anonymous Coward]

OO is for yankers and Enron conslutants. It is a big pile of lies. No evidence, just hot air.

Re: OO is for large programs

[Tablizer]

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.

My technique is to break large problems into smaller "scripts" or "tasks", and use the database to tie them altogether. It works (if you do it right). I swear on it for most biz apps. OO philosophy focuses too much on managing large applications when one should instead focus on making lots of smaller apps instead a huge sea of Java classes. Divide and Conquer.

Dijkstra wouldn't like the LingerieExceptions...

[I'm Just An Object]

Or the girl in the bathtub, or, well, about 98% of what's in a Head First book. And this was deliberate. I'm the co-perpetrator, and creator of the Head First series.

Personally, and as smart as he is...Dijkstra is just not someone I would have ever wanted to date, or even sit next to at a dinner party.

And wasn't he also the author of something to the effect of, "Anthropomorphizing is the sign of an immature mind?"

Well, we blew that one Big Time. I think half the book is anthropomorphized *things* -- objects, variables, threads, you name it, we've turned it into a living breathing (sometimes swearing) thinking *feeling* creature.

We'd like to counter Dijkstra with someone we feel certain would kick his ass in a celebrity boxing match. Roger Schank. He was chairman of the computer science dept at Yale (and director of the artificial intelligence project). Last I heard he was Distinguished Professor of Computer Science at Carnegie Mellon University. (OK, as far as the boxing thing goes, Schank does have the advantage of being alive...)

And since we know some people will be misled by the pictures into thinking that it must be a "for the lesser mind" , or that, "if it's that fun, it must not be serious." we can point to some heavy hitters who have endorsed the book (on the cover) . One is a former PARC guru and now the Director of User Sciences and Experience Research at IBM Almaden Research Center. He also teaches advanced studies in artificial intelligence at Stanford.

Another is Ken Arnold, co-author with James Gosling of "The Java Programming Language", and a co-developer of the Jini specification.

Then again, another quote inside the book is from Rick Rockwell, the original groom from "Who Wants To Marry A Millionaire" (now Darva Conger's ex.).

PARC and FOX in the same endorsement page...

That alone will stop some folks from getting it.
And if you don't like the style, it won't even be tolerable -- at best, an acquired taste, whereas a more traditional format is usually acceptable even if you don't LOVE it.

So a lot of folks (me especially) are wondering how many people out there will actually *want* to learn this way. This is a brand new concept, so we'll have to see. If you want to know how it's being received, check on Amazon from time to time, and search on Java, and sort on bestsellers, or check the O'Reilly bestseller list. The book has been out for only a few weeks; it will be up to learners/readers to decide.

I can tell you our proudest moment came when we got an email from a guy whose wife doesn't fully approve of him reading the book.

cheers,
Kathy Sierra, co-author Head First Java

Re:I'd like to take this oppertunity..

[Anonymous Coward]

Actually, that's not entirely true. You may notice that high performance software is not programmed in java because on large scale problems it can not compare to C. These benchmarks are on relatively small size problems. Further, when I'm designing a time critical, high performance application I can't afford to have a garbage collector go off in the middle of my program and cause strange performance variations.

I'm sure that java will become faster in the following years. I'm sure its garbage collection will improve (or maybe you can manually manage memory; I don't know.) But, flat out, it can not compare to a low level language like C in a large-scale high performance application.

Re:I'd like to take this oppertunity..

[soppyfrog]

That is true, very true. But the point I was trying to make is that Java is not slow. While not fast enough for situations where time is of the upmost importance (which for the majority of applications it is not; but not all of them) C/C++ is really the only option. I have just had it with people saying Java is sloooooooooooooooooooooooooooooooooow when the reality dictates otherwise.

Re:I'd like to take this oppertunity..

[HuguesT]

Hi,

> Good GC implementations are actually significantly
> faster than hand memory management (malloc/free)
> in terms of total CPU time consumed by memory
> management,

Can you provide a reference to that, this is interesting and I don't believe it offhand. I can't see why a multi-threaded GC would be better either. It would have to block all the threads as well, and it would have to do at least a log(N) search for garbaged blocks, whereas a hand free is constant time, no search needed.

> Then again, it's good to keep in mind that most
> malloc/free implementations don't provide any
> maximum latency guarantees, either (though average
> latencies do tend to be less than with GC).

Similarly there are real-time implementation of malloc/free that do provide maximum latency guarantees. The best approach might be a malloc/free combined with a GC. The frees are used as simple markers and return instantly. The GC is called when CPU usage is low and does the actual free in one go. You get the best of both world at the cost of increased average memory usage.

You are right about the indirection problem. At least in C++ you can elect not to use virtual methods if you don't need to.

Finally in my opinion the curse of java is the guarantee that bounds are checked for every array access. This is great during development but there ought to be a way to turn that feature off.

I work in image analysis where array access is what we do all the time. That aspect of the language is a killing blow.

Re:Java is bad for our industry

[hoggoth]

> speed to completion [...] Perl not Java

Does everyone agree with me on that?
I was sort of hoping someone who loves Java might try to argue/explain to me why this isn't true (in their opinion).
I'd like to find out if I am missing something about Java. I mean why is the whole industry so nuts about it?

Mr. Bunny's Big Cup o' Java

[Anonymous Coward]

Actually, the name of the text is "Mr. Bunny's Big Cup o' Java".

Damn funny book. It even got it's own review here on Slashdot. For those unforunates who haven't read this fine text, you can find a sample page here.

Since I'm not a highly paid author of technical books, I'll just steal this quote:

• There is simply no better way to learn Java than to have the pineal gland of an expert Java programmer surgically implanted in your brain. Sadly, most HMOs refuse to pay for this career saving procedure, deeming Java to be too experimental. At last there is an alternative treatment for those of us who cannot wait for sweeping health care reforms.

• Mr. Bunny's Big Cup O' Java is recommended by n out of ten doctors, where n is any integer you wish to make up to impress an astoundingly gullible public.

  The book begins with an overview of the book, and quickly expands into the book itself. Just look at the topics covered:

  Mr. Bunny's rucksack Farmer Jake's overalls Java

  In short, MBBCOJ will teach you all you need to know for a successful career in today's rabbit development environments.

If you need more details, you can look at a preview at Amazon.

Grrr... Apparently I've moderated this dicussion, so I have to post as an AC or someone will lose precious karm.

Re:I'd like to take this oppertunity..

[Moraelin]

Strictly speaking, it's more complicated than that.

The code generation part, at least in IBM's implementation, is not much worse than what your average C++ compiler does. (Been using it since 1999 at work, so I'd say by now I have some idea of what its strengths and weaknesses are.)

In fact, I know a lot of commercial C++ programs which shipped with poorer code. Why? Because at release noone turned the optimizations on, nor the assertions off. Someone just stripped the debug info and shipped the sub-optimal debug version as it was.

What slows down Java are a bunch of other factors, which are not an implementation issue, but stem from its very design and philosophy.

E.g., the strong OO design, combined with the fact that _everything_ is dynamically allocated, means a flurry of small objects are allocated and dealocated. Any program more complex than "Hello World" is going literally through anywhere between _thousands_ and tens of thousands of objects per second.

In C you could just allocate an array of structs on the heap, for exactly zero penalty. In Java the best you can do is an array of _pointers_ to those structs, each struct individually malloc-ed. And even the array _itself_ is malloc-ed and all you have on the heap is a pointer to it.

So if for you had an array of 1000 structs, the Java version will have an extra 1001 malloc and free operations, and an extra two levels of indirection through pointers. You can see how it can't possibly be as fast as the C program, even if the code generator is identical.

Now add the fact that a garbage collector has to go through the whole mess periodically, and figure out which of those gazillion little objects are still in use.

Then there's stuff like the string processing. In C you could do wonderful things with byte arrays, and it was damn quick. In Java's strict object oriented world, even putting together a small web page brings you back to problem 1: a flurry of small objects being malloc-ed and destroyed.

Now if you want to go even further, Java also has other features, like mandatory array size checking. Even if you _know_ that a buffer overflow can't possibly happen (e.g., because you copy between two buffers and allocated both at the same time and with the same size), Java still keeps the training wheels on. Every single byte copied will go through two array index bounds checks: once when reading it from the source array, once when writing it to the destination array.

On the other hand, unfortunately, this is precisely the stuff which makes Java nice in the first place.

E.g., sure, you could do much better performance-wise in C with malloc, than relying on Java's garbage collector. On the other hand, this also means that in Java you won't have to go through months of debugging memory leaks. (You can still get a memory leak in Java, but far less often.)

E.g., sure, you could do much better performance-wise in C by cleverly removing unneeded array size checks. But then you can and _will_ go to far and remove checks which are actually needed. See the ton of Windows and IE exploits based on buffer overflows. By contrast, Java's forcing you to keep the training wheels on, tends to produce far more robust code and far less debugging work.

Etc.

Basically Java does have a bunch of nice features, and it does trade some speed to get them.

You get sick because you want to

[jotaeleemeese]

The reviewer clearly stated that one tool has reached its usefulness peak and that it was time for a better one. No confussion unles you read what you want to read.

If you can't read don't post.

[jotaeleemeese]

He clearly understands that they are two different things, he just states that he used one and looked for another one better suited for whatever he was doing.

that's dead wrong

[MemeRot]

I write ansi sql 99% of the time. it runs fine anywhere - sql server, sybase, oracle, access, whatever.

you are also assuming that a company will EVER change it's database. in my experience, this just DOES NOT ever happen. it would be so prohibitively expensive and error prone, that if you spend ONE SECOND making sure your code can be ported to another database system, you're wasting valuable company time. i've worked at a half dozen different companies. none of them ever changed database systems or OS platforms. 4 of them are out of business at this point, so the choice of an OS platform or database system has a longevity equal to the length of the company - portability to another system is not a feature that adds value. besides, web services and xml allow you to write completely platform agnostic applications while taking full advantage of native OS code. if you don't care whether data is stored in a database or a filesystem, you're throwing out the billions spent refining the capabilities of the database.

have you ever personally worked at a company that switched their mission critical systems to another OS or database? if so.... what the hell did they do it for? i can't imagine how long the time period would be before you'd see s return on investment - which is what drives the business world, not CS idealism.

More on why scripting rocks

[MemeRot]

from: http://www.softpanorama.org/People/scripting_guant s.shtml

The best introduction that shows the importance of scripting languages was written by John K. Ousterhout. He outlined four main advantages of mixed scripting language + compiled language programming in his famous paper Scripting: Higher Level Programming for the 21st Century

He pointed out that scripting languages represent a new type of languages: glue languages. ...Scripting languages such as Perl and TCL represent a very different style of programming than system programming languages such as C or Java. Scripting languages are designed for "gluing" applications; they use typeless approaches to achieve a higher level of programming and more rapid application development than system programming languages. Increases in computer speed and changes in the application mix are making scripting languages more and more important for applications of the future.

The second main idea is that scripting languages presuppose component programming and component framework can benefit from scripting languages. If you think a little bit, you can even consider Unix shell as the historically first component oriented language ;-). ...Scripting languages and system programming languages are complementary, and most major computing platforms since the 1960's have provided both kinds of languages. The languages are typically used together in component frameworks, where components are created with system programming languages and glued together with scripting languages. However, several recent trends, such as faster machines, better scripting languages, the increasing importance of graphical user interfaces and component architectures, and the growth of the Internet, have greatly increased the applicability of scripting languages. These trends will continue over the next decade, with more and more new applications written entirely in scripting languages and system programming languages used primarily for creating components. ...Scripting languages such as Perl, Python, Rexx, Tcl, Visual Basic, and the Unix shells represent a very different style of programming than system programming languages. Scripting languages assume that there already exists a collection of useful components written in other languages. Scripting languages aren't intended for writing applications from scratch; they are intended primarily for plugging together components. For example, Tcl and Visual Basic can be used to arrange collections of user interface controls on the screen, and Unix shell scripts are used to assemble filter programs into pipelines. Scripting languages are often used to extend the features of components but they are rarely used for complex algorithms and data structures; features like these are usually provided by the components. Scripting languages are sometimes referred to as glue languages or system integration languages.

The third important idea is that scripting languages are better used in tandem with compiled languages. The latter should be used for the component building where as scripting languages should be used a s a glue. ... A scripting language is not a replacement for a system programming language or vice versa. Each is suited to a different set of tasks. For gluing and system integration, applications can be developed 5-10x faster with a scripting language; system programming languages will require large amounts of boilerplate and conversion code to connect the pieces, whereas this can be done directly with a scripting language. For complex algorithms and data structures, the strong typing of a system programming language makes programs easier to manage. Where execution speed is key, a system programming language can often run 10-20x faster than a scripting language because it makes fewer run-time checks.

Most of the major computing platforms over the last 30 years have provided both system programming and scripting languages

Java Game Development

[AndersDahlberg]

Before/At this years JavaOne Sun created a Java Gaming Group aiming at making java the best language/platform for writing (including AAA style) games. Doing this will be by supporting the old java3d (win32 and linux scenegraph + opengl/direct3d functionality) and java2d (all java platforms, most hardware accelerated on win32 atm though). And, here comes the big news, by the release of the open source java opengl api - a java binding to opengl which is as fast as any c native binding thanks to the use of java nio buffers (read: native read/write memory access, the difference between java and c bindings should be unnoticable in any game). IMHO This news with java's superior networking api's will make java the nr 1 language/platform to write the next generation of game titles on.

Also, maybe look for news concerning java and playstation in the next year or so (this is just a rumour that's been going for a couple of months/year at www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi).. .

So my advise to you is to cover the basics of how to write efficient, first class, high performance games with java.

Suggested api's to cover (all or subsets/overview):
games-core.dev.java.net (sun sponsored java gaming community site)
JoGL: 3d hardware accelerated graphics (opengl)
JoAL: 3d sound - EAX and others (openal)
JInput: high performance input framework - pullable keyboard/mouse, force-feedback gamepads, joysticks etc etc.

and also (the thing that got all above started, by making people understand java can be used to write great games):
LWJGL (a package of opengl, openal, high performance vector math package, jxinput into one small library ~ 500kb)
Another, different, version of the above, with the only exception that earlier mentioned JoGL is a more "broad" approach to 3d - whereas LWJGL is *only* targeted at gaming.

Related links:
http://community.java.net/games/
http://w ww.lwjgl.org pre-release 0.7 available now!
http://www.puppygames.net

Thanks and some comments

[theolein]

After learning Pascal some twenty years ago, the first time I had something to do with a compiled language was with Java in 1999. My first book was the Java in 21 days thing, which was a desaster for me. I found a used copy of Exploring Java in our company and that, although I had no experience in C or C++, was the best book I'd ever read on programming language. The occaisional, out of the blue, witty sarcastic comments could have come from any developer who is sitting in frustratedly in front of the monitor at 2AM. I refer here to the comment about how banging one's head against the monitor is also an event. I almsot wet myself when I read that.

It was things like that and not childish cartoons found in many books attempting to be simple, that made the book a good read. Programming is difficult and the acceptance of that is what helped me.

Thanks for a brilliant book.

Re:I'd like to take this oppertunity..

[sahala]

Really? I didn't know that. Not that I doubt you, but where'd you read this?

Re:I'd like to take this oppertunity..

[The Mayor]

Well, for one thing, JBoss (which includes Resin in their default install) has only one .zip file for all platforms (implying that they either have binaries for all platforms included, or it is pure Java). Second, I did a google search and came up with this. See question #46.

Re:I'd like to take this oppertunity..

[swillden]

Can you provide a reference to that, this is interesting and I don't believe it offhand.

That's understandable... it's pretty counterintuitive. As far as references, I've seen various papers at different times, but the only one I have to hand is this, which isn't ideal, as it requires special hardware support. You might also find some useful information here. Oh, there's also this which shows a conservative, non-relocating GC that is only slightly worse than malloc/free implementations on C and C++ programs that were designed for malloc and free (in the GC version, free simply becomes a NOP). It shouldn't be too surprising that it's worse since it's a case of GC operating within a very tight straightjacket.

In general, the reason GC can be faster is because (a) it can look at the heap more holistically, better optimizing the heap structure for fast allocations and (b) because it doesn't have to free memory on the programmer's schedule, it can defer the work until it can accomplish more at once, with less amortized effort. That's a lot of handwaving, of course. Sorry.

I can't see why a multi-threaded GC would be better either.

It's not that a multi-threaded GC is better, it's that GC is more efficient than malloc/free in a multi-threaded program because free typically has to aquire and release a lock on every invocation (and locking is generally pretty expensive, particularly in SMP environments where you have to execute write barriers), whereas GC can simple take control of the entire heap once in a while (one acquire/release, rather than hundreds or thousands). The GC is more efficient overall because it does its work in larger chunks.

Similarly there are real-time implementation of malloc/free that do provide maximum latency guarantees.

Yep. If you're doing real-time, you need a real-time memory manager, whether it's GC-based or manual. My point is that people often compare non real-time GCs to non real-time malloc/free implementations (which are faster on average than real-time implementations, but have unpredictable worst case behavior) and then declare that GC is unsuitable for real-time.

The best approach might be a malloc/free combined with a GC. The frees are used as simple markers and return instantly. The GC is called when CPU usage is low and does the actual free in one go. You get the best of both world at the cost of increased average memory usage.

Hybrid manual and automatic collection schemes are indeed useful, but not really for the reason you specify. In practice, the work of scanning the stack to discover the rooted objects isn't as bad as you might think, particularly on architectures where pointers have to be aligned, and especially when the GC knows where the pointers in heap resident objects are to be found. The main reasons for a hybrid approach are to (a) manually deallocate very large objects, to defer GC, (b) temporarily suspending GC during a critical section of code that cannot be interruped, which often requires manual deallocation for the period that the GC is turned off and (c) providing specialized memory pools for objects that are allocated and deallocated with extreme frequency and predictability (for much the same reasons you do pooled allocations rather than relying on malloc and free).

That said, a "free" that simply informs the GC that this object is no longer needed could be a good idea. Whether the GC should take this as a hint or a fact is open to debate.

One final comment about GC: it is *not* the savior of lazy programmers who don't want to worry about memory allocation. It makes things a bit easier, sure, but I've had opportunities to debug huge memory leaks in Java programs that were caused simply because the programmer didn't think about nulling a

Re:I'd like to take this oppertunity..

[sahala]

Cool. That's pretty impressive. I never really looked at Resin under the covers (never really needed to...it just worked) but I always assumed that it used native code to get great performance.

cheaper

[Anonymous Coward]

Amazon has it with free shipping!

School prep

[czion3]

This previous school year I took the first year of a two year computer science class (I am part of the first year where the AP exam will be in Java instead of C++ ). I will not be able to take the second year next year because of scheduling conflict but will be able to take it my senior year. Our class left off at advanced math problems being solved by recursion (the Towers of hanoi problem sticks out in my head.) What would be a good book to review what we learned this year and be prepared for my second year of the class?

Re:School prep

[Anonymous Coward]

FJK;le'aeikpo'[amjke;l'a3k'l243251234 lm,;a'fm,;.a ,ml'3

Sorry about getting the title wrong.

[PHAEDRU5]

Thanks for not modding me down on that account.

I actually came across CE3 after his ActiveX book, and I've been loving him since.

IMHO, he's right up there with ESR's hacker's dictionary.

Re:I'd like to take this oppertunity..

[HuguesT]

Thanks, that was very informative.

A few comments ; I thought that the `final' keyword was reserved for whole classes but you are right, it can be attributed to methods only.

I think the point is often made, at least in C++ circles, that a mandated GC in standard C++ would be non-real-time, because a real-time GC has worse average performance (like you said) and is very OS-dependent. I'm not sure you could implement a real-time GC for current Linux 2.4 for example. It would require kernel support, and so it is fair to compare malloc/free vs. non-real-time GC because that is realistically what developers would face.

> The work of scanning the stack to discover the
> rooted objects isn't as bad as you might think,
> particularly on architectures where pointers
> have to be aligned, and especially when the GC
> knows where the pointers in heap resident
> objects are to be found

Even on 64-bit architectures? Even with lots of allocations (hand-written lists, etc)? I guess it's possible but non-trivial, and a search is always at least O(log N), right?

Re:I'd like to take this oppertunity..

[swillden]

I think the point is often made, at least in C++ circles, that a mandated GC in standard C++ would be non-real-time, because a real-time GC has worse average performance (like you said) and is very OS-dependent.

Were such a thing to be mandated in C++, I suspect the standard would simply specify the APIs and semantics without touching on performance, just as they do with new/delete and malloc/free. However, I don't think making GC part of standard C++ would be a good idea, anyway. The language isn't well suited to GC, mainly because the programmer can play all kinds of pointer tricks, which means that any GC for C++ must be conservative (has to assume that any pattern of bits that might be a pointer *is* a pointer) and non-copying (meaning it's not allowed to move stuff around in memory, because tracking down and updating all of the references would be slow and error-prone).

I think GC is a useful add-on to C++, though, and it's not really necessary to make it part of the standard for it to work. The relatively small performance degradation you're likely to get from a conservative, non-copying collector vs. malloc/free is often well worth the savings in programmer effort and the increase in reliability.

I'm not sure you could implement a real-time GC for current Linux 2.4 for example. It would require kernel support, and so it is fair to compare malloc/free vs. non-real-time GC because that is realistically what developers would face.

I don't think there's any difference between GC and malloc/free in that regard. Kernel support isn't necessary at all for GC, although I have to wonder if there's anything that could usefully be done... Normally, though, a GC-based system requests large chunks of memory from the OS (via sbrk(), etc.) and then parcels it out as needed, just like malloc does. This is a good thing performance-wise in both cases -- switching to kernel mode for every memory allocation would be tremendously expensive.

Anyway, if you need hard real-time guarantees on Linux, you'd better get a Linux patched up for real-time, and you'd better use a real-time memory manager, whether malloc/free or GC.

Even on 64-bit architectures? Even with lots of allocations (hand-written lists, etc)? I guess it's possible but non-trivial, and a search is always at least O(log N), right?

I can't really see why a 64-bit architecture would matter at all. In fact, I'd think a conservative GC would end up being less conservative, since the space of potentially valid pointers would be such a small fraction of the total 64-bit space.

As to the cost of a search... in the worst case I think it's linear with respect to stack size + size of reachable heap objects. In practice, however, people have come up with all sorts of really clever ways to reduce the effort required. I'm no expert on this (though I have a casual interest that used to motivate me to read papers), so I can't really describe the techniques. There's some good information here.

One that I think is cool, though, is generational copying collection. Basically, it exploits the fact that most objects are allocated and then die very quickly, with only a few being retained "long-term". So, what they do is allocate all new objects in a "young object" pool. When a GC happens, they move all of the objects that are still live into another pool and then just mark the entire "young object" pool as free. You can see how this makes allocation and deallocation of short-lived objects very, very cheap, since the young object pool has no real structure -- just a pointer that indicates where the free space begins; allocation always grabs memory from there, with no worries about finding a block large enough, or updating lists or flag bits or anything. The copying is a bit of overhead on the deallocation side, of course, but it's usually dominated by the savings of not having to examine all of those individual chunks, update free l