in reply to Re^14: Data Structures
in thread Data Structures

Was that a personal dig? Never mind.

Not at all, IIRC you and I have had debates/discussions about this before. And I know you have debated this with nothingmuch too. Would you classify yourself as not performance obsessed? Maybe obsessed is too strong a word for you, but you get my point.

No, not a dig at all, I would have been much more snide and condescending if was going for that ;)

Many applications are performance intensive (cpu-bound, data-bound), rather than IO-bound. And indeed, cpu-intensive applications are exactly the ones which most benefit from OO ...

Well, any application over a given size benefits from OO (or some similar modularization construct). I would argue that CPU-intensive applications while maybe benefiting from the encapsulation and modularization bits of OO would not benefit from the heavy abstraction of OO (boxed types, etc). It is also worth pointing out that languages like Java, C++ and even Ocaml/Haskell have the benefit of optimizing compilers and no need for runtime type information due to static analysis. It is very easy for the compiler (at compile time) to remove lots of information that would otherwise slow down an application. It is not so easy for a dynamic language like Perl (or Python, or Ruby) to do this. The real point being, there is always trade-offs and language choice is one place you make those trade-offs. If my application is cpu-bound then I would likely not use Perl (or at least not 100% Perl) simply because I would have to make too many compromises for performance and not be able to use nice things like OOP.

And, on the basis of my limited exploration of Moose guts, I truly believe that it wouldn't take a huge effort to reduce the performance penalty for using it to the point where it wouldn't have to advertise itself as for "non-performance critical applications only". It might require the dropping of a few Holy Cows though.

Want a commit bit? I am open to thoughts about dropping cows and such.

-stvn

Replies are listed 'Best First'.
Re^16: Data Structures
by BrowserUk (Patriarch) on May 24, 2008 at 06:15 UTC

    That the very reason for choosing tos' Rubix Cube. As bad as the code is,

    1. It is already, 95% or more OO structured.

      And none of the places where it breaks from good (in the Perl 5 roll-your-own standard of) OO mechanisms, are done for performance reasons. Just because tos didn't know how to achieve what he needed using those OO techniques, and wanted to get on with writing his application.

      If he could have let some framework do the OO bit of it, the rest is just fine.

    2. It demonstrates that it is quite possible to write this kind of app using Perl.

      Right now. No C. No Java. No convoluted low-level optimisations. Just very ordinary Perl, that's (sort-of) OO to boot.

      No need to go learn another language. No need to give up all the things we all love about using Perl. Not even the need to resort to (and have to learn) Inline::C or PDL or anything else. It runs at a more than acceptable redraw rate. If only the OO were cleaner...

    C'est la vie.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.