Если скала отстаивает неизменность, почему она приняла модель актера с ее изменчивой природой?

Я новичок в мире скал и актеров.

Это то, что я узнал до сих пор:

Scala - это функциональное программирование (не чисто), и люди советуют не использовать изменяемое состояние в Scala.

Но с другой стороны, есть фреймворк akka, который реализует модель актера. И во время игры с аккой я понял, что сообщения неизменны, НО состояние актеров в MUTABLE. Итак, мне нужно указать внутри актеров переменные "var" и изменяемые коллекции. И для меня наличие изменчивого состояния не является естественным для скалы.

Итак, мое понимание правильно? Почему люди приняли изменчивую модель актеров на неизменном языке скала?

3 ответа

Это интересный момент, и действительно, актеры сильно отличаются от остального Scala-подобного кода.

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

Он обеспечивает прочную основу для создания более функциональных абстракций. Команда Akka выпустила akka-streams. Spark использует akka для связи между узлами. Futures, еще одна успешная функциональная альтернатива этой проблеме - это, по сути, особый случай потоков: поток ровно одного элемента и может быть реализован с использованием акторов.

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

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

Scala - это язык, который допускает смешанные модели. Это правда, что большинство примеров используют изменяемое состояние внутри Actors, но вы можете использовать Actors с неизменным состоянием, используя become:

class ListActor extends Actor {
  def receive = changeState(List.empty[String])

  def changeState(state: List[String]): Receive = {
    case Add(item) =>
      context.become(changeState(item :: state))
  }
}

Это хороший вопрос с интересным ответом (ИМХО): Scala не работает. Это пост-функционал. Это означает, что он объединяет объектно-ориентированное и функциональное программирование в единую парадигму.

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

Другие вопросы по тегам