I\'ve just recently discovered the functional programming style and I\'m convinced that it will reduce development efforts, make code easier to read, make software more main
If by the 'functional style' you mean the usage of concepts like 'map', 'apply', 'reduce', 'filter', lambda functions and list comprehensions, then it should be evident that code that has to deal with operations on lists is almost always more concise when written in the 'functional style'. But if you're mixing 'functional style' with imperative code in a mostly imperative language, it really is just a matter of style.
In python for example, you can reimplement the Haskell qsort crackmigg posted like so:
def qsort(list):
if list == []:
return []
else:
x = list[0]; xs = list[1:]
return qsort(filter(lambda y: y= x, xs))
Although writing the last line as
return qsort([y for y in xs if y=x])
is arguably more 'pythonic'.
But this is obviously more concise than the implementation here:
http://hetland.org/coding/python/quicksort.html
Which, incidentally, is how I would have thought about implementing it before I learned Haskell.
The functional version is extremely clear if and only if you are acclimated to functional programming and grok what filter
is going to do as easily as the well-worn C++ programmer groks a for
loop without even having to think much about it. And that's clearly what the real issue at stake here: functional 'style' programming is a completely different mindset. If the people you work with aren't used to thinking recursively, and aren't the type to get excited about, not just a new technology, but a whole other way of thinking about solving their problems, then any amount of code comparisons isn't going to win them over.