haskell wikipedia - 현재 Functional Reactive Programming 구현의 상태는 어떻습니까?




functional-programming erlang reactive-programming (4)

Mono와 .Net 공간에 몇 가지 항목을 나열하고 너무 오래 전에 찾은 하스켈 공간에서 하나를 나열 할 것입니다. 하스켈부터 시작하겠습니다.

느릅 나무 - link

해당 사이트에 대한 설명 :

Elm은 프론트 엔드 웹 개발을보다 즐겁게 만드는 것을 목표로합니다. HTML, CSS 및 JavaScript의 시스템 문제를 수정하는 GUI 프로그래밍에 대한 새로운 접근 방식을 소개합니다. 느릅 나무를 사용하면 시각적 레이아웃으로 빠르고 쉽게 작업하고, 캔버스를 사용하고, 복잡한 사용자 입력을 관리하고, 콜백 지옥에서 벗어날 수 있습니다.

그것에는 FRP 그것의 자신의 이체가있다. 그 예를 가지고 노는 것에서 그것은 꽤 성숙한 것처럼 보인다.

반응 확장 - link

첫 페이지 설명 :

Reactive Extensions (Rx)는 관찰 가능한 시퀀스 및 LINQ 스타일 쿼리 연산자를 사용하여 비동기 및 이벤트 기반 프로그램을 작성하기위한 라이브러리입니다. 개발자는 Rx를 사용하여 Observables로 비동기 데이터 스트림을 나타내고 LINQ 연산자를 사용하여 비동기 데이터 스트림을 쿼리하며 Schedulers를 사용하여 비동기 데이터 스트림의 동시성을 매개 변수화합니다. 간단히 말해 Rx = Observables + LINQ + Schedulers.

Reactive Extensions는 MSFT에서 제공되며 이벤트 처리를 단순화하는 우수한 운영자를 많이 구현합니다. 불과 며칠 전에 오픈 소스 였습니다. 매우 성숙하며 생산에 사용됩니다. 제 의견으로는 TPL 라이브러리가 제공하는 것보다 Windows 8 API에 더 좋은 API 였을 것입니다. 왜냐하면 관측 대상은 뜨겁거나 추울 수 있고 재 시도 / 병합 될 수 있기 때문입니다. 작업은 항상 실행 중이거나 오류가 있거나 완료된 계산 작업을 나타냅니다.

Rx를 사용하여 asynchronous를위한 서버 측 코드를 작성했지만 C #에서 기능적으로 작성하는 것이 약간 짜증나게 할 수 있음을 인정해야합니다. F #에는 몇 개의 래퍼가 있지만 API 개발을 추적하기가 어려웠습니다. 다른 프로젝트와 마찬가지로 MSFT가 그룹을 비교적 폐쇄하고 승격시키지 않았기 때문입니다.

오픈 소싱은 IL-to-JS 컴파일러의 오픈 소싱으로 이루어 졌으므로 JavaScript 또는 Elm에서 잘 작동 할 수 있습니다.

RabbitMQ와 SocksJS 같은 메시지 브로커를 사용하여 F # / C # / JS / Haskell을 아주 잘 묶어서 바인딩 할 수 있습니다.

블링 UI 툴킷 - link

첫 페이지 설명 :

Bling는 Microsoft의 WPF / .NET에서 이미지, 애니메이션, 상호 작용 및 시각화를 쉽게 프로그래밍 할 수있는 C # 기반 라이브러리입니다. 블링은 풍부한 UI 디자인 아이디어의 신속한 프로토 타이핑을 돕기 위해 때로는 프로그램하는 설계 기술자, 즉 디자이너를 지향합니다. 학생, 예술가, 연구원 및 애호가는 아이디어 또는 시각화를 빠르게 표현하기위한 도구로 블링이 유용하다는 것을 알게됩니다. 블링의 API와 구조는 프로덕션 코드의 신중한 프로그래밍과는 달리 던져진 코드의 빠른 프로그래밍에 최적화되어 있습니다.

무료 LtU-article .

나는 이것을 테스트했지만, 클라이언트 프로젝트를 위해 그것으로 일하지 않았다. 멋지게 보이고 값 사이의 바인딩을 형성하는 멋진 C # 연산자 오버로드가 있습니다. WPF / SL / (WinRT)의 종속성 속성을 이벤트 소스로 사용합니다. 3D 애니메이션은 합리적인 하드웨어에서 잘 작동합니다. 필자가 시각화를 필요로하는 프로젝트를 끝내면 이것을 사용할 것입니다. 아마도 Windows 8로 이식하는 것입니다.

ReactiveUI - link

이전 MSFT의 Github에 있었던 Paul Betts는 그 프레임 워크를 썼습니다. 나는 꽤 광범위하게 모델과 비슷하게 작업 해왔다. 그것은 블링크 (Rx와 추상화를 사용하는 것이 자연 스럽다)보다 디커플링되어있어이를 사용하여 단위 테스트 코드를보다 쉽게 ​​만들 수 있습니다. Windows 용 github git 클라이언트는 여기에 쓰여 있습니다.

코멘트

리 액티브 모델은 대부분의 성능이 요구되는 어플리케이션에 충분한 성능을 제공합니다. 어려운 실시간을 생각하고 있다면 대부분의 GC 언어에 문제가 있다는 것을 내기 할 것입니다. Rx, ReactiveUI는 구독이 생성 / 폐기되고 중간 값이 콜백의 반응적인 "모나드"에서 진행되기 때문에 GCed 할 필요가있는 소량의 개체를 만듭니다. 일반적으로 .Net에서는 태스크가 동적으로 할당되고 (알 수 없지만 모든 호출에 인스턴스가 필요하고 쓰레기가 생성되는) 콜백이 정적 (콜백 시간, 할당 없음)이기 때문에 태스크 기반 프로그래밍에 대한 반응 형 프로그래밍을 선호합니다. 그리고 lambdas는 컴파일러 생성 클래스.

분명히 C # 및 F #은 엄격하게 평가되므로 시간 누설은 여기에서 문제가되지 않습니다. JS와 동일합니다. 그것은 재생 가능하거나 캐시 된 관찰 대상에 문제가 될 수 있습니다.

하스켈에서 간단한 자동 물리적 시스템 (진자, 로봇 팔 등)을 시각화하려고합니다. 종종 이러한 시스템은 다음과 같은 방정식으로 설명 될 수 있습니다.

df/dt = c*f(t) + u(t)

여기서 u(t) 는 일종의 '지능형 제어'를 나타냅니다. 이러한 시스템은 Functional Reactive Programming 패러다임에 매우 적합합니다.

그래서 Paul Hudak의 "Haskell School of Expression"책을 가져 와서 거기에 소개 된 도메인 별 언어 "FAL"이 내 간단한 장난감 시스템에서 실제로 즐겁게 작동한다는 것을 알았습니다 (일부 기능, 특히 integrate , 효율적인 사용을 위해 너무 게으른 것처럼 보였지만 쉽게 고칠 수 있음).

제 질문은 더 진보 된, 또는 심지어 실용적인 응용 프로그램을위한 더 성숙하고 최신의 유지 관리가 잘 된 성능 튜닝 된 대안이 무엇인가하는 것입니다.

이 위키 페이지 에는 하스켈에 대한 몇 가지 옵션 나열되어 있지만 다음과 같은 점에 대해서는 명확하지 않습니다.

  1. 이 프로그래밍 패러다임의 발명가 중 한 사람인 Conal Eliott의 프로젝트 인 "reactive"의 상태는 조금 낡은 것처럼 보입니다. 나는 그의 코드를 좋아하지만 어쩌면 나는 다른 더 최신의 대안을 시도해야 할까? 구문 / 성능 / 런타임 안정성 측면에서 이들 간의 주요 차이점은 무엇입니까?

  2. 2011 년 survey 에서 인용하기 위해, " ... FRP 구현은 여전히 ​​지연 시간 보장이 필요한 영역에서 효율적으로 사용하기에는 충분히 효율적이거나 성능면에서 예측 가능하지 않습니다 ... ". FRP가 15 년 넘게 존재한다는 사실을 감안할 때 조사에서 몇 가지 흥미있는 가능한 최적화가 나와 있습니다. 필자는이 성능 문제가 적어도 몇 년 이내에 해결하기가 매우 어렵거나 본질적으로 어려운 것이라고 생각합니다. 사실입니까?

  3. 같은 설문 조사의 저자는 그의 blog 에서 "시간 누설"에 관해 이야기합니다. 문제는 FRP만의 문제인가 아니면 순수하고 엄격하지 않은 언어로 프로그래밍 할 때 일반적으로 발생하는 문제입니까? 충분히 성능이 없다면 시간이 지남에 따라 FRP 기반 시스템을 안정화시키는 것이 너무 어렵다는 것을 알았습니까?

  4. 이것은 여전히 ​​연구 수준 프로젝트입니까? 공장 엔지니어, 로봇 공학 엔지니어, 금융 엔지니어 등의 사람들이 실제 사용하고 있습니까 (요구 사항에 맞는 언어로)?

개인적으로 하스켈 구현을 선호하지만 다른 제안을 할 수 있습니다. 예를 들어 Erlang 구현을 사용하는 것이 특히 재미있을 것입니다. 지능적이고 적응력이 뛰어난 자체 학습 서버 프로세스를 갖는 것이 매우 쉽습니다!


이미 좋은 답변이 있지만 구체적인 질문에 대답하려고합니다.

  1. 시간 누출 문제로 인해 심각한 프로젝트에는 반응 형을 사용할 수 없습니다. (# 3 참조). 가장 유사한 디자인의 현재 라이브러리는 반응 형 바나나입니다.이 바나나는 영감을 얻어 반응적이고 Conal Elliott와의 토론에서 개발되었습니다.

  2. Haskell 자체는 하드 실시간 응용 프로그램에는 적합하지 않지만 어떤 경우에는 Haskell을 소프트 실시간 응용 프로그램에 사용할 수 있습니다. 나는 현재의 연구에 익숙하지 않지만, 이것은 극복 할 수없는 문제라고 생각하지 않습니다. Yampa와 같은 시스템이나 Atom과 같은 코드 생성 시스템이 아마도이 문제를 해결하는 최선의 방법이라고 생각합니다.

  3. "시간 누설"은 전환 가능한 FRP에 고유 한 문제입니다. 누출은 시스템이 이전 오브젝트를 사용할 수없는 경우에 발생합니다. 장래에 스위치가 발생할 경우 해당 오브젝트가 필요할 수 있기 때문입니다. 메모리 누수 (상당히 심할 수 있음) 외에도 스위치가 발생할 때 시스템은 일시 중지해야하며 이전 객체의 체인을 탐색하여 현재 상태를 생성해야합니다.

Yampa와 이전 버전의 반응성 바나나와 같은 전환 할 수없는 frp 라이브러리는 시간 누출이 없습니다. 전환 가능한 frp 라이브러리는 일반적으로 두 가지 방법 중 하나를 사용합니다. 즉, FRP 값이 생성되는 특수 "생성 모나드"를 갖거나 스위치가 발생할 수있는 컨텍스트를 제한하기 위해 "에이징"유형 매개 변수를 사용합니다. elerea (그리고 아마도 netwire?)는 전자를 사용하는 반면 최근의 반응성 바나나와 자몽은 후자를 사용합니다.

"switchable frp"는 Conal의 함수 switcher :: Behavior a -> Event (Behavior a) -> Behavior a 또는 동일한 의미를 구현하는 것을 의미합니다. 즉, 네트워크의 모양이 실행될 때 동적으로 전환 할 수 있습니다.

이것은 모나드 인터페이스에 대한 @ertes의 진술과 모순되지 않습니다. Event Monad 인스턴스를 제공하면 시간 누설이 가능 해지고 위의 방법 중 하나를 사용하면 더 이상 해당 Monad 인스턴스를 정의 할 수 없습니다.

마지막으로, FRP로 수행해야 할 작업이 아직 많이 남아 있지만 새로운 플랫폼 (반응성 바나나, 요소, 네트워크)이 안정적이고 성숙되어있어 신뢰할 수있는 코드를 작성할 수 있다고 생각합니다. 그러나 좋은 성과를 얻는 방법을 이해하기 위해 많은 부분을 배우면서 많은 시간을 할애해야 할 수도 있습니다.


바로 지금 기능적 반응 프로그래밍을위한 두 가지 실용적인 하스켈 라이브러리가 있습니다. 둘 다 한사람에 의해 관리되지만 다른 하스켈 프로그래머들로부터 코드 기여도를 받고 있습니다 :

  • Netwire 는 효율성, 유연성 및 예측 가능성에 중점을 둡니다. 자체 이벤트 패러다임을 가지고 있으며 네트워크 서비스 및 복잡한 시뮬레이션을 포함하여 전통적인 FRP가 작동하지 않는 영역에서 사용할 수 있습니다. 스타일 : 적용 및 / 또는 화살표. 초기 저자이자 관리자 : Ertugrul Söylemez (나).

  • reactive-banana 는 전통적인 FRP 패러다임을 기반으로합니다. 사용하는 것이 실용적이지만 고전적인 FRP 연구의 토대가됩니다. 주요 초점은 사용자 인터페이스이며 wx에 대한 기성 인터페이스가 있습니다. 스타일 : 적용 가능. 초기 저자 겸 관리자 : Heinrich Apfelmus.

둘 다 시도해야하지만, 응용 프로그램에 따라 어느 쪽이 더 적합 할 가능성이 높습니다.

게임, 네트워킹, 로봇 제어 및 시뮬레이션을 위해 Netwire를 유용하게 사용할 수 있습니다. 다양한 애플리케이션 차동, 통합 및 투명한 이벤트 처리를위한 많은 기능을 포함하여 이러한 애플리케이션을위한 기성품 와이어 가 함께 제공됩니다. 튜토리얼은 내가 링크 된 페이지에있는 Control.Wire 모듈의 문서를 방문하십시오.

현재 그래픽 사용자 인터페이스의 경우 최상의 선택은 반응성 바나나입니다. 이미 wx 인터페이스 (별도의 라이브러리 반응 - 바나나 -wx)가 있으며 하인리히는 코드 샘플을 포함하여이 컨텍스트에서 FRP에 대해 많은 블로그를 작성합니다.

다른 질문에 대답하려면 : FRP는 실시간 예측 성이 필요한 시나리오에는 적합하지 않습니다. 이것은 주로 Haskell 때문이지만, 불행하게도 FRP는 저급 언어로 구현하기가 어렵습니다. 하스켈 자체가 실시간으로 준비되는대로 FRP도 거기에 도착할 것입니다. 개념적으로 Netwire는 실시간 응용 프로그램을 사용할 준비가되었습니다.

시간 누설은 모나드 프레임 워크와 크게 관련되어 있으므로 실제로는 더 이상 문제가되지 않습니다. 실용적인 FRP 구현은 모나드 인터페이스를 제공하지 않습니다. Yampa가 이것을 시작했고 Netwire와 반응 형 바나나가 그 두 가지를 기반으로합니다.

나는 현재 FRP를 사용하는 상업적 또는 대규모의 프로젝트가 없다는 것을 알고 있습니다. 도서관은 준비가되었지만, 사람들은 아직 그렇지 않다고 생각합니다.


이것을 설명하는 또 다른 방법은 함수 가 현재 시간을 가져올 수는 없지만 (계속 변경되므로) 현재 시간을 얻을 수 있습니다. getClockTime 이 현재 시간을 가져 오는 작업 을 나타내는 상수 (또는 원하는 경우 무효 함수)라고 가정 해 보겠습니다. 이 동작 은 언제 사용 되든 매번 동일하므로 실제 상수입니다.

마찬가지로 print 가 시간 표현을 사용하여 콘솔로 출력하는 함수라고 가정 해 봅니다. 함수 호출은 순수 함수형 언어에서 부작용을 가질 수 없으므로 대신 타임 스탬프를 사용하여 콘솔에 출력하는 작업 을 반환하는 함수라고 상상해보십시오. 다시 말하지만, 이것은 실제 함수입니다. 왜냐하면 동일한 타임 스탬프를 주면 매번 동일한 작업 을 반환하기 때문입니다.

자, 어떻게 현재 시간을 콘솔로 출력 할 수 있습니까? 글쎄, 당신은 두 가지 행동을 결합해야합니다. 그러면 어떻게 할 수 있을까요? print는 getClockTime 을 넘겨 getClockTime 수 없습니다. print는 작업이 아니라 타임 스탬프를 기대하기 때문입니다. 그러나 우리 두 개의 액션을 결합한 연산자 인 >>= 상상할 수 있습니다. 하나는 타임 스탬프를 얻고, 다른 하나는 인수로 취해서 인쇄합니다. 이것을 이전에 언급 한 행동에 적용하면 결과는 ... tadaaa ... 현재 시간을 가져 와서 인쇄하는 새로운 동작입니다. 그리고 이것은 부수적으로 Haskell에서 정확히 어떻게 이루어 졌는지입니다.

Prelude> System.Time.getClockTime >>= print
Fri Sep  2 01:13:23 東京 (標準時) 2011

따라서 개념적으로 볼 수 있습니다. 순수한 기능적 프로그램은 I / O를 수행하지 않으며 런타임 시스템이 실행하는 동작을 정의합니다. 작업 은 매번 동일하지만 실행 결과는 실행될 때의 상황에 따라 다릅니다.

이것이 다른 설명보다 더 명확한지는 모르겠지만 때로는이 방법으로 생각할 때 도움이됩니다.







haskell functional-programming erlang reactive-programming