Further evidence of the increasing commercial relevance of functional programming (and just as important, the desire of the academic community for said relevance) is the announcement that the Journal of Functional Programming is now accepting Commercial Use articles.

The software engineering (SE) community and the programming language theory (PLT) community have traditionally been quite separate. This has led to much duplication of work. For example, it is well known that patterns are language features, indicating that the two communities have essentially been solving the same problems from different angles. The SE field assumes the language is fixed, and so develops abstractions (i.e. patterns) that exist above the level of code. The PLT researcher changes the language to directly express the abstraction. The SE approach is pragmatic but inelegant. The promise of the PLT approach has been retaining elegance (with associated reduction in development and maintenance cost), but the cost of adopting a new language is often seen as too high. (Incidentally, solving this problem is why you want a language with macros. I.e. Scheme.)

That the JFP is looking to publish essentially SE articles is definitely a good thing. It will, however, be interesting to see how the community adapts to members with quite different aims and values to the typical PLT researcher. For example, the PLT researcher is very focused on formality, and in particular giving precise semantics to language constructs. This leads to a style that deals with concepts in a very abstract mathematical manner. While powerful this is certainly not the best presentation for a working programmer to learn from. Consider, for example, Comprehending monads, which aims to be an easy introduction to monads. Given that this paper was published in 1992, we can see its ineffectiveness as a tutorial by considering the zillions of monad tutorials that have been written since. The problem is the abstract style of presentation. While presenting in an abstract style allows you to generalise to many different situations, people work best going from the specific to the general. Better tutorials start with a concrete example, and abstract from there. The question for the PLT community is how they will accommodate the desire for less formality and abstraction from the working programmer when one of the key differentiating factors between SE and PLT is the use of formalisms. If the right balance can be found this will be a great thing for both researchers and practitioners.