Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^2: On the scaleability of Perl Development Practices

by jdrago_999 (Hermit)
on Aug 18, 2008 at 15:39 UTC ( [id://704961]=note: print w/replies, xml ) Need Help??


in reply to Re: On the scaleability of Perl Development Practices
in thread On the scaleability of Perl Development Practices

Why do there have to be winners?
Well, each option is a "winner" for some reason (otherwise it might not have been written).

Having options is great - having some way to qualify those options based on our current needs is even better.

If we have (just throwing numbers out there):
  • 25 web frameworks
  • 10 ORM layers
  • 6 Charting/Graphing libraries
  • 5 Email-sending modules
And I need to build a website that allows users to sign-up to receive daily sales data charts in graphic format, I have 25 * 10 * 6 * 5 options. That's 7500 possible options, and that kind of site is not exactly complicated.

I don't know about you, but I haven't tried all 7500 possible combinations to know which works best. What I think works fine could really stink. I could really be missing out on something great, and not even know it.

If we had some kind of objective means of qualifying the many modules and how well they work together, that would be great. I don't expect (or want) to see Perl end up with a J2EE/.Net FCL-style "Your Way Is Inevitable. You will be assimilated" One True Way of doing anything.

Having solved just about every problem there is with Perl, I think we should (as a community) be able to find some way to rate combinations of modules and techniques as they apply to the various problems out there.

Maybe a kind of "create-a-combination" tool that then allows you to vote on it. If someone else has already created a combination identical to yours, you just go to that combination instead. Similar combinations would be displayed near one another. It would lend context to the huge array of options we have, and allow the community to quickly ascertain the group opinion of a specific combination of modules. Things like "What worked?" "What didn't work?" "What issues arose?" and so on.

An idea anyways.

Replies are listed 'Best First'.
Re^3: On the scaleability of Perl Development Practices
by talexb (Chancellor) on Aug 18, 2008 at 16:02 UTC
      • 25 web frameworks
      • 10 ORM layers
      • 6 Charting/Graphing libraries
      • 5 Email-sending modules

    Sounds like you need to create a survey (Survey Monkey comes to mind) and ask people to take it. But why ask people for their opinions when you experience may not be the same as theirs?

    I know I was keen to use an ORM interface to my database and spend a week trying to wrap my brain around Class::DBI. I hung out on IRC, asked all sorts of stupid questions and got nowhere, so decided to stick with just writing my own queries and commands instead of doing database stuff programmatically.

    I also tried using CGI::Application about 6-7 years ago and couldn't figure it out, but gave it another shot two years back and it worked out great.

    On the other hand, I've used Template Toolkit for half a dozen years and think it's fantastic. As long as it stays up to date, I won't need any other templating library.

    But those are my experiences, and they reflect my own strengths and weaknesses. You probably have different experiences, so my choices won't necessarily match with yours. So even doing a survey of what everyone uses won't help you -- you need to figure out what works for you.

    And don't think about needing to pick one of 7500 choices -- look at each piece individually. Being as this is Perl, it's pretty likely that your best choice for each part will work fine with your other choices.

    Really, I think you're over-thinking this whole thing. Pick some tools that you're comfortable with and Just Do It.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re^3: On the scaleability of Perl Development Practices
by mr_mischief (Monsignor) on Aug 18, 2008 at 16:47 UTC
    I don't know about you, but I haven't tried all 7500 possible combinations to know which works best. What I think works fine could really stink. I could really be missing out on something great, and not even know it.
    You don't need to find 7500 ways that work. You need to find one way that works well enough. If it's fast enough to develop, easy enough to maintain, and scales well enough in production then your problem is solved.

    One of the first things you learn in an economics class is the importance of opportunity costs. There is always a different way to spend your money or your time. The most important lesson about opportunity costs, though, is not that you must be perfectly methodical in your evaluation of them. The most important thing about opportunity costs is that if you spend all your time trying to figure out how to spend your time and money, then you'll have no time or money to spend and will never spend it on anything useful anyway.

    Pick which trade-offs are acceptable to you and which ones are not. Then, be prepared to actually make a decision and follow it through. If you find you can't complete a task reasonably well with what you've chosen the first time, that's an expense. It's probably a smaller expense than never making the decision because you were still studying the options when it was time to act.

    More information would be nice, and there have been numerous metadiscussions about the module selection process here already. However, this is not a perfect world and we often must act with incomplete or even inaccurate information. There's a large middle ground between acting too hastily and acting too cautiously. Try to find that middle ground, because that's where things get accomplished.

Re^3: On the scaleability of Perl Development Practices
by oknow (Chaplain) on Aug 18, 2008 at 21:20 UTC
    And I need to build a website that allows users to sign-up to receive daily sales data charts in graphic format, I have 25 * 10 * 6 * 5 options. That's 7500 possible options, and that kind of site is not exactly complicated.

    It is more than a little disingenuous to say that you need to test anywhere near 7500 combinations of modules to find out which ones work well together. For the most part, all you have to do is pick the module in each of the four categories that works best for you.

    How do you know which individual components to choose from the vast choices? I'd start with modules I've used in the past, asking friends and colleagues for advice, and then searching the internet/perlmonks for discussions on the same topic. If those options fail, then it is time to get my hands dirty and start trudging through CPAN. Thankfully, when there are 126 Config:: modules there tend to be a lot of people with opinions of a small subset of them.

    Having solved just about every problem there is with Perl, I think we should (as a community) be able to find some way to rate combinations of modules and techniques as they apply to the various problems out there.

    Have you actually had this problem a lot in practice? I don't think I have ever looked into using a module that didn't explicitly state in the documentation that it was made to operate with other particular modules.

    This particular problem seems to be the exception and not the rule. I've never been bitten by it. I can't think of anyone I know telling me they'd been bitten by it, and I think you're the first person I have seen mention it at all.

    Maybe a kind of "create-a-combination" tool that then allows you to vote on it. If someone else has already created a combination identical to yours, you just go to that combination instead.

    You would end up with a vast number of positive votes in this system. You'd be better off having people submit just the combinations that are more difficult to use together. Otherwise we'd just end up with a bunch of noise saying Data::Dumper plays well with damn near everything :).

    Oknow
Re^3: On the scaleability of Perl Development Practices
by phaylon (Curate) on Aug 19, 2008 at 12:07 UTC

    I think you're tackling the problem from the wrong side. You seem to want "I need to write $project_site, what combination of @template_systems, @database_layers, @web_frameworks will do the job best?"

    I think it is much better to start by analyzing your project, what it needs, where it needs to go now, and where in the future. If you want to write, for example, a bulletin board, most template systems will work fine for that. But if you know you want extensibility, lots of plugins, and much view functionality in the templates, you might want to start looking at Template-Toolkit rather than HTML-Template. If you want to build a bulletin board thats easy to customize for non-Coders, and don't need any fancy features in the templates itself, I'd go to HTML-Template.

    That's why I am usually not interested in surveys or lists of modules people prefer in general. It all needs context. In my experience you can learn a lot by looking at successful projects, their dependencies, and how they use them. And most Perl projects I know are happy to answer "So, you guys used $foo for your project, I'm thinking about using it for $bar, so I'd like to hear how it worked out for you" questions.


    Ordinary morality is for ordinary people. -- Aleister Crowley

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://704961]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (9)
As of 2024-03-28 18:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found