tilly: Kudos to the first person to figure out what the bug is.

Update: The above split-based "solution" introduces spurious "" words if a line (say) begins (or ends) with a \W. Looks like m/(\w+)/g is the Right Thing in this case.

Update 2: Of course, split discards any empty trailing entries, so only the ones at the beginning of the line are a problem. (I'll get this eventually...)

Pretty good...

But your proposed fix only handles 95% of the problem. Why didn't I try fixing things that way? (ie What does your fix miss?)

BTW so far this code example is not making the case for Perl being maintainable look very good... :-(

UPDATE
Your update is half-right. The half that is wrong is the most common misunderstanding I have encountered about how split behaves...

UPDATE 2
Eventually seems to have come. Modulo difficult questions about how the definition of a word ain't what you would expect. Consider a kudo delivered. :-)

95%? You expect to only have 20 words? ;) [Update: I was thinking of a "slurp" version -- and rechecking shows that the original Perl version had a much more serious bug...]

BTW, I guess "ain't" ain't a word. (:

        - tye (but my friends call me "Tye")

What if you want to print out the list not alphabetically, but by how many occurances of the word occur? The easiest way to do this would be an ST¹. Is an ST easy to maintain?

Correct me if i'm wrong but i believe that Java has a method of doing this immediately (which is probably why they used the Tree to print it) whereas Perl can do it readily, but it's harder to understand for the common Java programmer, not to mention a few Perl programmers. Who wins maintainability this time?

jynx

¹Schwartzian Transform
update - d'oh, i shouldn't post before my first cup of coffee. please disregard...

Perl.

Right now our Java solution hasn't yet figured out how to handle contractions yet. Perl is still ahead. Secondly why break out the sledgehammer when you don't have to?

foreach my $word (
  sort {
    $freq_count{$b} <=> $freq_count{$a} or $a cmp $b
  } keys %freq_count
) {
  print "$word:\t$freq{$word}\n";
}
[download]

Most Perl programmers should understand this. Doing the same in Java, well probably somewhere in their maze of classes is one that naturally sorts in exactly the order you want. Good luck finding it, and good luck for the average Java programmer realizing why you chose this way of doing things.

And as for the maintainability of a Schwartzian Transform, it is a trick. If you think in a list-oriented way, or if you have ever really understood the tranform, then maintaining it when you see one is pretty easy. I understand it, and I try to ensure that people I train are able to handle list-oriented thinking. So it isn't a problem for me. But YMMV on its maintainability.

No Schwartzian Transform is required. Does Java let you easily sort ignoring case? How about by length?...

sort { $freq{$a} <=> $freq{$b} } keys %freq
sort { lc($a) cmp lc($b) || $a cmp $b } keys %freq
sort {
    length($a) <=> length($b)
 || lc($a) cmp lc($b)
 || $a cmp $b
} keys %freq
[download]

You might find that a ST executes faster for that second case (and you could almost certainly speed it up with one of several techniques that are faster in Perl than an ST), but I doubt the speed gain would be worthwhile since lc() shouldn't be that slow.

Speeding up the third case with a ST would be more difficult than using some other sort-speeding techniques (many of which have names that I don't recall). Though you'd have to have a whole lot of different words for the trade off of sort speed for code complexity to be a "win" here, especially since we are trying to write very maintainable code.

        - tye (but my friends call me "Tye")