haskell - wikipedia reactive programming




현재 Functional Reactive Programming 구현의 상태는 어떻습니까? (2)

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 구현을 사용하는 것이 특히 재미있을 것입니다. 지능적이고 적응력이 뛰어난 자체 학습 서버 프로세스를 갖는 것이 매우 쉽습니다!


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

  • 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를 사용하는 상업적 또는 대규모의 프로젝트가 없다는 것을 알고 있습니다. 도서관은 준비가되었지만, 사람들은 아직 그렇지 않다고 생각합니다.







reactive-programming