Why Why Functional Programming Matters Matters

"Why \"Why Functional Programming Matters\" Matters" Considered Harmful

Why "\"Why \\\"Why Functional Programing Matters\\\" Matters\" Considered Harmful" Matters

What does "powerful" mean, in programming lanugages? I can think of three meanings:

(1) what it can do. Once a language is Turing complete (call this 1.1), in one sense it can do anything. In another sense (1.2), maybe it can't: I wouldn't attept to write a Unix kernel in Java or a 3-D graphics library in Python because in both cases they are too high level of the task.

(2) how easy it is to program in? I.e. the number of programmer-hours it takes to solve a problem in that language.

(3) how easy it is to automatically reason about programs written in the language. This includes tools such as compilers, source code coverage tools, etc.

Now let's examine the original statement by these 4 criteria. We'll also consider the obverse, i.e. whether you can make a language less powerful by adding features.:

1.1 - if a language is already Turing-complete, removing features won't make it more so. Nor will adding features make it less powerful. But Turing-completeness is a trivial sense, as the article points out.

1.2 - adding eatures can make a language less powerful in this sense, because it can reduce the things it can do. For example, a big complex language with a large standard library might not work on a simple embedded controller, so in that sense it could do less. Or a language might require a certain model of multitasking that means it can't run on certain OS's (e.g. Java couldn't run on early versions of Windows (IIRC either 3.1 or 95 -- I don't remember the details). Or consider that Java is "write-once run anywhere"; adding lots of low level features might imperil this.

2 -- adding features can certainly reduce power here too, e.g. if you have a large C++ program written by a team of programmers each of whom uses a different subset of the language.

3. -- again, adding features can reduce power. For example, in Fortran, an optimising compiler can make assumptions about the code that a C++ compiler can't make because C++ allows pointers to point to anything, e.g.:

   int foo(int a, int* b){
      a = 1;
      *b = 2;
      bar(a); /* we don't know here if bar is being called
                 with parameter of 1 or 2 */ 
   }

In a game design where you have important information about a rule smeared all over the object hierarchy, you have very poor separation of concerns. It looks at first like there’s a clear factoring “Baltic Avenue has a method called isUpgradableToHotel,” but when you look more closely you realize that every object representing a property is burdened with knowing almost all of the rules of the game.

Hmm,

A "noun" or OO language would make each property part of the property class and that would solve the problem so-far as he's articulating it.

The thing is, how would a 'verb' oriented language deal with a very specific kind of noun, one which both reacting to general verbs differently and required it's own special verbs. It seems like this special noun would 'smeared' around the verbs to a worse extent. If Baltic Avenue has some weird behavior, it seems cleaner to have it as separate subclass than having it's behavior taken into by various conditionals.

Similarly, think about the design of a Chess game. The verbs would be 'move', 'capture'. It seems cleaner to make these verbs into 'messages' or member functions that each piece responds to according to it's class, rather than creating a single method that might call submethods.

Still, it's a nice discussion.