Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Thursday January 21, 2010
08:47 PM

The most damaging interface in the entire Perl ecosystem

[ #40120 ]

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 ..." is the real icing on the cake, because we don't even provide the poor guy running the Perl script with a useful error message that describes the failure in high level terms, let alone provide some suggestion on how to fix it.

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 .pl script to an admin and reliably have them be able to run it. Unable to know that they have to install one tiny PPM package, the code becomes "That shitty Perl script".

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I agree that "Can't locate Foo.pm in @INC" is a very poor error message. For a new user is must be worse than meaningless and as an experienced user the handful of times that it has been useful to me (i.e. messed up paths and not missing modules) I could have figured out anyway with perl -V or similar.

    A Google search for Can't locate in @INC [google.ie] turns up 128,000.00 hits. That is a large number but even more telling is the wide range of forums that they appear in. The "@INC" message is clearly a hinderance to

  • Perl::Shell is a minimalist module and as such it would be easier to support and maintain, but I've been using Devel::REPL with great success as my command line perl.

    --
    life is short
  • You really like to goad me to put my "evil hat" on. This is a crude example to show the concept -- it would need to be a bit more helpful and a bit more robust for real use.

    package Nice;
    use strict;
    use warnings;
    no warnings 'once';

    *CORE::GLOBAL::require = sub {
      my $mod = shift;
      eval { CORE::require($mod) };
      if ($@) {
        if ( my ($mod) = $@ =~ /\ACan't locate (\S+)/ ) {
          $mod =~ s{/}{::}g;
          $mod =~ s{\.pm$}{};
          $@ = <

    • Also, maybe try to trap the file and line number where they tried to require the module?

    • Nice first hack though. Seriously.

    • It'd be nice if Padre detected this in its console output too - and automatically opened a CPAN GUI to help the user install the dependency (http://padre.perlide.org/trac/ticket/70#comment:2)
  • 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).

    Eh, no, you don't have to patch perl.exe. Instead, put it in a module. Just like diagnostics [perl.org] does nothing but explaining warnings and errors better.

    You can load this module on the command line using -M, or you could set an environment variable like PERL5LIB, so it gets used in every Perl script that gets run from the batch file.

    • ... you don't have to patch perl.exe.

      If the executable supported localization and translation files, swapping in other error messages would be easier. (Replacing them entirely might not be as easy though.)

    • I can't load this module on the command line, as I am neither the person who wrote this code nor am I the person running this code.

      The people doing both the writing and the running are not on this website, and do not have the benefit of this suggestion (which is why any answer that involves eduction doesn't work in general).

      I can't modify the site perl script, because I'm only the vendor of the Perl distribution, not the site.

      And I'm a teensy bit dubious about PERL5LIB, one because it won't work under taint

      • So build Strawberry with -Dusesitecustomize, and put it in there. That's exactly what it's there for, and anyone who knows enough to know they don't want it can turn it off with the -f switch.
  • > 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 hate 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.

    So about the same as EVERY OTHER LANGUAGE. Python, Ruby and Java all have the same problem of not making it at all clear how to resolve missing dependencies. Certainly m

    • Perl doesn't even really make it clear there IS a missing dependency.

      It just says it can't load some file

    • The fact that so many other languages get it wrong does not excuse us for getting it worse.

      It *does* mean we have an opportunity, *if* we can get it right. And, given CPAN, we *can* get it right. All we need to do is send the right patch to the core maintainers, and convince them it's right. Alternatively, we could produce a module, and convince them to have the normal build process include that in a location that will normally get loaded in as core (maybe as sort of a 'usecorecustomize'ish type thing.)

      T