Terminal Type/Productivity correlation (re:was hardcopy/productivity)
Onward Lam
onward at fsg.UUCP
Mon Nov 26 12:38:07 AEST 1990
We've seen quick a bit on hardcopy/productivity discussion.
How about a discussion on Editors and productivity (NO, not the
vi vs. emacs religious debate), but more like size of terminals
(ie. lines x columns), or windows/xterms vs ascii terminals.
Here's to start it off:
1. 24x80 is okay for programming, but painful for debugging (you
need the paper printouts then).
2. Bigger displays (or windows), eg. 48x80 is much better for
debugging. Reason: With 48 lines, you can see more of the code
around where you think the error is, and keeping it on one
screen allows the brain to take it all in without constantly
forward/back paging. Plus, we were taught (weren't we?) to
write short functions, so 48 lines may actually be most of
the function already. Argument here is on what the upper limit
of lines is before you overtax the brain/eyes (60 lines perhaps)
A small flame: it may perhaps be conjectured that a 24x80
ascii, after a split screen is almost counterproductive ??
3. Using multiple windows during development: convenience or
distraction?
Personally I prefer big screens. I used to use hp300 workstations
as a 49x128 line terminal and it was GREAT. I tried Suns (34 lines)
but their emulation was painfully slow - (? Why is the SLC console
terminal emulation so @!*# slow ?) ....guess I'm not that into
windows yet
Hm.., wonder if someone's done research on this...
About paper I prefer the availability of real lineprinters
(66x132 fanfold 11"x14.5" type). Some of you out there probably
thinks every installation has one, which is no longer true with
the proliferation of Laserjets. I almost had to beg my managers
to keep the lineprinter at my last job, since most people were
printing their code out on Laserjets.
-----------------------------------------------
-- Onward Lam ..!uunet!fsg!onward --
-- Of course these are my personal views :-) --
-- I dont't deserve to be flamed, yet. Do I? --
-----------------------------------------------
More information about the Comp.lang.c
mailing list