The History of JavaScript

Here is a version timeline of JavaScript

JavaScript was developed in 1995 by Brendan Eich at Netscape, now a division of AOL. initial name was Lifescript and it was changes to JavaScript for marketing reasons. JavaScript was based on Self, a prototype-based object-oriented language developed by Sun.

As a language JavaScript belongs has nothing to do with Java. It is a scripting language like Perl, TCL, Python, etc. See also  NetscapeWorld - JavaScript 1.2's evolution as explained by its creator - May 1997. Here is his own version of events that led to the creation of JavaScript:

I came to Netscape in April 1995, after seven years at Silicon Graphics and three years at MicroUnity Systems Engineering. Netscape was about a year old then and was looking for someone to work on a scripting language or some kind of language inside the browser that could be used to automate parts of a web page or make a web page more dynamic. Java had been around for five years at First Person and Sun, and had been retooled for the web in late 1994. Netscape was the first Java licensee, so the issue became: Can we do just Java, or do we need another language?

There were people who argued strongly that Java's fine for programmers who build components, but there's a much larger audience of people who write scripts or maybe copy a script from somebody else and tweak it. These people are less specialized and may be paid to do something other than programming, like administer a network, and they write scripts part-time or on the side. If they're writing small pieces of code, they just want to get their code done with the minimal amount of fuss. Finally, we agreed that this new language should look like Java, but be a scripting language.

Like all languages, it borrowed from others. LiveScript was the official name it was given when it first shipped in beta releases of Netscape Navigator 2.0 in September 1995, but we rechristened it JavaScript in a joint announcement with Sun on December 4, 1995.

JavaScript attracted a lot of developer attention, because what people wanted back then (and still want) is the ability to go one step beyond HTML and add a little bit of code that makes a web page dynamic - that makes things move, respond to user input, or change color; that makes new windows pop up; or that raises a dialog box to ask a question, with an answer necessary to proceed - things that HTML cannot express. That's really where you need a programming language, but something simpler than Java or C++.

Content creation should not be recondite. It should not be this bizarre arcana that only experts and gold-plated computer science gurus can do. There are economic advantages to lowering the entry costs in creating web content and in sharing it or aggregating it, like Netscape is doing in Web Building.

Calling JavaScript "the glue that holds web pages together" is short and easy to use, but doesn't do justice to what's going on. Glue sets and hardens, but JavaScript is more dynamic than glue. It can create a reaction and make things keep going, like a catalyst.

While in development, JavaScript had been known as LiveWire then LiveScript. Its core script syntax closely resembled Java, so it was renamed JavaScript when it was released. The way it referenced forms, links and anchors as children of the document object, and inputs as children of their parent form became known as the DOM level 0. Netscape 2 was released in early 1996 with JavaScript support.

The same year, Netscape passed their JavaScript language to the European Computer Manufacturers Association (ECMA) for standardisation. The ECMA produced the ECMAscript standard, which embodied the JavaScript core syntax, but did not specify all aspects of the DOM level 0. With the release of Netscape 3 later in the same year, Netscape had produced JavaScript 1.1, which could also change the location of images, bringing on a wave of web sites that used this most popular of web page effects, making images change when the mouse passed over them. The images were also referenced as children of the document object and thus the DOM level 0 was completed.

ECMAscript was still updated, as with the release of Netscape 4 in 1997, Netscape produced their most advanced technology to date, DHTML. Using a combination of yet more proprietary HTML tags and portions of the new W3C CSS 1 recomendation, JavaScript 1.2 gave programmers the ability to change the CSS style for document components, in particular the position and visibility of elements on the page, which were adopted by the W3C for their CSS 2 specification. This layers technology was greatly accepted, although little used because of its lack of support for older, and still popular browsers. JavaScript now offered the {} and [] syntaxes for creating objects and arrays (WebTV to version 2.6 does not support {}) but more importantly, the Layers DOM was born.

As layers became more popular, Microsoft decided to muscle in on the competition, releasing their Internet Explorer 4 browser in 1997. This browser showed programmers just how agile a browser could be. Unlike the Layers DOM model, the proprietary DOM model of IE 4 allowed any part of the document to be referenced, and have any CSS style changed, including many CSS 2 declarations. Most could have their contents rewritten. It also offered many other extensions, such as filters and transitions. This new syntax for referencing document components was more reliable and far more versitile and the W3C decided to adopt many of its syntaxes and components for their forthcoming DOM recommendation.

In mid 1998, Netscape released a new version of their browser, still relying on the poor layers DOM. They had failed to fix many of the bugs that plagued their browser, despite the new JavaScript 1.3 version. They also released the source code, and stopped charging for their browser. They had hoped to produce the next version of their browser using the open source community. The open source community had more sense, and decided instead to abandon the unstable and restricted Netscape core, in favour of completely re-writing, according to the W3C DOM guidelines.

In 1999, Microsoft released the most advanced browser so far, Internet Explorer 5, the first fifth generation browser, which supported most of the W3C DOM 1 recommendation, as well as the properietary techniques used by Internet Explorer 4. It also supported what is the current version of ECMAscript, ECMAscript 3, equivalent to JavaScript 1.5 (JavaScript 1.4 was used only by Netscape's server side JavaScript). As with all Internet Explorer versions, it still used a JavaScript version with several core extensions, known as Jscript.

The W3C DOM allowed much greater functionality than the previous DOMs. It gave ways to create, remove and modify html elements, even after the page had loaded. All aspects of the page could be changed. Attributes could be added and removed from HTML elements. All styles could be changed, added or removed. It even changed the way that events could be detected, allowing more than one handler function for any event, capturing and bubbling were both supported. Internet Explorer still does not support all of these event techniques according to the standard, and instead uses proprietary variations. The W3C DOM also represented the document differently, as a tree structure where the root was the HTML element, and each element within it was a child object of the element it was contained within. Text within elements was a child node of the parent element node. This gave a much more complex but realistic representation of the document, that gave access to every part of it.

In 2000 Opera released their Opera 4 browser, one of the most badly bugged to date. Its script handling was based on the W3C DOM, although it only implemented enough to be comparable to Intenet Explorer 4. However, its bugs usually caused it to fail to manage even that. With the subsequent Opera 5 and 6 releases, the functionality did not increase, but the stability and popularity definitely did. At about the same time, several other browser projects came to light, such as Konqueror, and ICEbrowser, both of which were fifth generation. Television browsers were also becoming fifth generation.

In 2002, the Mozilla project finally released Mozilla, based on their open source Gecko rendering engine and SpiderMonkey JavaScript engine. This was the open source project started in 1998 by Netscape, and at last, it had paid off. We were given one of the most flexible browsers ever, which, by following the W3C's DOM recommedations, had given web programmers the ability to do anything they wanted. Alongside that, the Mozilla project had also adapted the java based Rhino JavaScript engine created by Norris Boyd of the Netscape corporation, which is what had been used by ICEsoft Technologies together with their ICE Storm architecture to produce ICEbrowser.

The largest market share was still held by Microsoft, as they released the sixth version of their browser. In reality, this browser was more hype than anything. Its CSS support was still far less than the Gecko engine, and by making subtle changes to its Jscript, Microsoft succeeded in causing web developers more problems than before. Dispite this setback, the world was finally heading towards a centrally recognised standard, the W3C DOM. The W3C are now on their third DOM recommendation, which is partially supported by Konqueror and Mozilla.

Thankfully, because of the portability of the Gecko rendering engine, Mozilla's popularity is increasing, and already the Gecko engine is used by nearly thirty different browsers, including Netscape 6+. With any luck, Microsoft may follow ... It is the hope of most web developers that all browsers will, at some point, use the same syntax for JavaScript. The W3C DOM may at last help that to happen. If all browser manufacturers produced browsers that operated along the guidelines set out by the W3C, the makers of the World Wide Web itself, web development might actually become easy, while still being flexible enough to create inspiring and exciting web pages. As all browsers would behave the same way, web developers would not have to waste so much time, energy and money on solving all of the many browsr incompatibilities.

With the release of Opera 7, all major browsers have now become fifth generation. Even Escape now has basic DOM functionality. The only exception now is iCab, although the currently closed 3 beta may already be fifth generation. Apple have also released a major browser, Safari, based on the Konqueror libraries, improving it for even better support of the W3C standards. The release of OmniWeb 4.5 also brings yet another minor browser into the collective of fifth generation browsers, using the same rendering and JavaScript core as Safari. The world of browsers is changing, but fortunately, they are all moving in the same direction. In a few years time, it may become acceptable to abandon the old proprietary technologies, and embrace a global, flexible standard.

SpiderMonkey is not the only JavaScript engine that Mozilla have produced. The now defunct codename Xena project, sometimes called Javagator, attempted to create a 100% Java version of the Mozilla browser. Xena produced a couple of interesting subprojects including a newsreader Grendel and a fully equipped Java based JavaScript engine called Rhino. Rhino would be a particularly good choice for any XML handling application because it now includes the power of E4X which makes XML programming very easy. Rhino is very easily embedded in  Java applications.

JavaScript name terminology

These names are subject to interpretation by the browser developers. For example, browsers may support what they call JavaScript1.5, but not even support DHTML. This makes the JavaScript version unreliable, DON'T RELY ON IT!

ECMAscript

The core syntax for JavaScript, defining control stuctures, intrinsic objects and variable types, operators etc.

DOM level 0

Says how to refer to forms, inputs, images, links and anchors as children of the document object

Layers DOM

Says how to refer to positioned elements (layers) and modify their style as children of the document object with nested references

Proprietary DOM

Says how to refer to elements and modify their style using the all collection of the document or parent object and the style child object of the element

W3C DOM

Says how to refer to elements and modify their style using various getElementBy... methods of the document or parent object and the style child object of the element. Also says how to represent all document elements as a tree structure. Also allows elements to be created, modified or deleted even after the document has loaded

LiveWire

An early name for JavaScript - not recognised by most browsers - now used as the name of Netscape's server side JavaScript

LiveScript

An early name for JavaScript - recognised by most browsers

JavaScript

A collective name for all versions of JavaScript

JavaScript1.0

The first version of JavaScript to be released
Early ECMAscript + DOM level 0 without images

JavaScript1.1

Early ECMAscript + DOM level 0

JavaScript1.2

ECMAscript + DOM level 0 + layers or proprietary DOM

JavaScript1.3

More advanced ECMAscript + DOM level 0 + layers or proprietary DOM

JavaScript1.4

Server side JavaScript

JavaScript1.5

Even more advanced ECMAscript + DOM level 0 + W3C DOM

Jscript

Microsoft's JavaScript variations with extended core features

Active scripting

Microsoft's user friendly way of saying 'Jscript'

JellyScript

WebTV's interpretation of JavaScript

InScript

iCab's interpretation of JavaScript

News

 O'Reilly Network JavaScript How Did We Get Here

JavaScript. Spawned in 1995 by the need to make Netscape Navigator's newly added support for Java applets more accessible to non-Java programmers and web designers, a powerful scripting language too often described as "simple."

Plagued in its early days by security flaws, crippled by a lack of powerful development tools such as integrated development environments, debuggers, and meaningful error messages, extended to contexts that range far beyond the initial intent of its designers, and saddled with the legacy of incompatible browser object models, JavaScript has suffered for years at the hands of those who would criticize it for being too unlike Java, or too much like Perl, or too often used by well-meaning but otherwise ignorant web designers, shoehorned into pages without thought of future compatibility, intelligent abstraction, or code reuse.

Yet it is by far the most popular language on the Web, the foundation for the next generation of dynamic client-side Web applications, a solid core with amazing potential and power. So why don't more programmers view JavaScript as an essential part of their toolbox? Let's look at the history of JavaScript (née LiveScript) and take a good, hard look at where it came from -- and where it is going.

Back to the early days of the web

Rewind to early 1995. Netscape had just hired Brendan Eich away from MicroUnity Systems Engineering, to take charge of the design and implementation of a new language. Tasked with making Navigator's newly added Java support more accessible to non-Java programmers, Eich eventually decided that a loosely-typed scripting language suited the environment and audience, namely the few thousand web designers and developers who needed to be able to tie into page elements (such as forms, or frames, or images) without a bytecode compiler or knowledge of object-oriented software design.

Related Reading JavaScript: The Definitive Guide, 4th Edition By David Flanagan Table of Contents Index Sample Chapter Full Description

The language he created was christened "LiveScript," to reflect its dynamic nature, but was quickly (before the end of the Navigator 2.0 beta cycle) renamed JavaScript, a mistake driven by marketing that would plague web designers for years to come, as they confused the two incessantly on mailing lists and on Usenet. Netscape and Sun jointly announced the new language on December 4, 1995, calling it a "complement" to both HTML and Java.

JavaScript quickly took on a life of its own, more commonly used to manipulate images and document contents than to control Java applets, perhaps reflecting the then-current trend (driven by typographer David Siegel and others) to bring full interactivity and sophisticated user interface and typography concepts to the formerly static Web. It is telling that a vast majority of the scripts used in the first couple of years simply swapped one image for another in response to user-generated mouse events.

The astonishing success of JavaScript as a programming language with a low barrier to entry (no compiler needed, scripts could be copied and pasted into existing HTML pages with little to no editing, seemed tightly bound to the browser) led many experienced programmers to write it off as a toy. Early conflicts between JavaScript's power and the relatively under-powered rendering engine caused early UI experiments such as dynamic, client-side tree widgets and the like to flash annoyingly on the screen.

Disdain for a language that apparently required no skill to use, lacked an IDE and a reliable cross-platform debugger, and could only be tested in the context of the actual browser in which the page will be viewed, combined with a few highly publicized security flaws and several books aimed at non-programmers, caused many to write off JavaScript as a "simple" language for beginners and overshadowed its amazing potential.

Subsequent releases of Navigator included support for script-driven interaction with plugins, a better, more rigorous security model, and more. Netscape's LiveWire introduced JavaScript as a server-side language capable of performing database queries and other advanced features. However, the server-side scripting never achieved the popularity of ASP or Perl or Cold Fusion, and was mostly neglected by all but Netscape's server customers. JavaScript's destiny was to be the way document authors control and extend the capabilities of the client.

Microsoft's response to JavaScript

Microsoft responded to JavaScript in part by releasing its own VBScript language (itself capable of hooking into embedded components, although initially limited to the platform, Windows, where those components were first implemented). In addition, they released a port of JavaScript called "JScript," on July 16, 1996. Internet Explorer 3.0, otherwise an amazing technical accomplishment from the standpoint of support for new W3C-sanctioned standards like Cascading Stylesheets, was one revision behind Navigator's JavaScript -- which by then allowed for the wildly popular image swapping -- and would remain behind until the release of version 3.02.

Many designers simply checked for Navigator in their scripts and ignored IE as a lost cause, just as early CGI programmers checked for "Mozilla" in the user agent environment variable, leading to the ridiculous convention, still followed today, whereby practically all of the major browsers announce themselves as "Mozilla" first, then "(compatible; BrowserName)" second. In short, JavaScript took on a not-entirely-deserved reputation for being yet another roadblock to a truly cross-platform standards-driven Web.

ECMAScript: an attempt at standardization

The introduction of IE3 and its unfortunate lack of support for the document.images array led Netscape and Sun to standardize the language with help from the European Computer Manufacturers Association (ECMA), giving us yet another name for what had by now become a strange hybrid of powerful and universally supported core functionality and often incompatible object models: ECMAScript. Standardization was begun in conjunction with ECMA in November 1996 and adopted in June 1997 by ECMA and by ISO in April 1998.

In the meantime, as ECMAScript was being standardized (but unfortunately neglecting everything but the core language), Netscape and Microsoft introduced the 4.0 browser generation, each browser with its own completely proprietary document object model, and "Dynamic HTML" became the next morass into which JavaScript's good heart was dragged.

Fiefdoms of functionality

The nightmarish workarounds and multiple implementations necessary in order to provide cross-browser DHTML applications are legion. Some folks provided libraries that made Navigator act as much like IE as possible. Others provided libraries that made IE act as much like Navigator as possible. Everyone provided libraries that helped programmers wrap incompatible code with a consistent API, but soon found that the lowest common denominator required for truly cross-platform code was a bit too low for all but the most basic applications, and so many deserted Navigator entirely for IE on Windows, further fragmenting the Web into little fiefdoms of functionality.

While the browser wars were raging, Microsoft, Netscape, and dozens of other companies worked with the W3C to try to lay the groundwork for a truly universal Document Object Model (DOM), while staying as backwards compatible as possible with the original browser object model (referred to as "Level 0" by the framers of the W3C DOM). The desire to get the Web back on track as an SGML-inspired platform, where document structure encodes semantics but not presentation, fueled by the relative simplicity and power of XML, led to another layer of abstraction and several years of incompatible or partial implementations.

The open source Mozilla project took years without a stable or widely distributed public release, while Microsoft tightened its hold on the browser market share. DHTML programmers retrenched, for the most part, in response to the complexity of cross-browser DHTML, a new emphasis on standards support, and the rise of other tools for providing interactive content, such as Flash.

Where does this leave us today?

Fast forward to 2001. JavaScript's dependence on context-specific object models is both the core of its strength and the fatal flaw in its implementation. Unlike Perl or Java or other languages, JavaScript's capabilities can't be extended or overridden by developers, who are instead utterly dependent on the caprice of the browser vendors. JavaScript is flexible enough to overcome many weaknesses, but not enough to overcome fundamental, context-enslaved object model incompatibilities.

Also, the inability to hide source continues to be an obstacle to the development of applications whose code the owners wish to protect as their intellectual property. Continuing lack of an IDE, debugger, and other standard development tools are still considered insurmountable problems by many programmers, who defend their Windows-only applications with the not unreasonable excuse that debugging is too hard on a platform that lacks a debugger. The WYSIWYG tools vendors caught up with some excellent cross-browser JavaScript libraries integrated into their page building tools, only to be caught out by Mozilla's abandonment of the old Netscape document.layers object model.

And yet, JavaScript has evolved into an incredibly powerful mélange of the best features of Perl (associative arrays, loosely typed variables, regular expressions), C/C++ and Java (clean, block-parsed syntax, objects and classes, highly evolved date, math, and string libraries), and TCL (widely ported application control environment), to name a few, with all the power of the W3C DOM in the latest browsers (Mozilla, Netscape 6, IE6/Windows and IE5/Mac).

Companies such as Blox, KnowNow, and others are using client-side JavaScript in combination with intelligent server-side tools to deliver the next generation of Web-based applications. Even Microsoft, with all the ballyhoo about C#, seems to have recognized the power of JavaScript: Pick any MSDN sample application or one-off script, and odds are it's written at least partly in JavaScript.

Java has suffered at the hands of internecine and highly publicized feuds between Sun and, well, pretty much everyone. VBScript is being abandoned by Microsoft, but the compiled C# can't be expected to fill the ever-needed role of scripting language. JavaScript has conquered the Web. So why don't you know more about it? What is there to know? How should you begin to address your long-standing neglect of this powerful and mature language? We'll address these issues and more in our next article.

Steve Champeon is a recognized developer, author, and editor specializing in Web technologies. At his "day job," he serves as the CTO of hesketh.com, a Web services firm in Raleigh, NC.

 

Recommended Links

Softpanorama Recommended

Top articles

Sites

JavaScript 2.0

JavaScript 2.0 is an experimental proposal maintained by waldemar for future changes in the JavaScript language. The eventual language may differ significantly from this proposal, but the goal is to move in the directions indicated here and do so via a coordinated plan rather than adding miscellaneous features ad hoc on a release-by-release basis.

JavaScript is Netscape's implementation of the ECMAScript standard. The development of JavaScript 2.0 is heavily coordinated with the ECMA TC39 working group. JavaScript closely matches the ECMAScript Edition 4 standard under development. The intent is to make JavaScript 2.0 and ECMAScript Edition 4 be the same language, but JavaScript 2.0 will also include a few features for which more feedback and experience is appropriate before standardizing them.

Web Workshop - What's New in Windows Script 5.5

[Apr 5, 2000] Netscape Announces Availability of Javascript 1.5 in New Netscape 6 Browser

MOUNTAIN VIEW, CA, -- Netscape Communications, a subsidiary of America Online, Inc. (NYSE: AOL), today announced the availability of JavaScript 1.5, the latest version of its industry-leading scripting language. Netscape™ 6 Preview Release 1, available for free public download today, features full support for JavaScript 1.5, allowing Web developers to create powerful new Web applications using JavaScript, the Web's most popular scripting language. By focusing on standards compliance and free, open source, cross-platform implementations, Netscape is once again making developers' lives easier by enabling them to use their existing skill across languages, platforms, and applications, on both the client and the server. With JavaScript 1.5, Netscape is the first vendor to deliver full support for the ECMA-262 edition 3 standard of JavaScript, and the only vendor to provide a free and open source implementation of JavaScript, which is available in both C and Java versions. These embeddable engines allow developers to easily and at no cost make their own applications scriptable using JavaScript.

Core JavaScript Guide 1.4 -- what's new

What New in JavaScript 1.3

JavaScript 1.3 Overview, Part II - Doc JavaScript

• How to use the new Function object's call() method.
• How to use the new Function object's apply() method.
• How to use the new strict equality operators.
• How to use the modified equality operators.
• How to use the new lambda expression in the replace method.
• How to use the modified Array object.
• How to use the modified Boolean object.
• How to use the modified toString() method.
• How to use the right JavaScript version in the SCRIPT tag.
• How to use the modified JavaScript console.

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.

Last updated: March 12, 2019