Согласен.
ФП это совершенно другое программирование.
Я бы вообще отдельную ветку завел, но ты у нас один такой)).
Начни с примера про пиццу на ФП.

mayton,

https://habr.com/ru/post/303312/

mayton,

авторкак мы будем печь функциональный пирог:
Пирог—это горячий пирог, остывший на полотенце, где горячий пирог—это подготовленный пирог, выпекавшийся в разогретой духовке 30 минут.
Разогретая духовка—это духовка, разогретая до 175°C.
Подготовленный пирог—это тесто, выложенное в подготовленный противень, где тесто—это кремовая масса, в которую добавили измельченные грецкие орехи. Где кремовая масса—это масло, сахар-песок и коричневый сахар, взбитые в большой миске до тех пор, пока они не стали легкими и воздушными, где…

А, ну его к черту—я не могу это закончить!

mayton,
Вы не ищите отличий.
А цель исследования объекта найти ХАРАКТЕРНЫЕ ПРИЗНАКИ. То есть - отличия.
В статье это напр
>императивных языков-таки есть огромное преимущество в том, что у них есть неявное состояние. И люди, и машины очень хорошо работают с неявным состоянием,.....

mayton,
С базами мы подстроились под машины. Вот и всё.
Машинам удобнее работять с реляционной теорией.

Выполнить пример с пирогом в парадигме ФП.
....
Если вы всю жизнь писали на jdbc, то пример на ОРМ повергнет вас в шок.
Аналогия понятна?

Вот еще пример

Мне мои мозги 6м чувством говорят. Что они вообще не воспринимают ФП.
Мне только отрадно что нас большинство))

забыл ник,
Где она выше?
На этой ветке статус ФП не поменялся уже сколько лет?
А на фронте вообще ничего постоянного нет.

mayton,
Я же тебе привел аналогию jdbc/orm и даже код показал.
Парадигмы СОВЕШЕННО РАЗНЫЕ.
А ты доказываешь что одинаковые?

забыл ник,

>С какой-то стати ты приравниваешь event-driven с акторной моделью.
Да. Он вечно пытается все в кучу.
Мы тут вроде и просим.
Сначала пример на ФП. Демку.
А потом остальное.

Basil A. Sidorov,
"Выкинуть" это максимализм.
Они занимают свое место? Вот и пусть там сидят.
Я отвечал на мессандж, почему мы работаем с тем что нам неудобно (человеку?
Я ответил что подстроились под комп.
Так же как с xml человеку неудобно. Но работаем ведь?
А ФП неудобно НИКОМУ)))

Здесь подчеркивается величина разницы.
Вот перефразирую:
Программирование ФП или на Акторах отличается настолько от обычного, как программирование на jdbc отличается от программирования на хибере.

))
Ветка на форуме есть по ФП?

Предлагаю ТС поискать конкретную задачку под ФП.
Выше уже озвучивали. Я не максималист.

andreykaT
и у меня как то в голове каша получается.

Отсюда задача - выявить ОСОБЕННОСТИ ФП НА ПРИМЕРАХ.

mayton,
Да. Есть такая трудность.
У тебя были топики. Но они скорее про алгоритмы.
А автору подходы / архитектура нужна.
Пусть работает, ищет Akka hello world.
Мы не торопимся.

Это вы вывод сделали на основе того что я не перечислял историю развитие СУБД?
А где же презумпция невиновности? )))
- "не говори что я не знаю, если я об это не говорил" )))

Зашквар - это аргумент. ОК.

тебе вторым постом сказали - не бери из головы. Возьми из сети. У тебя произношение слабое.


переведи. Аутентификация? Авторизация? Юз кейс - "Приём на работу"?

Зачем?
Если ты про аутентификацию, то она отдельно совсем.
Не смешивай ее с БЛ никогда.
Считай что ЗАПИСЬ ЮЗВЕРЯ ЕСТЬ В бд.
Разбери юз кейс реальный.

забыл ник,
Как это ниже мешает ООП?
авторВ этих определениях собраны три основные черты того, что называют Serverless:

Абстракция. Вы не управляете сервером, на котором запускается ваша программа. Вы вообще ничего про него не знаете, все нюансы операционной системы, обновлений, сетевых настроек и прочего спрятаны от вас. Это сделано для того, чтобы вы могли сосредоточиться на разработке полезной функциональности, а не на администрировании серверов.

Эластичность. Провайдер Serverless услуги автоматически предоставляет вам больше или меньше вычислительных ресурсов, в зависимости от того, насколько большая нагрузка приходится на ваше приложение.

Эффективная стоимость. Если ваше приложение простаивает — вы ничего не платите, т.к. оно в этот момент не использует вычислительных ресурсов. Оплата же происходит только за время, которое ваше приложение реально работает.

Ограниченный жизненный цикл. Ваше приложение запускается в контейнере, и, спустя короткое время, от десятка минут до нескольких часов, сервис автоматически его останавливает. Конечно же, если приложение снова должно быть вызвано — новый контейнер будет запущен.
Стримы в шарп это Linq.
Никакого переворота и революции не сделали. Как пришли так и ушли.
Есть огромный сдерживающий фактор у облаков и собирания программ из кусочков.
Сначала вы грезили что будет тонкий экран клиент у всех. А Ось в облаке.
Потом грезили про ворд в облаке.
Потом грезили про микросервисы.
Потом про докеры.
Это ведь все админов касается. Развертывания. Управления ПО. А не РАЗРАБОТКОЙ ПО.
Почему EJB помер?
>И что там обсуждать?
Сначала выясни, это хрень академическая или революционная вещь?
Если второе то нужна ветка в форуме. Отдельная.

Отдельно от этого топика.
Ее асинхронно не сделать никогда.
Убери ее из топика и перефразируй вопрос свой.
Hello world найди. Пятый раз просят.

andreykaT,
Держи hello world Akka
Раз ты сам вторую страницу никак не родил.
https://medium.com/@ian.shiundu/building-a-fully-functional-rest-service-using-akka-actors-8b5c12978380

Что касается применимости модели акторов в архитектуре.
Это в основном асинхронный код, код на событиях.
Как это решается БЕЗ АКТОРОВ?
Очень просто - в веб короткие транзакции, меньше 0, 1сек
- в веб есть кеши
- в веб есть контейнер который параллелит.
Поэтому пример нужности акторов, это игровые серверы.
Там в модели каждая травинка это Актор.
Поэтому на старой модели все встанет.
Как то так... Имхо.

mayton,
Модель акторов вроде вообще скрывает эти понятия. О них просто не говорят. Они внизу.

mayton,
Согласен.