Functional programming: A step backward

Functional programming languages will have a place in general application development when we can read their code at a glance

Page 2 of 2

There are many places where functional programming and functional programming languages are a great fit and probably the best approach. For pure mathematical calculation, functional programming is actually clearer than imperative programming. But for business software and other general application software, exactly the opposite is true. As Martin Fowler famously said, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." The syntax of functional programming just isn't readable at a glance.

A couple of code snippets will show you what I mean. An example from Erlang:


by_length(Lists) ->
   qsort(Lists, fun(A,B) -> A < B end).

qsort([], _)-> [];
qsort([Pivot|Rest], Smaller) ->
   qsort([X || X <- Rest, Smaller(X,Pivot)], Smaller)
   ++ [Pivot] ++
   qsort([Y || Y <- Rest, not(Smaller(Y, Pivot))], Smaller).

And one from Haskell:

-- file: ch05/Prettify.hs
pretty width x = best 0 [x]
    where best col (d:ds) =
              case d of
                Empty -> best col ds
                Char c -> c : best (col + 1) ds
                Text s -> s ++ best (col + length s) ds
                Line -> '\n' : best 0 ds
                a `Concat` b -> best col (a:b:ds)
                a `Union` b -> nicest col (best col (a:ds))
                                      (best col (b:ds))
          best _ _ = ""

          nicest col a b | (width - least) `fits` a = a
                         | otherwise = b
                         where least = min width col

Man versus machine
Any halfway decent programmer can quickly glean the general intent of most imperative code -- even in a language he or she has never seen. While you can certainly figure out what functional routines do by looking at them, it may not be possible in a glance. Unlike imperative code, functional code doesn't map to simple language constructs. Rather, it maps to mathematical constructs.

We've gone from wiring to punch cards to assembler to macro assembler to C (a very fancy macro assembler) and on to higher-level languages that abstract away much of the old machine complexity. Each step has taken us a little closer to the scene in "Star Trek IV" where a baffled Mr. Scott tries to speak instructions into a mouse ("Hello computer"). After decades of progress in making programming languages easier for humans to read and understand, functional programming syntax turns back the clock.

Functional programming addresses the concurrency problem of state but often at a cost of human readability. Functional programmming may be entirely appropriate for many circumstances. Ironically, it might even help bring computer and human languages closer together indirectly through defining domain-specific languages. But its difficult syntax makes it an extremely poor fit for general-purpose application programming. Don't jump on this bandwagon just yet -- especially for risk-averse projects.

This article, "Functional programming: A step backward," was originally published at Follow the latest developments in business technology news and get a digest of the key stories each day in the InfoWorld Daily newsletter. For the latest business technology news, follow InfoWorld on Twitter.

| 1 2 Page 2
From CIO: 8 Free Online Courses to Grow Your Tech Skills
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.