İşlevsel GUI programlama mümkün müdür? [kapalı]

Geçenlerde FP hatasını yakaladım (Haskell öğrenmeye çalışıyorum) ve şimdiye kadar gördüklerimden çok etkilendim (birinci sınıf fonksiyonlar, tembel değerlendirme ve diğer tüm güzellikler). Ben henüz uzman değilim, ama zaten temel algoritmalar için (işlevsel olarak geri gitmekte sorun yaşıyorum) zorunluluk olarak "işlevsel" akıl yürütmek daha kolay bulmaya başladım.

Bununla birlikte, mevcut FP'nin düz düştüğü bir alan GUI programlamasıdır. Haskell yaklaşımı, zorunlu GUI araç setlerini (GTK + veya wxWidgets gibi) sarmak ve zorunlu bir stili simüle etmek için "do" bloklarını kullanmak gibi görünüyor. F # kullanmadım, ancak benim anlayışım, .NET sınıfları ile OOP kullanarak benzer bir şey yapıyor olmasıdır. Açıkçası, bunun iyi bir nedeni var - mevcut GUI programlama tamamen IO ve yan etkilerle ilgilidir, bu nedenle mevcut çerçevelerin çoğunda tamamen işlevsel programlama mümkün değildir.

Sorum şu ki GUI programlamaya işlevsel bir yaklaşım mümkün mü? Bunun pratikte nasıl görüneceğini hayal etmekte zorlanıyorum. Herkes deneysel veya başka türlü, bu tür bir şey deneyen (hatta işlevsel bir dil için sıfırdan tasarlanmış çerçeveler) biliyor mu? Yoksa çözüm GUI parçaları için OOP ve mantık için FP ile sadece melez bir yaklaşım kullanmak mı? (Ben sadece meraktan soruyorum - FP'nin "gelecek" olduğunu düşünmek isterim, ancak GUI programlama oldukça büyük bir delik gibi görünüyor.)

Haskell yaklaşımı, zorunlu GUI araç setlerini (GTK + veya wxWidgets gibi) sarmak ve zorunlu bir stili simüle etmek için "do" bloklarını kullanmak gibi görünüyor

Bu gerçekten de "Haskell yaklaşımı" değildir - zorunlu GUI araç setlerine en direkt olarak - zorunlu bir arabirim üzerinden nasıl bağlanırsınız. Haskell oldukça belirgin bağlara sahip.

GUI'lere, çoğunlukla Haskell'de ve öncelikle fonksiyonel reaktif programlama kullanılarak, orta derecede olgunlaşmış veya daha deneysel tamamen işlevsel / beyan edici yaklaşımlar vardır.

Bazı örnekler:

• refleks platformu, https://github.com/reflex-frp/reflex-platform
• greyfurt, http://hackage.haskell.org/package/grapefruit-ui-gtk
• reaktif, http://hackage.haskell.org/package/reactive-glut
• wxFruit, http://hackage.haskell.org/package/wxFruit
• reaktif-muz, http://hackage.haskell.org/package/reactive-banana

Haskell, Flapjax, http://www.flapjax-lang.org/ hakkında bilgi sahibi olmayanlarınız için JavaScript'in üstünde işlevsel reaktif programlama uygulamasıdır.

Sorum şu ki GUI programlamaya işlevsel bir yaklaşım mümkün mü?

Aradığınız anahtar kelimeler "fonksiyonel reaktif programlama" (FRP).

Conal Elliott ve diğerleri, FRP için doğru soyutlamayı bulmaya çalışmaktan biraz yazlık endüstrisi yaptılar. Haskell'de FRP kavramlarının birkaç uygulaması vardır.

Conal'ın en yeni "Push-Pull Fonksiyonel Reaktif Programlama" belgesiyle başlamayı düşünebilirsiniz , ancak bazıları haskell.org sitesinden bağlantılı birkaç başka (daha eski) uygulama vardır . Conal, tüm alan adını kapsayan bir ustalığa sahiptir ve makalesi, daha önce gelenlere referans olmadan okunabilir.

Bu yaklaşımın GUI gelişimi için nasıl kullanılabileceğine dair bir fikir edinmek için, 90'lı yılların ortalarında tasarlanan, bugünlerde dişte biraz uzarken , sağlam bir FRP yaklaşımı sunan Fudgets'a bakmak isteyebilirsiniz. GUI tasarımına.

Windows Presentation Foundation , işlevsel yaklaşımın GUI programlama için çok iyi çalıştığının bir kanıtıdır. Birçok işlevsel yönü vardır ve "iyi" WPF kodu (MVVM paternini araştırın) zorunlu olana göre fonksiyonel yaklaşımı vurgular. WPF'nin en başarılı gerçek dünya işlevsel GUI araç takımı olduğunu cesurca söyleyebilirim :-)

WPF, XAML'deki Kullanıcı arabirimini açıklar (işlevsel olarak C # veya F # 'ya da yeniden yazabilmenize rağmen), böylece yazacağınız bazı kullanıcı arabirimleri oluşturmak için:

<!-- Declarative user interface in WPF and XAML --> 
<Canvas Background="Black">
   <Ellipse x:Name="greenEllipse" Width="75" Height="75" 
      Canvas.Left="0" Canvas.Top="0" Fill="LightGreen" />
</Canvas>

Dahası, WPF ayrıca başka bir bildirim etiketi kümesi kullanarak olaylara animasyonları ve tepkileri bildirerek tanımlamanızı sağlar (yine aynı şey C # / F # kodu olarak yazılabilir):

<DoubleAnimation
   Storyboard.TargetName="greenEllipse" 
   Storyboard.TargetProperty="(Canvas.Left)"
   From="0.0" To="100.0" Duration="0:0:5" />

Aslında, WPF'nin Haskell'in FRP'si ile birçok ortak yanı olduğunu düşünüyorum (WPF tasarımcılarının FRP'yi bilmediğine inanıyorum ve biraz talihsiz - WPF, işlevselliği kullanıyorsanız bazen biraz garip ve belirsiz hissediyor. bakış açısı).

Aslında fonksiyonel programlama (F #) kullanıcı arayüzü programlama için örneğin C # çok daha iyi bir araç olduğunu söyleyebilirim. Sadece sorunu biraz farklı düşünmelisin.

Bu konuyu Bölüm 16'daki işlevsel programlama kitabımda tartışıyorum , ancak (IMHO) 'yı F #' de kullanabileceğiniz en ilginç modeli gösteren ücretsiz bir alıntı var . Dikdörtgen çizimlerini uygulamak istediğinizi varsayalım (kullanıcı düğmeye basar, fareyi hareket ettirir ve düğmeyi serbest bırakır). F # 'da, şöyle bir şey yazabilirsiniz:

let rec drawingLoop(clr, from) = async { 
   // Wait for the first MouseMove occurrence 
   let! move = Async.AwaitObservable(form.MouseMove) 
   if (move.Button &&& MouseButtons.Left) = MouseButtons.Left then 
      // Refresh the window & continue looping 
      drawRectangle(clr, from, (move.X, move.Y)) 
      return! drawingLoop(clr, from) 
   else
      // Return the end position of rectangle 
      return (move.X, move.Y) } 

let waitingLoop() = async { 
   while true do
      // Wait until the user starts drawing next rectangle
      let! down = Async.AwaitObservable(form.MouseDown) 
      let downPos = (down.X, down.Y) 
      if (down.Button &&& MouseButtons.Left) = MouseButtons.Left then 
         // Wait for the end point of the rectangle
         let! upPos = drawingLoop(Color.IndianRed, downPos) 
         do printfn "Drawn rectangle (%A, %A)" downPos upPos }

Bu çok zorunlu bir yaklaşımdır (alışılmış pragmatik F # tarzında), ancak mevcut çizim durumunu depolamak ve inital konumu depolamak için değişebilir durumu kullanmaktan kaçınır. Yine de daha işlevsel hale getirilebilir, bunu yüksek lisans tezimin bir parçası olarak yapan ve birkaç gün içinde blogumda bulunması gereken bir kütüphane yazdım .

Fonksiyonel Reaktif Programlama daha işlevsel bir yaklaşımdır, ancak oldukça gelişmiş Haskell özelliklerine (oklar gibi) dayandığından biraz daha zor buluyorum. Bununla birlikte, çok sayıda durumda çok zariftir. Sınırlaması, bir durum makinesini (reaktif programlar için yararlı bir zihinsel model olan) kolayca kodlayamamanızdır. Bu, yukarıdaki F # tekniği kullanılarak çok kolaydır.

F # veya OCaml gibi karma bir işlevsel / OO dilinde veya yan etkilerin IO monadına düştüğü Haskell gibi tamamen işlevsel bir dilde olun, çoğunlukla bir GUI'yi yönetmek için bir ton işin gerekli olduğu durumdur. tamamen işlevsel bir algoritmadan çok "yan etki" ye benzer.

Bununla birlikte, fonksiyonel GUI'lere gerçekten sağlam araştırmalar yapıldı . Fudgets veya FranTk gibi bazı (çoğunlukla) fonksiyonel araç takımları bile vardır .

Dizinin bir GUI oluşturduğu F # üzerinde Don Syme'nin dizisini kontrol edebilirsiniz. aşağıdaki bağlantı serinin üçüncü kısmına aittir (oradan diğer iki kısma bağlayabilirsiniz).

WPF geliştirme için F # kullanmak çok ilginç bir GUI paradigması olacaktır ...

http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Dr-Don-Syme-Introduction-to-F-3-of-3/

Fonksiyonel Reaktif Programlamanın arkasındaki fikir açıcı fikirlerden biri, olaylara İKİ tepki veren bir olay işleme fonksiyonuna ve bir sonraki olay işleme fonksiyonuna sahip olmaktır. Böylece gelişen bir sistem, olay işleme işlevlerinin bir sırası olarak temsil edilir.

Benim için, Yampa'yı öğrenmek, o işlev üreten işlevleri düzgün bir şekilde elde etmek için çok önemli bir bakış oldu. Yampa hakkında güzel makaleler var. Ben Yampa Arcade tavsiye:

http://www.cs.nott.ac.uk/~nhn/Talks/HW2003-YampaArcade.pdf (slaytlar, PDF) http://www.cs.nott.ac.uk/~nhn/Publications/hw2003. pdf (tam makale, PDF)

Haskell.org'da Yampa'da bir wiki sayfası var

http://www.haskell.org/haskellwiki/Yampa

Orijinal Yampa ana sayfası:

http://www.haskell.org/yampa (maalesef şu anda kırılmış)

Bu soru ilk sorulduğu için, Elm tarafından fonksiyonel reaktif programlama biraz daha yaygın hale getirildi.

Tamamen işlevsel bir tarayıcı içi GUI'nin nasıl oluşturulacağına dair gerçekten mükemmel etkileşimli öğreticiler içeren http://elm-lang.org adresinden kontrol etmenizi öneririm .

Kendinize sağlamanız gereken kodun yalnızca saf işlevlerden oluştuğu tamamen işlevsel GUI'ler yapmanıza olanak tanır. Şahsen çeşitli Haskell GUI çerçevelerinden çok daha kolay buldum.

Elliot'un FRP ile ilgili konuşmasını burada bulabilirsiniz .

Ek olarak, gerçekten bir cevap değil, bir açıklama ve birkaç düşünce : bir şekilde "fonksiyonel GUI" terimi bir oksimoron (aynı terimdeki saflık ve IO) gibi görünüyor.

Ancak belirsiz anlayışım, fonksiyonel GUI programlamanın, (gerçek) zamana bağımlı kullanıcı girişini alan ve zamana bağlı GUI çıkışı üreten zamana bağlı bir fonksiyonu tanımlayıcı olarak tanımlamakla ilgilidir.

Başka bir deyişle, bu işlev, değişken durumu zorunlu olarak kullanan bir algoritma yerine, deklaratif olarak bir diferansiyel denklem gibi tanımlanır.

Geleneksel FP'de zaman bağımsız fonksiyonlar kullanılırken, FRP'de bir program tanımlamak için zamana bağlı fonksiyonlar yapı taşları olarak kullanılır.

Kullanıcının etkileşime girebileceği bir yay üzerinde bir topu simüle etmeyi düşünelim. Topun konumu grafiksel çıktıdır (ekranda), topu iten kullanıcı bir tuşa basar (giriş).

FRP'de bu simülasyon programını tanımlamak (anlayışım doğrultusunda) tek bir diferansiyel denklemle (deklaratif) yapılır: hızlanma * kütle = - yay gerilmesi * yay sabiti + Kullanıcı tarafından uygulanan kuvvet.

İşte ELM'de bu bakış açısını gösteren bir video .

2016 yılı itibariyle Haskell için Sodium ve Reflex (aynı zamanda Netwire) gibi nispeten daha olgunlaşmış FRP çerçeveleri vardır.

Manning Fonksiyonel Reaktif Programlama üzerinde kitap vitrinleri çalışan örnekler için Sodyum Java sürümü, ve karşılaştırmalı olarak bir FRP GUI kod tabanı davranacağını ve ölçekler Aktör temelli yaklaşımların yanı sıra imperative ve nasıl göstermektedir.

Ayrıca, Arrowized FRP ve yan etkiler, IO ve mutasyonun yasalara uyan, saf FRP ortamına dahil edilme olasılığı hakkında yeni bir makale var: http://haskell.cs.yale.edu/wp-content/uploads/2015/10/ dwc-yale-biçimlendirilmiş-tez.pdf .

Ayrıca belirtmek gerekir ki, ReactJS ve Angular ve diğerleri gibi JavaScript çerçeveleri zaten ölçeklenebilir ve oluşturulabilir GUI bileşenleri elde etmek için bir FRP veya başka bir şekilde işlevsel bir yaklaşım kullanmaktadır.

XUL gibi biçimlendirme dilleri, beyan edici bir şekilde bir GUI oluşturmanıza olanak tanır.

Bunu ele almak için F # kullanarak bazı düşüncelerimi yayınladım,

http://fadsworld.wordpress.com/2011/04/13/f-in-the-enterprise-i/ http://fadsworld.wordpress.com/2011/04/17/fin-the-enterprise-ii- 2 /

Ayrıca seri bitirmek ve F # UX programlama katkıda nasıl göstermek için bir video eğitimi yapmayı planlıyorum.

Burada sadece F # bağlamında konuşuyorum.

-Fahad

Tüm bu diğer cevaplar fonksiyonel programlama üzerine kuruludur, ancak kendi tasarım kararlarının çoğunu alırlar. Temelde tamamen işlevlerden ve basit soyut veri türlerinden yapılmış bir kütüphane gloss. İşte playişlevi için kaynak türü

-- | Play a game in a window. Like `simulate`, but you manage your own input events.
play    :: Display              -- ^ Display mode.
        -> Color                -- ^ Background color.
        -> Int                  -- ^ Number of simulation steps to take for each second of real time.
        -> world                -- ^ The initial world.
        -> (world -> Picture)   -- ^ A function to convert the world a picture.
        -> (Event -> world -> world)    
                -- ^ A function to handle input events.
        -> (Float -> world -> world)
                -- ^ A function to step the world one iteration.
                --   It is passed the period of time (in seconds) needing to be advanced.
        -> IO ()

Gördüğünüz gibi, tamamen diğer kütüphanelerin size yardımcı olduğu basit soyut türlerle saf işlevler sağlayarak çalışır.

Haskell'de yeni insanlar tarafından fark edilen en belirgin yenilik, dış dünya ile iletişim kurmakla ilgili saf olmayan dünya ile saf hesaplama ve algoritma dünyası arasında bir ayrım olması. Sıkça başlayan bir başlangıç ​​sorusu, "Nasıl dönüşebilirim IO, yani IO adönüşebilirim a?" Bunun yolu, IO ve zincir efektleri gerçekleştiren kod yazmak için monad'ları (veya diğer soyutlamaları) kullanmaktır. Bu kod dış dünyadan veri toplar, bir model oluşturur, muhtemelen saf kod kullanarak bazı hesaplamalar yapar ve sonucu çıkarır.

Yukarıdaki model söz konusu olduğunda, IOmonaddaki GUI'leri manipüle etmede korkunç bir şey görmüyorum . Bu stille ortaya çıkan en büyük sorun, modüllerin artık oluşturulamamasıdır, yani, programımdaki ifadelerin küresel yürütme sırası hakkındaki bilgimin çoğunu kaybediyorum. Onu kurtarmak için, eşzamanlı, zorunlu GUI kodunda olduğu gibi benzer bir muhakeme uygulamak zorundayım. Bu arada, saf olmayan GUI kodu için, yürütme sırası IOmonad'ın >==operatörünün tanımı nedeniyle açıktır (en azından sadece bir iş parçacığı olduğu sürece). Saf kod için, performansı artırmak veya sonuçta ortaya çıkan değerlendirmelerden kaçınmak için köşe durumlar hariç, hiç önemli değil ⊥.

Konsol ve grafik IO arasındaki en büyük felsefi fark, ilkini uygulayan programların genellikle senkron tarzda yazılmasıdır. Bu mümkündür (sinyalleri ve diğer açık dosya tanımlayıcılarını bir kenara bırakarak) yalnızca bir olay kaynağı vardır: yaygın olarak adlandırılan bayt akışı stdin. GUI'ler doğal olarak eşzamansızdır ve klavye olaylarına ve fare tıklamalarına tepki vermek zorundadır.

İşlevsel olmayan bir şekilde asenkron IO yapma felsefesine Fonksiyonel Reaktif Programlama (FRP) denir. ReactiveX gibi kütüphaneler ve Elm gibi çerçeveler sayesinde son zamanlarda saf olmayan, işlevsel olmayan dillerde çok fazla çekiş elde etti . Özetle, GUI öğelerini ve olay kaynakları olarak "gözlemlenebilir" adı verilen olay akışları gibi diğer şeyleri (dosyalar, saatler, alarmlar, klavye, fare gibi) görüntülemek gibidir. Bu olaylar gibi bilinen operatörleri ile birleştirilir map, foldl, zip, filter, concat, join, vb, yeni akışları elde edilir. Bu yararlıdır, çünkü programın kendisi scanl . map reactToEvents $ zipN <eventStreams>, program Ntarafından şimdiye kadar dikkate alınan gözlemlenebilirlerin sayısına eşit olan programdan görülebilir .

FRP gözlemlenebilirleriyle çalışmak, bir akıştaki olaylar zamanında sıralandığı için birleştirilebilirliğin kurtarılmasını mümkün kılar. Bunun nedeni, olay akışı soyutlamasının tüm gözlemlenebilirleri kara kutular olarak görüntülemeyi mümkün kılmasıdır. Sonuç olarak, olay akışlarını işleçleri kullanarak birleştirmek, yürütme sırasında bazı yerel siparişleri geri verir. Bu beni, Haskell'deki tüm işlevlerin referans olarak şeffaf olması gerektiği gibi, programımın gerçekte hangi değişmezlere dayandığı konusunda çok daha dürüst olmaya zorlar: Programımın başka bir bölümünden veri çekmek istiyorsam, açık olmalıyım reklam, işlevlerim için uygun bir tür bildiriyor. (Saf olmayan kod yazmak için Etki Alanına Özgü bir dil olan IO monad, bunu etkili bir şekilde atlar)

Fonksiyonel programlama, üniversitedeyken devam etmiş olabilir, ancak hatırladığım gibi, fonksiyonel bir programlama sisteminin ana noktası programcının herhangi bir “yan etki” yaratmasını durdurmaktı. Bununla birlikte, kullanıcılar oluşturulan yan etkiler nedeniyle yazılım satın alırlar, örneğin bir kullanıcı arayüzünü güncelleme.