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
          • You can hardly invoke the “stay out of my livingroom not because I have a shotgun” argument to justify writing a God Object.

            But you don’t need mandatory controls if you’re writing a God object either. You won’t understand the need for them until you try to do good OO design, just like a ten-liner can be written without strictures too. Access controls are just another aspect of the sort of design you are talking about.

            It makes me sick to be associated with a language where

            • Quick recap.

              1. I argued that Perl programmers could benefit from some time spent on OO design, and give thought to things like interfaces and which objects can see which other objects.

              2. You object on the grounds that Perl doesn't need forced encapsulation.

              3. I clarify that at no point in that point did I argue for forced encapsulation (though I did at another point, but at that point, I was talking about something else). I restate that, ignoring enforced encapsulation, Perl programmers don't do nearly as

              • Every now and then, I post a disclaimer on my blog, saying that I will be extremely mean to anyone who doesn't follow the house rules. I know I can't impose them, but I can be quite mean. So, please don't do certain things on my blog. But first I ask people to go away. Aristotle [sic] made it to this point and continued on, all the while acting oblivious.

                This isn't a discussion of whether Perl programmers could benefit from learning more about OO design as it was traditionally taught in the late 80's and early 90's. We (meaning this particular reader) seems to have skipped that point and fixed himself on whether Java is doing anything right or better, concluded that that would be impossible and that life wouldn't be worth living if that's the case, and decided that, by extension, the related comment must be faulty.

                There are a few easy things to do in this case. You see them on blog comments all the time. Those who will stop at no length to perpetuate fallicies repeat them endlessly.

                I already mentioned starting with the conclusion and deeming the argument (in the traditional sense) invalid based on the conclusion (I don't agree with your conclusion so your logic *must* be wrong!, or, the answer couldn't possibily be three! Check the equation again!).

                Another of them is silently translating one argument into an invalid one. If I reference something related to OO and Java, it must also be invalid, just like the "Perl doesn't need forced encapsulation" idea. Even if I made it clear from the onset that I wasn't referencing forced encapsulation in any way. Even if I come back and reiterate in a clarification.

                Another approach these weenies use is just steadfastly continuing on in their invalid argument even as their fallicies are pointed out.

                To repeat from my rules for posting in my blog, there are correct (yes, logic is a field of study -- "Aristotle" should know that) ways to argue. You can challenge the premises. If a premise turns out to be false, the conclusion is meaningless. The other way is to point out logical errors. Again, logic has been formalized. Writing out an argument in formal notation will clearly reveal logic errors.

                Aristotle has chosen to attack the conclusion, not any premise. And rather than argue the validity of the logic, he introduces inferences of his own, which are invalid, and argues them (the straw man argument). No, that point had nothing to do with forced encapsulation.

                Aristotle [sic] is a weenie who argues for the point of arguing, or the glory of being right. There is no room in my blog for people like him. Here, we have productive conversations that explore topics and broaden our knowledge -- except when we have to counter attack weenies.