Organization of Programming Languages (CSE452) - PowerPoint PPT Presentation

About This Presentation
Title:

Organization of Programming Languages (CSE452)

Description:

Detour into Dr. Cheng's background. Freshman year at Northwestern Univ in 1981: ... More of the detour ... End of Detour ... Industry experience: Boeing ... – PowerPoint PPT presentation

Number of Views:19
Avg rating:3.0/5.0
Slides: 28
Provided by: cse6
Learn more at: http://www.cse.msu.edu
Category:

less

Transcript and Presenter's Notes

Title: Organization of Programming Languages (CSE452)


1
Organization of Programming Languages(CSE452)
  • Instructor Dr. B. Cheng
  • Fall 2005

2
Why are there so many programming languages?
  • Evolution -- we've learned better ways of doing
    things over time
  • Socio-economic factors
  • Proprietary interests,
  • Commercial advantage orientation toward special
    purposes
  • Orientation toward special hardware
  • Diverse ideas about what is pleasant to use

3
What makes a language successful?
  • Ease of use
  • Easy to learn (BASIC, Pascal, LOGO, Scheme)
  • Easy to express things
  • Easy to use once fluent -- "powerful" (C,
    Common Lisp, APL, Algol-68, perl)
  • Easy to implement (BASIC, Forth) possible to
    compile to very good (fast/small) code (ForTran)
  • Cost factors
  • Backing of a powerful sponsor (COBOL, PL/1, Ada,
    Visual Basic)
  • Wide dissemination at minimal cost (Pascal,
    Turing, Java)

4
Why do we have programming languages?
  • Programmers perspective
  • way of thinking
  • way of expressing algorithms
  • languages from the user's point of view
  • Abstraction of virtual machine
  • way of specifying what you want the hardware to
    do without getting down into the bits
  • languages from the implementor's point of view
  • Course Objective balance coverage of two angles.
  • Commonalities and differences among
    languages
  • Implementations of languages

5
History of Programming Languages
http//www.webopedia.com/TERM/P/programming_langua
ge.html
6
Detour into Dr. Chengs background
  • Freshman year at Northwestern Univ in 1981
  • First programs written in Fortran IV
  • Typed programs onto punch cards
  • Computer used CDC Cyber (size of 2-3 fridges)
  • Terminal used card punch machine
  • End of first quarter, exposed to new language --
    Pascal
  • Second quarter computer organization class
  • Learned PDP-11 assembly language
  • Computer used PDP-11 machine (size of 1 fridge)

7
More of the detour
  • Subsequent courses in undergrad mostly in Pascal
    (structured programming, data abstractions, etc.)
  • AI course exposed to LISP.
  • Graduate course taken as undergrad exposed to
    Prolog (as part of AI and theorem proving).
  • Graduate school at UIUC (1985)
  • Exposed to Unix and C.
  • Shared office with Smalltalk research group.
  • C was just gaining popularity, along with OO

8
End of Detour
  • Industry experience
  • Boeing (Fortran and Pascal) (1982-83)
  • IBM (version of PL/I) (1984)
  • Data General (Pascal, C) (1985)
  • Digital ( C ) (1986)
  • Fast forward to start at MSU (1990)
  • First quarter taught Org. of Programming
    Languages (C, LISP, Prolog, C)
  • Java introduced in early 1990s
  • Web takes off in mid 1990s.
  • Mobile computing, cross platform computing, etc.
  • 2004-05 multi-paradigm languages, heterogeneous
    platforms, anytime, anywhere computing

9
Major Influences to Programming Languages
  • Computer Architecture
  • Von Neumann Architecture
  • Programming methodologies
  • Programming paradigms

10
Von Neumann Architecture
11
Influence of Computer Architecture
Computer Architecture
Programming Language
  • Memory cells
  • Pipelined execution of instructions
  • Variables
  • Computation is viewed as a sequence of actions

?
?
12
Programming Paradigms
Imperative Imperative
Procedural (von Neumann) ForTran, C, Basic, Pascal, Algol60
Object-Oriented Simula67, C, Smalltalk, Java, C
Declarative Declarative
Functional LISP, Scheme, ML, Haskell
Logical Prolog, VisiCalc, RPG, spreadsheets
13
Desirable Qualities of Software
  • Software must be reliable
  • Program performs to its specification under all
    conditions
  • Software must be maintainable
  • It is no longer feasible to always build software
    from scratch
  • Must be able to easily modify existing software
  • Software must execute efficiently
  • Although hardware getting cheaper and has better
    performance, need for efficient execution remains
    due to increasingly demanding applications

14
Why study programming languages?
  • Help you choose a language.
  • C v. Modula-3 v. C for systems programming
  • Fortran v. APL v. Ada for numerical computations
  • C v. Ada v. Modula-2 for embedded systems
  • Common Lisp v. Scheme v. ML for symbolic data
    manipulation
  • Java v. C/CORBA for networked PC programs

15
Why study programming languages?
  • Make it easier to learn new languages (by
    analogy)
  • some languages are similar easy to walk down
    family tree (e.g., ForTran 77, ForTran90)
  • Identify common concepts
  • E.g. iteration, recursion, abstraction
  • Think of an analogy to human languages
  • good grasp of grammar makes it easier to pick up
    new languages (at least romance languages).

16
Make better use of language
  • Understand obscure features
  • In C, help you understand unions, arrays
    pointers, separate compilation, varargs,
  • In Common Lisp, help you understand first-class
    functions/closures, streams, catch and throw,
    symbol internals

17
Make better use of language
  • Understand implementation costs choose between
    alternative ways of doing things, based on
    knowledge of what will be done underneath
  • Use simple arithmetic equalities (use xx instead
    of x2)
  • Use C pointers or Pascal "with" statement to
    factor address calculations
  • avoid call by value with large data items in
    Pascal
  • avoid the use of call by name in Algol 60
  • choose between computation and table lookup

18
Make better use of given language
  • Figure out how to do things in languages that
    don't support them explicitly
  • Lack of suitable control structures in Fortran IV
  • use comments and programmer discipline for
    control structures
  • Lack of recursion in Fortran 77, CSP, etc.
  • write a recursive algorithm then use mechanical
    recursion
  • elimination (even for things that aren't quite
    tail recursive)
  • lack of named constants and enumerations in
    Fortran
  • use variables that are initialized once, then
    never changed
  • lack of modules in C and Pascal
  • use comments and programmer discipline
  • lack of iterators in just about everything
  • fake them with (member?) functions

19
Language Design Criteria
  • Simplicity
  • Simpler language is easier to master
  • Achieved by having a small number of features
  • Feature multiplicity
  • more than one way to accomplish the same task
  • E.g. count count count 1 count 1
  • Operator overloading
  • same operator has more than one meaning
  • Overload operator for
  • Summing integers in two arrays
  • Concatenating two arrays

20
Language Design Criteria
  • Orthogonality
  • Every possible combination of primitive
    constructs of the language is legal and
    meaningful
  • Lack of orthogonality means lots of exceptions in
    the language rules
  • Assembly language for IBM mainframe
  • A Reg1, memory cell Two
    different rules for addition
  • AR Reg1, Reg2 Cannot
    use A for adding 2 registers
  • Too much orthogonality makes language become
    overly complex (Algol 68)

21
Language Design Criteria-Syntax
  • Identifier forms
  • Fortran77 restricts identifiers to 6 characters
  • Special words
  • Pascal requires begin-end pairs to form groups
    for all control constructs
  • Ada uses end if or end loop to distinguish
    closing syntax for each type of control statement
  • Fortran 90 allows special words such as DO and
    END to be legal variable names

22
Language Design Criteria
  • Safety
  • Language should not provide features that make it
    possible to write harmful programs
  • E.g., goto statements and pointer variables
  • Type checking
  • testing for type errors in a given program,
    during compilation or program execution
  • Aliasing
  • Having two or more distinct referencing methods,
    or names, for the same memory cell (e.g., union
    members, pointers in C)
  • Robustness
  • Provides the ability to deal with undesired
    events (arithmetic overflows, invalid input, etc)
  • E.g., Exception handling facility in Java and C

23
Language Design Criteria
  • Portability
  • Programs can be compiled and run on different
    machines without rewriting the source code
  • Uniformity
  • Similar notations should look and behave in the
    same way (e.g., every end must be preceded by a
    matching begin)
  • Support for abstraction
  • Ability to define and then use complicated
    structures or operations in ways that allow many
    details to be ignored
  • Process abstraction vs Data abstraction

24
Design Trade-offs
  • Reliability vs Efficiency
  • Ada demands all references to array to be checked
    to ensure that indices are within their legal
    ranges
  • C does not require index range checking, and thus
    executes faster
  • Buffer overflow problem
  • void function (char str)
  • char buffer16 strcpy (buffer, str)
  • int main ()
  • char str "I am greater than 16 bytes"
  • function (str)

25
Design Trade-offs
  • Flexibility vs Safety
  • Pascal variant records allow a memory cell to
    contain either a pointer or an integer
  • This allows a program to do arithmetic on
    pointers, which is sometimes convenient, but is a
    dangerous practice.

26
Course Organization
  • Lectures material supplement textbook material
  • (i.e., come to class)
  • Homework assignments reinforce key concepts
  • Programming assignments give hands-on experience
  • Exams provide a way for you to demonstrate what
    youve learned
  • (and I need something to use for calculating
    grades)

27
Course Organization
Homework 15
Programming Assignments 30
Exams (2) Exam 1 10/18/05 Exam 2 12/13/05 50
In-class participation 5
Write a Comment
User Comments (0)
About PowerShow.com