Applications for Normal Users

| 10 Comments

I spend most of my programming time writing tools for other programmers. My business (Onyx Neon Press) has a modest amount of code to produce books, but a fair amount of the code in our production process is Pod::Simple and Pod::PseudoPod -- tools for other programmers.

Most of my work on Parrot and Perl 6 is infrastructure for other programmers to use too.

I suspect -- but can't prove sufficiently -- that many of the most popular and most widely used projects on the CPAN are likewise tools for programmers. Moose is a tool for programmers. So are Catalyst, Scalar::Util, Method::Signatures, Devel::NYTProf, and perl5i.

That's not a bad thing. I'm not complaining. It's an observation.

Perhaps CPAN is a tool primarily for developers. That's fine too.

Even so, I wonder where are all of the wonderful applications Perl programmers can mention when people outside the Perl community ask "What's it good for? What can it do for me?"

I'm happy to talk about Padre and BioPerl or Movable Type and Melody. Frozen Bubble is a good story (especially with SDL Perl under fresh development again -- see Kartik Thakore's journal for more SDL Perl details). dotReader didn't get much attention, but it's an impressive project. BBC iPlayer is just on the edge of projects to mention.

I'm not sure bragging about websites implemented in Perl 5 is useful or interesting. For the most part, that's immaterial. A web site is a web site is a web site.

Maybe Perl 5 doesn't need this. Java does pretty well with its comfortable niche in enterprisey web development, Eclipse (a programmer tool for writing programmer tools, remember), and LimeWire. Python gets a boost from the original Bittorrent code (Mercurial is a developer tool, as is embedded Python for game developers and 3D modeling programs). Ruby... well, there's Rails.

Sometimes I read Planet Gnome and Planet KDE and marvel at all of the nice projects that non-developer end-users can use. I see some of these applications developed in Vala and JavaScript (yes, a developer tool -- but one used to write a web browser, a mail client, a music player, et cetera) and even sometimes Python.

I know I've used Perl 5 for system administration, web development, workflow automation, games, visualization, and more. Maybe I'm a very unrepresentative user, and that's fine. Maybe I don't have the mindset to create software for non-developer users and that's probably fine too.

Even so, sometimes I wonder if the Perl community spends so much time obviously and obsessively focused on the needs of other developers that we might neglect some easy and obvious problems where Perl can be part of a great solution.

... not that such users will use Perl directly, but that expanding our area of influence may be a very good idea.

10 Comments

My media player, Remedie http://remediecode.org/ has tons of users outside non-Perl programmers land and it even has .app Mac binary that you can run on every Leopard or Snow Leopard installs by just double clicking it, even though it depends on 50 CPAN modules (which is bundled in the .app binary and it just works)

To your point re: web, yes Perl is a great tool for the Web, and then that's exactly why we can reuse that for desktop apps for "Normal" users. Here's my slides from YAPC::NA this year http://www.slideshare.net/miyagawa/building-a-desktop-app-with-httpengine-sqlite-and-jquery The HTTP::Engine thins gets outdated since we've got tons of progress in a couple of few days around PSGI/Plack but the basic principal is the same.

But Padre & BioPerl are developer tools too. I think it's better to say that, we can't talk about desktop (which is dominated by windows on the os side) programs. And we can't talk about Forum applications, CMS etc. There are MT & WebGUI but with less buzz. As a side note; it's sometimes frustrating to see that some modules/apps does not support windows while only a little abstraction is needed.

Anyway, I think we can also mention the smartphone platform too. Perl is ported to most of them. It works under Symbian, Windows mobile (?) and iPhone is some sort of os x which in turn bsd right? There is also Maemo which is linux. But you can't do anything "real" on these devices since the API bindings are missing. I remember reading something about Android support and it includes api support probably, but not sure about that either right now. So, I can't say "hey, cool phone and I can write Perl apps on it" :( And please don't tell me why I don't write the bindings myself. It needs C/C++ (or even Python/XS for Symbianperl as JHI suggests) hackery and some deep knowledge in the platform specs which I don't possess.

Bragging about websites implemented in Perl 5 is useful and interesting.

Rails fuels Ruby. Catalyst doesn't seem to fuel Perl. Why not?

(Catalyst shouldn't be the only thing that fuels Perl, of course.)

This page is a good place to look http://www.perlfoundation.org/perl5/index.cgi?applications (I helped to expand it's parent page http://perl.net.au/wiki/Perl_applications ).
Several server programs are very well-known: SpamAssassin, Majordomo. I recently used Munin - a tool that collects data about computer (how much it is loaded, number of processes and much more). There are Webapps like RT, OTRS, tools like Plagger, Perlanet, Vitacilina (tried this one recently, requires some changes that are already in repository). AFAIK, SqueezeCenter is widely used. get_iplayer is also interesting.

Coming from a graphic design background, I tend to focus on user facing applications where I can use my UI/design skills. I have written a few applications in perl (RSS reader, IRC client, usenet downloader), but I always have a hell of a time trying to distribute them. Recently I have resorted to using local::lib and creating packages for each platform (e.g. .app, .deb.) I really wish I could just point people at CPAN, but failing tests and confusing questions make that impossible. Ruby gems seems more like what is needed in my case. Gems doesn't run the tests or spit out hundreds of lines of info.

> Bragging about websites implemented in Perl 5 is
> useful and interesting.

See CatalystSites.org - http://catalystsites.org/

I'm loving Zim - http://zim-wiki.org/ - a desktop wiki, which is written in Perl. Definitely something normal users could enjoy!

Ruby gems seems more like what is needed in my case. Gems doesn't run the tests or spit out hundreds of lines of info.

I'm not criticising Ruby here, but it seems to me that NOT running the tests is a big drawback.

Readers of this blog probably don't need to have it said yet again why running a test suite on every piece of software *before* installing is a good thing, but I'd like to stress this one point:

QA is laborious and expensive. It takes an ever-growing amount of resources to ensure a piece of software will work properly across the variety of platforms, environments and parameters where people may try to use it. Having the ability to automatically run a test suite for each component that is required by your software greatly reduces the effort required to find problems when they do *inevitably* occur.

While it may feel good to be able to install a large app with lots of external modules in "one shot" without seeing any errors... are you ready to track down the issue on a customer/user's system when you can't be sure if the problem is because of your code or someone else's?

BTW, wrt. the hundreds of lines of output... I agree there. I would love to have a built-in option for a "silent CPAN" that drops all output to some log and only displays the absolutely necessary info. I've cobbled such a thing together before for my own purposes but it was an ugly hack and not entirely reliable. :)

I agree that running tests is great for QA, but it is unreasonable to expect every user (of a desktop/web app) to run what amounts to 30 minutes of tests. And yes, it really does take at least that long to install MooseX::Declare on a clean OS X perl install. There is a reason I have resorted to packaging all of the dependencies, and it is because people are not willing to sit through the long CPAN install processes.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on September 8, 2009 1:24 PM.

When SUPER Isn't was the previous entry in this blog.

The False Dilemma of Novice and Savant User Experiences is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?