|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells
Institute of Applied Iconoclasm
Department of Computer Science, University of York
I Am The Greatest
Get New Utilities!
My Favourite ...
Give Us The Tools!
Meta Problem Solver
What's A Core File?
I Come From Ruritania
Old Fart At Play
I Can Do That!
What Colour ...
It's Safety Critical!
During the course of a computer science research project (or even a Ph.D research project) 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 Ph.D thesis! No resemblance to individual researchers alive, dead or at York is intended.
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 memorized 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 customized
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.
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 huge disk space and good connectivity, but demands for OS upgrades, net bandwidth and new disks are 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 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 written.
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.
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 220.127.116.11.4.12 to the gnuseless programs he needs to build more gnuseless programs, there isn't any time either.
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...
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 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.
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 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.
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.
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...
Scripting Magician believes that programming is obsolete because you can make any program sit up and beg via use of its shell, scripting or macro language; SM can solve your problem with a quick script or macro here and a bit of shell script there to hold it all together. There are two types of SM; the Unix Script Magician (USM) and Windows Scripting Magician (WSM).
Whether it's solving the Towers of Hanoi in shell or sorting lists in perl, USM knows how to do it. USM has a .profile that self modifies itself on each login; the vast majority of USM systems are implemented in Emacs Lisp and require all 2.5Gbytes of memory 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 WSM is into HyperCard, Visual Basic and other BiCapitalised pieces of syntactic sugar, although he also relishes the chance to delve into any macro languages available on the earth; ideally using everything to build an application which takes a morning to start up and keeps flashing up obscure menus and dialogue boxes for the rest of the day.
NU is an extremely organized, devoted and motivated workaholic that relishes complexity. Given freedom he quickly changes your networking infrastructure so that each database communicates with middleware server over two firewalls; the X-windows desktop on Sun workstation is exported to HP-UX and then is viewed in vnc on windows, There will be also three chained Sendmail systems in DMZ each with slightly different function, but none working completely reliably without his constant heroic efforts to deliver them in time. DNS is split and your root server is somewhere in Germany.
There is no doubt that NU can create a system which works, but it's at least twice as expensive and impossible to explain to mere mortals, to say nothing to maintain it without his presence. He himself often login from home to keep things working. 10 hours on the computer each day is a normal workload for NU.
NU firmly believes that security is important, especially if it interferes with the productivity.
If you assign his to run webservers each page will be generated via complex Perl scripts and then dynamically converted to XML with in turn will be dynamically converted into XHML with dynamically generally CCS stylesheet. The content will be two year old as nobody will be able to change any page on this server without breaking it completely.
NU can be exhilarating to work with but also infuriating - never let NU tinker with your DMZ or you will be running two webcaching security-enhanced appliances (neither can correctly display msnds page without some tweaking), a dosen firewalls with central Provider-1 console and a couple of load balancers to balance load of almost completely idle server. He will try to persuade everybody that it is impossible to use streaming protocols without installing a $30K cashing appliance in each and every lab.
Best relegated to a support job if at all possible.
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.
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 conferences.
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.
NC knows the solution to the problem it's always the same differential equation that he is working with since his childhood. And he uses Mathematica to adapt it to a new reality making the solution even more sophisticated and even more useless each time. Usually has Ph.D. Often murmurs that university students should be taught differently as their differential equation course no longer corresponds to the need of the industry. Unfortunately NC isn't much of a programmer (Mathematica, some FORTRAN or at most K&R-ish C he do not fully understand ) and his programs contain all typical mistake numeric programming warms about. He often isn't quite sure which routine, or which parameters, or for that matter which library he is using...
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 flow if liquids, aerodynamics and similar. Can be relied upon to have the floating point format for the machine tattooed inside her eyelids and mumbles Denormal, Abnormal, Inf, NaN! in his/her sleep (while running another variation of his differential equation).
Is the only person in the office who actually remember university maths and as such is occasionally useful.
Believes that any problem can be solved by either defining it as a special case for 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 of superficial things 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.
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 time.
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.
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. Loves Norton Commander, 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:
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, 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.
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 structures.
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.
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, colors, 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.
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 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?
Former Document URL: http://purists.org/academic/
Last modified Thu Oct 25 by Georg Kraml.
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: September 12, 2017