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 ]

masak (6289)

masak
  (email not shown publicly)
http://masak.org/carl

Been programming Perl since 2001. Found Perl 6 somewhere around 2004, and fell in love. Now developing November (a Perl 6 wiki), Druid (a Perl 6 board game), pls (a Perl 6 project installer), GGE (a regex engine), and Yapsi (a Perl 6 implementation). Heavy user of and irregular committer to Rakudo.

Journal of masak (6289)

Tuesday January 13, 2009
03:55 PM

Pretending that Envy is one of the Perl virtues

[ #38279 ]

Sometimes I read parts of _why's Poignant Guide to Ruby, and marvel at the inimitable writing style, the pedagogical comics, and the balance between explanations and, uh, story. But the other day I read The Tiger's Vest, and I realized that we in the Perl 6 community need to be really envious about two things in Ruby, otherwise we're not going provide good enough versions of these two things ourselves.

Actually, I'm not sure we need Envy to do this. It might be that this falls well under Hubris, whose definition (in the Perl context) is as follows, according to Wikipedia: "Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about."

It might well be that we need not look at other languages to excel in this area, but I think that's the easiest way for us to be motivated. It sets a minimum bar, shows what actually can be done. And what more or less needs to be done so that people won't say bad things about Perl 6.

Oh, and the two things? They're simply the two main things _why talks about in the chapter: an interactive shell and a documentation tool. Will go into detail about these now.

An interactive shell

This is not my main point for tonight, so I'll be brief. Rakudo has a REPL. It's — and I don't like to say this because I prefer to say nice things about Rakudo — not very good. Try it, and you'll see. (Just type perl6, and you're in.) The main thing lacking from it is that you can't declare a variable, hit enter, and then use the variable on the next line.

I understand the technical limitations behind this behaviour; I've had them explained to me. But the explanations just make me want to whisper, really softly, "I want results, not excuses!". Surely Perl 6 isn't so perfectly crystalline in its structure that a proper interactive shell (which, in case I didn't stress this enough, is a really good thing to have) is beyond its reach? I have enough motivation to see this happen that I'm willing to personally go ahead and implement an interactive shell that retains its variables between lines. (As soon as I figger out how to overcome the technical limitations, that is.)

Other non-essential but very desirable features of an interactive shell are also mentioned in the chapter: continuation prompts, nesting depth, tab completion. You get the idea. Envy.

A command-line documentation tool

_why presents Ruby's documentation tool ri with giant brown serifed letters, reverberating with double parentheses as if struck like a heavenly gong. Or as if a chorus of angels were heard from inside of its name, I don't know. It is described in the text, somewhat obliquely, as the "Most Blatantly Great Thing Since Michael Dorn". The bottom line is, easily accessible documentation matters.

And it takes time. Not so much writing the script that displays the documentation for a certain class, method, sub, operator, macro or other syntactic feature — that's an important task, but a relatively easy one compared to putting together all the documentation, making sure it looks nice, is complete, understandable and nice to read. In fact, since it takes time, I think we'd better start now.

I hereby pronounce the Userdocs For Christmas project (U4X) started. Our official goal shall be to provide easy-to-access comprehensive user documentation, through a ridiculously easy-to-access command line tool, providing snippets of Perl 6 clarification so perfectly worded and so brilliantly illustrative that the unsuspecting reader will be brought close to tears.

The documentation writing itself will be done in a controlled manner, where "controlled" means that people with tuits get to make sure that things are consistent. All the documentation will be written in Pod, the Perl 6 version of POD. More information will be found in the U4X README file which I just committed to the Pugs repository.

When I look at all the things that are going on in the Perl 6 community right now, I think that Envy really needn't be one of the Perl virtues. It could very well be Pride. But for that to happen in time for the release of Perl 6.0.0, an interactive shell and exquisitely good documentation are needed. At least if Perl 6 is also to be the most blatantly brilliant thing since Michael Dorn.

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.
  • Was this a Perl 6 specific thing? I find perldoc to be a wonderful tool myself but I don't know its state in P6.

    • Was this a Perl 6 specific thing? I find perldoc to be a wonderful tool myself but I don't know its state in P6.

      I realize I could have been more clear in this regard. Yes, this was a Perl 6-specific thing; I also like perldoc very much. Both on the command line and on the web [perl.org].

      The reason that the situation is different for Perl 6 is that Perl 6 is a complete rehaul of most everything. We can't just blindly inherit the docs, and we need to prepare new docs of the same high quality before our first major release. Documentation is one of those little things that matter a lot.

      In doing this, I think we should take not only

  • If i want to quickly evaluate a Perl expression, I open scite, set the file language to perl.

    write code, hit F5 this is working great for me.

    for browsing perldoc, I prefer to use EPIC.

    of course if you can create a tool that combine the two, and have can run in terminal emunlators or dos, this would be great, this will be great.

    i think one can easily an emacs or vim mode to do this, but a didicate simple program is welcomed
    • Care to elaborate on that?

      • "So, you want to learn perl? Where to start? A good place is " not one, but two places -- one of which is perlintro, and the other of which is even more places: a bunch of books.

        And after that, we're left to just the list of books, or maybe we followed the "perl documentation" link and are now reading the perldoc.perl.org root page [perl.org], which again has a link to perlintro and then a lot of meta information about perldoc.perl.org.

        So, learn.perl.org basically does nothing to capture the first-time reader's inter

        • "So, you want to learn perl? Where to start? A good place is " not one, but two places -- one of which is perlintro, and the other of which is even more places: a bunch of books.

          And after that, we're left to just the list of books, or maybe we followed the "perl documentation" link and are now reading the perldoc.perl.org root page [perl.org], which again has a link to perlintro and then a lot of meta information about perldoc.perl.org.

          So, learn.perl.org basically does nothing to capture the first-time reader's interest -- such as getting them started doing something interesting. I would expect a 'learn.something' to have e.g. a series of lessons. It would be better named 'books.perl.org' in its current state.

          Aye. IMO, there's nothing factually wrong with the page; it's just not very captivating. Imagine what you could do if you didn't take the web visitor at her word and just replied "well, there's perlintro, and a couple of books..." -- you could showcase how one could solve cool but tricky problems with just a few lines of Perl, you could show how a few common modules solve even trickier problems. You could have links to a couple of common 'starting points' in Perl: CGI, shell scripting, bioinformatics... the

  • I looked all over the place to find a solid replacement for irb in the perl world and there really just isn't something like it. I must assume that the reason is that perl people are generally more ok with doing things with perl -e, but the tab completion in irb is enough to make me never want to leave ruby.
    --
    --fREW
    http://blog.afoolishmanifesto.com
    • I looked all over the place to find a solid replacement for irb in the perl world and there really just isn't something like it. I must assume that the reason is that perl people are generally more ok with doing things with perl -e, but the tab completion in irb is enough to make me never want to leave ruby.

      You, sir, have understood the point of my post. Now, let's make sure we get tab completion by Christmas. And all the other good stuff.

  • I think we need to talk more about these issues. Too many perl people seem to be grumpy about this kind of change. It's like when I posted somewhere about andand for perl5. Everyone's answer (mostly) was just "Don't do that!" I think that if we get some kind of ipl going we should go out of our way to make a web based version like _why's tryruby. Imagine telling people about that! Everyone says perl6 is vaporware; but having a web based interpreter would be just so excellent that it might get some mor
    --
    --fREW
    http://blog.afoolishmanifesto.com
    • I think we need to talk more about these issues. Too many perl people seem to be grumpy about this kind of change.

      I think that's a slight generalization. In the Perl developer community, and in the Perl 6 one in particular, you're more likely to find openness to new ideas than not. At least that's my experience.

      It's like when I posted somewhere about andand for perl5. Everyone's answer (mostly) was just "Don't do that!"

      This one [perlmonks.org]? I think the responses were very helpful, with example code and all. Searching the page gives one "don't", which isn't directed towards you. It might be you're expecting too much Ruby syntax out of Perl 5. :)

      I think that if we get some kind of ipl going we should go out of our way to make a web based version like _why's tryruby. Imagine telling people about that! Everyone says perl6 is vaporware; but having a web based interpreter would be just so excellent that it might get some more interest!

      Here I am able to provide some historical context: there was one just like that at one time, du

      • Glad you agree about ipl.

        More on grumpiness: I use the cgiapp framework. In general I think a lot of the wisdom of rails can be used in other web frameworks, even if they aren't as heavy as rails. I recently read a thread about how many actions should be in a controller, how long actions should be, etc.

        There were numerous cgiapp people that said that they had 100 actions in their controller, or that their actions were 250 lines long, etc. I think that is a mistake and when new people come in and a
        --
        --fREW
        http://blog.afoolishmanifesto.com
  • This post got me excited. I think both tools are needed. I have been programming in Perl for quite some time now, more than 7 years. Perl is still my favorite language, even though my main programming language that I use at work is not Perl at the moment. I do understand completely what you said and I concur that ipl and doc command line tools are great addition to Perl 6. When I got introduced to ruby's irb (and even python via IronPython's ipy), I immediately thought that those are indespensable tool