Commercial Uses of Functional Programming

Commercial Use articles focus on functional programming "as a means, not an end". As such, we solicit papers about experiences using functional languages in commercial and open source settings. The purpose of a Commercial Use article is to document and assess cases where functional programming was used in a real world setting. We are interested not only in successes, but also in failures. Articles should distill experiences using functional languages so that others can learn from those experiences, whether the lessons learned be technical, organizational, or about the narratives used to make the case to management.

A Commercial Use article is distinguished from a normal JFP paper by its title, its length, and the criteria used to evaluate it. The title of each accepted Commercial Use article must begin with the words "Commercial Uses'' followed by a colon. Commercial Use articles will typically, but not necessarily, be shorter in length than normal JFP papers. The suggested length is 5 to 10 JFP pages.

A Commercial Use article should make clear points about the efficacy of functional programming and provide supporting evidence. The content of the article must be relevant to JFP, but it need not be novel. The editors will accept or reject Commercial Use articles based on whether they judge the material to be relevant and the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. The editors will be especially convinced by evidence that includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people.

A Commercial Use article should be short and to the point: if functional programming worked for you in the same ways it has worked for others, you need only to summarize the results, the main part of your paper should discuss how well it worked and in what context. Most readers will not want to know all the details of your project and its implementation, but please characterise your project and its context well enough so that readers can judge to what degree your experience is relevant to their own projects. Be especially careful to highlight any unusual aspects of your project. Also keep in mind that specifics about your project are more valuable than generalities about functional programming; for example, it is more valuable to say that your team delivered its software a month ahead of schedule than it is to say that functional programming made your team more productive. While we want you to be as specific as possible, we do not want you to give away any trade secrets!

If you are considering writing a Commercial Use article, the following list suggests some questions you might want to address in your article:

• What is your problem domain?  A brief review will help to set the context for your experience.
• What is the nature of your organization?  How did that nature impact the use of functional languages?
• Why did you pick a functional language?
• Why did you pick the particular language(s) that you did?
• What were the advantages and disadvantages of your choice?
• What worked well and what didn't?
• Would you do it again?  Why?
• Did using a functional language give you a competitive advantage? Why?
• How did the available software tools affect your project?
• What changes to the functional language would make it easier to use?
• What insights did you gain from real-world projects using functional languages?
• How did your experience using a functional language compare with using a conventional language?
• What process did you use to convince management to adopt a functional approach?
• How did using functional languages impact finding and retaining engineers?
• What project-management, business, or legal issues did you encounter?

A single article need not address all these questions. Nor should it simply list the questions and provide answers to them. Rather, it should tell the story of your project and use of functional languages.

If you have questions about these guidelines and whether to submit a particular article, please feel free to contact the editor.