0% found this document useful (0 votes)
34 views

Introductory Chapter

This document discusses programming languages and some key factors related to them. It covers: 1) What mattered in early programming (efficiency) versus now (problems beyond efficiency as software gets more complex). 2) Reasons for many languages existing, including evolution to better approaches, specialization for tasks, and personal preference. 3) Why some languages are more successful, focusing on expressive power, ease of use, good implementation/tools, and corporate backing. 4) The importance of studying programming languages for increased ability to solve problems, choose languages, learn new ones, understand implementation, design languages, and advance computing overall.

Uploaded by

sagni
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
34 views

Introductory Chapter

This document discusses programming languages and some key factors related to them. It covers: 1) What mattered in early programming (efficiency) versus now (problems beyond efficiency as software gets more complex). 2) Reasons for many languages existing, including evolution to better approaches, specialization for tasks, and personal preference. 3) Why some languages are more successful, focusing on expressive power, ease of use, good implementation/tools, and corporate backing. 4) The importance of studying programming languages for increased ability to solve problems, choose languages, learn new ones, understand implementation, design languages, and advance computing overall.

Uploaded by

sagni
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 56

Jimma University Institute of Technology

School of
Electrical and Computer Engineering

Programming Languages
(ECEg-4182)

1
Chapter 1: Introduction

2
What matters in programming?
 1950s: cost and use of machines
 How many programmers could one ‘buy’ with the price of
one computer?
 The primary positive characteristic of programming
languages was efficiency

 Nowadays
 problems other than efficiency are often more
important
 cost of labor has far surpassed the cost of machinery
 software systems are getting more and more
complex
3
Why are there so many programming languages?

 Evolution
 finding ‘better’ ways to do things
 structured programming, modules, o-o, ...

 Special languages for special purposes


 C is good for low-level systems programming
 Prolog is good for logic programing

 Personal preference
 Some people find it natural to think recursively; others
prefer iteration

4
Why are some programming languages more successful?

 Expressive power
 programmer’s ability to write, read, and maintain,
understand and analyze code for complex systems
 Tools abstraction facilities (for computation & data)

 Ease of use: low learning curve

 Ease of implementation
 E.g a simple, portable implementation of Pascal

5
More reasons for success

 Excellent compilers and tools


 possible to compile to very good (fast/small) code
(e.g Fortran)
 Economics(cost)
 10000000 lines of Cobol is hard to rewrite
 100000 Cobol programmers are hard to re-train

 backing of a powerful sponsor (COBOL,


PL/1, Ada, Visual Basic, C#)
6
Why Study Programing Languages ?
 All languages are based on a relatively small group
of basic concepts

 What should we look for in a programming


languages?

 Should I use c, c++ or c# for system programing?


Why?

 Fortran or c for scientific applications ?


7
Why Study Programing Languages ?
 Increased capacity to express ideas
 Improved background for choosing appropriate
languages
 Increased ability to learn new languages
 Better understanding of the significance of
implementation
 Increased ability to design new languages
 Overall advancement of computing

8
Increased capacity to express ideas

 The depth at which people can think is influenced


by the expressive power of the language in which
they communicate their thoughts
 Programmers, in the process of developing
software, are similarly constrained

 The language in which they develop SW place


limits on
 Control structures
 Data structures
 Abstractions that can be used
9
 Awareness of such wider variety of language
features reduces these limitations during
software development
 Features of one language may be simulated in
another

 Study of PLC builds appreciation for language


features and encourages their use, even when the
language they are using does not directly support
such features
 simulation of feature is more cumbersome, and less safe

10
Improved background for choosing languages

 Many programmers have had little formal CS


training or training in the distant past

 Programmers tend to use what they are familiar


with, even if it is not suitable for the task

 Familiarity with variety of language constructs


allows for more informed language choices
 Reduce the required effort in coding
 e.g C or Java for graphical user interface

11
Increased Ability to learn new languages
 A through understanding of PLC makes it easier
to see how language concepts are incorporated
in the language being learned
 For example, understanding object-oriented concept
will help to learn Java easily

 Understanding data abstraction facilitates learning


how to construct ADTs in C++ or Java

 Understanding PLC makes it easier to understand


manuals for programming languages and compilers

12
Understanding implementation
 Understanding language implementation
issues leads to

 Understanding why languages are designed the


way they are

 Ability to use a language more efficiently when


there is a choice among several constructs:
 Example: recursion vs. iteration

13
Better use of languages that
are already known
 Study of PLC helps programmers to learn
about previously unknown or unused
features and constructs of the language
they already use

14
Overall advancement of computing
 Why does a particular language become popular?
 Best suited to solving problems in a particular domain

 Those in positions to choose are familiar with PLC

 ALGOL 60 vs FORTRAN (1960s)


 ALGOL more elegant, better control statements
 Programmers of the time found ALGOL 60 language
description difficult to read, concepts difficult to
understand

15
Programming Domains
 Scientific Apps
 The 1st digital computers were invented and used
for scientific application
 Scientific computations
 Simple data structures (array and matrices)
 Large number of floating point computations
 Fortran, Algol

16
System programming
 The operating system and the programming support
tools of a computer system are collectively known as
its systems software
 System software must be efficient because of
continuous use
 IBM’s PL/S, Digital’s BLISS

 But today most of system softwares are written


using general PLs such as c and c++
 Eg. UNIX is written in c
17
Business Applications
 use of computers for business applications began
in the 1950s
 Special computers were developed for this
purpose, along with special languages

 Produce reports, use decimal numbers and characters


 COBOL

 A.I. (Artificial intelligence)


 Symbols rather than numbers manipulated
 LISP, Prolog

18
Language Evaluation Criteria
 To examine the underlying concepts of the
various constructs and capabilities of
programming languages we need a set of
evaluation criteria
 Readability
 Writeability
 Reliability
 Cost

19
Readability
 One of the most important criteria for
judging a programming language is the ease
with which programs can be read and
understood
 Before 1970 efficiency was the main concern
but after 1970 maintenance was the issue of
design
 Distinct crossover from a focus on machine
orientation to a focus on human orientation
20
 characteristics that contribute to the
readability of a programming language
 Overall Simplicity
 Orthogonality
 Control Statements
 Data Types and Structures
 Syntax Considerations

21
Readability: Simplicity
 The difficulty in learning a new language
increases with the number of components in the
language
 Feature multiplicity negatively impacts readability
 C: x++; ++x; x = x+1; x += 1;
 Operator overloading should be used sensibly
 Simplicity in the extreme: assembly language

22
Readability: Orthogonality
 A relatively small set of primitive constructs
can be combined in a relatively small
number of ways to build the control and
data structures of the language.
 Every possible combinations of primitives is
legal and meaningful

23
Orthogonality
 Example: suppose a language has
 4 data types (int, float, double, char)
 2 type operators (array and pointer)
 If the 2 type operators can be applied to
themselves and the 4 data types, a large
number of data structures is possible.
 int[5][2], float***, float*[4], etc.

24
Orthogonality
 The more orthogonal the design, the
fewer exceptions the language rules
require.
 C is not very orthogonal:
 There are 2 kinds of structured data types,
arrays and structs; structs can be returned
as values of functions, arrays cannot
 Parameters are passed by value, except for
arrays, which are passed by reference.

25
Orthogonality
 Too much orthogonality can cause problems,
such as ALGOL 68, which had an explosion of
combinations
 Functional programming languages such as
LISP provide a good balance of simplicity and
orthogonality
 Single construct, the function call, which can be
combined with other function calls in simple ways
 Functions are first-class objects

26
Readability: Data Types
 Features for user-defined data types
enhance readability.
 Record types for storing employee info
vs a collection of related arrays
(FORTRAN):
CHARACTER(LEN=20) NAME(100)
INTEGER AGE(100)
INTEGER EMP_NUMBER(100)
REAL SALARY(100)

27
 suppose a numeric type is used for an
indicator flag because there is no
Boolean type in the language
 timeOut = 1 meaning unclear
 timeOut = true meaning is clear

28
Readability: Syntax Considerations
 The syntax, or form, of the elements of a language
has a significant effect on the readability of
programs

 readability are strongly influenced by the forms of


a language’s special words

 Especially important is the method of forming


compound statements
 Designing statements so that their appearance at
least partially indicates their purpose is an obvious
aid to readability 29
Readability: Syntax
Considerations
 Identifier forms
 FORTRAN 77 (6 chars max, embedded blanks)
 Original ANSI Basic (a single letter, optionally
followed by a single digit)
 Special words
 Compound statement delimiters
 Pascal: begin..end
 C: { .. } simplicity resulted from fewer reserved words
 Ada: if .. End if loop .. end loop
(greater readability resulted from more reserved words)

30
Writability
 Writability is a measure of how easily a language can
be used to create programs for a chosen problem
domain
 process of writing a program requires the
programmer frequently to reread the part of the
program that is already written

 As is the case with readability, writability must be


considered in the context of the target problem
domain of a language

31
Writeability: simlicity & orthogonality

 a smaller number of primitive constructs


and a consistent set of rules for combining
them
 too much orthogonality can be a detriment
to writability

 too much orthogonality can cause errors in


programs to go undetected

32
Writeability: Support for Abstraction

 abstraction means the ability to define and


then use complicated structures or operations
in ways that allow many of the details to be
ignored
 Process abstraction
 Data abstraction
 The overall support for abstraction is clearly
an important factor in the writability of a
language

33
Writeability:
 Expressivity

 Control structures

 Abstraction mechanisms

 means that a language has relatively


convenient, rather than cumbersome, ways of
specifying computations

 for statements for counting loops (instead of while)

 count++ vs count = count + 1


34
Reliability
 A program is said to be reliable if it performs to its
specifications under all conditions

 Type checking
 Type checking is testing for type errors in a given
program either at compile or run time
 Subscript ranges: Ada vs. C
 Static vs. dynamic type checking

 failure to type check, at either compile time


or run time, has led to countless program
errors
35
Exception handling

 Intercept runtime errors, take action to correct


problem, and continue processing is an indication for a
reliable programing language
 This facility is called exception handling
 PL/I, C++, Ada, Java, C#
 Aliasing
 2 or more ways to reference same memory cell
 Possible via pointers, reference parameters, unions

36
Costs

 Training programmers
 A function of the simplicity and orthogonality of
the language and the experience of the
programmers
 Writing programs
 The original efforts to design and implement
high-level languages were driven by the desire
to lower the costs of creating software

37
 Compiling programs
 Executing programs
 A language that requires many run-time type
checks will prohibit fast code execution,
regardless of the quality of the compiler
 Language implementation system
 A language whose implementation system is
either expensive or runs only on expensive
hardware will have a much smaller chance of
becoming widely used
38
 Poor reliability
 If the software fails in a critical system,
such as a nuclear power plant or an X-ray
machine for medical use, the cost could be
very high
 Maintaining programs

39
Language paradigms
 There are four computational models that
describe most programing today

 Imperative
 Functional (applicative)
 Logic (rule based)
 O-O

40
Imperative Languages
 Example: a factorial function in C

int fact(int n) {
int sofar = 1;
while (n>0) sofar *= n--;
return sofar;
}
 Characteristics of imperative languages:
 Assignment

 Iteration

 Order of execution is critical

41
Functional Languages
 Example: a factorial function in ML
fun fact x =
if x <= 0 then 1 else x * fact(x-1);

 Characteristics of functional languages:


 Single-valued variables = no assignments
 Heavy use of recursion = no iteration

42
Logic Languages
 Example: a factorial function in Prolog
fact(X,1) :-
X =:= 1.
fact(X,Fact) :-
X > 1,
NewX is X - 1,
fact(NewX,NF),
Fact is X * NF.

 Characteristics of logic languages


 Program expressed as rules in formal logic
43
Object-Oriented Languages
 Example: a Java definition for a kind of object that
can store an integer and compute its factorial
public class MyInt {
private int value;
public MyInt(int value) {
this.value = value;
}
public int getValue() {
return value;
}
public MyInt getFact() {
return new MyInt(fact(value));
}
private int fact(int n) {
int sofar = 1;
while (n > 1) sofar *= n--;
return sofar;
}
} 44
Object-Oriented Languages
 Characteristics of object-oriented
languages:

 Usually imperative, plus…

 Constructs to help programmers use


“objects”—little bundles of data that know
how to do things to themselves

45
New Languages
 A clean slate: no need to maintain compatibility with
an existing body of code

 But never entirely new any more: always using ideas


from earlier designs

 Some become widely used, others do not

 Whether widely used or not, they can serve as a


source of ideas for the next generation
46
Widely Used: Java
 Quick rise to popularity since 1995 release
 Java uses many ideas from C++, plus some
from Mesa, Modula, and other languages
 C++ uses most of C and extends it with ideas
from Simula 67, Ada, ML and Algol 68
 C was derived from B, which was derived
from BCPL, which was derived from CPL,
which was derived from Algol 60

47
Not Widely Used: Algol
 One of the earliest languages: Algol 58,
Algol 60, Algol 68
 Never widely used
 Introduced many ideas that were used
in later languages, including
 Block structure and scope
 Recursive functions
 Parameter passing by value

48
Fighting the Language
 Languages favor a particular style, but
do not force the programmer to follow
it
 It is always possible to write in a style
not favored by the language

 It is not usually a good idea…

49
Non-object-oriented Java
class Fubar {

public static void main (String[] args) {

// whole program here!

}
}

50
Language Design Tradeoffs
 Reliability vs. cost of execution
 Ada’s runtime type checking adds to execution overhead
 Java array index range checking vs C
 C programs execute faster than semantically equivalent
Java programs, although Java programs are more reliable
 Readability vs. writeability
 C and APL
 The designer of APL traded readability for writability
 APL includes powerful set of operators for array operands
 Flexibility vs. safety
 Pascal variant record is a flexible way to view a data
object in different ways, but no type checking is done to
51
Implementation methods
 Compilation
 Translate high-level program to machine
code
 Slow translation
 Fast execution
 C, COBOL, C++, Ada

52
53
Implementation methods
 Interpretation
 No translation
 Slow execution (10 to 100 times slower)
 Becoming rare
 APL, SNOBOL, LISP,JavaScript
 Hybrid implementation systems
 Small translation cost
 Medium execution speed
 Java applets are compiled into byte code 54
55
Programming Environments
 A collection of tools used in software
development

 UNIX (solaris CDE, Gnome & KDE)

 Borland C++, JBuilder


 integrated compiler, editor, debugger, and file
system for sw development
 Microsoft Visual C++, Visual Basic
56

You might also like