Re^13: Data Structures

Your argument against Sub::Exporter does not make sense to me, it seems as if you are saying that I should only provide as much features as my user base uses and that the extra bits inside Sub::Exporter that I am not using are slowing me down. To start with Moose is not a simple one-size-fits-all module, some people use it as a simple accessor generator and base.pm replacement, but others use it as a full fledged metaprogramming system and hit on edge cases I never even imagined to exist. Now, very few people have taken advantage of the extra bits that Sub::Exporter adds, basically anyone who has done what is described in the "EXTENDING AND EMBEDDING MOOSE" section of the Moose POD. However, that said I do not think that providing a broken (Exporter) or minimal (hand-coded to the exact spec) would be a superior solution, it would only mean then when people wanted/needed those extra features I would have to add them or say "no sorry I used Exporter and it sucks to bad" or "Well it will take me a while to add that to my hand-coded solution". Sure you can make an argument for speed, but not all of us are as speed obsessed as you seem to be. Perl is getting faster (the Moose and Class::MOP test suites both run noticably faster in 5.10) and computers in general are getting faster (the argument that Moores law has a ceiling really doesnt apply to this specifically so lets not go there). You can also make an argument for "extra dependencies", but honestly I dont see the problem with dependencies. If we were coding Python and this was 3-4 years ago and there was no decent module repository and dependency management tool, or better yet, if we were coding Java today,.. then I could understand that argument. But we have CPAN, and despite the number of problems it has, the benefits of it far outweigh them. There is (IMO of course) absolutely no excuse for not using the CPAN as much as possible. This is not to say that people shouldnt re-invent wheels, I think that is an excellent way to learn and grow as a programmer, and if you wheel is better then please upload it. But anyway, I digress, and honestly I think we will have to agree to disagree on many of these points.

It's minimal, just enough to meet the requirements of the challenge, but I hope it is enough to show that much of what Moose does, could be met without large dependency chains, and rather more efficiently. (Especially once you drop the need for bondage and discipline!)

Hmm, not really, not really at all. Where is the MOP? Method modifiers? Roles? And what about types? You call it B&D, but really its much more about sanity checking, if you have only ever used the strong type systems of Java/C++/C#/Ada then I would understand your dislike, but if you explored the more superior type systems that are offered in ML/Haskell/OCaml, then you would feel differently I suspect. Again, seems here that you are advocating only providing as many features as you need for a given usage. This may create efficient code with minimal dependencies, but this does not promote generic re-usable solutions. Sure, this can be your choice in the trade-off, but it is not mine.

Hmm,.. I am almost starting to think you have a background in embedded systems or something, given this obsession with efficient code that can run in a small space with few dependencies.

I guess that sums up my feelings about a lot of this kind of module. (Sub::Exporter et al.) At their core, they provide a single, useful mechanism. But then, almost inevitably, they feel the need to add to that basic mechanism a bunch of "fun tricks", which whilst fun, often aren't required by most of their users

I disagree completely on this with regard to Sub::Exporter, every feature that it provides is useful and well thought out. I know for a fact that RJBS uses a good portion of them in his $work code too, they are not just "fun tricks". I suggest you give this set of slides a look, he goes over a lot of what Sub::Exporter can do and where it is useful.

Again, it seems your only looking at the surface features and what the top layer provides and not digging deeper to see the possibilities. I believe that modules like Sub::Exporter and Moose are "disruptive" modules, meaning they force you to stop and rethink previously held assumptions and ways of doing things. Just as Moose is helping to rid the Perl world of hackish DIY-OO programming, so too could Sub::Exporter be used to fix some really ugly and horrid code in some other modules (I wish I had the time to show an example of this, perhaps I will at some point).

If you are really up for a challenge?

No thanks, the code looks like a mess and I am not really in the mood to detangle that. If you want to clean it up and port it to Moose I will be glad to work with you in making sure it is as Moosey as it can possibly be.

But the results would make for a very good demonstration of the power of Moose.

I totally disagree, this is a performance intensive application, and Moose has well known performance issues. If I didn't know better I would think you were stacking the deck against Moose here ;)

-stvn

Comment on Re^13: Data Structures

Replies are listed 'Best First'.
Re^14: Data Structures by BrowserUk (Patriarch) on May 23, 2008 at 23:07 UTC
not all of us are as speed obsessed as you seem to be. Was that a personal dig? Never mind. IO-bound programs are essentially event-driven. That means state machines, which virtually precludes good encapsulation, or even good abstraction. 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. That's why so many of the graphic simulations of cpu-intensive algorithms (from sorts to searches to the travelling salesman and other NP=hard problems), are written in Java. OO allows the mechanics of the graphics simulation to be separated (encapsulated) from the mechanics of the algorithms being simulated. The algorithm is just coded to operate on an extended data-structure (eg. a subclassed array or hash) and the internals of the enhanced DS take care of displaying the effects of the algorithmic actions upon that DS. Perl is getting faster (the Moose and Class::MOP test suites both run noticeably faster in 5.10) Perl is getting faster, because they (p5p) optimise for performance. Because they realise that the performance of their code impacts the performance of every piece of code built on top of it. Perl deserves to have the power and completeness of the OO-implementation that Moose gives them, so that Perl users can get on with the business of writing their applications instead of reinventing the OO wheel each time around. That's what impresses me about Moose. The clear, clean (and in its basic form, simple) interface to a complex infrastructure that can do pretty much anything that is required. You can start out writing just as much code as you need to get the application running with a few 'has this' and 'has that' and 'extends something else' for each of your classes, and then get right on with writing the detail of the application using those classes. Once you have the application running, you can go back and enhance the classes to parameter typing, pre- & post- contracting, introspection and all the other good stuff required to make it robust. But you can prototype it quickly without all the frills and and if you have to scrap it and start again (that's what prototypes are for!), then you haven't needed to expend effort adding the frills before you found out whether it was going to work. That's what really impresses me about Moose. The ability to get something going quickly without have to cross every T and dot every I, safe in the knowledge you can go back and add the frills as and when you need them. But... Any library that sits at the core of other peoples applications, like Perl itself, should do its utmost to impose as few performance penalties as possible. I think people writing cpu-intensive applications (like tos) deserve Moose (or something very similar to it). Then they could get on with the business of writing their applications and not re-inventing OO mechanisms (badly!). 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. I totally disagree, this is a performance intensive application, and Moose has well known performance issues. Graphical apps like tos' are only one of a whole range of non-IO-bound applications that would really benefit from a sound, extensible, thorough but essentially simple (interface-wise) OO-framework like Moose. And given the obvious skill-levels and motivation of the Moose team, it's my belief that it could be Moose, if the motivation was there to make it so. Anyway, I'll get off your case now. Congratulations on what you've already achieved with Moose. 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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^15: Data Structures by stvn (Monsignor) on May 24, 2008 at 04:28 UTC
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	[reply]
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, 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. 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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l]