MacPerl Gains Ground

Jun 3, 1998 by perldotcom

New MacPerl CD-ROM Available

Rich Morin (rdm@cfcl.com) of Prime Time Freeware has produced the MacPerl CD-ROM, a distribution of the Perl for the Macintosh along with other Mac tools and documentation. I asked him about the MacPerl community and we were soon joined in email by Matthias Ulrich Neeracher (neeri@iis.ee.ethz.ch), who is the person primarily responsible for porting Perl to the Macintosh.

What’s the size of the MacPerl user community and its percentage of the whole Perl community?

Rich: Small, but we’re hoping to change that a little! The MacPerl email list numbers under 2000, so the total user population is unlikely to be more than 5000, at present. This is far smaller than the size one might predict, based on the 25 million or so Macintosh users that are out there. Consequently, it is also a small percetage of the total Perl community.

Matthias: In fact, it’s approximately 1000 and remains fairly stable. However, there seems to be a self-limiting effect at work here in that with more then 8-900 users, the list grows too noisy for some and they unsubscribe.

Counting through mail logs, I found that at least 3500 different e-mail addresses were subscribed to the list at one point, so it’s plausible that 2500 to 3000 different people were subscribed to the list over the last 5 years.

It’s very hard to estimate the number of users, since it’s impossible to estimate the percentage of them on the list. MacPerl has been distributed on several Mac Magazine CDs, especially in Japanese magazines, so it might have penetration well beyond the internet. My estimate is similar to Rich’s, in the 5-10,000 user range.

In some ways, Perl and the Mac seem to be at opposite ends of the computing spectrum.

*Rich:*I think that part of the problem is based on the fact that Apple promotes Macs as machines that one does not have to program. The Macintosh audience, therefore, self-selects for non-programmers. Also, because the Mac does not have a native command-based “shell” (discounting MPW, which is not a mass-market product), Mac users may not have experience in using textual commands of any sort.

On the other hand, a great deal of Web development is done on the Mac platform, so MacPerl would seem to be a good fit. Also, many UNIX users keep Macs around for “productivity tools”. Some of these folks are likely to be interested in having a version of Perl for the Mac.

With MacPerl, you can run any perl script on a Mac. This helps make the Mac more UNIX-like as a development platform.

Rich: Well, almost any… MacPerl does not support some of the Unix- specific features of Perl, such as backquotes (though a few idioms such as `pwd` are emulated). Matthias: Backquotes themselves work, too, if you have MPW around. This is a real option now that MPW is free.

Can you talk about other ways Mac developers are using Perl?

Rich: MacPerl allows access to Apple Events, the Toolbox, and other Mac-specific capabilities. This lets them build Mac-specific applications to, for instance, grab data from a Mac database and process it for use on a Web page or in another Mac application. Matthias: To use one example that struck me as particularly odd, some people are apparently using MacPerl as a frontend to DNA sequence databases.

Rich: MacPerl also serves as an administrative scripting language for the Mac. Some tasks do not fit well in the interactive Macintosh paradigm (e.g., copy all the files with the extension ‘.html’ to another directory); MacPerl makes it trivial to automate these tasks. In fact, MacPerl allows the creation of “droplets” (Perl scripts, packaged as applications, onto which the user can drag- and-drop files and folders.

Vicki Brown and I are working, sporadically, on a package called ‘Mop’ (Mother of perl), which adds Unix-like commands to a Perl- based shell. If we can get it to the point where we’re reasonably happy with it, we’ll talk about it on the MacPerl Pages and in the MacPerl book.

MacPerl allows a Web developer to run CGI applications using the Mac as the platform for the Web server.

Rich: Although the Mac has many tools for creating CGI applications, a few grainy tasks will always require programming. MacPerl is a good answer for these. On the other hand, the Mac’s multitasking limitations can present performance problems. For instance, if a MacPerl-based CGI script goes off to calculate (or gets lost :-), no other script will be able to run for the duration

What are the OS-level differences between MacPerl and other implementations?

Rich: Mac OS does not support pre-emptive multitasking, pipes, fork or exec, hard links, relative symbolic links (read, aliases), really long file names (but see HFS+ in Mac OS 8.1 and Rhapsody!), or the use of devices as files (though MacPerl emulates some of these).

Isn’t there an effort underway to integrate MacPerl into the standard Perl release – rather than having separate code bases?

Rich: Matthias bases each of his releases off a recent Perl release. The current release of MacPerl (5.1.9r4), for instance, is based on Perl 5.004. (Think of it as the 1.9th version of MacPerl on the 5.004 base.) I know that Matthias works with the other Perl porters, but I don’t know how much MacPerl code gets back into standard (read, Unix) Perl. Matthias, can you help clarify this? Matthias: On this issue, there is my theoretical position and OTOH the practical implementation.

The theoretical position is that eventually, I’d like to have every file that occurs in both the Mac and standard Perl releases to be identical in both. I will *not* merge Mac specific files into the standard distribution (but will not stop anybody from doing so either), because that would enlarge the standard distribution a lot. The numbers that I came up with:

  Source File Size Lines of Code Mac specific core files ~20K ~1000 ext/MacPerl and ext/Mac 1M >40000 MacPerl IDE (Application) ~600K ~23000* * plus some binary files (And with those, you’d still not have all sources you need to build MacPerl. There are a few non-Perl specific libraries needed in addition).

Regarding the practical implementation of my theoretical position, I’m putting this off for “after I finish my PhD thesis” which, itself, has been a target far more moving than I’d like to admit.