Slashdot Mirror
E-commerce with mod_perl and Apache
rob_99 writes: "Cool new mod_perl article at perl.com documents building a large scale ecommerce solution w/ mod_perl & apache!" Pretty cool stuff - it's kind of funny to think how ephemeral their work turned out to be.
Having built numerous e-commerce sites and even worked on a commercial shopping cart written entirely in Perl, I can't say that I think it's the best choice. It's great if the job is small; it's quick to code, is installed on almost all hosting providers, and so forth. But for large projects the code becomes very difficult to manage, mainly because getting people to write clean Perl code is difficult.
.xs version of the Perl client which wrapped around our C library. This has proven to be much easier to maintain.
There's a second downside: lack of good SSL networking. SSL is critical for credit card processing. I ported the GPL version of TCLink for Perl, and we ran into a lot of problems due to lack of a standard SSL library. For the first version of the client we ended up distributing a patched version of Net::SSLeay which added all of the certificate authentication functions we needed (and are missing from the standard install of Net::SSLeay). Later this became such a headache for the various platforms we were trying to support that we just coded a
Long story short: sure, Perl's great. Is it the best choice for e-commerce? I'm not so sure.
So in your opinion, nobody is allowed to do anything while "The souls of the victims are watching"?
How are people supposed to move on from this tradgedy if they cant do anything to take their minds off it?
Anyway to get ON TOPIC, perl is a great language to write this sort of thing in. I prefer using Embedded Perl myself (i wonder how that would perform as an ecommerce solution.).
but perl IMHO is the most powerful and versatile CGI language around, java creates too much of a load, and C requires you to recompile after altering any of the code.
ok im rambling now..
when everything is working perfectly.. BREAK SOMETHING before something else FUCKS up!
It seems like the primary (note /.'ers, I said PRIMARY, not your little pet project :) ) use for mod_perl is to avoid the overhead associated with loading modules.
It seems like the better choice would be to avoid using modules altogether. Or using another language like C or PHP that has stuff built-in. It's amazing how much CPU time loading a simple perl module takes.
Comparing performance between mod_perl, servlets or even asp is pretty fair... My preference is still for the java solution because i like the variety in VMs and there's some nice (and some bad... think back to classloader issues with the pre-2.1 servlet spec; ejb-jar interdependencies...) tools that are forced upon you with j2ee.
This article drives home a very good point: sound architectural design is what makes a complex system work. If you know what the big picture looks like, you can fill in the details whichever way suits you.
Object Oriented Perl is extremely powerful and flexible. It's possible to do exotic things like multiple dispatch, it *does* support true encapsulation, and you can change inheritance hierarchies at run time. I've seen people write first-class objects and classes (think Self), and I've implemented mixins having seen them in Ruby. You can use all sorts of design patterns, have compile time member checking, and even modify objects as the code is running. There are even good reasons to use multiple inheritance (Perl's not the kind of language that thinks it's smarter than you.)
If you mean "member data tends to be class based instead of object based", then you're right. That's a true limitation of OO Perl. It would also be nice to have a refactoring browser like Smalltalk has.
As for readability, I can't read anything written with Kanji characters. That doesn't mean I'll ever claim it's "unmaintainable compared to English". (To be fair, complex data structure dereferencing *can be* hard to read in Perl.)
how to invest, a novice's guide
http://software.tangent.org/projects.pl?view=mod_l ayout
Were that I say, pancakes?
If you're problem is even moderately interesting, there will be no out-of-the-box solutions. That Open Source might require more implementation time may be true, but the "turn-key" fantasy is most always a lie.
Using Perl as opposed to, say, Java or C++, is like using Emacs as opposed to Notepad.
You can learn Notepad lickety split. You'll get alot more done if you know neither and have to get something done in a single day.
But over the long haul, you'd be far better off using Emacs.
Perl (and Python) are the same way: If you turn a bunch of inexperienced coders loose with no oversight and no structure, you'll get crap. But if you have a team of experienced Perl programmers, they will beat the pants off of any team of, say, C++ developers in terms of development time any day of the week.
Not to detract from C++. I am simply saying that the languages are used for different things, and that poor code follows from poor coding standards and practices, inexperience, and unorganized minds.
So if you can't write Perl without seeing spaghetti, I would suggest you have either some learning to do or that you need more discipline in your coding practices.
-- My choice of computing platform is a symbol of my individuality and belief in personal freedom.
They wrote a small piece in C++ because it was the right tool for the job. They wrote the rest in Perl because it was the right tool for the job.
If the whole thing was written in C++, they would probably still be coding the basic application.
When your needs are to get an application to market quickly, there are few languages that can compete with Perl.
If you question the scalability of Perl, I would challenge you to write a complex web application in any language that would handle 200,000 sessions and 2.5 million page views per hour.
-- My choice of computing platform is a symbol of my individuality and belief in personal freedom.
Maintainable yes...
Which is it? Write-only, or maintainable? My guess is maintainable, because I have never once heard one with a solid understanding of regular expressions state that perl is "write only".
Warning: This signature may offend some viewers.
Like the subject says, you should be safe in your career. After all, you know The One True Programming Language, right? Perl isn't a toy, though, is it? I mean, if it's functionally equivalent with Ruby or PHP in all respects then it must be worth something, right? (Just don't let those interpreted guys into the Compiled Officer's Club... they might tell wild stories about getting lots of work done really quickly or spread notions about non-compiled languages being the right tool for the job...)
Seriously (or maybe not), perhaps you could check your OO bigotry at Dr. Dobbs door when you come slumming it in Scripting Land? I know some of us started using Perl before a "real" language like C++ or Java, but that doesn't make us unable to learn that real language, does it? Does it mean that we won't be able to get real work done? Are the sites we work on less useful to you?
Why would you look down on someome who has started out with Perl? I started out in the computing world using BASIC on my VIC-20. I didn't have the luxury of Java or C++. Do you think I can still learn? Am I worthy? Can I evolve to your level? Will I ever be able to look down my OO nose at mere scripters like you do? Can I be effete?
Ok, sorry to bait you. I use perl as much as I use shell scripts. I no longer use BASIC or Pascal and I'm glad. Quick and dirty GUI apps in C and C++ are a pipe dream -- Java works very well for that (especially when your app has to very quickly work on everything from BSD to WinNT). But I hate to break it to you: I have no CS eductation. The only CS course I ever took I wound up teaching. Should I resign from my job? Am I doing my company a disservice by "trying" to write OO Java apps for them since I don't have a "real CS education"? Are the OO perl apps I've written even OO enough to get me in the club? Are my C apps more portable than my lack of education? Are my Java apps?
You should realize that your "real" CS education bought you knowledge, but not at the expense of anyone else's abilities. Software Engineering is not a zero-sum game; we can all play without dimishing the accomplishments of others. But if you need to feel important, then I guess your post is like therapy for you or something...
Life is too short to be a snob.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Why? Business and partnering. Not technical. When the CEO was in meetings with possible partners and said "MySQL" when asked about our database, he got wrinkled noses and confused looks (mys..what?) in response. When he said "but we are migrating to Oracle," the result were ohhhss and hhhhhaaaa. Sigh.
Once the technical team got into Oracle, they liked it and started to use various features that MySQL didn't support (at the time). I can remember doing rollbacks more than once while handjamming SQL code before a demo.
Nonetheless, I think we all remain MySQL fans.
Because just like Apache/Perl or JSP/Servlets, PHP etc. ASP can also be an adequate environment for large-scale solutions if someone with enough experience is using it. If you throw enough brains and money on a problem set, you're bound to get a good answer, no matter which technology is used (unless it has some fundamental deficiencies, of course).
As far as the article is concerned - I doubt that more than the top 1% of experienced Perl programmers could build anything like that...
"I love my job, but I hate talking to people like you" (Freddie Mercury)
Ok, I'm going to try you on this. Reason is, I've written fairly serious server code in Java, and didn't use many "application server" facilities, because I didn't see the advantage.
Container managed persistance
Far as I can tell, this saves you writing some trivial SQL statements. Plus, as soon as you have any interesting data (ie, not just one row in a table) or performance needs (this is backed up by benchmarks by an experienced app-server user), container manager persistence is impractical anyway, so you have to learn how to do it yourself.
transactional support
Unless you have some exotic need, a transactional data store is the beginning and the end of the solution.
message queues
Easily implemented over an SQL database (I wrote some pseudo-code, but it's too hard to format in slashdot).
naming and lookup services
I know Java has some facilities for this, but what do they do that's not easy with LDAP or similar?
Integration with existing business objects and processes?
You'd be surprised how many of these are already in Perl. :-) That aside, most of this means accessing an SQL database. I mean, sure, Java will integrate better with a Java shop and other Java software, if that's important.
They pulled off clustering
Pretty easy with a remote data store.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
[quote]so only non-CS folk will persue perl as a primary language.[/quote]
I earned a Bachelor of Science in Computer Science, which I received in May after completing four years of computer science coursework in a CS department that was focused on the OO development model. We did most of our advanced development in C++, so I got plenty of exposure to that. I learned it well enough to get satisfactory marks (mind you, I didn't get perfect marks, but I at least showed that I could use what I was learning).
Now? I am working at a large e-commerce company, developing website/database functionality in Perl. Perl is my primary language. In fact, including me, five out of the six developers in my department earned their BSCS at the same college. We all program in Perl. We also write a lot of modules to encapsulate functionality for our site, and write/use them in an OO manner. Some of us are not as crazy about OO as others, but we all use it. We have certainly never 'looked down upon' Perl.
Except for this...
To be fair, complex data structure dereferencing *can be* hard to read in Perl.
Yes, but(tm)... In the context of OO, you should never have to dereference a complex data structure. You shouldn't have to know a dang thing about the structure.
Regardless, I've found people squawking about the "write only" feature of Perl all share a common feature amongst themselves. None of them write Perl.
Go figgure.
--
You sure got a purty mouth...
I wrote the C++ daemon. The question here is not "Perl is scalable" or "C++ is scalable". The question is "is the site scalable"? Use the correct tool for the job. Without boring you with too many details, the search engine kept two large in-memory indices. A perl script (best tool for the job) extracted the search data from the database, built the indices, wrote to a file. The C++ server read the file (in about 7 seconds) in was serving away. Why C++? It was easier (for me) because I had more C++ experience than Perl and I prefered the ability to share the index in a threaded environment. I would have been much harder to write the database extraction and Index build in C++, and much harder (for me) to write the daemon in Perl. The right tool for the right programmer for the right job. An aside: I have just finished my first Java/JSP project. While the java solution was nice, I found the Perl solution easier because of the nicer syntax for hashes and Template Toolkit is awesome.
If you are just selling products in a plain way, you can get simple enough e-commerce. But if you want to provide good e-commerce that ties in with other content, again there are no out-of-the-box solutions. Also, you have to be happy with a out-of-the-box appearance, where you get to control a few graphics and colors on the page, but the essential layout is fixed. It's usually (but not always) pretty easy to change layout -- but that's still not really out-of-the-box.