ФП для симуляции и моделирования

Я собираюсь начать проект моделирования / моделирования. Я уже знаю, что ООП используется для такого рода проектов. Однако изучение Haskell заставило меня задуматься об использовании парадигмы FP для моделирования системы компонентов. Позвольте мне уточнить:

Допустим, у меня есть компонент типа A, характеризуемый набором данных (такой параметр, как температура или давление, PDE и некоторые граничные условия и т. Д.), И компонент типа B, характеризующийся другим набором данных (отличающимся или один и тот же параметр, разные PDE и граничные условия). Предположим также, что функции / методы, которые будут применяться к каждому компоненту, одинаковы (например, метод Галеркина). Изменчивое состояние объекта будет использоваться для непостоянных параметров.

Если бы я использовал подход ООП, я бы создал два объекта, которые будут инкапсулировать данные каждого типа, методы для решения PDE (здесь будет использоваться наследование для повторного использования кода) и решение для PDE.

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

В заключение, будет ли реализация подхода FP на самом деле проще и проще в управлении (добавить компонент другого типа или новый метод для решения pde) по сравнению с ООП?

Я родом из C ++ / Fortran, плюс я не профессиональный программист, поэтому поправьте меня во всем, что я ошибся.

Хороший вопрос, я думал в том же духе. Исторически ОО-парадигма возникла из-за необходимости компьютерного моделирования - посмотрите историю Simula - и, несмотря на то, что ранние ОО-языки, такие как Smalltalk , создавались людьми, которые знали, что они делали (например, Алан Кей), ОО сейчас, вероятно, чрезмерно используются и вносит слишком много случайных сложностей .

Как правило, программы в стиле FP будут короче, проще для тестирования и проще в модификации, чем программы OO. Как сказал Роб Харроп в своем выступлении: «Будущее функционирует?» , вы никогда не можете стать проще, чем функции и данные; эти два составляют бесконечно, чтобы построить любые абстракции, необходимые. Итак, один из способов ответить на ваш вопрос (или я просто повторяю его? :) - это спросить, как выглядит функция высшего уровня, а как выглядят данные верхнего уровня -> выходные данные? Затем вы можете начать разбивать эти «альфа» функции и типы данных на следующий уровень абстракций и повторять при необходимости.

Другая точка зрения (не совсем ответы) на ваш вопрос заключается в том, чтобы взглянуть на эту ветку (заявление об отказе, я ее начал) в StackOverflow, некоторые ответы очень интересны: /programming/3431654/how-does- функционально-программирование применить к симуляции

Мое собственное мнение на данный момент таково, если вы не моделируете ситуацию, когда действительно существуют дискретные объекты, которые взаимодействуют только определенным образом (например, модель компьютерной сети) - и, таким образом, отображаются непосредственно на возможности чистого сообщения. Проходная парадигма ОО языка - проще перейти на ФП. Обратите внимание, что даже в сообществе разработчиков игр, где моделирование очень распространено и требования к производительности имеют первостепенное значение, опытные разработчики отходят от ОО-парадигмы и / или используют больше FP, например, см. Это обсуждение HN или комментарии Джона Кармака по FP

ИМХО почти для каждой задачи разумной сложности на вопрос «является ли стиль FP или стиль ООП лучшим выбором» нельзя ответить объективно. Как правило, в такой ситуации вопрос заключается не в «FP или OOP», а в том, как объединить лучшие части обеих парадигм для решения вашей проблемы.

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

С другой стороны, PDE являются уравнениями на функциях, и решение может снова быть функциональным. Таким образом, использование функционального подхода для этого типа «компонентов» может показаться здесь естественным. Эти функции могут иметь параметры матрицы, показывая один пример того, как объединить ООП и FP. Другим примером может быть реализация класса матрицы, которая использует функциональные инструменты для сопоставления определенной операции с каждым элементом вашей матрицы. Так что и здесь, это не «ООП против ФП», а «ООП в сочетании с ФП», который приносит вам лучшие результаты.