Scott's Blog

I didn’t manage to like Blosxom so I’ve moved to Typo: http://blog.rinspin.com.

When fighting monsters, take care that you don’t become one yourself.

(a paraphrase)

I been too long
I’m glad to be back
Yea, the fingers are loose
with the juice that’s kept me up since noon
I’m just bangin’ through the docs cause it’s the only way
Forget old source cause it got no API
I got mad books, secret hooks
And the whole time I’m wondering why
Cause I’m back
Yes I’m back
Mama I’m back
Well I’m back, back
Well I’m back on the Mac, yes I’m back on the Mac. Ow!
            (in honor of AC/DC’s Back in Black)

From a conversation over email…

> Public domain you need to sue the public, since it is owned
> by the public!  :-)  I only want PD code so that commercial
> operations can understand that it is available for use in a
> commercial application, the same as if the code was 200
> years old.

Here in the US, absurdly, it’s not quite that simple. There are two problems:

• It’s illegal to give away dangerous things. If the prosecuting attorney can prove that you knowingly placed flawed software in the public domain, he can sue you and win. However, if the receiving party must accept a license to use your code, then the license can legally ensure that the author is not liable.

• Because PD software falls under gift law, rather than license/contract law, the author may retract the gift at any time. There are exceptions, but it gets somewhat complex. US companies are rather hesitant to adopt PD code.

Here’s an article that explains it pretty well: http://www.rosenlaw.com/html/GL15a.pdf

The MIT license is short and agreeable. It makes it very clear that the software may be used for any purpose, and that the author is not liable for any damages. http://www.opensource.org/licenses/mit-license.php

Anyhow, that’s my thinking. I want companies to use my code for any purpose. It appears that the MIT license does a better job of making that clear than public domain! Well, in the lawsuit-happy US anyway.

You can tell that the PHP designers struggled to avoid making PHP too much like Perl. The problem is, in haphazardly adopting some parts and rejecting others, they produced a language that can be even stranger to use. Here’s a good paper describing some of the issues.

In February I had the opportunity to make a reasonably complex mod_perl-based site (using HTML::Mason to do the templating), and in October, I made a reasonably complex PHP-based site. I feel that I’ve now used both to capacity. The verdict? They both work very well, but they both have serious limitations. You need to use the right tool for the job.

With mod_perl, you spend more time dealing with low-level stuff. Exactly how do you want to maintain session data? How do you want do synchronization? It harder to start a project but it does offer amazing flexibility. You can store session data however and wherever you want. Do you have a unique requirement like, say, needing to store your session data on a WebDAV server? No problem. Once your wizards get it working reliably, you never have to touch it again.

PHP, on the other hand, gives you sessions right out of the box. They just work. Unless you want to do something slightly beyond trivial. For instance, one of my PHP sites needed to copy a variable from one session to another (due to naming issues I couldn’t just merge the two sessions into one). I struggled for two days before realizing that I was absolutely screwed. Forget having two sessions open simultaneously: PHP makes it impossible to open one session, close it, and then open another. It’s an astounding limitation. PHP’s libraries grew directly out of the needs of the people that wrote them. None of them have really been fleshed out completely. For instance, you can’t use the FTP library to read a remote file into a string — you have to save it as a file in /tmp, read the file into a string, then delete the file. There’s just no design forethought.

With mod_perl, you have pretty much every module on CPAN at your disposal. Over 25,000. That’s a hell of a lot of functionality at your disposal. Frankly, it’s daunting. You need to spend a fair amount of time just managing the modules you’re using. Is Apache::Session::Flex being buggy? Try Apache::Session::File. With PHP, you don’t need to spend any time managing externals: if it’s not built into the language, you’re pretty well hosed.

Perl is outrageously expressive. There are 5 different ways to write any single concept. This makes it hard for one programmer to read another programmer’s code. I imagine it’s a bit like the British Isles a few hundered years ago: Perl programmers really have to concentrate to understand each other’s thick accents. On the one hand, it leads to an amazingly rich culture. On the other, it leads to fragmentation.

PHP is exactly the opposite. It’s got very clear idioms for very common operations making the code easier to read for others. The problem is, uncommon operations are very difficult. For instance, to prevent PHP from transparently duplicating an object when performing an assignment or calling a function, you need to mark it with an ampersand. You must to scatter ampersands everywhere! If you forget a simple ampersand, you’re now operating on an exact duplicate of the object and any changes you make silently disappear when the script ends. It can be outrageously difficult to debug this sort of thing. For complex data processing, definitely avoid using PHP objects! If you forget one ampersand it might take days to try to track it down.

mod_perl can drive your memory usage through the roof if you’re not careful. The programmer needs to remember at all times to walk very lightly in the process space. A single Apache process can collect a fair amount of garbage as it handles hundreds of requests before terminating. With PHP, you can be fairly careless how you handle memory and files because all resources are automaticalliy released when the script ends.

Both scale to millions of hits without too much trouble (IMDB (modperl) and (insert PHP example here)). However, when code corpus gets big, they both tend to fall over. Small to medium sites with tight, well-disciplined development teams can use them well, but they are both unsuitable for big projects. Perl allows better encapsulation and modularity, but it also has a weirder syntax.

What happens when you need to make deep changes to your project? Well, refactoring Perl is usually painful. Refactoring PHP, however, thanks to its odd usage of global variables and lack of “use strict” is an absolutely monstrous task that should be avoided at all costs. Witness how large PHP projects typically fork and rewrite, rather than refactor. Unit testing and automated testing is much easier in Perl than in PHP. In fact, many Perl modules include very good test suites right in their distributions.

So, what does it all mean? I suppose you could think of PHP as a small, powered snowblower. It is extremely good at clearing your driveway when it snows, but that’s about all it can do. When things start getting unique, say, if it occasionally rains frogs instead of snow, you’re stuck.

Perl is more like a snow shovel. It requires a little more sweat, a little more skill, and a little more time, but it is also extremely good at clearing your driveway of snow. It can also clear your sidewalk and front porch, and is just as good with mud or frogs as it is with snow. You can use it as a sled, fend off an intruder, grill food on it, … In fact, whatever it is you want to do, somebody else has probably already done it and uploaded a module to CPAN.

So which one should you use? Well, as always, that depends entirely on the problem you’re trying to solve.