On 1 Feb 2007, [EMAIL PROTECTED] wrote: > On 2/1/07, Uri Guttman <[EMAIL PROTECTED]> wrote:
> > perl modules can be more easily fixed and such. badly written c > > code is much harder to deal with. and with proper design (and not > > using half of cpan) you can do that in perl. but what would i know > > as i have already done that. :) stem is only 10k lines of code and > > does the equvilent of many more and much larger amounts of cpan > > code with more isolation, speed, clean code, cleaner apis and > > easier interconnectivity and scaling. this is due to an > > architectural design the aims for that. async is core including > > async flow control which is not easily done. > I've learned through experience to NEVER believe a developer's > claims about his own code. I'd be interested if you can point to a > community of people who have opted to use your code, succeeded > without your assistance, and are willing to back up your claims > about things like ease of use and scalability. I was curious about stem a while ago and looked into it. It's an OK framework that requires different design from the ground up. The problem with using it vs. something like mod_perl is that you're much more likely to run into unsolved problems. mod_perl deployments are probably 3 orders of magnitude more than stem. There's books, expertise, and modules available for mod_perl and not as much for stem. So from an entirely pragmatic, business-case view, stem is not a good choice unless you have a support contract or someone already experienced with stem on your staff. Note I'm not making software quality judgments. I'm only pointing out why a business might decide the risk of using stem is not worth the benefits it may offer, today. In the future this may change. As for the event loop vs. async argument, I'll say that there are few developers comfortable with async programming, maybe 5% of those I've met in a business setting. Most programmers simply write synchronous code because it's what they know, and it's easier to write and debug. So they don't look for async cores, they look for a simple environment that will give them a nice environment for the linear business/presentation logic. Technically async may be wonderful, but it's a hard sell. That's been my experience. pop @popcorn; $self->pass($mjbrooks, [EMAIL PROTECTED]); Ted _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
