On Wed, Sep 16, 2009 at 8:15 PM, Steven Siebert <smsi...@gmail.com> wrote: > I would also add, in addition to the frameworks, the availability of tools > such as Netbeans and Eclipse IDE's are unmatched in the perl domain. These > IDE's provide many high-level conveniences for enterprise developers, most > notably in the realm of SOA (such as graphical building of BPEL and CEP).
Emacs, Vim, Komodo, and others are equally as capable in the Perl domain. What you don't have as much of in the Perl domain is the commercial support for those tools, with the exception of ActiveState. I just pulled down the latest copy of Komodo and took it for a spin; though however many times I try out the GUI based editors I end up going back to cli based tools because they are so much more performant when you've been using them a while and have customized them for your particular needs. I don't doubt there is more support for service oriented architectures with Java based IDEs, as Java tends to be a preferable language for medium and large sized development teams which are easier for larger entities to support. Factors such as productivity per individual developer are less important with a large team. > After nearly 10 years building and maintaining a critical government system, > we are sadly migrating away from mod_perl to a J2EE based solution due to > the success and growth of our mod_perl-based system. mod_perl and MySQL has > served as well when we were taking on medium-to-large loads...however, as we I think this is a natural progression of successful applications. The development needs of a large established system are different than those of a fast growing application. Large systems tend to have more management levels involved, and development speed and scalability are no longer bottlenecks - external systems and compliance tend to be higher priority, and that takes less code writing and more coordination between stakeholders. > Add to this Jeff's comment on the availability of high caliber perl > engineers...we are almost forced to make this decision. Maybe you aren't looking in the right places: http://jobs.perl.org YAPC::* This email list The Perl Mongers groups Dice, Craigslist, Monster, etc. are great places to find Java programmers but bad places to find Perl programmers. In Silicon Valley, you can usually shake a tree and a couple of Java programmers will fall out.. ;) > > We will continue to use mod_perl for other uses, such as our custom SCM/ALM > system we built over the years...but the main product is migrating. > > > On Wed, Sep 16, 2009 at 10:47 PM, Jeff Nokes <jeff_no...@yahoo.com> wrote: >> >> Doesn't Amazon run mod_perl/Mason? >> >> BTW, I agree with most of your points (would debate #4,5). I may >> substitute the phrase "More convenient" for "Easier" in #3. I would also >> add ... >> >> #7) How many engineers are available to hire that know or want to work >> with said technology? >> >> I built a great platform at eBay on mod_perl/Mason that handled eBay-size >> traffic; we ran 6 eBay sites on it. Now it is used for specialty e-commerce >> solutions like worldofgood.ebay.com, global.ebay.com (cross-border trade), >> dealfinder.ebay.com, etc. In fact, on the same hardware, the main eBay Java >> app would support ~6 threads per box; the mod_perl platform supported ~60 >> (prefork), significant CapEx and power savings (which adds up at a place >> like eBay). >> >> >> >> ________________________________ >> From: Brad Van Sickle <bvs7...@gmail.com> >> To: mod_perl list <modperl@perl.apache.org> >> Sent: Wednesday, September 16, 2009 3:31:30 PM >> Subject: Re: Why people not using mod_perl >> >> >> >> This is a mod_perl list, so I would expect to see Perl championed pretty >> heavily, but Java, .net and there ilk are undoubtedly *the* choice for large >> web applications. I'd like to get into some discussion as to why almost all >> *large* sites choose these languages. >> >> I don't have any experience developing a large application in Java, >> although I do have a lot of experience working on the operations side of a >> large web application that is Java based. >> >> The reasons I generally hear for choosing Java over mod_perl are: >> >> 1) Speed - I don't buy this at all >> 2) Maintainability - I think this makes sense. Perl can be pretty easy to >> maintain if you stick a good framework around it, but you have to seek out >> that framework and YOU are responsible for adhereing to it. All of that is >> inherent in Java. It also helps that Java has OO built in. >> 3) Easier to package and build/move code - In my experience this is true. >> 4) Advantages to be gained from running on an actually application server >> - Also valid >> 5) Compatible enterprise class middleware - Also true, Java plugs into >> more truly enterprise level suff than Perl does. (security frameworks, >> etc... ) >> 6) Support >> >> A lot of the industry seems look at Perl as obsolete technology that has >> been replaced by *insert hot new technology of the week here* which is a >> total shame. I've worked with a lot of technologies and I think Perl is a >> great choice for small/medium websites and webapps, which is probably what >> most of us work on. But I'm very interested to know at what point (if any) >> a site/app grows too large or too complex for mod_perl and what defines that >> turning point. Could Amazon run on mod_perl for example? >> >> >> >> >> Phil Carmody wrote: >> >> --- On Thu, 9/17/09, Igor Chudov <ichu...@gmail.com> wrote: >> >> >> My site algebra.com is about 80,000 >> lines of mod_perl code. >> >> I wrote a relatively large framework, with many homegrown >> perl modules, about five years ago. >> >> >> It uses a database, image generation modules, a big >> mathematical engine that I wrote (that "shows >> work", unlike popular third party packages), etc. >> >> >> All pages of my site are dynamic and it is very image heavy >> >> >> due to math formulae. >> >> I can say two things: >> >> 1) It is relatively fast, serving pages in 0.1 seconds or >> so >> >> 2) Despite the quantity of code, and its age, it is still >> very maintainable and understandable (to me). >> >> >> >> >> In that case, would you like to fix its mangled output? >> >> e.g. >> http://www.algebra.com/algebra/homework/divisibility/Prime_factorization_algorithm.wikipedia >> >> >> >>   (Redirected from Prime factorization algorithm) >> >> faster than O((1+ε)b) for all positive ε >> >> an integer M with 1 ≤ M ≤ N >> >> Pollard's p − 1 algorithm >> >> Section 4.5.4: Factoring into Primes, pp. 379–417. >> >> >> >> Chapter 5: Exponential Factoring Algorithms, pp. 191–226. Chapter 6: >> Subexponential Factoring Algorithms, pp. 227–284. Section 7.4: Elliptic >> curve method, pp. 301–313. >> >> Eric W. Weisstein, “RSA-640 Factored†>> >> >> >> v • d • e >> >> AKS · APR · Ballie–PSW · ECPP · Fermat · Lucas · Lucas–Lehmer · >> Lucas–Lehmer–Riesel · Proth's theorem · Pépin's · >> Solovay–Strassen · Miller–Rabin · Trial division >> >> Sieve of Atkin · Sieve of Eratosthenes · Sieve of Sundaram · Wheel >> factorization >> >> >> >> CFRAC · Dixon's · ECM · Euler's · Pollard's rho · P − 1 · P + 1 · >> QS · GNFS · SNFS · rational sieve · Fermat's · Shanks' square forms · >> Trial division · Shor's >> >> Ancient Egyptian multiplication · Aryabhata · Binary GCD · Chakravala >> · Euclidean · Extended Euclidean · integer relation algorithm · integer >> square root · Modular exponentiation · Schoof's · Shanks-Tonelli >> >> >> >> >> >> Looks like you've got utf8 and iso8859-1 messed up. >> >> Phil >> >> >> >> >> >> >
