Функциональное программирование для основных алгоритмов

Почти все языки функционального программирования имеют некоторую конструкцию, позволяющую осуществлять императивное кодирование (например, do в Haskell). Есть много проблемных областей, которые нельзя решить с помощью «чистого» функционального программирования. Один из них - сетевые протоколы, например, когда вам требуется последовательность команд в правильном порядке. И такие вещи плохо поддаются чистому функциональному программированию.

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

Это работает довольно хорошо, наоборот, эмуляция функционала в императивном стиле.

Помните, что внутренняя часть интерпретатора или виртуальной машины настолько близка к металлу и критична к производительности, что вам даже следует подумать о переходе на уровень сборки и подсчитать тактовые циклы для каждого инструкция (например, Smalltalk Dophin просто делает это, и результаты впечатляют). ЦП обязательны.

Но нет проблем с выполнением всей базовой реализации алгоритма - тот, который вы упомянули, является НЕ низким уровнем - они являются базовыми.

I don't know about list sorting, but you'd be hard pressed to bootstrapp a language without some kind of string matching in the compiler or runtime. So you need that routine to create the language. As there isn't a great deal of point writing the same code twice, when you create the library for matching strings within the language, you call the code written earlier. The degree to which this happens in successive releases will depend on how self hosting the language is, but unless that's a strong design goal there won't be any reason to change it.

Это часть SDK (.NET, или теперь Windows SDK )

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

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

См. также

Как функциональное программирование влияет на структуру вашего кода?

1) По какому стандарту подходит? Какие свойства вы хотите?

Сортировка списка? Легко. Давайте сделаем быструю сортировку на Haskell:

sort [] = []
sort (x:xs) = sort (filter (< x) xs) ++ [x] ++ sort (filter (>= x) xs)

Этот код имеет то преимущество, что он чрезвычайно прост для понимания. Если список пуст, он отсортирован. В противном случае вызовите первый элемент x, найдите элементы меньше x и отсортируйте их, найдите элементы больше x и отсортируйте их. Затем объедините отсортированные списки с x посередине. Попробуйте сделать это понятным в C ++.

Конечно, Mergesort намного быстрее сортирует связанные списки, но код также в 6 раз длиннее.

2) Очень легко реализовать императивный стиль, оставаясь при этом чисто функциональным. Суть императивного стиля - последовательность действий. Действия упорядочены в чистой настройке с использованием монад. Суть монад - это функция привязки:

(Monad m) => (>>=) :: m a -> (a -> m b) -> m b

Эта функция существует в C ++ и называется ; .

Последовательность действий в Haskell, например, записывается следующим образом:

putStrLn "What's your name?" >>=
  const (getLine >>= \name -> putStrLn ("Hello, " ++ name))

Доступен некоторый синтаксический сахар, чтобы это выглядело более привлекательно. обязательно (но обратите внимание, что это тот же код ):

do {
  putStrLn "What's your name?";
  name <- getLine;
  putStrLn ("Hello, " ++ name);
}