Mevcut Fonksiyonel Reaktif Programlama uygulamalarının durumu nedir?

Haskell'de bazı basit otomatik fiziksel sistemleri (sarkaç, robot kollar vb.) Görselleştirmeye çalışıyorum. Genellikle bu sistemler aşağıdaki gibi denklemlerle tanımlanabilir

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

burada u(t)bir tür 'akıllı kontrolü' temsil eder. Bu sistemler, Fonksiyonel Reaktif Programlama paradigmasına çok iyi uyuyor gibi görünüyor.

Bu yüzden Paul Hudak'ın "Haskell İfade Okulu" kitabını aldım ve orada sunulan alana özgü "FAL" dilinin (İşlevsel Animasyon Dili için) aslında basit oyuncak sistemlerim için oldukça hoş bir şekilde çalıştığını keşfettim (özellikle bazı işlevler integrate, verimli bir kullanım için biraz tembel görünüyordu, ancak kolayca düzeltilebilir).

Sorum şu, bugün daha gelişmiş ve hatta pratik uygulamalar için daha olgun, güncel, iyi korunmuş, performansa göre ayarlanmış alternatif nedir?

Bu wiki sayfası Haskell için birkaç seçenek listeliyor, ancak aşağıdaki hususlar konusunda net değilim:

1. Bu programlama paradigmasının mucitlerinden biri olan (anladığım kadarıyla) Conal Eliott'tan "reaktif" projesinin durumu biraz eski görünüyor. Kodunu seviyorum, ama belki daha güncel alternatifleri denemeliyim? Sözdizimi / performans / çalışma zamanı kararlılığı açısından aralarındaki temel fark nedir?

2. 2011'deki bir anketten alıntı yapmak gerekirse , Bölüm 6, " ... FRP uygulamaları, gecikme garantileri gerektiren alanlarda etkin bir şekilde kullanılmak için performans açısından yeterince verimli veya yeterince öngörülebilir değildir ... ". Anket, bazı ilginç olası optimizasyonları önermesine rağmen, FRP'nin 15 yıldan fazla bir süredir orada olduğu gerçeği göz önüne alındığında, bu performans sorununun en azından birkaç yıl içinde çözülmesi çok veya hatta doğası gereği zor bir şey olabileceği izlenimini edindim . Bu doğru mu?

3. Anketin aynı yazarı, blogunda "zaman sızıntılarından" bahsediyor . Sorun FRP'ye özel mi yoksa saf, katı olmayan bir dilde programlama yaparken genel olarak sahip olduğumuz bir şey mi? Yeterince performanslı değilse, zaman içinde FRP tabanlı bir sistemi stabilize etmenin çok zor olduğunu fark ettiniz mi?

4. Bu hala araştırma düzeyinde bir proje mi? Tesis mühendisleri, robotik mühendisleri, finans mühendisleri vb. Gibi insanlar onları gerçekten kullanıyor mu (ihtiyaçlarına uygun başka bir dilde)?

Şahsen bir Haskell uygulamasını tercih etmeme rağmen, diğer önerilere açığım. Örneğin, bir Erlang uygulamasına sahip olmak özellikle eğlenceli olurdu - o zaman akıllı, uyarlanabilir, kendi kendine öğrenen bir sunucu sürecine sahip olmak çok kolay olurdu!

Şu anda, işlevsel reaktif programlama için esas olarak iki pratik Haskell kitaplığı var. Her ikisi de tek kişiler tarafından yapılmaktadır, ancak diğer Haskell programcılarından da kod katkıları almaktadır:

• Netwire verimlilik, esneklik ve öngörülebilirliğe odaklanır. Kendi olay paradigmasına sahiptir ve ağ hizmetleri ve karmaşık simülasyonlar dahil olmak üzere geleneksel FRP'nin çalışmadığı alanlarda kullanılabilir. Stil: uygulanabilir ve / veya ok işaretli. İlk yazar ve devam ettiren: Ertuğrul Söylemez (bu benim).

• reaktif-muz , geleneksel FRP paradigmasına dayanır. Kullanımı pratik olsa da, aynı zamanda klasik FRP araştırması için zemin görevi görür. Ana odak noktası kullanıcı arayüzleridir ve wx için hazır bir arayüz vardır. Stil: uygulama. İlk yazar ve geliştirici: Heinrich Apfelmus.

Her ikisini de denemelisiniz, ancak uygulamanıza bağlı olarak muhtemelen birini veya diğerini daha uygun bulacaksınız.

Oyunlar, ağ oluşturma, robot kontrolü ve simülasyonlar için Netwire'ı faydalı bulacaksınız. Çeşitli kullanışlı diferansiyeller, integraller ve şeffaf olay işleme için çok sayıda işlevsellik dahil olmak üzere bu uygulamalar için hazır kablolarla birlikte gelir . Bir eğitim için Control.Wirebağladığım sayfadaki modülün belgelerini ziyaret edin .

Grafik kullanıcı arayüzleri için şu anda en iyi seçiminiz reaktif-muz. Zaten bir wx arayüzüne (ayrı bir reaktif-banana-wx kitaplığı olarak) sahiptir ve Heinrich, bu bağlamda, kod örnekleri de dahil olmak üzere FRP hakkında birçok blog yazmaktadır.

Diğer sorularınızı cevaplamak için: FRP, gerçek zamanlı öngörülebilirliğe ihtiyaç duyduğunuz senaryolarda uygun değildir. Bu büyük ölçüde Haskell'den kaynaklanmaktadır, ancak ne yazık ki FRP'nin daha düşük seviyeli dillerde gerçekleştirilmesi zordur. Haskell'in kendisi gerçek zamanlı olarak hazır hale gelir gelmez, FRP de oraya ulaşacaktır. Kavramsal olarak Netwire, gerçek zamanlı uygulamalar için hazırdır.

Zaman sızıntıları artık gerçekten bir sorun değil çünkü bunlar büyük ölçüde monadik çerçeve ile ilgili. Pratik FRP uygulamaları basitçe tek bir arayüz sunmaz. Yampa bunu başlattı ve hem Netwire hem de reaktif-muz bunun üzerine inşa edildi.

Şu anda FRP kullanan ticari veya başka türlü büyük ölçekli projeler bilmiyorum. Kütüphaneler hazır ama bence insanlar henüz değil.

Şimdiden bazı iyi cevaplar olmasına rağmen, özel sorularınızı cevaplamaya çalışacağım.

1. reaktif, zaman kaçağı problemlerinden dolayı ciddi projelerde kullanılamaz. (bkz. # 3). En benzer tasarıma sahip mevcut kütüphane, ilham olarak reaktif olarak geliştirilen ve Conal Elliott ile tartışılan reaktif-muzdur.

2. Haskell'in kendisi zor gerçek zamanlı uygulamalar için uygun olmasa da, bazı durumlarda yumuşak gerçek zamanlı uygulamalar için Haskell'i kullanmak mümkündür. Mevcut araştırmalara aşina değilim, ancak bunun aşılmaz bir sorun olduğuna inanmıyorum. Ya Yampa gibi sistemlerin ya da Atom gibi kod üretme sistemlerinin bunu çözmek için muhtemelen en iyi yaklaşım olduğundan şüpheleniyorum.

3. "Zaman sızıntısı", değiştirilebilir FRP'ye özgü bir sorundur. Sızıntı, bir sistem eski nesneleri serbest bırakamadığında meydana gelir, çünkü gelecekte bir noktada bir anahtar meydana gelirse bunlara ihtiyaç duyabilir. Bir bellek sızıntısına ek olarak (oldukça şiddetli olabilir), başka bir sonuç da, anahtar oluştuğunda, mevcut durumu oluşturmak için eski nesnelerin zinciri geçilirken sistemin duraklaması gerektiğidir.

Yampa ve reaktif-banana'nın eski sürümleri gibi değiştirilemeyen frp kitaplıkları zaman sızıntılarından etkilenmez. Değiştirilebilir frp kitaplıkları genellikle iki şemadan birini kullanır: FRP değerlerinin yaratıldığı özel bir "oluşturma monad" a sahiptirler veya anahtarların oluşabileceği bağlamları sınırlamak için "eskiyen" tipte bir parametre kullanırlar. elerea (ve muhtemelen ağ teli?) birincisini kullanırken, son reaktif muz ve greyfurt ikincisini kullanıyor.

"Değiştirilebilir frp" derken, Conal'ın işlevini uygulayan switcher :: Behavior a -> Event (Behavior a) -> Behavior aveya aynı semantiği kastediyorum . Bu, ağın şeklinin çalışırken dinamik olarak değişebileceği anlamına gelir.

Bu, @ ertes'in monadik arayüzler hakkındaki ifadesine gerçekten çelişmiyor: Bir Monadörnek sağlamak Eventzaman sızıntılarını mümkün kılıyor ve yukarıdaki yaklaşımlardan herhangi biri ile eşdeğer Monad örneklerini tanımlamak artık mümkün değil.

Son olarak, FRP ile daha yapılacak çok iş olsa da, bazı yeni platformların (reaktif-banana, elerea, netwire) onlardan güvenilir kod oluşturabilecek kadar kararlı ve olgun olduğunu düşünüyorum. Ancak nasıl iyi performans elde edeceğinizi anlamak için giriş ve çıkışları öğrenmek için çok zaman harcamanız gerekebilir.

Mono ve .Net alanındaki birkaç öğeyi ve çok kısa bir süre önce bulduğum Haskell alanından bir tane listeleyeceğim. Haskell ile başlayacağım.

Karaağaç - bağlantı

Sitesine göre açıklaması:

Elm, ön uç web geliştirmeyi daha keyifli hale getirmeyi hedefliyor. HTML, CSS ve JavaScript'in sistemik sorunlarını düzelten GUI programlamaya yeni bir yaklaşım getiriyor. Elm, görsel düzen ile hızlı ve kolay bir şekilde çalışmanıza, tuvali kullanmanıza, karmaşık kullanıcı girdilerini yönetmenize ve geri arama cehenneminden kaçmanıza olanak tanır.

Kendi FRP varyantına sahiptir . Örnekleriyle oynamaktan oldukça olgun görünüyor.

Reaktif Uzantılar - bağlantı

Ön sayfasından açıklama:

Reaktif Uzantılar (Rx), gözlemlenebilir dizileri ve LINQ tarzı sorgu operatörlerini kullanarak eşzamansız ve olay tabanlı programları oluşturmak için bir kitaplıktır. Rx kullanan geliştiriciler, Observables ile eşzamansız veri akışlarını temsil eder, LINQ işleçlerini kullanarak eşzamansız veri akışlarını sorgular ve Zamanlayıcıları kullanarak eşzamansız veri akışlarındaki eşzamanlılığı parametreleştirir. Basitçe söylemek gerekirse, Rx = Observables + LINQ + Schedulers.

Reaktif Uzantılar MSFT'den gelir ve olayları işlemeyi basitleştiren birçok mükemmel operatörü uygular. Öyleydi kaynaklı açık gün önce sadece bir çift. Çok olgundur ve üretimde kullanılır; bence Windows 8 API'leri için TPL kütüphanesinin sağladığından daha güzel bir API olurdu; çünkü gözlemlenebilirler hem sıcak hem de soğuk olabilir ve yeniden denenebilir / birleştirilebilir vb. iken, görevler her zaman çalışan, hatalı veya tamamlanmış olan sıcak veya tamamlanmış hesaplamaları temsil eder.

Eşzamansızlık için Rx kullanarak sunucu tarafı kodu yazdım, ancak C # ile işlevsel olarak yazmanın biraz can sıkıcı olabileceğini itiraf etmeliyim. F # birkaç sarmalayıcıya sahiptir, ancak API gelişimini izlemek zor, çünkü grup nispeten kapalı ve diğer projeler gibi MSFT tarafından desteklenmiyor.

Açık kaynak kullanımı, IL-JS derleyicisinin açık kaynak kullanımı ile geldi, bu nedenle muhtemelen JavaScript veya Elm ile iyi çalışabilirdi.

F # / C # / JS / Haskell'i muhtemelen RabbitMQ ve SocksJS gibi bir mesaj aracısı kullanarak çok güzel bir şekilde birbirine bağlayabilirsiniz.

Bling UI Toolkit - bağlantı

Ön sayfasından açıklama:

Bling, Microsoft'un WPF / .NET'inde görüntüleri, animasyonları, etkileşimleri ve görselleştirmeleri kolayca programlamak için C # tabanlı bir kitaplıktır. Bling, zengin UI tasarım fikirlerinin hızlı prototiplenmesine yardımcı olmak için bazen program yapan tasarım teknolojisi uzmanlarına, yani tasarımcılara yöneliktir. Öğrenciler, sanatçılar, araştırmacılar ve hobiler de Bling'i fikirleri veya görselleştirmeleri hızlı bir şekilde ifade etmek için bir araç olarak faydalı bulacaklar. Bling'in API'leri ve yapıları, üretim kodunun dikkatli bir şekilde programlanmasının aksine, atılan kodun hızlı programlanması için optimize edilmiştir.

Ücretsiz LtU makalesi .

Bunu test ettim, ancak bir müşteri projesi için çalışmadım. Harika görünüyor, değerler arasındaki bağları oluşturan güzel C # operatörü aşırı yüklemesine sahip. Olay kaynağı olarak WPF / SL / (WinRT) 'deki bağımlılık özelliklerini kullanır. 3D animasyonları makul donanımlarda iyi çalışıyor. Görselleştirmeye ihtiyaç duyan bir proje bulursam bunu kullanırdım; muhtemelen Windows 8'e taşıyor.

ReactiveUI - bağlantı

Daha önce MSFT'de, şimdi de Github'da olan Paul Betts bu çerçeveyi yazdı. Onunla oldukça kapsamlı bir şekilde çalıştım ve modeli beğendim. Blink'ten daha fazla ayrıştırılmıştır (doğası gereği Rx ve soyutlamalarını kullanmaktan) - onu kullanarak kodu birim test etmeyi kolaylaştırır. Windows için github git istemcisi burada yazılmıştır.

Yorumlar

Reaktif model, performans gerektiren uygulamaların çoğu için yeterince performanslıdır. Gerçek zamanlı olarak çok şey düşünüyorsanız, GC dillerinin çoğunun sorunları olduğuna bahse girerim. Rx, ReactiveUI, GClenmesi gereken bir miktar küçük nesne yaratır, çünkü bu şekilde abonelikler yaratılır / atılır ve geri aramaların reaktif "monad" ında ara değerler ilerletilir. Genel olarak .Net üzerinde reaktif programlamayı görev tabanlı programlamaya tercih ederim çünkü geri çağırmalar statiktir (derleme zamanında bilinir, ayırma yoktur), görevler dinamik olarak tahsis edilirken (bilinmez, tüm aramaların bir örneğe ihtiyacı vardır, çöp yaratılır) - ve lambdas derleyici tarafından üretilen sınıflar.

Açıkçası C # ve F # kesinlikle değerlendirilir, bu nedenle burada zaman sızıntısı bir sorun değildir. JS için aynı. Yine de tekrar oynatılabilir veya önbelleğe alınmış gözlemlenebilirlerle ilgili bir sorun olabilir.