While not quite as busy as I would like, the #win32 IRC support channel has so been highly successful. Having fixed most of the obvious flaws in Strawberry uncovered by people in the support channel, things have started to stabilise now.
In this steady state, we are seeing three specific problems surface against and again on a daily basis (for the type of user that clicks on the "Live Chat" link on the front page of a Perl distribution's website).
1. Nobody is there to answer, or not there fast enough.
The pattern we seem to be seeing amoungst the most need users (who don't change their nick from mib_$hexstring to something else) is that they have a typical tolerance for silence of around 3 minutes.
They will join the channel, ask their question, wait three minutes, then leave.
The existing infobot dipsy is almost worse then useless, because about a third of the time it creates the apparent situation where the user thinks that someone IS there to answer their question, but is intentionally ignoring them after the initial greeting.
There's a clear need here for a customer support bot. Something that monitors new arrivals for questions and informs the user that nobody is there right now, and they should lurk for a little bit (and provide information on when the most recent conversation was and how long they should wait).
2. Users expect Perl to come with an IDE.
"I've installed Perl, but I can't find where to edit/run/etc Perl files" is a major complaint. We even get some people that thing that the "CPAN Client" start menu entry is a Perl shell of some kind, then get confused when Perl code they type in doesn't work.
The editor part we plan to fix shortly with Strawberry Professional, but the other half suggests the need for some kind of shortcut to a "Perl Command Line", or at least something LIKE this so at least we can place an obvious-looking Start Menu entry for their perceived need.
I've been playing with Perl::Shell a bit more lately, to turn it into something suitably dumbed down and approachable, so this shouldn't be hard to solve.
3. Can't find Net/LDAP.pm in @INC ( giant wall of text )
The first two problems we can fix at a project and distribution level.
This problem, on the other hand, is a different kettle of fish.
This ordinary Perl error message is an endemic cause of complete failure on the part of the user.
Perl scripts are all over the place, most of them NOT part of a well structured CPAN distribution or PPM package.
The smarter Windows people can survive not having an editor, and they work out how to run the script.
This cryptic error, however, stops them completely in their tracks.
"Can't find Net/LDAP.pm in giant set of paths" (which is the specific case that happened to our Windows admin team in meatspace at work today) actually means "You need to install the distribution perl-ldap, using the PPM tool listed in the start menu entries".
That an error message like this even exists, instead of being at least something like "The Perl class 'Net::LDAP' is not installed on your machine: Can't find Net/LSAP in
For Strawberry Professional, I'm pondering the idea of adding a "Run a Perl Script" start menu program, built using perl and Wx, who's only job is to run a named perl script in a way that turns the cryptic stuff into vaguely useful instructions on what probably caused the problem, and how to fix it (and ideally, to automatically fix it for them).
I end up letting people run Perl by completely preventing them from ever running perl.
But since lots of people don't use the command line (they hit Perl via a batch script or similar) now I might also need to hijack perl.exe entirely to deal with it (except that breaks things that do pass-through code to child Perl's for process isolation reasons).
It's not surprising that Perl has some of the reputation it does, if a Perl coder can't reasonably give a
I posit that there's a whole swath of people that don't hate Perl for it's syntax, since they don't read all kinds of other ugly languages they use day to day.
They have it because running a typical Perl program as an untrained user is hard when it works, and impossible to setup when it is missing dependencies.
But I'm not really sure what, if anything, the core team could do at this point to fix this problem.