Без контекста нельзя ничего утверждать :) В соседнем канале была ссылка на современные игры для загрузочного сектора. Это всего 512 байт. Вот здесь лишние абстракции могут только повредить. С другой стороны — для такого малого объема можно использовать синтез программ и, возможно, реализовать его имено на Haskell :)

То что что-то где-то не используется в данное время не означает, что оно там не нужно/не подходит. Когда МакКарти создавал ЛИСП все кругом вообще писали только на Ассемблере - ЛИСП был "не нужен" и слишком медленный, а поди ж ты! 😉
Я не говорю, что ФП - это священный грааль для эмбеддеда, но это не из-за каких-то фундаментальных проблем ФП, а больше из-за мелких технических ограничений - отсутствия компиляторов, библиотек и прочей интеграции в картину и практику.

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

На Лиспе в свое время было создано немало, как сейчас говорят, "не имеющих аналогов" программ. Код тех же Eliza, Shrdlu, Macsyma и проч. даже сейчас полезно изучать. Но современное ФП, как мне кажется, не про это. В основном, я вижу вторичные реализации систем, которые были разработаны на иных ЯП. И, возможно, в этом есть свой смысл. Сначала exploratory programming на каком-нибудь Python/Julia/..., а затем аккуратное перенесение устоявшегося решения на строгий ФЯ, где разработчик будет заниматься не архитектурой, в вопросами корректности, мат. строгости кода.

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

Интересно, я вот что-то с ходу не припомню систем, разработанных на других языках, и перенесённых на ФП. Тут, видимо, у кого какие источники трафика. 😊

А Вы какую предметную область имеете в виду, и какой у неё аппарат?

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

Я в последних сообщениях говорил об embedded.

Но функции - это не лишние абстракции. Они базовые. Если нам потребуется определенить понятие ассемблерной инструкции, без функций не обойтись. С точки зрения математики эти 512 байтов - функциональная программа в определённой монаде, где инструкции - это функции.

Я вот соглашусть, например I/O очень плохо вписывается в FP парадигму, так как почти все фунции там не чистые, и нужно обмазываться монадичными структурами (State, IO) и в конечном итоге все это вглядит как будто пытаются натянуть сову на глобус)

Мы же вроде бы договорились, что у математики множество точек зрения, а выбирать нужно ту, которая наиболее соответствует конкретной задаче. Я пока не вижу, что Вы, вооруженный понятием монады, сможете противопоставить демокодеру-ветерану :)

Скорее всего, демокодер-ветеран и так во всю использует понятие монады, просто не явно.

Ну конечно, все есть монада даже оператор запятая;)

В теории, да. Ну, и, как бы, теорию знать полезно, когда изобретаешь велосипеды.

Вызов функции, кстати, тоже монада. И об этом забывают в Haskell, например :)

Тут, конечно, вопрос терминологии, но я бы не говорил, что embedded - это предметная область. Для меня "предметная область" - это то, чем занимаются люди, для чего мы разрабатываем систему. Например, разработка embedded системы для приставки smart TV - это одна предметная область, а разработка автомобильной навигационной системы - другая.
Так что для меня embedded - это раздел (программной) инженерии. То, что в этой области сложились определённые практики и стандарты моделирования, использующие определённые формализмы - явление не фундаментальное, а социальное и техническое. Поэтому эти практики и стандарты меняются с течением времени. Мне кажется, что с этим течением времени в область embedded-разработки будет просачиваться всё больше ФП, в том числе вместе с зав. типами и прочим correct-by-construction и верифицированным программированием.

Это всего лишь вопрос привычки! 😂

Для человека с молотком все становится похоже на гвоздь :)

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

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

Конечно, особенно сейчас (когда тяжеловесные OC в духе Linux и совсем сомнительные штуки в духе microPython проникли в embedded) это очень широкая область. Но это явно нечто иное, чем HPC или frontend/GUI, о которых ранее шла речь здесь. И я не вижу, как современный ФП может быть заменой древним подходам в духе сетей Петри, иерархических КА, процессов Кана и проч. ФП может появиться на конечных стадиях процесса уточнения моделей системы. В целом его место, как мне кажется, на этапе реализации, а не проектирования. Ровно в том же духе, как в случае с ООП.

Сети Петри на практике - это жуть. Гораздо большая, чем монады.