1. 39

    …this is a critique of fp that is both informed and aims to be balanced.

    It’s not. It’s trivial and insipid, hinging its main argument on the claim that “The syntax of functional programming just isn’t readable at a glance.” Whether or not code is readable at a glance is really dependent on a vast number of factors, and furthermore the author expects that we accept, unequivocally, this vague notion of “readability” being a critically important factor in choosing a language. I don’t always agree with Martin Fowler but I doubt he’d approach the argument with the same lack of nuance. Quoting him to bolster the point is an appeal to authority which doesn’t even hit the mark.

    It’s easy to find more to criticize in this piece, but more generally I think we should stop with these OO vs. Functional programming articles–the reality is that it’s much more illuminating and meaningful to talk about specific choices in a given language or languages and compare and contrast what programming styles they enable or promote, or what therefore becomes difficult because of specific choices. I like reading about philosophies underpinning the structure of a language or the history of a language feature…etc. I agree with what sdiehl wrote: there are so many interesting dimensions to discuss–why bother with a piece like this?

    1. 10

      It is hilarious as well, since the author quotes Quicksort in Erlang as hard to read whereas Quicksort in an imperative language like C is even worse to read and understand and most importantly, to get right. The argument is completely flawed.

      1. 2

        While I don’t disagree with you about the problems in the article, I do feel like that C implementation of quicksort you linked to as an example of poor readability has readability problems primarily because of extremely poor variable naming, something which is easy to fix (though that’s perhaps not the only problem, but it is the one that will stand out the most to people). That kind of poor naming seems to be ingrained in C programming culture which is unfortunate. I write C code myself and I always use descriptive names anyway. I’m also not really sure I agree that implementing quicksort in C is hard to get right, at least not moreso then with most other imperative languages.

        1. 1

          I think the readability problems with the functional implementations are primarily because of extremely poor function naming, which unfortunately seems ingrained in Haskell programming culture.

          1. 2

            I doubt the names are poor, but rather, unfamiliar to a general audience. Most programmers don’t understand the theory from which they originate.

            1. 2

              No, I think they’re badly named even within the theory. Too many symbols that would be better as words, and too much inconsistency just because of traditions in the field (e.g. “type constructor”).

      2. 7

        “The syntax of functional programming just isn’t readable at a glance.”

        I really hate syntax arguments. They hide systematic arguments.

        For example, good object-oriented systems have the habit that everything happens somewhere else. This can be extremely confusing and hard to grasp at a glance (though not necessarily bad, systematically thinking). It has nothing to do with syntax, though.

        1. 4

          Take my python fan advice as it is.

          I think readability is not a critically important factor, but it is important as a lots of others. One of other important dimension is as believe how much immutability of data structures there is built in language (and here python is really poor)