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.

Comments

Web, schmeb

[jargoone]

Perl (also love it or hate it) was almost synonymous with website programming.

Love Perl for most anything, hate it for web "programming". There's a good reason it was synonymous with website programming. It's because there now exist more flexible, robust, easy-to-use platforms for web development.

Re:Web, schmeb

[wawannem]

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.

Re:Web, schmeb

[zerocool^]

Thank you, that was my immediate first reaction. Perl is a regexp manipulation language first, and very well suited for a variety of other tasks, other than web development. But, for webdev, there are many other languages that have been developed since perl that are much better.

Perl had to be adapted to web development, and it still suffers from various problems (for example, it's significantly slower than php). Php was written to be a web processing language. It's easier to understand and easier to program in, and faster. The only reasons to use perl over PHP for web development are 1.) familiarity with perl (slashdot), and 2.) security (to avoid "today's php upload root exploit").

~Will

Re:Web, schmeb

[DAldredge]

Please support you statement that Perl is slower than php.

Re:Web, schmeb

[hotfries]

I call bullshit on the PHP is faster part:

http://www.chamas.com/bench/#2000

Re:Web, schmeb

[Anonymous Coward]

Check out this book on PHP and MySQL intergration by David Lane, one of my favorite new O'Reilly writers.

Re:Web, schmeb

[zerocool^]

?? Support your inferrence that perl is faster than PHP?

I don't have hard numbers, but I have been in environments where both are used, and perl seems to perform much worse. Specifically, I administer ~100 webservers, and clients that use more php put far less of a load on the system than people writing in perl scripts executed through web pages or mod_perl. In multiple years of working with both, perl just has become synonymous with higher system load.

The load jumps related to PHP that I see are always MySQL based loads.

~Will

Re:Web, schmeb

[Mr. Neutron]

Besides, why use Perl with MySQL when PHP exists? Isn't PHP designed around MySQL? I haven't used it, but it can't possibly be as painful as Perl.

One time for kicks I wrote a small bulletin-board engine in Perl+MySQL. A few years later I re-wrote it from scratch with JSP/Servlets+MySQL. Guess which took an order of magnitude less development time? :-)

Re:Web, schmeb

[DebianRcksLindowsLie]

Perl DEFINITELY has its uses. You've just got to use the right tool for the right job. There are good tools out there, just use the right tool in the right place.

Re:Web, schmeb

[Etyenne]

It well-known indeed that the plural of anecdote is data.

Re:Web, schmeb

[Anonymous Coward]

there now exist more flexible, robust, easy-to-use platforms for web development

Indeed. I have done some simple scripting in Perl, but unless you already use it day in and day out and are comfortable with the syntax, there's not much incentive to use it for Web programming.

PHP is relatively easy to learn and does most anything you would need to do for basic Web development. Is there anything Perl can do that PHP can't?

Re:Web, schmeb

[skiflyer]

Perhaps I'm not reading the graphs right, but more requests per second is better correct?

If so, PHP beats Perl on every graph except one, where they tie... and it has better memory utilization too... or am I way off on how I'm reading these?

Either way, they're both pretty close on that specific benchmark, I don't think I'd consider it proof of much of anything.

Re:Web, schmeb

[zerocool^]

I call bullshit on your link:

While there are some numbers here available for your review, benchmarking does not provide a real world assessment for any application operating in a specific real world scenario, and this does not try to demonstrate any proof that any system is better than any other.

Not to mention that, in those graphs, perl occasionally handles more requests per second than PHP, but almost ALWAYS has higher system load, and in many applications is SIGNIFICANTLY slower than PHP. For instance, who runs mod_perl on a webserver without a LOT of those modules added in (when you add stuff like Mason, Image::Magick, DBD::MySQL, it makes mod perl slower!).

Take another look at that graph, and average all of the perl instances versus the one PHP instance that they have listed, and compare the speed and requests per second.

~Will

Re:Web, schmeb

[consumer]

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.

Re:Web, schmeb

[Anonymous Coward]

Perhaps that is because people are doing complex things with perl while the PHP users are doing this:

<?PHP echo 'Welcome to my leet haxoring page, you have been ownzored' ?>
<?PHP header("Location: http://www.goatse.cx/") ?>

Re:Web, schmeb

[consumer]

Simply using modules does not make mod_perl slower. There is no performance overhead for just loading them. A program that does things will take longer than a program that does nothing, but that's just as true for PHP.

Re:Web, schmeb

[Anonymous Coward]

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.

Re:Web, schmeb

[zerocool^]

Possibly, but, in my world, you have to take that into account. You can't just say "properly written perl is faster". It might be; however, it is just as important that badly written perl brings a server to its knees, while PHP seems to fail gracefully.

I'm honestly not trying to sing the praises of PHP, I'm just trying to point out that a LOT of system load of computers I deal with is due to perl code. I didn't write the code, so I don't know the specifics of how good/bad it is, but I'm just making a general comment: When I see system load due to web serving, the first thing I go check on is if the person is using perl.

~Will

Re:Web, schmeb

[Anonymous Coward]

Of course it's a benchmark, and it doesn't take in to account all the complex variables in a live environment.

But: the mod_perl handler results (mod_perl 2000), which many would argue is best-practice for a mod_perl application beats PHP in requests per second (951.6 vs 651.7), AND uses less memory.

I'd say that refutes your simplistic assertion that PHP is faster than perl

Re:Web, schmeb

[sporty]

No. perl is not a regexp manip language. The regular expression stuff is a subset of it, just like the data structures and what not.

Saying that perl had to be addapted to web development is just wrong. perl also, is not slower than php. Perl is a VERY modular language. You can do traditional CGI programming in it, just like php. There are many templating options as well as mod_perl, which more resembles java servlets than it does php.

Also, stating that it's clearer means nothing. At least with DBI, i know how to connect to any database. With php, there's a seperate function to open a connection to the database, per vendor. Their function names are quite conveluded, switching orders of word types, i.e. noun_verb vs verb_noun.

PHP is built for the web first, and is a programming language second.

Re:Web, schmeb

[Anonymous Coward]

Isn't PHP designed around MySQL? I haven't used it, but it can't possibly be as painful as Perl.

Do you really have to talk about something you don't know?
What are the moderators doing?

Re:Web, schmeb

[daperdan]

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.

Re:Web, schmeb

[consumer]

You may have this perception because people rarely use PHP code to do heavy lifting. Or it may be that you've encountered many servers where people were actually running code as CGI, not mod_perl. CGI is slow.

Regardless, I have never seen a benchmark where PHP ran faster than mod_perl, and for the most part, performance differences between them are negligible compared to the performance differences resulting from well-written code vs. poorly-written code.

Re:Web, schmeb

[abirdman]

Damn, that's a beautiful post! I'm in tears laughing. Bravo. Not only have you tossed an asbestos blanket over the smoldering flame war, but did it with some humor.

Thanks.

Re:Web, schmeb

[ajs]

Perl had to be adapted to web development

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 ... to a PHP programmer yes.

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)"

Re:Web, schmeb

[ajs]

clients that use more php put far less of a load on the system than people writing in perl scripts...

Well there you have it. Treat Perl like a scripting language and you get what you deserve.

Check out TTK, Mason or bricolage. I think you'll find that writing very low-footprint, scalabale applications is as easy in Perl as it is in many languages, and moreso than most. The problem arises when you get someone who doesn't even understand what a stateless system's likely bottlenecks will be trying to write complex code. In that case, yes, PHP protects you to a certain extent, but in doing so, it vastly limits the options of those who DO know what they're doing!

Re:Web, schmeb

[eviltypeguy]

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.

Re:Web, schmeb

[Doyle]

In multiple years of working with both, perl just has become synonymous with higher system load.

Here are some benchmarks you might find interesting. Particularly:

The results of PHP were not what we expected. Being exposed to the hype that rules on the Internet about PHP, we expected it to be at least at the second place. It did not scale well (see BENCH4) and exhausted system processing power when it run, leaving it unusable. We must admit that PHP is tightly linked to MySQL, which was not how we used it, but it is our belief that a fast system can be fast irrelevant its environment.

You can see from the graphs that mod_perl performs way better than PHP on the whole, and places less load on the server than PHP. They were not using MySQL.

Re:Web, schmeb

[next1]

maybe you've just learnt more in a few years and know java better than Perl.

i program in Perl and am currently learning Java. so far, i can't see it being just quicker overall for web development.

Re:Web, schmeb

[Anonymous Coward]

Also, stating that it's clearer means nothing. At least with DBI, i know how to connect to any database. With php, there's a seperate function to open a connection to the database, per vendor.

There are several mature choices to interface with databases in PHP. I am about to begin a task on a PHP program where the goal is to migrate from our home-grown API that interfaces with a text file database to one of the more established interfaces like PEAR DB (which I believe now comes with standard PHP installations).

I should point out that when you need a web application, you may want a language built for the web first. I'm not very familiar with Perl but I suspect that a web-based product could generally be developed faster using PHP. In this environment, money is what counts, not how your programming language was designed.

Re:Web, schmeb

[SphericalCrusher]

I've never been much into Perl myself when I was large into website design, because I never really saw how it could do more for me than PHP could.

For me, PHP, HTML, MySQL, and Photoshop are the Kings of website design. Maybe I should write a book... ha.

Re:Web, schmeb

[Mr. Neutron]

What are the moderators doing?

Modding as Flamebait any comment that disparages Perl.

Re:Web, schmeb

[next1]

depends what you mean by more flexible. One of the reasons my company uses Perl for web apps is because the apps have a front-end (web) and a back-end (shell) component.
In Perl we can have the shell and the web applications both sharing the same code, which is a perfect example of Perl's flexibility.

It would be possible to do the same thing with java and probably PHP as well by running a standalone version or something, but Perl is perfectly suited to the task.

Re:Web, schmeb

[Anonymous Coward]

At least get your coding straight. Sending headers after page content will result in a 'headers already sent error'!!

Re:Web, schmeb

[Anonymous Coward]

Yes, all my friends told me that.

Re:Web, schmeb

[trewornan]

Take a look at the great language shootout. It depends what you're doing of course but my general impression from the figures supplied here is - PERL is significantly faster than PHP for most algorithms. There are a myriad of entirely reasonable criticisms you can make of PERL, I don't think this is one of them though.

Re:Web, schmeb

[eyeye]

Its sheer ignorance for you to say that perl is slower than PHP. Perhaps you should get the book reviewed here and look at the ways to run perl persistently or with the web server (as php does).

Re:Web, schmeb

[eyeye]

That is because most web programming is done by people who dont know what they are doing. If perl came with mod_perl as the default setup you wouldnt see higher system loads than with PHP.

You are one of those retarded admins that dont allow perl because it "uses too much system resources" arent you... get a clue.

Re:Web, schmeb

[FilthCatcher]

With php, there's a seperate function to open a connection to the database, per vendor.

Not if you use PEAR.

Re:Web, schmeb

[sporty]

Yeah, it requires your developers to nto be total noobs.

Re:Web, schmeb

[redtux1]

How about - It works!!

Three cheers for LAMP

[Neil Blender]

Linux, Apache, Mysql, and Perl. They changed the world forever.

Re:Three cheers for LAMP

[scragz]

I thought that was supposed to be 'P' for 'PHP'.

Re:Three cheers for LAMP

[rainman_bc]

the P in LAMP stands for PHP not Perl. PHP and MySQL are a perfect fit. Perl and Mysql are a real PITA.

Re:Three cheers for LAMP

[crass751]

I learned all I needed to know about Perl and MySQL from the Perl Cookbook. I wrote a whole DB interface in CGI. It wasn't that hard. Once I learned the few commands necessary, it was really easy. I agree though, PHP is even easier.

Re:Three cheers for LAMP

[Anonymous Coward]

Nonsense. The P is for Perl, Python or PHP.

http://www.onlamp.com/pub/a/onlamp/2001/01/25/lamp .html

Re:Three cheers for LAMP

[Monkey Angst]

Hitler also changed the world forever. What's your point?

How the hell do you Godwin a thread about a Perl book?

Re:Three cheers for LAMP

[Anonymous Coward]

Goodwin and his 'laws' are worse than Hitler ever was.

Re:Three cheers for LAMP

[Anonymous Coward]

Why you nazi bastard! I'll Hitler you and Hitler you good!

Re:Three cheers for LAMP

[rainman_bc]

even better? I mean, You can run Apache, MySQL, PHP on windows.

And hey, you can run PHP over IIS

And hey, Sybase runs on Windows and Linux.

So under O'Reily's premise, Lamp can mean whatever the hell you want? Isn't that a pretty retarded acronym then? LAMP=Linux, Apache, MySQL, PHP. Nothing more. Not a big deal, but still, at least it has a definition. Per O'reilly it can mean whatever you want it to mean. That's just stupid.

AFAIK, O'Reilly didn't coin the term LAMP. They're just bastardizing it.

Re:Three cheers for LAMP

[glwtta]

PHP and MySQL are a perfect fit. Perl and Mysql are a real PITA.

Meaning that PHP is a real PITA - couldn't agree more. :)

Re:Three cheers for LAMP

[deque_alpha]

the P in LAMP stands for PHP not Perl.

Actually, both are equally valid and recognized, and LAMP is often broken out as Linux - Apache - MySQL - perl/PHP. The P stood for perl first though.

Re:Three cheers for LAMP

[Anonymous Coward]

RTFA. O'Reilly doesn't claim to have coined the term.

It also doesn't mention IIS or Windows or Sybase.

Re:Three cheers for LAMP

[SCHecklerX]

So abstract the Mysql stuff in your own perl module. Here are some examples of what is necessary to grab data in my own web code:

$db = initialize('dbauth');
#'dbauth' is a file with all of the database/authentication information for the restricted web account

($category, $categories) = selectquery($db, "select ID, name from sport order by name");
#returns a reference to an array, and the number of elements in the array

($mindate) = singlerow($db, "select min(date) from event");
#returns an array with values from a query that results in a single row of data

etc.

There are also functions for submitting data, which are also one-line functions. None of the extra setup necessary.

Combine this with Apache::DBI, and you have a persistent database connection that does not get torn down between every query.

What is so hard about that?

Re:Three cheers for LAMP

[Anonymous Coward]

Except you really meant to type Linux, Apache, MySQL and PHP.

Re:Three cheers for LAMP

[ACPosterChild]

pretty well, apparently!

Italics..

[Anonymous Coward]

..isn't meant to be used for whole paragraphs, because it is hard to read.

Good!

[JaxWeb]

I find there are a lot of books and resources which each Perl, or teach SQL, but don't teach you how to use Perl, or use SQL. For example, it is perfectly possible to read a book, learn Perl, and not be able to actually use it for anything useful (in regard to websites). Not many books that I've seen have addresses this. My personal knowledge of Perl for use in webpages is scraped together. Perldoc.com helps a lot, however. Books like this seem useful as a starting ground. PHP is gaining a lot of ground on PHP (It's overtaken it, I hear). This may be because it is more suited to suited to web development, or it may be more because all it does is web development: As soon as you know PHP, you know how to make a website using PHP. Most Slashdot readers will be past this point in learning a language I should imagine, so, without reading anymore than this book review, I might suggest it wouldn't be worth buying, but this is certainly the sort of book which should be on the bookselves in shops. A lot more helpful than 101 books about how to use IOSTREAMs in C++.

Re:Good!

[rainman_bc]

PHP is gaining a lot of ground on PHP (It's overtaken it, I hear).

PHP is gaining ground on PHP?

Sounds like it's the leader if it's gaining on itself :)

Re:Good!

[Anonymous Coward]

Where did you cut and paste this from?

Re:Good!

[JaxWeb]

I find there are a lot of books and resources which each Perl, or teach SQL, but don't teach you how to use Perl, or use SQL.

For example, it is perfectly possible to read a book, learn Perl, and not be able to actually use it for anything useful (in regard to websites). Not many books that I've seen have addresses this. My personal knowledge of Perl for use in webpages is scraped together.

Perldoc.com helps a lot, however. Books like this seem useful as a starting ground.

PHP is gaining a lot of ground on PHP (It's overtaken it, I hear). This may be because it is more suited to suited to web development, or it may be more because all it does is web development: As soon as you know PHP, you know how to make a website using PHP.

Most Slashdot readers will be past this point in learning a language I should imagine, so, without reading anymore than this book review, I might suggest it wouldn't be worth buying, but this is certainly the sort of book which should be on the bookselves in shops. A lot more helpful than 101 books about how to use IOSTREAMs in C++.

(This is a repost with correct HTML... why didn't I pressed Preview? :D)

Re:Good!

[Anonymous Coward]

All bold is just as unreadable as all italics.

Re:Good!

[wawannem]

How about a book on using HTML? Pay close attention to the chapter on closing your tags.

Re:Good!

[Daniel Dvorkin]

I find there are a lot of books and resources which each HTML, or teach Slashdot posting, but don't teach you how to close your HTML tags, or use the Preview button ...

Oh, hell, you know the rest. ;)

Re:Good!

[JaxWeb]

Yes. I'm an idiot. Fair point.

I really, really should had pressed Preview. I was thinking about clicking preview, but I thought, "Nah, I'm not going to make a mistake with HTML am I?"... I forgot about those things called line breaks...

JaxWeb (Score: -1, Retarded)

Re:Good!

[wawannem]

Glad you can take it without insulting me right back... I'll give you credit though, it is *Monday*

Re:Good!

[Anonymous Coward]

Perhaps you need to preview for correct content as well. :) Did you mean "PHP is gaining a lot of ground on Perl"?

As far as books on how to use Perl or SQL, there are tons of them, especially SQL that has been around forever. I've found one good way to learn how to use a language is to look at other people's code. Go to your favorite open source website and search for applications similar to yours, that use the same technology. Copy these applications, read them and learn from them, especially from their mistakes.

Re:Good!

[mrdogi]

I find there are a lot of books and resources which each HTML

as you say...

Re:Good!

[Daniel Dvorkin]

Heh. Read the original post carefully. ;)

Re:guffaw

[Neil Blender]

"Website programming".

Tee-hee. I still laugh when I see that phrase.

Heh, not every website is a 50 line PHP hack made by a kid. You can do extremely powerful things with a website and those things can require complex programming skills. And that programming can be done in Perl.

Huh?

[Anonymous Coward]

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

Translation please?

Re:Huh?

[stratjakt]

It translates roughly to this (my dingbat is rusty, please forgive me);

Blah blah blah buzzword buzzword buzzword spacefiller spacefiller blah blah this submission is now longer.

Re:Huh?

[Anonymous Coward]

but there is no argument that if you are planning on putting together a website using MySQL and Perl, MySQL & Perl for the Web will aid immensely in that development.

Re:Huh?

[Decaff]

there is no argument that... using MySQL and Perl will aid immensely in that development

Translation: either ignorance or flamebait.

You don't use phrases like 'no argument' without expecting an argument.

Re:Huh?

[Anonymous Coward]

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

Re:Huh?

[Anonymous Coward]

"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"

Translation: Reading a book about MySQL and Perl if you are programming in MySQL and Perl will probably be helpful.

See how much the context changes when you read all the words. Do you happen to work for Fox News?

Re:Huh?

[slagish666]

"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"

Translation please?

The book would be helpful in creating a website.

Perl is very flexible

[Anonymous Coward]

It could be programmed to tell you when you forget a closing tag.

Perl / MySQL CMS solution.

[Archangel Michael]

I have been using a MySQL / Perl solution called WebGUI for quite a while
now. It is a full CMS system that is truly open source and cross
platform, running on *nix, Windows and MacOS.

It truly is powerful yet very easy to use. Plenty of features such as Submissions system, Bulletin Board, Calendar, Syndicated Content and much more.

If you are looking for such a solution, feel free to give it a try.

Italic

[Anonymous Coward]

Does the whole thing have to appear like this?

I used to use Perl until..

[Anonymous Coward]

I discovered PHP. It just seems to be such a natural language when it come to designing a dynamic website.

If you're familiar with DBI...

[tcopeland]

...and you've got a Ruby app to write, you'll be happy to know that Ruby/DBI is available.

It's being actively developed - a FrontBase release just happened a few days ago - and it supports a big list of databases.

Re:If you're familiar with DBI...

[Anonymous Coward]

For once Tom Copeland isn't measuring how good code is with his cute little app, and he's presented useful information to me!

This is TOTALLY on topic. Thanks, Tom!

Re:If you're familiar with DBI...

[tcopeland]

> For once

Be not dismayed, I'll go back to my old ways as soon as an opportunity presents itself...

> Thanks, Tom!

You're welcome - but why would you post such a devastating retort as an AC? Unmask thyself, forsooth!

I'm going to have to get my copy..

[Metallic Matty]

This will be an excellent addition to the O'Reilly books on Perl I already have.

The whole love or hate thing in the article intrigues me I might add. I love both MySQL and Perl. Why? Well, you can't beat MySQL for its cheapness facor. Let's face it, most people don't need some professional job, myself included. And as far as Perl goes, well, anyone who's used it significantly can understand how great it is for practical answers on the fly.

Re:I'm going to have to get my copy..

[Unordained]

Well, you can't beat MySQL for its cheapness facor. Let's face it, most people don't need some professional job, myself included.

By that, do you mean most people don't need more features, as in PostgreSQL and Firebird? Both are free (in fact, more free, if you consider MySQL's licensing requirements for businesses) ... and both are supported by interface layers like jdbc/odbc, as well as perl, php, and so forth ...

I used to enjoy coding in Perl…

[Anonymous Coward]

...until I discovered poking myself with a sharp stick.

Re:I used to enjoy coding in Perl…

[Anonymous Coward]

You know you've been coding in Perl too long when...

• It starts to look like line noise.
• You start copying line noise into your perl scripts.
• The scripts still work.

old book?

[inf0c0m]

does anyone else realize that this book is exteremly old?

Paperback, August 2001

also.... on the same bn site

A new copy is not available from Barnes & Noble.com at this time.

Re:old book?

[Anonymous Coward]

Yes. did YOU realize that the last sentance in the article summary was

"While not new, he says it's still a valuable volume"?

Pathologically Eclectic Rubbish Lister

[IO ERROR]

Yes, that's what it stands for, but don't tell anybody.

I love perl for what it was designed to do: process text in just about any way imaginable. I hate it for the purpose proposed here: CGI scripts.

I usually use PHP for Web pages, a mixture of PHP, Perl and Bourne shell (and whatever else is at hand) for the back end, and I wouldn't touch MySQL for a database if my life depended on it, when there are vastly superior OSS altrernatives available.

Re:Pathologically Eclectic Rubbish Lister

[Daniel Dvorkin]

I can think of nothing more likely to start a flamewar on /. than singing the praises of Perl and MySQL in the same story.

<1/2 g>

Re:Pathologically Eclectic Rubbish Lister

[Etyenne]

I was expecting the Python zealots to overwhelm this discussion with their usual snobbism of Perl, but for some reasons the PHP fanboys are the one making the most noise. It will be interesting to see where this will lead.

Re:Pathologically Eclectic Rubbish Lister

[reptilex]

You are probably right about MySQL, but last I looked it was the easyiest way. I'm working on a pretty large Project and I have come to see the downsides of MySQL, altough its not about ACID Im talking, but almost all of those times, the easynes with which I can manage the DB is more important than not heaving them. And this is mostly because of PHPMYadmin, I found a similar Project for PostgreSQL but it wasn't nearly as good as PHPMyAdmin is for MySql. How do you manage?

Re:Pathologically Eclectic Rubbish Lister

[archen]

Maybe if you made a Perl based web front end for a MySQL of all your Ogg Vorbis songs on Windows2003/IIS?

Re:Pathologically Eclectic Rubbish Lister

[jadavis]

phpPgAdmin is available, although perhaps that's what you already tried.

Also, there's pgAdmin III which is a nice database tool, but it's not web based.

Personally I just use psql, which is command line, but I understand a lot of people don't like to work with a database that way.

Re:Pathologically Eclectic Rubbish Lister

[Anonymous Coward]

Actually we Python Zealots have better things than to spout off. We're out there writing actual code instead of talking about it.

Python is a mature language with obvious advantages and huge power. We don't feel the need to step down and talk about other languages. We know we're faster, cleaner, smaller, more powerful and all around better at everything so really why would we step into this? We've proven our points with all the charts and graphs of benchmarks regarded with high esteem. We don't need to fight with Perl and PHP anymore, we've got our sights set on enterprise programming now. Java watch your back. SsSsSsSsSsSsSs

Obligatory links for people who want to know more about Python.
www.python.org
www.zope.com
www.zope.or g

Re:guffaw

[Anonymous Coward]

I still laugh when I see nerds trying to make themselves feel better by downplaying the skills of others. At the end of the day, although you state using Perl or PHP to generate dynamic webpages isn't programming in order to feel satisfied, you're still a nerd, and most people programming webpages are cooler than you. And you know it. nslookup that, nerd.

One whole chapter?

[oneiros27]

Even seasoned (hardened?) programmers may learn new tricks or methodologies from the second chapter of this book.

I don't know about you, but one whole chapter seems to be little reason to purchase a book.

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.)

Re:guffaw

[Daniel Dvorkin]

Yes. The Web (love it or hate it) is the preferred platform for delivering ... well, just about everything that goes over a network, these days. The days when "website programming" meant throwing together some 1337 Javascript hack to make your personal site flashier and more irritating than everyone else's are long gone, and they're not coming back. For some reason, this seems to bother some people; I'm not sure why.

are the plainblack docs still non-free?

[jbellis]

pretty extreme example of writing free software and charging for "services." I'm probably not the only one who didn't bother looking closer after seeing that.

Re:are the plainblack docs still non-free?

[Anonymous Coward]

It includes installation instructions, online help, and has a free community bulletin board.

There is no cost to evaluate it because they have a free hosted demo system that lets you create your own personalized website for a time (not sure how long)... but long enough to determine if it has what you need.

There is an e-book they charge for. $50.00. No major cost. The developers charge for answers to support questions within 24 hours. Nothing wrong with that. And the yearly support cost of $500.00 is pretty cheap for the timely answers.

I was most impressed by the architecture, the focus on ease of use for the content manager, and the development roadmap. I have personally created extensions for it and reported bugs that have been fixed by the developers.

The project is not what I would call "mature" just yet. They still find security bugs fairly frequently. It is good enough for many purposes though. As long as you're not needing to store private information, and have a decent backup/recovery plan in case something goes wrong, I would say it works.

So, for example, a company should not use it for online ordering yet... but it could be quite useful for a news, blog or brochure type website. I'm sure within the next year or two it will be "mature" enough for security-oriented tasks too.

There is also nothing preventing the community from developing better documentation for the project. Most young projects have relatively little documentation. Most of the answers are usually locked away in the developers heads... and they usually get documented eventually.

Re:are the plainblack docs still non-free?

[Archangel Michael]

Pretty extreme example of a Hypocrite expecting others to work for free. I'm probably not the only one who didn't bother looking into your hypocritical life after seeing your lame response.

Or are you really a skilled volunteer where you work?

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:I'm sure I'm redundant

[INeededALogin]

PHP is understood by more people than Perl?!?

Since when did PHP take these large grounds in popularity to overtake the most popular scripting language in history. PHP is nice, but it is very limited. Perl is very mature, stable and benefits from one of the best programmers in the world(Larry Wall). Not to mention that you can almost make toast with regular expressions.

And, I hate to say it, but installing PHP is one of my least favorite things to do, along with stabbing my eyes out with a rusty knife.

I feel your love for PHP, but different tools for different people.

Re:I'm sure I'm redundant

[consumer]

PHP is understood by more people, meaning there are more existing projects that you can implement or just borrow code from.

I'd love to know where you got that statistic from. My guess is "nowhere" or "my friends like PHP." PHP is popular within a certain community of designers who became programmers, but I strongly suspect that Perl has a wider base of users if you look at programmers as a whole.

As for your comment about borrowing code, there is really no language out there that has been as successful at sharing code in a resuable way as Perl with its CPAN system. Borrowing PHP code usually means copy, paste, modify. This problem is exacerbated by the fact that PHP seems to make all functions global within a single namespace, so you have no way of knowing if someone else is stepping on your function name.

'FP' ... Front Page, or First Post?

[oneiros27]

I know I've never been a fan of Front Page, with the security problems it has had in the past, but if this message was about that, then it's not directly offtopic.

Of course, the lack of a real message makes it rather useless, so it should probably be scored down for some reason or another.

Authors other books...

[agwis]

I personally won't use Perl for backend programming on a website but if I had to I would probably buy this book based on the fact that it is authored by Paul DuBois.

When I first started out with MySQL I bought the book titled 'MySQL' written by DuBois. Since then, I've obtained a couple of other books about it and still find myself referring to his most often.

Too bad it isn't MySQL and (PHP|Python|Java). Who uses Perl in web programming anymore?

*dons flame retardant suit*

-Pat

Re:Authors other books...

[Anonymous Coward]

Who uses Perl in web programming anymore?

Well, my company does (note the anonymous posting :)

We use Perl with Mason, mod_perl and Oracle to process huge amounts of data. The main obstacle we've found is that we have to hire a much better class of programmer who understands the limitations of Perl's OO model but is willing to accept that sacrifice in exchange for raw power. Combining that knowledge with test-driven development and we have teams of programmers who respond so fast to changing requirements that we're leaving our competitors in the dust and making a ton of money.

That being said, the reality is that we'd choose mod_ruby or mod_python if those languages had anything even remotely comparable to the CPAN. Since they don't, we've grabbed the biggest toolbox and accepted that some of the tools are made from cheap alloys. Were we able to go the Ruby/Python route, we'd have the luxury of hiring programmers of lesser skill and not be worried as much about their using a hammer on a screw.

Re:Authors other books...

[J-Worthington]

Who uses Perl in web programming anymore?

We use it at my company for the vast majority of our web programming tasks, and it works very well for us. Reasons I personally like it:-

* Contorl. While PHP may do a lot more for you (e.g. form parsing), there have certainly been issues related to how it did things. In Perl you can do it as you want. If you put this in a module, as we did, then Perl is no more work than PHP beyond that one-off cost.

* I find the Perl database access model preferable to PHP. Correct me if I'm wrong, but it seems to me that a lot of people end up writing database classes to encapsulate the mysql_whatever or pgsql_whatever methods. In Perl it's OO from the start. Furthermore, if you change from using one database server to another, you only have to make the change in the connection string, and not to a load of function calls.

* Perl puts pattern matching tools right into your hands - it has an operator (//) specially for pattern matching. A lot of the security issues I see in web development come from improper validation. Pattern matching is a powerful tool for writing validation and Perl makes it easier to do than other languages I've seen.

* CPAN. Perl has modules for a wide range of things. Need to look at the headers of uploaded MP3 sound clips to check they were encoded properly? We found a module on CPAN to do this within minutes. CPAN is an amazing resource.

Just my few thoughts on why I belive Perl isn't dead for web programming by any means. :-)

Jonathan

Re:Authors other books...

[glwtta]

Who uses Perl in web programming anymore?

Well, there's me... then there's sites like IMDB and Amazon.com, and *um* Slashdot?

Re:Authors other books...

[Anonymous Coward]

Who uses Perl in web programming anymore?

Only the good people - the rest of them have gone to (PHP|Python|Java).

Re:Authors other books...

[BerntB]

we have to hire a much better class of programmer who understands the limitations of Perl's OO model

I love programming in Perl! The sheer power and expressiveness combined with the (less than totally elegant) everything-and-the-kitchen-sink approach is fun!

But I really don't get this harping about the OO model? It's ugly syntax (and a "bit" of a hack), but it works. Perl's OO has much fewer things to do wrong than e.g. C++. (Advice -- read "Effective C++", I wish I had before! :-)

With good coding standards, and if some experienced programmer introduced the newbies, it shouldn't be hard to learn how to do it right? You need coding standards in any language, anyway, for a project with more than two programmers.

Re:Authors other books...

[lemonboy]

Those people that don't like perl have never unlocked the power of perl.

Re:Authors other books...

[eyeye]

I kept reading that perl has ugly OO syntax, not knowing OO perl I believed it.

I started learning Java and thought "WTF I have to put in all this crap to code java".

Now I am learning OO perl and its MUCH easier to code OO in perl.

Writing code in java is like trying to have a wank with oven gloves on.

Re:Authors other books...

[BerntB]

Now I am learning OO perl and its MUCH easier to code OO in perl.

You get more rope, yes? :-)

The problem (except being a bit kludgy and missing "real" members) is that you really need to know what you're doing.

My point in my comment was that given reviews of the new people's code and forcing people to follow the coding standards, OO in Perl is no harder than working in any other language. And you need to lay down and follow coding standards in any language, anyway.

I can agree on that the Perl interpreter model is less of a pain than save-compile-test, but IDEs today are quite OK. Without being too much of a Java expert, I'd say Java is quite OK to use, today. What's your specific criticism?

My main problem with Java is that if they took the painful hit of a GC, why did they not go the whole way and do a Lisp/Perl, or something good?? (Yes, yes, backward compatibility... The same reason today's std processor architecture is uglier than a festering wound.)

Re:Authors other books...

[eyeye]

Hmmm if you want me to put it in a nutshell I think its that I am lazy and dont like Javas enforced OO - in perl you can put in as little as you want.

Maybe I can get my head round putting a couple of extra curlies in easier than writing static protected void blah blah :-)

So anyway I gave up learning after getting half way through Bruce Eckels book - I understood it, I just didnt like it. Maybe I will go back to it in the future and it will *click* and i'll say "hey I like this!" - who knows :-)

For those getting started with Perl...

[CaptainPinko]

Nice. I'm planning on learning how to tie scripting (have decided on Perl yet but it's a contender) and databases this summer anyway. This book might make the decision as to what to use for me.

However, for those just picking up Perl for the first time I recommend the free ebook Picking Up Perl, and the ActiveState Perl Interpreter for Windows (this was a while ago-- if you are using Linux it probably aleraday has Perl installed). And then as it was Windows I was learning Perl on I used OpenPerl IDE. For Linux I recommend using Kate and Konsole.

Not trying to be off-topic here but I figure someone reading this may want to try out what this Perl thing is.

Disclaimer: Not a Perl fan at all, I actually perfer Python, but to each their own and as any Perl hacker can appreciate TIMTOWTDI! ;)

Re:For those getting started with Perl...

[glwtta]

And then as it was Windows I was learning Perl on I used OpenPerl IDE.

Personally I've never seen a use for a Perl IDE (maybe it's just that I haven't seen a good one) - I use UltraEdit day in and day out for Perl development and it's absolutely beautiful.

Re:USE ASP!

[I confirm I'm not a]

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.

Why bother?

[Decaff]

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?

Re:Why bother?

[consumer]

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.

I'll believe it when I see it. Right now, the situation is that Java Server Faces is a very complex API and mature tool support does not appear to be freely available. Beyond that, experienced coders (heck, even HTML monkeys) will usually tell you that the GUI tools only get you so far before you have to crack open the lid to get what you want.

Drag and drop dev tools have been promised for years, and they just never deliver enough to make coding obsolete.

Re:Why bother?

[killjoe]

Where is this JSF Creator? If you have a link I'd be most grateful.

Re:Why bother?

[Decaff]

Java Server Faces is totally free, and its not complex at all, especially when compared to hard-coding form validation in Perl/CGI. Mature tool support is available in the next few months from Sun, Borland, IBM and oracle. There is a free implementation that can be downloaded from Sun's website, and a free evaluation (but working) copy of the Creator visual designer.

You may need to crack open the lid at some point, but GUI tools will get you most of the way.

Re:Why bother?

[consumer]

Not complex at all? Take a look at the UML diagram in this introductory article. I don't think form validation is really the point of JSF, but if you want to look at form validation in Perl, it is as very simple. Take a look at this example in the docs for CGI::FormBuilder for example.

I want Java to succeed, but I don't think it will ever be simpler than Perl for web applications.

Re:Why bother?

[eyeye]

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.

So why would anyone want to hand-code all this in Perl?

And would you believe people still havent been turned on to the magic of creating websites in a "few clicks" using Frontpage? They are still writing HTML! LOL!!!111

Re:Why bother?

[JerkBoB]

especially when compared to hard-coding form validation in Perl/CGI.

Hard-Code No More!

I discovered this when I was putting together a web-based interface to our PowerDNS DB. Saved me lots of time, and we don't have to worry about our support staff putting bogus information into DNS.

Re:Why bother?

[Decaff]

You are looking at the UML describing the mechanism of how JSF works and how its implemented by tool providers.

JSF is simple for developers who use JSF to produce web interfaces: Its only a few lines of XML and and some tags on a JSP page.

Re:USE ASP!

[Anonymous Coward]

PHP is not object oriented, therefore making it teh ghey.

ATTENTION: Parent is NOT OFFTOPIC !!

[Anonymous Coward]

Okay, so it discusses the merits of PHP vs. Perl. So friggin' what? It's an attempt at creating a discussion, and has been replied to already. Why mod the hell out of something that could be interesting. And it IS Ontopic - it only widens the area of discussion in a logical fashion.

Choice Quote

[Eberlin]

"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."

However if you are putting together a basket and require that this be done while not being mentally "all there" and submerged in seawater, "Underwater Basketweaving for the Mildly Retarded" will aid immensely in your project.

I mean c'mon, can't we infer the subject matter from the book title? I'll admit that there are some obscure ones out there that you can't tell but this one just seems to be a no-brainer.

one thing perl did right

[jd142]

One thing that Perl has going for it that PHP doesn't is that it has correctly set up the database connection functions. Once you connect to a data source, all of the commands you use to interact with that connection are the same, whether you are using mysql, postgresql, or just a csv file. This means that you can change backend databases trivially, merely by changing one line of code.

With php, the commands for connecting to a database and running a query change, sometimes drastically, depending on the database you are using. For example, until recently if you had a query to run on a mysql backend, you did mysql_query($query) but for a postgres it was pg_exec($query). That is changing at least so now it's pg_query($query) but it still makes changing backends a large search, replace, and hope nothing breaks task.

Re:one thing perl did right

[NineNine]

Kinda' like ODBC did so many years ago, huh?

Re:one thing perl did right

[rainman_bc]

Not true. There's database layers for PHP you can use that'll make your database connections heterogeneous...

ezSQL is one that comes to mind. There's plenty more.

Re:one thing perl did right

[PCM2]

Just because a language wasn't designed with certain features in mind doesn't mean they haven't been made available for you to use. Take C, for example. The C language doesn't even let you print to the terminal without external libraries.

Similarly, if you look at the PEAR project site, you'll see no less than four database abstraction layers. PEAR DB is mature, widely used, and actually ships with the core PHP distribution these days. If you don't use it, that's your own affair.

Re:one thing perl did right

[ryantate]

You're greatly overstating the strengths of Perl's DBI. I love the system but to say "you can change backend databases trivially, merely by changing one line of code" is wrong in nearly any real-world application, in my experience.

Just one quick example, the highly common operation of obtaining the value of an autoincrement column for a row you have just inserted. That is to say, obtaining (usually) the id of the row you have just inserted. This is not abstracted across RDBMS platforms. So for MySQL it is "$statement_handle->{mysql_insertid} ". If you switch to Postgres, you have to change this in each and every case, unless you have written a custom abstraction wrapper on top of DBI.

Re:one thing perl did right

[interiot]

• There's plenty more

And there's no problem with this? I have the same reaction when people tell me that X language now has regular expression libraries available for it. That's great in some circumstances, but unless there's one or two really good implementations of an API that everyone clusters around, it ends up being a drag on the community. Perl has very good built-in strings, associative arrays, and regular expressions, and this is very helpful the community. The community uses CPAN and generally chooses good API implementations, and this is a good thing too. Visual Basic where there's 40 different table widgets, that is a bad thing (at least for hacking-for-pleasure... if it's for work and it's a given that you'll spend day and night with it for several weeks, no big deal).

Re:one thing perl did right

[rainman_bc]

Visual Basic where there's 40 different table widgets, that is a bad thing

I beg do differ. I have choice, and choice is always a good thing. I can choose the widget that works for me, or write my own and pass it on to those who may have needs similar to mine. That's the beauty of open source. In your world, I guess there would be one standards body controlling the table widget and we'd all have to like it, and if not we get stuffed. You sound like a Windows sales person dude. Open source is all about choice.

Re:one thing perl did right

[killjoe]

DBI is a library not a part of perl itself. Same with all of the PHP database abstraction layers.

Re:one thing perl did right

[pairo]

You're confusing Perl with CPAN. Perl by itself doesn't allow you to connect to a database the way you described, you use CPAN's DBI to do it. Which is a database abstraction layer, same as PEAR's DB

Re:one thing perl did right

[VirtuaKnight]

If he was a Windows salesperson, why would he be bashing software designed for Windows?

Re:one thing perl did right

[interiot]

They don't have to be a part of the core language or core libraries, there just has to be strong community support and mechanisms for selecting good implementations and everyone wrapping their head around those and sending in patches for those, rather than everybody going off and writing hundreds of alternatives.

• Perl 6 will be the community's rewrite of Perl, and the community's rewrite of itself.

  -Larry Wall

Re:one thing perl did right

[interiot]

No no, extremes are usually bad (eg. see democracy, and tyranny of the majority). A world with only one Microsoft is bad. A world with only one copyright regime (the US's) is bad. A world with Gnome v KDE is a good one. Emacs v. Vi is also a good one. A world where there's 4,000 different electrical socket configurations and voltages, just because people feel the need to be different and unconstrained, is a bad one.

There are just certain things where standardizing around one or two alternatives can be a good thing. You DO have a choice to use something other than TCP/IP and HTTP on a daily basis. But Slashdot is infinitely stronger due to the fact that Rob doesn't have to code to 20 alternative protocols, and everyone can log in and post using whatever OS they want.

Re:one thing perl did right

[jadavis]

This means that you can change backend databases trivially, merely by changing one line of code.

That assumes that the SQL still works. Some databases don't follow the SQL spec very closely, so lots of stuff breaks. And sometimes you use a feature only available to some databases.

Re:one thing perl did right

[killjoe]

There are only three major libraries for database abstraction. Adodb, metabase and PEAR. PEAR is the "official" one and is late to the party. I prefer adodb but they all have a thriving community.

Re:one thing perl did right

[AcornWeb]

Unless of course you program using objects and subclass from a generic DB object. In which case, you define your PHP PostGreSQL DB object at the top once and then call it just like you called your old MySQL DB object. :-)

Re:I'm sure I'm redundant

[lpangelrob2]

Actually, I'm an on-again, off-again PHP website developer that came from a community of programmers who happened to fall into web design. And happened not to like Perl enough to want to learn it.

PHP sometimes seems more than hackish at times, and I won't start the whole separation of presentation and data thing started. (i.e., if you care, use JSPs). But it's done well for me in small, interactive websites that require a convenient interface to a database of some type.

Call me ignorant of Perl... but I would also like to see some more complex programming in websites. Next time I'm at Barnes and Noble, I'll give this book a look.

Re:Put me down for...

[Anonymous Coward]

Fucking shit, lame ass slashdot doesn't have an "edit" button.

Mysql is the choice of ignorant newbies and dishonest greedy hucksters.

Re:USE ASP!

[thebra]

PHP is not object oriented, therefore making it teh ghey.

Yes it is.

too many linebreaks

[Anonymous Coward]

Seriously, when your type in BR 5 times after each paragraph, don't you feel that at least 3 of them are superflous.




It's bad enough we have people posting the slashdot FAQ at 60 second intervals.




And what are the 2 linebreaks after the end of your post for? Deliberate annoyance? Extra scrolling pleasure? come on.

Re:too many linebreaks

[CaptainPinko]

sorry, i just used the paragraph tags, no break-lines, and some white space just to see what i was writing better and still missed a few mistakes, sorry about that

Why actually choose MySQL?

[jesterzog]

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.

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:

• MySQL being the only DB supported for an application that someone wanted.
• People already being very familiar with MySQL's strange ways of doing things that are inconsistent with every other respected database, not to mention SQL standards.
• No other free databases having reliable Windows builds. (A Windows build of Postgres is on the way, but not yet fully complete.)
• ISP's only providing a MySQL server.
• Simply not knowing anything else due to past experience.

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.

Re:Why actually choose MySQL?

[Thorizdin]

How about MySQL actually accomplishes what I want to do for a reason?

I love people screaming that the tool I am using is wrong, when they have no idea of just what I am doing. We also use Oracle, where needed, but we run MySQL 24/7/365 in an incredibly mission critical spot and are very satisfied with it. We tried other DB's and technologies including:

LDAP (Open and Sun/Netscape's)
Oracle
Postgres
Informix (Ok we still had a license and were bored :)

and none of them offered any better stability and only LDAP matched the performance in reads. Writes MySQL blew LDAP away so thats what we run. since we need good read & write speed.

As for what MySQL does better? Thats easy speed. The team started with that as its goal and kept performance in their sights the entire time. The pushed back other things, like row level locking, sub-selects, and views expressly for the purpose of running quickly. This is obviously not the right approach for some applications, but for most database driven web sites it makes perfect sense. Honestly, how many web sites really need triggers and stored procedures? There is a reason that LAMP has changed small/medium web site development business, and while its not right for all sites its a perfect fit for the vast majority.

Re:Why actually choose MySQL?

[njdj]

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?

I agree with most of your post, indeed I'd go further: MySQL doesn't deserve to be called a database at all, because it does not support transactions with commit/rollback, and cannot therefore guarantee to maintain referential integrity.

But to answer your question: I think the answer is performance, compared with Postgres. Of course it's easy to have good performance when you drop vital database functionality.

And compared with Oracle, it's price. I try to use open-source stuff exclusively, but I have to admit that Oracle is one impressive product, that has no serious competitor in the open-source world. MySQL performance (or better) with complete database functionality! For once, you actually do get what you pay for.

Re:Why actually choose MySQL?

[iwadasn]

Something I think I'll point out. If you want a little toy database, consider HSQL. It's about as good of a database as MySQL (give or take), but it's written in Java (runs on anything), is about 300k or so in size, takes all of ten seconds to set up, and is actually much more SQL compliant than MySQL.

If a tiny easy to use database is all that you need, HSQL is for you. The one real gotcha though is that it can't handle datasets larger than 1/2 a GB. That's way too small for real database servers, but more than enough for most websites, even many commercial ones, I imagine.

In addition, HSQL can run within your java apps, which is really nice. I usually go for a dual pronged approach. use HSQL to handle all the file BS that you app might need (various config parameters, a small data cache that can be sifted efficiently in lots of different ways, other nastiness) and as (small) test databases to try a new idea.

For real DB work though, trade up to Postgres, and be sure to get 7.4, the 7.3.x line has a lot of crippling bugs.

The one real gripe I have about Postgres, is god, these people are in love with Hash joins. Any really good database should avoid hash joins like the plague unless it can guarantee that all the data that could possibly be returned by a subquery will fit into RAM. Postgres often wildly mis-estimates the size of a sub query, decides to hash it, and then gets killed when the query returns 100,000 rows, rather than 100.

A real database using a hash join when it doesn't know that it can take the whole table into RAM (if needed) is just begging to get run over. This is one of the few things that can really knock out an otherwise good database, and really should be considered more carefully. Hashjoins are for small reference data tables (few thousand rows), and should not be used unless you're guaranteed to be surprised.

HSQL of course doesn't have this problem, because it doesn't mess around with these "big" tables that are all the rage nowadays.

Re:Why actually choose MySQL?

[Anonymous Coward]

Java? Hehe.. lol.

Dude, check out SQLite. It's written in C. It's fast. And it's smaller than your java shite.

The one real gripe I have about Postgres, is god, these people are in love with Hash joins. Any really good database should avoid hash joins like the plague unless it can guarantee that all the data that could possibly be returned by a subquery will fit into RAM. Postgres often wildly mis-estimates the size of a sub query, decides to hash it, and then gets killed when the query returns 100,000 rows, rather than 100.

This isn't a problem with PostgreSQL, but rather with it's user (that would be YOU). Perhaps you should actually edit postgresql.conf, and vacuum the database once in a while. Idiot.

Stop spreading FUD.

Re:Why actually choose MySQL?

[GabboFlabbo]

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.

I'd still recommend MySQL if you are just starting to learn SQL language. If, however, you are looking for a fully robust database with 100% guaranteed data integrity, I'd say go with Postgres.

I always remember 2 years ago when I first started researching free SQL databases. I tried out MySQL and Postgres. I stuck with MySQL because it was easier to setup, the documentation was much better and at the time it was much faster. It also didn't have an easy way to get the recently inserted auto increment field. Fast forward to today, I now use Innodb for my tables and am willing to sacrifice some speed for more integrity.

After the news story a couple days ago, I went and installed Postgres and here's my experience.

• Setup was pretty straightforward.
  
• Documentation is pretty good though MySQL docs are still about twice as good.
  
• I still can't figure out how to get the list of tables that my db currently has. I've searched the docs. Please enlighten me.
  
• I also still can't figure out how to get the definition for a table I just created. Feel free to point me to a page that shows my stupidity (or ineptitude in reading / searching docs)
  
• After going through the docs and trying some of the advanced features (things that MySQL doesn't have). I really love VIEWS.
  
• Postgres still doesn't have REPLACE even though it is not a standard SQL command, it's still nice at times. I could probably learn to live without it now though.
  

With these things being said, I'd probably use Postgres over MySQL now. Why?

1) I don't need commercial support
2) I haven't worked on a project in a long time that requires speed over data integrity.
3) VIEWS

If I needed commercial support for a project though, I'd obviously have to drop Postgres. Since MySQL is the cheapest out there and it now does support some base level transactions, It's definetly the best bang for your buck. Oracle is pretty damn expensive.

Re:Why actually choose MySQL?

[ajs]

The most fundamental reasons to use MySQL are:

It's fast out of the box, and even moreso if you know how to tune it. Coming from an Oracle background, that's a breath of fresh air.

It's very, very easy to administer. Don't have enough room on this filesystem? Move your largest table over to another with "mv" and "ln".

It comes pre-installed just about everywhere.

Is all of that true for [pick your fav DB]...perhaps, but shock though it may be, people generally look for a tool that suits their needs, not EVERY tool that suits their needs. MySQL suits the needs of a lot of people, and it's very good at what it does. I've yet to find something that I needed that it didn't do well, and given my rather painfully convoluted needs, that was something I was very pleased with.

Re:Why actually choose MySQL?

[Anonymous Coward]

Run psql and type \?. \dt list tables and \d [NAME] describe table, index, sequence, or view

You can also use pgadmin or phppgadmin

Do you want support? try http://www.pgsql.com/

Re:Why actually choose MySQL?

[killjoe]

Firebird has excellent windows support. It also does not have of the quirks of mysql and is full featured.

Re:Why actually choose MySQL?

[abirdman]

Answer to third question: If you're in psql interpreter, and connected to the database, type \dt and voila, a list of the tables. There are various ways to get the same list by querying the system tables, but I never learned them (I admit to using phpPgAdmin which is superb for administering PostgreSQL databases, and which makes those kinds of things easy).

Answer to fourth question: in psql type describe your_tablename and it will show you the structure. Many of the commands in psql are the same as in SQL*Plus in Oracle, and it wouldn't be a bad idea to get a nutshell guide to that for this kind of problem.

I agree, views are great, but wait until the first time you create an inline function... Mmmmm... true database goodness.

And I don't know where you get the idea that replace is any better than update... set... where... functionality. I guess I just don't think in "replace" anymore (FoxPro has it, and I used to use it all the time).

Re:Why actually choose MySQL?

[The Unabageler]

I myself am a postgres diehard, and push it heavily at my new job that is based on mysql and i think nothing is wrong with postgres but many things are wrong with mysql. Anyway, to respond to your statement: many people are incapable of performing database maintenance tasks. they can do a couple inserts and selects via php because someone wrote an article at phpbuilder on how to make a web based contact manager and that's it. No real brain to speak of that can figure things out for themselves or read db docs. He is an idiot, but some idiots just can't save themselves and you should pity them, not be angered by them ;)

Re:Why actually choose MySQL?

[GabboFlabbo]

\dt works great, but where is it in the docs?

describe your_tablename doesn't work. \d works

test=# describe foobar;
ERROR: syntax error at or near "describe" at character 1
ERROR: syntax error at or near "describe" at character 1

but once again, where is it in the docs? It's small stuff like this that once again show MySQL is much easier on beginners.

And I don't know where you get the idea that replace is any better than update... set... where... functionality. I guess I just don't think in "replace" anymore (FoxPro has it, and I used to use it all the time).

Well I never said it was better but if you want to insert a record and if it encounters a duplicate it just does an automatic delete / insert automatically, replace is your friend. It's rather nice since all other methods require 2 queries. It's not good in all situations, but for some it's nice.

Re:Why actually choose MySQL?

[Lazy Jones]

\dt works great, but where is it in the docs?

You must be blind. The first thing you see when you start the "psql" command-line utility is:

Welcome to psql 7.4.1, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

So, try out the \? command and you'll be presented with all the useful commands ...

Re:Why actually choose MySQL?

[GabboFlabbo]

Ok, but where is it in the documentation: http://www.postgresql.org/docs/

Re:Why actually choose MySQL?

[aled]

And free as in free beer, unlike "HisSql".

Re:Why actually choose MySQL?

[jesterzog]

It's in the documentation for the psql command line utility, which is here, which is listed in the reference section of the manual under "PostgreSQL Client Applications". This appears to be from the same source as the psql man page.

I think the postgres attitude to this is that their command line client utility for accessing databases is a discrete entity from the database product itself. I agree that it could perhaps be clearer in the main part of the documentation. psql is referenced in the tutorial, but there isn't much indication of where to find out more about it.

Re:Why actually choose MySQL?

[Anonymous Coward]

Wrong, mysql has commit and rollback.

When I last downloaded it, they offered a free t-shirt if I filled out a survey. I got my shirt, and it says on the back:

[X] TRANSACTIONS

They've got transactions! They've had them for a while!

Re:Why actually choose MySQL?

[sqlgeek]

So what's your prefered execution plan for joining a couple of 100,000 row tables, call them A & B? Lets take the ever popular nested loops strategy.

1. We do a full table scan of table A -- 100,000 rows. Cool.
2. For each row we do an index read to find the row id of our target row(s) in B.
3. Now we read the appropriate row(s) of B.
4. Repeat 2 & 3 until finished.

Notice, if you will, that we just did 100,000 read of B's index and at least 100,000 reads of B. Lets say our database does block-reads, with say 8K blocks. Lets say our table has 100 rows per 8K block. Now we just read 100,000 blocks, reading each row an average of 100 time (since we're fetch the whole block to get 1 row).

Or were you advocating sort joins? Those have the same sort & temp space overhead as hash joins and typically don't perform as well -- though implementation is of course central here.

Give your database enough swap space and I think you'll be quite happy with hash joins. They're obviously not appropriate all the time, but when you're joining the preponderance of 2 tables together they really are the best strategy.

Scott

Re:Why actually choose MySQL?

[jadavis]

If you want to see some really horrible, self-serving speed analysis, check this out.

SQLite talks about how fast they are when doing the operations inside a big transaction. Well, that's wonderful, but since it's embedded that means no concurrent access. So what kind of application would do 2500 inserts in a big transaction? If you're doing a data load in PostgreSQL you just "COPY". Yet if you do a bunch of inserts with SQLite and sync on, the benchmarks show PG and Mysql to be better. I bet those numbers would be different if you turned fsynch off in postgres.

Not to mention they used postgres 7.1! Why even have the page still around? Run the tests again.

Re:Why actually choose MySQL?

[abirdman]

You're right, describe doesn't work. I'm too used to Oracle. (I could have sworn I typed it into psql before I posted it, but alas, I'm wrong). \d table_name does work as well. It's also possible to get the information by querying the system catalog tables, though in the last 10 minutes, I've proven to myself that your complaint is valid. This is all less than obvious to a newcomer, and finding it in the documentation is less than trivial.

If you've got access to a web server that has PHP, it's well worth it to install phpPgAdmin, which makes all this incredibly simple. PgAccess also works well, and there's a windows version as well as a linux version, and it doesn't require a webserver or PHP.

The thing that makes PostgreSQL great is every time you define a view, you never have to write it again in code! Just query the view. And every time you define a function that returns a value, you can use it in any subsequent query. And every trigger you define is there whenever you insert or update or delete a record, not just when you remember to do it correctly in your code. MySQL is great to use when you're slapping out the code to get the job done. PostgreSQL is great when you've forgotten exactly how everything works (for me, that's a couple of weeks at most) and you've got to make a change or add some functionality. Keep trying, it's not easy to learn, but it's worth the trouble!

And finally, your point about "update" is well taken. I use that feature in ADODB all the time, and it saves writing a lot of code.

Re:Why actually choose MySQL?

[MattRog]

Sort-merge is very, very good if you have pre-sorted data (which is often the case with B-tree indexes and/or clustered indexes).

Sounds like the particular query in question wasn't using a sort-merge when it should (could) have.

Re:Why actually choose MySQL?

[Anonymous Coward]

Sqlite doesn't make any outraegous claims -- quite opposite, it is extremely honest about its limitations. It's a small footprint embedded database that does a small number of databasey task well and quickly, and is very easy to deploy.

Contrast this with MySQL... which manages to claim that many important RDBMS features are uneeded and better simulated with client code. Pillocks.

Re:Why actually choose MySQL?

[iwadasn]

OK, hmmm, lets seee. I vacuume all the freaking time. Not that this is really relevant, as with the 5-10 billion rows we'll be looking at, it looks like we won't be able to vacuum more than once a week, if that.

And I did edit the postgres.conf. I had to actually turn off the Hash joins and the sequential scan, in addition to adjusting all the buffer sizes. Both of them are simply not an option for a db of that size. And yes, it does run about 5 times faster now. Don't you think it's a little broken when turning off some optimizations gets almost a full order of magnitude speed improvement. Reading the query plans the problem is obvious. Postgres doesn't keep track of the number of unique keys in a database (or most other things about the database) which is perfectly possible to do with B-trees. As it doesn't know how many unique keys, or how many keys there are within an interval, it cannot accurately guess the nubmer of rows returned by even a simple query. So it selects out of a multi million row table, thinks a hash join is feasible, then gets killed when half the table comes back. Open and shut.

You're out of your league here buddy. Go back under your bridge. Return if you learn a little about databases.

Re:Why actually choose MySQL?

[iwadasn]

Needed query plan is two index scans and a merge join, should be obvious. With huge datasets I don't join on any columns that aren't indexed, so it should always index scan and merge join. You can make it do this by turning off seqscan and hash join. This improves the speed by almost a full order of magnitued (5+ times). In addition, a hash join that big pretty much locks up the box because it makes it thrash so badly. No thank you. Not only is the merge join much faster, but the box remains responsive.

The real problem with hash joins is lack of locality, a problem that sort joins don't have. So hash joins generally take a substantial performance hit because you're fetching each page in multiple times. In addition, real men index their columns that they expect to join on. With several billion rows (once we fill it up) there is no other option.

I'd even go so far as to say that a database should add an index to any column that's used in a join if the tables in question are each multi million rows (the size of our test database that this data comes from. Would be much worse on the production one). Any other query plan is simply never going to finish.

ATTENTION: He's right! They were TROLLING!

[Anonymous Coward]

The OP discusses nothing of the merits of PHP vs Perl. It gives an uninformed opinion.

It really should've really been modded "troll"....just like all the other PHP, Ruby, Python karma whoring wankers...

Re:Put me down for...

[Etyenne]

HELLO ? PEAR ?

Re:I'm sure I'm redundant

[consumer]

I would actually consider JSP a bad example, unless you use taglibs. Something like WebMacro or Velocity would be better.

There are some large and complex sites written in Perl: TicketMaster.com, Amazon.com's newer stores, imdb.com, and others. PHP can be made to work in many situations, but Perl has more features for progamming in the large with teams and sharing code.

Re:USE ASP!

[rainman_bc]

So to understand you correctly, you use perl over chillisoft ASP to run your code on a non-iis box? Are you related to MacGuyver? I mean, really dude.... mod_perl on Apache is a lot less layers to have to depend on. Less stuff that can go wrong really.

Perl synonymous?

[Laptop Dancer]

Perl (also love it or hate it) was almost synonymous with website programming. Arguably there are different choices for different needs in web development..

I'm willing to argue vociferously with that!

Re:Perl synonymous?

[el-spectre]

Ah, were you one of the 3 C++ CGI coders?

Re:Perl synonymous?

[shaitand]

I've coded cgi in c and perl both (not too big on C++ personally although I can work with it if suitably bribed). Both have their advantages and when your talking high enough volume perl is no longer than option, the interpreter consumes too much memory per instance.

Sometimes 4000 simultaneous instances just plain need to consume less than 256mb of RAM, it's just the way it is.

Re:Perl synonymous?

[Etcetera]

Both have their advantages and when your talking high enough volume perl is no longer than option, the interpreter consumes too much memory per instance.

That's why I use SpeedyCGI to keep things around persistently. Think of it as mod_perl, without the heartache. If you're writing your perl to use strict, you can probably replace /usr/bin/perl with /usr/bin/speedy and solve most of your problems right there.

Re:I'm sure I'm redundant

[geoffspear]

How about Sourceforge?

Perl (5498 projects)
PHP (8923 projects)

Re:USE ASP! PHP is not object oriented.

[Anonymous Coward]

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.

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 .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.

You guys aren't in sales are you?

[The_Real_MrRabbit]

...otherwise you wouldn't have so much trouble with closing tags...

=8-)

Re:I'm sure I'm redundant

[Monkey Angst]

And, I hate to say it, but installing PHP is one of my least favorite things to do, along with stabbing my eyes out with a rusty knife.

Installing PHP = not so easy.
Learning PHP -- now that's where its strengths lie. I don't know much about the strengths and weaknesses of PHP vs. Perl as programming languages, but the learning curve for PHP is much lower.

PHP is understood by more people than Perl?!? Since when did PHP take these large grounds in popularity to overtake the most popular scripting language in history.

Well, Perl may be used by more people, but I wouldn't be surprised if more people understand PHP.

Rooting

[ryantate]

The only reasons to use perl over PHP for web development are 1.) familiarity with perl (slashdot), and 2.) security (to avoid "today's php upload root exploit").

So PHP is ideal unless, you know, you don't want to be rooted ...

Noted.

(Backs away slowly ...)

Re:Rooting

[zerocool^]

yeah, or you just turn off php_upload() or whatever the function is in your config, and keep your system patched.

Re:Rooting

[Vaughn Anderson]

http://bugs.php.net/bug.php?id=15736

You want to substantiate your statement?

Is this the bug you are refering to?

If so, it's two years old and already fixed, unless there's a different upload bug...

Re:Put me down for...

[Anonymous Coward]

Yeah, Jeremy Zawodny truly is a stupid ignorant fuckhead.

Re:Put me down for...

[Anonymous Coward]

HELLO ? PEAR FUCKING SUCKS.

Re:I'm sure I'm redundant

[consumer]

The previous poster was saying there were more PHP programmers, which is not supported by that stat. And of those PHP projects, how many have code that is reusable, i.e. not tied to specific HTML, won't clash with other people's function names, written as components, etc.?

Re:Put me down for...

[daperdan]

Pear? Leave your fruit slander at the door!

Perl, the Web, and Rapid development

[kellan1]

While the idea of a 3 year old book on web development appeals to the poetry in my soul, I think it is misleading. In the last few years the Perl dev community has been making really significant progress in enabling rapid development methodologies, in particularly using tools like Class::DBI

A book which claims to detail how to do web development with Perl and MySQL and doesn't address the following issues is painfully out of date:

* Class::DBI
* SPOPS
* Kake's How to avoid writing code

With the Perl Foundation funded work on Maypole being the most recent efforts in this direction.

Re:Perl, the Web, and Rapid development

[glwtta]

I really wish the parent didn't use buzzwordy phrases like "enabling rapid development methodologies," because the aforementioned tools really do kick some serious ass (once combined with a proper templating system.

CPAN Schmepan

[gimpboy]

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.

Re:CPAN Schmepan

[skiflyer]

Both statements are true... PEAR has made some amazing strides in the last year or so. It is still no comparison to the massive body of code that CPAN provides.... yet.

Re:USE ASP!

[Anonymous Coward]

Excuse me, cockmaster, this is a mod_perl parser for Perl in ASP-like syntax and objects. Maybe that clears things up.

It was lack of advertisement for me...

[gimpboy]

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.

This is what almost got me. I started mucking around with databases in '99, and the first book I found was Mysql & msql from O'reilly. I read throught the book and started messing around. I found a message board or something, where someone was responding to a comment where the responder said something like "hey why aren't you using PostgreSQL?". That got me to ask the question, what is the PostgreSQL thing? Since I wasn't too entrenched, I eventually started using PostgreSQL instead of MySQL.

I'm happy that I started using PostgreSQL because of all the features. MySQL may be faster for db's that dont change much (i.e. few inserts, deletes and updates), but I don't really notice the effects for what I do.

Perl or PHP faster?

[Anonymous Coward]

I had to throw in my 2 cents after seeing some of what is being posted here.

When using the appropriate tools, such as mod perl combined with the template toolkit or Mason, Perl is not at all slower then php. In fact in many cases you have to use add on's like the Zend accelerator before it's as fast as something like mod perl/template toolkit.

Re:Perl or PHP faster?

[shaitand]

That's good and well, there's only one problem with it.

Perl isn't exactly in competition with php, they have different purposes and are used for different things. Might as well start comparing perl to SSI's. True they overlap, and there are many things you could do in either but generally, if it's the front, you want php, if it's the back, you want perl.

Perhaps your perl backend might output a little html/php but it's certainly not going to be the other way around ;)

Perl is great for cgi's, php is great for dymanic web content, cgi's were never good for that.

PHP is actually an counter to something more like SSI's, or ASP

Re:I'm sure I'm redundant

[Anonymous Coward]

Installing PHP = not so easy.

What?! There's a windows installer for christ's sake! Click the download link, click open, click next 4 times, you're done!
Bring up a dos window and use it just like any other dos app. Or if you want it for webpages, install IIS. If IIS is hard to set up [it's not, although it is significantly more effort than PHP], well, that has nothing to do with the difficulty of installing PHP. Hell, php gives you a radio box set. Just pick your web server and it does the rest. If you can't manage to select which server you're running, then perhaps PHP isn't for you...

Re:But why would you use Perl?

[glwtta]

but scaling Perl and MySQL to scale to 100's of 1000's of users?

That's kind of ironic, coming from "FatSean (18753)."

Re:USE ASP!

[I confirm I'm not a]

No. Apologies for the confusion. The AC recommended apache-asp, a PerlScript implementation of ASP. I use <whispers> VB Script </whispers> on Chilisoft. I agree that mod_perl seems a far saner way to run Perl on Apache.

wtf?

[glwtta]

A story about Perl and MySQL? Why not also mention that it runs best on FreeBSD, especially if it is written in vi?

Re:USE ASP! PHP is not object oriented.

[I confirm I'm not a]

I use Chillisoft's ASP on Apache with MySQL, and it works quite well: it seems more stable than IIS. It's not object-oriented, though it can use Java "chillibeans". It's a reasonable platform for small- to medium-sized projects.

I've got to admit I still can't see any advantage .net has over Java, but I try and stay current in both.

JSF Creator URL

[Decaff]

http://wwws.sun.com/software/products/jscreator/in dex.html

+1, true

[Anonymous Coward]

mad propz

If you already know perl ...

[SCHecklerX]

I recommend HTML::Embperl (embedded perl).

Makes it trivial to create web-based apps. If you use Apache::Session, then state maintenence is a simple matter of populating an element in a hash. Makes web development really fast and modular, and mostly XSS-proof (it's sometimes a pain to make embedded perl actually create something like a link if you refer to it in a variable, unless you really think about it).

http://perl.apache.org/embperl/

Use it with mod_perl, some sort of database, and a bunch of your own modules (preloaded in your apache config, of course), and you'll have a high-speed, easily-maintained, dynamic site in no time.

Speed?

[kpharmer]

> As for what MySQL does better? Thats easy speed.

Really? Without partitioning? Without automatically maintained materialized views?

Ah, what you probably meant to say is that mysql does a read-only index-oriented workload better on small hardware than its larger competitors.

I'll buy that.

But, it's nonsensical to think that mysql can scan 300 million rows faster than Oracle/DB2/Informix when you add partitioning into the picture. In that case they can often simply scan the 5% of the data needed.

Same situation with maintained materialized views. Doing both reporting and transactions on same database? Bet those reporting queries are beating up the database pretty badly! Materialized views can be just the ticket here.

Or, how about a mixed workload? Have you compared mysql to oracle on a server supporting 3000 inserts a second along with 20 users simultaneously reading from the database? No?

Or how about on large hardware? Can you spread a database across a cluster of servers and have them all cooperate on each query in parallel? Informix & DB2 could do that since the mid-90s. You can spread DB2 across a hundred 8-way servers in a fully parallel configuration.

Well then, I suppose you can say that for a subset of what databases are used for MySQL is very fast. But that's about it. But there's an entire set of other situations out there in which it comes in way behind the more sophisticated alternatives.

I'm a little confused...

[shaitand]

It's just the alternatives I suppose that have me truely confused.

A fully featured website (which needs it all), has several layers, at most:

The client-side dynamic content, javascript, vbscript, etc

The middle-ground dynamic content,
SSI's, PHP, ASP

And the backend,
Perl, C/C++, Java, (insert any true, full blown, fully featured, programming language here, which none of the above are).

There are places where these overlap, there are number of things you could do in Perl, PHP, ASP, or with SSI for instance, which it should be done with is a matter of efficientcy of course and preference when it's just as fast at 100,000 simultaneous connections either way (even if you only expect 5). But something like PHP is not a replacement for Perl anymore than Perl is for PHP.

It's apples and oranges guys, if you want to compare something go with the SQL database flames, at least there you are comparing pretty much the same thing to pretty much the same thing. And there that same thing and generally used for the same purposes.

Re:I'm a little confused...

[modeling jobbank]

totally agree when starting my site http://www.modelingjobbank.com i quickly learn that many tools are needed not just one

wow, there's a lot of Perl-haters here

[Anonymous Coward]

What's up? Did the camel piss in your cheerios or something? Why so much time wasted basically saying "Perl is da suxx, PHP/Java/Python/foo is da r00lz!" Ya'll sound like a bunch of immature freaks! I wouldn't hire any fucking one of you!

Re:Perl or PHP?

[tunesmith]

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.

Should have been...

[Anonymous Coward]

*dons flaming retard suit*

If you are interested in PHP and SQL...

[Dozix007]

I run Uberhacker.com. The site is a PHP and SQL security challenge with forums on the subject. The site also includes some tutorials on programming securely in PHP and SQL.

Why mysql? OR perl for that matter?

[kuzb]

IMO Perl is rapidly losing steam due to the enormous popularity of PHP. PHP is easier to learn, faster to master and less confusing to begin with. Not to mention, PHP's online documentation is really hard to beat sporting many easy to follow examples, a very functional layout, and features (such as the http://php.net/ search) that i'm pretty sure i've only seen mysql.com adopt.

Granted, PHP is not great for everything, but for small to medium websites (and arguably large websites as well, I know of some corporations that use PHP, see bravenet.com, one of the largest providers of ready-to-run webmaster tools. They use PHP quite extensively.). For rapid application development, it's a dream.

As we come closer to PHP5 (which is RC2 now) we're also seeing the integration of sqlite as an option which may appeal to people who just want to write small blogs and other applications which simply do not demand the need of mammoths like mysql or postgresql. This means less headache for budding programmers, and easier migration of applications since sqlite does not require an SQL server.

Re:I'm sure I'm redundant

[kuzb]

You are absolutely correct, however PEAR and PECL are definatly trying to fix this. Granted, they are nowhere near the size of CPAN, but Rome wasn't built in a day ;)

Nice Book

[dumbledoor]

I have this one.
You need to know perl basics to begin using this though. Just reading Learning Perl would do.
Great book for beginners (that's me). Covers a broad range of web apps.

AFAIK Amazon is not Perl

[Anonymous Coward]

AFAIK nothing on Amazon.com is actually done in Perl anymore.

Re:Why mysql? OR perl for that matter?

[Anonymous Coward]

PHP is an ugly crufty hack IMHO ... everytime I use it I find some new "feature". The current ones:

1. There is an strftime function, but no strptime??

2. They use something that looks a whole lot like C format strings, the documentation claims they work like C format strings, but they don't actually format strings the way C format strings do. Sorry, no time for examples ATM.

Anyway, that's just my latest example, and probably my last. Everytime I use PHP it feels like I'm working with a beta project, so I'm currently learning Perl ... at least the sane bits.

Perl's great, but ...

[Anonymous Coward]

But I really don't get this harping about the OO model?

That's the problem I'm talking about. It's very dangerous for us to hire programmers who are confused on this issue or, better phrased, programmers who do not understand OO well enough to recognize the problems in Perl when they encounter them.

Perl encourages a lack of encapsulation. This is more than a "stay out of the kitchen" type of rule. If I want to subclass a standard Perl class but use a blessed array reference instead of a blessed hash, the odds are that I am out of luck. The standard Perl object model locks me into a particular implementation that may not be suitable for my needs.

Next, there's no clear separation of class and instance data. As many Perl programmers have little OO experience outside of Perl, they frequently don't recognize the distinction and simply treat the class data as instance data. This is inefficient and bug prone. Failing to understand the difference between the two can cause many problems for programmers.

And don't forget the problem with lack of private and protected methods and the accidental overriding of them. Sure, you can use anonymous subroutines to get around the private methods, but that can become a hack upon a hack (particularly when you accidentally generate a closure and start leaking memory.)

Yet another problem is the whole "blessing" issue. If you bless a referent, you can call methods on it. Unfortunately, those method calls are much slower than subroutine calls and, if you need to programatically know the difference between a method and a subroutine, you're pretty much out of luck. Since Perl kind of bolted this on (or "bolted through", as Larry Wall himself described it), we have a slow OO implementation that's useful for small projects but can be difficult to scale because it's slow and at odds with core OO benefits.

Don't get me wrong, I love Perl. It's very powerful and I'll kick any Java programmer's tail in the speed in which I can turn out robust code (with a full test suite no less). However, most Perl programmers can't do this and the ones who are can be tough to find.

Re:Perl's great, but ...

[BerntB]

Yes, totally correct description -- I agree. (I hadn't thought about getting a closure by accident -- thanks for the tip! Personally, I just don't "=head1 DESCRIPTION" methods that shouldn't be called, since I'm too lazy to read my own code and call anything non-documented!)

Your point was that you can't hire cheap inexperienced people that only know Perl and nothing else. I didn't get it, since most Perl people I know are impressive old Unix nerds -- Perl is quite a bit to learn.

(-: I just didn't understand you were so cheap, if you excuse the joke! :-)

But OK. Perl is a scripting language, so I guess there should be lots of people without longtime education/experience using it.

(What you're really saying is that you'd get acceptable results in e.g. Java with that hiring practice?! Wow, I'm impressed with Java!)

another review

[kwoff]

I also posted a review on Perl Monks when the book came out. It still isn't in his list of reviews, though. :/