OOP
CLOS
ObjectFunctional
LazyEvaluation
ClojureStreams
DataflowProgramming
OrganizingFunctionalCode
Clojure
Scala
Haskell
XSLT
TheLambdaPapers
briefly: no state, just functions and their values.
no (mutable) state means: no side-effects. calling the same function with the same arguments always results in the same return-value.
A purely functional program can have zero side-effects, which means all it can do is warm your computer up. And an audience member pointed out that even that's a side effect, so it can't even be allowed to do that! :-) [1]
Normally, state is associated with a set of variables that can be changed in the course of a computation. There is also a more abstract notion of state, which does not refer to particular constructs of a programming language: An object has state (or: is stateful) if its behavior is influenced by its history.[2]
- http://wesnerm.blogs.com/net_undocumented/2006/05/functional_prog.html
- Obvious advantages not withstanding, member functions are disfavored in state-of-the-art C++ libraries. The problem is that a member function is useful only for a single class. This is the bane of code reuse. Think, for example, of a library of containers. If each container class defines its own size() member function, you will end up writing numerous size() functions that basically do the same thing.
- All the new innovations we are seeing in languages herald back to the earlier era of functional programming.
Pure Functions
- Pure Functions @ ddj
- benefits
- self-documentation - no indirect context must be considered - less cognitive load - this alone is worth it.
- don't require synchronization
- compiler-optimizations
- can be executed asynchronously
- can be hot-swapped
FP and Memory Management
Functional Pearls
FP in the real world
FP and OOP compared
- From Functional to Object-Oriented Programming
- author
- I learned that OO was great because it names things. OO allows a traceable connection between the conceptual design level and the implementation level. Concepts have names, so you can talk about them, between programmers and architects. The promise of OO was to replace the dazzling complexity (and intellectual challenge) of functional programming with something more manageable.
- Higher-higher-order functions and inferred types, or lists of lists of pairs whose cdr happens to represent some concept (except when it represents another concept)
- Remember: Going from functional to OO is an advance.
- OOP is an advance over functional programming. Because functional programming tempts you to name too few things, and makes you create abstractions in a way that is hard to communicate to anyone unfamiliar with your code.
- commentors
- Object-oriented programming is therefore for when you are in an office full of screaming morons and no one gets any work done? Does OOP magically make software easy? I doubt it.
- Did anyone actually notice the bug in the inlined code I used in my example? I wanted to prove a point: Inlining of control flow constructs out of fear that abstraction would make the code abstruse and unreadable is not only morally wrong; it can actually cause its own class of bugs.
- HOF or OOP? Yes!
- object oriented programming vs function oriented (short and sweet please)
- In a functional paradigm what invariably happens as a large system grows: it becomes a huge pile of functions. All of which are interconnected, and dependent on each other. Which means if you change one function you break 10 others, it becomes impossible to manage. A *good* large program written in a functional language is usually designed with OOP principles in mind. (i.e. it is designed as a set of modules that are not inter-dependent on other modules)
- imperative vs. declarative
- http://funcall.blogspot.com/2009/07/whats-wrong-with-this-code.html
- looping becomes invisible
media
clips