Each art form can be defined by its constraints. Technological progress means that many formerly-unavoidable constraints can be overcome, yielding a less-constrained art form, permitting wonderful new art that couldn't be made before. Consider the effect that the development of computer graphics during the 1990s has had on cinematic art.
Where an artistic constraint is not inherent, there can still be great interest in artificially imposing a constraint. In cinema, consider the rules of Dogme 95, which has produced some beautiful films of great storytelling integrity. Particularly severe constraints, such as those of 55 Fiction (English fiction no longer than 55 words), force an intense focus of creative effort.
Many constrained art forms also have a benefit of accessibility. At the time of writing, the physical resources necessary to make a Dogme 95 film are several orders of magnitude cheaper than the resources required to make a CGI-heavy Hollywood-style film. Similarly, while good 55 Fiction can't be rattled off instantly, it requires a time investment on the order of a hundredth of that required to write a novel.
(For more on constrained art, particularly in a literary context, see the Wikipedia article on "constrained writing".)
"Single screen Perl" is a constrained art form, a sub-genre of the programming art form, where the objective is to fit a self-contained and interesting program into one screenful of Perl source code.
Why one screenful? Many people have played with the possibilities of one to four lines of Perl, and it's impressive what can be achieved in such a small space. But often such tiny programs have to make gross compromises in order to fit, so they end up being no more than clever hacks to show off, not actually useful programs. A screenful is sufficiently large to fit many genuinely useful and complex programs. At the same time, a screenful is sufficiently small to meaningfully and interestingly limit the size of the program, posing challenges analogous to those provided by early computers that had only a couple of thousand words of addressable memory.
In single screen Perl, then, minimal code size is not the overwhelming objective. The aim is to build a useful program in a challengingly small, but not overwhelmingly restrictive, space. It's amazing how much one can actually fit into one screenful of Perl — there's room to express the core of almost any interesting algorithm, which gives great latitude in selection of subject matter. The only major difference between single-screen-Perl aesthetics and ordinary unconstrained-Perl-programming aesthetics is in the consideration of code layout.
Minimal code size is not the primary objective of single-screen-Perl programming. While there is an absolute upper bound to the permitted size, which must not be exceeded, there is no aesthetic gain from using less than the permitted screenful. In fact, greater skill is displayed by making maximum possible use of the permitted space. However, programs should not be padded out to fill the screenful; it should be difficult to make the program shorter without affecting functionality. Padding is not considered a good use of the permitted space.
Where a program is unavoidably significantly shorter than a full screenful, it is preferred to give the source a pleasing shape. Filling fewer than 23 lines, with exactly 79 characters each, is the goal for programs that really can't use all 23 lines.
Any compromise in functionality that has been made in order to shorten the program counts heavily against it.
The ideal single-screen-Perl program, then:
The `size' limit imposed on programs by the rules of single-screen-Perl is not a pure length constraint, which has some interesting effects. Because of the mandatory newline after each 79 characters, greater use of the available space can be made by reordering sections of the program to avoid wasting columns at the end of a line. (Space is wasted when the next token won't fit into it and so has to be spilled onto the next line.) Sometimes a desirable rearrangement, resulting in the program taking up fewer lines, may actually involve the program containing more characters.
A particularly significant special case of the more-is-less phenomenon occurs with strings that are too long to fit the space at the end of a line. They can be split across lines, using a concatenation operator, which (naively done) always introduces more characters but (even naively done) never worsens the line count.
Another effect of line splitting is the introducction of `free' whitespace. Two adjacent identifier-like tokens may be separated by only a (mandatory) newline, whereas if they had occurred in the middle of a line it would have been necessary to spend one of the 79 available characters on that line on a space to separate them.
While developing a single-screen-Perl program, the character count without regard to line splitting effects is a useful metric. It's only in the final fine-tuning stages that it needs to be abandoned.
I invented the single-screen-Perl art form in 2003-09 for the emergency holographic talker, which is the first single-screen-Perl program, and now exists in two versions, both meeting the single-screen layout constraint. Because the EHT needs to interact with non-programmer humans (rare among programs that I write), and because of the nature of its subject matter, I adopted as part of the "good programming practice" rule a requirement that it should be usable by novices without instruction, which limited how terse its messages could be. I encourage other single-screen-Perl programmers to apply analogous subject-specific requirements to their programs.
The original version of the EHT filled the permitted single screen exactly, but was capable of being made shorter and turned out to have a couple of minor bugs. Version 0.1, released on 2004-07-12, fixed the bugs, made the code more concise, introduced a new feature in order to use up the 20 or so character cells now going spare, and (inevitably) reshuffled everything to resatisfy the layout constraints. Comparison of the two versions is instructive, and the pair of versions stands as testimony to the fact that single-screen-Perl programs can be edited without destroying their single-screen-ness. Version 0.1 of the EHT is very nearly (but not quite) a perfect single-screen-Perl program.
So far the EHT is the only single-screen-Perl program that I know of. I'd be fascinated to hear of anyone else working in this genre.