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.
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.
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.
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.
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...
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 incomprehensible.
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.
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 there...
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.
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.
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...
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.
...at 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.
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.
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.
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.
NN 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 useful.
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.
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.
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.
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 anything.
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.
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.
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?
Last modified: Thu Jan 16 11:50:07 EST 1997