Observations

ф функциональных языках принято такие длинные функции расклеивать на череду более коротких, которые могут обрастать параметрами по мере необходимости (употребил праметры, переработал, послал дальше). в чисто-функциональных языках вроде хасекла ничего кроме функций нет, все данные абсолютно immutable и этот паттерн склеивания функций кто-то при царе горохе в шутку назвал "монадой". у ляйбница всё в мире вплоть до бога состоит из одних только монад... оно действительно относительно удобно когда просечёшь вывернутый наизнанку синтаксис склеивания.

From:

А вот State Machine на Scala?

From:

в принципе можно, но зачем? вся грязь типа mutable state в функциональных языках делегирована "платформе", в которой все нужные стейт машины реализованы под ключ. в языках основанных на ML, вроде скалы, главная стейт машина в платформе - матчер паттернов, заменяющий очень кудрявый branching в более обычных языках одной-двумя дивно выглядящими строчками прокидывающими сматченное в простые функции.

From:

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

From:

В F# есть и циклы, и переменные которые можно поменять (аж двух видов) и даже прямой доступ к байтам в памяти, но в целом в нём меньше шума который хочешь-не хочешь придётся написать если делать то же самое на C#. на уровне железа, если рассматривать ipx как пример, функциональный подход тоже применим. машина решающая любые задачи обречена на пониженный кпд, функциональные языки просто убирают boilerplate crap... где-то так

From:

и тут меня осенило - когда c++ peoples говорит про "стейт машину" он имеет в виду что угодно кроме собственно "конченого автомата" как средства решения той или иной проблемы, а думает исключительно про хренову жменю классов, интерфейсов, енамов и прочей параферналии которая потенциально реализует переходы между значениями хранящейся в замудрённом классе переменной означающей "state". функциональные языки обычно во всей этой _._бени не нуждаются, прямо в грамматике языка есть всё что нужно для состряпывания беготни по состояниям с вызовами функций в промежутках. плюс, из-за традиционного отсутствия непредсказуемой переменчивости данных, достижимость конечного состояния доказать проще чем для перемешанных как попало в "объектно-ориентированных" языках кода и данных. например, при помощи темпоральной логики.

From:

Собственно конечный автомат имелся в виду. Вот робот, который потенциально может выполнить много разных инструкций (таки заранее известных), но переход к следующей инструкции зависим от контекста, в который робот был заведён предыдущими инструкциями. То есть, нужно как-то иметь persistent state.

From:

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

From:

Ну вот можешь ли ты подтвердить имплементируемость стейт-машины на чистом FP? Ведь на практике случается даже несколько стейт-машин, ответственных за разное, и отдельная машина может просто никуда не ехать, а стоять, в то время как её состояние важно, чтобы другие могли прочесть мысль.

From:

Можно начать с вопроса, является ли лямбда-исчисление полным по Тьюрингу.

From:

Я это не очень понимаю. Вопрос был ремесленнический.

From:

Так я не вижу проблемы - чисто формально state machine - это функция Input -> State -> State; ты хочешь поднять эту функцию на List[Input] -> State -> State, и, может быть, поменять порядок параметров и получить State -> List[Input] -> State - и? Где проблемы? В имплементации? В книге Beautiful Code первая глава как раз посвящена тому, как, зная, что у нас речь о морфизме двух моноидов (там этих слов нет) иы можем лихо сократить вычисления, в редакторе ли, в контроле ли версий, все равно.

From:

Ну дык, нет глобальных и статических переменных по определению? FP - это же просто высокоуровневые навороты, а под ними всё та же OS, всё те же потоки, банальная JVM. Или хранят стейт где-то не только в локальном контексте потока-функции, или нигде нет стейт, доступного другим блокам программы.

From:

Ты и по хардверу специалист? На тему, что там под низом, есть разные мнения. Но на самом деле это неважно. Ты когда мячик кидаешь, ты о судьбе молекул вряд ли задумываешься, что за электрические силы заставляют все молекулы дружно вдруг сниматься и нестись в воздухе. Разные уровни абстракции, вот что я хочу сказать.

From:

I wish I was... nope generalist. Поискал, вот http://doc.akka.io/docs/akka/snapshot/scala/fsm.html

Не очень внимательно пока читал, но показалось, что банальный цикл, и вуаля, имеем висящий в памяти синглтончик на Scala. :) Он отвечает на запросы. Всё как у людей.

From:

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

From:

Монаду Вадлер свистнул в теории категорий; там это обычная вещь, вроде интеграла в матанализе.

From:

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

From:

Да меня философы как-то не особо интересуют.
Единственно что еще до Вадлера был такой Трахтман, в одной конторе на Васильевском; он впаривал монады в программировании, ссылаясь именно на Лейбница, но описывая именно наши, программистские, монады. Он написал об этом письмо в обком, которое, по неписаным законам природы, попало мне для рецензии. Ну и т.д.

From:

ну функциональное программирование ведь не вчера родилось, хасеклю вон четверть века уже, а лисп вообще всегда был. слово в литературе встречается лет тридцать. что одна школа озорной мысли называет "монадами", другая по-простому называет чем они есть - functional expression'ами. откольники ml'а кто в один лагерь попал, кто в другой более-менее поровну.

From: