Slash Boxes
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.
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
      • It’s not the least bit out of place to worry about which classes can see which other classes and what kind of interfaces they’re presenting for each other.

        Yah [].

        • No, actually... I intentionally avoided discussion of private, protected, public etc because of this essay. I said "interfaces" and "which classes can see each other", which is in reference not to hiding bits of themselves but simply who has references to who and what the basic topology of the application is. You can hardly invoke the "stay out of my livingroom not because I have a shotgun" argument to justify writing a God Object. Sometimes strong typing makes sense; aside from that, large projects need
          • Since you often complain about people failing to address the actual argument, I opted to moved all the incidental but off-topic quibbles to a second reply so they don’t get in the way of my real response.

            Anyway, I wanted to nitpick the following statements:

            Interfaces are a way of keeping straight

            I don’t like interfaces in particular. As seen in Java, they fall out of a confusion and conflation of language design goals. Traits/roles are a much superior concept.

            But even as far as interfac

            • Alright, that was slightly better than I had hoped for but I'm unswayed with regards to whether I want to talk to you.

              My comment was that Perl programmers should spend more time worrying about interfaces and the structure of the code; your retort was that interfaces are poorly implemented and Perl 6's traits and roles are better. That's great... but it's also completely off topic. The point wasn't "Java is better than Perl". That wasn't even the title of the essay. It seems to be a conclusion you slipped in just so you could (easily) dispute it. Your remark has nothing to do with whether Perl programmers would do well to consider interfaces, spend more time on design, or why I like Java. The discussion has nothing to do with language features at all -- at least that part of it.

              Let's recap that one real quick. Recapping again, but quickly this time. Perl programmers should spend more time on interface design. You're saying, no Perl programmers shouldn't (actually you're not even being man enough to give me such a conclusion so I know when I've invalidated it) because Java's implementation of interfaces is somehow subpar. Think about that for a minute. That's laughably irrelavent. It's terrible that this kind of randomness passes for discussion anywhere than in front of the TV when the bong is out.

              "I’ve found that designing in the abstract is of limited use." -- aha! That's at least on topic, though probably by accident. Okay, so Perl programmers don't need to spend more time on design because time spent on design is wasted, to paraphrase you (and when someone paraphrases you, you can argue with the correctness of it thought I wouldn't make it a strategy in general). I asserted that Perl programmers do. I could argue it. But I don't want to. Throwing one away and refactoring but not reading books in favor of reading fluffy articles might be adequate. In my experience (which is not valid as a premise), it isn't adequate, and I won't speculate why. Or maybe one of my premises is the well supported opinion that code written in Perl is terrible.

              They, let's run with that for a second. The world at large believes that code written in Perl is terrible. I have a survey that strongly supports this [premise]. Input B: Perl programmers can write good code. Either B is false or else Perl is a terrible language that ruins attempts to write good code in it. Which is it?

              This stopped being interesting a long time ago. I hope you feel the same way and leave.


              • My comment was that Perl programmers should spend more time worrying about interfaces and the structure of the code

                Which I agreed with. And in the same breath I pointed to one of my posts in another place where I say that Perl programmers chanting “we prefer politeness not shotguns” is misguided, which I think of as being a sign of the same immaturity.

                That’s great… but it’s also completely off topic.

                Wow, you found the start of my post (where I said all therein was just