May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

History of development and key concepts of Orthodox Editors

Dr. Nikolai Bezroukov

Version 0.81 (March 27, 2015)

Copyright 1998-2013, Dr. Nikolai Bezroukov. This is a copyrighted unpublished work. All rights reserved.


Notion of Orthodox interface

Eastern Orthodox Editors

Western Orthodox Editors



This paper tried to introduce a new concept: orthodox editors as a special category of editors. All of them have command line set of commands and respective glue macrolanguage. We have found two such families:

We define the notion of  "orthodox editors" as having the following distinct features:

  1. They have a well-defined command set that is comparable in power to GUI based commands and command line can be used to enter editor commands. For some of them (vi - line ) that comes naturally, from the fact that they were initially designed for typewriters. 
  2. They permit doing any editing task using keyboard  (although mouse can speed up or simplify many of those tasks and is not rejected in the extremist way)
  3. They use a standard scripting language as a macrolanguage (TCL, REXX) or unique for the application (YASL  - yet another scripting language) like in vim 6 as a macrolanguage. It serves as a glue for the command set implemented by the editor. With some reservations we can accept  a unique for the application (YASL  - yet another scripting language) like in VIM. This is definitely less attractive solution as it is difficult to master the language that you use only for a specific application (in this case an editor).  The same consideration is applicable to Emacs. 
  4. They support folding (all command in XEDIT and its derivatives; folding capabilities in VIM )
  5. They distinguish between editing buffer and the windows in which this editing buffer is displayed allowing multiple windows to display the same buffer.
  6. They support regular expressions
  7. They permit processing selected part of the editing buffer or all the buffer via pipe connected to external command (! command in vi)
  8. They support multiple views of the same editing buffer.
  9. They allow piping in output from arbitrary pipe into the current position of cursor, selection, or all buffer as well as exporting a selection or all buffer as an input stream for an arbitrary pipe.  

This article is a modest attempt to create a basic classification useful for further studying this important class of editors. The author argues that this class of editors can serve as viable mid-weight editors for programmers (see a companion paper A Note on Size-based Classification of Text Editors for this further discussion of related ideas).

This article is a modest attempt to create a basic classification useful for further studying this important class of editors. The author argues that this class of editors can serve as viable editors for programmers providing despite Spartan interface rich functionality absent in almost any other editor with possible exception of vi and its derivatives. Despite integrating a macro language they are actually pretty small, mid-weight by some standards (see a companion paper A Note on Size-based Classification of Text Editors for this further discussion of related ideas).

Please note that both subclasses of orthodox editors were pioneers in introducing several important for any modern editor features, features that unfortunately still are absent or poorly implemented in most other editors: 

This paper explores two sets of deep interconnections that were previously unnoticed in the literature:

Actually the second point was the main reason that I decided to use a superclass term "orthodox editors" that includes as subclasses both XEDIT editors line and VI editors lines. Not only because I like to invent new terms (that goes with Ph.D ;-), but I really see deep similarities between them and their connection to a similar phenomenon that I studied earlier in case of File Managers (see OFM page for details).

In other words those tools are second representatives of a different approach to GUI interface then Apple GUI or Microsoft GUI (which are converging). Interface that can be called "Orthodox Interface" and which originated in Xedit, vi and NC.  And this Spartan interface with ancient-looking, "half-baked" GUI with command line present at the bottom of the screen give users important and unique capabilities that are missing in other similar "pure GUI" Tools. And those tools survived despite all odds because they are capable of giving advanced users the ability to achieve an extremely high productivity, beating competition. Although some design decisions in those editors were dictated by limitation of old hardware they withstand the test of time and proved to be useful and extremely productive tools for modern environments.


I abhor a system designed for the "user", if that word is
a coded pejorative meaning "stupid and unsophisticated".
-- Ken Thompson

I would like to stress that an editor is probably the most important tool for programmers, therefore one needs to choose it wisely. A popular consideration that easy to learn editor (for example Pico or Notepad) is the best does not withstand any critique. An editor is too important tool for programmers to settle for the basic capabilities and it's a big disadvantage to select a mediocre or worse, primitive editor such as Pico just because it's simple to learn. It's like settle for life to use Basic.   Any professional programmer needs a professional editor.

Any professional programmer needs to learn a professional editor. Any professional sysadmin needs learn a professional editor too

In case you are a casual user simple editor might make sense, but still lack of  growing space is a disadvantage.  But for everybody else this is one of the most serious mistakes that you can make -- a mousetrap to avoid. You do need a powerful editor or you will regret your choice the rest of  your professional career (that in case you will be able to switch somewhere during active phase of your career; otherwise you have pretty good chances to die in happy ignorance ;-).  Bad habits are difficult to change and usage of a primitive editor is such a bad (and pretty widespread) habit.  Naive tales like "How I like Pico (or Notepad)" are amusing the same way as stories about people who voluntarily deprive themselves of basic staff and enjoy this state of deprivation.

The main problem that I see is that people tent to stick to whatever editor they got used to first and even became emotionally attached to the "first choice". It happened to me and it took me a lot of efforts to move from a primitive editor to a decent one. Often this "first choice" is a pretty mediocre editor that is/was widely used in a particular environment, but that not necessary is able to provide high performance in all typical editing tasks.

The author argues that programmable editors are worth studying like programming languages and a powerful editor is huge advantage from the point of view of reaching high productively (and avoiding many typical frustrations).  In this paper I would like to draw an attention to two old but still viable programmer editors that I included in a broad class of Orthodox editors.

Please note that both subclasses of orthodox editors were pioneers in introducing several important for any modern editor features, features that unfortunately still are absent or poorly implemented in most other editors:

This paper explores two sets of  deep interconnections that were previously unnoticed in the literature:

Actually the second point was the main reason that decided to use a superclass term "orthodox editors" that includes as subclasses both XEDIT editors line and VI editors lines. Not only because I like to invent new terms, but I really see deep similarities between them and their connection to a similar phenomenon that I studied earlier in case of File Managers (see OFM page for details): all this tools give users the ability to achieve an extremely high productivity both in GUI-based and  non-GUI environment. Although some design decisions in those editors were dictated by limitation of old hardware they withstand the test of time and proved to be useful and extremely productive tools for modern environments.

Orthodox Editor Definition

I will call the editor Orthodox if  and only if:

Both Orthodox File Managers and Orthodox Editors are descendants of some very old implementations with unique features that were not preserved by most more modern and more fashionable editors that replaced them.

Two Families of Orthodox Editors

We will distinguish between two families of orthodox editors:

There are some important common features in those two families despite the fact that REXX is full-fledged scripting language while VIM-macro language is an ad-hoc (and pretty limited) YASL (Yet another scripting language) development. There are also some interesting links between  Eastern Orthodox Editors and  Orthodox File Managers.

Notion of Orthodox interface

Orthodox interface is the interface that has both command line interface elements and GUI interface elements glued together.  As cynics would say this is a half-baked GUI-interface and this statement definitely has some truth as at least one of them  emerge during attempts to convert previously pure command line tool to GUI (text terminal GUI) mode: this was the case with vi which was text terminal GUI extension of ex editor.  Apple and Microsoft GUI interface attempt to hide from us the internal command that you mouse gestures are generating, while orthodox interface attempts to expose it.

In Orthodox interface there is always a set of commands that exists as a language with text  names for functions and parameters and glued together by control structures. Special keys and key combinations as well as mouse buttons and mouse gestures are just shortcuts to this basic set of commands. So interface is split into two parts:

This existence of formal internal language is the most distinctive feature of orthodox interface.

And this idea was invented and reinvented by so many people that it looks like this is a new different type of interface, distinct from Apple-Microsoft interface.

For example this is true for various OFM, for orthodox editors such as vi or XEDIT like of editors (Edit, Kedit, THE, Slickedit), for GNU screen, smith in AIX and many other programs.  Those tools were from the beginning designed is a way that allow coexistence of command line with GUI interface. So in a way Orthodox interface is all about co-existence of two principal forms of computer interfaces in a single program by using command line as the focal point. 

That means that we can look at orthodox interface as a compiler of GUI "gestures" into regular command language with text representation. Those generated statements of this command line language are executed to achieve the desired effect.

We can also introduce idea of channel: each channel forward generated or manually written commands to specific processor. For example we can thing about vi as having two command channels: one is ": channel" (internal commands channel) which process commands directed to editor buffer and another is "! channel" (external commands channel) which direct commands to OS with the possibility of using all or part of editing buffer as input as well as to modify all or part of the editing buffer using output of executed in OS command of complex pipe. 

In OFMs this is implemented differently: there is a single "OS command channel", but there is not distinct "internal command language", althouth some OFMs recently moved in this direction.

All-in-all I am convinced that the notion of Orthodox interface as an interface distinct from and based on different principles then Apple and Windows GUI interfaces (which are actually became much closer with time). As such this is a much wider phenomenon then either OFMs and orthodox editors such as vi and THE (orthodox editors),  windows multiplexers (GNU screen), windows managers (such as ratpoison).

I am still working on refining this notion but as a set of  ideas it definitely includes three following notions:

  1. Extensibility and programmability (with shell and/or scripting languages) are key to enhancing productivity of advanced users and as such they should have much higher priority for designers of the interface then chrome.  This "the ability to program as second literacy"  paradigm (see  Ershov1972 ) inherent in orthodox interface is actually radically different design paradigm than the one used in classic Apple-Microsoft GUI with their emphasis on "users" and  multicolor eye candy with gradient colors icons and fancy animations.
  2. Orthodox GUI is a "visual shell".  Like classic Unix shells, Orthodox GUI should have least one "command channel": ability to type statements in some formal language which, when executed, change the state of GUI. In other words they implement what can be called "command line controlled GUI". It can be just "external" command channel where commands  go directly to OS (like in OFMs), or internal command channel where commands are processed by internal interpreter (for example REXX or Lua) and reflected on the part of editing buffer that is displayed as in orthodox editors, or some combination of both. Commands that are entered into command channel are executed immediately like in shell and the result is immediately reflected in GUI interface. They can be glued into complex scripts by some ad-hoc or (preferably) standard scripting language like REXX or LUA.
  3. Elements of  automatic program generation with the help of GUI.  Another way of looking on orthodox interface is to assume that GUI "gestures" in it first are compiled into some command line language and that those generated statement are executed by command processor and cause corresponding changes in GUI screen. That means that we can (and probably should) look at orthodox interface as a compiler of GUI "gestures" into regular command language with text representation. Those generated statements of this command line language are executed to achieve the desired effect.

    GUI can also be used in supplementary role to generate part of command line construct that are written by the user on the command line by inserting certain elements via macros or shortcuts like (Ctrl-Enter, Ctrl-[ and Ctrl-] in OFMs) and any other creative way. Generally in OFMs you can "assemble" pretty complex commands from elements of GUI (and freely move within directory tree in a process without destroying it, the capability that was always a desirable part of Unix command interface)

    Recently those ideas related to vi and orthodox editors started cross-pollinated OFM that consider themselves not derivatives of Norton Commander, but derivatives by  vi  See ranger and vifm. have some interesting, distinct from traditional "Norton" line of OFM ideas implemented.

There are also some other common features but they just overlap and extend the three more fundamental features listed above:

  1. Tiled, nonoverlapping windows with minimum decorations. Generally both Orthodox editors and Orthodox file manager feather rather Spartan interface.
  2. Stress on availability of all commands via keyboard, not only via mouse clicks, althouth mouse can be productively used and is widely used in such interface. In this sense claim that such interfaces are "mouse-less" is completely untrue. Simply mouse plays the role of important but supporting instrument, not as the primary instrument as "drag and drop" type of interface. 
  3. Stress on availability of macrogenerator. This is connected with viewing shortcuts as the means to generate some internal commands.
  4. Stress on the ability to utilize pipes and external program as a source of gui elements. This is especially visible in vi with its ! and !! commands. Ability to redirect output of commands executed in one window to other windows and processes. That includes the ability of forwarding result of particular command execution into panel in OFMs (panelize command in OFMs, especially external panelize command in Midnight Commander) and capability of ! command to use part of editing buffer as input and pipe the result into selected part of editing buffer in vi. For example, the command:
    will beautify your program using standard Unix beautifier (indent). This is a classic example of using piping in vi.

Eastern Orthodox Editors

The level of sophistication of command line interface in EOE is pretty high and I would argue that a professional can achieve in this environment a higher productivity than with any editor that relies mainly on mouse and menus.  This family is probably the oldest production-level folding editors in (XEDIT seems to be around on VM/CMS from late 80th) in existence and it still in wide use. 

The initial version XEDIT was released by IBM in late 1980 and as Melinda Varian (Princeton University) wrote in her very interesting history of VM "There can be no question that by releasing XEDIT in 1980, IBM gave CMS a new lease on life". Here is the quote from her very interesting paper ( I strongly recommend to read at least the beginning of this 73 pages paper -- it provides new insights into how two most interesting operating system Unix and VM/CMS were influenced by Corbato's CTTS and MIT Multix project):

At the same time, we started seeing the results of IBM's new commitment to VM. VM System Product Release 1 came out late in 1980. VM/SP1 combined all the [B]SEPP function into the new base and added an amazing collection of new function (amounting to more than 100,000 lines of new code): XEDIT, EXEC 2, IUCV, MIH, SUBCOM, MP support, and more. There can be no question that by releasing XEDIT in 1980, IBM gave CMS a new lease on life. Within no time, programmers and end users were building large, sophisticated applications based entirely on XEDIT, stretching it to its limits and doing things with it that IBM had never envisioned. That they were able to do that was a tribute to XEDIT's author, Xavier de Lamberterie. 130 (If you've ever wondered where the ``X'' in ``XEDIT'' came from, now you know---it was Xavier here.) It was also fortunate that those XEDIT macros could be written in the new language EC 2, which was considerably faster and more powerful than VM's original EXEC processor. The author of EXEC 2 was Chris Stephenson, of IBM Research.

130 When asked what other editors influenced the design of XEDIT, Xavier graciously replied with the following note (X. de Lamberterie, private communication, 1989):

Well, XEDIT comes from a long way. It has been influenced by the editor from CPˇ67, then some other editors that were developed locally at the Grenoble University (including editors with macro capabilities, which were probably the first ones to have such a concept), and certainly from Ned that we had a long time ago (some XEDIT target commands are inspired from Ned). Then later on, when full screen displays were available, XEDIT took some ideas from Edgar and ISPF (features like prefix line commands).  But I guess the major feature of XEDIT was to keep the "heart'' relatively small and allow users to redefine and/or extend the existing commands via EXECs or REXX macros. This was one of the major successes of XEDIT.

Members of this family of editors are best known to users OS/2, VM/CMS and users of TeX . Even one flavor of DOS used to have such an editor: IBM DOS 7.  Inside IBM developers had access to epm (derived from e / e3 / peII / tiny etc). My understanding on epm is the author of  epm left IBM and started (with others) Visual SlickEdit.

I consider folding (actually there are several types of folding -- the one implemented in EOS is usually called  slicing (in most EOE it is implemented as command All).  The second important type of folding  is outlining as implemented in MS Word and other word processors as well as in best HTML-editors) -- also an extremely useful feature. Once you have got used to the folding paradigm, you will not want to use a flat editor again! See also the main page that probably can help you to understand why folding is so important.

All members Eastern Orthodox Editors family use REXX as a scripting language, but this is not principal feature --  conversion to TCL seems possible and even desirable, especially for THE

THE is GPLed editor and probably is as portable as Emacs. The unique feature of this category of editors is so called selective editing or slicing. All members of the family (almost two dozens actually, if you count all implementations) have all command. It  that provides for selective pattern-based slicing of test based on regular expression with the capability of editing. Underling mechanism of selective display is very powerful and can be used for outlining. I never saw similar capability in other editors.

Among commercial editors Slickedit has a very similar feature, under the name of The Selective Display dialog. It uses ad-hoc C-style macro language instead of REXX. This language, called Slick-C, is the actual implementation language for the editor. Almost all editor is written in Slick-C and the binary code is just the Slick-C interpreter.

The most important innovation 1:  Folding

I consider folding a very important feature of any programmer editor, the feature without which programmer is unable to achieve the highest productivity and job satisfaction possible. Actually there are several types of folding

Folding is a special case of program abstraction and as such is linked to program understanding issues. There are some interesting research ideas relevant for this topic. Based on the results in this area it's evident that pure syntax-based folding (or it's indenting-based surrogates) are too rigid and not that useful and why simple all command in Xedit style editors is such a flexible and powerful tool that  in many cases beats more "program navigation" systems. 

Most users who were exposed to the folding paradigm valued it so high that they are ready to experience some disadvantaged by adopting an editor that support it. Most never want to use "a flat editor" again! That's why, paradoxically, due to its outlining capability (and macro language) early versions of MS Word (Word 4) were used as a programming editor :-).

Although orthodox editors are one of the oldest family of editors in existence they still hold their own against competition. May programmers consider editors without command line and imbedded scripting language inferior to editors that have this capabilities no matter how much GUI frosting is present. 

This page also establish important implicit links between Eastern Orthodox Editors and Eastern File managers (I suspect that the first implementation of the orthodox manager were based of Xedit in CMS environment. The other important link is the link between EOE and WOE or VI-style editors with folding capabilities (VIM).

In this page I will mainly concentrate  Eastern Orthodox Editors  or EOE editors (Xedit was originated in IBM and as everybody knows IBM is on the East Coast).

The most important innovation 2: Usage of a standard scripting language (REXX) as a macro language

Usage of standard scripting language has distinct advantage over "vendorspeak" type of macro language used in most programming editors. The skills are transferable and that stimulates deeper learning of the language while with vendorspeak skills are limited to the editor environment which typically is not sufficient incentive to study it deeply and keep your knowledge current.

Because EOE uses a standard scripting language, orthodox editor community developed a lot of interesting macros, much like Emacs community.  Please take a look at  THE macro contributions from users...

Western Orthodox Editors

The important thing to understand is that like Xedit-style editors VI is also an editing philosophy (set of ideas of how editor should be), not only the implementation. And this philosophy is quote different from the mainstream GUI editors. That's why Windows users usually have so many problems mastering vi. That also means that there can be and actually are implementations that are much better than the original vi, but that adhere to the same philosophy.  One of such implementations is VIM and in starting form version 6 it is a very powerful editor that satisfy the requirements of the orthodox editor and can be considered as a representative of a new, different family of orthodox editors -- western orthodox branch, You can call it catholic editors, if you wish :-).

Despite its Spartan appearance (actually not that Spartan in the VIM GUI-based version for Windows ;-)  vi contains some unique ideas and while the initial version of vi have had no scripting language at all if was definitely written in the same spirit of attention to command line that is characteristic for  Eastern Orthodox editors (VM/CMS Xedit, THE, Kedit).

Due to its Unix roots VI has unique features that other editors do not have and some non-Unix editors cannot have in principle (due to absence of OS support for them). Actually some of these features can never be found in Windows-style editors. Among the most importa unique features of vi:

  1. The idea of access to buffers via pipes -- really great and even today pretty novel idea that is essentially absent in any other family of editors that I know. This ability was extended in VIM to the ability to use Perl for operations on the buffer.  Here VI was a real pioneer and just for this feature alone we can forgive a lot of shortcomings...

  2. Use of regular expressions. The precursor of VI Ed pioneered use of regular expressions in editing and this is still probably one of the best support of regular expressions (a feature that until recently was a weakness of Eastern orthodox editors).

  3. A set of the command line commands (this is an essential feature of orthodox editors. Unfortunately the set of commands taken from ex is far from being perfect and can benefit from modernization.

  4. The ability to invoke any shell command from the editor (! escape on the command line). That means the ability to construct arbitrary complex pipes and then access the results.

  5.  Text-buffer execution, which operates only in command mode: once text has been placed in any of the named text buffers, that text can be executed as if it were a sequence of 'vi' commands.

  6. A pretty idiosyncratic but very interesting idea of two modes -- command mode and text mode. The fact that editor survived is an implicit confirmation of the fact that this idea help to perform some class of tasks. In some respect I suspect that this feature provides an implicit "mini command line":  the possibility of creating short sequences of commands that perform a particular function at the current location. Such sequences sometimes has internal logic (like in dd -- delete line; dw -- delete word, dc delete symbol, etc) that simplify memorizing them. That means that like orthodox file manages users, power VI users eventually acquire piano player like motor skills for performing typical tasks, especially configuration files maintenance tasks.  As one researcher put it (cited in There is A Perfect Editor):

    Experienced emacs and vi users, who use their editors to write and edit English text, performed a series of basic editing tasks and wrote a movie or book review. Our findings suggest that moded editing, as exemplified by the vi editor, may be preferable for fixed editing tasks, while modeless editing, as exemplified by the emacs editor, may have some advantages for free composing.

I believe that it was VIM 6 that opened the possibility of usage of vi as the standard mid-weight editor for programmers. Old vi implementations deprive the user from a significant subset of functionality that should be typical for mid-weight editors. In this sense VIM6 is the first really decent implementation of VI editing philosophy. Among shortcomings of the old versions I would like to mention:

All-in-all I think that VIM6 is a very interesting and very convenient for some operations editor that preserved all major advantages of the original VI and removed most of its shortcomings. Let's reiterate the most important and innovative features of the original vi editor again:

Actually VI command set emulation can be an interesting test for any midweight or heavy-weight editor including THE. For example Emacs is able to emulate VI using viper package

In any case please, please do not use old implementations of vi, if it's possible to use VIM6. Please use vim6 as it supports most of the features required for a decent mid-weight editor including folding, undo/redo, Perl integration, etc. See also If you gotta use VI, use VIM. Linux Gazette August, 1995

Generally editor is usable if it satisfy the following criteria:

  1. Users must be able to accomplish their editing task with minimal effort (that's a complex question and advanced vi users can argue that the presence of command mode increases productivity in correction of programs and configuration files, but this is not very convenient in composition)

  2. The editor must always provide feedback to the user to help him to understand what is happening. (here vi is rather bad -- there is almost no feedback in vi).

  3. The editor should not produce any unexpected results at any point in the process (not true for the combination of windows users and vi ;-)

  4. Users should not suffer from information overload (this is the case with vi as the user need to know more than a two dozen of keys and a dozen commands to be minimally productive; this is a definite drawback, but there is no free lunch )

  5. The editor must be consistent at every point in the process. This is a (weak) argument against command mode/insert mode, but people are very flexible ;-)

For users with windows experience vi breaks rules 1-3 and 5. Anyway,  vi is default editor on Unix and even if you hate vi, you still need to learn at least the minimal subset if Vi/Vim commands. Vi knowledge is also part of Unix/Linux certification requirements. 

The most important innovation 1:
Regular expressions as an editing tool

Regular expression of an editing tool was an innovative idea 30 year ago, but now it's almost commonplace. Still the level of integration of regular expressions in command set is different between editors and most editors provide just find command that support regular expressions. vi in its command set, which is essentially ex editor command set went farther then that.

The most important innovation 2:
Concept of Editor Buffer Piping

VI and its derivatives possess a unique powerful feature that is not present in any other class of editors. This feature is the possibility of access to editor buffers via pipes. Despite being almost 30 old it still looks like a pretty novel feature, which is a sure quality of really revolutionary innovations: simple and poweful at the same time.

In VI the pipe is applied to editing buffer both as a source and as a destination. A VI pipe is thus can alter the buffer using standard Unix filters that instantly become a part of editor toolbox. This is an extremely elegant idea. The ability to pass nearly arbitrary chunks of text through any UNIX filter adds incredible flexibility  at no "additional cost" in size or performance of the editor. 

This ability was extended in VIM to the ability to use Perl for operations on the buffer.  Here VI was a real pioneer and just for this feature alone we can forgive a lot of shortcomings


Both classes of editors can benefit from greater awareness of the developer community about each other. Some solutions like XEDIT-style folding or VI-style buffer piping are perfectly adaptable as cross-family solutions.

Users can greatly benefit from the availability of well defined command set and glue language for it (especially standard one line TCL or REXX.  The power and flexibility achievable via command line set cannot be replicated in a pure GUI environment.




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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard 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 DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting 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-MonthHow 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-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) 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 to buy a cup of coffee for authors of this site


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