Maintenance of Dynamically vs. Statically typed Languages

CPSC 543

Dynamically and Statically typed Languages
June 10, 2009

Submitted By
Muhammad Bandeali

Submitted to
Prof. Allen Holliday
California State University, Fullerton

i

Table of Contents

Introduction....................................................................................................................................1
Data Types......................................................................................................................................1
1.1 Sound types..........................................................................................................................1
1.2 Explicit/Implicit types .........................................................................................................1
1.2.1 Implicit type..................................................................................................................2
1.2.2 Explicit type..................................................................................................................2
1.3 Structural types ....................................................................................................................2
1.4 Duck typing..........................................................................................................................2
Static Programming Languages......................................................................................................3
Dynamic Programming Languages.................................................................................................3
Core Differences.............................................................................................................................3
Languages.......................................................................................................................................4
Static to Dynamic...........................................................................................................................4
Type Inference and Binding............................................................................................................5
Sub-typing......................................................................................................................................5
Generics..........................................................................................................................................5
Reflection.......................................................................................................................................6
Maintenance....................................................................................................................................7
12.1 Packages/Namespaces........................................................................................................7
12.2 Contracts.............................................................................................................................7
12.3 New Requirements Testing.................................................................................................8
12.4 Refactoring.........................................................................................................................8
12.5 Reengineering.....................................................................................................................9
12.6 Reuse..................................................................................................................................9
12.7 Documentation.................................................................................................................10
Language Selection.......................................................................................................................10
13.1 Capability.........................................................................................................................10
13.2 Productivity......................................................................................................................10
13.3 Costs ................................................................................................................................10
13.4 Expectations.....................................................................................................................10
13.5 Development....................................................................................................................10
13.6 Support.............................................................................................................................11
13.7 Deployment......................................................................................................................11
13.8 Performance......................................................................................................................11
13.9 Scalability.........................................................................................................................11
13.10 Reliability.......................................................................................................................11
13.11 Hardware........................................................................................................................11
13.12 Ramp-Up Time ..............................................................................................................11
Conclusion....................................................................................................................................12
References....................................................................................................................................14

i

Introduction
For the last few years a major change has been taking place; more and more people have been
transitioning from static system languages such as Java, C#, C++ to dynamic languages such as
Perl, Python, etc. Even though many people are participating in the change, not many know why
is it really happening? Do dynamic languages handle many of the programming tasks better than
static languages?
The answer to this phenomenon is not so simple. Static system programming languages were
designed for creating data structures and algorithms in a bottom up manner by hand typing in the
most primitive variables to high level abstract classes. Dynamic languages are designed for
gluing the already built set of powerful components on static system programming languages.
Hence, both dynamic and static languages could be complementary [4].
Static languages strive to minimize surprises at the runtime and therefore fix any errors at
compile time. But the nature of design and implementation of these languages places constraints
on the user that narrows any choices.
Dynamic languages on the other hand minimize those constraints and let the user do anything
they want by eliminating bookkeeping, organizations and declarations. That makes them a
perfect candidate for prototyping ideas.
However, performance have been a key issue in dynamic languages, while static languages have
overcome that challenge by compiler code optimizations and further optimizations by their
respective virtual machines (platforms).
This paper is geared towards defining, comparing and contrasting dynamically typed languages
to statically typed languages in their most basic traits. It will also shed light on the different
aspects of those language types that assist or hinder in maintaining software.
Data Types
A data type is an abstraction. It is the common property of a set of similar data objects. This
property is used to define a representation for these objects in a program. Objects are said to
“have” or to “be of” that type to which they belong [1].
In a statically typed language, every variable and parameter has a fixed type that is chosen by the
programmer. Thus the type of each expression can be deduced, and each operation type-checked,
at compile-time. Most high-level languages are statically typed [2].
In a dynamically typed language, only the values have fixed types. A variable or parameter has
no designated type, but may take values of different types at different times. This implies that the
operands must be type-checked immediately before performing an operation at run-time. [2]
These are the different forms of type systems:

1.1 Sound types
A sound type system is one that provides some kind of guarantee for the user. Many modern type
systems like JAVA and C# are sound; but older languages like C often do not have sound type
systems by design; their type systems are just designed to give warnings for common errors [20].

1.2 Explicit/Implicit types
Implicit / explicit types refer to the extent to which a compiler will reason about the static types
of a language. ML and Haskell have implicit types, in that no type declarations are needed. Java
and Ada have very explicit types, and one is constantly declaring the types of things [20].

1

1.2.1 Implicit type
// i is compiled as an int
var i = 5;

1.2.2 Explicit type
// i is declared as an int
Int32 i = new Int32(5);

1.3 Structural types
This distinction is generally applied to static types with sub-typing. Structural typing means a
type is assumed whenever it is possible to validly assume it. It also allows you to be a bit more
explicit about your expectations on an object.

// In scala the object f passed in this method should have the
method called getName()
def test(f: { def getName(): String }) {
log(f.getName)
}

1.4 Duck typing
If it walks like a duck and quacks like a duck, it must be a duck. This is a concept that has
become popular recently. It refers to the dynamic type analogue of structural typing in which an
object’s current set of methods and properties determines the valid semantics, rather than its
inheritance from a particular class or implementation of a specific interface [21].

//pseudo code for the calculate method
function calculate(a, b, c) => return (a+b)*c

//calculate method called with different parameters
example1 = calculate (1, 2, 3)
example2 = calculate ([1, 2, 3], [4, 5, 6], 2)
example3 = calculate ('apples ', 'and oranges', 3)

//printing the output from above
print to_string example1
9

[1, 2, 3, 4, 5, 6, 1, 2, 3, 4, 5, 6]

apples and oranges, apples and oranges, apples and oranges,

As we can see, the language outputted the correct result as long as any of the input data types
(int, string) supported the ‘+’ and ‘*’ operator.

2

Static Programming Languages
Static system languages were introduced as an alternative to assembly. In assembly languages,
virtually every aspect of the machine is reflected in the program. Each statement represents a
single machine instruction and programmers must deal with low-level details such as register
allocation and procedure calling sequences. As a result, it is difficult to write and maintain large
programs in assembly language [4]. Static languages are also known as strongly typed languages.
These are called strong because they guarantee a certain runtime behavior before running the
actual program. The compiler ensures that operands only function in a pre-destined way with the
actual operations and the data objects never changes over the object’s lifespan. They also provide
type safety. At compile or run time, the rejection of operations or function calls which attempt to
disregard data types. In a more rigorous setting, type safety is proved about a formal language by
proving progress and preservation [5]. Statically typed systems are necessarily also conservative.
They can categorically prove the absence of some bad program behaviors, but they cannot prove
their presence [9].
Dynamic Programming Languages
Dynamic programming language is a term used broadly in computer science to describe a class
of high-level programming languages that execute at runtime many common behaviors that other
languages might perform during compilation, if at all. These behaviors could include extension
of the program, by adding new code, by extending objects and definitions, or by modifying the
type system, all during program execution [6].
Dynamically typed languages support dynamic allocation of storage objects whenever they are
needed to contain an input value or the result of a computation. Identifiers are typeless in the
sense that types are not permanently attached to them. Rather, a type tag is attached to each
storage object when it is created. The storage object is then bound dynamically to an identifier.
Thus the type that is indirectly associated with an identifier may change dynamically [1].
Dynamic language opponents argue that these languages cannot scale in terms of capacity
handling, because they are “built on top of their own runtimes, which are arguably vastly inferior
to the engineering effort that goes into the garbage collection facilities found in the JVM Hotspot
or CLR implementations.” [7]
Core Differences
The following table illustrates major differences between static and dynamic languages in a
nutshell that are in production today:

Static Languages Dynamic Languages
Earlier detection of programming mistakes at Detection is delayed until runtime
compile-time
Better documentation through type signatures Documentation possible through comments
Compiler and runtime code optimizations Runtime code optimizations only
Better IDE support for a at design time IDE support limited to few well-known
developer experience, through features like languages, since it is considerably hard for IDE
Refactor, Rename, etc. to assume types at design time. [13]
Not too good for prototyping. Static typing is Well suited for prototyping due to its ad-hoc
too rigid. nature, implicit and duck typing.
Have to be compiled, deployed and forked Can usually be run from an interactive

3

using the underlying platform. command prompt, increasing productivity. [13]
Longer learning curve. Usually shorter learning curve. [13]
Languages
The following table houses few popular static and dynamic languages that are in lime light
today:

Statically Typed Languages Dynamically Typed Languages
ML, Haskell, Java, C#, C++, etc Lisp, Scheme, Php, Ruby, Postscript,
JavaScript, etc
Static to Dynamic
For illustration purposes, the following section would show the steps involved in transforming a
traditional statically typed language, Java to a modern dynamic language, Ruby. The following
method is taking an object of the class country and printing the output by calling a method on it,
called capitalCity.

private static void printCapitalOf(Country country)
{
System.out.println(country.capitalCity());
}

public static void main(String[] args)
{
Country aus = new Australia();
Country jpn = new Japan();
printCapitalOf(aus);
printCapitalOf(jpn);
}

The above could turn into a dynamically typed language, by leaving out the types, as follows:

private static void printCapitalOf(Country country)
{
System.out.println(country.capitalCity());
}

public static void main(String[] args)
{
Country aus = new Australia();
Country jpn = new Japan();
}

The same logic as above implemented in a dynamically typed language Ruby. As we can see,
duck typing is being used to assume the type of the object country:

4

def printCapitalOf(country)
{
print(country.capitalCity())
}

def aus = new Australia();
def jpn = new Japan();

Type Inference and Binding
Type inference plays a big role in language performance and security. Dynamic typing implies
that execution of the program is slowed down by implicit run-type checks, and also implies that
every value must be tagged to identify its type in order to make these type checks possible. These
time and space overheads are avoided in a statically typed language, because all type checks are
performed at compile-time. Another feature of static typing is compile time security. Type errors
are guaranteed to be detected by the compiler, rather than being left to the vagaries of testing [2].
Static binding happens when the body of a function is evaluated in the environment of the
function definition, whereas dynamic binding occurs when the function body is evaluated in the
environment of the function call. With static binding we can do this at compile-time; with
dynamic binding we must delay this until run-time [2].
Sub-typing
Static type systems can enforce higher-level modularity properties to protect the integrity of user
defined abstractions, therefore enforcing disciplined programming. Violations of information
hiding, such as directly accessing the fields of a data value whose representation is supposed to
be abstract, are caught at compile time, instead of runtime in opposed to dynamic typed
languages. In large-scale software composition, statically typed languages form the backbone of
module languages used to package and tie together the components of large systems. Structuring
larger systems in terms of modules with clear interfaces leads to a more abstract style of design,
where interfaces are designed and discussed independently from their eventual implementations.
More abstract thinking about interfaces generally leads to better design [9].
Generics
Generic programming is a style of computer programming in which algorithms are written in
terms of to-be-specified-later types that are then instantiated when needed for specific types
provided as parameters. Generic programming refers to features of certain statically typed
programming languages that allow some code to effectively circumvent the static typing
requirements. Generic programming is commonly used to implement containers such as lists and
hash tables and functions such as a particular sorting algorithm for objects specified in terms
more general than a concrete type [14].

//The following is an interface which allows the methods to work
on a type T unknown till runtime.
interface IEnumerator<T>

5

{
bool MoveNext();
T Current { get; }
}

Generic classes and methods in statically typed languages combine reusability, type safety and
efficiency in a way that dynamically typed languages cannot. By allowing types and programs to
be parameterized by types, it becomes possible to create highly reusable libraries, while
maintaining the benefits of compile-time type checking [11].
In combination with type-inference, usually writing types explicitly is unnecessary. In the
example below, the compiler infers that variable xs has type IEnumerator<string>, and hence
that variable x has type string:

var xs = {
yield return quot;Helloquot;;
yield return quot;Worldquot;;
};

foreach(x in xs)
{
Console.WriteLine(x);
}

In languages without generics a new sort function would require for any element type, and any
kind of collection. Using generics a single function that sorts arbitrary collections of arbitrary
element types void Sort<T>(...) and IComparer<T> would be enough.

void Sort<T>(IComparer<T> comparer)
{
...
}

Reflection
Reflection is the ability to find out information about objects, the application details
(assemblies), its metadata at run-time [15]. It is a special trait of statically typed languages. It is
very powerful since it is a way of collecting and manipulating information present in application
shared libraries and its metadata. Metadata contain all the Type information used by the
application. The ability to obtain information at runtime also makes it even more advantageous
[15].
It is a consensus that that the ability to dynamically eval strings as programs is what sets
dynamic languages apart from static languages. But, in reality any language that can dynamically
load class loaders in some form or another, either via DLLs, shared libraries or dynamic class
loading, has the ability to do eval, even though eval is considered a poor man’s substitute for
higher-order functions. Instead of passing around a function and call it, they pass around a string
and eval it [12].

6

Maintenance

12.1 Packages/Namespaces
Namespaces are well-defined boundaries that are used to organize code in a unique fashion.
Every statically programming language supports various forms of namespaces, be they as fine-
grained as the context of a procedure or a block, or as coarse-grained as packages or modules.
Namespaces provide a consistent way of grouping related source code together in a pre defined
fashion. This makes code cleaner, streamlined and easier to maintain. In most, if not all statically
typed languages namespaces are first-class citizens. Namespaces can be used to model objects,
classes, meta-objects, software components, modules, and a variety of compositional
abstractions, such as wrappers and mix-in layers. Furthermore, namespaces lend themselves well
to formal specification using standard semantic modeling techniques, which can form the basis
for reasoning about language constructs [22]. Dynamic languages have second class namespaces.
In languages like JavaScript, most global functions that are part of the language are in the global
namespace. These class names have to be organized in ways that there are no conflicts between
two classes of same names in two files. This type of distinction is usually done by

company_namespace_class
{
…
}

Good namespaces could aid quite a bit in development and maintenance activities. In languages
where namespaces are not available, the above technique has to be used; otherwise there is a
good possibility of method or class name confusion. Namespaces also help when reading,
understanding, restructuring or reengineering software.

12.2 Contracts
In human affairs, contracts are written between two parties when one of them performs some
task for the other. Each party expects some benefits from the contract, and accepts some
obligations in return. Contracts in object oriented languages, facilitates the concept of
inheritance, which makes software more maintainable by avoiding redundancy and sharing
structures and behaviors. Statically typed languages provide a very solid means for contracts
between elements and provide a standard way to document them [3]. A method with three
arguments, in Java for example would only and only accept the objects it is expecting in a well-
defined sequence. However, static typing could provide a false sense of safety, since it can only
prove the absence of certain errors statically at compile time. Even if a program does not contain
any static type-errors, it does not imply that you will not encounter any unwanted runtime errors.
Dynamic languages being susceptive to runtime surprises forces developers to put in place very
strict unit testing frameworks therefore eliminating any chances for run-time contract
nightmares. In a dynamic language like PHP, contracts could be loose; depending on how a
method is written, it could accept a combination of parameters based on their default values in
the method. The same method could have multiple contracts, therefore unit tests should be
written for each type of method usage.

7

12.3 New Requirements Testing
Dynamic languages could be more productive and easier to use than static languages. However,
making code easier to write does not necessarily yield long term gains. In bigger projects, the
lack of language formality can be detrimental to the maintenance bottom line. That includes
adding new features to the system. Unit testing helps but they are a form of sampling and as
such, they tend to suffer from selection bias. Static languages, while limited in what they can
accomplish right off the bat, have a 100% success rate for what is type checked and covered.
Unit tests on the other hand have a failure rate due to limited input/output/state coverage and
should not be considered as a replacement for basic error checking but as a supplement to it.
New features are far easier to add in dynamic languages than static, however both paradigms
need strict and well to do unit tests to verify and validate the new features/requirements. The
type of issues that should be cared for while testing dynamic languages are:

• Order of tests in case of interpreters since they interpret code line by line
• Tests cannot be run in parallel due to global state variables and their sharing
• New tests can break old tests by changing global state variables

Even though in static languages like Java, method definitions could be replaced at runtime using
a Class Loaders and Aspect Oriented Programming frameworks; this is not how Java is used in
the real world and therefore there are not many unknown cases that have to be brought into
perspective when unit testing while adding new features. Usually unit tests that cover 90% or
more validate the design.

12.4 Refactoring
Refactoring is a disciplined technique for restructuring an existing body of code, altering its
internal structure without changing its external behavior. Its heart is a series of small behavior
preserving transformations. Each transformation (called a ‘refactoring’) does little, but a
sequence of transformations can produce a significant restructuring. Since each refactoring is
small, it’s less likely to go wrong. The system is also kept fully working after each small
refactoring, reducing the chances that a system can get seriously broken during the restructuring
[10].
Refactoring is usually aided by very sophisticated editors. Few of them are eclipse and IntelliJ.
Static typing helps these editors navigate between modules. A well-factored, well-tested
application spreads each feature over several layers and unites them all by type. These editors
can easily bounce between related tests, views, controllers, and models, simply by tracking the
types they use. Dynamic languages however, don’t have a notion of types at development time.
Hence, any IDE would have a hard time navigating through code. Here are few ways that
dynamic languages could be modeled for refactoring. Using PHP interpreter and running the
code [18]. In order to find all occurrences of a function, for example few work-around have been
proposed like renaming the original function name and create a function with the old name that
adds the caller to a list and then modifying the callers to call the renamed functions. At the end
delete the function with the old name. Refactoring of dynamic languages depend on a 100%
coverage test suite so each and every possible path in the program’s flow could be covered.

8

12.5 Reengineering
Reengineering software is defined as “reorganizing and modifying existing software system(s) to
make them more maintainable by re-structuring or re-writing part or all of a legacy system
without changing its functionality.” [17] It is applicable where few or all of the components or
modules of a larger system require frequent maintenance. Reengineering plays a big role in
adaptive, perfective and preventive change. In order to implement a new version of a software
system, it is crucial to obtain its architecture and design if not already present. This information
is required for the identification of all the entities that have some relation with the evolving part
of the software. In addition, we need it for providing new source code that will fit in the existing
system. Recovering the design of an application has to be done by using both static and dynamic
information. Static information describes the structure of the software as it is written in the
source code, while dynamic information describes what is really happening at runtime. Statically
typed languages provide a very comprehensive set of static information, while dynamically typed
languages do not reveal much at development time. Therefore, it could be possible that structural
information would show that two classes are just a bit related, as there could only be one method
call from one class to the other. However, it dynamic information could show that the same call
occurs continuously when running the application, making the two classes very related.

12.6 Reuse
Reusability is the likelihood a segment of source code that can be used again to add new
functionalities with slight or no modification. Reusable modules and classes reduce
implementation time, increase the likelihood that prior testing and use has eliminated bugs and
localizes code modifications when a change in implementation is required. Martin Fowler says:
“Any fool can write code that a computer can understand. Good programmers write code that
humans can understand.” However, for software to be reusable, it must be usable in a variety of
contexts. An important attribute of reusability at the code level is genericity. Generic software
can operate, unmodified, on a variety of object types. Dynamically typed languages provide
genericity naturally:

//Python function that determines the smallest of whatever it
receives as a parameter
def smallest(stuff):
assert len(stuff) > 0
theMin = stuff[0]
for x in stuff[1:]:
if x < theMin: theMin = x
return theMin

This function can be called with any type of sequence:

smallest([1,2,3])
1
smallest(quot;cbaquot;)
a

9

The only constraints on the parameter stuff are that it is an iterable entity and that its contained
objects support the less than operator [16]. Hence, smallest is a generic function and is very
easily reusable in variety of applications. Statically typed languages cannot have such flexibility
out of the box [16], but that is changing. Modern languages such as Java and C# now have
generic programming capability while retaining the safety and efficiency that comes with static
type checking.

12.7 Documentation
Statically typed languages could prove to be easier when reading programs. Because
documentation is not just about comments. It is about everything that helps people understand
software. Static type systems build ideas that help explain a system and what it does. They
capture information about the inputs and outputs of various functions and modules. The type
declarations in procedure headers and module interfaces constitute a form of documentation,
giving useful hints about behavior. Moreover, unlike descriptions embedded in comments (in
dynamically typed languages), this form of documentation cannot become outdated, since it is
checked during every run of the compiler. This role of types is particularly important in module
signatures [9].
This is exactly the set of information needed in documentation. Clearly, if all of this information
is written in comments, there is a pretty good chance it will eventually become out of date. If this
information is written in identifier names, it will be nearly impossible to fit it all in. Type
information is a very nice place to keep this information.
After all it is better to have self-documenting code than code that needs a lot of comments. Most
languages with static type systems have type inference, which is directly analogous to self-
documenting code. Information about the correct way to use a piece of code is extracted from the
code itself, but then verified and presented in a convenient format. It is this type of
documentation that doesn’t need to be maintained or even written, but is available on demand
even without reading the source code.
Language Selection
There is no universally superior language, but language selection has long term implications
including those of business capability, cost and technology lock-in. So how should a team choose
a language for its next “big” project? According to Dhananjay Nene [19], these are the
dimensions of selection of a programming language:

13.1 Capability
What the languages can and cannot do?

13.2 Productivity
How efficiently can one write programs using the language?

13.3 Costs
What are the costs of using the language?

13.4 Expectations
Can the language deliver on expectations? What is the cost of delivering on expectations?

13.5 Development

10

How long does it take to write and debug code? If skills are not present, what is the cost and
time required to build them?

13.6 Support
What is the support structure available from community?

13.7 Deployment
What are the hardware and deployment costs?

13.8 Performance
How fast can the programs run for given hardware?

13.9 Scalability
How cost effectively can the software be scaled to handle higher loads?

13.10 Reliability
How fault tolerant can the resultant software be?

13.11 Hardware
Ease of cloud/virtualized hosting; hosting requirements for small vs. medium vs. big apps.

13.12 Ramp- Up Time
How easily can you get online?

As things stand, today’s programmer has a wide range of languages to choose from but none of
them is perfect for every job. However, a programmer who has a knowledge of static (usually for
back-end) and dynamic languages (usually for front-end) probably does not need anything
beyond those tools. The following is the breakdown of languages currently being part of the
O’Reilly’s code zoo, [24] which is one view point of various languages being in use today. As
we can see, dynamic languages like Python, PHP, Ruby, and Perl seem to have taken down
almost 50% of the pie chart with C, C# and C++ taking down a large majority of the rest. It is
also interesting to note that Java, a major language is missing from this pie chart.

11

Conclusion
Maintenance is an ongoing activity in the world of software. Therefore, a lot of effort should go
into choosing the right languages and tools for a new software application. The languages and
tools usually stay with the application for its entire lifetime. The creators of the application
usually leave the project after development due to what I call software maintenance syndrome.
Maintenance programmers could then be overwhelmed by the complexity of the source code.
After a number of modifications, design documents could be outdated or non-existent. They just
have to do it hoping the bugs disappear before the deadline. Despite of the fact that maintenance
requires experience and skills, novice programmers are often assigned to this time-consuming
task, making the situation worse.
In many ways, we are still in the dark ages of programming language design. Consider, for
example, the great innovations in programming languages over the past fifty years. To a large
extent, most of these innovations were achieved in the 1950s and 1960s. It is harder and harder
to identify significant contributions over the past 20 years. It is also hard to identify truly radical
language designs in recent years [23]. The software industry is faced with new challenges posed

12

by enormous advances in hardware and internet technology. Silicon chips cannot go up in
performance and clock cycle anymore; we therefore need language features like inherit
concurrency and multi threading. The truth is there is no silver bullet; if I want to drive on the
race track, my regular car wouldn’t fit the profile, but a good performance car with special
suspension, brakes and tires would, in which case I should be ready to pay the price for constant
barrage of new tires and brake pads.

13

References
[1] Alice E. Fischer, Frances S. Grodzinsky. “The Anatomy of Programming Languages”.
Prentice Hall. January 1993.
[2] Watt, David. “Programming Language Concepts and Paradigms”. Prentice Hall. May 1990.
[3] Building bug-free O-O software: An introduction to Design by Contract(TM).
http://archive.eiffel.com/doc/manuals/technology/contract/page.html
[4] Ousterhout , John.“Scripting: Higher Level Programming for the 21st Century”. Sun
Microsystems Laboratories.
[5] http://en.wikipedia.org/wiki/Strongly-
typed_programming_language#Meanings_in_computer_literature
[6] http://en.wikipedia.org/wiki/Dynamic_programming_language
[7] http://sadekdrobi.com/2008/02/09/scalability-dynamic-and-static-programming-languages/
[8] Erik Meijer, Peter Drayton. “Static Typing Where Possible, Dynamic Typing When Needed:
The End of the Cold War Between Programming Languages”. Microsoft Corporation.
[9] Pierce, Benjamin. “Types and Programming Languages”. The MIT Press.2002
[10] Fowler, Martin. http://www.refactoring.com
[11] D. A. Schmidt. quot;The Structure of Typed Programming Languagesquot;. MIT Press. 1994.
[12] D. Ungar and R. B. Smith. “Self: The Power of Simplicity”. In Proceedings OOPSLA’87.
1987.
[13] Visual Numerics, Inc. “Components for Analytic Prototyping and Production Deployment”.
February 2009
[14] http://en.wikipedia.org/wiki/Generic_programming
[15] Code Source. http://www.codersource.net/published/view/291/reflection_in.aspx
[16] Allison, Chuck. “Designing Reusable Software”. StickyMinds.
[17] Sommerville,Ian. “Software Engineering”. Addison Wesley; 6 edition. August 21, 2000.
[18] Don Roberts, John Brant, Ralph Johnson. “A Refactoring Tool for Smalltalk”.
[19] Nene, Dhananjay. “Programming Language Selection”. A PuneTech event. March 28, 2009.
[20] Smith, Chris. http://www.pphsg.org/cdsmith/types.html.
[21] http://en.wikipedia.org/wiki/Duck_typing
[22] Oscar Nierstrasz, Alexandre Bergel, Marcus Denker, St´ephane Ducasse, Markus G¨alli, and
Roel Wuyts. “On the Revival of Dynamic Languages”. Software Composition Group, University
of Bern.
[23] Black, Greg. “Programming Language Selection”.
[24] http://lesscode.org/2005/08/04/code-zoo-language-breakdown/

14

Maintenance of Dynamically vs. Statically typed Languages

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (16)

Similar a Maintenance of Dynamically vs. Statically typed Languages

Similar a Maintenance of Dynamically vs. Statically typed Languages (20)

Más de Amin Bandeali

Más de Amin Bandeali (11)

Último

Último (20)

Maintenance of Dynamically vs. Statically typed Languages