cs164 Introduction to Programming Languages and Compilers (PowerPoint)

Document Sample
cs164 Introduction to Programming Languages and Compilers (PowerPoint) Powered By Docstoc
					    Some Thoughts on
 Programming Languages
         & OOP

A deeply philosophical treatise on the
 nature of programming languages.
How is a compiler class different?
Why are you taking this course?
  a)   learn what the compiler does to my code
  b)   write a large, magic piece of software
  c)   understand various programming languages
  d)   learn about some classical CS algorithms.
  e)   It’s a required class.

None of you answered
  “When I grow up, I want to write the best C++ compiler.”
How is a compiler class different?

Not intended for future compiler engineers
   – there are few of those

... but for software developers
   – Lots of those

But why does a software engineer need a compiler
   – we’ll take a stab at this question
Why a software engineer/developer needs
       Programming Languages
• New languages will keep coming
  – Understand them, choose the right one.
• Write code that writes code
  – Be the wizard, not the typist.
• Develop your own language.
  – Are you kidding? No.
• Learn about compilers and interpreters.
  – Programmer’s main tools.
New Languages will Keep Coming
A survey: how many languages do you
• Let’s list them here:
Be prepared to program in new languages
• Languages undergo constant change
   –   FORTRAN     1953
   –   ALGOL 60    1960
   –   C           1973
   –   C++         1985
   –   Java        1995
• Evolution steps: 12 years per big language
   – are we overdue for the next big one?
• ... or is the future already here?
   – are we in a major change in what programs express,
     and how?
Develop your own language

• Are you kidding? No. Guess who developed:
  –   PHP
  –   Ruby
  –   JavaScript
  –   perl

• Done by smart hackers
  – say these were done “in a garage”
  – not in ivory tower
Trends in Programming Languages
Trends in programming languages

• the programming language and its compiler:
   – programmer’s primary tools
   – you must know them inside out

• languages has been constantly evolving ...
   – what are the forces driving the change?

• ... and will keep doing so
   – to predict the future, let’s examine the history…
Hollerith Type III Tabulator 1932
ENIAC (1946, University of Philadelphia)

ENIAC program for external ballistic equations:
Programming the ENIAC
ENIAC (1946, University of Philadelphia)

• programming done by
  – rewiring the interconnections
  – to set up desired formulas, etc
• Problem: what’s the tedious
  – programming = rewiring
  – slow, error-prone
• Lesson:
  – store the program in memory!
  – birth of von Neuman paradigm
UDSAC (1947, Cambridge University)

• the first real computer
   – large-scale, fully functional, stored-program
     electronic digital computer (by Maurice Wilkes)
   – this was a von Neuman computer, but did it solve all
• problem: Wilkes realized:
   – “a good part of the remainder of my life was going to
     be spent in finding errors in ... programs”
• solution: procedures (1951)
   – reusable software was born
   – procedure: the first (implemented) language construct
IBM 407 Accounting Machine (1949)
IBM 407 Accounting Machine (1949)
The IBM 602 Calculating Punch
Assembly – the language (UNIVAC 1,
• Idea translate mnemonic code (assembly) by hand
   – by hand, they did not have a compiler yet
   – write programs with mnemonic codes (add, sub),
     with symbolic labels,
   – then assign addresses by hand
• Example of symbolic assembler
   clear-and-add a
   add b
   store c
• translate it by hand to something like this (understood by
   B100 A200
Assembler – the compiler (Manchester, 1952)

• it was assembler nearly as we know it, called AutoCode
• a loop example, in MIPS, a modern-day assembly code:
loop: addi $t3, $t0, -8
     addi $t4, $t0, -4
     lw $t1, theArray($t3)      #   Gets the last
     lw $t2, theArray($t4)      #    two elements
     add $t5, $t1, $t2          #   Adds them together...
     sw $t5, theArray($t0)      #   ...and stores the result
     addi $t0, $t0, 4           #   Moves to next "element“
                                #   of theArray
     blt $t0, 160, loop         #   If not past the end of
                                #   theArray, repeat
     jr $ra
Assembly programming caught on, but

• Problem: Software costs exceeded hardware

• John Backus: “Speedcoding”
  – An interpreter for a high-level language
  – Ran 10-20 times slower than hand-written assembly
     • way too slow
FORTRAN I (1954-57)
• The first compiler
  –   Produced code almost as good as hand-written
  –   Huge impact on computer science
  –   Modern compilers preserve its outlines
  –   FORTRAN (the language) still in use today

• By 1958, >50% of all software is in FORTRAN

• Cut development time dramatically
  – 2 weeks  2 hrs
  – that’s more than 100-fold
FORTRAN I (IBM, John Backus, 1954)
• Example: nested loops in FORTRAN
  – a big improvement over assembler,
  – but annoying artifacts of assembly remain:
     • labels and rather explicit jumps (CONTINUE)
     • lexical columns: the statement must start in column 7

  – The MIPS loop in FORTRAN:

    DO 10 I = 2, 40
    A[I] = A[I-1] + A[I-2]
Side note: designing a good language is
• A good language protects against bugs, but lessons take
  a while.
• An example that cause a failure of a NASA planetary

        buggy line:
              DO 15 I = 1.100
        what was intended (a dot had replaced the comma):
              DO 15 I = 1,100
        because Fortran ignores spaces, compiler read this
              DO15I = 1.100
      which is an assignment into a variable DO15I, not a

• This mistake is harder (if at all possible) to make with the
Goto considered harmful
  L1: statement
  if expression goto L1

• Dijkstra says: gotos are harmful
  – use structured programming
  – lose some performance, gain a lot of readability

  how do you rewrite the above code into structured form?
Object-oriented programming (1970s)
• The need to express that more than one object supports
  draw() :
   draw(2DElement p) {
      switch (p.type) {
        SQUARE: … // draw a square
           CIRCLE: … // draw a circle

• Problem:
   – unrelated code (drawing of SQUARE and CIRCLE) mixed in
     same procedure;
• Solution:
   – Object-oriented programming with inheritance
Object-oriented programming

• In Java, the same code has the desired
    class Circle extends 2DElement {
      void draw() { <draw circle> }
    // similar for Square

• the dispatch is now much simpler:
  – p.draw()
Review of historic development
• wired interconnects  stored program (von Neuman
• lots of common bugs in repeated code  procedures
• machine code  symbolic assembly (compiled by hand)
• tedious compilation  assembler (the assembly
• assembly  FORTRAN I
• gotos  structured programming
• hardcoded “OO” programming  inheritance, virtual calls

                     Do you see a trend?

• Removal of boilerplate code
   – also called plumbing, meaning it conveys no application logic
• Done by means of new abstractions, such as procedures
Where will languages go from here?
• The trend is towards higher-level abstractions
  – express the algorithm concisely!
  – which means hiding often repeated code fragments
  – new language constructs hide more of these low-level

• Also, detect more bugs when the program is
  – with stricter type checking
… and why the trends matter to you
      Become unoffshorable?

“We design them here, but the labor is cheaper in Hell.”
Don’t be a straight programmer

• Build tools for others
   –   libraries
   –   frameworks
   –   code generators
   –   small languages (such as configuration languages)
   –   big languages
          Cargo Cult Programming

• A style of (incompetent) programming dominated
  by ritual inclusion of code or program structures
  that serve no real purpose.
• A cargo cult programmer will usually explain the
  extra code as a way of working around some bug
  encountered in the past, but usually neither the
  bug nor the reason the code apparently avoided
  the bug was ever fully understood .
             Cargo Cult Programming
• The term ‘cargo cult’ is a reference to aboriginal religions
  that grew up in the South Pacific after World War II.
• The practices of these cults center on building elaborate
  mockups of airplanes and military style landing strips in
  the hope of bringing the return of the god-like airplanes
  that brought such marvelous cargo during the war.
• Hackish usage probably derives from Richard Feynman's
  characterization of certain practices as “cargo cult
  science” in his book Surely You're Joking, Mr. Feynman!
             Two Distinct Trends

• One is positive and is connected with the
  refinement of traditional programming constructs
  (generic procedures, templates, visibility of
  variables, etc.).
• The second is hugely negative as try to position
  OO as a new encompassing software
  engineering paradigm. Often OO is oversold as
  panacea and even as a cult.
       Why OOP Is Like Communism

• Economic communism spread like wildfire in the
  first half of the 20th century because it had such
  appealing ideals.
• Like OO, these ideals were very seductive on
• Intellectuals all over the world were drawn in
  by it's concepts in droves.
• However, the complexities and dynamism of
  human nature proved not to favor economic
  communism as a productive model.
       Why OOP Is Like Communism

• One of these ideals was central control and
  planning of the economy.
• Duplication and coordination of production
  would eliminate wasteful, redundant
  procedures; thus increasing the overall
• A watchful, central eye would also keep
  people in line so that they would produce
  only what was deemed useful and fair.
       Why OOP Is Like Communism

• OOP has a similar appeal.
• Data and operations (methods) are tightly
  integrated and controlled within the watchful
  eye of the OO paradigm.
 OOP and economic communism suffer similar
• They both get bogged down in their own
  bureaucracy and have a difficult time dealing
  with change and outside influences which are
  not a part of the internal bureaucracy.
• It simply has it's rules and regulations and
  follows them like a good little bureaucratic

• Object Oriented Programming (OOP) is a term
  largely borrowed from the SmallTalk community,
  who were espousing many of these techniques
  in the mid 1970's.
• In turn, many of their ideas derive from Simula
  67, as do most of the core ideas in C++.
• Key notions such as encapsulation and reuse
  have been discussed as far back as the 60's,
  and received a lot of discussion during the
  rounds of the Ada definition.

• It is said that countries get the governments
  they deserve, and perhaps that is true of
  professions as well--a lot of the energy
  fueling this hype derives from the truly poor
  state of software development.
• While hardware developers have provided a
  succession of products with radically increasing
  power and lower cost, the software world has
  seen very little productivity improvement.
          He said that She said…

• Using a computer language is a social, and
  even political act, akin to voting for a
  candidate or buying a certain brand of car.
• As such, our choices are open to
  manipulation by marketeers, influence by
  fads, and various forms of rationalization by
  those who were burned and have trouble
  admitting it.
                 Early Adopter

• Is an early customer of a given company,
  product, or technology.
• Typically this will be a large, sophisticated
  customer that, in addition to using the vendor's
  product or technology, will also provide
  considerable and candid feedback to help the
  vendor refine its future product releases, as well
  as the associated means of distribution, service,
  and support.

• Careful observers can spot the rise of languages
  as they hit the early stages of the technology
  adoption lifecycle.
• How widely deployed is the language in any
  given moment?
• The rate of adoption - is it accelerating or slowing


Shared By: