В embedded, конечно, есть реализации ФЯ, но погоды это не делает. Мне кажется, в какой-то момент полезно перейти от уровня парадигм программирования к формализмам и моделям из предметной области. При этом не вижу особой пользы в привязывании этих моделей и формализмов к конкретным ООП и ФП. Зачем ставить эти самые ФП и Ко во главу угла при формализации практических задач? Это часто затеняет, усложняет изначально простые понятия и подходы.

Раз уж речь пошла о встраиваемых системах, давайте откроем один из солидных учебников -- Embedded System Design Питера Марведеля. Там есть очень хороший раздел на тему спецификаций и моделей. Никакого ФП нет просто потому, что речь идет о конкретной предметной области. Реплика в духе "а в ФП тоже можно" -- специалистов из этой области совершенно не удовлетворит :)

кстати говоря об абстракциях - а разве ФП-языки могут обходиться без сборщика мусора?

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

Графы — тоже язык математики. Сети Петри, SDF-процессы и проч. — тоже математика.

Да, но это всё описывается функциями.

Графы — тоже язык математики. Сети Петри, SDF-процессы и проч. — тоже математика.

А множества еще фундаментальнее :)

А множества еще фундаментальнее :)

Тут ещё одно условие требуется - чтобы перенести модель на компьютер без реинжениринга, модель должна обладать вычислительной семантикой. У большинства перечисленных моделей с этим не очень хорошо.

А как же тогда работают синхронные языки? :)

До сих пор спорят, что фундаментальнее. Но особенность в том, что с функциями мы можем более менее адекватно программировать, а со множествами - не очень.

Особенность как раз в том, что создания программно-аппаратной системы, которая работает в реальном времени, ни то, ни другое не является адекватным формализмом. Есть же колоссальная разница между можно описать и — нужно. И разница эта ощущается именно при практической деятельности, при конструировании систем.

Особенность как раз в том, что создания программно-аппаратной системы, которая работает в реальном времени, ни то, ни другое не является адекватным формализмом. Есть же колоссальная разница между можно описать и — нужно. И разница эта ощущается именно при практической деятельности, при конструировании систем.

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

Я просто еще раз предлагаю посмотреть, что пишут в соотв. учебниках по electronic/embedded system level design. С этим можно не соглашаться, но именно так сейчас создают спецификации и модели для hw/sw систем.