Differences & Similarities Between Programming Paradigms [duplicate]

Answer 1

Here's my take:

• Functional programming means writing functions that take in data and operate on it. You build up large applications by assembling functions.
• Object-oriented programming encapsulated data and its operators together into a single component that maps onto mental models well. You build up large applications out of collaborating objects.
• Declarative programming (e.g., SQL) separates what is done from how it's done. You tell a relational database what you'd like it to do and leave the driving to the query engine.

Answer 2

By far the best explanations of programming paradigms are found in Peter van Roy's works. Especially in the book Concepts, Techniques, and Models of Computer Programming by Peter Van Roy and Seif Haridi. (Here's the companion wiki.) CTM uses the multi-paradigm Distributed Oz programming language to introduce all the major programming paradigms.

Peter van Roy also made this amazing poster that shows the 34 major paradigms and their relations and positions on various axis. The poster is basically an incredibly compressed version of CTM. A more thorough explanation of that poster is contained in the article Programming Paradigms for Dummies: What Every Programmer Should Know which appeared as a chapter in the book New Computational Paradigms for Computer Music, edited by G. Assayag and A. Gerzso.

Another great book that demonstrates several major programming paradigms is Structure and Interpretation of Computer Programs by Harold Abelson and Gerald Jay Sussman. This book was the basis of MIT's CS101 for several decades. A course taught by Abelson and Sussman themselves was recorded at a corporate training for Hewlett-Packard in 1986.

The main difference between CTM and SICP is that CTM demonstrates most major paradigms using a language that supports them (mostly Distributed Oz, but also some others). SICP OTOH demonstrates them by implementing them in a language that does not support them natively (a subset of Scheme). Seeing Object-Orientation implemented in a dozen or so lines of code is friggin' awesome.

You can find video recordings and course materials from the Spring 2005 course on MIT's OpenCourseWare website. Another recording of the course from MIT's short-lived ArsDigita University project. SICP has also been taught at other universities, in fact it is being taught at Berkley right now.

On a personal note, my own experience has been that really understanding a programming paradigm is only possible

• one paradigm at a time and
• in languages which force you into the paradigm

Ideally, you would use a language which takes the paradigm to the extreme. In multi-paradigm languages, it is much too easy to "cheat" and fall back on a paradigm that you are more comfortable with. And using a paradigm as a library is only really possible in languages like Scheme which are specifically designed for this kind of programming. Learning lazy functional programming in Java, for example, is not a good idea, although there are libraries for that.

Here's some of my favorites:

• object-orientation in general: Self
  • prototype-based object-orientation: Self
  • class-based object-orientation: Newspeak
    • static class-based object-orientation: Eiffel
  • multiple dispatch based OO: Dylan
  • functional + object-orientation: Scala
• functional programming: Haskell
  • pure functional programming: Haskell
    • lazy pure functional programming: Haskell
  • static functional programming: Haskell
  • dynamic functional programming: Clojure
• imperative programming: Lua
• concurrent programming: Clojure
  • message-passing concurrent programming: Erlang
• metaprogramming: Scheme
• language-oriented programming: Intentional Domain Workbench

Answer 3

Well this link tries to explain something I've used over the last two decades. I mention it because it's provably useful and I think it counts as a paradigm, because to use it you need to think in a particular way.

The different way you have to think is that when analyzing a problem, rather than asking what objects there are and what actions take place, you start with the overall requirements and ask What Needs to be Said?

From that, you choose or design a domain-specific-language (DSL), and state your problem in that language.

That link explains a particular language for describing dynamically changing dialog user interfaces. Its implementation depends on a particular control structure, Differential Execution. What it accomplishes is an order of magnitude reduction in source code, with fewer chances for coding errors. Those savings can then be spent in making the UI more sophisticated.

For other kinds of problems, other control structures are appropriate, but the concept of working through a well-chosen DSL, making source code much smaller, more easily modified, and less error-prone, is the common approach.

I think the paradigms of functional programming and OOP are best evaluated by identifying the types of problems for which they are the best expression. Often these paradigms simply become bandwagons and are touted as cure-alls, rather than classifying them by the problem spaces they address.