Fun_People Archive
16 Nov
Academic Programmers - A Spotter's Guide

Date: Tue, 16 Nov 93 13:41:00 PST
To: Fun_People
Subject: Academic Programmers - A Spotter's Guide

[This Field Guide to the Programmers is veddy British and waayy long,
 but amazingly accurate when you least expect it.  -psl]

 From: bostic@vangogh.CS.Berkeley.EDU (Keith Bostic)

          Academic Programmers - A Spotter's Guide
Pete Fenelon, Department of Computer Science, University of York


     During  the  course  of  a  computer  science  research
project  (or  even  a  DPhil) it is  highly  likely  that  a
researcher will have to generate at least a couple of  lines
of code. Most researchers fall into a number of well-defined
categories  when it comes to programming. This  handy  guide
for  supervisors, other researchers or the plain bored helps
you to identify some of the prime suspects...

     Disclaimer:  this was written when I should  have  been
concentrating  on my current research project,  the  one  my
previous   contract  was  for  AND  my  DPhil   thesis!   No
resemblance to individual researchers alive, dead or at York
is intended.

1 "I Am The Greatest"

     Firmly  believes that he is the greatest programmer  to
have  walked  the  earth and has the three-line  version  of
Tetris to prove it.

     IATG  spent  most  of  his undergraduate  days  in  the
terminal  room and only got a degree because he could  break
security  and decrypt the exam answers. Thinks in a  mixture
of  C  and  assembly language, thinks Real  Programmers  are
sissies,  has memorised even the unwritten volumes of  Knuth
(who he believes sold out the moment he started writing TeX)
and  has most of the source to obsolete Unix kernels in  his
room.  Has  VMS source on microfiche, mysteriously acquired.
Knows what the Lions Book is and has his own n-th generation
copy  of it. Has played a Plan 9 distribution CD ROM through
an audio player for fun.

     Nobody else can understand IATG's code, which suits him
fine,   and   absolutely  nobody  can  use  his   customised
environment,  which  also  suits him  because  it  means  he
doesn't have to answer questions about it.

     Absolutely   lethal  on  any  project  which   involves
collaboration,  documentation, theory, or distributing  code
to  other sites; IATG is best steered away from research and
into hacking for GCHQ or similar.

2 "Internet Vegetable"

     Probably spent most of his early career sitting next to
IATG  in the terminal room but was reading the news instead.
IV  brings a new approach to research programming. IV has  a
near  religious belief that the Internet is infinite in size
and  therefore  must contain, accessible via anonymous  FTP,
precisely  the package which is needed to solve the  problem
at  hand. The problem is of course that it either won't  run
on  any  of  the machines on site and necessitates wholesale
upgrading  of software and hardware, or requires  "just  one
more"  patch to be obtained via the net. When it does  work,
often  IV  is instantly disappointed by the vast  shiny  new
package  and  throws  it all away in favour  of  some  other
package which "may well do the job". IV knows where  to  get
an infra-red weather map of Hawaii for 1963 and a program to
display it on a TI 99/4A emulating a Commodore-64.

     IV  can  survive at sites with tolerant  sysadmins  and
good  connectivity -but use of disk space is tremendous  and
demands  for  OS  upgrades,  net  bandwidth  and  new  disks
phenomenal... once in a while IV finds something useful  but
is  usually too busy looking for something else to  actually
install it or port it.

3 "Rabid Prototyper"

     RP  has read all the books on software engineering  and
believes that you should build things incrementally and  use
prototypes. Unfortunately, RP takes it to extremes  and  re-
starts from scratch almost every day, trying new approaches,
new  user  interfaces, even new languages, in an attempt  to
achieve  a design of such amazing elegance that all who  see
it  shall be awe-struck. Unfortunately, every time RP has  a
new  idea  it means all the old work is thrown out,  and  in
many  cases  this happens before any decent  components  are

     RP tends to have an arcane knowledge of Unix tools like
lex,  yacc,  Perl  and Awk and RP systems are  usually  held
together  by the most incredible array of plumbing since  an
Italian hotel water closet.

     With  someone to catch the pieces thrown away by a good
RP  things  might actually get done, and it can't be  denied
that  they  often  have good ideas, but the  sheer  lack  of
commitment makes them impossible to cope with for any length
of time.

4 "Get New Utilities"

     GNU,  as suggested by the name, believes that there  is
One  True Source of good software and it's the Free Software
Foundation.  Not content with the perfectly  good  utilities
and  compilers shipped with the system, GNU has to have gnu-
cat, gnu-rm, gnu-everything before any work can be done.  Of
course, because gnu-anything usually requires gnu-everything
else  to  build,  you always end up with a complete  set  of
gnutilities  filling  your user disk leaving  no  space  for
research  work. Come to think of it, because GNU  is  always
applying  patch to the gnuseless  programs  he
needs to build more gnuseless programs, there isn't any time

     On the rare occasions when GNU actually does write some
code  it'll require the entire GNU CD-ROM to be shipped with
it before it'll even compile on a standard machine.

     Useful  to have at least one of them around, but beware
getting  two GNUs, since they'll inevitably both want  their
own collection of software...

5 "Square Peg; Round Hole"

     SPRH  wrote a good program a couple of years ago, which
solved  a  problem nicely and had some useful  bits  in  it.
Since  then,  however, SPRH has moved to a new project  with
new objectives. This doesn't matter, since as far as SPRH is
concerned ALL software is reusable.

     The  old  program  will either grow enormously  into  a
multi-modal,   immense  crock  held   together   by   hidden
parameters,  mode bits, recondite options and  obscure  data
types,  or  will  shatter  into a disk  full  of  libraries,
macros,   class  hierarchies  and  fiddly  little   separate
programs  which used to fit together but now  need  so  many
intermediaries   to   communicate   that   they've    become

     SPRH often looks productive, but that's because most of
the  work was charged to another project five years ago,  or
whatever  work  is  going  on is  just  another  attempt  to
bludgeon code into an alien Weltanschauung.

6 "Objectionably Oriented"

     OO  experienced a Road To Damascus situation the moment
objects  first  crossed  her  mind.  From  that  moment   on
everything  in  her  life  became object  oriented  and  the
project never looked back. Or forwards.

     Instead,  it kept sending messages to itself asking  it
what  direction it was facing in and would it mind having  a
look  around  and  send me a message  telling  me  what  was

     OO  thinks  in Smalltalk and talks to you in Eiffel  or
Modula-3;  unfortunately  she's filled  the  disk  with  the
compilers for them and instead of getting any real work done
she's busy writing papers on holes in the type systems  and,
like all OOs, is designing her own perfect language.

     The   most   dangerous  OOs  are  OODB  hackers;   they
inevitably  demand a powerful workstation  with  local  disk
onto  which  they'll  put a couple of hundred  megabytes  of
unstructured, incoherent pointers all of which point to  the
number  42; any attempt to read or write it usually  results
in the network being down for a week at least.

7 "My Favourite Toy Language"

     MFTL  knows  the  solution to  the  problem.  The  only
problem is, we haven't got a compiler for the language  that
it  should be implemented in. MFTL knows only two languages;
his  favourite  toy language and the language  you  need  to
compile  its  compiler. (If a language can compile  its  own
compiler then it isn't a toy!).

     The  problem  with TL compilers is that the  code  they
generate  is  often  inefficient and  impossible  to  debug;
however good MFTL is as a programmer the system will be huge
and  clunky...  in  many cases the TL also  needs  extensive
runtime libraries and support tools to be distributed.

     Is  more  likely to spend time tinkering  with  the  TL
compiler than actually working on the project; dreams of the
day  when TL is implemented in TL, and will probably  resign
as  soon  as  it  is,  unless it's a Functional  Programming
project - almost all of them are about writing compilers for
someone else's TL.

8 "Give Us The Tools..."

     GUTT  already  has the software to solve  the  problem.
Whether  custom-written or commercial, it's excellent  stuff
and  works  nicely; it's robust, it's simple  and  neat.  It
often  originated from the last site that GUTT was  employed
at and there's the problem...

     It  doesn't run on any of our machines. GUTT  seems  to
have  been living in an alternate reality in which  Scrotely
Whizzbangs running ScroteOS and StainedGlassWindows are  the
most  popular computing environment and has begged,  stolen,
borrowed or even written software to suit.

     The  problem is of course that outside Ruritania nobody
on Earth has ever heard of Scrotely Systems and the software
isn't worth a row of beans to anyone...

     Since  Scrotely  went out of business five  years  ago,
truly  great  GUTT  people spend months trying  to  write  a
Scrotely emulator on your local machines; mere mortals spend
their  time posting to comp.sys.scrotely and comp.sys.foobar
to  ask whether anyone has ever tried porting anything to  a
Foobar 250...

9 "Macro Magician"

     Macro  Magician believes that programming  is  obsolete
because you can make any program sit up and beg via  use  of
its  command  or macro language; MM can solve  your  problem
with a quick macro here and a bit  of shell  script there to 
hold it all together. There  are two  types  of MM; the Unix 
Macro Magician (UMM)  and  Micro Macro Magician (MMM).

     Whether  it's  solving the Towers of  Hanoi  in  vi  or
sorting lists in TECO, UMM knows how to do it. UMM pipes his
.profile through the C pre-processor and watches it  rewrite
itself  every  time  he logs in; the vast  majority  of  UMM
systems  are  implemented  in Emacs  Lisp  and  require  all
2.5Gbytes  of  the latest distribution before  they'll  even
think  about running. They usually take at least as long  to
run as to write. the other end of the scale MMM is into HyperCard,
ToolBook and other BiCapitalised pieces of syntactic  sugar,
although  also relishes the chance to delve into  the  macro
languages  of  word processors, databases and  spreadsheets,
preferably all at the same time; ideally using everything to
build  an  application which takes a week to  start  up  and
keeps flashing up obscure menus and dialogue boxes.

     No  cure  for either of these, sadly. Best bet is  240v
through their chair.

10 "Nightmare Networker"

     NN  relishes complexity. The database runs  on  an  IBM
somewhere  in Canada; the X-windows front end on a  Hewlett-
Packard  in Switzerland, the inference engine on a  Cray  in
Indonesia and the program itself on Voyager II... each  part
of  the packages employs different comms protocols depending
upon  a  wide  range of factors including the phase  of  the

     There  is  no  doubt that NN can create a system  which
works,  but  it's impossible to explain to mere mortals  and
keeps getting more and more complex. NN firmly believes that
"it's  all  virtual  anyway", unfortunately  including  such
things as execution time and network bandwidth.

     NN   can   be  exhilarating  to  work  with  but   also
infuriating  -  never  let NN tinker with  your  workstation
because  in no time flat it'll be running EBCDIC  to  SixBit
translation  software  routing X.500 address  requests  from
Uzbekistan  to  Ouagadoudou via a steam  powered  TCP/IP  to
Alohanet  gateway in Auchtermuchty...  Best relegated  to  a
support job if at all possible.

11 "Configuration Unmanageable"

     Never  produces anything remotely useful, but  has  all
the  crud that he has ever written under a wonderful change-
management  system. Literally everything he's ever  written,
from  "fank  you leter to aunty doris by me age(6)"  to  his
underpants, is stored under RCS with proper versioning  etc.
Want version 8.2 of his O-level English essay? There it is.

     Somewhere in there are 14000 versions of the source  to
the  current  project; CU saves and generates  a  new  build
every time a single character changes because "you can never
be  too  sure"... CU is also an archive freak and his office
is  habitually  filled  with  magtapes,  QICs  and  Exabytes
containing a complete backup of the revision notes about the
versioning policy of the document identification scheme  for
the  change-management procedure for the  backup  procedures
for the system.

     Words  like "anal retentive" have been used to describe
CU  but  he  can't  look them up because there's  no  longer
enough space for the online dictionary...

     Impossible to work with and to get any work out of.  Is
more  likely to be out spotting trains or collecting  stamps
than working in any case.


12 "Artificial Stupidity"

     Two  types of AS researcher exist and both of them  are
hell to live with. The more traditional type spends most  of
the  day  counting  parentheses in epic  Lisp  programs  and
trying  to  tell Prolog systems about families. If  he  gets
mixed  up  he  just fires up Eliza and tells  it  about  his
family  until  it  crashes with boredom...  Truly  great  AS
researchers get their Prolog programs to talk to Eliza about
their   families  and  spend  the  rest  of  the   time   at

     The  new type is into Neural Networks and spends  hours
(and  megabytes) with kludgy, flaky software creating arrays
full  of  zeros  and  the odd one here and  there  for  good
effect. Interminable programs generate huge files with these
in,  in an attempt to prove that you can tell the difference
between  margarine  and  butter in less  than  ten  hours...
Occasionally   has   video  cameras  and  image   processing
software,  run  like the clappers when this happens  because
invariably  it  will  be unable to distinguish  you  from  a
picture of Cecil Parkinson or suchlike.

     The  problem  with AS researchers is that  the  systems
they  create are at least as stupid as the people who create
them. Avoid at all costs.

13 "Number Crusher"

     NC knows the solution to the problem - it's a couple of
seventeenth-order non-stiff bloody hard integral  equations,
and  there's a routine somewhere in the NAG library to solve
them.  Isn't  there?  Unfortunately  NC  isn't  much  of   a
programmer  (strictly FORTRAN or the most K&R-ish  C  you've
seen for years) and isn't quite sure which routine, or which
parameters, or for that matter which library...

     NC is often not a computer scientist - physics or maths
backgrounds  are  common - and tend to  have  the  clunkiest
working environments on machines you've ever seen. Keep  all
their files in one directory and name them F44433232.DAT and
suchlike.  Almost always have a Julia set  as  their  screen
wallpaper (Mandelbrot is a bit old hat and doesn't  take  up
enough processing power...)

     Knows  a  lot  about  the likes of Uniras,  GINO-F  and
similar.  Can  be  relied upon to have  the  floating  point
format  for  the  machine  tattoed inside  her  eyelids  and
mumbles  Denormal, Abnormal, Inf, NaN! in her  sleep  (while
the system recompiles). Is the only person in the office who
can  remember  O-level  maths and as  such  is  occasionally

14 "Meta Problem Solver"

     Believes  that  the  problem can be  solved  by  either
finding  a  solution to a well-known problem which  can  map
onto  your problem, or by creating a tool which can generate
a  program  to solve the problem. MPS usually  knows  a  lot
about  automata, language theory and obscure algorithms  and
revels in complexity.

     Often sounds plausible, but the meta-problem which  MPS
keeps  trying to solve generally generates a whole  slew  of
meta-meta-problems,  and  the  meta-meta-problems  in   turn
infect   the  project  with  meta-meta-meta  problems,   and
eventually MPS either disappears up his own rear end or ends
up  having  to solve the Halting Problem before he  can  get
anything else done.

     An  MPS on the team can be extremely exhilarating,  but
most  of  the time it's downright difficult. Many MPSs  were
formalists  or mathematicians in another incarnation,  which
can  make them difficult to deal with. Their programs  often
run better on a whiteboard than on a computer.

15 "What's a Core File?"

     The  deadliest  of  the deadly, WACF drifted  into  the
Department  from some other planet and still  believes  that
computers are magical, strange, contrary beasts. Every login
session is a strange and terrible adventure. Has a filespace
full  of .dvi files, editor backups, text files called aaaa,
bbbb,  cccc, xxxx and suchlike and a few core dumps (usually
caused  by  the window manager or kernel, since WACF  rarely
programs).  Generally  uses one or two  killer  applications
which hammer the fileserver or the net, but forgets to  kill
them  off  and  ends up with seventeen text  editors,  eight
window managers and a dozen or so clocks running at any  one

     As  long  as  you  can  convince WACF  not  to  do  any
programming  you  might have a chance of  getting  something
done.  Ideally  one should buy them a PC or Macintosh  which
isn't attached to the net. Oh, and protect the system files,
because  WACF has been known to delete things like MSDOS.SYS
to save space.

16 "I Come From Ruritania"

     Used  to  be  the  best programmer in Ruritania,  where
computers  run on steam and use trinary deontic  logic  with
lots of don't cares.  Regards 8k of memory as a paradise  of
unheard-of proportions and doesn't trust windowing  systems.
Speaks  fluent  Ruritanian and starts off seeming  to  speak
good English, but gets confused whenever the phone rings  so
doesn't  bother  answering it, only  believes  things  other
Ruritanians tell him and insists on using the office  as  an
informal Ruritanian social club.

     Some  ICFRs  are actually excellent programmers  by  any
standards,  but  the effectiveness of their work  is  blunted
rather by the fact that (A) if you can persuade them to write
user  documentation it will display a choice of  grammar  and
vocabulary  which  is  at  best idiosyncratic  and  at  worse
somewhat  like  a Sun manual; added to this the  code  is  of
course all commented in perfect Ruritanian. It's often fun to
dig  out their CVs or read their mbox files, which they often
seem  to  leave  unprotected. Unfortunately in several  cases
ICFRs have left their girlfriends back home unprotected  just
before coming to the UK; being present at the birth by  email
is a difficult option.

17 "Old Fart At Play"

     Every  institution has one. OFAP has been  around  since
(as   a  bare  minimum)  the  mid-sixties  and  regards  such
arriviste  architectures as VAX as  being  unproven  and  too
modern. OFAP regards the PDP-6/10/Decsystem-20 line as  being
the One True Architecture and reckons characters are six bits
wide,  never mind all this ASCII rubbish, let alone  Unicode.
Delights in explaining the CAILE instruction at coffee breaks
and maintains an FTP archive of old PDP-10 operating systems.
Was mentioned in HAKMEM and is delighted when he finds anyone
else who's heard of it.

     OFAP has occasionally been convinced to port some of his
code  to Unix, but of course never got further than V7.  Once
tried to port Spacewar to a modern machine but it wasn't fast
enough.  Knows that Sketchpad is the greatest drawing program
ever.  Knows what all the funny mode bits in obscure  TECO  Q
registers  are  used for, and exploits them in his  programs,
which  are  an unholy mixture of assembly language  and  TECO
macros. Dangerous, usually has a beard (even if female),  but
is useful to have around because s/he has seen it/done it all
before  and knows the tricks - just don't let OFAP  implement

18 "I Can Do That"

     ICDT  tends  to  be  an enthusiastic new  graduate  and
mistakes  user  interface for functionality. That  is,  once
ICDT  has  seen a program running he believes  that  he  can
"knock  up a quick hack to do that in a week". Four or  five
years  later  the "quick hack" is still unfinished,  because
ICDT  doesn't  understand the underlying semantics  or  data

     Combining  an ICDT with another programmer is  often  a
damn  good  idea as long as someone can curb his enthusiasm.
There  is  a slight downside in that most ICDT programs  are
predicated  upon a huge and unreliable user interface  class
library  -  InterViews is particularly popular for  creating
mock-ups of programs that will never work, although in  this
enlightened  day  and age Visual Basic and  Visual  C++  are
starting to take over as media for creative delusions.

     May  be  a useful member of an HCI group or some  other
motley  crew in which programming skill isn't important  but
getting pretty pixels on screen is vital.

19 "What Colour Should That Be?"

     Has  read all of the books on HCI and believes all  the
contradictory stuff that's contained in them. Always  has  a
more  expensive machine than you, usually with a  very  nice
colour  screen,  sound  card, Dataglove,  voice  recognition
equipment  etc.  -  and  no keyboard,  because  WCSTB  can't
(won't?)  type.  Is  more likely to  be  a  psychologist  or
sociologist than a real computer scientist.

     WCSTB   basically  prefers  tinkering  with  typefaces,
colours,  screen layouts and window-management  policies  to
programming,  although most WCSTBs have a working  knowledge
of  some  of the surprisingly grubby depths of either  X  or
Windows,  in order to facilitate the above. A typical  WCSTB
"Hello  World" program is four hundred lines long and  takes
up  a  meg  and  a  half when linked, but is  essentially  a
complete  multimedia experience with a non-threatening  user
interface  and  configurable  options;  at  that  rate  it's
perhaps surprising that none of the WCSTBs ever get anything
more substantial written.

20 "It's Safety Critical..."

     ISC   is   the  barrack-room  lawyer  of  the  research
community. Since the application areas in which he works are
closely  allied  to blowing things up/stopping  things  from
blowing up he takes a considered and principled approach  to
software development for safety critical systems - his claim
is  that  "all  software is unsafe and  I'm  damned  if  I'm
writing any to complicate the issue".

     In  theory this is fine, but occasionally ISC is forced
into writing some code by whoever holds his grant. Depending
on  what  sort of safety critical project he's involved  in,
this  will either be low-level bit-twiddling in C,  PL/M  or
assembler  on  a single-board computer (which  ISC  secretly
loves because you basically don't have to do any V&V on  it)
or  will  involve  interacting with  twenty  different  CASE
tools,  eight design notations and four formal methods  with
subtly incompatible semantics. Tends to be employed on  long
contracts, and with a development process like that can  you
blame him?

Peter Fenelon - Research Associate - High Integrity Systems Engineering Group,
Dept. of Computer Science, University of York, York, Y01 5DD (+44/0)904 433388
Email: ``Art is a science with more than 7 variables''

[=] © 1993 Peter Langston []