Registered: Dec, 2006
Re: Typing like a Functional Programmer
Posted: Dec 8, 2006 2:16 PM
> - all OOP related techniques and principles
Depends on the functional language.
in Common List, CLOS is the defacto OOP library which is a very powerful library.
In Scheme, a common joke is that Scheme programmers know quite a bit about OOP... they have generally implemented it from scratch at least twice and use the version tailored for the problem at hand. Good multi-inheritance OOP models can be implemented in a few lines of code. Most of the time you don't need OOP as closures are more flexible.
OCaml is so OOP it has Object as the first word in it's name.
Haskell is above OOP... type classes are FAR more flexible that asking a Haskell programmer to use traditional OOP is like asking a C++ programmer to stop using inheritance.
> - generic programming
Lots of Generic programming in functional langs. The Lisps typically don't use them because they have dynamic typing, but I know Haskell has a large generic library.
> - using constructors/destructors to allocate and
> deallocate resources (RAII)
Garbage collection handles alot of this. Most functional languages also have an anagolous mechanism
> - using exemplars or prototype objects to serve as basis
> for new objects
Closures. They do all this and more.
> - using function objects
Function objects are a hack to make imperative languages do functional programming things. Having first class objects make "function objects" just silly.
> - defining copy-constructors
These are only needed in imperative languages. The hybrids, like Lisp have similar things. The pure functionals do not need them. Think about it.... if by definition NOTHING is ever mutable, why would you ever need to copy anything. Simply take as many references to the object as you like as you are guaranteed that the object will never change.
So, to answer your question rather than each of your examples, the hybrids (Lisp, Scheme, OCaml, etc..) tend to use techniques from both worlds. The pure languages either don't need the technique that the imperative world uses because the problem the imperative technique is trying to solve is a trivial one, or they use an equivelent technique, or in some cases, the technique that the imperative language uses is impractical in functional paradigms and so they use a completely different and novel technique. Also, just like there are some problems in imperative programming that are so absolutely trivial from a functional perspective (non-synchronized parallel threading for instance) that they aren't even problems, the converse is also true. For instance, in a purely functional language, everything can be done out of order and no side effects are allowed. Writing to a port is a side effect. now imagine this code snippit in a functional language:
Not only can you not print, but even if you could, you can't print IN THE RIGHT ORDER. This is a (nominally) hard problem in functional programming (solved by monads BTW).