Keynote: The Power of Abstraction

291 views

Published on

Video and slides synchronized, mp3 and slide download available at http://bit.ly/13YbQvb.

Abstraction is at the center of much work in Computer Science. It encompasses finding the right interface for a system as well as finding an effective design for a system implementation. Filmed at qconlondon.com.

Barbara Liskov is an Institute Professor at MIT, a member of the National Academy of Engineering and the National Academy of Sciences, a fellow of the American Academy of Arts and Sciences, and a fellow of the ACM. Awards received: ACM Turing Award, the ACM SIGPLAN Programming Language Achievement Award, the IEEE Von Neumann medal, lifetime achievement award from the Society of Women Engineers.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
291
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Keynote: The Power of Abstraction

  1. 1. The Power of AbstractionBarbara LiskovMarch 2013MIT CSAIL
  2. 2. InfoQ.com: News & Community Site• 750,000 unique visitors/month• Published in 4 languages (English, Chinese, Japanese and BrazilianPortuguese)• Post content from our QCon conferences• News 15-20 / week• Articles 3-4 / week• Presentations (videos) 12-15 / week• Interviews 2-3 / week• Books 1 / monthWatch the video with slidesynchronization on InfoQ.com!http://www.infoq.com/presentations/programming-abstraction-liskov
  3. 3. Presented at QCon Londonwww.qconlondon.comPurpose of QCon- to empower software development by facilitating the spread ofknowledge and innovationStrategy- practitioner-driven conference designed for YOU: influencers ofchange and innovation in your teams- speakers and topics driving the evolution and innovation- connecting and catalyzing the influencers and innovatorsHighlights- attended by more than 12,000 delegates since 2007- held in 9 cities worldwide
  4. 4. Software is Complex Systems are big and they do complicated things and they may be distributed and/orconcurrent
  5. 5. Addressing Complexity Algorithms, data structures, protocols
  6. 6. Addressing Complexity Algorithms, data structures, protocols Programming methodology Programming languages
  7. 7. This Talk Programming methodology as itdeveloped Programming languages Programming languages today
  8. 8. The Situation in 1970 The software crisis!
  9. 9. Programming Methodology How should programs be designed? How should programs be structured?
  10. 10. The Landscape E. W. Dijkstra. Go To StatementConsidered Harmful. Cacm, Mar. 1968
  11. 11. The Landscape N. Wirth. Program Development byStepwise Refinement. Cacm, April 1971
  12. 12. The Landscape D. L. Parnas. Information DistributionAspects of Design Methodology. IFIPCongress, 1971 “The connections between modules arethe assumptions which the modulesmake about each other.”
  13. 13. Modularity A program is a collection of modules
  14. 14. Modularity A program is a collection of modules Each module has an interface,described by a specification
  15. 15. Modularity A program is a collection of modules Each has an interface, described by aspecification A module’s implementation is correct if itmeets the specification A using module depends only on thespecification
  16. 16. Modularity A program is a collection of modules Each has an interface, described by aspecification A module’s implementation is correct if itmeets the specification A using module depends only on thespecification E.g. a sort routine sort(a)
  17. 17. Benefits of Modularity Local reasoning Modifiability Independent development
  18. 18. The Situation in 1970 Procedures were the only type ofmodule Not powerful enough, e.g., a file system Not used very much Complicated connections
  19. 19. Partitions B. Liskov. A Design Methodology forReliable Software Systems. FJCC, Dec.1972
  20. 20. PartitionsPartition stateop1 op2 op3
  21. 21. From Partitions to ADTs How can these ideas be applied tobuilding programs?
  22. 22. Idea Connect partitions to data types
  23. 23. Meeting in Savanah ACM Sigplan-Sigops interface meeting.April 1973. (Sigplan Notices, Sept.1973) Started to work with Steve Zilles
  24. 24. The Landscape Extensible Languages S. Schuman and P. Jourrand. DefinitionMechanisms in Extensible ProgrammingLanguages. AFIPS. 1970 R. Balzer. Dataless Programming. AFIPS.1967
  25. 25. The Landscape O-J. Dahl and C.A.R. Hoare. HierarchicalProgram Structures. StructuredProgramming, Academic Press, 1972
  26. 26. The Landscape J. H. Morris. Protection in ProgrammingLanguages. Cacm. Jan. 1973
  27. 27. Abstract Data Types B. Liskov and S. Zilles. Programmingwith Abstract Data Types. ACM SigplanConference on Very High LevelLanguages. April 1974
  28. 28. What that paper proposed Abstract data types A set of operations And a set of objects The operations provide the only way to usethe objects A sketch of a programming language
  29. 29. From ADTs to CLU Participants Russ Atkinson Craig Schaffert Alan Snyder
  30. 30. Why a ProgrammingLanguage? Communicating to programmers Do ADTs work in practice? Getting a precise definition Achieving reasonable performance
  31. 31. Some Facts about CLU Static type checking Heap-based Separate compilation No concurrency, no gotos, noinheritance
  32. 32. CLU Mechanisms Clusters Polymorphism Iterators Exception handling
  33. 33. ClustersIntSet = cluster is create, insert, delete, …% representation for IntSet objects% implementation of the operationsend IntSet
  34. 34. ClustersIntSet = cluster is create, insert, delete, …% representation for IntSet objects% implementation of the operationsend IntSetIntSet s = IntSet$create( )IntSet$insert(s, 3)
  35. 35. PolymorphismSet = cluster[T: type] is create, insert, …% representation for Set object% implementation of Set operationsend SetSet[int] s := Set[int]$create( )Set[int]$insert(s, 3)
  36. 36. PolymorphismSet = cluster[T: type] is create, insert, …where T has equal: proctype(T, T)returns (bool)
  37. 37. Iterators For all x in C do S
  38. 38. Iterators For all x in C do S Destroy the collection? Complicate the abstraction?
  39. 39. Visit to CMU Bill Wulf and Mary Shaw, Alphard Generators
  40. 40. Iteratorssum: int := 0for e: int in Set[int]$members(s) dosum := sum + eend
  41. 41. Also Exception handling Strong specifications, e.g., IntSet$choose First class Procedures and Iterators
  42. 42. After CLU Argus and distributed computing Programming methodology Modular program design Reasoning about correctness Type hierarchy
  43. 43. From CLU to Object-OrientedProgramming SmallTalk provided inheritance
  44. 44. The Landscape Inheritance was used for: Implementation Type hierarchy
  45. 45. Type Hierarchy Wasn’t well understood E.g., stacks vs. queues
  46. 46. The Liskov SubstitutionPrinciple (LSP) Objects of subtypes should behave likethose of supertypes if used viasupertype methods B. Liskov. Data abstraction andhierarchy. Sigplan notices, May 1988
  47. 47. What Next? Modularity based on abstraction is theway things are done
  48. 48. Programming LanguagesToday Languages for experts, e.g., Java, C#
  49. 49. Programming 1A E.g., Python
  50. 50. Challenges A programming language for novicesand experts Ease of use vs. expressive power Readability vs. writeability Modularity and encapsulation Powerful abstraction mechanisms State matters
  51. 51. Challenges Massively-parallel computers Programming methodology Programming language support
  52. 52. The Power of AbstractionBarbara LiskovMarch 2013MIT CSAIL

×