A Note on Size-based
Classification of Text Editors

Dr. Nikolai Bezroukov

Version 0.35

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

Contents

• Introduction

• Lightweight Editors

• Mid-weight Editors

• Heavyweight Editors

• Webliography

Abstract

The article presents an attempt to understand correlation between features of text editors and editor size based of tasks each weight category performs better and1 propose size based classification of editors

The concept of "editor weight" is useful for explaining why most programmers use several editors (usually three: standalone lightweight editor like Notepad, midweight editor like Vim, Kedit or SlickEdit and heavyweight editor like Microsoft Visual Studio .Net, Emacs, etc).

That suggests that there are tasks for which one editor of a certain size suit best and perfoming of which with the editor of a different category is less efficient despite the additional power it might provide. This paradox that most programmers use several editors while leading one would be more efficient can be explained by the hypothesis that editors can be classified into three distinct categories and that each category of editors has its own unique set of features In this case one size does not fit all. We will distinguish 

• lightweight editors (editors that does not need installation and can be fully functional if the computer contains one executable and a user can start editing after moving this executable to new computer. They can  They can use additional initialization and configuration files but they should be optional of at max two files (editor executable and optional initialization file/files)

• midweight editors should have powerful macro language, folding and full multi-windows support. That's the category were orthodox editors fall into.

• heavyweight editors are essentially in IDE in disguise. Emacs is classic example of heavyweight editor, visual Studio .Net is another example.

The main idea here that there are tasks that are better, quicker performed by lightweight editors and they're are tasks that are better performed by midweight/heavyweight editors, so those categories of editors develop in different directions.

The concept of "editor weight" is useful for explaining that we need not one but several editors. This paradox that most programmers use several editors while leading one would be more efficient can be explained by the hypothesis that editors can be classified into three distinct categories and that each category of editors has its own unique set of features In this case one size does not fit all. We will distinguish 

• lightweight editors (editors that does not need installation and can be fully functional if the computer contains one executable and a user can start editing after moving this executable to new computer. They can  They can use additional initialization and configuration files but they should be optional of at max two files (editor executable and optional initialization file/files)

• midweight

• heavyweight

The main idea here that there are tasks that are better, quicker performed by lightweight editors and they're are tasks that are better performed by midweight/heavyweight editors, so those catagories of editors develop in different directions.

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 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 on the basic capabilities and it's a big disadvantage to select a mediocre or even primitive solution just because it's simple to learn.  Any professional programmer needs a professional editor.

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.

In this paper we introduce three categories of editors and discuss how each of them can help a programmer be productive. The author argues that a professional programmer need to muster at least two editors to achieve optimal productivity.

 Lightweight Editors

Those editors are usually used for making small corrections in program files or configuration files. They rarely used for editing text documents, even plain text documents. Based on this range of tasks they usually have several distributing characteristics:

• The main distinguishing feature of those editors is untraportability: they usually does not require any installation. You just need to put an executable to the computer and you can start editing. They can use additional initialization and configuration files but they should be optional. Old good vi was such editor. 

• Usually lightweight editors have a standalone executable that is less than 256K (an older limit was 100K :-); the current limit might be increased for modern compliers ;-) and thus can be loaded almost instantly.

• Should be able to work on any computer that have this executable and may be some initialization file (any editor that requires more then two files to be present for basic editor should not be classified as lightweight, but lightweight editor can use additional files if available (for example syntax coloring maps))

• Should offer syntax highlighting if color maps are available (might be not customizable)

• Should have flexible block editing

Lightweight editors usually have no multi-windows support. One important role for lightweight editor is to serve as a default editor in the file managers, see my OFM  page for a discussion. IMHO the compatibility and ease of use within OFM and integration with it is really important.  For this reason in Unix/Linux environment I would recommend mcedit. Despite some severe limitations, mcedit is well integrated with Midnight Commander and this combination provides unique productivity gains despite its shortcomings as an editor. See my super-lightweight links for additional details.  If you do not like mcedit FTE Text Editor  seems to be OK too. For Windows suitable candidates can be found in a category Notepad replacements ;-). Among them NoteTab Light looks especially promising and can be used with Total Commander.  Some people like QEedit (now Semware editor), but I don't. 

The obvious choice for Unix users is good old vi.  But I feel that it outlived its usefulness: unless absolutely necessary you probably should not use plain-vanilla Vi supplied with Solaris or HP-UX. If you can, use vim instead: it's a much better implementation of the same paradigm and it even supports some Perl integration. On current PCs with 3 GHz CPU and fast drives VIM6 can probably be used as both lightweight and mid-weight editor. Actually light version of vim is used instead of the standard vi in most Linux distributions.

Mid-weight Editors

Often have a standalone executable that is approximately less than 512K. This class includes some powerful professional editors like THE. In addition to features present in lightweight editors they should have:

• macro language support (might be not full scripting language).

• ctags support. "Bookmarks" for remembering positions in files to return to later (Exuberant Ctags support is desirable)

• customizable syntax highlighting

• menu with definable hotkeys. Reconfigurable keyboard shortcuts for everything

• full multi-windows support. Should support linking of windows (called also splitting -- the ability to view the same file in multiple windows).

• unlimited undo/redo

• piping in (to insert the output from a UNIX command into a file, immediately after the cursor) and out (passing range to a pipe that possibly write to an editor buffer).

• Comprehensive online help

• Set of keyboard commands for manipulating words, lines and paragraphs at a time
• Rectangular selection

Still usually this class of editors not necessary has folding/condensing/outlining ( like all command in THE). Probably one of the best examples of midweight editors can serve vim. BTW it  has a very good windows port. If you use Java then  jEdit - Open Source programmer's text editor might be close. GWD Text Editor  also can be considered. JED is also very close and has a macro language.

In Windows environment Microsoft Visual Studio editor is pretty primitive, but it has a scripting language support and can come close to the requirements above.   Moreover in a particular environment of Visual Studio it's almost a standard editor. 

Important Note: support for piping and using Perl or other scripting language is a very useful feature. that's why vim6 is probably one of the best choice for midweight editors, but only for qualified users with Unix experience.  For Windows users it might make sense to use a heavyweight editor instead. 

OK, I will not go so far as to outlaw all other mid-weight editors in existence in favor of  open source editors. Proprietary editors sometimes have important advantages, but still some of open source editors  are very portable, have a reasonable quality and probably will be supported for the rest of your professional life. Among them I would recommend to try both THE and Vim6. Vim6 is generally underappreciated editor that is especially attractive for users who use Unix extensively as vi is a standard editor on all commercial Unixes and you need to know it to be productive. For users that predominantly use Windows it might make sense to use heavyweight editor instead: you can buy Slickedit and it's a pretty much OK editor, if you have company funds available. It has non-standard scripting language and it sucks, but otherwise the editor is OK. SlickEdit is portable to all major flavors of Unix including Linux. The main drawback is that it's too expensive for home/hobby use.  If you never use Windows MultiEdit might be an interesting choice too. It has very good windows management capabilities.

The principal advantage of  VIM6 as a vi-style editor in comparison with other lightweight editors is the support of processing of the buffer by arbitrary external shell filters -- a very elegant and nice feature. Another very interesting capability and the ability to executing shell commands without leaving an editor. The ability to execute the content of the buffer as simple script is also pretty unique and quite useful. But cut and past operations in vi are not that good (although in GUI version of VIM6 there are acceptable). What is really important is that VIM6 even supports folding. Missing scripting language are OK for midweight editor, but  not very flexible multiwindows capabilities might be a disadvantage.

If VIM6 looks too idiosyncratic (and that is usually the case for Windows users, although VIM Windows implementation is really decent) and you still want OSS editor my recommendation is to try JED. It does not support piping the buffer but it has a better multiwindows and scripting language support that provides a lot of very useful functionality.

Heavyweight Editors

This class of editors has no size limitations and should have GUI version that should be able to take advantage of full GUI capabilities like different fonts, overlapping windows, etc.  Thus, most  heavyweight editor generally does not have a command line version (although MultiEdit for DOS and Emacs are notable exceptions) 

The second requirement is to have a built-in ftp-client, so that the editor can be used in a cross-platform environment.

I consider this kind of editors as one of the most important programmer tools that programmers should use for daily work. This class is represented by such well-known names as XEmacs, Kedit, MultiEdit, SlickEdit and even MS Word. GVIM 6.1 is close but it's not here yet -- no decent macro language. Some TCL-based editors, for example Tkedit might also came close.

Required features for this class of editors include:
 

• A powerful, preferably standard scripting language as a macro language. Again I would prefer standard multiplatform scripting language like REXX, TCL, JavaScript (or VBScript), Lisp or Perl rather than unique or proprietary language that you will never master and even if  you manage to master it, you soon forget everything due to insufficient practice (as is often the case with users of MultiEdit or SlickEdit).
   

• A powerful, built in FTP client.
   

• Full multi-window paradigm support (with capability of editing the same text in several windows -- linked windows; THE provides correct semantic for this -- operation of opening a new window leads to display of the current file in it; it can be replaced with a separate load command). Tabs for bookmarks and/or windows (preferably with colored tags like in Jed or Excel).
   

• Folding and outlining -- selective pattern-based editing  (like implemented  all command in Xedit/KEDIT/The family). Nesting-based outlining is a very useful feature too but it can be easily implemented as a macro if folding capabilities are present. 
   

• Definable syntax highlighting.
   

• Interface to OS filters, utilities and compilers (for example via piping like implemented in vi family that provides such capabilities as spell checking, pretty printing via external utilities). IMHO pretty printing is a very useful feature for heavyweight editors, but the best way to implement it is probably to use external module via piping interface as in VIM.

Among open source editors the natural choice would be XEmacs but it looks somewhat outdated for me. Still it is a very flexible editor with Lisp as a scripting language. I definitely prefer Kedit (or any other Eastern Orthodox Editor) but it's not available for Unix/Linux. SlickEdit is but it has a proprietary macrolanguage.

XEmacs is capable to meet almost all requirements listed above and for many programmers it serves as an pseudo IDE. As one XEmacs user put it Xemacs is my operating system, Linux is my device driver ;-)

One of the most problematic things with heavyweight editors is that it is not easy to learn all those capabilities and its easy to forget all what you learn due to absence of practice. As I already mentioned that is especially bad for scripting. The best cure for this problem is to study the editor that supports a standard scripting language.  Currently there not that  many editors that support standard scripting languages. Eastern Orthodox Editors support REXX, some editors support TCL ( for example Tkedit) and Microsoft editors can be used with JavaScript or VBscript and that's about it.

REXX, the  traditional for EOE scripting language is no longer popular and thus two other variants might be a better deal (JavaScript or  TCL) but it's user dependent and should be waited against other capabilities of the editor.  There is no easy choice...

If you try to learn to use a more powerful editor after learning a simple one like Visual Studio editor, then first you will feel yourself like a foreigner. And usually at the beginning you will hate this new clumsy editor. But after a while you will never be the same -- you will start to appreciate features that they provide and even if you will not switch, you will definitely be more productive with your old editor. This reasoning also applies to windows users learning vim -- it's an old editor, but it does have several unique convenient features that are usually absent in  flashy DOS/Windows-style editors (for example the ability to process any part of the buffer with the standard Unix filters like indent or Perl interpreter). 

I was lucky enough because at various stages of my career I used (and for some wrote quite a lot of macros) several different middleweight and heavyweight editors including MultiEdit,  Orthodox editors (Xedit/KEDIT/THE family), Vi family (vim, vile, etc.) and MS Word (BTW not a bad programming editor with quite powerful outlining, but no folding/slicing). It's interesting to note that  MS Word is quite suitable for literate programming and some of my friends used it as such.  

I also used a dozen or so lightweight editors like  FTE, QEdit (now Semware editor), WordStar-based Borland IDE editors, DOS-edit, mcedit as well as special purpose editors like Heavy Metal Pro or FrontPage (please note that both FP2000 and FP2002 are scriptable using VBA). But of course I do not know them as well as I know THE/Kedit line or MultiEdit.

This class of editors should support all features of middleweight editors and more. You can think about them as a GUI-based midweight editors, or like the best editors money can buy, kind of Cadillac of editors ;-). The most important feature of a heavyweight editor in the proposed classification is folding/outlining and a comprehensive scripting language support. 

Naturally the most important and quite religious question is what scripting language in the best in the editor -- there are so many of them. As an orthodox preacher I would like to warn you against joining some obscure cults ;-).  You should chose the scripting language wisely -- preferably the one that you already know. Stay away from proprietary C-like scripting languages -- IMHO they are difficult to remember unless you use them n daily basis, which is a very rare mode of work (that happened with my MiltiEdit macro programming skills -- they simply disappear).

TCL, JavaScript, REXX, Lisp are all applicable outside the editing domain and that's an extremely important consideration. If you use Perl them VIM or other editor that support processing of the buffer with scripts is the best. To master scripting language used in the editor is really important, but you will have almost no chance to achieve this if you do not use the language for solving other tasks. See my overload page for details. My own preferences are with REXX, TCL and JavaScript (can be used instead of VBScript in Microsoft products, for example MS Word). I actually would prefer that THE editor supported TCL along with (or even instead of) REXX. 

The best solutions is when you editor scripting language is used as the shell language of your OS, but this is currently achievable only Windows (VBScript/JScript), OS/2 and Amiga (with REXX).  Linux and all other flavors of Unix unfortunately are is worse shape. Still one can try to use TCL as there are editors and Orthodox file managers that are written in this langue and that naturally support it as a macro language.

Anyway the choice is really difficult and I would like to stress it again, that (unless you are a language freak) it's wise to chose and editor that supports a scripting language that you already know and already use in other tasks, if possible.  But often this criteria is imporsible to meet. For example I do not know any decent mid-weight editor that support Perl -- probably the most common scripting language in Unix world.   If we speak about Unix then our choices are essentially limited to BeanShell, TCL and REXX and Lisp

• For people who know REXX (or want to learn -- it's a very easy scripting language to learn) I strongly recommend EOE family of editors (for example Kedit for Windows) -- the single "all" command instantly will instantly raise you to the another level of productivity ;-) And that statement is not just religious propaganda ;-). But again, to benefit from the editor features outside folding ("all" command) you probably need to know REXX, which is not so widely used as TCL in Unix or VBscript in Windows. Due to its VM/CMS( mainframe) origin EOE has somewhat idiosyncratic command set, but you can easily adjust it to your taste.  OS/2 users usually know this type of editor and REXX and do not need any adjustment (IMHO wide usage of REXX both as scripting language and macro language was the most attractive feature of OS/2). But even if you hate REXX, the elegance and power of this family of editors well worth to learn it. Of course, users of Kedit will not have any problems with THE as it supports (limited) Kedit emulation (essentially version 1.0 of Kedit emulation). 

• Lisp is used in Emacs. It's a very idiosyncratic choice is you do not use it for anything else.

• TCL never managed to reach mainstream but still it used in some editors -- Tkedit is probably the best choice, but I it does not support folding.

• BeanShell  is a very attractive choice for Java programmers (and thus JEdit looks very attractive for them). 

• I tend to use Perl for anything relating to text files, such as processing HTML files, converting files from one format to another, etc, but for the editor it looks like Perl can be used only in VIM6 style -- as a piping tool.

Anyway, please use a decent editor for complex editing jobs. Believe me this is really important !  I know some quite gifted programmers/administrators who never managed to learn decent editor with scripting and folding. They are actually depriving themselves of one of the most important tools and artificially make programming and Unix (as well as Windows) administration much more complex than it is. 

Commercial editors like MiltiEdit and Slickedit  are OK, but Multiedit is not-portable and SlickEdit is expensive. Still Slickedit has reasonable folding support.  But its weakest point is support of  rather strange, proprietary scripting languages which bears only a superficial resemblance to C/C++ but have no classes. It uses both typed and untyped variables.. The syntax is, to put it kindly, eclectic, held together with duct tape and bailing wire. The designer has never heard of the concept of orthogonality. Every feature of the language comes with a list of odd exceptional conditions under which it does not work. It is the quirkiest most ad hoc, asymmetrical language I have ever encountered, and probably the hardest to learn. However, the internal pcode it uses is reasonable fast and gets the job done. All the common methods are written in native code for speed. You learn it mainly by studying the existing source code.  Those comments generally are applicable to Multiedit too. Still both SlickEdit and MiltiEdit are pretty powerful editors that have advantages that might outweigh disadvantages, especially in windows environment. 

Note that MS Word (and Word Perfect) are usually classified as document editors. Paradoxically Ms Word is a pretty decent programmable editor (using VBScript or Jscript). One should think about it as a literate programming paradigm tool. I do not know about WordPerfect much but this is probably true about WP too.  

Other useful features that you need to consider include: Context Tagging, Dynamic Difference Editing, FTP Support, a Functions/Class Browser, Dynamic Tagging and a Code Beautifier. 

• Functions/class browser lets you easily see your code hierarchy. the user can transparently view members of the class. You can also define a search filter to help find members and classes quickly. As a special type of outliner Class browser usually allow adding and removing members of a class. 
• Dynamic Tagging - the editor dynamically maintains a database of symbols (i.e. variables, functions, methods, classes, etc.) for your source files and indicates the symbol you are currently editing. Files are automatically re-tagged when they are added to a project, saved or an idle time threshold is reached.

• Powerful outlining system

• Built-in interface to the software configuration management system

• Optional HTML editing mode  

• Built-in source code beautifiers for major languages including C, C++, Java, JavaScript, and HTML. That helps to reformat C, C++, Java, JavaScript he HTML beautifier should allows you to reformat tag/attribute case, indenting and more. It even reformats embedded JavaScript! Actually achievable in a more general contest by Vim buffer piping feature, but Cadillac is Cadillac ;-)

Of course Emacs is a classical example, but it suffers from a rather idiosyncratic scripting language (Lisp)... It is interesting to note that such a great thinker in computer science as Professor Donald Knuth is an XEmacs user. But I actually am not impressed with Emacs/XEmacs. May be that's because of my REXX and Perl background and that fact that Lisp is not a useful language for me outside the editor.  

MS Word is another example from another platform with another idiosyncratic scripting language (VBA). It main advantage that it supports HTML, and has a very powerful outlining capabilities, but again I am not a VBA user ;-). That means that  for me the attractiveness of MS Word as a super-editor is pretty limited. Probably even Word Perfect might be a better bet for a new user (due to better XML support and the same VBA macrolanguage), as probably any powerful XML-based editor (but probably Microsoft bridged the gap did a good job with XML in Word 2002), but I really do not know as I still is mainly an XHTML user ;-). What is really interesting in MS Word is that some programmers successfully used it as a programming editor in Windows environment (and that is a long tradition, actually starting from version 4.0) -- paradoxically it is one of the best implementations of the literate programming paradigm. Ms Word supports automatic construction of index, has powerful outlining and other features that are primary literate programmer instruments.  It's not very difficult to write an extraction of programming module tool to send part of  Word documents to compiler. BTW Thinking in Java was written this way. See my altoffice page for more details. 

The latest MultiEdit 9.0 supports  HTML editing, has (limited) folding capabilities and thus can be considered to be a heavyweight editor. It's an excellent editor -- IMHO for years it was the best implementation of a programmer editor in the DOS environment. But this is Windows only implementation, no Unix ports yet and I do not recommend to use non-portable editors :-(.

Webliography

Nikolai Bezroukov Orthodox Editors

Softpanorama Orthodox Editors Page

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Created May 16, 1996; Last modified: March 12, 2019