Что некоторые проблемы лучшие/хуже обращенный функциональным программированием?

Я бы сказал, что функциональное программирование подходит для решения проблем, например, задач ИИ, математических задач (это слишком просто), игровой движок, но не слишком хорошо подходит для разработки графического интерфейса и пользовательских элементов управления или настольных приложений, требующих модного пользовательского интерфейса. Я считаю интуитивно понятным думать следующим образом (хотя это может быть слишком обобщающим):

            Back-end   Front-end
Low-level   C          C++
High-level  FP         VB, C#

Некоторые проблемы, которые я считаю подходящими для функционального программирования:

• параллелизм
• компиляторы
• создание сценариев

Проблемы, которые лично я считаю не очень подходящими:

• веб-приложения ( но это, вероятно, только я, Hacker News, например, реализован в LISP)
• настольные приложения
• игровые движки
• вещи, в которых вы передаете много состояний

Я считаю, что простота функционального программирования для математических задач с матричной математикой абсолютно прекрасна, посмотрите, как эти типы задач решаются в схеме!

Я считаю, что Haskell также хорошо подходит для любых задач, связанных с математикой. Не то чтобы это настоящий профессиональный проект, но я сделал с его помощью решатель судоку и анализатор покера. Прекрасно иметь программу, которая математически доказуема.

Насколько она не подходит, так это то, для чего производительность является приоритетом. У вас меньше контроля над используемыми алгоритмами, поскольку они более декларативны, чем императивны.

Я не согласен с тем, что FP нельзя использовать для веб-приложений. Я знаю, что Пол Грэм и Роберт Моррис основали Viaweb, который использовал Lisp для доставки веб-приложений. Я думаю, что по мере приближения к оборудованию (драйверы устройств, ядро ​​и т. Д.) Нужно использовать как можно более низкий уровень языка. Это связано с тем, что чем больше абстракций используется, тем труднее отлаживать в случае ошибок. Взгляните на статью Джоэла Спольски «Закон протекающей абстракции»

It may not be directly tied to functional programming, but nothing beats unions in the design and implementation of data structures. Let's compare two equivalent pieces of code:

F#:

type 'a stack = Cons of 'a * stack | Nil
let rec to_seq = function
    | Nil -> Seq.empty;
    | Cons(hd, tl) -> seq { yield hd; yield! to_seq tl }
let rec append x y =
    match x with
    | Nil -> y
    | Cons(hd, tl) -> Cons(hd, append tl y)
let x = Cons(1, Cons(2, Cons(3, Cons(4, Nil))))
let y = Cons(5, Cons(6, Cons(7, Cons(8, Nil))))
let z = append x y
to_seq z |> Seq.iter (fun x -> printfn "%i" x)

Java:

interface IStack<T> extends Iterable<T>
{
    IStack<T> Push(T value);
    IStack<T> Pop();
    T Peek();
    boolean IsEmpty();
}
final class EmptyStack<T> implements IStack<T>
{
    public boolean IsEmpty() { return true; }
    public IStack<T> Push(T value) { return Stack.cons(value, this); }
    public IStack<T> Pop() { throw new Error("Empty Stack"); }
    public T Peek() { throw new Error("Empty Stack"); }
    public java.util.Iterator<T> iterator()
    {
        return new java.util.Iterator<T>()
        {
            public boolean hasNext() { return false; }
            public T next() { return null; }
            public void remove() { }
        };
    }
}
final class Stack<T> implements IStack<T>
{
    public static <T> IStack<T> cons(T hd, IStack<T> tl) { return new Stack<T>(hd, tl); }
    public static <T> IStack<T> append(IStack<T> x, IStack<T> y)
    {
        return x.IsEmpty() ? y : new Stack(x.Peek(), append(x.Pop(), y));
    }
    private final T hd;
    private final IStack<T> tl;
    private Stack(T hd, IStack<T> tl)
    {
        this.hd = hd;
        this.tl = tl;
    }
    public IStack<T> Push(T value) { return new <T> Stack(value, this); }
    public IStack<T> Pop() { return this.tl; }
    public T Peek() { return this.hd; }
    public boolean IsEmpty() { return false; }
    public java.util.Iterator<T> iterator()
    {
        final IStack<T> outer = this;
        return new java.util.Iterator<T>()
        {
            private IStack<T> current = outer;
            public boolean hasNext() { return !current.IsEmpty(); }
            public T next()
            {
                T hd = current.Peek();
                current = current.Pop();
                return hd;
            }
            public void remove() { }
        };
    }
}
public class Main
{
    public static void main(String[] args)
    {
        IStack<Integer> x = Stack.cons(1, Stack.cons(2, Stack.cons(3, Stack.cons(4, new EmptyStack()))));
        IStack<Integer> y = Stack.cons(5, Stack.cons(6, Stack.cons(7, Stack.cons(8, new EmptyStack()))));
        IStack<Integer> z = Stack.append(x, y);

        for (Integer num : z)
        {
            System.out.printf("%s ", num);
        }
    }
}

Функциональное программирование подходит для параллельного программирования. Тот факт, что вы не полагаетесь на изменения состояния при функциональном программировании, означает, что различные процессоры / ядра не будут вмешиваться друг в друга. Таким образом, типы алгоритмов, которые хорошо подходят для параллелизма, такие как сжатие, графические эффекты и некоторые сложные математические задачи, также обычно являются хорошими кандидатами для функционального программирования. И тот факт, что популярность многоядерных процессоров и графических процессоров только растет, также означает, что спрос на такие устройства будет расти.

Я бы сказал, что при функциональном программировании возникнут проблемы с низкоуровневым материалом, операционной системой ядра, драйверы устройств и т. д.

Я сказал «есть проблемы», а не «не может использоваться» (из-за эквивалентности Тьюринга все может быть использовано для чего угодно).

Интересный вопрос: является ли эта проблема фундаментальной в функциональное программирование (поскольку физические устройства имеют состояние) или если мы можем представить себе системно-ориентированный функциональный язык программирования / среды. Например, BitC работает только частично (он во многом зависит от изменчивости).

На самом деле, мне нравится использовать чистый функциональный код для задач, требующих управления большим количеством состояний. Подобные языки обычно предоставляют лучшие механизмы для явной обработки состояния, поскольку они не позволяют вам делать это неявно. Неявное управление состоянием может показаться более простым в малом масштабе, но как только состояние начинает усложняться, вы сталкиваетесь с проблемами без гарантий правильности, которые вы получаете, делая это методом FP.