Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • When I think of scrottie code, these are the characteristics that come to mind:

    • minimal (so that it can run on your old hardware)
    • concise (for its own sake)
    • unusual (...your penchant for coroutines and byte code manipulation comes to mind)

    When I think of Java code, I think it's:

    • bloated
    • wordy
    • normal (in the worst way possible)

    That's why I find it unusual that someone like you would find reasons to like Java. But if you like it, whatever.

    I know that you don't actually code in it that much

    • "I know that you don't actually code in it that much. ;-)"

      That's key. I can take lots of stuff in small doses, and enjoy it. Just not PHP.

      When writing Java, I used to use kaffe and jikes. Both are pretty small, and both are open source and support my old, slow hardware. jikes is extremely fast. kaffe only does 1.1ish or 1.2ish, but at the time you had to program down to that version anyway to support MS's fuxored Java version they distributed with IE. And then compared to Flash, which was barely progr
      • most Perl programmers would do well to spend some time ignoring the language itself and just concentrate on design.

        Hmm, I think of Perl programmers as actually focusing more on design than the Java I've seen. For a community that values TMTOWTDI, there sure is a lot of emphasis at times on making sure you do things the One True Best Way, which can be good for design. That's one reason I ask Perl programmers questions involving other languages.

        I, too, really like interfaces. :) Unfortunately the Java programmers I've dealt with never use them. :(

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
        • Hi jdavidb,

          You make some good points.

          There is a movement in the Perl community towards clean code (Perl::Critic). We collectively seem to have fallen in love with MVC frameworks. In trying to do things the right way, we obsess over decisions like Mason or Template::Toolkit.

          But, compared to the Java camp, we don't read about OODA. (We also don't read about project management methodologies, which is a good thing, IMO.) Rather than going out and buying _Design Patterns_ and _Refactoring: The Art of Improving the Quality of Existing Code_, we read and write fluffy half-assed, dumbed down articles. I could walk into a Perl shop and not see a copy of the actual books anywhere and walk into a Java shop and see a copy on nearly every desk. Those books were overhyped and trendy, but there are a lot of good books out there on OO design. My favorite is _Object Oriented Design Heuristics_. These things are something of a relic of a late 1980's or early-mid 1990's when C++ was unchalleneged for dominance in the application space, so it's not surprising that Java, which many see as the successor to C++, took over the appetitite for those books.

          So, there's a movement in the Perl community of wanting to do things the right way, and going through a lot of the motions, there's also a strong element of *only* going through the motions and missing the point at the same time. OODA is a big, complex, hard field. It would do us well to study it a bit rather than wave our hands, say, "oh, yeah, I've heard of that, I think we can do that"... like PHP programmers do when it comes to security. (Yes, PHP is my example of all that is evil and wrong and dangerously ignorant and bizarrely self confident.)

          It's good that when we're given specifications for a complex system, we sit down and kick out a simple version of it a matter of days. It's good that we go in try to clean up code. But we're singularly ineffectual at it -- we're as ineffectual at arcitecting something as Java programmers are at kicking out a prototype.

          All of this is opinion so it's hard to argue so the best I can do is try to illustrate my point with colorful language.

          -scott