Интерпретатор или компилятор чего угодно написать всегда можно - но это отдельные программы, которые никак потом не объеденишь с компилятором самого паскаля. А реализовать средствами самого языка? А я именно об этом.
Не знаю в какие Вы дебри хотите зайти, но я говорю про то, что удобнее для решение задачи. фп не панацея, а паскаль безнадежно устарел.
Это слишком упрощенный взгляд на ООП. Или слишком широкий - под такое определение можно подвести все, что угодно.
Это как же: оставаясь в рамках ФП, можно реализовать парадигму ООП? Не решить некую задачу, уже решенную методами ООП, а именно реализовать парадигму ООП?
Я имел в виду, что если мы вооружимся некоторой функцией, которая сможет ставить по каким-то свойствам данным(метаданным) для них функцию-обработчик, то мы получим на ФП реализацию ООП. В этой функции реализовываем наследование, и вуаля, получаем полиморфизм. Вот и выходит : "ооп - синтаксический сахар".По-моему где-то на лиспе реализовали ооп примерно в таком ключе.Но на лиспе для таких трюков есть кое-что кроме фп, а именно естественная среда для метапрограммирования.
И зеркальный вопрос: можно ли, оставаясь в рамках ООП, реализовать парадигму ФП? Только не говорите нет, не попадайтесь в ловушку.
Либо я не понял, в каком смысле подмножество.
Я про стили мышления! Я говорю про кирпичики,из которых программист составляет решение задачи. В моем представлении кирпичики-зависимости проще кирпичиков-объектов.
Это приготовление обеда или уборка квартиры?
Бизнес-приложения
по-моему очень даже бытовое. ООП тут очень, очень удобно. Не думаю, что я бы захотел писать реализацию бизнес-процессов на ФП. зачем это?)
Так ведь прикладник будущий только. Посмотрит он на всю эту дискуссию и сразу вспомнит первую часть анекдота про воздушный шар...
Меня как прикладника сильно перевернуло знакомство с ФП и анекдота, увы, не знаю