|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
Nikolai Bezroukov. Portraits of Open Source Pioneers
For readers with high sensitivity to grammar errors access to this page is not recommended :-)
|"Without wanting to be elitist,
the thing that will prevent literate programming from becoming
a mainstream method is that it requires thought and discipline.
The mainstream is established by people who want fast results
while using roughly the same methods that everyone else seems
to be using, and literate programming is never going to have
that kind of appeal. This doesn't take away from its usefulness
as an approach."
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
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 Knuth did not understand the usefulness of dynamic provision of frames which contain slice of program text, hypertext language reference and code fragments libraries but that is just natural extensions of his approach. With two or three 19 inch displays one can get pretty substantial working area for three of four representations of the program.
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 ;-)
The very act of communicating one's work clearly to other people will improve the work itself
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.
I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title: "Literate Programming."
Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.
The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.
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.
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
Documentation sections of the program can hyperlink with code
sections and cross-reference table.
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.
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.
Incorporation of outlining and slicing into programming environment
(extraction of documentation of code from a mixed document is a special
case of outlining)
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.
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.
Literate programming is not without problems and this might explain low level of adoption of this technology.
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.
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.
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.
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 .
Most published examples of literary programming are pretty dull and actually more discredit then attract people to the technology.
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 ;-)
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
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