does, lead to storage violation errors that are extremely difficult to
resolve.

Many computer languages require garbage collection, either as part of the
language specification (e.g., Java, C#, and most scripting languages) or
effectively for practical implementation (e.g., formal languages like lambda
calculus); these are said to be garbage collected languages. Other languages
were designed for use with manual memory management, but have garbage
collected implementations available (e.g., C, C++). Some languages, like Ada,
Modula-3, and C++ allow both garbage collection and manual memory management
to co-exist in the same application by using separate heaps for collected and
manually managed objects; others, like D, are garbage collected but allow the
user to manually delete objects and also entirely disable garbage collection
when speed is required.

###### Benefits

Garbage collection frees the programmer from manually dealing with memory
allocation and deallocation. As a result, certain categories of bugs are
eliminated or substantially reduced:

  * •

Dangling pointer bugs, which occur when a piece of memory is freed while there
are still pointers to it, and one of those pointers is then used.

  * •

Double free bugs, which occur when the program attempts to free a region of
memory that is already free.

  * •

Certain kinds of memory leaks, in which a program fails to free memory
occupied by objects that will not be used again, leading, over time, to memory
exhaustion.

###### Disadvantages

Typically, garbage collection has certain disadvantages.

  * •

Garbage collection is a process that consumes limited computing resources in
deciding what memory is to be freed and when, reconstructing facts that may
have been known to the programmer. The penalty for the convenience of not
annotating memory usage manually in the code is overhead leading, potentially,
to decreased performance.

  * •

The point when the garbage is actually collected can be unpredictable,
resulting in delays scattered throughout a session. Unpredictable delays can
be unacceptable in real-time environments such as device drivers, or in
transaction processing. Recursive algorithms that take advantage of automatic
storage management often delay automatic release of stack objects until after
the final call has completed, causing increased memory requirements.

  * •

Memory may leak despite the presence of a garbage collector if references to
unused objects are not themselves manually disposed of. Researchers draw a
distinction between “physical” and “logical” memory leaks. In a physical
memory leak, the last pointer to a region of allocated memory is removed, but
the memory is not freed. In a logical memory leak, a region of memory is still
referenced by a pointer, but is never actually used.[4] Garbage collectors
generally can do nothing about logical memory leaks.

  * •

Perhaps the most significant problem is that programs that rely on garbage
collectors often exhibit poor locality (interacting badly with cache and
virtual memory systems), occupying more address space than the program
actually uses at any one time, and touching otherwise idle pages. These may
combine in a phenomenon called thrashing, in which a program spends more time
copying data between various grades of storage than performing useful work.
They may make it impossible for a programmer to reason about the performance
effects of design choices, making performance tuning difficult. They can lead
garbage-collecting programs to interfere with other programs competing for
resources.

  * •

The execution of a program using a garbage collector is not deterministic. An
object which becomes eligible for garbage collection will usually be cleaned
up eventually, but there is no guarantee when (or even if) that will happen.
Most run-time systems using garbage collectors require manual deallocation of
limited non-memory resources (using finalizers), as an automatic deallocation
during the garbage collection phase may run too late or in the wrong
circumstances. Also, the performance impact caused by the garbage collector is
seemingly random and hard to predict, leading to program execution that non-
deterministic.

Generally speaking, higher-level programming languages are more likely to have
garbage collection as a standard feature. In languages that do not have built
in garbage collection, it can often be added through a library, as with the
Boehm garbage collector for C and C++. This approach is not without drawbacks,
such as changing object creation and destruction mechanisms.

Most functional programming languages, such as ML, Haskell, and APL, have
garbage collection built in. Lisp, which introduced functional programming, is
especially notable for introducing this mechanism.

Other dynamic languages, such as Ruby (but not Perl, or PHP, which use
reference counting), also tend to use garbage collection. Object-oriented
programming languages such as Smalltalk and Java usually provide integrated
garbage collection. A notable exception is C++ which, uniquely, relies on
destructors [22].

  1. 1.

http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29

  2. 2.

http://en.wikipedia.org/wiki/Finalizer

####  3.4.2 Manual memory management

Manual memory management refers to the usage of manual instructions by the
programmer to identify and deallocate unused objects, or garbage. Up until the
mid 1990s, the majority of programming languages used in industry supported
manual memory management. Today, however, languages with garbage collection
are becoming increasingly popular; the main manually-managed languages still
in widespread use today are C and C++.

Most programming languages use manual techniques to determine when to allocate
a new object from the free store. C uses the malloc() function; C++ and Java
use the new operator; determination of when an object ought to be created is
trivial and unproblematic. The fundamental issue is determination of when an
object is no longer needed (ie. is garbage), and arranging for its underlying
storage to be returned to the free store so that it may be re-used to satisfy
future memory requests. In manual memory allocation, this is also specified
manually by the programmer; via functions such as free() in C, or the delete
operator in C++. Manual memory management is known to enable several major
classes of bugs into a program, when used incorrectly:

  * •

When an unused object is never released back to the free store, this is known
as a memory leak. In some cases, memory leaks may be tolerable, such as a
program which “leaks” a bounded amount of memory over its lifetime, or a
short-running program which relies on an operating system to deallocate its
resources when it terminates. However, in many cases memory leaks occur in
long-running programs, and in such cases an unbounded amount of memory is
leaked. When this occurs, the size of the available free store continues to
decrease over time; when it finally is exhausted the program then crashes.

  * •

When an object is deleted more than once, or when the programmer attempts to
release a pointer to an object not allocated from the free store, catastrophic
failure of the dynamic memory management system can result. The result of such
actions can include heap corruption, premature destruction of a different (and
newly-created) object which happens to occupy the same location in memory as
the multiply-deleted object, and other forms of undefined behavior.

  * •

Pointers to deleted objects become wild pointers if used post-deletion;
attempting to use such pointers can result in difficult-to-diagnose bugs.

Languages which exclusively use garbage collection are known to avoid the last
two classes of defects. Memory leaks can still occur (and bounded leaks
frequently occur with generational or conservative garbage collection), but
are generally less severe than memory leaks in manual memory allocation
schemes.

Manual memory management has one correctness advantage, which comes into play
when objects own scarce system resources (like graphics resources, file
handles, or database connections) which must be relinquished when an object is
destroyed. Languages with manual management, via the use of destructors, can
arrange for such actions to occur at the precise time of object destruction.
In C++, this ability is put to further use to automate memory deallocation
within an otherwise-manual framework, use of the auto ptr template in the
language’s standard library to perform memory management is a common paradigm.

Many advocates of manual memory management argue that it affords superior
performance when compared to automatic techniques such as garbage collection.
Manual allocation does not suffer from the long “pause” times often associated
with garbage collection (although modern garbage collectors have collection
cycles which are often not noticeable), and manual allocation frequently has
superior locality of reference. This is especially an issue in real time
systems, where unbounded collection cycles are generally unacceptable. Manual
allocation is also known to be more appropriate for systems where memory is a
scarce resource.

On the other hand, manual management has documented performance disadvantages:

  * •

Calls to delete and such incur an overhead each time they are made, this
overhead can be amortized in garbage collection cycles. This is especially
true of multithreaded applications, where delete calls must be synchronized.

  * •

The allocation routine may be more complicated, and slower. Some garbage
collection schemes, such as those with heap compaction, can maintain the free
store as a simple array of memory (as opposed to the complicated
implementations required by manual management schemes).

  1. 1.

http://en.wikipedia.org/wiki/Manual_memory_management

##  Chapter 4 Programming Languages Popularity

Since the beginning of the computer, thousands of programming languages have
been designed. However, a relatively few proportion of these were actually put
to practical use in the industry. Some languages have been developed and/or
adopted by the academic community for teaching purposes but did not really
come into practical use either. Due to their adoption in University computer
science programs, such languages can boast great popularity, but still failed
to have become popular for extensive industrial software development. Many
factors or indicators can be used to measure the popularity of programming
languages. Here we discuss various surveys that have been made to measure the
popularity of programming languages.

###  4.1 langpop.com

The methodology and results presented here are based on:
http://www.langpop.com/. It uses various web sites as a data source to extract
indicators of programming languages’ popularity rankings.

####  4.1.1 Yahoo Search

Arguably, the popularity of a programming language can be measured by the
number of web pages discussing it. Yahoo provides an API for doing customized
searches on its web pages indexing database. Searching for various programming
languages’ names, http://www.langpop.com/ arrives to the conclusion that the
programming languages most referred to on the web are: C++, C, Java, and PHP,
as shown on the extracted figure:

####  4.1.2 Job Postings

Since industry demand is probably a more relevant indicator of a language’s
popularity, one might search a job offerings database and search for specific
programming languages being asked for in job offerings. Based on a search of
craigslist.org, http://www.langpop.com/ arrives to the conclusion that PHP,
SQL, C, C++, Java, JavaScript, and C# are the most in-demand languages, as
shown on the extracted figure:

####  4.1.3 Books

Arguably, the more a programming language is popular, the more books are being
sold explaining how to use it. In http://www.langpop.com/, a search is made to
a bookstore database to figure out what languages are more popular as books’
topics. It arrives to the conclusion that Java, C++, Visual Basic, C#, and C
are the most popular from this regard, as shown on the extracted figure:

####  4.1.4 Open source code repositories

The open source code development community provides a public a free source of
information that can be used to measure the popularity of programming
languages effectively used by developers. In http://www.langpop.com/, a search
is made on various open source code repositories and the programming language
used in each open source project is extracted.

##### freshmeat.org

While searching the freshmeat.net open source community web site, it showed
that C, Java, C++, PHP, Perl, and Python are the most popular, as shown in the
extracted figure:

##### Google code search

Doing a similar search on the Google code web site
(http://www.google.com/codesearch), it was extracted that (as for the results
for freshmeat.org) C, Java, C++, PHP, Perl, and Python are the most popular
languages.

##### Ohloh

Doing yet another similar search on the Ohloh web site (www.ohloh.net) [1], it
was extracted that, quite differently from the two previous results, Java, C,
C++, JavaScript, Shell, Python, and PHP are the most popular languages, as
shown in the figure:

####  4.1.5 Discussion sites

Another relevant source of information to measure the relative popularity of
programming languages is public discussion sites, where programmers discuss
technical issues among themselves. In http://www.langpop.com/, the following
discussion sites were searched for: lambda-the-ultimate.org, slashdot.org,
programming.reddit.com, and freenode.net. Overall, the results of these
searches revealed that Java, C, C++, C#, PHP and Python are the languages that
the programmers communities are the most discussing among themselves, as shown
in the extracted figure:

.

Notably in the search on public discussion sites, lambda-the-ultimate.org is a
site that is very popular particularly with the academia circles. Searches on
this site has revealed a different taste in academia, showing that languages
like Haskell, Lisp, Scheme, Python, Erlang, Ruby, Scala, Smalltalk, and Ada
are popular discussion topics in academic circles, as shown in the extracted
figure:

.

###  4.2 www.tiobe.com

The results presented here are based on a monthly survey done by Tiobe
Software (www.tiobe.com). As stated on the “Tiobe index” web page updated
monthly, the TIOBE Programming Community index gives an indication of the
popularity of programming languages. The index is updated once a month. The
ratings are based on the number of skilled engineers world-wide, courses and
third party vendors. The popular search engines Google, MSN, Yahoo!, Wikipedia
and YouTube are used to calculate the ratings. Observe that the TIOBE index is
not about the best programming language or the language in which most lines of
code have been written. The data presented here is as of March 2010.

####  4.2.1 Top 20 programming languages (March 2010)

According to the TIOBE index (March 2010), the top 20 most popular programming
languages are depicted as in the extracted figure:

.

####  4.2.2 Long-term trend

As the TIOBE index is calculated monthly, and has been there for a long time,
it is very interesting to see long-term trends in the history of programming
languages popularity, as depicted in the extracted figure:

.

####  4.2.3 Categories of programming languages

The TIOBE index also enables the categorization of popular programming
languages. The results are as depicted in the extracted figure:

.

##  Chapter 5 Programming Languages Performance Ranking

In order to perform a relative evaluation of programming languages other than
based on their popularity, the execution performance of programs can be
exercised and compared. This requires the design of algorithmically comparable
solutions in various languages and executing these programs in the same
execution environment.

Many such empirical studies have been made to compare programming languages.
Notably, the Computer Languages Benchmark Game [1]
(http://shootout.alioth.debian.org/) provides a dynamic web site demonstrating
extensive empirical results enabling the comparison of various programming
languages using a wide variety of benchmarking programs.

Among the most revealing comparisons that can be found on this site is the
following: [2] (http://shootout.alioth.debian.org/u32q/which-language-is-
best.php). It enables the comparison of programming languages according to
performance criteria such as: execution time, memory consumption, and source
code size.

###  5.1 Execution time

###  5.2 Memory consumption

###  5.3 Source code size

###  5.4 Overall results

## Bibliography

  * [1] Jason Allen, Scott Collison, Robin Luckey, and Andy Verprauskus.  Ohloh.  ohloh.net, 2008.  http://www.ohloh.net/, viewed in January 2008.
  * [2] Apache Foundation.  Apache Jakarta Tomcat.  [online], 1999–2010.  http://jakarta.apache.org/tomcat/index.html.
  * [3] AspectJ Contributors.  AspectJ: Crosscutting Objects for Better Modularity.  eclipse.org, 2007.  http://www.eclipse.org/aspectj/.
  * [4] Autodesk.  Maya.  [digital], 2008–2010.  autodesk.com.
  * [5] Blender Foundation.  Blender.  [online], 2008–2010.  http://www.blender.org.
  * [6] Fancois Bourdoncle and Stephan Merz.  On the integration of the functional programming, class-based object-oriented programming, and multi-methods.  Technical report, Centre de Mathemathiques Appliquees, Ecole des Mines de Paris and Institut fur Informatik, Technische Universitat Munchen, October 1996.
  * [7] Robert G. Clark.  Comparative Programming Languages.  Addison-Wesley, 3 edition, November 2000.  ISBN: 978-0201710120.
  * [8] Dale Green.  Java reflection API.  Sun Microsystems, Inc., 2001–2005.  http://java.sun.com/docs/books/tutorial/reflect/index.html.
  * [9] P. J. Landin.  The next 700 programming languages.  Communications of the ACM, 9(3):157–166, 1966.
  * [10] Kenneth C. Louden.  Compiler Construction: Principles and Practice.  PWS Publishing Company, 1997.  ISBN 0-564-93972-4.
  * [11] Lee E. McMahon, Paolo Bonzini, Aur’elio M. Jargas, Eric Pement, Tilmann Bitterberg, Yao-Jen Chang, Yiorgos Adamopoulos, et al.  sed – stream editor for filtering and transforming text.  ftp://ftp.gnu.org/pub/gnu/sed and http://sed.sf.net, 1973–2006.  http://sed.sourceforge.net/, last viewed May 2008.
  * [12] Brian McNamara and Yannis Smaragdakis.  Functional programming in C++ using the FC++ library.  SIGPLAN Notices, 36(4):25–30, 2001.
  * [13] Tobias Nipkow, Lawrence C. Paulson, and Markus Wenzel.  Isabelle/HOL: A Proof Assistant for Higher-Order Logic, volume 2283\.  Springer-Verlag, November 2007.  http://www.in.tum.de/~nipkow/LNCS2283/, last viewed: December 2007\.
  * [14] Joey Paquet.  Course notes for COMP6411, winter 2010.  Department of Computer Science and Software Engineering, Concordia University, Montreal, Canada, 2010.  [online].
  * [15] Lawrence C. Paulson and Tobias Nipkow.  Isabelle: A generic proof assistant.  University of Cambridge and Technical University of Munich, 2010.  http://isabelle.in.tum.de/, last viewed: February 2010.
  * [16] Yannis Smaragdakis and Brian McNamara.  FC++: Functional tools for object-oriented tasks.  Softw., Pract. Exper., 32(10):1015–1033, 2002.
  * [17] Sun Microsystems, Inc.  Java servlet technology.  [online], 1994–2005.  http://java.sun.com/products/servlets.
  * [18] Sun Microsystems, Inc.  JavaServer pages technology.  [online], 2001–2005.  http://java.sun.com/products/jsp/.
  * [19] Various Contributors and the Flex Project.  flex: The fast lexical analyzer.  [online], 1987–2008.  http://flex.sourceforge.net/, viewed in January 2008.
  * [20] Various Contributors and the GNU Project.  Bison – GNU parser generator.
  * [21] Various Contributors and the GNU Project.  GNU Compiler Collection (GCC).  [online], 1988–2009.  http://gcc.gnu.org/onlinedocs/gcc/.
  * [22] Emil Vassev and Joey Paquet.  Aspects of memory management in Java and C++.  In Hamid R. Arabnia and Hassan Reza, editors, Software Engineering Research and Practice, pages 952–958. CSREA Press, 2006.
  * [23] Sreenivasa Viswanadha and Contributors.  Java compiler compiler (JavaCC) - the Java parser generator.  [online], 2001–2008.  https://javacc.dev.java.net/.
  * [24] Jimmy Wales, Larry Sanger, and other authors from all over the world.  Wikipedia: The free encyclopedia.  [online], Wikimedia Foundation, Inc., 2001–2010.  http://wikipedia.org.

## Index

  * .NET
    * JIT §3.2.1
  * Ada §1.2.5
  * Ahead-of-time compile §3.2.1
  * Alan Kay §2.2.3
  * AOP §2.2.3
  * API
    * aspect §2.2.3
    * bark() 3rd item, 5th item, 5th item, 5th item, 5th item, 7th item, 7th item, 8th item
    * CALL §2.2.1
    * COPY §2.2.1
    * DOALL §3.2.1
    * Duck §3.3.1
    * else §3.3.1
    * false §3.3.1
    * free() §3.4.2
    * GET §2.2.1
    * IDisposable §3.4.1
    * inhale() 7th item
    * malloc() §3.4.2
    * new §3.4.2
    * printf §1.2.5
    * PUT §2.2.1
    * quack() §3.3.1, §3.3.1, §3.3.1
    * READ §2.2.1
    * scanf §1.2.5
    * speak() 8th item, 8th item, 8th item
    * unsafePerformIO §3.3.1
    * walk() §3.3.1, §3.3.1, §3.3.1
    * where §1.2.5, §1.2.5, §1.2.5
    * WRITE §2.2.1
  * Aspect-oriented programming §2.2.3
  * AspectJ §2.2.3
  * Assembly §2.2.1
  * Back end §3.1.2
  * BASIC §1.2.5
  * bytecode §3.2.1
  * C §1.2.5, §1.2.5, §1.2.5, §1.2.5, §2.2.3, §2.2.4, §3.2.2, §3.3.1, §3.3.1, §3.4.1, §3.4.1, §3.4.2, §3.4.2, §4.1.1, §4.1.2, §4.1.3, §4.1.4
  * C# §1.2.5, §2.1, 7th item, §2.2.4, §2.2.4, §3.3.1, §3.3.1, §3.3.1, §3.4.1, §3.4.1, §3.4.1, §4.1.2, §4.1.3
  * C++ 1st item, 2nd item, 3rd item, 4th item, 5th item, 6th item, 7th item, §1.2.5, §1.2.5, §1.2.5, §1.2.5, §1.2.5, §1.2.5, §1.2.5, §1.2.5, §1.2.5, §1.2.5, §1.2.5, §2.1, 7th item, 8th item, §2.2.3, §2.2.4, §2.2.4, §3.3.1, §3.3.1, §3.3.1, 3rd item, §3.4.1, §3.4.1, §3.4.1, §3.4.1, §3.4.2, §3.4.2, §4.1.1, §4.1.2, §4.1.3, §4.1.4
  * Code generation §3.1.2
  * Common LISP §3.2.1
  * Compilation §3.2.1
  * Compilation vs. interpretation §3.2
  * David Warren §3.2.1
  * Duck typing §3.3.1
  * Dynamic compilation §3.2.1
  * Dynamic typing §3.3.1
  * embedded systems §2.2.1
  * FC++ §2.2.4
  * Files
    * .class §3.2.1
  * Fortran §3.2.1, §3.3.1
  * Front end §3.1.1
  * Garbage collection §3.4.1
    * Benefits §3.4.1
    * Disadvantages §3.4.1
  * hard-wired §2.2.1
  * Haskell §1.2.5, §1.2.5, §2.2.4, §2.2.4, §2.2.4, §2.2.4, §3.3.1, §3.3.1, §3.4.1
  * History §1.2
    * Analytical engine §1.2.1
    * Early computer era §1.2.3
    * Modern/Structured programming languages §1.2.5
    * Pre-computer era §1.2.1
  * Interpretation §3.2.2
  * ISWIM §1.2.5
  * Java §1.2.5, §1.2.5, 4th item, 7th item, §2.2.3, §2.2.4, 1st item, §3.2.1, §3.2.1, §3.2.1, §3.2.1, §3.2.1, §3.2.2, §3.2.2, §3.2.2, §3.3.1, §3.3.1, §3.3.1, §3.4.1, §3.4.1, §3.4.1, §3.4.2, §4.1.1, §4.1.2, §4.1.3, §4.1.4
    * JIT §3.2.1
  * JIT §3.2.1
    * .NET §3.2.1
    * Java §3.2.1
  * JSP §3.2.1
  * Just-in-time compiler §3.2.1
  * JVM §3.2.1
  * Lexical analysis §3.1.1
  * LISP §1.2.5, §1.2.5, §3.2.2, §3.3.1
  * low-level §2.2.1
  * Mac OS X §1.2.5
  * Memory management §3.4
  * ML≤ §1.2.5
  * Nominative type system §3.3.1
  * OpenMP §3.2.1
  * Optimization §3.1.2
  * Pascal §1.2.5, §3.2.2
  * Performance Chapter 5
  * Perl §1.2.5, §1.2.5, §2.1, §2.2.3, §2.2.4, §2.2.4, §3.2.2, §3.3.1, §3.3.1, §3.4.1
  * PHP §2.2.3, §3.3.1, §3.4.1, §4.1.1, §4.1.2, §4.1.4
  * Plankalk l §1.2.3
  * Popularity Chapter 4
  * Program analysis and translation phases §3.1
  * Program Evaluation Chapter 3
  * Prolog §1.2.5, §3.2.1
  * Python §1.2.5, §1.2.5, §1.2.5, §1.2.5, §1.2.5, §1.2.5, §1.2.5, §1.2.5, §2.1, §2.2.3, §3.2.1, §3.2.2, §3.2.2, §3.3.1
  * Ruby §3.2.2
  * Scheme §1.2.5, §1.2.5, §1.2.5, §1.2.5, §1.2.5, §2.1, §2.2.4, §2.2.4, §2.2.4, §2.2.4
  * security §3.2.1
  * Self §3.2.1
  * Semantic analysis §3.1.1
  * Short Code §1.2.4
  * Smalltalk §1.2.5
    * 80 §3.2.2
  * Source-to-source compiler §3.2.1
  * Stage compiler §3.2.1
  * Static typing §3.3.1
  * Structural type system §3.3.1
  * symbol table §3.1.1
  * Syntactic analysis §3.1.1
  * Tools
    * gcc §2.2.4
    * JavaCC §3.1.1
    * lex §3.1.1, §3.1.1
    * sed §1.2.5
  * Type checking §3.3.1
  * Type System §3.3
  * WAM §3.2.1
  * Warren Abstract Machine §3.2.1