소듐이라는 저자의 라이브러리를 사용하므로 이는 설명하지 않고 이론적이거나 개념만을 설명하고자 한다

• FRP

  • 이벤트를 값의 흐름(스트림)으로 보고 각종 콤비네이터(고차 함수)를 사용해서 값을 어떻게 변환할 지 기술하는 프로그래밍 스타일
  • RX(Reactive Extensions)와 마찬가지로 간단한 라이브러리 형태로 제공되며 관찰자 패턴에서 널리 사용되는 리스너(콜백)을 대신한다
  • 반응형 프로그래밍을 달성하기 위해 함수형 프로그래밍의 규칙을 따르도록 강제하며, 합성성 을 강조한다
  • 합성성: 소프트웨어 구성 요소들을 예상치 못한 부수 작용 없이 서로 합성할 수 있게 해주는 특성
  • 선언형 프로그래밍 스타일을 이용하여 출력을 입력의 측면에서 기술한다
  • 순서에 의존하는 명령형 프로그래밍 스타일을 탈피하도록 언어적 제약을 가한다
  • IO 처리는 스트림을 받아 스트림으로 결과를 출력하는 함수로 만들 수 있다

• RX와의 차이점

  • 둘 다 관찰자 패턴에 대한 랩퍼
  • 둘 다 새로운 기본요소를 만드는 것이 좋지 않다 → 잘못하면 합성성이 깨질 수 있다
  • FRP 의 최소주의적 관점보다는 실용주의적 관점에서 더 많은 기능을 제공
  • FRP와는 달리 트랜잭션의 개념이 없다

• 액터와의 차이점

  • 액터는 문제가 선형 제어 흐름인 경우 매우 유용하다
  • 한 개의 상태 변수를 제어하는 경우 매우 유용하다 → 여러 상태 변수는 FRP가 더 유용하다

• 리스너 / 콜백의 문제점

  • 예측 불가능한 순서: 리스너는 동기화 코드가 아니면 실행 순서를 알 수 없다
  • 첫 번째 이벤트의 소실: 초기화 순서/ 처리 순서에 영향을 받아 리스너가 등록되기 전 이벤트를 잃어버릴 수 있다
  • 지저분한 상태: 클래스가 여러 이벤스 소스를 구독하는 경우 상태 관리가 매우 지저분해진다
  • 스레드 문제: 공유된 변경 가능한 변수(상태)를 지니면 동기화가 매우 어려워 진다
  • 콜백 누수: 리스너 제거를 잊어버리면 누수가 발생한다
  • 의도하지 않은 재귀: 순서에 영향을 받아 불필요한 재귀 동작을 수행할 수 있다 → 공감 불가

• 함수형 프로그래밍: 수학적 의미의 함수에 기반한 프로그래밍 방식. 공유된 변경 가능한 상태를 의도적으로 회피한다.
• 반응형 프로그래밍: 이벤트 기반/ 입력 반응/ 데이터 흐름에 따른 프로그래밍 스타일. 구성 요소 간 느슨한 결합을 허용한다
• 뉴 타입 패턴: 값을 클래스로 감싸서 의미를 부여하고 타입 안정성을 추가로 얻어내는 패턴(like value class)