|Perl Monk, Perl Meditation|
A peek at the other side or, Poof and He's Gone!by mr.nick (Chaplain)
|on Oct 22, 2001 at 17:16 UTC||Need Help??|
Not to give myself credit beyond my due, but have you noticed the complete drop off of my presence here at Perlmonks? It has, from multiple per week postings to absolutely nothing in the past two+ months. And it's entirely due to my new, new job, writing Java code.
The job was a strange one to take. I did so entirely because of the environment of the work place. It was a small company, filling a very narrow niche extremely well, and profitably. They hired me knowing I have never written Java before beyond a simple "Hello world" to test my JDK's installation years ago.
I admit: I went into it very biased. I had just reached another level of Perl programming and it seemed to me that Java had some very large shoes to fill. But I regarded it as Yet Another Learning Experience and pushed on. I lucked out completely. The developer who took me under his proverbial wing was the author of the flagship application that had "made" this company. And he is as much of a JavaGod as any PerlGod I've ever heard from.
This application (in parts, of course :) is an absolutely masterpiece of Java Object Oriented programming. It's obviously written by someone who not only programs in Java, but understands Java. And it was my first exposure. I could not have dreamed of a better intro.
So, the undefeatable combination of superb example and superb tutoring quickly turned my feelings for Java.
I love it. It's better than sliced bread. But you have to get below its skin to see why. When you don't try to port stuff from another language into Java, but instead use it natively, it shines. It's all about the hierarchy of objects and STRICT adherence to types and parent/child/sibling relationships. Without going into depth about Implementations, Abstracts, Interfaces, Packages and a horde of other features, I don't think I can provide enough info to make any sort of persuasive argument. It hinges too much on the interaction between objects and the FORCED conformation to standards to get without having seen the objects used in the method they were designed.
One aspect that is easy to comment on is Javaís Exceptions. They are basically error codes (and triggers) that propagate back up the function stack. In any method that calls a subroutine that can POSSIBLY throw an exception, you have two choices available to you: catch it or propagate it back to the caller. The compiler DEMANDS you do one or the other. It makes for very efficient (and required) error handling. Read up at Sunís tutorial for more information.
Another aspect I can comment on is the myth of Java being slow. The only slow Java I've seen is poorly written Java. When written correctly, it rivals C++. Take this personal mistake that I made in a critical data path as an example:
I made MANY boo boo's here, one that I should have known better and one that I don't feel bad about not knowing :)
The first was the for() statement: I'm calling the function size() every time it loops :( Bad Mr.Nick. Should have been:
The second is more subtle and when I realized it, I instinctively knew that MANY other Java coders probably do the same thing every day. It's the string concatenation occurring on the 2nd line of the example.
There are VERY few "magical" things that occur in Java. One of them, however, is putting a string in quotes like "This". When the java compiler hits that, it creates a String object primed with the quoted value. The String object is immutable. Once it stores a string, it can't be altered. To "alter it", you must destroy the old String and create a new one. Sounds wacky, I know, but there are reasons for it. So in my example the following sequence happens: a String object with "PR-" is created. Then you concat the String object in array[i] to it; which means that a third String is created and the first is destroyed. Then you do it again with "-RD": another String is created ("-RD") and added to the other one, which results in yet another String and another destroyed one.
Not very efficient. The proper Java way is this:
Quoted strings as function variables do NOT get converted to a String object. Instead, they are passed as an array of char's (an intrinsic type, not OO). And, of course, StringBuffer is written in an EXTREMELY efficient manner.
It's situations like the above that give Java a bad name. But once you understand it, and use it like it was MEANT to be used, it's fast and clever.
It bears mentioning that I am not suddenly a convert :) My personal Perl project has benefited greatly from some of the techniques I have learned. But it does make me have high hopes (and expectations) for Perl 6.
PS (and unrelated): since "upgrading" to IE 6.0, I noticed that all the text here at PM is center-aligned (including code blocks). Is there anyway to fix that?