STAT8030 Programming in R
COURSE NOTES 1: Hoganson
Programming Languages
Dr. Ken Hoganson, © August 2014
Programming
• Introduction/overview of
programming ideas
• Quick review
• Not intended as the student’s first
exposure to programming as a
stand-along piece.
• Overview of language and
software concepts.
Dr. Ken Hoganson, © August 2014
Programming Logic Structures
• Sequence:
• Selection:
• Iteration:
• Modules and modular design
• Recursion
• Objects, Inheritance, Polymorphism
Dr. Ken Hoganson, © August 2014
Sequence
• Sequence is simply executing instructions in order, one
at a time. We understand this intuitively.
• A basic idea, actually implemented in hardware inside
the CPU.
–
–
–
–
Fetch instruction i, the CPU gets set to fetch instruction i + 1.
Execute instruction i
Fetch instruction i+1, the CPU gets set to fetch instruction i + 2.
Execute instruction i+1
• Older programming
languages used line
numbers which
indicated the
sequence of
instructions.
• Modern languages do
not use line numbers.
Dr. Ken Hoganson, © August 2014
Selection
IF statements: (conditionals)
common to all programming
languages (though form may differ)
IF (some condition is true)
THEN do-something
ELSE do-something-else
Dr. Ken Hoganson, © August 2014
Selection
Dr. Ken Hoganson, © August 2014
Compound and Nested IFs
IF statements can be compounded
and nested.
IF score >= 90 THEN grade = ‘A’
ELSE IF score >= 80 THEN grade = ‘B’
ELSE IF score >= 70 THEN grade = ‘C’
Etc.
Dr. Ken Hoganson, © August 2014
Dr. Ken Hoganson, © August 2014
Dr. Ken Hoganson, © August 2014
SWITCH or CASE
• Testing multiple IF conditions is so
common that most languages
have a SWITCH or CASE statement:
SWITCH (grade)
CASE ‘A’: print “You Earned an A!”
CASE ‘B’: print “You Earned a B!”
etc.
Dr. Ken Hoganson, © August 2014
Iteration - Loops
 Repeat a block of statements
 Test before the block, or after the block
WHILE (test is true) DO
some set of statements
REPEAT
some set of statements
UNTIL (test is true)
 Testing after the block of code guarantees
that the code inside the loop is executed at
least one time.
Dr. Ken Hoganson, © August 2014
While loop test before executing the body
of the loop
Dr. Ken Hoganson, © August 2014
Data, Variables, Pseudocode
Dr. Ken Hoganson, © August 2014
Better Simple Program
Dr. Ken Hoganson, © August 2014
Modules
 In the early days of programming, the
usefulness of breaking a program
down into pieces, components, or
modules was realized.
 A modular program is easier to write,
because the complexity is subdivided
into more manageable pieces (the
modules). “Divide and conquer”.
 A module can be used from multiple
places in a program, and from multiple
other modules. This code need be
written only once, and then accessed
from anywhere. Reusable
Dr. Ken Hoganson, © August 2014
Module Definition
A simple module:
PROCEDURE [name] BEGIN
Some set
of programming
statements
RETURN
END PROCEDURE
Dr. Ken Hoganson, © August 2014
CALL
Calling a module: the process of transferring
the CPU from the current location, to
executing instructions in the module,
procedure, or function.
 Some instructions before the subroutine call
 [subroutine name] execute module
 some instructions executed after
completing the call
Dr. Ken Hoganson, © August 2014
Dr. Ken Hoganson, © August 2014
Dr. Ken Hoganson, © August 2014
Modules and complexity
• Modularizing a program manages complexity –
smaller easier to design pieces or modules.
• BUT, it introduces a new level of complexity –
the interaction between the modules, and the
communication between modules.
• Which Lead to structured programming
• Which lead to modern understanding of data
structures: the idea of packaging data
together with the code that manipulates
• Which lead to software engineering – designing
large software systems to explicitly define and
systematically engineer the interactions
between modules
Dr. Ken Hoganson, © August 2014
Modules and complexity
• Which lead to object-oriented programming,
where data and code are packaged as
objects.
• Objects can be created and deleted as
needed.
• Objects interact through the traditional module
call mechanism (now defined within the
objects).
• Objects also are organized in a heirachy, where
child objects inherit code and data structures
from their parents. A new dimension of object
interaction.
Dr. Ken Hoganson, © August 2014
Spiral Design Model
 A simple way to design software. An intuitive
software engineering approach.
 Particularly effective for students new to
programming, OR
 When learning a new programming language
 Also, when building an application in
◦ new area,
◦ or with a new technology,
◦ or new techniques.
 Build and test in parts, that slowly evolve
 Build a prototype, and then evolve and grow
the prototype.
Dr. Ken Hoganson, © August 2014
Evolving Prototypes (Spiral Design)
• Build a prototype, and then evolve and grow the
prototype.
• Prototype Demonstrations: and excellent way to
communicate with
– clients,
– customers,
– focus groups,
– managers.
• Prototype demonstrations can validate the:
– objectives,
– goals,
– and user interface
Dr. Ken Hoganson, © August 2014
Dr. Ken Hoganson, © August 2014
3.8 Modules
 The module has a defined interface – with possible
parameters that are passed to the module, and
possible values returned.
 Modular (also called structured) programming
simplifies the complexity within each module, but
introduces complexity in the communication and
interactions between modules.
 Early software engineering focused on the
communication complexity and topology, and in
developing a standard approach to organizing a
program into modules.
Dr. Ken Hoganson, © August 2014
Objects
• The structured programming methodology led
directly to object-oriented programming.
• An object is often defined as data structure
(that contains the object’s attributes) and a set
of methods (functions and modules) that
access that data.
• The object is formalized within the programming
language, building on ideas from structured
programming.
Dr. Ken Hoganson, © August 2014
Recursion
• Recursion is a module programming
idea, where a module will CALL ITSELF!
• This is a useful technique in limited
circumstances, that simplifies some
problems.
• The tricky part is the stopping condition –
the module should not call itself
indefinitely (which would cause the
machine or program to crash).
• It is a repeating programming logic more
comlplex than loops.
Dr. Ken Hoganson, © August 2014
Threaded programming
• Threaded modules can run concurrently
and somewhat independently
• “Threads of execution”
• Multiple modules working
together/cooperating
• Can be a software design strategy: break
down a complex system into a set of
cooperating modules that interact. Some
problems are simplified with this approach.
• Also is a parallel/high performance
comptuing technology.
Dr. Ken Hoganson, © August 2014
Object-Oriented Programming
The object paradigm led to additional
programming language innovations –
• Objects can be grouped into classes.
• Objects can be defined by their
membership in classes.
• Objects can inherit from parent classes.
• Additional capabilities of objects is enhanced
power, but at a cost of more complex
programming.
Dr. Ken Hoganson, © August 2014
Object-Oriented Programming
• Objects can work with different data types by
“overloading” their functions.
– Overloading means to have more than one
meaning for a symbol or idea, which is context
dependent.
– Example: + means addition, or + means the
logical OR operation, depending on context.
• Object capabilities are powerful, but make
programming more complex.
• “R” is NOT object-oriented in the traditional sense.
– “R” is a structured and interpreted language, but with
additions for “Big Data”.
– A nice and clean language.
Dr. Ken Hoganson, © August 2014
Agents: An AI language idea
• Combines the thread concept with
the object concept.
• Objects can be independently
operating and cooperating
“agents”.
• Agents can run independently and
concurrently, with communication
with other agents and modules.
• AI, but also great for game design!
Dr. Ken Hoganson, © August 2014
Summary
Programming is multi-dimensional, the human
brain must think in multiple dimensions, and about
complexity at multiple levels:
• L1: Syntax and grammar: the keywords and
language syntax.
• L2: The programming paradigm: structured,
threaded, objects, agents, etc.
• L3: Software design paradigm to be used
• L4: The software architecture. The design
chosen to define/build the application. A hint:
the architecture chosen should minimize the
complexity of interactions between
models/objects etc.
Dr. Ken Hoganson, © August 2014
Summary
Sad fact: the challenges of programming exceed
the ability of our minds to master reliably.
• So we use strategies to compartmentalize and
manage complexity.
• Studies have show that even the best
programmers spend most of their time revising
their code already written.
• Code evolves, because we cannot visualize the
entire project, so we “grope” our way to
success, with much trial and error.
Dr. Ken Hoganson, © August 2014
Summary
So if humans are poor programmers generally, why
not make computers write their own code?
• Great idea, but not solved yet.
• We do not understand the human process well
enough to “capture” our thinking into machine
form.
• Hmmm, so AI is having machines follow human
logic and thought process?
• True for much of AI. Other techniques that are a
non-human modeled are in use with success.
Dr. Ken Hoganson, © August 2014
End of Lecture
End
Of
Today’s
Lecture.
Dr. Ken Hoganson, © August 2014