Немає нічого поганого у функціональній мові, що підтримує стан, що змінюється. Навіть "чисті" функціональні мови, такі як Haskell, повинні підтримувати стан, щоб взаємодіяти з реальним світом. "Нечисті" функціональні мови, такі як Clojure, дозволяють побічні ефекти, які можуть включати мутаційний стан.
Основний момент полягає в тому, що функціональні мови перешкоджають зміненному стану, якщо вам це справді не потрібно . Загальний стиль полягає в програмуванні з використанням чистих функцій та незмінних даних, а взаємодія лише з "нечистим" змінним станом у конкретних частинах вашого коду, які цього вимагають. Таким чином, ви можете зберегти решту бази коду «чистою».
Я думаю, що є кілька причин, чому STM є більш поширеним у функціональних мовах:
- Дослідження : STM - гаряча тема дослідження, і дослідники мови програмування часто вважають за краще працювати з функціональними мовами (тема самодослідження сама по собі, плюс простіше створити "докази" щодо поведінки програми)
- Блокування не складається : STM можна розглядати як альтернативу блокувальним підходам до одночасності, який починає виникати в проблемах, коли ви масштабуєте складні системи шляхом складання різних компонентів. Це, мабуть, головна «прагматична» причина STM
- STM добре поєднується з незмінністю : Якщо у вас велика незмінна структура, ви хочете переконатися, що вона залишається незмінною, тому вам не потрібно, щоб якась інша нитка надходила і мутувала якийсь під елемент. Так само, якщо ви можете гарантувати незмінність зазначеної структури даних, ви можете надійно трактувати це як стабільне "значення" у вашій системі STM.
Мені особисто подобається підхід Clojure до можливості зміни змін, але лише в умовах жорстко контрольованих "керованих посилань", які можуть брати участь у транзакціях STM. Все інше в мові "чисто функціональне".
;; define two accounts as managed references
(def account-a (ref 100))
(def account-b (ref 100))
;; define a transactional "transfer" function
(defn transfer [ref-1 ref-2 amount]
(dosync
(if (>= @ref-1 amount)
(do
(alter ref-1 - amount)
(alter ref-2 + amount))
(throw (Error. "Insufficient balance!")))))
;; make a stranfer
(transfer account-a account-b 75)
;; inspect the accounts
@account-a
=> 25
@account-b
=> 175
Зверніть увагу, що наведений вище код є повністю трансакційним та атомним - зовнішній спостерігач, який читає два баланси в рамках іншої транзакції, завжди побачить послідовний атомний стан, тобто два баланси завжди будуть дорівнювати 200. З одночасністю на основі блокування це напрочуд складна проблема вирішити у великій складній системі з багатьма транзакційними утвореннями.
Для додаткового просвітлення Річ Хікі чудово справляється з поясненням STM Clojure у цьому відео