|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
|May the source be with you, but remember the KISS principle ;-)|
|News||Orthodox Editors||Recommended Links||Eastern Orthodox editors||Western Orthodox Editors (VIM)|
|Folding||Slicing||Outlining||Ctags||Regex||PC-style light weight Unix/Linux||Light-weight win32 Editors|
|VIM||Slickedit||FTE||MultiEdit||Mcedit -- Midnight Commander’s Editor||Emacs|
|GUI-based programmable||Programmable Word processors||HTML programmable||Html editors||History||Humor||Etc|
The best editors are often those written by programmers who use them themselves and know exactly what they want out of an editor. SlickEdit is a good editor written by the person who really undersood XEDIT and who was behaing an excellent IBM DOS 7 editor. But its macro language, slick-c, is a crappy hacked language, a real mess.
Slickedit website contains several manuals in PDF:
There are several Flash animated walkthroughs with commentary. Watching them is a great way to learn the editor.
A major feature is the integration with the compilers. In a way this editor is biased toward C++ and Java, althouth it supports Python more or less well. If you use Visual C++ then SlickEdit can act as a simple IDE and let you see all the error lines at once after a compiler. Every line with an error has a little red X highlighting it. Move the cursor over the X and you get a list of the errors there. That's quite a time saver.
SlickEdit supports tags. You do not need to use the "Symbols" tab to
search for a tag. If there is a tag symbol at the cursor (for example, a
function name), place your cursor on the tag name and invoke the push_tag
(or f) command (CTRL+PERIOD or "Search", "Go To Definition...").
You can also use the Go To Definition dialog box to go to a specific tag. This dialog box will list all tags which match the prefix you have typed so far. Deselect "Prefix Match" to match tags using a regular expression or a substring search. If you prefer to use the command line, use the f command and use the completion keys (SPACEBAR and '?') to assist you when entering a tag name. For example, if you are tagging the C run-time library, type "f str?" on the Visual SlickEdit command line for a list of tag names starting with "str" (such as strcpy, strcmp, etc.).
The push_tag command sets a bookmark in the file you are currently editing so that you can easily return to your edit position. To go back to the previous edit position, press CTRL+COMMA.
Use the find_proc (or fp) command ("Macro", "Find Slick-C Proc...") to navigate to a Slick-C tag symbol. If you are editing a Visual SlickEdit macro, you can invoke the push_tag command (CTRL+PERIOD) to find the symbol at the cursor. The push_tag command actually calls the find_proc command with the symbol name at the cursor to perform the task. Though most compilers come with a built in IDE, third party tools can make your life easier by providing extra needed functionality. They let you work faster with better editing, powerful macro languages, and better compiler integration.
A major part of SlickEdit is the Slick C Macros. Much of the built in
functionality in SlickEdit such as the Beautify command, is actually done
using Slick C Macros, complete with forms. Macros can be recorded or written
and saved out as
bytecode and the degree of customization, including form design is just
amazing. It is a built in
complete with preprocessor!
This is a very powerful editor, in fact it's more powerful than some IDEs. I think novice developers could be a bit overwhelmed by the many features and the complexity of the Slick C Macro system despite the excellent and detailed help system. That apart, it is fast, powerful and almost limitless in terms of features you can add to it through the macros.
Also included is DiffZilla, a powerful diff utility that renders Windiff obsolete. It includes merge, an invaluable feature when you need to resolve differences between source code files.
December 24, 2003Junkster
I'm an editor junkie. I've used dozens of them. I'm currently using with EditPlus for Windows, but it's still not my perfect editor. These days, it should be easy enough to have a more componetized editor: a simple visual display component, plus ways of shooting text to Perl or Python (or your favorite language) to do fancy grunt work. Instead, text editor authors tend to take a GUI-heavy approach, building everything into one, monolithic application. I have seen two alternatives. One is Emacs. I don't want to get into a flame way about Emacs. I've used it. But it's more a lifestyle than a text editor. And then there's Wily, which is a clone of an editor for Plan9 called ACME. Wily looks interesting, but it is a UNIX-only program--no Windows version. And, okay, someone is going to mention vi. Yes, I've used vi. I've written tens of thousands of lines of code with vi. But in the end both vi and Emacs strike me as editors from another era. The cleanliness that comes from an editor like EditPlus or BBEdit (a Mac editor), is something I don't want to lose.
Extreme programmability is important for several reasons. The first is that it offers up a lot of options, letting you do things that the author hadn't thought of. For example, I often use non-mainstream programming languages that would benefit from being syntax colored in non-standard ways (certain types of lines colors a specific way, rather than just keywords). I'd also like to be able to extend an editor to context-sensitive tab completion; build custom, interactive project management systems, etc. All of this stuff is business as usual in Emacs. But Emacs is a relic of the past otherwise.
Text munging is easy. We have entire programming languages devoted to it. An editor just needs to be a thin interface with hooks to routines written in such a language. It shouldn't be a monlithic application. I'm surprised that no one has followed this road, other than Stallman's Emacs.
Visual slickedit is a good alternative. But slick-c is a crappy hacked scripting language. I have written dozen of functions to do things that I want similiar in emacs and vim, but slick-c just can't live up with any other scripting languages that I have used (lisp, perl, python, js).
And the source code that came with vslick are not horrible mess. Good luck trying to learn and understand those source code - it's like I haven't had enough reading my peer's code...
Just my $0.02
And the source code that came with vslick are JUST horrible mess.
BTW, the API provided by slick-c is very inconsistent (I'm not saying elisp is WAY better, but at least it's still managable...)
christopher baus (www.baus.net) Wednesday,
I used to be a emacs bigot, but I'm over it. I still write code nearly every day in Emacs on Unix, and VC++ on Windows, but having seen a demonstration of XCode, I've decided to move my Unix development over to the Mac.
What I think is interesting is that emacs it is completely unique approach to application development, and it worth learning just for the alternative look at software applications. I has certainly influenced Gosling's (who used to work on emacs), NeWS and Java -- not to mention autocad which orginally had a lisp based scripting language. Lisp had a VM and garbage collection a million years ago.
Emacs is powerful enough that it is still useful 25+ years after it was orginally written. But I'm not a student anymore, and I don't have time to endlessly tune my .emacs and custom makefiles. Plus I've grown so used to modern IDEs that emacs + gud is painful.
What I think might be interesting is a editor or platform built with emacs as the model, but assuming a modern windowing environment. Maybe we have it in .NET, but it doesn't seem quite the same.
Yes, I've used UltraEdit. It's essentially the same as EditPad Pro and EditPlus. But they're all very closed systems (in the extensibility sense, not the open source sense). An editor can just be shell and use Perl, for example, to do the real grunt work.
I have also tried vim, which I consider to vi plus some much needed extensions. It still comes across as dated and clunky under Windows. The interface in a typical Windows editor is so invisible compared to vim and Emacs.
Phillip J. Eby
jEdit. It's scriptable with Jython and BeanShell. It has syntax highlighting for a bazillion languages, and it has a flurry of plugins available for every imaginable want or need. I use the XML plugin, the LaTeX plugin, the project management plugin, and there are many many many more available out there. It's hugely configurable, lots of GUI options. Extremely extensible, cross platform, and of course it's FLOSS.
It's written in Java, and startup takes a while on older machnes; 20-30 seconds on an old 400Mhz machine. My newer machines start it in 10 or 15. But I've never had any performance issues once it's loaded, even on slower machines.
Oh yeah, the syntax highlighting also configures lots of nifty features like autoindenting, block comment, bracket matching (tag matching in XML mode), code folding, and suchlike features. It's a *very* complete programmer's editor, and should not be confused with Eclipse (which is a generic IDE/tool platform with some editing capabilities, and whose plugins are heavily slanted towards Java development).
Oops, forgot to include the URL: http://www.jedit.org/
Interesting that nobody mentioned Multi-Edit. http://www.multiedit.com/
Their kernel is Delphi, then everything else is built using CMAC, their scripting language. Their community is very active, and a new version was just released.
I just played a bit with jEdit on my WinXP notebook. Can someone please explain to me why the font rendering sucks like a typical Java application? No AA. My XEmacs looks nice on Win XP. It's also a bit embarrassing that you have to reload the entire app to change the text font. (XEmacs is a fork of Emacs, not the X11 version)
There seems to be no viable alternative to Emacs or Vim...
jEdit does offer anti-aliasing of text, and you enable it via Utilities -> Global options... -> Text Area. Choose Smooth text and Fractional font metrics (depending upon system spec.).
jEdit is an excellent modern editor. Emacs suffers from massive complexity -- there's so much to remember. The modal design of vi/m is just weird.
I have JEdit installed, and it's not bad at all. JEdit had the same plugins as Eclipse, and more. But I don't feel "at home" with it. Like Junkster, I use mostly EditPlus. As Junkster probably knows, you can do a lot with EditPlus, though it's not extensible in the usual sense. At home, I also use ConText, which is similar to EditPlus, just a little less powerful.
I also use Multi-Edit and have ever since its DOS days. ME is a great value ($80-$120 or so depending on upgrade or new purchase) since it includes features like file differencing and a generalized compiler interface to act as a sort of self contained IDE to host command line tools.
The only drawback I've ever seen to ME is that you have to customize its key command mappings quite a bit in order to get reasonable behavior (ctrl-F for search, F3 for search again, Ctrl-F4 for close window, etc). ME has very strange notions about common shortcuts. And I have not found a way to make these definitions portable to a new system. (Or, I just don't know the MultiEdit configuration system as well as I "should".) So every time I move ME to a new PC I have to spend about 1/2 hour re-customizing it.
Only you can calculate a true return on investment for your work patterns. However, it's easy to show that you don't have to save much time to quickly make up for a $300 purchase. Assume an annual salary of $60,000, which is a conservative value for the average salary paid to programmers in the USA. Assuming a normal work year of 236 days and a normal work day of 8 hours, you have to save 1.6 minutes per day [i] to pay for SlickEdit in the first year of purchase. Here are some of the ways SlickEdit can help you save 1.6 minutes per day:
- It takes 30 seconds for Eclipse™ or Microsoft® Visual Studio® to open on my machine. The same project in SlickEdit opens in a second or two. So SlickEdit can save you that much time if you open your environment at least 3 times per day.
- Our tagging engine allows you to instantly jump from a symbol to its definition with a single keystroke (Ctrl+Dot). In most editors, you have to either know the file and where it is stored or search for it. Then you have to scroll down or search for the function name. This process can easily take 30 seconds to a minute. So a couple of quick navigations per day will pay for SlickEdit. By the way, we also have a Symbol View that will preview the definition of the current symbol without having to open the file!
- We have many features that cut down on the number of characters you have to type, like Syntax Expansion, which automatically completes block statements like if and for. Surround With quickly wraps the selected lines in a block statement. In a normal coding session, these will easily save you a couple minutes.
- Code Templates automate the process of creating new classes or patterns. Powerful substitutions are run when a template is instantiated, easily saving you a minute or two on a simple class and several minutes on multi-file templates.
- DIFFzilla®, our dynamic differencing tool allows you to compare files and edit them in the diff view, providing many of the same editing capabilities in our editor window. This saves wasted time re-running a diff after making changes.
Posted by Dennis B under Code EditorsA programmer's editor is a text editor with features fine tuned for writing code. In this article we will explore the top 10 essential features of a programmer's editor and how each one saves you time and energy.
* Color coding
* Syntax expansion
* Code navigation features
* List-members and function parameter information
* Comment and function documentation extraction
* Syntax-driven auto-indentation
* Macro recording and playback
* Code snippets and other shortcuts
* Integrated project build support
* Multiple file and window support
Color coding is a language specific feature which allows the editor to display comments, keywords, strings, numbers, and other lexical elements using specific foreground and background colors as well as potentially using bold or italic fonts.
"I don't need my editor to look like Walt Disney lost his lunch." - How do you find your car in a parking lot? Do you look at every car until you find your 1998 Camry with velvet blue interior, or do you look for a red sedan with a "My border collie is smarter than your honor student" bumper sticker. Color stands out; it helps you find things. You have a color monitor, why waste the potential?
Color coding helps you distinguish comments from code. If that were all it did, that would be a great win, but it can do so much more. Color coding also helps you see immediately when you have mistyped a keyword, or if you have accidentally used a keyword as an identifier, or failed to terminate a string. This saves you many compile and edit cycles and lets you focus on what's important.
There is very little investment to this feature; if anything, you may find yourself un-training your eyes because you do not have to read as much syntax to see comments vs. strings vs. code.
This feature completes statements for you so you only have to type the leading keyword such as "if" or "while" and the editor will insert the rest of the code for that statement in accordance with your brace style and indentation preferences.
"I've been coding for years; I type these statements without even thinking." - This is true for many seasoned programmers, but the real question is why?
For novice programmers, syntax expansion can save them time trying to remember how a particular statement is written. This is especially true for statement heavy languages such as COBOL. For all programmers, syntax expansion helps enforce coding consistency; it will always use your brace style and your indention preferences.
In fact, the investment to start using syntax expansion is just a matter of un-training your fingers to type the whole statement. Very quickly, you will get used to just typing "while" and then being ready to put in the loop condition.
Syntax driven auto-indentation
Auto-indentation will position your cursor at the expected indentation level when you split or open a new line so that you can start typing code immediately. A good implementation of auto-indentation will respect your tab preferences and either insert real tabs, spaces, or position the cursor on a virtual column without inserting unnecessary space. A very good implementation will handle more than just simple block scopes: it will also handle continuation indents, parameter lists, initialization lists, and splitting comments.
"I am very particular about indentation; I don't trust the editor to do it for me." - This is the sort of feature that must be configured to match your preferences. Once you configure it correctly, the editor will do the right thing more than 90% of the time. If it doesn't, you are probably using the wrong editor, or in the worst case, can turn the feature off.
Auto-indentation will save you time for every line of code you write. Furthermore, it will improve the consistency of your code.
This feature requires no time to learn, but you may have to un-train your fingers to not lean on the space key every time after you hit enter.
A good implementation of code navigation turns your code into a hypertext. For any symbol in your code, you can jump to it's declaration or definition in one keystroke. You can jump back to where you were in another keystroke.
"I don't need this; I've memorized where everything is." - That's very impressive; let me know how that works out when you inherit a half-million lines of code you have never seen before.
A really good code navigation system makes file boundaries irrelevant, which make it possible for you to focus on the code, not what files the code is stored in. A good implementation does not just use the symbol's name, but finds the symbol's declaration or definition using the same language specific scoping rules that your compiler uses. A better implementation can also find all references to a symbol. An awesome implementation recognizes that when you navigate to a symbol and then pop back, it can close the file in order not to pollute your working set of open files.
In terms of keyboard shortcuts, you need to learn three things: (a) the key to jump to the symbol under the cursor, (b) the key to see all references to the symbol under the cursor, and (c) the key to jump back. If you have not been using code navigation, you are probably finding symbols by manually opening files and poking around, or using grep or another multi-file search to find symbols. In terms of work habits, you may have to train yourself that there is an easier way to do things and use it.
List members and function parameter information
List members (referred to as Intellisense™ by Microsoft) will display a list of class members in the class when you type a member access operator such as "." or "->" in C++. You can then pick one of the items from the list and the editor will insert it, or you can continue typing the name of the symbol and the list will be filtered down to include only symbols that match what you have typed.
Function parameter information is typically activated when you type the open parenthesis for a function call and will display the prototype for the function being called and highlight the current argument.
"Those things will just get in my way." - A well designed implementation of list members and function parameter information will not get in your way. List members is typically displayed below the current line, left aligned to the cursor position. Function parameter information is typically displayed below the current line, aligned with the function name. The windows typically have minimal borders and are shrunk down to the minimal size to display the required information. A good implementation works hard to stay out of your way when coding.
If you do not have list members, you will need to be very good at remembering the names of the members of the classes and structures that you use. Suppose you need to convert a STL string to a character pointer. You may remember that it is done using the "c_str()" method. You may have an STL reference manual on your desk and can spend five minutes looking it up. If you have list members, you type "." and then scan through the list and see that "c_str()" returns "const char*" and remember that is the conversion function.
Likewise, function parameter information brings vital information to you when you need it. Suppose you need to call the standard C library function strncpy(), but you can not remember the order of the arguments. You could look it up in your C book, check MSDN or the man page. That's fine if you have five minutes to burn. If you have parameter information, the prototype is displayed for you: "char* strncpy(char *, const char *, size_t)", and you can see immediately that the first argument is the destination (by virtue of being char*), and the second argument is the source string, and the third argument is the max number of chars to copy.
Typically, these features are invoked automatically when you type open parenthesis or member access operators. You will also want to learn two keyboard shortcuts: one to bring up list members manually and one to bring up function help manually. This will be extremely valuable to you when you are editing established code.
Comment and documentation extraction
Comment and documentation extraction pulls documentation comments from your source code and displays them in conjunction with list members and function parameter information. Really good implementations of this feature will format JavaDoc and XMLdoc comments for you, and highlight function parameter documentation when displaying function parameter information.
"What will I do with all these Java reference manuals?" - Build a giant pyramid in your cubical and declare yourself a Java deity.
If your editor does not have this feature then when you need to see the documentation for a function, you either need to look it up in a reference manual, or jump to that function, read it, remember it, and then jump back to where you were working. Having this feature is like having a really good research assistant who brings exactly what you need directly to you exactly when you need it.
Another nice side-effect of having this feature is that it genuinely encourages you and your whole team to write better documentation comments in your code because you will be seeing them and using them on a regular basis.
This feature is typically completely automated.
Macro recording and playback
This facility allows you to record a sequence of keystrokes and/or editor commands and then play them back later.
"You're hurting my head!" - No, your head will be fine, and your fingers will also appreciate the break once you master this feature.
Sometimes you need to make a bunch of very similar changes to code. Macro recording allows you to do it once and repeat the macro instead of tediously doing the same thing over and over again. More powerful editors allow you not only to record macros, but to name them and save them for later. Some even more powerful editors allows you to record not just one, but a suite of macros that you can repeat with a single keystroke.
There are, at a minimum, two keyboard shortcuts you need to learn: one to toggle macro recording on and off, and one to repeat the last recorded macro.
Code snippets and other shortcuts
This feature allows you to define chunks of text that can be expanded using a keyboard shortcut.
"I just copy and paste when I need to create idiomatic code." - The problem with this technique is that, first, it is slow and tedious. Second, it requires you to remember where you can find an example to copy. Third, when you copy and paste chunks of code, you might be copying and pasting chunks of code with errors in it.
This feature helps you build a library of snippets of idiomatic code that you can expand at the touch of a key. To add further power, most editors support parameterized code snippets so you can plug in different variable names, constant values, etc.
In addition, some editors also let you define global shortcuts and use them nearly anywhere in the editor, including the open file dialog. Why type "/usr/include/sys/" or fiddle around with the mouse to navigate to that directory if you could just have an alias named "sys", expand it, and continue from there?
You need to learn how to create and customize a snippet in your editor, and you need to learn one keyboard shortcut for expanding snippets.
Integrated project build support
This feature allows you to invoke a compile or a project build from your editor, and correlate the compilation errors with source code.
"We have a custom build system and we can not change it." - In most cases, you do not have to change your build environment; you just have to be able to tell your editor to use your existing build command to build the project.
The first benefit is that you will not have to leave your editor to start a build. You can associate the project build with a keyboard shortcut, such as Control-M (for make). You no longer have to remember the build commands for different, disparate projects. Last, and definitely not least, you can navigate directly to the compilation errors with a single keystroke instead of manually locating the offending file, opening it, jumping to the line number, and then repeating that process for every error.
You will need to learn the project system of your new editor; how to create a project, how to specify your build command. You will also need to learn the keyboard shortcut for navigating to the next build error.
Multiple file and window support
This is really two facilities. One is the ability to open more than one file at a time in your editor and rapidly switch between them. The other is to be able to open multiple windows so that you can look at different files or different parts of the same file at the same time.
In particular, I address this issue for the programmers out there who are still using text mode vi on Unix or notepad on Windows. Noting those exceptions, almost all other modern editors have these capabilities to varying extents. Some support multiple files and windows, but force you to use the mouse to switch buffers or switch windows. Some editors have a tabbed view for quickly seeing what files you have open and modified. Some editors have support for buffer management, so if you navigate to a file and then pop back (see Code navigation, above) the file is automatically closed, keeping your working set of files small and tidy.
"Too much clutter" - Some people like to keep things simple, so viewing just one file at a time is great for them, they don't need side-by-side windows all the time. But, for those times when you absolutely need it, this is a feature that is well worth having available.
Modern projects are large and encompass many source files, sometimes tens of thousands. You can seldom get a complete understanding of a system looking at just one file at a time. Being able to switch between files with a single keyboard shortcut is more efficient than starting a new editor to view another file. If you have unsaved changes to a file and need to look at another file, what do you do if your editor does not support multiple files?
You need to learn a few keyboard shortcuts: (a) to open a file; (b) to cycle through your open files; (c) to split windows horizontally and vertically; (d) to cycle through your open windows; and (e) minimizing and maximizing windows. The first two will get you up and running so that you can maintain a working set of open files. The last three will help you move to the next level.
It's natural to resist change. Learning a new editor requires an investment of time and a change of work habits. You will seldom regain your investment in the timeframe of your first project with a new editor. But the time you will save in the long run will quickly eclipse the small amount of time you invest. Perhaps you feel that you are extremely proficient with your current editor, maybe even working at power programmer level. This may trick you into thinking that you are already working at peak productivity and will not benefit from a better programmer's editor. The truth is exactly the opposite, you will benefit even more. Your tools are your foundation. Think of this analogy. No matter how proficient you are at riding a bicycle; you can go further faster on a motorcycle.
The features outlined in this article are things that I have grown to view as essential for writing code proficiently. It can be hard to appreciate exactly how much they help you until you seriously set down to work with these tools in your hands. After which, I can assure you that you will ask yourself how you ever managed to work without them.
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: September 12, 2017