Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

A peek at the other side or, Poof and He's Gone!

by mr.nick (Chaplain)
on Oct 22, 2001 at 17:16 UTC ( [id://120508] : perlmeditation . print w/replies, xml ) 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:

for (int i<0; i< array.size(); i++) { String result = "PR-" + array[i] + "-RD"; file.write(result); }
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:

int size = array.size(); for (int i<0; i< size; i++) {
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:

StringBuffer sb = new StringBuffer(); int size = array.size(); for (int i = 0; i < size; i++) { sb.append("PR-").append(array[i]).append("-RD"); file.write(sb.toString()); sb.length(0); }
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?

mr.nick ...

Replies are listed 'Best First'.
Re: A peek at the other side or, Poof and He's Gone!
by footpad (Abbot) on Oct 22, 2001 at 19:05 UTC

    But you have to get below its skin to see why.

    I believe this is true of nearly every programming language. In my experience, each has certain design concepts that must be mastered for your code to move beyond a certain stage. Sure, you can produce acceptable programs1 after a limited amount of training, but certain skills must be acquired before you can move beyond the most trivial (or possibly even tortured) implementation.

    For example, C requires a firm grounding in pointers and indirect thinking. A certain database language of my acquaintance requires you to understand the interactive product before you can effectively program it. Old fashioned assembler (of the 8086 kind) required a handle on using the registers efficiently as well as the interrupts provided by the BIOS.

    We might choose various things in Perl: regexes, variable context, hashes, map, CPAN use, whatever.

    That's not where I'm going with this.

    I get nervous when folks criticize languages for lacking specific features or constructs--especially when I feel I understand those languages quite well. For example, some have criticized Borland Delphi (a Pascal derivative) because it doesn't support multiple inheritance (ala C++). Personally, I know that there was a great deal of internal discussion within the original development team about that very point and that a specific design choice set aside that feature for others that were deemed more appropriate. Now, we can argue the validity of that choice (if we must; I'd rather not), but my point is: Sometimes we criticize things without understanding their context.

    I submit that such criticism is misplaced.

    That's not to discourage healthy discussions about ways to improve a language. Those are always needed, however, I don't believe that one language is completely superior to another. They're just tools and you should use the tool most appropriate for the job. And in choosing your tool, you need to account for your needs, as wells as those of the project, the people involved, and those that'll support and maintain your program over time.

    Informed comparisons are fine...however, make sure that you don't make statements that others would find odd. That is, don't say "this is how it's done" without verifying that is indeed the preferred way to do it.

    To illustrate, someone once offered a talk discussing certain aspects of variable typing, as implemented in popular languages.2 When discussing Pascal, he first (accurately) noted that the language stores strings in arrays of chararacters. However, he noted that the following was a problem:

    var str : array[ 1..20 ] of char; endVar begin str := 'Hello, World!'; end;

    Why did this strike me as odd? This example is problematic, but only because the wrong data type of used. If str is declared as a string type (in Delphi and its older sibling: Turbo Pascal), it works fine. (I should've asked for clarification at the time and I regret that I didn't. It would have been instructive to know what compiler the author had been using.)

    Unfortunately, I was so struck by the oddness of the example, that I lost the train of thought in the overall presentation for several minutes. The presenter's points during that time were pretty much lost to me and the presentation ended up failing to achieve its purpose. (I really should have asked for a clarification.)

    So why bring this up, especially on this site and in this thread?

    Simply to point out that:

    • As you pointed out (and I just want to highlight that), sometimes the problem lies in how you're using the language, not in the language itself.

    • Exposure to other languages is helpful and such exposure needs to be long enough to actually understand the language and why other (presumeably) intelligent people like it.

    • Computer languages are just tools for getting certain jobs done. The more you know about the tool you have available to you, the better equipped you'll be to use the proper one for the task at hand. (This is, I think, something that tilly's been trying to tell us for months.)

    • Skills acquired in one language frequently improve your work in others. (The optimizations you mentioned can be applied to many languages, not just Java.)

    • It's natural to prefer certain languages, tools, or what-have-you. It's dangerous to disregard things you aren't familiar without first taking the time to understand them as completely as possible.

    • If you're going to criticize a product, language, person, design choice, or whatever, then you had best take the time to make certain that you fully understand why the thing you're criticizing is done that way. You may find yourself pleasantly suprised.

      If you don't have the time--or inclination--to fully investigate the situation, then you really don't have the time to create an informed criticism. Sherlock Holmes is quoted as saying, "It's a capital mistake to theorize without data."

    And, finally, the IE6 behavior you noted has been noticed; I believe efforts are underway to find a solution that works on as many browsers as possible.


    1 - By acceptable, I means programs that do what they're supposed to do, have no unacceptable problems, and fulfill the requirements of the person who gave you the task in the first place, whether instructor, manager, author, or client.

    2 - Yes, I'm trying to be vague. It's an attempt to protect the original presenter, who has accomplished much. I don't want my disgreement with certain points in that single presentation to take away from his other accomplishments.

Re: A peek at the other side or, Poof and He's Gone!
by stefan k (Curate) on Oct 22, 2001 at 17:47 UTC
    I don't want to break your happiness with Java (probably that isn't possible at the moment - at that is good if it's your job to code in Java *grin*), but I don't get the point.

    Have you not been in contact with other OO languages before? Other than C++ that is. I mean, exceptions are not really new, they are available in many languages and passing them up the stack is just normal, I think.

    Using a very OO-like syntax for calling methods of objects like in your second example is quite common, too. At least as far as I know.
    And then one could demand that Java shall be able to make the concatenation by adding strings together with the plus operator just the same call as the one to .append (but maybe there are reasons for that that I don't know -actually this is just a sidekick).

    Java is a hype-oriented language but it doesn't mean that it sucks like hell, so one should expect that some things are fine in Java.

    OK, I admit: I have never coded any real life project in Java, I just did some tutorials and a course in a magazine. I found out I didn't like it, but that's no reason for me to go cursing it. In the last weeks I spent a lot of time in Ruby and it was fun (plus there is space for people new to the opensource scenery to make themselves known, because it is new ;-)). It's got exceptions and a very powerful string class, too (just as an example).

    Well, in every language it is possible to code badly and well. It's just a matter of how much you know about the internals of a language, how much you really need to care about performance and maybe how intuitive it is designed.

    Sorry for not feeling that enthusiastic, I hope you'll enjoy your coding in Java!

    PS: Hmm, while proofreading this post I somehow feel that I'm expressing myself quite clumsy; I hope you get my point.

    Regards... Stefan
    you begin bashing the string with a +42 regexp of confusion

(jeffa) Re: A peek at the other side or, Poof and He's Gone!
by jeffa (Bishop) on Oct 22, 2001 at 19:20 UTC
    Welcome back Mr. Nick!

    i am glad that you are thrilled about Java. i myself did the opposite, i came to Perl from Java. Personally, i would pick Perl any day of the week - but we all know that the correct choice is the 'right tool for the job'.

    My point is that i envy you, because even though i like Java, it tends to frustrate me, simply because there is usually a slicker way to do it in Perl. I came from a strong Object Oriented background, even though the department i graduated from treated C++ more like 'C with structs that just happen to be objects' than a true Object Oriented paradigm. Luckily, i had a great professor that showed me a little SmallTalk, and a another awesome professor that taught a Java elective course one summer. I fell in love with Java immediately.

    Then i saw Perl.

    Perl shattered every preconception i had about OO practices, in particular, the fact that some of those practices are more 'anal retentive' than they are productive.

    merlyn once told me that programming in Java after grokking Perl is like riding a motorcycle with training wheels. Now i understand.

    i guess my biggest gripe about Java is it is simply too wordy. Too many objects. Too many committees deciding what to call methods and which classes they belong. Don't get me wrong - i am not giving up on Java. i participate on JavaJunkies and i rather like seeing Sun moving in on Microsoft's pilliaged territory.

    i just like Perl better ;)

    jeffa minor grammar updates applied

      merlyn once told me that programming in Java after grokking Perl is like riding a motorcycle with training wheels.
      :) Excellent. I remember him saying that PHP is "training wheels without the bike"

      Perhaps Merlyn's Secret Uncovered! needs updating.

      Simon Flack ($code or die)
      $,=reverse'"ro_';s,$,\$,;s,$,lc ref sub{},e;$,
      =~y'_"' ';eval"die";print $_,lc substr$@,0,3;
Re: A peek at the other side or, Poof and He's Gone!
by drewbie (Chaplain) on Oct 23, 2001 at 01:31 UTC
    A little background on me first. I have little to no formal software training (ie college courses). I first began programming when HTML & Word macros got boring at my first web development job. :-) I have read many books, mostly perl but lately more on general concepts & design patterns. I think I'm a pretty darn good programmer, but there are others much better than me.

    That said, I am a perl junkie. I love perl. But at my last job my boss wanted me to learn Java, so I started reading. It was a good experience. While Java is too controlling for me, I really like the thought processes it forces you to have. You have to think OO, and design & develop accordingly. It forces you to design before you implement.

    Those processes have helped me be a better perl programmer. I can take the concepts that Java enforces, and turn them into Perl, where it is optional. I can definitely say that learning Java has helped me be a better programmer. It is easier for me to see the big picture, which makes the project that much better.

    Java (among other things) has helped me grow from just another hacker, into something vaguely resembling a software engineer by forcing me to learn programming concepts. These concepts are what distinguishes wanna-be's from true programmes. Every language has it's place. And every language you learn helps you to be a better programmer.

    Kudos to you mr. nick for finding such a cherry position!

    PS. It's rather ironic that Java Junkies is run on a perl-based engine. ;-)

Re: A peek at the other side or, Poof and He's Gone!
by scott (Chaplain) on Oct 22, 2001 at 18:13 UTC
      I'm wondering whether one has a list for all the languages and the related communities. Of course I checked the links on the EveryDevel-Page.
      I'd really be interested in similar communities for elisp, ruby and XML (plus maybe LaTeX, C/C++ and some relatives of XML like XSL(T)).

      Regards... Stefan
      you begin bashing the string with a +42 regexp of confusion

        I find this page a good starting point when I am looking for info on other languages.

        Simon Flack ($code or die)
        $,=reverse'"ro_';s,$,\$,;s,$,lc ref sub{},e;$,
        =~y'_"' ';eval"die";print $_,lc substr$@,0,3;
      I have :) There I am also mr.nick. Unfortunately, I haven't really posted anything there as it's MUCH quicker just to stick my head into my Guru's office and ask a question: he ALWAYS has an answer. And 99.9% of the time, it's the correct one.

      mr.nick ...

        perhaps your mentor would be interested in contributing his talents to Java Junkies :)
Re: A peek at the other side or, Poof and He's Gone!
by grinder (Bishop) on Oct 23, 2001 at 16:25 UTC

    Disclaimer: I have written one Java program in my career, (although I have read quite a few).

    Take this personal mistake that I made in a critical data path as an example:
    for (int i<0; i< array.size(); i++) { String result = "PR-" + array[i] + "-RD"; file.write(result); }

    I can safely say I wouldn't have made the i < array.size() error. I've seen this enough in various other languages to know to hoist the function call out of the loop construct.

    On the other hand, I'm pretty aghast at the way Java forces you to deal with string concatenation. There is always a trade-off between language purity and getting the job done. The Proper Way to do in Java is one that you are unlikely to determine all by yourself, even if you saw it in someone else's code.

    It seems to me that the Java language designers went too far down the purity route, rather than having the compiler do the right thing for you. That's not the best use of costly human time. Make the compiler do the grunt work. Even in C++, an awful lot of effort has gone into building compilers that optimise away intermediate copy constructors and what not. I am surprised that Java compilers are not up to the level that C++ compilers were any number of years ago.

    g r i n d e r
Re: A peek at the other side or, Poof and He's Gone!
by Anonymous Monk on Oct 26, 2001 at 01:48 UTC
    It's situations like the above that give Java a bad name.

    And it should. That's classic examples of the programmer doing stuff that the compiler should be doing.