Slashdot Mirror
MySQL and Perl for the Web
Craig Maloney writes "MySQL (love it or hate it) is one of the most popular databases for deploying websites. Perl (also love it or hate it) was almost synonymous with website programming. Arguably there are different choices for different needs in web development (PostgreSQL, PHP, Java, etc.), but there is no argument that if you are planning on putting together a website, using MySQL and Perl that MySQL & Perl for the Web will aid immensely in that development." Read on for the rest of Maloney's concise review of the book. While not new, he says it's still a valuable volume.
MySQL and Perl for the Web
author
Paul DuBois
pages
552
publisher
New Riders
rating
10
reviewer
Craig Maloney
ISBN
0735710546
summary
A clear, well written book for Perl and MySQL
Who is this book for? Developers looking for a quality book on Perl and database development should not pass this book up. While the title of this book is MySQL & Perl for the Web, it could have easily been called DBD/DBI & Perl for the Web. The SQL examples may or may not work with various databases, but the DBI interface code should remain the same. This book will also do well as a reference for experienced coders looking for well-crafted examples of web-based applications. What's good? The second chapter should be enough to get anyone up to speed with using Perl, DBI, CGI, Apache, and MySQL. After a brief introduction and configuration of MySQL and Apache, the author settles in to discuss coding DBI and Perl. The remainder of the chapter details the best practices for using Perl and DBI together. Near the end of the second chapter, the author creates a fully functional to-do list, demonstrating ways to add, update, and delete information from the database using Perl and DBI. Instead of taking small baby steps over many chapters, the author shows important concepts and best practices for those concepts quickly. Even seasoned (hardened?) programmers may learn new tricks or methodologies from the second chapter of this book.
Is that the end? Are we left with one very well written tutorial chapter? Thankfully, the rest of the book has plenty to offer. Subsequent chapters include:
- Improving performance with mod_perl
- Generating and processing forms
- Writing form-based applications
- Automating the form-handling process
- Performing searches
- Session management
- Security and privacy issues
- E-commerce applications
Each chapter is clearly written, with several examples used to demonstrate the concepts presented. The examples are clearly written, and the author makes the whole learning process enjoyable and fun. The examples range from a give-away contest (including a random drawing), an electronic greeting card program, polling programs, and a shopping cart program. Each of the examples is presented completely, but are introduced in pieces (subroutines, modules, etc.) The full source code is available from the author's website at http://www.kitebird.com/mysql-perl/
What's in it for me? MySQL & Perl for the Web is the book that Perl programmers on any project will wish The Other Guy had read. The examples are clear, the writing is engaging, and the code is maintainable. This is a practical book and should not be overlooked in any serious Perl programmer's library.You can purchase MySQL and Perl for the Web from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Currently working in a Java/JSP/Sybase-based web programming environment and I love it.
But, I will give perl it's props.
I often use it to prototype large projects. Despite most arguments for other languages, I will say that you can pump out perl code pretty fast and it does help when you need some mockups and basic functionality to sell a concept.
As there are already books such as Programming the Perl DBI and Web Development with Apache and Perl, is the niche that this book is trying to fill actually worth it? Would I be better off reading Writing CGI Applications with Perl and The Official Guide to Programming with CGI.pm?
Personally, I haven't read a single one of them, so I'd really love to know. (one of these days, I'll actually read the copy of Practical mod_perl that's been collecting dust on my shelf.)
Build it, and they will come^Hplain.
ASP's not a scripting language, it's a technology. The language in this implementation is PerlScript, which is pretty much - wait for it - Perl. You don't specify how this implementation of ASP makes PHP "look like a kids' [sic] toy" but I've used two implementations of ASP - ChiliSoft (now SunONE) and Microsoft's - and PHP compares very favourably to both. I'd be surprised if apache-asp differed significantly.
This is where the serious fun begins.
Perl is a superb scripting language for system coding, but...
Now with systems like Java Server Faces and Creator you can design a web form in a few seconds using a drag-and-drop designer, clip in some data validators, and visually design navigation through a complex website. A few more clicks and you have an single archive file that can be dropped into any J2EE application server, using any JDBC database on any platform.
You can design, code and test complex form-based web applications in minutes.. and all the tools are free.
So why would anyone want to hand-code all this in Perl?
Even more puzzling, given that Perl has a portable database interface, why restrict things to MySQL?
Frankly, if PHP outperformed mod_perl on your system it was probably because of mistakes in the Perl code. Even PHP boosters admit that mod_perl is faster, as in this talk from Yahoo.
Maybe so, but I still have trouble figuring out why MySQL is given so much credibility in the first place.
In the previous story about MySQL, I posted a comment asking what it actually did that other databases (including the also-free PostgreSQL) didn't do at least as well, or better. The main responses seemed to include:
The Windows build issue seems quite reasonable, but the other reasons imply that the main reason MySQL is so popular is simply due to lock-in. People use it because they have to, or because they're not familiar with the alternatives --- not necessarily because it's actually better for the task-at-hand.
Perhaps MySQL is such a common name that people haven't heard of better alternatives out there. Presumably the book that this story reviews, which gives it even more publicity, is yet another reason that someone might consider MySQL without even thinking about alternatives.
Can anyone tell me if I've missed anything, though? Besides the typical lock-in reasons for using MySQL, does it actually do anything better than other databases as any sort of killer feature?
If not, and if you're looking to start learning about a database and actually have a choice, it seems that you're much better off looking at an alternative database.... whether it be a free one such as Postgres, or one of the big ones such as Oracle or SQL Server. At the very least, you'd get a more reliable database than MySQL, a more portable database than MySQL, and even postgres (just as free) offers a wealth of additional -- often useful and important -- features such as stored procedures and more complete data integrity. You'll probably also become much more familiar with correct SQL syntax ... for what it's worth.
A few years later I re-wrote it from scratch with JSP/Servlets+MySQL
The difference, my friend, is the "few years", and not the tool. Your productivity improvement can be attributed to improvements in the IDEs, testing tools, frameworks, etc., which evolve over time.
Well first to the latter. You should check out the upcoming PHP 5 release, it will give you a glimpse of the type of easy Object Oriented Programming that I think is enough for the web. And PEAR is a nice library too, that is almost completetely object oriented.
.NET structure has not convinced me. Why is it such a Hype? Just because of Market percentages? Or is there really something I'm missing.
About ASP I just can say, that if you like being on the secure side of programming you cannot really use it. IIS is known for not being that secure, as it is working with MS, if you wanna keep your data to yourself. ASP is not meant to work with MySQL. The last time I tried doing that I just had headaches with it. So if I would have a very large project I would think of Java, but otherwise I prefer PHP than PERL. But I would never touch ASP. And this not mentioning all the MS licenses that would be needed to make it work.
The
Maybe you should qualify your statement with: PHP is faster than a perl script executed out of a /cgi-bin/ directory without any accelerators. You'll find benchmarks all over the place that will show you that mod_perl out performs php in most cases.
http://www.bagley.org/~doug/shootout/
This is old info but it does show that php's scripting engine has room for improvement.
Ultimately, when you consider the price of memory and processor speed, it doesn't really matter.
You may have this perception because people rarely use PHP code to do heavy lifting.
I would have to agree with you here. If you are going to compare speed of perl to speed of php, you have to compare the two doing the same thing.
Also, You cannot forget CPAN. The PHP folks will typically say something like, well we have PEAR. Unless PEAR has made some amazing strides in the last year or so, it is still no comparision to the massive body of code that CPAN provides.
-- john
Perl had to be adapted to web development
... to a PHP programmer yes.
No more so than any other language. PHP really doesn't count here... it's an HTML templating tool that was adapted to programming, which is why it's great for prototyping small web tools, but even at the medium-scale (e.g. PHPNuke/PostNuke) it's already cumbersome in the extreme (look at how many times those two projects have had to re-architect). Insofar as PHP is getting back to its roots and becoming Perl again, it's a good language.
If I were starting from scratch on a new Web-related project I might use PHP, but I would almost certainly treat it as a templating system only, and then write the back-end in Perl or Java depending on the platform. But that might just be that I've not explored TTK enough... I've heard very good things about it as a templating system.
it's significantly slower than php
No, no it's not. Running any kind of benchmark on real code it's not. When you integrate Perl poorly with a Web server, then it's slow. When you integrate it well (e.g. bricolage, TTK, Mason) it's quite reasonable, and VERY easy to develop in.
[PHP is] easier to understand and easier to program in
well
PHP is a Perl derivative in roughly the same way that Java is a C++ derivative. One's children always spend their youth claiming that their parents "did it all wrong", but as they grow and mature they find that their parents had gone through all of this before and that their decisions were not so very surprising after all. PHP has come a long way, and bravo to it, but let's not get hyperbolic.
Familiarity with perl (slashdot)
Were you using Slash as an example of something written by someone familliar with Perl or as an example of something one would be familliar with?
If the former, it probably should have been "Familiarity with Perl and PHP not having been written yet (Slashcode)"
I'm not sure I could agree, at least for pure web-based applications. The company I work for has a massive, modular, quasi-object oriented, web-based application that is written using mod_perl and XS. It totals over 300,000 lines of Perl code easily (lost track at this point) and is fairly easy to maintain since it's modular (designed to allow easy removal of pieces of system and have it respond accordingly).
The things that keep us using Perl are easy to identify:
1) very rapid development and even our non-C programmers "get it"
2) large existing codebase for reuse (CPAN)
3) excellence in text parsing and manipulation (which is most of what a web-based application does)
4) fairly easy to write low-level code (XS, which is just C code with lots of macros) for performance-intensive areas and interface it with high-level code (Perl)
5) easy to interface with existing C libraries by writing an interface stub
6) large community of support
7) easy to do object oriented programming where it makes sense
8) no worries about memory management
9) mature platform (Apache, etc.)
It's not all daisies and roses obviously. PHP is not an option for us, at least until 5 matures (PHP4 didn't have namespace support and a few other things we wanted at last check). We also need our code to work outside of a web-based environment where Apache doesn't exist, and at that moment that rules out several other languages.
I'd be glad to hear of alternatives that allow one codebase for a server-side web-based application that also runs from the server command line when needed and can meet the above criteria that work under Linux based environments.
I freelance professionally with both perl and php. I like them both. Perl is my first language. I find that it's easier for me to use php when I'm using techniques I already know, and it's easier for me to use perl when I'm learning new techniques. php has a way of penalizing you for experimenting, it's kind of inscrutable in terms of doing what you'd expect. Perl is great that way. But when you know exactly what you're doing, php is cleaner.
If you're the kind of coder that has an urge to make things complicated, then perl is better. But I find that as I get more experienced and senior level, that I aim more towards making my code as simple and elegant as possible. I aim towards frameworks rather than applications with a lot of anticipated features. You want the application layer (in MVC terms, the control layer) to be as thin as possible. I find that I rarely need to even do things like subclass other classes. A lot of highly competent but inexperienced programmers tend to overengineer things, make too many layers of interface, use too much API, write utilities to write other utilities, get stuck in meta-land. It's like the people that declare that they can't use anything that can't do multiple inheritance. It's silly.
All you need to do is just get the job done without coding yourself into a box. Design, design, design. Architecture, architecture, architecture. You can make six figures with a solid understanding of MVC. The language choice doesn't really matter all that much. You'd be surprised how much syntax I don't have memorized. You'd be surprised how little code I write. And I can still get a lot better - I'm only started to work with Class::DBI. I'm only starting to work with php 5.
skkkoooonnnggggkkk ptui