Nikolai Bezroukov. Portraits of Open Source Pioneers

For readers with high sensitivity to grammar errors access to this page is not recommended :-)

Literate programming

The idea of literate programming is an combination of several ideas including idea of hypertext and the idea of  content management applied to program sources. It was proposed by Donald Knuth in 1984 in his article Donald Knuth. Literate Programming published in Computer Journal (British computer society publication) but it was clouded by Knuth excessive attention to typography. 

While the term got some traction, unfortunately the idea itself cannot be completely counted as one of Donald Knuth successes. Unlike TAOCP or TeX it never caught up and had a rather cool initial reception. But that does not mean that the idea was/is without merits and later some components of it became standard part of every decent IDE.

But the whole idea of literate programming was three key components:

• The first is essentially an re-invention of benefits of hypertext representation of program and its documentation for software writing.  As originally conceived by Don Knuth, literate programming involves prettyprinting code: displaying it using several fonts with proper nesting and systematic line breaks. It probably was inspired by the "publication syntax" of Algol 60 as used in CACM and other computer magazines. Now it is easy to covert any program test to HTML as there are (often multiple) converters almost for any language in existence. As such HTML is a better markup language then TeX, but we need to remember that at this time when Donald Knuth wrote his article HTML did not exist (This idea was described in his paper in Computer Journal, 1984). TeX was created using this approach and simultaneously used in a bootstrap fashion but the key notion is classic idea of hypertext.

  It is interesting to note that Donald Knuth ( interview on CWEB, "Why I Must Write Readable Programs") named the original literate programming tool/language WEB long before WWW was created. The literate-programming FAQ quotes Knuth as saying

  The philosophy behind WEB is that an experienced system programmer, who wants to provide the best possible documentation of his or her software products, needs two things simultaneously: a language like TeX for formatting, and a language like C for programming. Neither type of language can provide the best documentation by itself; but when both are appropriately combined, we obtain a system that is much more useful than either language separately.

  The structure of a software program may be thought of as a web that is made up of many interconnected pieces. To document such a program we want to explain each individual part of the web and how it relates to its neighbors. The typographic tools provided by TeX give us an opportunity to explain the local structure of each part by making that structure visible, and the programming tools provided by languages such as C or Fortran make it possible for us to specify the algorithms formally and unambiguously. By combining the two, we can develop a style of programming that maximizes our ability to perceive the structure of a complex piece of software, and at the same time the documented programs can be mechanically translated into a working software system that matches the documentation.

  Now it is simpler both to discuss and implement ideas of literate programming in the HTML context as the latter is now dominant markup language. It is actually a historical accident that the markup language for Web was created on the base of SGML and not on the base of  TeX. But right now HTML rules and Web server can be the cornerstone of an implementation of a literate programming platform.  Most utilities and www browsers will convert HTML back to plain text, for example the Linemode browser or Lynx:

  lynx -dump "some-URL" > my-text  # See the Lynx documentation

  Netscape and Internet Explorer let you "save as" web page as plain text
   

• The second is the view of program writing as a new type of literate work.  The key finding is that writing documentation/notes along with program improves quality of both, often dramatically. An ideal program, Knuth used to say, can be read by the fireside, like good prose. This idea was field tested by Knuth himself while writing TeX and was first described in his paper in Computer Journal, 1984. Knuth essentially reiterated old and powerful maxim that the very act of communicating one's work clearly to other people will improve the work itself.

  The key idea is that there are more symmetric relationships between program and documentation. That means that different views such as "program text only", "documentation only", "mixed view", "program text and XREF table", etc should be provided as an essential part of programmer  toolbox along with such classic features as folding and outlining. System that provides multiple views is very useful in working with program code. Attempts to view a program as a book were not new and isolated components of Knuth vision were refined long before TeX.  For example the whole XPL Language compiler was documented in the book A Compiler Generator by McKeeman, Horning and Wortman, published by Prentice-Hall, 1970, ISBN 13-155077-2.  Special class of editors, called orthodox editors provided sophisticated folding (see Orthodox Editors Page). Prettyprinters for various languages were knows since late 60th.

  What was new is the idea of the tools that can make such method of writing of program more smooth and efficient. Knuth vision was limited to paper representation as his style of programming evolved around working with printouts and became fixed in time and space. But interactive tool is definitely more productive for most people and  can be by integrating capabilities of a simple Webserver as a viewer, programmable HTML editor like Frontpage and programmable IDE like Eclipse. 
   

• The third idea is that content management tools including those similar to tools used in books like cross reference table has tremendous effect on minimizing initial number of errors in the program and as such make debugging less labor intensive.  Again as Knuth method of programming is structured as writing program text in pencil and then working with paper printings. While Knuth did not understand the usefulness of dynamic provision of frames which contain slice of program text, hypertext language reference and code fragments libraries this is just natural extensions of his approach. With two or three 24 inch displays one can get pretty substantial working area for three representations of the program.  So IDE that allow this (say one sliced representation, on just comments, and one text without comments have an advantage of traditional representation of the program in one or two windows (with different regions of program in each)

Instead of writing code containing documentation, the literate programming suggest writing documentation containing code. Knuth indicated that he chose the name "literate programming" in part to contrast with "structured programming", which was the fashion of the time and which he apparently felt pointed programmers in the completely wrong direction (and he was 100% right on this; now nobody even remember all this fundamentalist ramblings, only positive things like enhanced control structures survived the test of the time from all structured programming blah-blah-blah   ;-)

In his later book on the topic [ pg. 99.] Knuth stressed the importance of writing programs and documentation as a single interrelated process not as a two separate processes.

Now after so many years and after Web and HTML became firmly entrenched we can reformulate the idea of literate programming in WWW terms. Actually usage of TEX while a tremendous step forward is not optimal for literate programming and actually negatively affected subsequent acceptance of "literate programming" as a technology. In WEB terms we can view literate programming as a certain specialized wiki framework with several distinct features.  

1. Sections of Wiki which represent code are automatically converted into "neat" format using pretty printing and syntax highlighting for program source (this is already an old hat; typographical niceties that now became pretty much standard  in any programming environment GUI).
    

2. Documentation sections of the program can hyperlink with code sections and cross-reference table.
    

3. Automatic code extraction with or without documentation sections and submitting the resulting text file to compiler and interpreter. This should be completely automatic (BTW that is achievable in many modern HTML editors, including FrontPage, Dreamweaver, etc).  HTML provides server side which can be used to include program fragments into a composite document.
    

4. XREF tables as an important part of  programming environment (currently the best way to generate then is to use the editor with pipe execution capabilities like SlickEdit of vim, or generate then into a separate window in the browser). Various class browsers were developed for partial symbol table generation.
    

5. Incorporation of outlining and slicing into programming environment (extraction of documentation of code from a mixed document is a special case of outlining)
    

6. Availability of blog-type sections that can document the progress of the work.

All sub-technologies that are linked under the umbrella of literate programming are pretty well known and used by programmers for a long time.  But nobody managed to link them together into a coherent meta-technology and style of programming before Knuth. For example cross-reference tools were a part of any good programmer toolset from early 60th. Pretty printing of programs also comes from early 60th. Syntax highlighting in pretty printing was almost as old as pretty printing itself and reappeared in editors with the introduction of color displays.  I also know that in early 70th many programmers used document editors like MS Word with its outstanding outlining capabilities instead of  a programming editor with considerable success.   Orthodox editors like Kedit and SlickEdit are close to this approach due to support of programmable folding.

But at the same time, while serving as a integration point for previously isolated technologies,  literate programming create a qualitatively new paradigm of program development.  At the same it allowed for further development of each of the underling technologies in new directions. For example software visualization is much broader  and much more complex subject that just TeX based program representation.   What is really important is the viewing program as a literate work, book or article, not just an ability to manipulate the program in various ways that increases its understanding.

XREF tools, syntax highlighting and outlining are just three approaches, three tools that help to solve comlpex problem of content management of large programs.   The "missing link" (integration of all three into Wiki style environment)  probably can explain rather cool acceptance of the idea.

In modern environment the usage of HTML (and HTML editors such as Frontpage) is preferable to usage of TeX.  TeX proved to be not a very flexible way to develop a complex programming code and as such it does not provide any significant advantages over will developed IDE with the elaborate code browser, instant syntax checking and project management tools like Visual Studio or Eclipse

Now with HTML widely used and wiki technologies available it's might be a good time to take a second look on the initial ideas and re-implement most sound concepts in a new way with much better integration and flexibility then TeX permits.  The great advantage of using HTML is simplicity and availability of excellent html editors like FrontPage. The real question is how to integrate cross references, indices, outlining and "syntax highlighted" sources in an attractive, flexible system.

Key Problems with Literate Programming

Literate programming is not without problems and this might explain low level of adoption of this technology.

1. There is no silver bullet in program understanding/program writing and like any technology "book-style" representation is better for some purposes and worse for others.
    

2. The key problem with literary programming is that it is a static representation. Understanding (and writing) of the program requires flexible dynamic representation. Also generation of program text from the markup representation creates the classic problem of two texts although it is less severe in comparison with problems that arise in macro substitution and can be amended by usage of Wiki style environment where access to underling representation is available only for editing. 
    

3. Also omitted from the concept of literary programming the idea of folding and outlining which are two powerful tool that simplify writing of complex documents and programs.
    

4. Generating XREF tables is only one approach to the visibility of variables in the program. There are many other. Again, the programmer can benefit from many views of his variables not just a single table. Typical SQL-style queries might be useful .
    

5. Most published examples of literary programming are pretty dull and actually more discredit then attract  people to the technology. 

Working Environment

It looks like Professor Knuth is pretty Spartan in his needs and uses a regular Linux-based Intel computer for most of his work. It does not look like he is using some fancy proprietary tools that might speed up development. It is somewhat strange, but Donald Knuth uses this huge monster called Emacs as an editor and one of the most tiny windows managers Fvwm2 as a windows manager. Here is his Fvwm2 configuration:

# This Fvwm2 setup file provides the basic emacs-centered environment
# that I have found most comfortable on my standalone machine at home.
# Basically it gives me a big Emacs window at the left and a slightly
# smaller XTerm at the right, together with a clock and CPU monitor
# and a few buttons for accessing independent desktops.

# I've tried to write lots of comments because I will certainly forget
# most of the details of Fvwm2's syntax and semantics before long.

# My screen is 1024 pixels wide and 768 high; about 88dpi.

# First, make sure that Exec chooses tcsh instead of bash:
ExecUseShell /bin/tcsh

# Next, specify the path to the Fvwm modules:
ModulePath /usr/lib/X11/fvwm2

# Next, specify the paths for all icons (.xpm files) that I'm using:
# PixmapPath /usr/share/icons:/home/icons
ImagePath /home/icons:/usr/share/icons

# I tried mxn desktops and didn't like them.
DeskTopSize 1x1

# X's font rendering without anti-aliasing looks least bad with the following:
WindowFont -adobe-times-bold-r-*-*-18-*-*-*-*-*-*-*
IconFont -adobe-helvetica-bold-r-*-*-10-*-*-*-*-*-*-*

# "gainsboro" is a light grey; it's for the active window border
HilightColor black gainsboro

# FVWM style menus have a 3D look but not exaggeratedly so;
# this MenuStyle option must come first
MenuStyle * FVWM

# I'm guessing that gold letters on deep blue background will make cool menus
MenuStyle * Foreground gold, Background #000060, Greyed #202080
MenuStyle * Font -adobe-times-bold-r-*-*-14-*-*-*-*-*-*-*

# With FocusFollowsMouse and AutoRaise, I don't need to click for attention.
# (FvwmAuto will raise the window after one second = 1000 milliseconds.)
# But I set SloppyFocus on text windows below; this keeps them focused
# when the mouse goes over an empty ("root window") area.
Module FvwmAuto 1000 Raise Nop
Style * FocusFollowsMouse

# Setting HandleWidth to 7 makes the handle 6 pixels wide; this seems
# most effective for a classy 3D look (2+2+2).
Style * BorderWidth 7, HandleWidth 7

# I'm glad I don't have to use the ugly "unknown1.xpm" that came as default...
Style * Icon unknown.xpm

# The default colors for window titles and frames might as well be documented:
Style * Color white/dimgrey

# The next is just to provide approximately decent behavior when a program
# has been written to follow protocols of Motif or OpenLook:
Style * MWMFunctions, MWMDecor, MWMButtons, HintOverride, OLDecor

# Transient windows will get title bar and other decorations by default.
Style * DecorateTransient

# Icons are supposed to cluster in the upper right part of the screen.
# (I could specify another IconBox for overflows, if I need it...)
# This specification evidently applies on all desktops.
# The number 488 is the width of my emacs window; FvwmButtons are 132x84
Style * IconBox 330x84+488+0, IconFill right bottom

# Try to place in open space, otherwise at random
Style * SmartPlacement, RandomPlacement

# (Here I originally used "SuperSmart placement", knowing full well that
#  the documentation said that the GlobalOpts feature was "temporary"....)
# GlobalOpts SmartPlacementIsReallySmart
# Now in version 2.4, we do it this way:
Style * MinOverlapPlacement

# XTerm gets the icon that I made from Royal Shell's web pages.
# (It surely is protected by trademark, but it's just for me at home.)
Style XTerm Icon royalshell.xpm, SloppyFocus, NoTitle
Style Emacs Icon emacs.xpm, SloppyFocus, NoTitle
Style XOsview Icon xosview.xpm, ClickToFocus
Style Gimp Icon gimp.xpm, StaysOnTop
Style XEyes NoTitle, StaysOnTop, Sticky, WindowListSkip
Style Xmag Icon xmag.xpm
Style Metafont StaysOnTop

# (By the way, it's interesting to try "while(1) ;  xeyes & ; end".)

# Now for mouse commands in the root window R:
# Left mouse button brings up Root-Menu; middle button brings up Window-Ops
# Clicking instead of dragging makes the menu stay up; cursor is <== then.
# Double-clicking takes the menu away.
# Here "A" means an arbitrary combination of shift/meta/control/numlock etc.
Mouse 1 R A Menu Root-Menu Nop
Mouse 2 R A Menu Window-Ops Nop
# Right button gives window list. Caution: Double clicking gets you a sort of
# random window, because double-click control comes only with a Menu spec!
Mouse 3 R A WindowList

# I'm putting three buttons in the titlebars of ordinary windows.
# At the left (which Fvwm calls button 1), a lightning bolt;
# this will close the program when touched with any mouse click.
# (It does NOT pop up a menu. Closing is better than Deleting and Destroying:
# it tries to delete gracefully, then destroys if the window is uncooperative.)
Mouse 0 1 A Close
ButtonStyle 1 Vector 7 \
  65x15@0 25x55@1 45x55@0 35x85@1 75x45@0 55x45@1 65x15@0
ButtonStyle 1 - MWMDecorMenu

# At the right, a button that iconifies the window; we draw a small square
# (because I tried to draw an X but it looked horrible):
Mouse 0 2 A Iconify
#ButtonStyle 2 Vector 17 \
#  20x20@1 30x20@1 50x40@1 70x20@1 80x20@1 80x30@0 60x50@0 80x70@1 \
#  80x80@0 70x80@0 50x60@0 30x80@0 20x80@0 20x70@0 40x50@1 20x30@0 20x20@1
ButtonStyle 2 Vector 5 40x40@1 60x40@1 60x60@0 40x60@0 40x40@1
ButtonStyle 2 - MWMDecorMin

# Next to that, a button with a big square; this one maximizes the window.
# (More precisely, if you double-click, the window goes to full screen size;
# if you single-click, it goes to full height but keeps its width.
# But if the window was already in "maximized" state, it goes back to normal.
# If you try to drag this button, it unconditionally goes to full width.)
Mouse 0 4 A Maximize-Function
ButtonStyle 4 Vector 5 20x20@1 80x20@1 80x80@0 20x80@0 20x20@1
AddtoFunc Maximize-Function "D" Maximize 100 100
+                           "C" Maximize 0 100
+                           "M" Function Go-Max
AddtoFunc Go-Max  "I" Current (Maximized) Maximize
+                 "I" Maximize 100 100
ButtonStyle 4 - MWMDecorMax

# Ordinary windows also have title bar ("T"), corner frames ("F"),
# side frames ("S"), or iconic state ("I"). Left mouse in the corner
# will resize or raise; in the title or on the side it will move or raise;
# double raising is lowering. Left mouse on an icon moves the icon,
# or deiconifies it on double-click.
Mouse 1 F A Resize-or-Raise
Mouse 1 TS A Move-or-Raise
Mouse 1 I A Move-or-DeIconify
AddToFunc Resize-or-Raise "I" Raise
+ "M" Resize
+ "D" Lower
AddToFunc Move-or-Raise "I" Raise
+ "M" Move
+ "D" Lower
AddToFunc Move-or-DeIconify "I" Raise
+ "M" Move
+ "D" Iconify

# Middle mouse iconifies or deiconifies.
Mouse 2 FTSI A Iconify

# Right mouse raises or lowers.
Mouse 3 FTSI A RaiseLower

# The root menus are next. Since I'm perfectly happy with launching programs
# from a command line, my menus mostly provide functions that are difficult
# to type (for example, when no terminal window is handy) or impossible
# to activate from a command line (namely Fvwm's builtin modules).
AddtoMenu Root-Menu "Shell terminal (BIG FONT)" \
  Exec exec rxvt -font "-adobe-courier-medium-r-*-*-17-*-*-*-*-*-*-*" -rv
+ "Shell terminal (Normal Font)" \
  Exec exec rxvt -font fixed -rv
+ "Shell terminal (small font)" \
  Exec exec rxvt -font "-adobe-courier-medium-r-*-*-10-*-*-*-*-*-*-*" -rv
+ "Shell terminal (as root)" \
  Exec exec doit rxvt -font fixed -fg white -bg DarkRed
+ "" Nop
+ "Emacs (BIG FONT)" \
  Exec exec emacs -font "-adobe-courier-bold-r-*-*-17-*-*-*-*-*-*-*"
+ "Emacs (Normal Font)" Exec exec emacs
+ "Emacs (small font)" \
  Exec exec emacs -font "-adobe-courier-medium-r-*-*-10-*-*-*-*-*-*-*"
+ "Emacs (as root)" Exec exec doit emacs -bg DarkRed -cr black
+ "" Nop
+ "" Nop
+ "Show window info" FvwmIdent
+ "Talk to Fvwm" FvwmTalk
+ "Disable AutoRaise" KillModule FvwmAuto
+ "Enable AutoRaise"  Module FvwmAuto 1000 Raise Nop
+ "" Nop
+ "Exit Fvwm" Popup Quit-Verify

AddToMenu Quit-Verify "Really Quit Fvwm?" Title
+ "Yes, Take Me Back To The Shell" Quit
+ "" Nop
+ "No, Sorry ... I Didn't Mean It" Nop
+ "" Nop
+ "Try To Refresh"   Refresh
+ "Try To Recapture" Recapture
+ "Try To Restart"   Restart fvwm2

# The other root menu, invoked by the middle mouse button, gives me a chance
# to do any window operation on a window of my choice. (The cursor changes to
# a big black ball as I go searching for the window that will be affected.)
AddToMenu Window-Ops "Window Operations" Title
+ "Move" Move
+ "Resize" Resize
+ "Raise" Raise
+ "Lower" Lower
+ "Iconify/DeIconify" Iconify
+ "Stick/UnStick" Stick
+ "Maximize/Normalize" Maximize
+ "Refresh" RefreshWindow
+ "" Nop
+ "Delete" Delete
+ "Close" Close
+ "Destroy" Destroy

# Now comes the fun part: Buttons to push that will take me from one
# desktop to another.
#
# Being a control freak, I am not trusting FvwmButtons to find the
# correct button layout; I'm building it myself. The goal is
# to have a 64x64 ASClock at the upper right, preceded by four 32x32 buttons
# that will aim my display at another desktop, all above a 16x128 CPU load
# display. Geometry-wise, I consider it to be an 8x5 grid of 16x16 squares
# (although I could have regarded it as a 4x5 grid of 32x16s).
# The border adds 4 pixels.

*FvwmButtonsRows 5
*FvwmButtonsColumns 8
*FvwmButtonsGeometry 132x84-0+0
*FvwmButtonsBoxSize fixed
*FvwmButtonsFont None
*FvwmButtonsBack Orange
*FvwmButtonsPadding 0 0
*FvwmButtons(4x4+4+0, Swallow(UseOld,Respawn) ASClock "Exec exec asclock")
*FvwmButtons(8x1+0+4, Swallow(UseOld,Respawn) \
  XLoad "Exec xload -nolabel -geometry 128x12+0+0 -bg dimgrey -fg white")

# (I had to use a full path name here, because fvwm2-2.4.17 didn't find
#  the following four icons from the ImagePath specified above.)
*FvwmButtons(2x2+0+0, Icon /home/icons/zero.xpm, Action "Desk 0 0")
*FvwmButtons(2x2+2+0, Icon /home/icons/one.xpm, Action "Desk 0 1")
*FvwmButtons(2x2+0+2, Icon /home/icons/two.xpm, Action "Desk 0 2")
*FvwmButtons(2x2+2+2, Icon /home/icons/three.xpm, Action "Desk 0 3")

Style FvwmButtons ClickToFocus, NoTitle, NoHandles, Sticky, WindowListSkip

# Finally, the initialization and restart logic.
# (The pattern "mod 2 2" is an attractive 2x2 plaid texture.)
# (This is mainly where the "root" background color and other colors
#  are specified.)

AddToFunc Basic-Setup "I" Module FvwmButtons
+ "I" Wait FvwmButtons
+ "I" Exec exec xsetroot -mod 2 2 -fg \#001860 -bg \#183078
+ "I" Echo done with basic setup...

AddToFunc InitFunction "I" Echo initializing...
+ "I" Function Basic-Setup
+ "I" Desk 0 2
+ "I" Exec exec xosview -geometry 400x200-11+92
+ "I" Wait xosview
+ "I" Desk 0 1
+ "I" Exec exec rxvt -geometry 80x50-3-0 -fg \#fff4c0 -bg \#381900 -sr
+ "I" Wait rxvt
+ "I" Exec exec emacs -geometry 80x61+0+0 -fg \#ffe97a -bg \#00002b
+ "I" Wait emacs
+ "I" Desk 0 0
+ "I" Exec exec rxvt -geometry 80x50-3-0 -fg white -bg black -sr
+ "I" Wait rxvt
+ "I" Exec exec emacs -geometry 80x61+0+0 -fg \#ffe97a -bg \#002b00
+ "I" Wait emacs
+ "I" Exec exec xeyes -geometry 55x50+829+0 -fg DarkGreen -center Orange -outline dimgrey
+ "I" Wait xeyes
+ "I" Exec exec unclutter
+ "I" Echo ready...

#  (When I revised this file in 2003, I made the rxvt windows two characters
#   narrower, because emacs version 21 wants to be that much wider.
#   Similarly, I made emacs geometry 3 rows taller because I'm deleting the
#   new tool-bar --- and the geometry is figured before the tool-bar goes.)

AddToFunc RestartFunction "I" Echo restarting...
+ "I" Function Basic-Setup

# By putting the line "exec fvwm2 >& /tmp/fvmw.out" in my .xinitrc,
# I'm getting an error log in /tmp/fvmw.out. The following command
# writes a message to that log.
Echo Hello, world

As you can see Knuth prefers tcsh to bash ;-)

Etc

Society

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

Quotes

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

Bulletin:

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

History:

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

Classic books:

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

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 Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019