Softpanorama

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

Softpanorama Bulletin
Vol 25, No.01 (January, 2013)

Prev | Contents | Next

Bulletin 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007
2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018
Jan Feb Mar Apr May Jun Jul Sept Oct Nov Dec

History of development and key concepts of Orthodox Editors

Dr. Nikolai Bezroukov

Version 0.71 (January 21, 2013)

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

Introduction

Notion of Orthodox interface

Eastern Orthodox Editors

Western Orthodox Editors

Webliography

Abstract

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). Those tools are representative of a different approach to GUI interface then Apple GUI or Microsoft GUI (which are converging). Interface that can be called "Orthodox Interface".  And this Spartan interface with ancient-looking, "half-baked" GUI with command line present give users important and unique capabilities that are missing in other similar "pure GUI" Tools. They survived 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.

Introduction

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 even primitive solution 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 need 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

[an error occurred while processing this directive]

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 mainenance 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

Conclusions

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.

Webliography

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

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org 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

Disclaimer:

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