Modules vs. Applications
While still drawing the differences between programmers, language practices and behaviors, I stumbled upon another major issue. Our tendency to write modules instead of applications.
This is a touchy subject, I'm sure, and I hope not to offend anyone.
Since the majority of Perl programmers are actually sysadmins by day [and superheroes by night], we're accustomed to writing pieces of software, "modules". We have CPAN to host all these modules. Occasionally we might write a program, an App, a small cute frontend to some module that we have. CPAN supports that.
This is all fine and dandy but when making an effort to market our kickass language, we need to tackle different approaches of marketing. One of them is the impression of producing something to the general public. A concept that is strong in marketing, but illusive to understand and tackle.
The illusiveness of it is mostly due to the way people judge and calculate your general public donation. If I'm a non-Perl programmer, and I wish to see how Perl contributes to the general public (me, for instance), I do not look at modules.
For the general public, the best way to view contribution is with applications. Applications give the impression of contribution greater than modules because they can be used by anyone: programmers, non-programmers and definitely non-Perl programmers. Sure, you could showcase a few technologies that would make their work much easier and many would appreciate it, but nothing scream "hell yeah" like a program someone likes.
Since having Google Buzz (the Google-laden Twitter), I've been receiving a flood of buzzes on various Ruby Gems. The unique issue was that all of them were applications. Applications I could use without needing to write anything for them. An app for providing me Xen like features for VirtualBox, an app for uniting and cleaning my javascript files into one (to save requests), an app for pre-processing LessCSS-written CSS, an app for this and an app for that.
People are busy creating programs while most of us (including myself, of course) are busy writing modules that could theoretically (or in practice) be used by applications. An important take on marketing is showing power, finesse, flexibility and beauty. The easiest way to show this (or perhaps, the most difficult way) is using actual application people can use without needing to write a CLI/GUI wrapper for it in Perl.
It might seem absurd for a lot of hardcore oldschool Perl programmers (and I expect a mirage of flames in the comments) but telling a friend that IMDB is written in Perl does hell of a lot more than saying "look at Catalyst, it's a really good MVC!" And it's absurd, I know, because that's merely the interface, but if there's one thing I learned from my offline activism is that what makes sense isn't what necessarily makes marketing.
Let's start writing programs, applications, things everyone can use!
Gots to do the bloggingz
I'll completely second that.
People tend to find apps cool, but frameworks just a required thingy to get something done. Frameworks can help to get things done easy, maintainable, fast. But it's not shiny by itself. Noone can use it directly. Although getting a Hello World up is now just a matter of minutes is nice, but useless to the enduser and in terms of marketing a language (btw. you can do that with most MVC frameworks in multiple languages already).
Python/Ruby did some nice marketing with getting apps running, most of them with polished UI, good usability and a very specific focus (see Trac for example).
But also perl can do that with projects like Shutter, Padre (just to name some). Also getting Win32 back in place with Strawberry Perl (Professional) helps here a lot. But we still need to keep on reminding people that IMDB runs on perl for example, because also I for myself was not aware of that. So thanks for that.
Since the majority of Perl programmers are actually sysadmins by day
Huh? What do you base that statement on? I'm guessing _you're_ a sysadmin, which isn't enough to draw conclusions from.
I've been employed to write apps in Perl my entire programming career (starting in late 1998).
I totally agree and I am trying to preach just that. Tomorrow, after your Moose talk we can discuss how you can build something cool on top of Padre. Maybe a desktop Google Buzzer?
I agree with all of your conclusions, but I don't agree with this premise at all. I know a small number of sysadmins who use Perl daily, but most of the Perl users I know are full-time developers.
Yeah I was hoping for a [citation needed] tag there too.
Btw. yes, I'm also mostly using Perl for real-world applications, although I'm also partly a sysadmin. So usually no perl one-liners or system glue.
To both Daves:
Duly noted. Perhaps my personal experience overcrowded my understanding/assessment. This wouldn't be the first and unfortunately probably wouldn't be the last. But duly noted and thanks for the correction!
Actually one of the interesting things about Perl is that due to it's history and origins in applied linguistics and just getting things done, I think that the user base of perl is pretty diverse compared to that of other open source scripting languages. The [dragging on forevever but now] up coming perl survey should tell us if this impression is actually true by the way.
No it won't tell us if that's true at all. The Perl survey is the mother of all sampling biases. It's not going to be taken by random system administrators who only incidentally use Perl for quick scripting tasks because they'll never hear about it.
It'll be taken by people who are active CPAN authors, participate in Perl user groups / mailing lists and are otherwise in the active minority of Perl users.
I'm in the latter group and I only incidentally found out about the Perl survey the last time it was held.
The debate about whether most Perl programmers are sysadmins first, programmers second is really beside the point. What's relevant is the number of developers, in absolute terms, who are developing applications with Perl, and where are all of these applications they are creating?
I'm one of the lucky ones: I'm a full-time developer, and I've got Perl-clued sysadmins backing me up. So where are all the applications I'm developing? The answer, sadly, is that they are largely too localized to be of use to the outside world. It would be nice to have time to package an app up and release it as something useful to the general public, but that takes cycles, and there's always more work to do, always more projects coming down the line.
Additionally, and this is likely the more important point, modules are inherently more portable and releasable (you know, "modular?") than applications. An application presents lots of surface area for the world-at-large to make demands of. A module (ideally) has a smaller, fixed API. And people using a module are generally programmers (in the general sense of the term). People using applications can be "regular" users. So if you think it's a chore maintaining a module...
In effect, I think it's not that we aren't developing applications or that we are preferentially developing modules, it's simply that modules are so much easier to release and maintain with the toolchain and community we've got, that the disparity between modules and apps has, over the past couple decades, become enormous.
Three cheers Sawyer X. I'm with the Dave's about most Perl programmers being sysadmins, but I've been preaching that we need applications released to the public for years. I know I've been doing it for years. It does two things:
1) It puts Perl on the map in people's minds Eye. IMDB, ShopZilla, and others are great and all, but most people don't know they're written in Perl, which is too bad. Apps that people can actually download and install (like MovableType and WebGUI) do let them know that.
2) If you've got a successful app that people can download and use or one that's a SaaS model like IMDB, chances are you can build a business around it. And if you do that, you're generating wealth. And if you do that, it creates jobs. And if you do that, people will start perking up and say, "Perl rocks, because I just got a job programming Perl!"
Adam Bellaire: While it's true that a lot of CPAN modules can't be easily made into stand-alone programs a lot of them can. There's a huge amount of CPAN that takes the form:
As long as they're just Perl modules they're mostly only of interest to Perl developers that use CPAN, but if they have even a basic command-line interface they could be used by a much wider range of people.
As an example if I want send SMS messages on Debian now I can:
The first result is a C program that's only useful in Poland but SMS::Send has drivers for operators all over the world. It also can't be trivially used by someone not familiar with Perl.
There's a lot of examples like that. I'd say the single most useful thing a new CPAN contributor can do is to write App::* wrappers for some of the more useful CPAN distributions that fit this pattern (stuff like MooseX::Getopt makes it really easy) and try to get those wrappers included in distributions like Debian, Ubuntu and Red Hat Linux.
That's an excellent suggestion!
In my life as a developer I don't care if frozen-bubble is written in Perl (it gives me a good feeling anyway :-) ). I appreciate the broad range of high quality Perl modules I can use.
I see the need for applications on the other hand. We want / need to convince users (managers are users) to realize what can be done with Perl. So that they let us do it in Perl.
Time is limited. Which is the best balance between modules versus applications?
Not easy to answer.
> I've been receiving a flood of buzzes on various Ruby Gems. The unique issue was that all of them were applications.
That's not true -- Look at http://rubygems.org/ and see New Gems or Most Downloaded. They are libraries. Same thing can be said against Python's PyPI http://pypi.python.org/pypi
> I've been receiving a flood of buzzes on various Ruby Gems. The unique issue was that all of them were applications.
I was referring to the buzzes I received.
Let me try and make it clearer: I don't necessarily think that all Gems out there are applications, or that even the majority are. What I am saying is that it is quite common for a Ruby programmer to create an application, perhaps more common than it is for a Perl programmer.
If I'm wrong, feel free to ignore. If I'm not, perhaps we should do something about it.
Cool apps would be Perl's holy grail. As long as the user doesn't have to touch cpan. Although cpan-minus is very cool. I'm curious which language has the most cool apps. Perl? I think not :(
I agree with all of your conclusions, but I don't agree with this premise at all. I know a small number of sysadmins who use Perl daily, but most of the Perl users I know are full-time developers.