а не вот этот весь менеджмент

Дык в итоге конторе остаются гроши на попить водичку

да не, я имею ввиду, если девелопер хочет получать все, ну так пусть и работу всю на себя берет, у меня с этим нет никаких проблем.

А, идею уловил, да

Хорошо ж платили, че ушла?)

А если серьезно, то непонятно, $3500 — это на руки или это стоимость разработчика для компании? (Полагаю, ближе к первому).
Ну и выше там было про то, как всё считать (налоги, неинженерные сотрудники, неполная загрузка).

Да уж. Самому на себя ещё надо научиться. Когда-то я ушёл в свободное плавание, рейт поставил в 2 раза больше, чем получал в компании. А работать стал в 2 раза меньше, потому что этого хватало на жизнь. И постоянно переживал из-за того, что не могу заставить себя работать 40 часов в неделю вместо 20, чтобы откладывать на дом, отпуск и т.п.

Приветы. Товарищи, чем в функциональном подходе заменяют стейт машины и заменяют ли?

как вариант, переменную за пределами функции объявить и там хранить что-то. хотя само понятие состояния противоречит идее фп

зависит от реальной задачи. StateMachine это конечный автомат - что из твоего значения (сосотояния) может быть только несколько переходов. Тебе не обязательно хранить промежуточное состояние "где-то".

Например мы парсим семантику (токены) - читаем рекурсивно StdIn пока не получим token или не произойдет ошибка. Прочитали токен - гуд - отдали его идентификатор. Ждем следующего In.

Если же речь идет о чем-то типа веб приложения и имеется ввиду состояние какой-то сущности реального мира, и мы хотим между request-ами сохранить значение, то скорее всего есть БД - через нее и делать состояние.
Так же можно в отдельной функции это делать (в терминах эликсира- в отдельном процессе/агенте)

Если речь идет об альтернативе state_machine/aasm - то реализация будет выбрана согласно задаче, быстрым поиском для elixir есть - https://github.com/joaomdmoura/machinery

Я ещё докину, тут стейт машину на эффектах написали

https://gist.github.com/andymatuschak/d5f0a8730ad601bcccae97e8398e25b2

вообще нас в универе учили что для конечного автомата прям самое то применять ФЯП. И мы делали какую-то экспертную систему на Лиспе даже

только я тех пор мало что помню

но судя по всему да, описываешь правила и стейт не сохраняешь, вот такая философия

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

или задача написать "фреймворк" для построения стейт машин, по типу state_machine/aasm?

и замыкания в фп никто не отменял, можно хранить стейт там

У меня была идея описать штуку, которая по данным стейт гоняла бы (и определяла его из данных)

https://github.com/davydovanton/state_changer

По сути единственное, что меняется с переходом к ФП, это вместо моделирования объектом самой машины  моделируется её конкретное состояние на момент времени.

Лол

Тогда уж и ссылку надо: https://github.com/functiondj/obscore/issues/33