Non-numerical use cases for functional programming?

Question

I just finished reading a book on scala. What strikes me is that every single example in the whole book was numerical in some form or another.

Like a lot of programm

Answer 1

Pattern matching is also a place where functional programming shines, making it really useful in areas such as Bioinformatics.

However, given great compilers we have today, functional programming shines nearly everywhere.

Answer 2

These days, I wouldn't even consider writing a DSL lexer/parser in a non-functional language (in broad sense of the term). ADTs and pattern matching make it so much easier.

Answer 3

The more I use a functional style, the better I like it. Consider this Python fragment from another question:

>>> testlist
[1, 2, 3, 5, 3, 1, 2, 1, 6]
>>> [i for i,x in enumerate(testlist) if x == 1]
[0, 5, 7]

This is admittedly a more or less mathematical statement, but there are lots of generators in Python. Once you get used to it, using a list comprehension in place of a loop is both easy to understand, and less likely to have a bug (you don't get "off by one" bugs.)

Answer 4

Bridging the algorithm gap: A linear-time functional program for paragraph formatting (1997)
by Oege De Moor, Jeremy Gibbons
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.7923

Structuring Graphical Paradigms in TkGofer (1997) by Koen Claessen, Ton Vullinghs, Erik Meijer http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.5525

Modelling office processes with functional parsers (1994) by Gert Florijn
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.1307

Answer 5

Got another one for you:

I'm involved in the very early stages of prototyping a suite of new enterprise-scale financial products intended for small-to-medium sized banks, local government, stock exchanges, etc. You're probably thinking "oh, financial code, you must be doing a lot of math" -- actually, no. These products are intended to be highly customizable and allow users to inject business rules at strategic points in the application.

We're using F# to represent and interpret business rules. To use a naive example, lets we're writing some code for check processing, we might write the rules like this:

type condition =
    | Test of string
    | And of condition * condition
    | Or of condition * condition
    | Not of condition

type transactionWorkflow =
    | Reject
    | Approve
    | AdministratorOverride of string
    | If of condition * transactionWorkflow list
         (* condition,  true condition *)
    | IfElse of condition * transactionWorkflow list * transactionWorkflow list
         (* condition,      true condition,            false condition *)
    | AttachForms of string list

Using a special application, users can write some business rules represented by the structure above. For example:

let checkProcessingWorkflow =
    [If(Test("account doesn't exist")
        ,[AdministratorOverride("Account doesn't exist. Continue?");
          AttachForms ["40808A - Null Account Deposit"]]
       );
     If(Test("deposit > 10000")
        ,[
            If(And(Test("account created within 3 months")
                   ,Test("out of country check"))
               ,[Reject]);
            IfElse(Test("account state = TX")
                    ,[AttachForms ["16A"; "16B"]]
                    ,[AttachForms ["1018"]]
                 )
         ]
       );
     Approve
    ]

So, rather than writing one business-rules engine to rule them all, we handle certain processes as a very tiny domain-specific language intepreted by F#. I'm hoping this approach will allow us to design very simple business-readable DSLs without needed to detect conflicting rules.

Of course, everything above is just concept-code, and we're still in the very earlier stages of even prototyping one of our rules system. We're using F# rather than Java or C# for one particular reason: pattern matching.

Answer 6

Functional programming is a paradigm like procedural/structured, object-oriented, and generic/templated programming are. It's turing-complete so you can do anything you want.

Aside from math and science, it's makes it easier for parser combinators, artifical intelligence, concurrency, dynamic evaluation, co-routines, continuations, terse notation (faster brain-to-keyboard-to-text-file cycle and less code to maintain), strongly-typed parametization (see Haskell's algebraic types) and dynamic self-reflection (e.g., minimalistic metacircular interpreters with a REPL).