The Rise Of Functional Programming: F#/Scala/Haskell and the failing of Lisp

The trade-off is that the code is butt-ugly, at least in this C# programmer's view.

  CL-USER> (sort (list 1 8 3 2 5) #'<) ; sort just needs a function of 2 arguments that tells if the first parameter is strictly less than the second
 => (1 2 3 5 8)
 CL-USER> (sort (list 1 8 3 2 5) #'>)
 => (8 5 3 2 1)
 CL-USER> (sort (list "hello" "HELLO" "hey" "bye") #'string<)
 => ("HELLO" "bye" "hello" "hey")
 CL-USER> (mapcar #'1+ '(1 7 3 9))
 ;mapcar applies a function to each element of the lists passed as arguments and returns a new list with the results
 => (2 8 4 10)
 CL-USER> (cons 1 2)
 => (1 . 2)
 CL-USER> (mapcar #'cons '(A B C) '(1 2 3))
 => ((A . 1) (B . 2) (C . 3))
 CL-USER> (defun make-adder (how-much-to-add)
 	   (lambda (initial-value)
 	     (+ initial-value how-much-to-add)))
 => MAKE-ADDER
 CL-USER> (mapcar (make-adder 10) '(1 7 3 9))
 => (11 17 13 19)
 CL-USER> (defvar *my-favorite-adder* (make-adder 42))
 => *MY-FAVORITE-ADDER*
 CL-USER> (mapcar *my-favorite-adder* '(1 7 3 9))
 => (43 49 45 51)
 CL-USER> (defun make-modifier (operator operand) ; a bit more general than make-adder
 	   (lambda (initial-value)
 	     (funcall operator initial-value operand)))
 => MAKE-MODIFIER
 CL-USER> (mapcar (make-modifier #'expt 3) '(1 7 3 9))
 => (1 343 27 729)
 CL-USER> (find-if #'numberp '(a "hi" nil 8 "test" 100))
 => 8
 CL-USER> (find-if #'numberp '(a "hi" nil 8 "test" 100) :from-end t)
 => 100
 CL-USER> (apply #'+ (remove-if-not #'numberp '(a "hi" nil 8 "test" 100)))
 => 108

It is much more expressive than imperative/OO programming.

I especially like Haskell, in my opinion the most expressive language there is and at the forefront of new exciting programming features.

Haskell has an awesome typesystem. Statically typed but with optional declarations. It will infer the types by itself and verify consistency. You can ask the interpreter for the type of a specific function(and search hoogle to find a function with the type you desire). But it is not only interpreted, on the contrary it is a compiled language and a very fast one. Much faster than Python, Ruby etc, rivals C at some stuff and it scales without problems to multiple cores so that advantage will only grow. Pattern-matching, not only is thetypesystem very good for avoiding bugs but patternmatching really helps to make code more readable and makes it easier to verify that you have covered every case.

I also find functional code very beautiful and easy to read, here is a naive mergesort in haskell:

  merge :: (Ord t) => [t] -> [t] -> [t]
  merge xs [] = xs
  merge [] ys = ys
  merge (x:xs) (y:ys)
         | x < y       = x:(merge xs (y:ys))
         | otherwise   = y:(merge ys (x:xs))

  mergesort :: Ord a => [a] -> [a]
  mergesort []  = []
  mergesort [x] = [x]
  mergesort xs = merge (mergesort left) (mergesort right) 
            where
              middle = div (length xs) 2
              (left, right) = splitAt middle xs

Scala is also cool since it takes the best from both worlds and really delivers. Building on an already existing platform and also providing nice abstractions for concurrency and parallellism.

more generally, the composability of functions allows for more tacit programming. for example:

  array = [ 1, 2, 3 ]

  sort( array )

  print( array )

  print( sort( [ 1, 2, 3 ] ) )

from there you can enforce immutability, and then you have to worry even less about the state... because there isn't any

but to me that's extreme. the ideal of FP is nice, but taking something fundamentally dynamic like an algorithm or a working software system, and then trying to process it with something that can in its nicest terms be called anally rigid, is IMO fundamentally misguided. the only language in which i've seen this work is XSLT (a strict functional language,) because in its case you're dealing with rigid things to begin with (declarative XML documents) and on top of that it maps perfectly to its domain (XML documents are structured/"composed")

of course, strict FP has lots of benefits for the computer regarding optimization. but from a language design POV i'd rather give full power to the programmer and do my best to optimize later (eg via JIT)

so, IMO, use first-class functions all over the place and take advantage of the conceptual alleviation that composabilility offers, but consider the type-anal, FP-anal, OO-anal, and pretty much anything-anal languages to have been designed by crazy kooks who can't see the very wide line between theory and practice

"Functional programming is like describing your problem to a mathematician. Imperative programming is like giving instructions to an idiot." --- arcus, #scheme on Freenode (via http://community.schemewiki.org/?scheme-fortune-cookies)

You know how annoying it can be when you're trying to debug a function and it turns out it was acting weird because of a global variable? Functional programming is sort of like avoiding that sort of thing* , and then discovering that once you guarantee you won't mess with global state, it's suddenly possible to e.g. easily parallelize code, since you already know the processes won't interfere with each other's data. At the very least, it makes code much easier to test and debug, since there aren't "hidden variables".

* Maybe entirely, maybe just as a general rule -- long story.

When you have code that is "referentially transparent", that is, it doesn't have any side effects, there's also really no difference between doing something a thousand times or doing it once and caching the value, except the first wastes time. The language could potentially just cache it for you, or any of several other optimizations. (Or not waste time calculating results that it knows won't be used.)

Also, I'm of the opinion that when most people are talking about OOP, they're thinking OOP as implemented in C++ and/or Java. That's a very specific style of OOP, grafted somewhat uncomfortably onto C's type system. You may find OO makes more sense when you see how it works in Smalltalk, for example.

Alternatively, look at how it works in something like Lua, which is not in itself OO, but can easily have its core extended with any style of OO system by defining the language's hooks (called "metamethods") for handling table lookup and a few other things.