(Re)Reading "Why Functional Programming Matters"
I just finished (re)reading Why Functional Programming Matters by John Hughes (of QuickCheck fame) Its a paper from 1984, and I - vaguely - remember reading it a long time ago, and having absolutely no clue why any of it was relevant. Functional Programming was a couple of Lisp/AI courses that I was taking, with a healthy side dose of parentheses, recursion, and goofy syntax.
The paper makes a bit more sense this time, but unfortunately, it now makes sense in a Well, D-uh way. The main lessons are somewhat blindingly obvious, for those of us who are well-versed in The Erlang Way (or Haskell. Whatever)
If you don't feel like wading through the paper, Hughes makes the following points:
Modular Programming is Good
This is because modules, being limited in scope, are quick and easy to code. They can, fairly easily, be made re-usable (and hence can be re-used, decreasing future effort). Finally, because they are limited in scope, they are far far more testable, and easier to debug.
Programs are Glued Modules
Put differently, programs should consist of modules that are "glued" together. This was, back in the stone-age, actually a proposition that could be debated (remember the goto wars? No you don't. Thats ok.)
Functional Programming Provides Superior Glue
The primary "glue" in functional programming is the fact that functions can be glued together to create higher-order functions. This allows for remarkable extensibility in the language, as well as providing a mechanism for localizing the knowledge about the representation of complex datatypes (and modules!).
The second "glue" is lazy evaluation, i.e., holding off on the evaluation of modules (or functions) till there is actually a need to do so - since the order of execution is not particularly relevant. This, by the way, is next to impossible to do with imperative languages, since you really can't define the order of execution.
As I mentioned earlier, this is all pretty basic stuff now. I just wished I'd grokked things back then, instead of taking my life through these wacky detours into CORBA/C++ and Java/EJB. Ah well, if wishes were cows, I'd have a dairy farm…
PostNote: From an erlang perspective, the lazy evaluation point is irrelevant - erlang doesn't have any (hello "soft realtime"). However erlang is all about higher-order functions.
PostPostNote: Ok, it actually can be "made" to have lazy evaluation. But then again, you could also code in assembler
The paper makes a bit more sense this time, but unfortunately, it now makes sense in a Well, D-uh way. The main lessons are somewhat blindingly obvious, for those of us who are well-versed in The Erlang Way (or Haskell. Whatever)
If you don't feel like wading through the paper, Hughes makes the following points:
Modular Programming is Good
This is because modules, being limited in scope, are quick and easy to code. They can, fairly easily, be made re-usable (and hence can be re-used, decreasing future effort). Finally, because they are limited in scope, they are far far more testable, and easier to debug.
Programs are Glued Modules
Put differently, programs should consist of modules that are "glued" together. This was, back in the stone-age, actually a proposition that could be debated (remember the goto wars? No you don't. Thats ok.)
Functional Programming Provides Superior Glue
The primary "glue" in functional programming is the fact that functions can be glued together to create higher-order functions. This allows for remarkable extensibility in the language, as well as providing a mechanism for localizing the knowledge about the representation of complex datatypes (and modules!).The second "glue" is lazy evaluation, i.e., holding off on the evaluation of modules (or functions) till there is actually a need to do so - since the order of execution is not particularly relevant. This, by the way, is next to impossible to do with imperative languages, since you really can't define the order of execution.
As I mentioned earlier, this is all pretty basic stuff now. I just wished I'd grokked things back then, instead of taking my life through these wacky detours into CORBA/C++ and Java/EJB. Ah well, if wishes were cows, I'd have a dairy farm…
PostNote: From an erlang perspective, the lazy evaluation point is irrelevant - erlang doesn't have any (hello "soft realtime"). However erlang is all about higher-order functions.
PostPostNote: Ok, it actually can be "made" to have lazy evaluation. But then again, you could also code in assembler
Comments