Slashdot Mirror

Denise writes: "'What happens if you get a bunch of academic computer scientists and implementors of languages such as Perl, Python, Smalltalk and Curl, and lock them into a room for a day? Bringing together the academic and commercial sides of language design and implementation was the interesting premise behind last weekend's Lightweight Languages Workshop, LL1, at the AI Lab at MIT.' Simon Cozens report, on perl.com, says it wasn't the flame fest you might have imagined."

Denise writes: "'What happens if you get a bunch of academic computer scientists and implementors of languages such as Perl, Python, Smalltalk and Curl, and lock them into a room for a day? Bringing together the academic and commercial sides of language design and implementation was the interesting premise behind last weekend's Lightweight Languages Workshop, LL1, at the AI Lab at MIT.' Simon Cozens report, on perl.com, says it wasn't the flame fest you might have imagined."

bleechack writes: "Looks like Perl.com is fully ready for the release of Lord of the Rings with this week's "Lighter Side of CPAN"."

bleechack writes: "Looks like Perl.com is fully ready for the release of Lord of the Rings with this week's "Lighter Side of CPAN"."

horos1 writes: "Hey all, I just ran across an article over at O'Reilly - Perl 6: Not Just For Damians which covers a lot of the negative commentary posted by slashdot on perl6 'featureitis'. Very interesting read, and IMO makes a hell of a lot of sense."

rob_99 writes: "Cool new mod_perl article at perl.com documents building a large scale ecommerce solution w/ mod_perl & apache!" Pretty cool stuff - it's kind of funny to think how ephemeral their work turned out to be.

chromatic writes "On the heels of Larry's most recent revelation, the mad scientist of Perl (Damian Conway) has followed up with Exegesis 3. His article gives working Perl 6 code examples of Larry's design decisions." Lots of good stuff in here.

chromatic writes "On the heels of Larry's most recent revelation, the mad scientist of Perl (Damian Conway) has followed up with Exegesis 3. His article gives working Perl 6 code examples of Larry's design decisions." Lots of good stuff in here.

rob_99 writes: "The third installment of the Apocalypse is out!" You may have missed the first or second Apocalypses. This one is roughly "all about operators".

nealbutler writes: "This is up on perl.com, and I suppose a lot of people have seen it, but I think it's cool enough to warrant an article! wxWindows, the free C++ Crossplatform GUI framework is now available for perl! I've wxPython, and it rocks, so Tk/Perl's days may now be numbered...My main development platform is (unfortunately...) Win32, and Tk/Perl doesn't have half as much Win32 stuff as wxWindows does (e.g. accessing proper windows dialog boxes, etc.)."

CosmicDreams writes: "Last April fools, I was indeed fooled by a slashdot article that claimed that Python and Perl developers were going to join forces and merge their current development trees into a new computer language called Parrot. It seems as though my foolishness was well placed. Today I came across this story In the article, it talks about the ongoing progress of the language and what plans the developers have for the near future. Now I'm so confused I don't really know if this is for real or not. Does someone know if this is the same Parrot programming language. I don't want to place my foolishness foolheartedly."

Anonymous Coward writes "I'm sure I'm not the first to report this, but Perl.com put up a synopsis of Larry Wall's annual report on the state of Perl. "

Anonymous Coward writes "I'm sure I'm not the first to report this, but Perl.com put up a synopsis of Larry Wall's annual report on the state of Perl. "

flounder_p queries: "I have recently started playing with the Ruby programming language and think it's really great. I was just wondering why you guys think Ruby has not caught on more in the open source community than it has? How many of you guys are using it? Will it ever catch on or will it always be looked at as yet another scripting language? Don't get me wrong scripting languages are great (and I live by Perl) but I still hope to see Ruby catch on more. I would like to hear opinions on things on why Ruby is good or bad not on why OOP is good or bad. We have already had that discussion here." On a side note, a little birdy tells me that BlackAdder has plans for Ruby support in its next beta.

jdavidb writes: "Dr. John Conway (author of the famous "Game of Life") has a wonderful algorithm for finding the day of the week for any year in history that you can do in your head. It's so easy and elegant, in fact, that someone has decided to write a poem about it. Shades of DeCSS haikus! What a marvelous example of how mathematics is a form of (free and protected) speech. As if to further illustrate that computer code is just another form of speech, there is an implementation of this algorithm (in Perl of course)!"

An AC sent in this article at perl.com which discusses new perl mailing lists set up especially to answer beginners' questions. Hopefully they're not all being answered with "Go buy Learning Perl" or something like that.

willmurat writes: "I read about Rebol in an article in UnixInsider months ago. It seems to me a very interesting language, with new features and trying to bring new paradigms in programming. But (always there is a but ...), it isn't Open Source and no institution is responsible to maintain that language. The only responsible party is Rebol Technologies. I'm not saying this is the right way to failure; there are examples of success following this way (Visual Basic and Delphi, for example), but I think a business strategy like that isn't good anymore. See the current developing of Perl version 6 for a very good example of language discussion. Seems to me the owners of Rebol language are limitating the popularization of that language choosing that way of dealing in this issue ... Is there any future to popularize a language that way?"

sumengen writes: "Damian's writing a series of articles parallel to Larry's Apocalypses. These 'Exegesis' articles will show full perl6 programs, with commentary exlaining the new features. The first Exegesis (numbered 2, to keep in sync with Larry) shows a perl6 version of a binary tree program from the Perl Cookbook. Get excited to see things like:
my int ($pre, $in, $post) are constant = (0..2);"

sumengen writes: "Damian's writing a series of articles parallel to Larry's Apocalypses. These 'Exegesis' articles will show full perl6 programs, with commentary exlaining the new features. The first Exegesis (numbered 2, to keep in sync with Larry) shows a perl6 version of a binary tree program from the Perl Cookbook. Get excited to see things like:
my int ($pre, $in, $post) are constant = (0..2);"

Larry Wall has written the second article in his "Apocalypse" series about Perl6. If you missed the first article, you might want to read that one first, or see the previous discussion.

Larry Wall has written the second article in his "Apocalypse" series about Perl6. If you missed the first article, you might want to read that one first, or see the previous discussion.

raelity writes "Larry Wall provides some insight into the design of Perl 6 on www.perl.com. "People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing. An Apocalypse is supposed to reveal good news to good people. (And if it also happens to reveal bad news to bad people, so be it. Just don't be bad.) What I will be revealing in these columns will be the design of Perl 6. Or more accurately, the beginnings of that design, since the design process will certainly continue after I've had my initial say in the matter." " This is a really interesting article and worth reading if you're at all into Perl. Full of Wallisms, entertaining and insightful.

raelity writes "Larry Wall provides some insight into the design of Perl 6 on www.perl.com. "People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing. An Apocalypse is supposed to reveal good news to good people. (And if it also happens to reveal bad news to bad people, so be it. Just don't be bad.) What I will be revealing in these columns will be the design of Perl 6. Or more accurately, the beginnings of that design, since the design process will certainly continue after I've had my initial say in the matter." " This is a really interesting article and worth reading if you're at all into Perl. Full of Wallisms, entertaining and insightful.

chipmunk writes "My prayers have been answered! Larry and Guido have joined forces to produce Parrot, what will surely become the best language ever written. The power of Perl and the sanity of Python. The Py3K and Perl 6 development are merging, with Jeremy Hylton and Dan Sugalski as joint development leads. Read more in the press release on use Perl;, and see a joint interview on perl.com!"

It's about time. It's like the right brain and left brain are working together, at long last. O'Reilly has already inked a deal to publish Programming Parrot, and Yet Another Society is set to merge with the recently launched Python Software Foundation. Both Guido and Larry will be working for ActiveState.

Ravagin asks: "OK, I'm trying to teach myself Perl, and I'm doing fairly well, but I'd like to be able to take it with me, as it were. I've got a Palm IIIxe and a Palm Portable Keyboard, and was wondering if there was a port of Perl to the Palm OS (as there is with C and BASIC)? It doesn't seem to me that it would be extremely difficult. And before you say it, my C skills are way too primitive to do it myself. The Ten Perl Myths Page says it's in the works, but that's from a year ago. None of the major palm software sites have anything, but is someone perhaps working on it?" Wow! Now this is something that would actually get me to dust off my (unused) Palm VII. Of course, you'd have to do quite a bit of coding to get a Perl interpreter (and base modules) to fit in 2 megs or less. Porters might have better luck with the 8MB Palm models but even that's kinda tight. Do any of you see Perl on the Palm platform anytime soon, or is it a pipe dream?

Kaufmann writes "Good old Perl guru Nathan Torkington has an article on O'Reilly's perl.com about "What every Perl programmer needs to know about .NET". It's quite short and, unsurprisingly, favourable to .NET (although not to Microsoft). Points to the SOAP module on CPAN and a bunch of other stuff. It contains a nasty error, though: claims that Java is the only language that compiles to the JVM. Check it out anyway."

Kaufmann writes "Good old Perl guru Nathan Torkington has an article on O'Reilly's perl.com about "What every Perl programmer needs to know about .NET". It's quite short and, unsurprisingly, favourable to .NET (although not to Microsoft). Points to the SOAP module on CPAN and a bunch of other stuff. It contains a nasty error, though: claims that Java is the only language that compiles to the JVM. Check it out anyway."

Kaufmann writes "Good old Perl guru Nathan Torkington has an article on O'Reilly's perl.com about "What every Perl programmer needs to know about .NET". It's quite short and, unsurprisingly, favourable to .NET (although not to Microsoft). Points to the SOAP module on CPAN and a bunch of other stuff. It contains a nasty error, though: claims that Java is the only language that compiles to the JVM. Check it out anyway."

richw showed us an excellent story talking about why language advocacy is bad. Its an excellent piece, and although many of the points he writes about are specifically related to Perl Programming, many of them can be equally applied to the irrational ways that people approach things like politics or Slashdot discussions.

In addition to all the other books he has insightfully reviewed, chromatic has written this review of CGI Programming With Perl. This books sounds like a great resource for the builder of dynamic Web sites with a Perl background. And isn't it nice to see a book with "an unapologetic Unix flavor"?

CGI Programming with Perl author Scott Guelich, Shishir Gundavaram, & Gunther Birznieks pages 451 publisher O'Reilly & Associates rating 9 reviewer chromatic ISBN 1-56592-419-3 summary Your guide to the protocols and practices of CGI programming, with a look at current tools, tips, and tricks.

The Scoop Static web pages sufficed back when the web was young. Information flowed one way (like it does on most corporate sites today). Those days are long behind us -- if you want dynamic and interactive content, a whole host of technologies have appeared to fill in the gaps.

Enter Perl and CGI -- the original Swiss Army chainsaw of programming met the standard for exchanging data over HTTP and it was good. Thousands and thousands of programmers discovered this combination of power and simplicity, and the web has never been the same. Now, it's your turn to descend into the mysteries of query strings and stateless transactions, hoping to emerge successfully with the knowledge of simple -- yet interactive -- web programming.

In this second edition, the authors have gone far beyond CGI circa 1996. New topics include XML, search engines, security, and high performance Perl-based alternatives to CGI. How far we've come...

What's to Like? The book begins with an explanation of HTTP. Understanding the underlying protocol gives a picture of the whole process. The same is done for CGI, examing the interface -- the environment, input, output, and headers. It's simple enough that the description never bogs down, but detailed enough to explain difficulties CGI authors must work around (session management being high on the list).

From there, it's on to forms and HTML and, before spending much time trying to write a custom decoder for form data, it's off to CGI.pm. (That's important, because it's hard to get this right, even for authors of some other CGI programming books.) As befits the module, this chapter explains handling input, generating output, and handling errors.

Shift gears for a second, and think about embedding your code in your HTML. Try SSI, HTML::Template, or Embperl. (This is just a taste of the techniques available for templating -- see Template Toolkit or Mason for other nice ones.) Following that, grit your teeth and learn some of the JavaScript you've been putting off. Use it to add an additional client-side form input checker, hook it up to your Perl with WDDX, or discover the powerful Bookmarklet.

Consider security in chapter 8 -- now that you've learned some cool tricks but before you know enough to get into real trouble, discover the vulnerabilities and how you can program around them. Use Perl's Taint mode and your web server configuration to help you out. Do not skip this chapter -- read it, then read perldoc perlsec until you get it. (It's a good chapter, but security can be hard, so don't rely on just one source of information.)

The rest of the book is a tour of various tasks you might want to accomplish. They're good too, but things shine again in the last three chapters, with help for the new, curious, frazzled Perl CGI programmer. How do you get rid of that annoying 500 server error? How can you make your program worth using for the next three years instead of worth throwing away every three months? How can you write something that will handle a hundred users a day? A thousand? A front-page link on Slashdot? (The answer is more than just FastCGI or mod_perl, though they're definitely the heavy guns.)

It's definitely time for a second edition of this tome. The expanded coverage of CGI.pm and templating technologies is a welcome addition. Promoting the use of the existing well-tested, documented, and debugged tools will, hopefully, lead to more maintainable code. Unlike some other books, the example code is clean and worthy of emulation. Hit the references and recommendation section in Appendix A for more good information, including relevant RFCs. Really. (It's a good sign for a Perl book to mention both the CPAN and perldoc, as in Appendix B.)

What's to Consider? Be careful about copying code blindly from the first few chapters without reading at least chapter 8 (and perldoc perlsec in Perl's included documentation)! Simple examples are appropriate for teaching and personal testing, but could have disastrous consequences on publicly-accessible servers. To the authors' credit, even the simple example code runs with warnings, taint mode, and the strict pragma.

You'll need to know some Perl -- at least enough to follow along with somewhat-idiomatic code. Platform and portability wise, there's an unapologetic Unix flavor to the examples. Nearly everything should work on Win32 and other operating systems, but be aware of certain differences. As for web server information, it's Apache-specific. (Configuration for other platforms will be similar, but is left as an exercise for the reader.)

Some topics could use more treatment. It would have been nice to have more information on HTML::Mason (though admittedly complex, it's powerful and probably deserves more than a two page introduction) and XML and Middleware. New technologies like RSS and WAP need tools and users and programmers. There's also more to say on debugging CGI applications, though a pointer to the facetiously named Idiot's Guide could be helpful.)

The Summary Newly updated, chock full of good advice and, above all, high-quality code, this book is a great place to learn how to focus your Perl skills in a popular direction. Follow the advice presented, ask around for help if you need it, and have fun. Don't bother spending 24 hours or 21 days or whatever it is now, learn CGI programming with Perl the right way.

special thanks to the amazing Simone at O'Reilly for her help making these and other reviews possible!

Table of Contents

1. Getting Started
2. The Hypertext Transfer Protocol
3. The Common Gateway Interface
4. Forms and CGI
5. CGI.pm
6. HTML Templates
7. JavaScript
8. Security
9. Sending Email
10. Data Persistence
11. Maintaining State
12. Searching the Web Server
13. Creating Graphics on the Fly
14. Middleware and XML
15. Debugging CGI Applications
16. Guidelines for Better CGI Applications
17. Effeciency and Optimization

1. Works Cited and Further Reading
2. Perl Modules

You can purchase this book at ThinkGeek.

Kaufmann writes: "In this interview with Joe Johnston (on O'Reilly's Perl.com), Larry Rosler (of HP, one of the people who helped put the 'ANSI' in 'ANSI C') shares his thoughts and advice on the value of standards, optimising Perl code, how Sun should handle Java, and programming in general. Will we ever see a Perl Language Subcommittee too?"

Kaufmann writes: "In this interview with Joe Johnston (on O'Reilly's Perl.com), Larry Rosler (of HP, one of the people who helped put the 'ANSI' in 'ANSI C') shares his thoughts and advice on the value of standards, optimising Perl code, how Sun should handle Java, and programming in general. Will we ever see a Perl Language Subcommittee too?"

Kailden asks: "I've run across several references to Ruby, a scripting language that claims to be a hybrid of Perl and Python. Supposedly, this language has taken Japan by storm. I'm looking for Slashdot's verdict before jumping in. Has anyone outside the Ruby site used this language? What advantages/disadvantages have you found?"

Simon Cozens writes "I've written a summary of what's new in the 5.6.0 release of Perl for this www.perl.com article. " The article does a good job of evaluating what's come out - worth reading if you're a Perl Monk

brockgr was the first to note that Perl 5.6.0 has been released and has begun propagating through CPAN. Anyone have a changelog or something I can link to?

thing12 wrote to us to say that the fine folks of Perl have a 5.6.0 release candidate announced.

aarestad writes, "Just saw this on perl.com: the new beta leading to perl 5.6. Read the announcement." It's mostly bugfixes. Pumpking Sarathy says we're on track for a 5.6 final release candidate by Feb.28.

aarestad writes, "Just saw this on perl.com: the new beta leading to perl 5.6. Read the announcement." It's mostly bugfixes. Pumpking Sarathy says we're on track for a 5.6 final release candidate by Feb.28.

Tom Christiansen , perl god, writer, and the guy that once kicked me out of #Perl for asking a question about sockets has written us another excellent feature. This one talks about modern keyboards, and the problem with them. It's an entertaining piece with gratuitous Who references so it's all good by me.

The following was written by Slashdot Reader and Perl God Tom Christiansen .

He stands like a statue, becomes part of the machine
Feeling all the bumpers, always playing clean
Plays by intuition, the digit counters fall
That deaf, dumb and blind kid sure plays a mean pinball.
from Pinball Wizard, sung by Elton John in Who's "Tommy"

When was the last time you really zenned out on a pinball machine? You know what I'm talking about: that transcendent state of consciousness in which you're no longer carefully calculating what to do and when to do it. You're completely oblivious of anything in the universe except for the ricochets of that silver ball. You're so totally in the groove that those extra balls and replays just keep racking up. Spectators and would-be players come and go, but their presence barely registers in your mind. Hours later, when it's all over and you finally step away from the machine, you find that words come haltingly; you've gone a bit nonverbal. Drifting off to sleep that night, instead of getting darker when you close your eyes, the world gets brighter as hypnagogic flashes from today's games explode in your mind's eye like comets dancing with lightning.

It's a pretty neat feeling, isn't it? You were in an altered mental state--a high, if you would. And like any other high, pinball zen is a bit addicting. Not only will this high leave you a lot less poor than plenty of others would, the only physical side-effects are apt to be some sore pects the next day.

This pleasant state of mind is hardly limited to pinball. You can become one with your skis and the powder you're flying over. You can become one with your musical instrument of choice. And, if you're a hacker, you can become one with your computer.

I'm not talking about sitting for hours on end, clicking from one web page to the next as trivia trickles passively in. I'm talking about actually creating or seriously manipulating something, not just impersonating the couch potatoes down the hall in the TV room. You're in the groove; you've got all the right moves down so pat you don't even think about doing them. The world again fades away. There is the computer. There is you. There is nothing else. And this is good.

This blissful state of being one with your computer doesn't actually have much to do with your computer. Paradoxically, the computer just gets in the way, a constant reminder of irrelevant physical constraints and realities. As long as your brain needs to spend time thinking about hardware, like the keyboard or the mouse or a flickering monitor or a whining disk drive, you will be forever denied access to the altered states. That's because it's not the computer itself you're trying to become one with. It's the software world that you're trying to enter. Only when the physical world recedes from conscious awareness can enlightenment become possible.

When you're learning a new piece of music, bringing it up to performance tempo and committing it to memory, a funny thing happens. After enough practice, it feels as though your fingers themselves remember how to play the piece. You don't even watch them. They've a job to do, and once they've it, can go about that job remarkably free of direct supervision. The key to clearing the mind of the outside world so that the program becomes the dominant reality is what a musician would call "finger memory". (You might have heard athletes or dancers refer to it as muscle memory, but when we're talking about using the computer, it really is the fingers that count.)

Of course, that's not really what's going on; it only seems to be. Your fingers don't really remember. But a part of your brain that controls them does, even though "you" don't realize it. What's happened is that you've so successfully assimilated the moves needed that conscious direction is no longer required. The little lighthouse keeper behind your forehead can worry about other things, assured that your fingers will do the job you've trained them to do. Your eyes are on the screen, the program in your head, and your head is in the program. Your fingers become an unnoticed extension of your will. They're are no more a conscious concern when typing commands than are your feet when you decide to walk across the room. That's probably just as well, because if you ever thought too much about how walking is really just perpetual falling and nick-of-time rescue, you'd probably stop being able to do it as well as you can now.

It's a shame, but many people never achieve the same zenning out with a program that they may with a pinball game or a musical instrument. Still, it can and does happen, and although it's something of an uncanny thing to witness someone else doing, it's a beautiful one to experience personally. In this satori-like state of experiencing knowledge without thought, the program's commands have become so deeply etched into your wetware that low-level tasks no longer require conscious direction. Your fingers seem to remember to do on their own. Now on automatic pilot, they dance across the keyboard as quickly and as accurately as any performing pianist's fingers move, and just as automatically.

This isn't to say that the keyboard is the sole path to blindingly efficient computer use. Far from it! To be honest, the keyboard is sometimes the worst possible choice. It's entirely dependent on the task. For example, if you're playing xbill, the hacker's favorite video game, you certainly don't want to try use the keyboard instead of the mouse. It's just going to slow you down. But neither does that mean that the mouse is always the best choice for all interactions.

Here's another example. I once tried using xmame to play millipede. Using the keyboard for movement was excruciatingly painful, but the mouse wasn't all that much better. I realized that I would never become one with the millipede using either access device. But just a few feet away stood a real millipede game (yes, I actually do own one). I have no problem becoming one with that version, even though as far as the software goes, it's the same as what xmame is running. Why? Because the real game has a trackball, that's why! No longer tied to a clunky input device, I could sail along so fast that the non-rational part of my brain could take over, and like Tommy, play by intuition alone. After the first 200,000 points, you get to play with eight darting spiders simultaneously. Try it sometime. It's a real trip.

There's no question that certain tasks, the keyboard is clearly the optimally efficient input device. Consider the game of rogue or one of its more recent incarnations. You wouldn't want to use anything but a keyboard there. The command set is just too rich. Trying to play the game with a mouse and menu interface instead of a keyboard one would slow you down by at least two orders of magnitude. It would be as bad as trying to play millipede with a keyboard, if not worse. As someone who at times spent most of his non-hacking waking hours at university playing rogue, srogue, larn, moria, and nethack, you'll just have to take my word on this. I certainly became one with the game. My fingers flew across the keys; my eyes never left the screen. I never had to think about how to do what I wanted to do, because no sooner did the desire enter my head than my finger memory took care of it.

When I wasn't playing rogue at university, I was hacking on code, for which I used a popular rogue-variant called vi. Yes, I know you probably think of vi as an editor, but I've always found people more receptive when I explain that it's actually a video game that gets a job done, too. In any event, the command set and design philosophy of the two programs overlap well enough to permit cross-competence between them. And as with rogue, I could zen out on vi. I was tremendously lucky I could, too, because most of the classes in my compsci program required more than 10,000 lines of code for each course. Now, try taking two or three of those classes in one term. You had to have a powerful and super-efficient editor, and you had to let the mechanics of the editor fade into the background, or else you just didn't survive. By zenning out, you ascended to a higher plane of productivity and did things that you normally couldn't do.

It sometimes seems that as time marches on, fewer and fewer people will get the chance to experience the sublime joy of becoming one with their computer. It's as though hardware and software manufacturers were all conspiring to render this good, clean high an unattainable one. It's not illegal, at least as far as I know, but for most people, it might as well be. In pursuit of the dubious goal of producing idiot-proof, zero-learning-curve programs, even programs intended for long-term, heavy-duty use such as an editor--arguably the most important piece of software you'll use--have been turned into children's toys, effectively expert-proofed. In mindless and unexamined pursuit of false efficency, the programs' authors have sacrificed all the design attributes that let our fingers go about their proper business, got our faces up out of the mundane mechanics, and let our minds transcend the hardware and get into the program. They installed, if not outright roadblocks, then velocity regulators and gratuitous speedbumps.

How did this ever happen? Let's start with why the current crop of keyboards are suboptimal in the extreme. There's a general rule (Fitts's Law) that says that the farther away something is, the larger it needs to be for equally swift access. This is true even if you are looking at the keys (but don't do that--see below), and fatal if you aren't. Distant keys like SHIFT, ENTER, TAB, CONTROL, and the spacebar used to be larger, but they keep getting smaller as more and more vanity keys get added to your main keyboard. Look at an old Sun keyboard. Notice how SHIFT is bigger than CONTROL, and CONTROL is bigger than TAB. This size corresponds to how much relative use you make of those keys. Oh, and the CONTROL key is both large and conveniently located on a Sun keyboard. What a joy.

Now go look on the cretinous keyboard that came with some poor sot's Wintel box. The spacebar, the most important key on the whole keyboard, is but a shrivelled and shrunken vestige of its former self. The ESCAPE key has been moved to the penalty zone, the CONTROL key is both distant and small (that's two strikes), and there's a CAPSLOCK key that's just as big as the TAB key. Hello? What are these people thinking? That I want to hit CAPSLOCK as often as I do tab, and that I don't care about CONTROL or ESCAPE? This is all nuts. The proper place for a CAPSLOCK key is in a different hemisphere from you. If we ever manage find out who invented that abomination, we're all going to show up for the lynching party, but we'll have to wait our turn in a line of programmeers stretching all the way from Boston to Mountain View.

If it were only the outlandishly rococo keyboards they were shoving at us, we hackers might still have a chance to become one with our computers. After all, we could always get a real keyboard instead, one with a decent layout and sans penalty zone.

But really, this is but the least of our many problems. First of all, there's no end of brain-damnged programs these days which both expect and require you to constantly enter and exit the penalty zone. This destroys your concentration, because you can no longer get there and back again while still looking at the screen. You incur a context-switch penalty that feels like a speedbump in your typing. It slows down your hands, and it interrupts your eyes. Once that happens, your concentration takes a severe blow as you're forced to deal with mechanics, once which you cannot internalize or omit.

The next gross inconvenience is requiring chorded key combinations. Any time you have to hold two or more keys down at the same time, this becomes more difficult to finagle. Compare how difficult it is to type a CONTROL-G chorded combination with a simple, unshifted `g'. If you ever need to hit a chord with more than two keys, such as CONTROL-ALT-SHIFT-F11, you're in serious, serious trouble. This kind of thing is especially arduous on keyboards lacking duplicated left and right versions of the modifer keys. There's a very good reason we have two SHIFT keys. We should have two control keys as well, and these should be easily accessible without looking. It's a lot easier on the hand to use the right-hand SHIFT key with a letter like `e' or `g'. Why should it be any different with CONTROL, ALT, or the vanity keys?

If you're striving for efficiency, it's best to stay away from chords entirely. If you look at the way popular video games like rogue and vi work, their command structure consist mainly of single, non-chorded keystrokes, or sequences of single keystrokes. That's why those games are inherently easier on the typist than games like emacs are, where all your most valuable real estate has been thrown away, and every command is now a chord. Chorded commands are harder to type because you have to hold down the SHIFT or CONTROL key, but in a program designed for efficient use, these are relegated to rarer activities, so the impact is minimized. The easy stuff is easy, and you never have to slow down, or even look down.

Consider how much easier it is to type a `/' to start a search than it is to start a search instead of a ALT-S, or horrors, pulling down a menu. There's no reason that a slash can't mean a search in context where it makes sense. This wouldn't mean that if you were typing in a path name in some text box that a search window would pop up. You simply make it context sensitive. Humans, you know, are really very good at context. Check out this sentence: "Can you please can the can-can while I'm in the can, man?" No problem. You see, our brains don't work off of a context-free grammar, and there's no reason that commands, keystroke or otherwise, should. In fact, because our brains do not work off of a context-free grammar, making our command set context free would be running against our inner natures. It's just not how we think.

Besides the useless vanity keys stealing invaluable real estate from the main keyboard, we are saddled with an ever-growing number of extra keys in the penalty zone, such as function keys, INSERT and its friends, arrow keys, and relics out of the shrouded mists of antiquity such as SysRQ and Scroll Lock. I'm sure there will be more in a year or two.

Can you imagine how painful it would be if you were typing in some code or a letter, and every time you wanted to go to the next line, you had to use ENTER key way over on the numeric keypad? That would be nuts, wouldn't it? So can anyone tell me why programs expect you to switch back and forth between the real keyboard and the penalty zone? Apparently nobody ever told them that the closer something is, the easier it is. According to Fitt's Law, something right underneath you is infinitely large, and, consequently, the most readily accessible. Proximity combined with non-chorded keystroke commands is why the rogue-style movement ("hjkl") is easier on the hand than emacs-style movement (CONTROL-B, CONTROL-N, CONTROL-P, CONTROL-F), and both of these are easier by far than using arrow keys over there in the penalty zone.

The much vaunted arrow keys, ostensibly easier to use for cursor motion, are in fact tremendously harder to use. First of all, if you're mixing commands over in the penalty zone with other commands which are on the keyboard, you're never going to achieve keyboard satori. You've got too much back-and-forth going on to find your grove. Your eyes act as a bridge linking two virtual worlds, one inside your head and the other inside your computer's memory. With arrow movements, they have to desert their post as vicar and go slumming in the real world for a while to play tour guide long enough to get you there and back again.

The second reason the arrow keys are inherently evil is that they are set in an arrangement designed by a masochist, probably the same nimrod who stuck us with the CAPSLOCK key. Even if all you were doing was keeping one hand poised above the arrow keys and never switching keyboard domains, you still would be slowed unacceptably. That's because the up arrow and the down arrow are directly aligned vertically. Your hand despises this, which is why the rest of the main keyboard has no such configuration on it anywhere. To see what I mean, try using the `j' and `k' keys in rapid succession, back and forth as though you were executing a trill. It's quite easy to go up three, down one, up two, etc. But now try playing your trill on the up and down arrows. Whoops! You have to turn your hand completely sideways, or use the same finger to do both jobs. Either way you play it, you lose.

Does the visible label on the arrow keys truly offset the gross inefficiencies of being placed in the penalty zone and being stacked vertically? After all, the argument runs, someone who doesn't know the key command to move around can just use those. In the shallow and ephemeral world of zero-learning-curve and one-shot programs, this might have a scant of iota of reason behind it. But really, for just how long do you expect your users to remain ignorant? Once they learn what the motion key is, they're not going to forget it from one moment to the next. If you assume that users cannot or will not learn, you thereby guarantee this very outcome. That hardly seems either fair or productive.

The third reason that arrow keys are inherently evil is that they support navigation based characters alone. You'll never move on to higher abstractions, like words, sentences, or paragraphs, or in the programming world, to tokens, expressions, statements, blocks, or functions. By relying upon arrow use alone for movement and discouraging other kinds of information chunking, you lock your poor users into a tedious monotony and forever bar them from making the jump to light speed.

In any program designed for heavy use, the penalty zone should be not merely strenuously avoided, but completely banned. The keys there interfere with your prospects of ever becoming one with the computer. But isn't the numeric keypad in the penalty zone, and isn't it great for accountants? Don't they become one with their keypad? Well, sure they do. That's because they're staying in the same area. If all you're doing is entering numbers, then it's actually a good bit quicker to use the numeric keypad, because it fits under the hand better. The keypad also optimized for numeric data entry: see how much larger the `0' key is there, and the `+' key? If you don't know why, watch a bean counter entering numbers on it some time. Now go to your keyboard manufactures and demand the return of the your CONTROL key to it proper place and the restoration your wimpy spacebar to its proper size.

Don't expect to switch between numeric keypad and the main keyboard with anything resembling speed or accuracy. Unlike a normal clavier, where you can feel where you are in the scale because of the alternating two-three sets of raised keys, on a computer keyboard, no such sign posts exit. That means that while, the musical keyboardist can often make tremendous leaps in complete confidence without bothering to engage his eyes, the computer keyboardist cannot. Sure, you've probably got little nibs on your `F' and `J' keys, and on the `5' over on the numeric keypad, and it's a good thing that they're there, but really, they don't help that much compared with a real keyboard's cues.

The lesson is that if you're going to change domains so radically that your hand has to move somewhere else, you absolutely need to stay right where you are for a good while in order to amortize the extreme cost of movement. Otherwise the context-switch latency issues will just kill you. And this is where the true root of all keyboard evil rears its ugly head: the mouse.

The mouse is the single greatest obstacle standing in the way of becoming one with your keyboard and the dramatically higher productivity levels which that state promises. That's because, of course, it has nothing to do with your keyboard. Compared with the mouse, even a high density of chorded commands in quick succession becomes fast and easy. Chorded they may be, but at least they're still on the keyboard. The mouse might as well be in Timbuktu for how convenient it is to get your hand over to it and then safely home again.

Unlike the arrow keys, that doesn't mean the mouse is inherently wicked for all things. (Well, unless you're an RSI victim, that is, or if you'd prefer not to become one. Mice, you see, destroy your wrists, and much more quickly than keyboards.) The mouse is only evil when you have to repeatedly switch between mouse and keyboard. That's because it knocks you out of the groove just as badly as an CONTROL-ALT-SHIFT-F11 chord would. (I call that one a demented eleventh.)

Let's go back to that wonderful, angst-purging video game, xbill. You think of yourself as a Jedi sharpshooter, the last, lone defender against that creeping darkness which seeks to pollute and assimilate the free world into its hive mind. Reflexes are everything. You must walk the path of knowledge without thought, of action without contemplation. Anything less than complete dedication to your sacred duty will see another sun lost to the Evil Empire. In the back of your mind, you know that if you set down your laser rifle, you could program up a smart bomb to encase the Bills in a treacle and slow them down for a file. This you would do by taking your hand off the mouse, moving over to the keyboard, and typing the mystic words, "Department of Justice Anti-Monopoly Litigation". But in the time it would take to do that, untold numbers of worlds would be lost, assimilated into the collective. So the smart bomb of slowness remains untriggered. The price is too great to justify putting down your laser rifle.

So you see, there's certainly a place for a mouse. And contrary to popular mythology, that place is not simply any system that provides the user with something more sophisticated than a 24-by-80 character display. Mouse doesn't mean GUI, you know (nor, for that matter does GUI mean mice and menus). And a keyboard doesn't mean a CLI. A keyboard means efficient input of diverse commands covering a vast domain. A mouse means efficient selection of points and areas. Even if we temporarily tolerate the mistaken notion that CLI=text and GUI=pixels, a keyboard should not be limited to the world of command-lines and pipes, nor should a mouse limited to the world of pixels and pop-up menus. Those are not the effective criteria for the most effective use of those two input devices.

If you don't believe me, just think for a minute about gpm, the mouse package for virtual consoles on Linux operating systems. It sure is a nice program to have around, isn't it? You don't have individual pixels, but you still appreciate having a mouse for certain tasks. Now think about your favorite pixel-addressable program, like xv or eterm. They have keyboard-accessible keystroke commands as alternatives to tedious mouse hunting. Aren't you glad those are there, too?

I'll say it again for the logic-impaired: keyboards aren't just for CLIs, and mice aren't just for GUIs. There's no good reason whatsoever that even in what's commonly referred to as the GUI world, that you should eschew the keyboard. For many problem domains (xbill and its ilk notably excepted), the keyboard remains the fastest, most efficient, and most powerful input device available, and it would be the height of folly to avoid it.

Have you ever tried to play a piano using a stick that's clenched tightly between your teeth? Oh, you can do it, sort of--if you call that playing. The percentage of your brain devoted to the hand, and in particular, the support structures for the fingers, is incredibly huge compared to the amount devote to nearly any other physical activity. By avoiding the full potential of Man's wondrous capacity for prestidigitation (in the literal sense), you cut him off from one of his greatest assets, one near and dear to his neural biology--he was made for.

There's just no way you'll ever zen out on a keyboard when all you've got is a one-bit stick stuck in your mouth and your hands are tied effectively behind your back. Perhaps you prefer it this way, but you should understand the consequences of that choice. You'll never reach the point where your fingers know what to do on autopilot. You'll never get your face completely up off your desk. And you'll never savor the pleasures of having your mind firmly ensconced in the virtual reality of the program you are manipulating. The higher levels of mastery will be forever forbidden to you, and you shall dwell in the House of Clumsiness and Inefficiency all the days of your life.

Software engineers need to pay attention to both the keyboard and the mouse, irrespective of whether the program is running in a terminal or in a full-display environment. They should maximize locality of operations to faciliate eyes-free operation of the program. Above all, careful attention must be given to programs destined for heavy use so that they offer an upward path for users so that experts are not hampered by zero-learning-curve demands from non-users. Don't require infelicitous input combinations that would hamper finger memory in accomplished speed demons. Only when the speed limits are removed can a programmer hope to reach that transcendent state of zenning out.

Tom Christiansen , perl god, writer, and the guy that once kicked me out of #Perl for asking a question about sockets has written us another excellent feature. This one talks about modern keyboards, and the problem with them. It's an entertaining piece with gratuitous Who references so it's all good by me.

The following was written by Slashdot Reader and Perl God Tom Christiansen .

He stands like a statue, becomes part of the machine
Feeling all the bumpers, always playing clean
Plays by intuition, the digit counters fall
That deaf, dumb and blind kid sure plays a mean pinball.
from Pinball Wizard, sung by Elton John in Who's "Tommy"

When was the last time you really zenned out on a pinball machine? You know what I'm talking about: that transcendent state of consciousness in which you're no longer carefully calculating what to do and when to do it. You're completely oblivious of anything in the universe except for the ricochets of that silver ball. You're so totally in the groove that those extra balls and replays just keep racking up. Spectators and would-be players come and go, but their presence barely registers in your mind. Hours later, when it's all over and you finally step away from the machine, you find that words come haltingly; you've gone a bit nonverbal. Drifting off to sleep that night, instead of getting darker when you close your eyes, the world gets brighter as hypnagogic flashes from today's games explode in your mind's eye like comets dancing with lightning.

It's a pretty neat feeling, isn't it? You were in an altered mental state--a high, if you would. And like any other high, pinball zen is a bit addicting. Not only will this high leave you a lot less poor than plenty of others would, the only physical side-effects are apt to be some sore pects the next day.

This pleasant state of mind is hardly limited to pinball. You can become one with your skis and the powder you're flying over. You can become one with your musical instrument of choice. And, if you're a hacker, you can become one with your computer.

I'm not talking about sitting for hours on end, clicking from one web page to the next as trivia trickles passively in. I'm talking about actually creating or seriously manipulating something, not just impersonating the couch potatoes down the hall in the TV room. You're in the groove; you've got all the right moves down so pat you don't even think about doing them. The world again fades away. There is the computer. There is you. There is nothing else. And this is good.

This blissful state of being one with your computer doesn't actually have much to do with your computer. Paradoxically, the computer just gets in the way, a constant reminder of irrelevant physical constraints and realities. As long as your brain needs to spend time thinking about hardware, like the keyboard or the mouse or a flickering monitor or a whining disk drive, you will be forever denied access to the altered states. That's because it's not the computer itself you're trying to become one with. It's the software world that you're trying to enter. Only when the physical world recedes from conscious awareness can enlightenment become possible.

When you're learning a new piece of music, bringing it up to performance tempo and committing it to memory, a funny thing happens. After enough practice, it feels as though your fingers themselves remember how to play the piece. You don't even watch them. They've a job to do, and once they've it, can go about that job remarkably free of direct supervision. The key to clearing the mind of the outside world so that the program becomes the dominant reality is what a musician would call "finger memory". (You might have heard athletes or dancers refer to it as muscle memory, but when we're talking about using the computer, it really is the fingers that count.)

Of course, that's not really what's going on; it only seems to be. Your fingers don't really remember. But a part of your brain that controls them does, even though "you" don't realize it. What's happened is that you've so successfully assimilated the moves needed that conscious direction is no longer required. The little lighthouse keeper behind your forehead can worry about other things, assured that your fingers will do the job you've trained them to do. Your eyes are on the screen, the program in your head, and your head is in the program. Your fingers become an unnoticed extension of your will. They're are no more a conscious concern when typing commands than are your feet when you decide to walk across the room. That's probably just as well, because if you ever thought too much about how walking is really just perpetual falling and nick-of-time rescue, you'd probably stop being able to do it as well as you can now.

It's a shame, but many people never achieve the same zenning out with a program that they may with a pinball game or a musical instrument. Still, it can and does happen, and although it's something of an uncanny thing to witness someone else doing, it's a beautiful one to experience personally. In this satori-like state of experiencing knowledge without thought, the program's commands have become so deeply etched into your wetware that low-level tasks no longer require conscious direction. Your fingers seem to remember to do on their own. Now on automatic pilot, they dance across the keyboard as quickly and as accurately as any performing pianist's fingers move, and just as automatically.

This isn't to say that the keyboard is the sole path to blindingly efficient computer use. Far from it! To be honest, the keyboard is sometimes the worst possible choice. It's entirely dependent on the task. For example, if you're playing xbill, the hacker's favorite video game, you certainly don't want to try use the keyboard instead of the mouse. It's just going to slow you down. But neither does that mean that the mouse is always the best choice for all interactions.

Here's another example. I once tried using xmame to play millipede. Using the keyboard for movement was excruciatingly painful, but the mouse wasn't all that much better. I realized that I would never become one with the millipede using either access device. But just a few feet away stood a real millipede game (yes, I actually do own one). I have no problem becoming one with that version, even though as far as the software goes, it's the same as what xmame is running. Why? Because the real game has a trackball, that's why! No longer tied to a clunky input device, I could sail along so fast that the non-rational part of my brain could take over, and like Tommy, play by intuition alone. After the first 200,000 points, you get to play with eight darting spiders simultaneously. Try it sometime. It's a real trip.

There's no question that certain tasks, the keyboard is clearly the optimally efficient input device. Consider the game of rogue or one of its more recent incarnations. You wouldn't want to use anything but a keyboard there. The command set is just too rich. Trying to play the game with a mouse and menu interface instead of a keyboard one would slow you down by at least two orders of magnitude. It would be as bad as trying to play millipede with a keyboard, if not worse. As someone who at times spent most of his non-hacking waking hours at university playing rogue, srogue, larn, moria, and nethack, you'll just have to take my word on this. I certainly became one with the game. My fingers flew across the keys; my eyes never left the screen. I never had to think about how to do what I wanted to do, because no sooner did the desire enter my head than my finger memory took care of it.

When I wasn't playing rogue at university, I was hacking on code, for which I used a popular rogue-variant called vi. Yes, I know you probably think of vi as an editor, but I've always found people more receptive when I explain that it's actually a video game that gets a job done, too. In any event, the command set and design philosophy of the two programs overlap well enough to permit cross-competence between them. And as with rogue, I could zen out on vi. I was tremendously lucky I could, too, because most of the classes in my compsci program required more than 10,000 lines of code for each course. Now, try taking two or three of those classes in one term. You had to have a powerful and super-efficient editor, and you had to let the mechanics of the editor fade into the background, or else you just didn't survive. By zenning out, you ascended to a higher plane of productivity and did things that you normally couldn't do.

It sometimes seems that as time marches on, fewer and fewer people will get the chance to experience the sublime joy of becoming one with their computer. It's as though hardware and software manufacturers were all conspiring to render this good, clean high an unattainable one. It's not illegal, at least as far as I know, but for most people, it might as well be. In pursuit of the dubious goal of producing idiot-proof, zero-learning-curve programs, even programs intended for long-term, heavy-duty use such as an editor--arguably the most important piece of software you'll use--have been turned into children's toys, effectively expert-proofed. In mindless and unexamined pursuit of false efficency, the programs' authors have sacrificed all the design attributes that let our fingers go about their proper business, got our faces up out of the mundane mechanics, and let our minds transcend the hardware and get into the program. They installed, if not outright roadblocks, then velocity regulators and gratuitous speedbumps.

How did this ever happen? Let's start with why the current crop of keyboards are suboptimal in the extreme. There's a general rule (Fitts's Law) that says that the farther away something is, the larger it needs to be for equally swift access. This is true even if you are looking at the keys (but don't do that--see below), and fatal if you aren't. Distant keys like SHIFT, ENTER, TAB, CONTROL, and the spacebar used to be larger, but they keep getting smaller as more and more vanity keys get added to your main keyboard. Look at an old Sun keyboard. Notice how SHIFT is bigger than CONTROL, and CONTROL is bigger than TAB. This size corresponds to how much relative use you make of those keys. Oh, and the CONTROL key is both large and conveniently located on a Sun keyboard. What a joy.

Now go look on the cretinous keyboard that came with some poor sot's Wintel box. The spacebar, the most important key on the whole keyboard, is but a shrivelled and shrunken vestige of its former self. The ESCAPE key has been moved to the penalty zone, the CONTROL key is both distant and small (that's two strikes), and there's a CAPSLOCK key that's just as big as the TAB key. Hello? What are these people thinking? That I want to hit CAPSLOCK as often as I do tab, and that I don't care about CONTROL or ESCAPE? This is all nuts. The proper place for a CAPSLOCK key is in a different hemisphere from you. If we ever manage find out who invented that abomination, we're all going to show up for the lynching party, but we'll have to wait our turn in a line of programmeers stretching all the way from Boston to Mountain View.

If it were only the outlandishly rococo keyboards they were shoving at us, we hackers might still have a chance to become one with our computers. After all, we could always get a real keyboard instead, one with a decent layout and sans penalty zone.

But really, this is but the least of our many problems. First of all, there's no end of brain-damnged programs these days which both expect and require you to constantly enter and exit the penalty zone. This destroys your concentration, because you can no longer get there and back again while still looking at the screen. You incur a context-switch penalty that feels like a speedbump in your typing. It slows down your hands, and it interrupts your eyes. Once that happens, your concentration takes a severe blow as you're forced to deal with mechanics, once which you cannot internalize or omit.

The next gross inconvenience is requiring chorded key combinations. Any time you have to hold two or more keys down at the same time, this becomes more difficult to finagle. Compare how difficult it is to type a CONTROL-G chorded combination with a simple, unshifted `g'. If you ever need to hit a chord with more than two keys, such as CONTROL-ALT-SHIFT-F11, you're in serious, serious trouble. This kind of thing is especially arduous on keyboards lacking duplicated left and right versions of the modifer keys. There's a very good reason we have two SHIFT keys. We should have two control keys as well, and these should be easily accessible without looking. It's a lot easier on the hand to use the right-hand SHIFT key with a letter like `e' or `g'. Why should it be any different with CONTROL, ALT, or the vanity keys?

If you're striving for efficiency, it's best to stay away from chords entirely. If you look at the way popular video games like rogue and vi work, their command structure consist mainly of single, non-chorded keystrokes, or sequences of single keystrokes. That's why those games are inherently easier on the typist than games like emacs are, where all your most valuable real estate has been thrown away, and every command is now a chord. Chorded commands are harder to type because you have to hold down the SHIFT or CONTROL key, but in a program designed for efficient use, these are relegated to rarer activities, so the impact is minimized. The easy stuff is easy, and you never have to slow down, or even look down.

Consider how much easier it is to type a `/' to start a search than it is to start a search instead of a ALT-S, or horrors, pulling down a menu. There's no reason that a slash can't mean a search in context where it makes sense. This wouldn't mean that if you were typing in a path name in some text box that a search window would pop up. You simply make it context sensitive. Humans, you know, are really very good at context. Check out this sentence: "Can you please can the can-can while I'm in the can, man?" No problem. You see, our brains don't work off of a context-free grammar, and there's no reason that commands, keystroke or otherwise, should. In fact, because our brains do not work off of a context-free grammar, making our command set context free would be running against our inner natures. It's just not how we think.

Besides the useless vanity keys stealing invaluable real estate from the main keyboard, we are saddled with an ever-growing number of extra keys in the penalty zone, such as function keys, INSERT and its friends, arrow keys, and relics out of the shrouded mists of antiquity such as SysRQ and Scroll Lock. I'm sure there will be more in a year or two.

Can you imagine how painful it would be if you were typing in some code or a letter, and every time you wanted to go to the next line, you had to use ENTER key way over on the numeric keypad? That would be nuts, wouldn't it? So can anyone tell me why programs expect you to switch back and forth between the real keyboard and the penalty zone? Apparently nobody ever told them that the closer something is, the easier it is. According to Fitt's Law, something right underneath you is infinitely large, and, consequently, the most readily accessible. Proximity combined with non-chorded keystroke commands is why the rogue-style movement ("hjkl") is easier on the hand than emacs-style movement (CONTROL-B, CONTROL-N, CONTROL-P, CONTROL-F), and both of these are easier by far than using arrow keys over there in the penalty zone.

The much vaunted arrow keys, ostensibly easier to use for cursor motion, are in fact tremendously harder to use. First of all, if you're mixing commands over in the penalty zone with other commands which are on the keyboard, you're never going to achieve keyboard satori. You've got too much back-and-forth going on to find your grove. Your eyes act as a bridge linking two virtual worlds, one inside your head and the other inside your computer's memory. With arrow movements, they have to desert their post as vicar and go slumming in the real world for a while to play tour guide long enough to get you there and back again.

The second reason the arrow keys are inherently evil is that they are set in an arrangement designed by a masochist, probably the same nimrod who stuck us with the CAPSLOCK key. Even if all you were doing was keeping one hand poised above the arrow keys and never switching keyboard domains, you still would be slowed unacceptably. That's because the up arrow and the down arrow are directly aligned vertically. Your hand despises this, which is why the rest of the main keyboard has no such configuration on it anywhere. To see what I mean, try using the `j' and `k' keys in rapid succession, back and forth as though you were executing a trill. It's quite easy to go up three, down one, up two, etc. But now try playing your trill on the up and down arrows. Whoops! You have to turn your hand completely sideways, or use the same finger to do both jobs. Either way you play it, you lose.

Does the visible label on the arrow keys truly offset the gross inefficiencies of being placed in the penalty zone and being stacked vertically? After all, the argument runs, someone who doesn't know the key command to move around can just use those. In the shallow and ephemeral world of zero-learning-curve and one-shot programs, this might have a scant of iota of reason behind it. But really, for just how long do you expect your users to remain ignorant? Once they learn what the motion key is, they're not going to forget it from one moment to the next. If you assume that users cannot or will not learn, you thereby guarantee this very outcome. That hardly seems either fair or productive.

The third reason that arrow keys are inherently evil is that they support navigation based characters alone. You'll never move on to higher abstractions, like words, sentences, or paragraphs, or in the programming world, to tokens, expressions, statements, blocks, or functions. By relying upon arrow use alone for movement and discouraging other kinds of information chunking, you lock your poor users into a tedious monotony and forever bar them from making the jump to light speed.

In any program designed for heavy use, the penalty zone should be not merely strenuously avoided, but completely banned. The keys there interfere with your prospects of ever becoming one with the computer. But isn't the numeric keypad in the penalty zone, and isn't it great for accountants? Don't they become one with their keypad? Well, sure they do. That's because they're staying in the same area. If all you're doing is entering numbers, then it's actually a good bit quicker to use the numeric keypad, because it fits under the hand better. The keypad also optimized for numeric data entry: see how much larger the `0' key is there, and the `+' key? If you don't know why, watch a bean counter entering numbers on it some time. Now go to your keyboard manufactures and demand the return of the your CONTROL key to it proper place and the restoration your wimpy spacebar to its proper size.

Don't expect to switch between numeric keypad and the main keyboard with anything resembling speed or accuracy. Unlike a normal clavier, where you can feel where you are in the scale because of the alternating two-three sets of raised keys, on a computer keyboard, no such sign posts exit. That means that while, the musical keyboardist can often make tremendous leaps in complete confidence without bothering to engage his eyes, the computer keyboardist cannot. Sure, you've probably got little nibs on your `F' and `J' keys, and on the `5' over on the numeric keypad, and it's a good thing that they're there, but really, they don't help that much compared with a real keyboard's cues.

The lesson is that if you're going to change domains so radically that your hand has to move somewhere else, you absolutely need to stay right where you are for a good while in order to amortize the extreme cost of movement. Otherwise the context-switch latency issues will just kill you. And this is where the true root of all keyboard evil rears its ugly head: the mouse.

The mouse is the single greatest obstacle standing in the way of becoming one with your keyboard and the dramatically higher productivity levels which that state promises. That's because, of course, it has nothing to do with your keyboard. Compared with the mouse, even a high density of chorded commands in quick succession becomes fast and easy. Chorded they may be, but at least they're still on the keyboard. The mouse might as well be in Timbuktu for how convenient it is to get your hand over to it and then safely home again.

Unlike the arrow keys, that doesn't mean the mouse is inherently wicked for all things. (Well, unless you're an RSI victim, that is, or if you'd prefer not to become one. Mice, you see, destroy your wrists, and much more quickly than keyboards.) The mouse is only evil when you have to repeatedly switch between mouse and keyboard. That's because it knocks you out of the groove just as badly as an CONTROL-ALT-SHIFT-F11 chord would. (I call that one a demented eleventh.)

Let's go back to that wonderful, angst-purging video game, xbill. You think of yourself as a Jedi sharpshooter, the last, lone defender against that creeping darkness which seeks to pollute and assimilate the free world into its hive mind. Reflexes are everything. You must walk the path of knowledge without thought, of action without contemplation. Anything less than complete dedication to your sacred duty will see another sun lost to the Evil Empire. In the back of your mind, you know that if you set down your laser rifle, you could program up a smart bomb to encase the Bills in a treacle and slow them down for a file. This you would do by taking your hand off the mouse, moving over to the keyboard, and typing the mystic words, "Department of Justice Anti-Monopoly Litigation". But in the time it would take to do that, untold numbers of worlds would be lost, assimilated into the collective. So the smart bomb of slowness remains untriggered. The price is too great to justify putting down your laser rifle.

So you see, there's certainly a place for a mouse. And contrary to popular mythology, that place is not simply any system that provides the user with something more sophisticated than a 24-by-80 character display. Mouse doesn't mean GUI, you know (nor, for that matter does GUI mean mice and menus). And a keyboard doesn't mean a CLI. A keyboard means efficient input of diverse commands covering a vast domain. A mouse means efficient selection of points and areas. Even if we temporarily tolerate the mistaken notion that CLI=text and GUI=pixels, a keyboard should not be limited to the world of command-lines and pipes, nor should a mouse limited to the world of pixels and pop-up menus. Those are not the effective criteria for the most effective use of those two input devices.

If you don't believe me, just think for a minute about gpm, the mouse package for virtual consoles on Linux operating systems. It sure is a nice program to have around, isn't it? You don't have individual pixels, but you still appreciate having a mouse for certain tasks. Now think about your favorite pixel-addressable program, like xv or eterm. They have keyboard-accessible keystroke commands as alternatives to tedious mouse hunting. Aren't you glad those are there, too?

I'll say it again for the logic-impaired: keyboards aren't just for CLIs, and mice aren't just for GUIs. There's no good reason whatsoever that even in what's commonly referred to as the GUI world, that you should eschew the keyboard. For many problem domains (xbill and its ilk notably excepted), the keyboard remains the fastest, most efficient, and most powerful input device available, and it would be the height of folly to avoid it.

Have you ever tried to play a piano using a stick that's clenched tightly between your teeth? Oh, you can do it, sort of--if you call that playing. The percentage of your brain devoted to the hand, and in particular, the support structures for the fingers, is incredibly huge compared to the amount devote to nearly any other physical activity. By avoiding the full potential of Man's wondrous capacity for prestidigitation (in the literal sense), you cut him off from one of his greatest assets, one near and dear to his neural biology--he was made for.

There's just no way you'll ever zen out on a keyboard when all you've got is a one-bit stick stuck in your mouth and your hands are tied effectively behind your back. Perhaps you prefer it this way, but you should understand the consequences of that choice. You'll never reach the point where your fingers know what to do on autopilot. You'll never get your face completely up off your desk. And you'll never savor the pleasures of having your mind firmly ensconced in the virtual reality of the program you are manipulating. The higher levels of mastery will be forever forbidden to you, and you shall dwell in the House of Clumsiness and Inefficiency all the days of your life.

Software engineers need to pay attention to both the keyboard and the mouse, irrespective of whether the program is running in a terminal or in a full-display environment. They should maximize locality of operations to faciliate eyes-free operation of the program. Above all, careful attention must be given to programs destined for heavy use so that they offer an upward path for users so that experts are not hampered by zero-learning-curve demands from non-users. Don't require infelicitous input combinations that would hamper finger memory in accomplished speed demons. Only when the speed limits are removed can a programmer hope to reach that transcendent state of zenning out.

jamiemccarthy writes "A rewrite of Perl in C++ is underway. The audacious plan, now called Topaz, will become Perl6 if and when it's successful. Its author, Chip Salzenberg, will tell you all about it. " Wow. That's quite a project - you can also listen to Chip's talk given at the OpenSource Convention. For those you unaware, Chip is one of the Perl core developers.

bryan schwab writes "Perl 5.6 is in development, here is a list of all the new features" The article is an interview with the "Patch Pumpkin" - one of the guys from ActiveState in charge of putting together the development release. Seems there is a lot planned for the next release.

Idmat writes "Nominate the Perl community's unsung heroes for the first White Camel awards. Three awards--for outstanding contributions to Perl Advocacy, Perl User Groups, and the Perl Community--will be awarded at O'Reilly's Perl Conference 3.0 on August 24, 1999. Nominate the folks who have made these important non-technical contributions to Perl at perl.com All nominations must be in by August 2. The White Camel awards are sponsored by Perl Mongers, O'Reilly & Associates, and sourceXchange. See the press release for more info " Anyone want to share their ideas?

The always non-political Tom Christiansen has written in with a nice little satire piece that you might want to read. I'll spare my own commentary on the piece.

[ The following is an interview by Hired, the monthly magazine devoted to commerce and trade, with Gilbert Oram Dawson, the founder of the Good Software Group. ]

Hired: Gilbert, it's been fifteen years since you single-handedly created the Good Software movement and its spokesman and umbrella organization, the Good Software Group. How does it feel to be sitting in the catbird seat, now that Good Software is all the rage?

Dawson: It's a great feeling to see just about everyone either using or else wanting to use Good Software. It proves that I am the visionary I always told you I was. But I'll tell you this: it hurts me that most people don't realize that without the Good Software Group, they probably wouldn't even *have* any Good Software. In fact, most people who use Good Software have barely even heard of the GSG. It really wounds me to be so under-appreciated, even after all the Good Software that I've personally created for the world.

Hired: Maybe that has something to do with the common misunderstanding of what Good Software is really about. Not everyone uses "good" the way you do, you know.

Dawson: Listen, I'm getting really tired of that old refrain. You get the feeling that these people have never looked into a dictionary before. If you check, you'll find that it is perfectly legitimate to use "good" to refer to saleable commodities, merchandise, or wares.

For example, here's one from the dictionary: "All that follows will hold true of any storable good, like cotton, wool, rubber, tobacco, wheat, coffee, sugar, oil, copper, or tin." Here's another: "As a steady, cheap, business-making consumer good,..the book is out." And here's one more: "For example, the existence of stocks of goods which might have to be reduced in some amount before additional resources were guided to the favoured good were ignored." Those are right there in the Oxford English Dictionary, so there's no room for argument. I'm right, and they're wrong.

I have invested many many years of my life in promoting Good Software. I am not about to change what I call it now simply because a bunch of idiots who never even finished grad school can't understand simple English words.

Hired: I'm sorry. I didn't intend to argue. Perhaps for the sake of our readers, Gilbert, you might please explain just what it is that you *do* mean by "good software"?

Dawson: Sure, I'd be glad to. Everything I'm about to say, though, is clearly explained on the Good Software Group's website, including just exactly what we mean when we say "Good Software". I don't always have time to explain just what a good is to everyone the GSG comes in contact with. I wish when they heard about Good Software--which is admittedly a slightly ambiguous abbreviation for a much more elaborate concept--that they would look at our website, or at the very least, pick up a dictionary. Words mean different things to different people and in different contexts. In my case, a word means just exactly what I say it means, and if people care about what I say it means, they should visit my website.

Hired: Um, and what *does* it mean?

Dawson: Oh right. It's so simple a child could understand it. Good Software is software that is made for the express purpose of facilitating the exchange of any sort of good or service for the purposes of commerce or trade.

Hired: And why did you form the Good Software Group?

Dawson: I'm really glad you asked that. I founded the GSG because at the time, our nation's E-conomy [The editors believe that the interviewee was referring to "electronic economy", but in retrospect, it's unclear. --Hired] was in serious straits, and I thought that a lot of the problem stemmed from wasted programming effort that did not produce Good Software. When programmers waste all their nights creating fritterware and useless eye candy, they are not actually *producing* anything. And without a tangible good for consumers to beg, barter, or steal, not only our E-conomy but also our economy stagnate. Think of the innumerable hours wasted on writing screen-savers. Where are the goods that come of that? Everything is just bits; nothing is tangible. If you're not writing Good Software, your effort has been lost to all of mankind, because you've made *nothing*.

Hired: Is that why you created the the GPL?

Dawson: Yes, that's *exactly* why I created the Good-Software Permanent Licence. The GPL is a way to use copyright law to make absolutely sure that the next bit of oh, I don't know, maybe manufacturing software, for example, can't ever be turned into something non-Good like a screen-saver. You really should go read about the GPL on our website, but what it amounts to is that Good Software can never be subverted into non-Good Software. That way any fixes or changes won't be lost forever to the business community that created the Good Software in the first place. By making sure that all effort on Good Software produces more Good Software, we as a people, a nation, an entire planet all benefit as commerce and trade continue to grow.

Hired: Do you feel that the Good Software Group is neglected when the New York Times or the Wall Street Journal mentions E-commerce but doesn't talk about how important Good Software and the GSG in particular have been to it?

Dawson: I don't care for the word "E-commerce", and you've put your finger on exactly why. It disrespects how important we are. Don't you realize that without Good Software, the E-conomy would be nowhere? It's the very foundation of the entire system! Oh, there isn't always a lot of our stuff there, but we were the guiding light behind it all. That's why I insist upon the term "Good/E-commerce" instead. However, if you really find that difficult, I shall permit you to use the term "E/Good-Commerce" in my presence as a tolerable but not a preferable alternative. The reason I don't care for it as much is that you've placed the Good part too far back, even though I really started it all. At least you give the GSG some credit that way, though.

Hired: I'm sorry -- I'll try to more careful from now on. I'd like to thank you for this interview. I'm sure that this will clarify for our readers your role in the goodware movement--

Dawson: Stop right there! I am not now nor have I ever been a member of the so-called "goodware" movement. I am the founding father of "Good Software" movement, which is completely different. "Goodware" is the despicable term used by a sham libertarian outfit who's trying to reach out to the not-for-profit community. When they say "goodware", they just mean software that's not bad. Can you believe it? Do you realize that they actually support letting people take what was originally Good Software and convert it into something that will never be used for one single good or service? That no longer will money change hands? Why, if everyone did that, our whole country would fall apart! That's not Good Software, and I shall have nothing to do with them. Fortunately, the GPL prohibits them from doing that with GPL'd software, which is why I strongly advocate slapping the GPL on every bit of software you can. It's the only way to keep those gun-toting libertarians off our backs and to keep our nation's E-conomy strong!

Hired: You know, Gilbert, if you were to legally change your name to add a second middle name like "Outspoken", then your initials would be a lot more meaningful for mail. Not only could you get mail sent to "good@gsg.com", but you could make your login a trademark to protect your unique use of the term "GOOD SOFTWARE".

Dawson: That's an intriguing idea -- it would certainly help me in my current legal battles with those pesky lawyers which the liberatian goodware people keep throwing up at me when I tell them they can't say "goodware" because I have prior art in using my own personal standard definition of "good".

But I'd really have to keep the old mail alias. For some reason, folks tend to put more weight into my writings under the current login. And it makes me feel good--er, I mean, important.

Tom Christiansen, the Perl deity who once kick/banned me from #perl for asking a question about socket programming (not that I'm bitter *grin*) has written a feature called "Free Linux, Support the Demon Penguin" where he argues with the FSF and RMSs stance that Linux should be referred to as GNU/Linux because it is mostly GNU. Tom includes some numbers that you might find revealing. This one is worth a read. The following was written by the Author of the Perl Cookbook, and Slashdot Reader Tom Christiansen Free Linux! Support the Demon Penguin.

The Demon Penguin, first seen on a T-shirt at the Linux World conference, is the mascot of the movement to create a an FSF-free Linux by replacing all FSF-owned software in Linux distributions with replacement programs from the BSD distributions.

The Linux kernel, while GPL'd, is certainly not to be replaced, nor is anything else that was *not* written directly by the FSF, whether it's GPL'd or not. As for the compiler, perhaps egcs is a better technical solution. A mere GPL does not GNUware make. Only software that the FSF claims is theirs should be replaced.

The point is *not* that we do not like the FSF's software, or that we do not like the GPL -- well, at least not all of us. Rather, it's because we cannot abide anyone usurping responsibility for the intellectual works of others. In the case of the FSF, such an inconsistent act is oxymoronic at best, and hypocritical at worst.

Let's use real data, not the hyperbolic rhetoric so common to the FSF. Here's a code analysis of a SuSE installation. Note that FSF ownership does not even quite reach 10%, yet rms and his followers would have it called "GNU/Linux". Their claim has no honest justification. Witness the numbers, and judge for yourself: http://www.vipul.net/codd/suse5.2.R.html

Code Contribution Distribution for S.u.S.E. 5.2 Package Name: suse5.2.codd
Package Size: +514659722 bytes.

1. uncredited: 82733250 (16.075%)
2. free software foundation, inc: 51254116 (9.958%)
3. sun microsystems, inc: 38243234 (7.43%)
4. the regents of the university of california: 23581801 (4.582%)
5. x consortium: 18163125 (3.529%)
6. thomas g. lane: 8464917 (1.644%)
7. the university of washington: 7832780 (1.521%)
8. digital equipment corporation: 7206660 (1.4%)
9. snns group, ipvr, univ: 4366722 (0.848%)
10. aladdin enterprises: 4108079 (0.798%)
11. silicon graphics, inc: 3680070 (0.715%)
12. robert nation: 2465545 (0.479%)
13. maorong zou: 2438025 (0.473%)

Even if it is 10%, that's not enough to rename Linux to the repugnant "GNU/Linux". And it's not 10%. On a fully loaded server system, it's much less. Attached you will find an `ls` of /usr/man/man1 and /usr/man/man8 from a well-loaded RedHat Linux server system. Let the FSF indicate which commands were written by the FSF themselves, so that their claim of GNU/Linux might have some legitimacy. Until the FSF can prove actual authorship for > 50% of these, they have no business with this deceptive "GNU/Linux" moniker.

Let us give credit where it is due: to all those hundreds and hundreds of selfless volunteers all over the world who have made all Linux what it is today. The bogus term "GNU/Linux" confuses the public about what free operating systems like Linux and BSD are all about, and, perhaps more dangerous to us in the long run, dishonors the innumerable contributors by ignoring their massive efforts.

So please, everyone: let Linux remain Linux, nothing more -- but nothing less! When rms and his minions abandon this misguided and deceptive battle, we too can relent, but until then, support the Demon Penguin!

Tom Christiansen, the Perl deity who once kick/banned me from #perl for asking a question about socket programming (not that I'm bitter *grin*) has written a feature called "Free Linux, Support the Demon Penguin" where he argues with the FSF and RMSs stance that Linux should be referred to as GNU/Linux because it is mostly GNU. Tom includes some numbers that you might find revealing. This one is worth a read. The following was written by the Author of the Perl Cookbook, and Slashdot Reader Tom Christiansen Free Linux! Support the Demon Penguin.

The Demon Penguin, first seen on a T-shirt at the Linux World conference, is the mascot of the movement to create a an FSF-free Linux by replacing all FSF-owned software in Linux distributions with replacement programs from the BSD distributions.

The Linux kernel, while GPL'd, is certainly not to be replaced, nor is anything else that was *not* written directly by the FSF, whether it's GPL'd or not. As for the compiler, perhaps egcs is a better technical solution. A mere GPL does not GNUware make. Only software that the FSF claims is theirs should be replaced.

The point is *not* that we do not like the FSF's software, or that we do not like the GPL -- well, at least not all of us. Rather, it's because we cannot abide anyone usurping responsibility for the intellectual works of others. In the case of the FSF, such an inconsistent act is oxymoronic at best, and hypocritical at worst.

Let's use real data, not the hyperbolic rhetoric so common to the FSF. Here's a code analysis of a SuSE installation. Note that FSF ownership does not even quite reach 10%, yet rms and his followers would have it called "GNU/Linux". Their claim has no honest justification. Witness the numbers, and judge for yourself: http://www.vipul.net/codd/suse5.2.R.html

Code Contribution Distribution for S.u.S.E. 5.2 Package Name: suse5.2.codd
Package Size: +514659722 bytes.

1. uncredited: 82733250 (16.075%)
2. free software foundation, inc: 51254116 (9.958%)
3. sun microsystems, inc: 38243234 (7.43%)
4. the regents of the university of california: 23581801 (4.582%)
5. x consortium: 18163125 (3.529%)
6. thomas g. lane: 8464917 (1.644%)
7. the university of washington: 7832780 (1.521%)
8. digital equipment corporation: 7206660 (1.4%)
9. snns group, ipvr, univ: 4366722 (0.848%)
10. aladdin enterprises: 4108079 (0.798%)
11. silicon graphics, inc: 3680070 (0.715%)
12. robert nation: 2465545 (0.479%)
13. maorong zou: 2438025 (0.473%)

Even if it is 10%, that's not enough to rename Linux to the repugnant "GNU/Linux". And it's not 10%. On a fully loaded server system, it's much less. Attached you will find an `ls` of /usr/man/man1 and /usr/man/man8 from a well-loaded RedHat Linux server system. Let the FSF indicate which commands were written by the FSF themselves, so that their claim of GNU/Linux might have some legitimacy. Until the FSF can prove actual authorship for > 50% of these, they have no business with this deceptive "GNU/Linux" moniker.

Let us give credit where it is due: to all those hundreds and hundreds of selfless volunteers all over the world who have made all Linux what it is today. The bogus term "GNU/Linux" confuses the public about what free operating systems like Linux and BSD are all about, and, perhaps more dangerous to us in the long run, dishonors the innumerable contributors by ignoring their massive efforts.

So please, everyone: let Linux remain Linux, nothing more -- but nothing less! When rms and his minions abandon this misguided and deceptive battle, we too can relent, but until then, support the Demon Penguin!

After a bit of a hiatus, Jason Bennett has returned with a review of Nancy Walsh's Learning Perl/Tk. As the title of the book would indicate, this is an ideal book for those looking to learn the Tk tool kit and Perl. This book assumes a level Perl background, and a little GUI, but is a good intermediate step-click below if you want to know more. Learning Perl/Tk author Nancy Walsh pages publisher O'Reilly rating 8/10 reviewer Jason Bennett ISBN 1-56592-314-6 summary A solid introduction to using the Tk toolkit with Perl. If you have a reasonable Perl background, and a little GUI on the side, you'll pick it up in no time. Background

Greetings, all. This will be the first in a series of reviews dealing with some Tcl/Tk books I've recently acquired. Since I already have some Perl in my background, I took this one first, both to sharpen my Perl skills, and to find out what this Tk thing is all about. Given that my GUI experience is limited to Smalltalk and Java, Tk is quite easy to use. With Smalltalk, I was too busy wrapping myself around OO theory to enjoy the interface, and Java always seemed to make GUI stuff more difficult than it needed to be (although I still love it). Perl and Tk are strong partners, because they share a philosophy of getting things done without a lot of fuss. Perl and Tk are excellent replacements for any GUI scripting language you might use (read: VB). Read on to see how to jump in!

What's the book about?

This is another book in O'Reilly's Learning series (of which Learning Perl really saved my butt in college), which is dedicated to teaching the fundamentals of a certain topic. I want to compare this series with the Learn XY in 21 days type of books, although I believe that would generally be an insult to the quality of O'Reilly. Once you finish this book, you will have enough of an understanding of Tk to be able to do most small projects. You will know most widgets (although I'll admit my own knowledge is limited here), and will generally be prepared to be productive with Tk in Perl.

What's Good?

In order for you to be able to evaluate the usefulness of this book, it will probably help to understand where I'm coming from. I have a BSCS from Georgia Tech, and have enough languages under my belt to do some damage (Lisp is cool!). In fact, I learned Perl originally for a networking project using Learning Perl. It gave me enough to do what was needed. Having said that, I don't live to program, and in fact I'm not big on reading language books. I don't know every language under the sun, and I don't necessarily learn them with the greatest of ease. In other words, my results should be duplicable by most programmers. The most important thing when reading this book is to know Perl (at least have written some stuff in it), and probably have an idea of what to expect when writing GUI code.

Going into this, my Perl was definitely rusty (having not touched it in a while). I didn't have any trouble diving straight in, however. The Perl constructs used are not overly complicated, and my knowledge was sufficient. (NOTE: make sure you have a very recent version of Perl installed. My Redhat 5.2 needed to be upgraded to m4 before the examples would work. Also, get the errata from O'Reilly.) The early chapters deal with basic constructs and widgets, and spend a great deal of time on the geometry managers (go figure). Each chapter introduces a new widget, although some are used before they are introduced (just nod and smile when you see those and don't worry). There are plenty of examples, code fragments, and exercises to keep anyone busy. I tried to work as many as I could, to get a feel for the language, and generally felt like they were helpful. I never felt completely lost or confused, and generally followed things without much trouble. Having finished the book, I feel confident that, given a little work on my Perl, I could write a useful application with Tk, especially given some research on CPAN for various contributed modules. For me, the book worked.

What's Bad?

Nothing in this book is particularly bad, although there are a few nits I'd like to pick. First, the early emphasis on geometry was somewhat interesting. I'm not sure why I care about grid vs pack when I can barely create a button to put on the screen. For that matter, frames are referenced in a short chapter late in the book, after being used all throughout. If the concept is so basic, why not put it toward the beginning? Also, there were times when the author mentions that an option is esoteric, or generally unused, and then spends much more time than necessary on that point. If it's so esoteric, why is it being covered in a basic book like this one? Finally, there were a few times that the book did not explain a point well enough to me, and I had to divine the answer down the road (like configuring scrollbars). It was not a major issue, but there were some things that could have been clearer.

What's In It For Us?

If you want to learn Tk using Perl, this book will let you do that. It gives a solid introduction to the topic, and on completion, you will be a useful Perl/Tk programmer. Just know your Perl going in, and you will be fine.

Purchase the book over at Computer Literacy.

1. Preface
   
2. Introduction to Perl/Tk
3. Geometry Management
4. The Basic Button
5. Checkbuttons and Radiobuttons
6. Label and Entry Widgets
7. Scrollbars
8. The Listbox Widget
9. The Text Widget
10. The Canvas Widget
11. The Scale Widget
12. Menus
13. Frames
14. Toplevel Widgets
15. Binding Events
16. Composite Widgets
17. Methods for Any Widget

1. Configuring Widgets with configure and cget
2. Operating System Differences
3. Fonts
   Index

An anonymous reader writes "Or at least a pretty comprehensive suite of the classic utilities. Tom Christiansen (well-known in Perl circles) has decided that it is easier to write the utilities in Perl and make them available on all platforms than to constantly rewrite Perl scripts that use backticks. Full details are available right here. "

The critical companion to the Camel/Llama books, the Ram book, published by O'Reilly, Perl Cookbook: Solutions and Examples for Perl Programmers has been reviewed by Reviewed by: Eugene Sotirescu. This piece of art has been written by Tom Christiansen and Nathan Torkington-and if you want the scoop on the book, click below. Perl Cookbook: Solutions and Examples for Perl Programmers author Tom Christiansen and Nathan Torkington pages publisher O'Reilly & Associates rating 10 reviewer Eugenia Sotirescu ISBN summary An indispensable compendium of Perl programming problems with expert solutions and commentary. The ScenarioThe first Perl book, "Programming Perl", (Larry Wall and Randal Schwartz, 1990; aka the Red Camel) included 2 chapters, "Common Tasks with Perl" and "Real Perl Programs", that were left out of the second edition of the book ("Programming Perl", by Wall, Tom Christiansen and Schwartz, 1996; aka the Blue Camel). Many people bemoaned the omission of all these Perl-at-work gems and one of the authors, Tom Christiansen, undertook to expand the 2 orphan chapters into a separate book. Two years later, with the help of fellow Perl programmer and Perl FAQ maintainer, Nathan Torkington, Christiansen gave us the "Perl Cookbook" (aka the Ram book).

While no review can even get close to summarizing the wealth of information in this book, its structure is easily described: the organizing metaphor is the cookbook and therefore the bulk of each chapter contains recipes designed to address specific programming problems.

A Code FeastHere's a brief list of other goodies you can find in this book:

• a juicy regex grabbag, that shows how to match HTML links, IP addresses, all-caps words and key=value pairs among many other patterns.
• A full chapter on Database access that in addition to DBI also includes the most extensive discussion of DBM files in Perl literature.
• 40 pages on UNIX processes from the point of view of Perl.
• Examples on how to write demon and non-forking servers in the chapter on sockets and code to create robots, parsing server logs and automating form submission in the chapter on web automation.
• Numerous tips and examples of safe and efficient CGI programming in the chapter devoted to this.
• How to keep your modules separate from the system-wide ones and how to prepare modules you've written for CPAN distro
• Everything you ever wanted to do to dates/time but didn't quite know how .

At times, though, the authors can't keep themselves to just code snippets and cook a full ready-to-eat meal in the form of a complete program to cap the solutions presented in a chapter.
At the end of the Pattern Matching chapter, for example, you can find 'tcgrep', Tom Christiansen's cross-platform supergrep that "ignores anything not a plain text file, automatically expands compressed or gzipped files, recurses down directories, searches complete paragraphs or user-defined records . . . and adds underlining or highlighting of the matches". A program called 'hopdelta' caps the "Dates and Times" chapter and shows the time an email message took to reach each destination based on an analysis of its header.

Anatomy of a ChapterAfter an introduction that tries to present the history and general outline of the topic of the chapter come the numbered recipes. Each recipe is divided into 4 parts: a brief statement of the Problem, followed by the code of the Solution and a detailed Discussion with further comments, code examples and pitfalls. The recipe ends with a See Also paragraph that sends the reader to the relevant man pages and further references.

Chapter 7, for instance, deals with File Access. It opens with a 4-page discussion of the basic concepts of file handles and I/O. It then quickly moves into the recipes, which range from the basic (opening a file, covered in depth, output flushing) to the often used and asked about (writing a filter, modifying a file) and ends with a longish complete program that implements lock control over a designated region of a file. Changing a file has 3 sections devoted to it: in-place modification using a temp file, doing it from the command line and the less common in-place modification without a temp file.

(Note: if you've been modelling your file locking on the flock() example on pp.166-7 of the Camel book, make sure you check out recipe 7.11, "Locking a File", to see what you may be doing wrong).

What's Bad?I'd say: nothing. A caveat is in order, though.
Good recipes do not a gourmet cook make. A handy compendium of code snippets like the ones in this book will help solve the problem at hand, but won't help you design better programs. I don't mean to detract from the book's value (after all its purpose is not to teach program structure), just to deflate a little the beginning Perl programmer who uses this book to get unstuck: he's solved the problem at hand and that's great, but he's not necessarily a better programmer for it. The authors are probably aware of this, hence the complete programs at the end of the chapters. I only wish there were more of these.

What's Good?Lucid presentation and clear organization make this book not only useful to refer to, but also pleasant to read through. And the code in it comes not only from experienced authors, but has also been polished by the feedback from scores of Perl gurus, which is a pretty good guarantee of its quality.

Do YOU Need the Ram book?To make it short, let's actually ask: "who doesn't need the Ram book?"
If you're Larry Wall, you probably don't need it . That's it. For the rest of the Perl crowd this book is pretty much an essential companion to the Camel, as both resource and learning tool.

(Note: If you use Perl to teach yourself programming, use the Llama ("Learning Perl," by Randal Schwartz) to get going, but keep the Ram in mind: if you get anywhere with Perl you too will want it).

Buy this book here.

Errata

Table of Contents

1. Strings
2. Numbers
3. Dates and Times
4. Arrays
5. Hashes
6. Pattern Matching
7. File Access
8. File Contents
9. Directories
10. Subroutines
11. References and Records
12. Packages, Libraries, and Modules
13. Classes, Objects, and Ties
14. Database Access
15. User Interfaces
16. Process Management and Communication
17. Sockets
18. Internet Services
19. CGI Programming
20. Web Automation

Geoff Eldridge writes " The text of the 2nd State of the Onion has been posted to perl.com - have not had time to read it in detail but I suspect it will have many messages and hopefully will be as motivating as his formative keynote from last year's conference. "