I find short routines very helpfull, because they are usually easy to grasp and the routine name gives me a way to hold onto the concept and the function of the subroutine.

Of course this breaks down as soon as the name is badly chosen or the subroutine has been artificially compressed/golfed to fit under the limit of "short".

The smattering of one long flow of execution into small, seemingly unrelated bits of structure is the reason why I don't like event oriented/driven programming, like with POE, HTTP or X / GDI. To get any kind of responsiveness/interaction in these areas, one is forced to break every nontrivial loop into at least three states/subroutines/case slots, which are visually separate, which makes the control flow hard to follow, if the control flow can be observed at all.

For classes, this problem can be simply avoided by underengineering and reducing the number of methods. Threads are a nice alternative to avoid this problem with event driven programming as long as you have only one process, and there have been some concepts of implementing stateful programming for HTTP through continuations.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web
[download]