Programming Language Paradigms: summary

1. Programming Language Paradigms: summary

2. Object-oriented programming • Objects are the fundamental building blocks of a program. • Interaction is structured as messages send to receivers. • Receivers implement methods in response to messages.

3. Smalltalk • Smalltalk is a pure OO language • Everything is an object. • All objects have a uniform communication structure. • Method invocation is done at runtime • Dynamic binding • Language, object system and development environment tightly integrated.

4. Inheritance • One of the most popular OO features is inheritance. • Can define new classes in terms of existing classes. • This creates a class hierarchy in which subclasses take on the behavior of their parent classes. • A subclass can generate new behaviors by • Defining new methods • Overriding a parent method.

5. Polymorphism • Polymorphism is the idea that an object or method can perform the same operation on different data types. • Addition is polymorphic in most languages. • Allows a programmer to write code without knowing the types of the data involved. • [listOfStuff sort] <- don’t need to know what this is a list of.

6. Encapsulation • Encapsulation provides a way of packing all the structure and behavior of an object into a single module. • Interface: the public face of an object • Implementation: How methods are carried out. • Prevents users from misusing internal structure. • Implementation can be changed without affecting external programs. • Promotes information hiding.

7. Objects and Messages • Everything in Smalltalk is an object. • You communicate with objects via messages. • The receiver of a message responds via the execution of a method. <object> <selector1>: arg1 <selector2>: arg2 … myList at: 1 put: someObject

8. Program design • Program design consists of constructing a set of objects and determining how they relate to each other. • is-A relationship • has-A relationship • Suitable for complex, decomposable applications. • GUIs • Distributed systems

9. Smalltalk vs. Java • Similarities • Integrated object system • Garbage collection • Single inheritance • Differences • Smalltalk has no non-object datatypes • Smalltalk methods are weakly typed.

10. Smalltalk vs. C++ • Similarities • Polymorphism • Differences • Multiple inheritance in C++ • No Object class in C++ • No typeof/getClass methods in C++ • Garbage collection • C++ is strongly typed – most binding happens at compile time. • No integrated IDE/Object system

11. Functional Programming • Functions are the basic building blocks. • A function takes zero or more inputs and returns an output • Inputs are unchanged • Bottom-up programming is the dominant style. • More complex functions are constructed from simpler functions. • Leads to the construction of libraries and modules.

12. Lisp • Read-eval-print loop • Arguments are evaluated at runtime. • Weakly typed. • Symbolic programming – able to work with either lists or symbols. • Large number of built-in functions

13. Recursion • Functional languages tend to use recursion. • Divide problem into: • Base case • Recursive case. • Tail recursion: recursive functions that return the final value in the base case with no other processing are tail recursive. • Can be rewritten as iteration

14. Lists • Lists are the primary data structure • Car/first: data • Cdr/rest – pointer to the next element in the list. c b a

15. Applicative Programming • Applicative programming is the idea of applying a function to a list of objects. • Functions are first-class objects. • Serves the same function as iteration • More terse and generalizable • Mapcar, apply

16. OOP in Lisp • CLOS – Common Lisp Object System • Provides classes, methods • Multiple inheritance, polymorphism • Implemented as generic functions • Methods are not associated specifically with a class, as in Smalltalk.

17. Declarative Programming • Clauses are the fundamental building block. • Emphasis on relations between data. • Built-in inference engine handles procedural control. • Implication used to direct search.

18. Declarative Programming • Best suited for domains where relations between data members are the important factor. • Expert systems • Databases • Natural Language • Goal: abstract away from procedural knowledge; focus on data.

19. Knowledge Representation in Prolog • Facts (unit clauses): • likes(homer, beer). • Constants are lower case. • Names of relations are lower case. • Conjunctions: • likes(homer,beer). • likes(homer,food). • Statement is represented as separate Prolog clauses. <- ends with a period

20. Knowledge Representation in Prolog • Rules • does(lisa,homework) :- likes(lisa,school). • Equivalent to: • likes(lisa,school) ->does(lisa,homework) • Read as: “Lisa does homework if she likes school.” or … • “To prove that Lisa does homework, prove that she likes school.”

21. Overall themes: Programs as Data • In both Lisp and Prolog, we saw programs that had the ability to dynamically generate new code. • This allows an application an incredible amount of flexibility. • Requirement: the structure of a program must be accessible and easily modifiable.

22. Overall themes: Abstraction • Abstraction is the key to large-scale software development. • Components are developed, tested, and then treated as a black box. • Used to build larger components. • Key requirement: no side effects!

23. Overall themes: Functions as objects • All of the languages we’ve studied treat functions as first-class objects. • This means that functions can be passed into and returned from functions. • Allows highly generic methods to be created • Sort, find, priority queue • Implementation of a message can be determined at run-time

24. Overall themes: Language Design • Adapt language to fit your problem • Reduce the programmer’s cognitive burden • Enhance readability/maintainability • Allows for short pieces of code with a single well-defined purpose.

25. Overall Themes: Reuse • Code reuse is one of the most important goals of software engineering. • One of the primary goals of OOP and functional programming. • If you find yourself building the same function more than once, generalize. • Improves readability • Reduces effort