1 / 35

David Evans http://www.cs.virginia.edu/~evans

Lecture 3: A Brief History of Programming Languages.

clive
Download Presentation

David Evans http://www.cs.virginia.edu/~evans

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Lecture 3: A Brief History of Programming Languages Available within the network will be functions and services to which you subscribe on a regular basis and others that you call for when you need them. In the former group will be investment guidance, tax counseling, selective dissemination of information in your field of specialization, announcement of cultural, sport, and entertainment events that fit your interests, etc. In the latter group will be dictionaries, encyclopedias, indexes, catalogues, editing programs, teaching programs, testing programs, programming systems, data bases, and – most important – communication, display, and modeling programs. All these will be – at some late date in the history of networking - systematized and coherent; you will be able to get along in one basic language up to the point at which you choose a specialized language for its power or terseness. David Evans http://www.cs.virginia.edu/~evans J. C. R. Licklider and Robert W. Taylor, The Computer as a Communication Device, April 1968 CS655: Programming Languages University of Virginia Computer Science

  2. Menu • Brief History of Programming Languages • Projects Kick-off • Wenger Discussion University of Virginia CS 655

  3. Really Brief History • 50s, 60s: Exciting Time • Invention of: assemblers, compilers, interpreters, first high-level languages, structured programming, abstraction, formal syntax, object-oriented programming, LISP, program verification • 70s, 80s, 90s: Boring Time • Refinement of earlier ideas, better implementations, making theory more practical • A few new/refined ideas: functional languages, data abstraction, concurrent languages, data flow, type theory, etc. University of Virginia CS 655

  4. 00s and beyond? • Pessimist’s View: • Like the 70s-90s: the most important concepts have been discovered, and nothing has really changed; slow incremental progress will continue. • Optimist’s View: • New environments (large scale networks, dynamic collections of unpredictable devices) provide new programming challenges (scalability, security, reliability), and new exciting developments will result. First time since 60s that PLs are behind the curve! • Alan Kay: “The best way to predict the future is to invent it.” University of Virginia CS 655

  5. UVA’s Info Systems Source: http://www.virginia.edu/year2000/att7-3.htm University of Virginia CS 655

  6. What drives programming language design? • Advances in Theory • BNF Grammars  Algol60 • Lambda Calculus  LISP • Type theory  CLU, ML • Changes in computing environment • Analytical engine  first programming system • von Neumann Machines  Procedural Languages • Parallel Machines  Functional Languages • Large scale networks  ??? • Changes in desired programs • Calculating missile trajectories  Assembly • Scientific computations  FORTRAN • Business computations  COBOL, PL/I • Larger programs  Data languages, Components • Even larger programs  ??? • Security requirements  ??? University of Virginia CS 655

  7. Less Brief History of PLs • Language Design Really Big Ideas • B0: The First Programs (1830s) • B1: High-level Languages (1950s-) • B2: Structured Languages (1960s-) • B3: Functional Languages (1960s-) • B4: Data Languages (1970s-) • Language Theory Really Big Ideas • L0: Chomsky’s Hierarchy • L1: Formal Syntax (BNF1960) • L2: Formal Semantics (Floyd 67, Scott 71) • L3: Program Verification (Hoare 69, etc.) • L4: Type Theory (60s-2000s) University of Virginia CS 655

  8. B0: Ada Byron, Lady Lovelace The First Programmer • Described program to solve Bernoulli equations using Babagge’s Analytical Engine • Store data and program (Jacquard punch cards) • Concepts of: • operator • numerical and symbolic computation (types)! • object-oriented programming! University of Virginia CS 655

  9. “It may be desirable to explain, that by the word operation, we mean any process which alters the mutual relation of two or more things, be this relation of what kind it may. This is the most general definition, and would include all subjects in the universe . . . Again, it [the Analytical Engine] might act upon other things besides number, were objects found whose mutual fundamental relations could be expressed by those of the abstract science of operations, and which should be also susceptible of adaptations to the action of the operating notation and mechanism of the engine . . . Supposing, for instance, that the fundamental relations of pitched sounds in the science of harmony and of musical composition were susceptible of such expression and adaptations, the engine might compose elaborate and scientific pieces of music of any degree of complexity or extent.” • Ada Lovelace, around 1830 University of Virginia CS 655

  10. P1: High-Level Languages • Assemblers, Macro Processors • Pseudo-Code Interpreters • Wilkes, Wheeler & Gill, 1951 (Appendix D) • First Compiler: Grace Murray Hopper, 1950s • Automatic Programming [A-2 compiler, 1953] • Symbolic addresses, decimal numbers • Laning and Zierler’s algebraic system • First algebraic compiler University of Virginia CS 655

  11. FORTRAN (Backus, 1954) • Radical idea: computers were more expensive than programmers – if performance suffered, would be failure • Experience with machine code hacking and automatic programming systems convinced programmers efficient code could not be generated automatically • “As far as we were aware, we simply made up the language as we went along. We did not regard language design as a difficult problem, merely a simple prelude to the real problem: designing a compiler which could produce efficient programs.” [Backus, HOPL-I 1978] • Used familiar mathematical notations • Project to design an automatic programming system for the IBM 704, not design a general language “We certainly has no idea that languages almost identical to the one we were working on would be used for more than one IBM computer, not to mention those of other manufacturers. (After all, there were very few computers around then.) [Backus, 1978] University of Virginia CS 655

  12. Hopelessly Naïve “In our naïve unawareness of language design problems - of course we knew nothing of many issues which were later thought to be important, e.g., block structure, conditional expressions, type declarations - it seemed to use that once one had the notions of the assignment statement, the subscripted variable, and the DO statement in hand, then the remaining problems of language design were trivial: either their solution was thrust upon one by the need to provide some machine facility such as reading input, or by some programming task which could not be done with existing structures.” [Backus 1978] University of Virginia CS 655

  13. Hopelessly Optimistic “Unfortunately we were hopelessly optimistic in 1954 about the problems of debugging FORTRAN programs (thust we find on page 2 of the Report: “Since FORTRAN should virtually eliminates coding and debugging…[!]”) and hence syntactic error checking facilities … were weak.” [Backus 1978] University of Virginia CS 655

  14. P2: Structured Languages: Algol(also called: Procedural, Imperative, etc.) • Algol58: captured ideas of FORTRAN in an elegant way – types, conditionals, loops; still limited abstraction from machine • Algol60: • First language designed with principles in mind • Explicit goal: language for publishing algorithms • Introduced: • Formal language syntax (BNF) • Block structure, compound statements, type declarations, variable scopes • Dynamic lifetimes, arrays with dynamic bounds • Notion of actual and formal parameters, call-by-value/call-by-name University of Virginia CS 655

  15. Algol’s Successors 1954 FORTRAN 1960 Algol60 Classes CPL Algol68 Committee Simula67 PL/I BCPL Algol-W 1970 Algol68 Smalltalk Pascal C CLU Modula-2 1980 C++ Oberon Modula-3 Java 2000 University of Virginia CS 655

  16. P3: Functional Languages • Imperative languages: assign • Functional languages: compose • No state (pure functional languages) • First class functions, closures University of Virginia CS 655

  17. Functional Languages FORTRAN 1960 LISP Algol60 ISWIM Mac Lisp 1970 Scheme ML FP 1980 Miranda Common Lisp SML 1990 Haskell ML2000 University of Virginia CS 655

  18. FL: Example def f    intsto f:5 (  intsto):5 (f  g):x  f:(g:x) *:(intsto:5) *:<1, 2, 3, 4, 5> 120 University of Virginia CS 655

  19. Functional Languages • Claimed Advantages: • Easier to write interpreter for • Easier to learn to program • Easier to reason about programs • Reality: • Hard to get decent performance • Useful for PL research • Especially ML, type systems • Useful for teaching • especially Scheme University of Virginia CS 655

  20. P4: Data Abstraction • FORTRAN: No declarations, types – integer, float, ?; identifier name determined type • Algol60: declarations, types: • Pascal, Algol68: User-defined types, confused about type equivalence • Simula67: added classes to Algol60 • Inheritance • CLU: data abstraction • Methodology for building programs by defining data types • Support for encapsulation (data hiding), iterators • Others: Ada (83), Oberon, Alphard • Smalltalk: object-orientation • Inheritance, subtyping (?), method dispatch • Other O-O languages: C++, Java, Eiffel, Sather, Ada (95), etc. University of Virginia CS 655

  21. Data Abstraction Ideas • Type-checking to reduce errors • Early languages: just manipulating bits • Lose expressiveness (especially if statically checked) • Encapsulation to reduce errors, improve maintainability • Specified type used as abstract entity • Subtyping to provide extensibility • Define new properties for a type • Inheritance to reuse code • Use a different types implementation to implement new type University of Virginia CS 655

  22. What’s missing? University of Virginia CS 655

  23. John’s Talk University of Virginia CS 655

  24. The Evolution of the C Programming LanguageThe Making of a CS655 Semester Project John Haskins, Jr. University of Virginia Department of Computer Science predator@cs.virginia.edu

  25. The Setup (1/2) The arrogant, irreverent assertion... “I don’t know what the language of the future will look like, but I know that its name will be FORTRAN.” - Peter Naur, Alan Batson, C.A.R. Hoare, Niklaus Wirth, etc. “I do know what the language of the future will look like and I know that its name will be C.” - John Haskins, Jr. University of Virginia CS 655

  26. The Setup (2/2) Initial justification of tough claim… • C has permeated virtually every field of computer programming endeavor and--love it or hate it--simply will not go away and therefore deserves to be periodically revisited and refurbished to make it into a more mature and “appropriate” tool. • C’s appropriate use is as a language for developing low-level systems and embedded applications. University of Virginia CS 655

  27. Details and Specific Proposals The new and improved C should have… • Rigorously defined built-in data types: int is too ambiguous, varying from compiler to compiler, sometimes as a function of machine word size • Improved variadic function mechanisms: current solution is clumsy and detached from the language itself • Built-in I/O mechanisms: I/O should be integrated into the language instead of being relegated to libraries separate from the language University of Virginia CS 655

  28. The Follow-through (1/2) • Alter the C lexer to recognize and return tokens for new keywords: • [s|u][8|16|32|64] and f[32|64|128], e.g., s32 means: “signed 32-bit storage region” • argc, argv and argt, e.g., if (argt[n]==f32) means: “If the type of the nth variadic parameter is 32-bit float…” • in() and out(), e.g., in(“/reg/$ra”,&r) means: “Place value contained in the $ra register into the memory region pointed to by the variable r.”; out(“/dev/tty”,famousquote()) means: “Send the output from the function famousquote() to the tty device.” University of Virginia CS 655

  29. The Follow-through (2/2) • Alter the C parser grammar to accept the new tokens in the language • Implement backend to generate actual assembly language code (MIPS R2000, in my case) from the language (easier said than done, but invaluable for proving that proposed language extensions are indeed doable) • Construct a paper detailing changes made to the language, giving justifications and support for each University of Virginia CS 655

  30. Concluding Remarks Important points… • Start NOW!!! Don’t wait!!! The deadline is rapidly approaching!!! • Be bold. Be arrogant. Be sure to back up your claims with adequate, compelling evidence! • Lucidly express your ideas in writing with both principles and examples. • Collaborate with colleagues. • Have fun. University of Virginia CS 655

  31. Course Project Calendar • Wednesday, 16 Feb: Proposal • Thursday, 17 Feb: Elevator Speeches • Week of 28 Feb - 4 Mar: Project meetings • Thursday, 23 Mar: Preliminary Report • Throughout Apr: Project meetings • Friday, 28 Apr: Final Report • Monday, 1 May, 6:30-9pm: Project Presentations in the Rotunda, West Oval Room University of Virginia CS 655

  32. Project Mantras 1 • Choose an ambitious topic, but be realistic about what you can accomplish in one semester • Work steadily throughout the term; keep in contact with your teammates using email and regular group meetings • Focus on design and understanding – building things should be motivated by solving a problem or conducting an experiment University of Virginia CS 655

  33. Project Mantras 2 • Use Dave, John and your classmates are resources • Don’t wait for project meetings if you run into problems, have ideas to bounce, etc. • All teammates get same grade • Let us know about team problems early • Divide work in way so that you aren’t waiting for teammates to finish their part • Good team management is key (recommendation: pick a manager) University of Virginia CS 655

  34. In Groups • What are the important developments I left out? • Use Wenger paper and your experience/knowledge of things that have happened since 1976. • Organize them into milestones. • If time permits: • Develop a better overall history that includes all the important developments. University of Virginia CS 655

  35. Charge • Read Algol papers • How to read a language report • Think about using features in a program • Its not just a list of features, think about interactions • Meet in project groups, come up with a project idea • PS1 due Thursday in class University of Virginia CS 655

More Related