Software Prototyping using Scripting Languages and Two language Approach
Software prototyping, refers to the activity of creating "disposable", threw-away version of software applications to test
the key ideas of the architecture .
A prototype typically simulates only a key aspects of the system, avoiding bells and whistles and as such can use different, higher
level implementation language then the final product. It also can be a virtual machine, not a software implementation in traditional
sense (see below).
As Wikipedia article states
Prototyping has several benefits: The software designer and implementer can get valuable feedback from the users early in the
project. The client and the contractor can compare if the software made matches the
according to which the software program is built. It also allows the software engineer some insight into the accuracy of initial
project estimates and whether the deadlines and milestones
proposed can be successfully met. The degree of completeness and the techniques used in the prototyping have been in development
and debate since its proposal in the early 1970s.
The monolithic "waterfall" approach to software development has been dubbed the "Slaying the (software) Dragon" technique, since
it assumes that the software designer and developer is a single hero who has to slay the entire dragon alone. Prototyping can help in
avoiding the great expense and difficulty of changing an almost finished software product due to changes in specification or understanding
of the problem (and understanding of the problem often comes too late in the "prototype-less" development of software).
The process of prototyping involves the following steps
- Identify key requirements
- Determine key requirements including the input and output information desired. Details, such as security, can typically
- Develop the Initial Prototype
- The initial prototype is developed that includes only key parts of the system. The customers, including end-users, can provide
some (limited) provide feedback on what is right and what is wrong in the specifications and implementations. Often at this
point specification radically changes.
- Review of architectural solutions
- Typically the initial approach to architecture is sub-optimal and during the implementation of the first version better
ideas surface. That's why it is of paramount important that architects were part of the prototype implementation team and "feel
the heat" of selected approaches to system design.
- Revise and Enhance the Prototype
- Using the feedback both the specifications can be made more realistic, often some requirements can be simplified or
eliminated. Negotiation what is within the scope of the project are very important part of getting high quality system
in time and within budget.
- Rewrite part of all prototype creating production version of software.
Approaches to prototyping
There are several appaches to prototyping. Among them there are two more or less realistic:
- Throwaway prototyping (which was
first advocated by Brooks in his famous book)
- Evolutionary prototyping ( software is developed and delivered incrementally to the
users. Functions are added or deleted as the software evolves, in situ, towards a satisfactory form.)
Also called close-ended prototyping. Throwaway or Rapid Prototyping refers to the creation of a model that will eventually
be discarded rather than becoming part of the final delivered software. After preliminary requirements gathering is
accomplished, a simple working model of the system is constructed to visually show the users what their requirements
may look like when they are implemented into a finished system.
- Rapid Prototyping involved creating a working model of various parts of the system at a very early stage, after
a relatively short investigation. The method used in building it is usually quite informal, the most important factor
being the speed with which the model is provided. The model then becomes the starting point from which users can
re-examine their expectations and clarify their requirements. When this has been achieved, the prototype model is
'thrown away', and the system is formally developed based on the identified requirements.
The most obvious reason for using Throwaway Prototyping is that it can be done quickly. If the users can get quick
feedback on their requirements, they may be able to refine them early in the development of the software. Making changes
early in the development lifecycle is extremely cost effective since there is nothing at that point to redo. If a project
is changed after a considerable work has been done then small changes could require large efforts to implement since
software systems have many dependencies. Speed is crucial in implementing a throwaway prototype, since with a limited
budget of time and money little can be expended on a prototype that will be discarded.
Another strength of Throwaway Prototyping is its ability to construct interfaces that the users can test. The user
interface is what the user sees as the system, and by seeing it in front of them, it is much easier to grasp how the
system will work.
- …it is asserted that revolutionary
rapid prototyping is a more
effective manner in which to deal with user requirements-related issues, and therefore a greater enhancement to
software productivity overall. Requirements can be identified, simulated, and tested far more quickly and cheaply
when issues of evolvability, maintainability, and software structure are ignored. This, in turn, leads to the accurate
specification of requirements, and the subsequent construction of a valid and usable system from the user's perspective
via conventional software development models.
Prototypes can be classified according to the fidelity with which they resemble the actual product in terms of appearance,
interaction and timing. One method of creating a low fidelity Throwaway Prototype is
The prototype is implemented using paper and pencil, and thus mimics the function of the actual product, but does not
look at all like it. Another method to easily build high fidelity Throwaway Prototypes is to use a
GUI Builder and create
a click dummy, a prototype that looks like the goal system, but does not provide any functionality.
Not exactly the same as Throwaway Prototyping, but certainly in the same family, is the usage of
storyboards, animatics or drawings. These are
non-functional implementations but show how the system will look.
SUMMARY:-In this approach the prototype is constructed with the idea that it will be discarded and the final system
will be built from scratch. The steps in this approach are:
- Write preliminary requirements
- Design the prototype
- User experiences/uses the prototype, specifies new requirements
- Repeat if necessary
- Write the final requirements
- Develop the real products
The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and
constantly refine it. "The reason for this is that the Evolutionary prototype, when built, forms the heart of the new
system, and the improvements and further requirements will be built.
When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt.
- "…evolutionary prototyping acknowledges that we do not understand all the requirements and builds only those
that are well understood."
This technique allows the development team to add features, or make changes that couldn't be conceived during the
requirements and design phase.
- For a system to be useful, it must evolve through use in its intended operational environment. A product is
never "done;" it is always maturing as the usage environment changes…we often try to define a system using our most
familiar frame of reference---where we are now. We make assumptions about the way business will be conducted and
the technology base on which the business will be implemented. A plan is enacted to develop the capability, and,
sooner or later, something resembling the envisioned system is delivered.
Evolutionary Prototypes have an advantage over Throwaway Prototypes in that they are functional systems. Although
they may not have all the features the users have planned, they may be used on an interim basis until the final system
- "It is not unusual within a prototyping environment for the user to put an initial prototype to practical use
while waiting for a more developed version…The user may decide that a 'flawed' system is better than no system at
In Evolutionary Prototyping, developers can focus themselves to develop parts of the system that they understand
instead of working on developing a whole system.
- To minimize risk, the developer does not implement poorly understood features. The partial system is sent to
customer sites. As users work with the system, they detect opportunities for new features and give requests for
these features to developers. Developers then take these enhancement requests along with their own and use sound
configuration-management practices to change the software-requirements specification, update the design, recode
Role of scripting languages in prototyping
Scripting language are ideal for software prototyping. Included among these benefits is the ability to address rapidly changing software
requirements. In addition, the efficiency gained from user-centered design, which consists of constant user feedback impacting the software
design, has received significant attention recently [Landauer95]. Fast compile-debug-test cycles, and high programming flexibility make
dynamically typed languages such as Perl, Python, PHP and Tcl ideal for the rapid creation of prototypes both on compoment
and system levels
Ousterhout was the first to argue that a two language approach is both feasible and practical for software development [Ousterhout97]
and created the scripting language (TCL) that has a transparent interface with C and can be extended using C modules. Python also provide
consistent interface to C to allow developers to move performance critical methods and procedures into C without modification of the
Supporting prototyping requires a language which can support transformation of components previously written in cscritping langue
into low level statically typed compiled language (C or C++) and vise versa. Currently, few scripting languages allow for this type
If developers choose to use a statically typed language (for example Java) they often encounter problems in the early prototyping
and development phases.
- They are inclined to define programming module interfaces prematurely which can cause delays for other developers when modules
are redefined and require recompilation of part or all of the system.
- They are forced to sped more time of development of a usable prototype due to long compile-test-debug cycles typical for static
- Determining the cause of an error can be difficult due to the inability to directly query the running program for information
other than through the use of a debugger.
- Debugging incomplete programs is almost impossible since the compiler will not allow the program to run until all of the compile-time
errors are corrected.
These limitations often make it difficult to use statically typed languages for rapid prototyping of all or part of an application.
On the other hand, if developers choose to use a single dynamically typed language they often encounter problems in the latter phases
of development when performance, scalability, and maintainability become critical issues. They often encounter performance problems
when writing computationally intensive code and tend to spend an unordinary amount of time optimizing code. They may also suffer
scalability problems related to CPU and memory usage typical for scripting languages. The detection of all coding errors is delayed
until the actual line of code containing the error is executed meaning that complex tests must be written in order to check the
validity of code. Despite the benefits of a scripting languages, these limitations increase the cost of maintaining a large codebase.
- TYPES OF PROTOTYPE
- LOW-FIDELITY versus HIGH-FIDELITY
A set of drawings (e.g., storyboard) that provide a static,
non-computerized, non-working mock-up of user interface for
the planned system
A set of screens that provide a dynamic, computerized,
working model of the planned system
- EXPLORATORY versus EXPERIMENTAL versus OPERATIONAL
A throw-away prototype used to clarify project goals, to
identify requirements, to examine alternative designs, or to
investigate a large and complex system
A prototype used to validate system specifications
An iterative prototype that is progressively refined until
it becomes the final system
- HORIZONTAL versus VERTICAL
A prototype that models many features but with little detail
- a horizontal slice of a system's structure chart from the
top down to a specific depth
- most useful in the early stages of design
- purpose is to test the overall interaction metaphor, so
includes common functions that the user is expected to
A prototype that models few features but with much detail
- a vertical slice of a system's structure chart from top
- most useful in the later stages of design
- purpose is to test details of the design
A prototype that is horizontal down to a particular level,
then vertical below that point
- GLOBAL versus LOCAL
A prototype of the entire system
- an expanded horizontal prototype that models a greater
number of features and covers multiple levels of the
system's structure chart
- useful throughout the design process
A prototype of a single usability-critical system component
- a vertical prototype that is focused on one feature
- useful at some specific stage of the design process
- DIMENSIONS OF PROTOTYPING
Will the prototype be runnable and, if so, what does that mean?
- CHAUFFEURED PROTOTYPE
"runnable" in the VERY LOOSE SENSE that the prototype allows
a walkthrough to be performed
- ANIMATION PROTOTYPE
runnable in the LOOSE SENSE that it is executes frame by
frame in "slide show" mode on a computer
- TURING PROTOTYPE
"runnable" in the sense that it executes in "slide show"
mode BUT allows a third party, hidden from view, to pick the
next slide based on user input (also called "Wizard of Oz"
- INTERACTIVE PROTOTYPE
runnable in the STRICT SENSE that it executes on the
computer AND responds to user input in real time
- FUNCTIONAL PROTOTYPE
runnable in the VERY STRICT SENSE that it executes on the
computer, responds to live input, and performs some of the
Will the prototype be improved by stages and, if so, will it
eventually grow into the final product?
What level of fidelity will the prototype achieve?
Will the prototype be limited to specific areas of
- CHARACTERISTICS OF A GOOD NON-DISPOSABLE PROTOTYPE
Works sufficiently well with live user input to permit
Can evolve, given sufficient refinement, into the final product
Has the "look and feel" and performance characteristics of the
As a minimum, simulates the 20% of the functions that customers
will use 80% of the time
- EVALUATION OF PROTOTYPING
- BENEFITS AND RISKS OF PROTOTYPING
- ADVANTAGES (BENEFITS)
- NUMBER 1 BENEFIT
Prototypes may be easily changed or even discarded.
- NUMBER 2 BENEFIT
Prototyping may improve communication between and among
developers and customers
- NUMBER 3 BENEFIT
Users may be more satisfied with systems developed using
- A prototype may provide the proof of concept necessary to
- A prototype may serve as a marketing tool.
- A prototype may serve as the basis for operational
- Early visibility of the prototype may help management assess
- Exploratory prototyping allows productive work to proceed
despite initial uncertainties.
- Prototypes may demonstrate progress at an early stage of
- Prototypes may provide early training for future users of
- Prototyping may prevent unpleasant surprises by calling
attention to incomplete or inconsistent requirements, or to
- Prototyping may produce some useful deliverables even if the
project runs out of time or money.
- Prototyping may reduce misunderstandings between and among
developers and customers.
- Prototyping may reduce redesign costs if problems are
detected early when they are cheap to fix.
- Prototyping may reduce the time required for testing if
problems are detected early when they are cheap to fix.
- Prototyping may require less effort (43% less, according to
Boehm, Gray & Seewaldt, 1984) than conventional development.
- Prototyping may result in a 50-50 partnership between users
and developers where both experience "ownership".
- Prototyping may result in a product that is a better fit for
the customer's requirements.
- Prototyping may save on initial maintenance costs because,
in effect, customers are doing "acceptance testing" all
along the way.
- Prototyping may strengthen requirements specifications.
- Systems produced through prototyping may be judged easier to
learn and easier to use.
- The horizontal prototyping method works nicely as a
complement to structured analysis.
- The prototyping environment less vested in a particular
design, hence more open to change and innovation.
- Use of prototypes may flush out change requests earlier,
when they are cheaper to process.
- Users may understand prototypes better than paper
- Using prototyping during development may reduce the amount
of code that is finally written (by 60%, according to Boehm,
Gray & Seewaldt, 1984).
- PITFALLS (RISKS)
- NUMBER 1 RISK
Prototpying may encourage an excess of change requests.
- NUMBER 2 RISK
Working prototypes may lead management and customers to
believe that the final product is almost ready for delivery.
- NUMBER 3 RISK
The excellent (or disappointing) performance characteristics
of prototypes may mislead the customer.
- Customers may not be prepared to provide the level or
frequency of feedback required for iterative prototyping.
- Customers may not be willing to participate in the iteration
cycle over the long haul
- Developers may have difficulty writing the back-end code
needed to support the slick front-end interface designed
with the prototyping tool.
- Due to time and market constraints, system specifications
may be frozen before the prototyping process has reached a
- During prototyping, the only "design specification" is the
prototype itself, which may allow uncontrolled change.
- Early prototypes may be of low fidelity, dismissed as toys.
- Hi-fidelity prototypes may be mistaken for a real product.
- Important system characteristics (e.g., performance,
security, robustness and reliability) may have been ignored
during prototype development.
- It may be impossible to prototype mission- or
safety-critical system functions.
- Iterative prototyping may be difficult for management to
plan and schedule.
- Prototypes may become over-evolved, straining to incorporate
secondary functionality even though that will take
disproportionately more development time.
- Prototypes may embody simplifications and other
- Prototypes may oversell the product.
- Prototypes of complex systems may themselves be rather
- Prototyping is an adaptive process that may not exhibit
- Prototyping may continue too long because there may be no
well-defined completion criterion.
- Prototyping may force developers to change design
philosophies (e.g., switch to a bottom-up or an event-driven
- Prototyping may provide little room for testing
NON-functional system requirements.
- Prototyping may stall if members of the team do not have
enough decision-making authority.
- Prototyping, because it may be less controlled than
conventional development methods, may lead to a reduction in
- Specifications that emerge during later prototyping may
reduce the structural integrity of the partially designed
system (e.g., increase coupling between modules).
- The context of use for a prototype may be very different
from the context of use for the final system.
- There is no guarantee that the positions of developers and
customers will converge during the iteration cycle.
- WHEN PROTOTYPING WORKS AND WHEN IT DOESN'T
- PROTOTYPING IS MORE LIKELY TO SUCCEED WHEN ...
- used as a means to achieve early usability testing
- used to compare alternative designs (the "dueling
- used to create a "living" specification
- used to escape from the rigid serial pattern imposed by the
traditional software development life cycle
- used to evaluate a proposed interface
- used to explore the effect of change requests
- used to expose new or unexpected requirements
- used to identify market requirements
- used to involve users in the design process
- used to model a system that has a significant user interface
- used to model a system that is relatively large and complex
- used to provide a common basis for good communication
between developers and customers
- used to stimulate customer input during requirements
- used within a rapid prototyping tool
- PROTOTYPING IS MORE LIKELY TO FAIL WHEN ...
- no clear terminating criterion has been established to end
the iterative development cycle
- the expectations of customers are allowed go grow beyond
- the functionality of an operational prototype does not scale
up to the functionality required of the final system
- the opinions of developers and customers diverge during the
- the project is too small to justify prototyping
- the prototype is mistaken for the promised product
- used to model systems that present no external interface
(e.g., embedded systems)
- used to gauge the future performance of the planned system
- used to market software that does not exist
Modern software development demands the use of Rapid Application Prototyping. Professor Luqi at the Naval Postgraduate School
coined the term "Computer Aided Prototyping" to describe this work. Her leadership showed its effectiveness in gaining understanding
of the requirements, reducing the complexity of the problem and providing an early validation of the system design. For every dollar
invested in prototyping, one can expect a $1.40 return within the life cycle of the system development.
Dr. Barry Boehm's experiments showed that prototyping reduces program size and programmer effort by 40%. It is the technology
that is the foundation for his Spiral development method. Prototyping is being used successfully to gain an early understanding
of system requirements, to simplify software designs, to evaluate user interfaces and to test complex algorithms. It is a best-in-class
Fully 30 to 40% of system requirements will change without prototyping. Rapid Application Prototyping provides a look at the
dynamic states of the system before we build it, whereas most other software engineering focuses on the source code. The special
problems of reliability, throughput and response time as well as system features are addressed in the best prototypes. A new field
of study, Software Dynamics, will emerge once Rapid Application Prototyping is widely practiced. It will focus on quantitative analysis
of how software performs under various loads and include a set of design constraints that will make it possible for us to build
components that can be hooked together without exhaustive coverage testing.
Software is hard because it has a weak theoretical foundation. Most of the theory that does exist focuses on the static behavior
of the software, analysis of the source listing. There is little theory on its dynamic behavior, how it performs under load. To
avoid serious network problems software systems are over-engineered with plenty of bandwidth for two or three times the expected
load. Without analysis of the dynamic behavior, application designers have no idea of the resources they will need once their software
is operational. Software has the awful propensity to fail with no warning. Even after we find and fix a bug, how do we restore the
software to a known state, one where we have tested its operation? For most systems, this is impossible except with lots of custom
design that is itself error-prone. Software prototyping has proven its mettle in helping designers avoid these problems in their
Much has been written about the best way to develop software applications. But there is no "best way." Both prototyping and requirements
are necessary. The tried and true process of synthesis and analysis is used to solve Software Engineering problems. Bottom-up is
synthesis. Top-down is analysis. Bottom-up is prototyping. Top-down is developing requirements. Prototyping is the best way to encourage
synthesis. Prototyping also eases communication with the customer and with the designer. Formal written requirements are needed
to establish a clear definition of the job, to control changes and to communicate the system capabilities between the customer and
So where does this leave us?
Start with an English language written statement of a problem and broadly outline its solution. Now build a prototype for the
elements where you need insight. Analyze the prototype using computer aided prototyping technology and synthesize a new solution
either by refining the prototype or building a new one. Once you and the customer agree on the workings of the prototype, write
requirements that include features, performance goals, product costs, product quality, development costs and schedule estimates.
What do I mean by prototype?
Prototyping is the use of approximately 30% of the ultimate staff to build one or two working versions of various aspects of
a system. It is not production code but it may eventually become pre-production code or it may be completely discarded. In the prototyping
effort, we are not concerned with the maintainability of the code nor are we concerned with formally documenting it. Code resulting
from prototyping is often used to train the programmers. Only after we have written specifications resulting from the experience
with the prototype should we start the formal development process. If we are fortunate enough that some of the code that was developed
for the prototypes can be carried forward, that's great, if not, there is no loss.
A prototype produces "running" software and the production development produces "working" software.
Recent project experience has led to the widespread acceptance of the concept that early prototyping is fundamental to the success
of operations supporting software products.
The reasons why prototyping is fundamental include:
- The prototype provides a vehicle for systems engineers to better understand the environment and the requirements problem
- A prototype is a demonstration of what's actually feasible with existing technology, and where the technical weak spots
- A prototype is an efficient mechanism for the transfer of design intent from system engineer to the developer.
- A prototype lets the developer meet earlier schedules for the production version.
- A prototype allows for early customer interaction.
- A prototype demonstrates to the customers what is functionally feasible and stretches their imagination, leading to more
creative inputs and a more forward-looking system.
- The prototype provides an analysis test bed and a vehicle to validate and evolve system requirements.
About the Author
Mr. Bernstein is president of the Center of National Software Studies and is a recognized expert in Software Technology.
He provides consulting through his firm Have Laptop - Will Travel and is the Executive Technologist with Network Programs, Inc.
building software systems for managing telephone services.
Mr. Bernstein was an Executive Director of AT&T Bell Laboratories where he worked for 35 years.
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
in our efforts to advance understanding of environmental, political,
human rights, economic, democracy, scientific, and social justice
issues, etc. We believe this constitutes a 'fair use' of any such
copyrighted material as provided for in section 107 of the US Copyright
Law. In accordance with Title 17 U.S.C. Section 107, the material on
this site is distributed without profit exclusivly for research and educational purposes. If you wish to use
copyrighted material from this site for purposes of your own that go
beyond 'fair use', you must obtain permission from the copyright owner.
Two Party System
as Polyarchy :
Corruption of Regulators :
and Control Freaks : Toxic Managers :
Harvard Mafia :
: Surviving a Bad Performance
Review : Insufficient Retirement Funds as
Immanent Problem of Neoliberal Regime : PseudoScience :
Who Rules America :
: The Iron
Law of Oligarchy :
War and Peace
Finance : John
Kenneth Galbraith :Talleyrand :
Oscar Wilde :
Otto Von Bismarck :
George Carlin :
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
Vol 25, No.08 (August, 2013) Cloud providers
as intelligence collection hubs :
Financial Humor Bulletin, 2010 :
Inequality Bulletin, 2009 :
Financial Humor Bulletin, 2008 :
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 :
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
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 :
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
The Last but not Least
Copyright © 1996-2014 by Dr. Nikolai Bezroukov. www.softpanorama.org
was created as a service to the UN Sustainable Development Networking Programme (SDNP)
in the author free time. This document is an industrial compilation designed and created exclusively
for educational use and is distributed under the Softpanorama Content License.
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...
The statements, views and opinions presented on this web page are those of the author 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: February 19, 2014