Nie ma nic złego w funkcjonalnym języku utrzymującym zmienny stan. Nawet „czyste” języki funkcjonalne, takie jak Haskell, muszą utrzymywać stan, aby wchodzić w interakcje ze światem rzeczywistym. „Nieczyste” języki funkcjonalne, takie jak Clojure, dopuszczają działania niepożądane, które mogą obejmować stan mutacji.
Najważniejsze jest to, że języki funkcjonalne zniechęcają do zmiany stanu, chyba że naprawdę go potrzebujesz . Ogólnym stylem jest programowanie przy użyciu czystych funkcji i niezmiennych danych oraz interakcja ze „nieczystym” zmiennym stanem w określonych częściach kodu, które tego wymagają. W ten sposób możesz zachować resztę kodu jako „czystą”.
Myślę, że istnieje kilka powodów, dla których STM występuje częściej w językach funkcjonalnych:
- Badania : STM jest gorącym tematem badawczym, a badacze języków programowania często wolą pracować z funkcjonalnymi językami (temat sam w sobie, a ponadto łatwiej jest stworzyć „dowody” na temat zachowania programu)
- Blokowanie nie komponuje : STM można postrzegać jako alternatywę dla opartych na blokadach podejść do współbieżności, które zaczynają napotykać problemy podczas skalowania do złożonych systemów przez komponowanie różnych komponentów. Jest to prawdopodobnie główny „pragmatyczny” powód STM
- STM dobrze pasuje do niezmienności : Jeśli masz dużą niezmienną strukturę, chcesz upewnić się, że pozostaje niezmienna, więc nie chcesz, aby jakiś inny wątek wchodził i mutował jakiś podelement. Podobnie, jeśli możesz zagwarantować niezmienność wspomnianej struktury danych, możesz niezawodnie traktować ją jako stabilną „wartość” w systemie STM.
Osobiście podoba mi się podejście Clojure do zezwalania na zmienność, ale tylko w kontekście ściśle kontrolowanych „zarządzanych referencji”, które mogą uczestniczyć w transakcjach STM. Cała reszta w tym języku jest „czysto funkcjonalna”.
;; 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
Należy zauważyć, że powyższy kod jest w pełni transakcyjny i atomowy - zewnętrzny obserwator odczytujący dwa salda w ramach innej transakcji zawsze zobaczy spójny stan atomowy, tj. Dwa salda zawsze będą sumować się do 200. Przy współbieżności opartej na blokadzie jest to zaskakująco trudny problem do rozwiązania w dużym złożonym systemie z wieloma podmiotami transakcyjnymi.
Aby uzyskać dodatkowe oświecenie, Rich Hickey doskonale objaśnia STM Clojure w tym filmie