Structured Programming

Course code: CSC 409

Credit Units: 3
Lecturers/Course coordinator Dr. E. O. Oyekanmi
Office: Computer Science Department
Phone: 08036427123
Email: [email protected]
Class Hours: (Monday, from 8.00 am to 10.00 am)
Office Hours: M, T, W, Th (from 2.00 pm to 4.00 pm)
Online Hours: M, T, W, Th, F, Sa (from 6.00 pm to 8.00 pm)
Course Description
There are several programming languages before now, however not all of them are
structured. The purpose of the structured ones are:
 improve programme dependability and programmers' understanding.
Three hows of programming:
 how to develop the solution to a given problem,
 how to organise a programme, and
 how to effectively use the standard techniques that represent the "tricks" of the
programming trade.
Three basic building blocks of structured programming
 Sequential, conditional, and repeating structured codes which are the are discussed in
details.
 These three components replace the need for GO TO commands to control the flow of
a programme.
Overall, this course will ensure that a programmer has greater confidence on a developed software code in
terms of simplicity to grasp and reduction of logical errors, because the programme is built of highly
independent modules.
Course Objectives
At the end of this course, students should be able to:
 explain the rationale behind structured programming paradigms.
 differentiate among three main approaches for writing a computer program
 compare and contrast between structured programming and procedural
coding.
 Interpret programming language with built-in structured programming styles
 implement programming methodology.
 Design language construct using C++.
 describe discipline of programming.
 demonstrate the use of structure programming in database.
Unit 4: Comparative study of programming paradigm

In this unit you will understand the following topics

 3.5. Functional Programming History.

 3.6. Reflective programming paradigm.
 3.7. Scripting programming.
 3.8. Aspect-Oriented programming.
Learning Objectives
 Learn about different programming paradigms
 Concepts and particularities
 Advantages and drawbacks
 Application domains

Comparative Study of Programming

Languages 5
Introduction
 A programming paradigm is a fundamental style of computer programming.
 Compare with a software development methodology, which is a style of solving
specific software engineering problems.
 Different methodologies are more suitable for solving certain kinds of problems or
applications domains.
 Same for programming languages and paradigms.
 Programming paradigms differ in:
 the concepts and abstractions used to represent the elements of a program (such
as objects, functions, variables, constraints, etc.)
 the steps that compose a computation (assignation, evaluation, data flow, control
flow, etc.).
Comparative Study of Programming
Languages 6
7
Programming
paradigms (Cont’d)

Comparative Study of
Programming Languages
 Functional
8
programming
paradigm

Comparative Study of
Programming Languages
Functional Programming
 Functional programming is a programming paradigm that treats computation as the evaluation
of mathematical functions and avoids state changes and mutable data.

 It emphasizes the application of functions, in contrast to the imperative programming style,

which emphasizes changes in state.

 Programs written using the functional programming paradigm are much more easily
representable using mathematical concepts, and thus it is much more easy to mathematically
reason about functional programs than it is to reason about programs written in any other
paradigm.

Comparative Study of Programming

Languages 9
 Functional Programming:
History

 Functional programming has its roots in the lambda calculus, a formal system developed in
the 1930s to investigate function definition, function application, and recursion. Many functional
programming languages can be viewed as elaborations on the lambda calculus.

 LISP was the first operational functional programming language.

 Up to this day, functional programming has not been very popular except for a restricted number
of application areas, such as artificial intelligence.

 John Backus presented the FP programming language in his 1977 Turing Award lecture "Can
Programming Be Liberated From the von Neumann Style? A Functional Style and its Algebra of
Programs".
Comparative Study of Programming
Languages 10
Functional Programming:
History
 In the 1970s the ML programming language was created by Robin Milner at the University of
Edinburgh, and David Turner developed initially the language SASL at the University of St. Andrews
and later the language Miranda at the University of Kent.

 ML eventually developed into several dialects, the most common of which are now Objective Caml,
Standard ML, and F#.

 Also in the 1970s, the development of the Scheme programming language (a partly-functional dialect
of Lisp), as described in the influential "Lambda Papers” and the 1985 textbook "Structure and
Interpretation of Computer Programs”, brought awareness of the power of functional programming to
the wider programming-languages community.

 The Haskell programming language was released in the late 1980s in an attempt to gather together
many ideas in functional programming research.
Comparative Study of Programming
Languages 11
Functional Programming
 Functional programming languages, especially purely functional ones, have largely been emphasized
in academia rather than in commercial software development.

 However, prominent functional programming languages such as Scheme, Erlang, Objective Caml,
and Haskell have been used in industrial and commercial applications by a wide variety of
organizations.

 Functional programming also finds use in industry through domain-specific programming languages
like R (statistics), Mathematica (symbolic math), J and K (financial analysis), F# in Microsoft .NET
and XSLT (XML).

 Widespread declarative domain-specific languages like SQL and Lex/Yacc, use some elements of
functional programming, especially in eschewing mutable values. Spreadsheets can also be viewed
as functional programming languages.
Comparative Study of Programming
Languages 12
Functional Programming
 In practice, the difference between a mathematical function and the notion of a "function" used
in imperative programming is that imperative functions can have side effects, changing the
value of already calculated variables.

 Because of this they lack referential transparency, i.e. the same language expression can
result in different values at different times depending on the state of the executing program.

 Conversely, in functional code, the output value of a function depends only on the arguments
that are input to the function, so calling a function f twice with the same value for an argument x
will produce the same result f(x) both times.

 Eliminating side-effects can make it much easier to understand and predict the behavior of a
program, which is one of the key motivations for the development of functional programming.
Comparative Study of Programming
Languages 13
Functional Programming:
Higher-Order Functions
 Most functional programming languages use higher-order functions, which are functions that can
either take other functions as arguments or return functions as results.

 The differential operator d/dx that produces the derivative of a function f is an example of this in
calculus.

 Higher-order functions are closely related to functions as first-class citizen, in that higher-order
functions and first-class functions both allow functions as arguments and results of other functions.

 The distinction between the two is subtle: "higher-order" describes a mathematical concept of
functions that operate on other functions, while "first-class" is a computer science term that describes
programming language entities that have no restriction on their use (thus first-class functions can
appear anywhere in the program that other first-class entities like numbers can, including as
arguments to other functions and as their return values).
Comparative Study of Programming
Languages 14
Functional Programming:
Pure Functions
 Purely functional functions (or expressions) have no memory or side effects. They represent a
function whose valuation depends only on the value of the parameters they are given. This
means that pure functions have several useful properties, many of which can be used to
optimize the code:

 If the result of a pure expression is not used, it can be removed without affecting other expressions.

 If a pure function is called with parameters that cause no side-effects, the result is constant with respect to that
parameter list (referential transparency), i.e. if the pure function is again called with the same parameters, the same
result will be returned (this can enable caching optimizations).

 If there is no data dependency between two pure expressions, then they can be evaluated in any order, or they can be
performed in parallel and they cannot interfere with one another (in other terms, the evaluation of any pure
expression is thread-safe and enables parallel execution).

Comparative Study of Programming

Languages 15
Functional Programming:
Pure Functions
 If the entire language does not allow side-effects, then any evaluation strategy can be used; this gives the
compiler freedom to reorder or combine the evaluation of expressions in a program. This allows for much
more freedom in optimizing the evaluation.

 The notion of pure function is central to code optimization in compilers, even for procedural programming
languages.

 While most compilers for imperative programming languages can detect pure functions, and perform
common-subexpression elimination for pure function calls, they cannot always do this for pre-compiled
libraries, which generally do not expose this information, thus preventing optimizations that involve those
external functions.

 Some compilers, such as gcc, add extra keywords for a programmer to explicitly mark external functions as
pure, to enable such optimizations. Fortran 95 allows functions to be designated "pure" in order to allow such
optimizations.
Comparative Study of Programming
Languages 16
 Functional Programming:
Recursion
 Iteration in functional languages is usually accomplished via recursion.

 Recursion may require maintaining a stack, and thus may lead to inefficient memory consumption, but tail recursion can
be recognized and optimized by a compiler into the same code used to implement iteration in imperative languages.

 The Scheme programming language standard requires implementations to recognize and optimize tail recursion.

 Tail recursion optimization can be implemented by transforming the program into continuation passing style during
compilation, among other approaches.

 Common patterns of recursion can be factored out using higher order functions, catamorphisms and anamorphisms, which
"folds" and "unfolds" a recursive function call nest.

 Using such advanced techniques, recursion can be implemented in an efficient manner in functional programming
languages.

Comparative Study of Programming

Languages 17
Functional Programming:
Eager vs. Lazy Evaluation
 Functional languages can be categorized by whether they use strict (eager) or non-strict (lazy) evaluation,
concepts that refer to how function arguments are processed when an expression is being evaluated.
Under strict evaluation, the evaluation of any term containing a failing subterm will itself fail. For example,
the expression
print length([2+1, 3*2, 1/0, 5-4])

 will fail under eager evaluation because of the division by zero in the third element of the list. Under lazy
evaluation, the length function will return the value 4 (the length of the list), since evaluating it will not
attempt to evaluate the terms making up the list.

 Eager evaluation fully evaluates function arguments before invoking the function. Lazy evaluation does not
evaluate function arguments unless their values are required to evaluate the function call itself.

 The usual implementation strategy for lazy evaluation in functional languages is graph reduction. Lazy
evaluation is used by default in several pure functional languages, including Miranda, Clean and Haskell.
Comparative Study of Programming
Languages 18
Functional Programming:
Type Inference
 Especially since the development of Hindley–Milner type inference in the 1970s, functional
programming languages have tended to use typed lambda calculus, as opposed to the untyped
lambda calculus used in Lisp and its variants (such as Scheme).

 Type inference, or implicit typing, refers to the ability to deduce automatically the type of the values
manipulated by a program. It is a feature present in some strongly statically typed languages.

 The presence of strong compile-time type checking makes programs more reliable, while type
inference frees the programmer from the need to manually declare types to the compiler.

 Type inference is often characteristic of — but not limited to — functional programming languages
in general. Many imperative programming languages have adopted type inference in order to
improve type safety.
Comparative Study of Programming
Languages 19
 Functional Programming:
In Non-functional Languages
 It is possible to employ a functional style of programming in languages that are not traditionally considered
functional languages.

 Some non-functional languages have borrowed features such as higher-order functions, and list
comprehensions from functional programming languages. This makes it easier to adopt a functional style when
using these languages.

 Functional constructs such as higher-order functions and lazy lists can be obtained in C++ via libraries, such as in
FC++.

 In C, function pointers can be used to get some of the effects of higher-order functions.

 Many object-oriented design patterns are expressible in functional programming terms: for example, the Strategy
pattern dictates use of a higher-order function, and the Visitor pattern roughly corresponds to a catamorphism, or
fold.
Comparative Study of Programming
Languages 20
 REflective
21
programming
paradigm

Comparative Study of
Joey Paquet, 2010-2014
Programming Languages
Reflective Programming
 Reflection is the process by which a computer program can observe and modify its own
structure and behavior at runtime.
 In most computer architectures, program instructions are stored as data - hence the distinction
between instruction and data is merely a matter of how the information is treated by the
computer and programming language.
 Normally, instructions are executed and data is processed; however, in some languages,
programs can also treat instructions as data and therefore make reflective modifications.
 Reflection is most commonly used in high-level virtual machine programming languages like
Smalltalk and scripting languages, and less commonly used in manifestly typed and/or statically
typed programming languages such as Java, C, ML or Haskell.

Comparative Study of Programming

Languages 22
Reflective Programming
 Reflection-oriented programming includes self-examination, self-modification, and self-replication.

 Ultimately, reflection-oriented paradigm aims at dynamic program modification, which can be

determined and executed at runtime.

 Some imperative approaches, such as procedural and object-oriented programming paradigms, specify
that there is an exact predetermined sequence of operations with which to process data.

 The reflection-oriented programming paradigm, however, adds that program instructions can be
modified dynamically at runtime and invoked in their modified state.

 That is, the program architecture itself can be decided at runtime based upon the data, services, and
specific operations that are applicable at runtime.
Comparative Study of Programming
Languages 23
Reflective Programming
 Reflection can be used for observing and/or modifying program execution at runtime. A reflection-oriented program
component can monitor the execution of an enclosure of code and can modify itself according to a desired goal
related to that enclosure. This is typically accomplished by dynamically assigning program code at runtime.

 Reflection can thus be used to adapt a given program to different situations dynamically.

 Reflection-oriented programming almost always requires additional knowledge, framework, relational mapping, and
object relevance in order to take advantage of this much more generic code execution mode.

 It thus requires the translation process to retain in the executable code much of the higher-level information present
in the source code, thus leading to more bloated executables.

 However, in cases where the language is interpreted, much of this information is already kept for the interpreter to
function, so not much overhead is required in these cases.
Comparative Study of Programming
Languages 24
Reflective Programming
 A language supporting reflection provides a number of features available at runtime that would
otherwise be very obscure or impossible to accomplish in a lower-level language. Some of
these features are the abilities to:

 Discover and modify source code constructions (such as code blocks, classes, methods, protocols, etc.) as a first-
class object at runtime.

 Convert a string matching the symbolic name of a class or function into a reference to or invocation of that class or
function.

 Evaluate a string as if it were a source code statement at runtime.

Comparative Study of Programming

Languages 25
Reflective Programming
 Compiled languages rely on their runtime system to provide information about the source code.

 A compiled Objective-C executable, for example, records the names of all methods in a block
of the executable, providing a table to correspond these with the underlying methods (or
selectors for these methods) compiled into the program.

 In a compiled language that supports runtime creation of functions, such as Common Lisp, the
runtime environment must include a compiler or an interpreter.

 Programming languages that support reflection typically include dynamically typed languages
such as Smalltalk; scripting languages such as Perl, PHP, Python, VBScript, and JavaScript.

Comparative Study of Programming

Languages 26
 Scripting
27
programming
paradigm

Comparative Study of
Programming Languages
Scripting Languages
 A scripting language, historically, was a language that allowed control of software applications.

 "Scripts" are distinct from the core code of the application, as they are usually written in a different language and
are often created by the end-user.

 Scripts are most often interpreted from source code, whereas application software is typically first compiled to a
native machine code or to an intermediate code.

 Early mainframe computers (in the 1950s) were non-interactive and instead used batch processing. IBM's Job
Control Language (JCL) is the archetype of scripting language used to control batch processing.

 The first interactive operating systems shells were developed in the 1960s to enable remote operation of the
first time-sharing systems, and these used shell scripts, which controlled running computer programs within a
computer program, the shell.
Comparative Study of Programming
Languages 28
Scripting Languages
 Historically, there was a clear distinction between "real" high speed programs written in compiled
languages such as C, and simple, slow scripts written in interpreted languages such as Bourne Shell or
Awk.

 But as technology improved, the performance differences shrank and interpreted languages like Java,
Lisp, Perl and Python emerged and gained in popularity to the point where they are considered general-
purpose programming languages and not just languages that "drive" an interpreter.

 The Common Gateway Interface allowed scripting languages to control web servers, and thus
communicate over the web. Scripting languages that made use of CGI early in the evolution of the Web
include Perl, ASP, and PHP.

 Modern web browsers typically provide a language for writing extensions to the browser itself, and several
standard embedded languages for controlling the browser, including JavaScript and CSS, or ActionScript.
Comparative Study of Programming
Languages 29
Scripting Languages:
Types of Scripting Languages
 Job control languages and shells

 A major class of scripting languages has grown out of the automation of job control, which relates to
starting and controlling the behavior of system programs. (In this sense, one might think of shells as
being descendants of IBM's JCL, or Job Control Language, which was used for exactly this purpose.)

 Many of these languages' interpreters double as command-line interpreters such as the Unix shell or the
MS-DOS COMMAND.

 Others, such as AppleScript offer the use of English-like commands to build scripts. This combined with
Mac OS X's Cocoa framework allows user to build entire applications using AppleScript & Cocoa objects.

Comparative Study of Programming

Languages 30
Scripting Languages:
Types of Scripting Languages
 GUI scripting

 With the advent of graphical user interfaces a specialized kind of scripting language emerged for
controlling a computer. These languages interact with the same graphic windows, menus, buttons, and
so on that a system generates.

 They do this by simulating the actions of a human user. These languages are typically used to automate
user actions or configure a standard state. Such languages are also called "macros" when control is
through simulated key presses or mouse clicks.

 They can be used to automate the execution of complex tasks in GUI-controlled applications.

Comparative Study of Programming

Languages 31
Scripting Languages:
Types of Scripting Languages
 Application-specific scripting languages

 Many large application programs include an idiomatic scripting language tailored to the needs of the application user.

 Likewise, many computer game systems use a custom scripting language to express the game components’
programmed actions.

 Languages of this sort are designed for a single application; and, while they may superficially resemble a specific
general-purpose language (e.g. QuakeC, modeled after C), they have custom features that distinguish them.

 Emacs Lisp, a dialect of Lisp, contains many special features that make it useful for extending the editing functions of
the Emacs text editor.

 An application-specific scripting language can be viewed as a domain-specific programming language specialized to a

single application.
Comparative Study of Programming
Languages 32
Scripting Languages:
Types of Scripting Languages
 Web scripting languages (server-side, client-side)

 A host of special-purpose languages has developed to control web browsers’ operation. These include JavaScript,
VBScript (Microsoft - Explorer), XUL (Mozilla – Firefox), and XSLT, a presentation language that transforms XML
content.

 Client-side scripting generally refers to the class of computer programs on the web that are executed by the user's web
browser, instead of server-side (on the web server). This type of computer programming is an important part of the
Dynamic HTML (DHTML) concept, enabling web pages to be scripted; that is, to have different and changing content
depending on user input, environmental conditions (such as the time of day), or other variables.

 Web authors write client-side scripts in languages such as JavaScript (Client-side JavaScript) and VBScript.

 Techniques involving the combination of XML and JavaScript scripting to improve the user's impression of
responsiveness have become significant enough to acquire a name, such as AJAX.
Comparative Study of Programming
Languages 33
Scripting Languages:
Types of Scripting Languages

 Client-side scripts are often embedded within an HTML document (hence known as an "embedded script"), but they
may also be contained in a separate file, which is referenced by the document that use it (hence known as an "external
script").

 Upon request, the necessary files are sent to the user's computer by the web server on which they reside. The user's
web browser executes the script using an embedded interpreter, then displays the document, including any visible
output from the script. Client-side scripts may also contain instructions for the browser to follow in response to certain
user actions, (e.g., clicking a button). Often, these instructions can be followed without further communication with the
server.

 In contrast, server-side scripts, written in languages such as Perl, PHP, and server-side VBScript, are executed by the
web server when the user requests a document. They produce output in a format understandable by web browsers
(usually HTML), which is then sent to the user's computer. Documents produced by server-side scripts may, in turn,
contain or refer to client-side scripts.

Comparative Study of Programming

Languages 34
Scripting Languages:
Types of Scripting Languages

 Client-side scripts have greater access to the information and functions available on the user's browser, whereas
server-side scripts have greater access to the information and functions available on the server.

 Server-side scripts require that their language's interpreter be installed on the server, and produce the same
output regardless of the client's browser, operating system, or other system details.

 Client-side scripts do not require additional software on the server (making them popular with authors who lack
administrative access to their servers). However, they do require that the user's web browser understands the
scripting language in which they are written. It is therefore impractical for an author to write scripts in a language that
is not supported by popular web browsers.

 Unfortunately, even languages that are supported by a wide variety of browsers may not be implemented in precisely
the same way across all browsers and operating systems.

Comparative Study of Programming

Languages 35
 Aspect-oriented
36
programming
paradigm

Comparative Study of
Programming Languages
Aspect-Oriented
Programming
• Aspect-oriented programming entails breaking down program logic into distinct parts (so-called
concerns or cohesive areas of functionality).

• It aims to increase modularity by allowing the separation of cross-cutting concerns, forming

a basis for aspect-oriented software development.

• AOP includes programming methods and tools that support the modularization of concerns at
the level of the source code, while "aspect-oriented software development" refers to a whole
engineering discipline.

Comparative Study of Programming

Languages 37
Aspect-Oriented
Programming
 All programming paradigms support some level of grouping and encapsulation of concerns into
separate, independent entities by providing abstractions (e.g., procedures, modules, classes,
methods) that can be used for implementing, abstracting and composing these concerns.

 But some concerns defy these forms of implementation and are called cross-cutting concerns
because they "cut across" multiple abstractions in a program.

 Logging exemplifies a crosscutting concern because a logging strategy necessarily affects

every logged part of the system. Logging thereby crosscuts all logged subsystems and
modules, and thus many of their classes and methods.

Comparative Study of Programming

Languages 38
Aspect-Oriented
Programming: Terminology
 Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they
often share common, secondary requirements with other classes. For example, we may want to add logging to
classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits specific
methods. Even though each class has a very different primary functionality, the code needed to perform the
secondary (e.g. logging) functionality is often identical.

 Advice: This is the additional code that you want to apply to your existing model. In our example, this is the
logging code that we want to apply whenever the thread enters or exits a specific method.

 Pointcut: This is the term given to the point of execution in the application at which the cross-cutting concern
needs to be applied. In our example, a pointcut is reached when the thread enters a specific method, and another
pointcut is reached when the thread exits the method.

 Aspect: The combination of the pointcut and the advice is termed an aspect. In the example above, we add a
logging aspect to our application by defining a correct advice that defines how the cross-cutting concern is to be
implemented, and a pointcut that defines where in the base code the advice is to be injected.
Comparative Study of Programming
Languages 39
Aspect-Oriented
Programming
 To sum-up, an aspect can alter the behavior of the base code (the non-aspect part of a
program) by applying advice (additional behavior) at various joint points (points in a program)
specified in a quantification or query called a pointcut (that detects whether a given join point
matches).

 An aspect can also make binary-compatible structural changes to other classes, like adding
members or parents.

 The aspects can potentially be applied to different programs, provided that the pointcuts are
applicable.

Comparative Study of Programming

Languages 40
Aspect-Oriented Programming:
Implementation
 Most implementations produce programs through a process known as weaving - a special case
of program transformation.

 An aspect weaver reads the aspect-oriented code and generates appropriate object-oriented
code with the aspects integrated.

 AOP programs can affect other programs in two different ways, depending on the underlying
languages and environments:

1. a combined program is produced, valid in the original language and indistinguishable from an ordinary program to
the ultimate interpreter
2. the ultimate interpreter or environment is updated to understand and implement AOP features.

Comparative Study of Programming

Languages 41
Aspect-Oriented
Programming

Compilation process

Weaving processComparative Study of Programming

Languages 42
Aspect-Oriented
Programming
base code

aspect code

woven code

Comparative Study of Programming

Languages 43
Aspect-Oriented
Programming: History
 AOP as such has a number of antecedents: the Visitor Design Pattern, CLOS MOP (Common
Lisp Object System’s MetaObject Protocol).

 Gregor Kiczales and colleagues at Xerox PARC developed AspectJ (perhaps the most popular
general-purpose AOP package) and made it available in 2001.

Comparative Study of Programming

Languages 44
Aspect-Oriented
Programming: Motivation
 Typically, an aspect is scattered or tangled as code, making it harder to understand and
maintain.

 It is scattered by virtue of its code (such as logging) being spread over a number of unrelated
functions that might use it, possibly in entirely unrelated systems, different source languages,
etc.

 That means to change logging can require modifying all affected modules. Aspects become
tangled not only with the mainline function of the systems in which they are expressed but also
with each other.

 That means changing one concern entails understanding all the tangled concerns or having
some means by which the effect of changes can be inferred.
Comparative Study of Programming
Languages 45
Aspect-Oriented Programming:
Join Point Model
 The advice-related component of an aspect-oriented language defines a join point model (JPM).
A JPM defines three things:

 When the advice can run. These are called join points because they are points in a running program where additional
behavior can be usefully joined. A join point needs to be addressable and understandable by an ordinary programmer
to be useful. It should also be stable across inconsequential program changes in order for an aspect to be stable
across such changes. Many AOP implementations support method executions and field references as join points.
 A way to specify (or quantify) join points, called pointcuts. Pointcuts determine whether a given join point matches.
Most useful pointcut languages use a syntax like the base language (for example, AspectJ uses Java signatures) and
allow reuse through naming and combination.
 A means of specifying code to run at a join point. AspectJ calls this advice, and can run it before, after, and around join
points. Some implementations also support things like defining a method in an aspect on another class.

 Join-point models can be compared based on the join points exposed, how join points are
specified, the operations permitted at the join points, and the structural enhancements that can
be expressed.
Comparative Study of Programming
Languages 46
Aspect-Oriented Programming:
Implementation
 Java's well-defined binary form enables bytecode weavers to work with any Java program
in .class-file form. Bytecode weavers can be deployed during the build process or, if the weave
model is per-class, during class loading.

 AspectJ started with source-level weaving in 2001, delivered a per-class bytecode weaver in
2002, and offered advanced load-time support after the integration of AspectWerkz in 2005.

 Deploy-time weaving offers another approach. This basically implies post-processing, but rather
than patching the generated code, this weaving approach subclasses existing classes so that
the modifications are introduced by method-overriding. The existing classes remain untouched,
even at runtime, and all existing tools (debuggers, profilers, etc.) can be used during
development.

Comparative Study of Programming

Joey Paquet, 2010-2014
Languages 47
Aspect-Oriented
Programming: Problems
 Programmers need to be able to read code and understand what is happening in order to prevent errors.

 Even with proper education, understanding crosscutting concerns can be difficult without proper support for
visualizing both static structure and the dynamic flow of a program. Starting in 2010, IDEs such as Eclipse
have begun to support the visualizing of crosscutting concerns, as well as aspect code assist and
refactoring.
 Given the intrusive power of AOP weaving, if a programmer makes a logical mistake in expressing
crosscutting, it can lead to widespread program failure.
 Conversely, another programmer may change the join points in a program – e.g., by renaming or moving
methods – in ways that the aspect writer did not anticipate, with unintended consequences.
 One advantage of modularizing crosscutting concerns is enabling one programmer to affect the entire
system easily; as a result, such problems present as a conflict over responsibility between two or more
developers for a given failure.
 However, the solution for these problems can be much easier in the presence of AOP, since only the aspect
need be changed, whereas the corresponding problems without AOP can be much more spread out.

Comparative Study of Programming

Languages 48
Aspect-Oriented Programming:
Implementations
 The following programming languages have implemented AOP, within the language, or as an
external library:
 C / C++ / C#, COBOL, Objective-C frameworks, ColdFusion, Common Lisp, Delphi, Haskell, Java, JavaScript, ML,
PHP, Scheme, Perl, Prolog, Python, Ruby, Squeak Smalltalk and XML.

Comparative Study of Programming

Languages 49
50
references

Comparative Study of
Programming Languages
References
1. John von Neumann. First Draft Report on the EDVAC, 1945.

2. A.M. Turing, On Computable Numbers, with an Application to the Entscheidungsproblem, Proceedings of the London Mathematical Society, 2 42: 230–
65, 1937.

3. J. R Gurd, C. C Kirkham, I. Watson. The Manchester prototype dataflow computer. Communications of the ACM - Special section on computer
architecture CACM Homepage archive. Volume 28 Issue 1, Jan. 1985, Pages 34-52, ACM New York, NY, USA.

4. Alan Bawden, Richard Greenblatt, Jack Holloway, Thomas Knight, David Moon, Daniel Weinreb, LISP Machine Progress Report, MIT AI Lab memos, AI-
444, 1977.

5. John Backus. Can programming be liberated from the von Neumann style?: a functional style and its algebra of programs. Communications of the ACM .
Volume 21 Issue 8, Aug. 1978. Pages 613-641. ACM New York, NY, USA.

6. Harold Abelson, Gerald Jay Sussman. Structure and Interpretation of Computer Programs. The MIT Press. 1996.

Comparative Study of Programming

Languages 51