Czy funkcjonalne programowanie GUI jest możliwe? [zamknięte]

Moje pytanie brzmi, czy można mieć funkcjonalne podejście do programowania GUI?

Słowa kluczowe, których szukasz, to "functional reactive programming" (FRP).

Conal Elliott i niektórzy inni zrobili trochę przemysłu chałupniczego, próbując znaleźć właściwą abstrakcję dla FRP. Istnieje kilka implementacji koncepcji FRP w Haskell.

Aby poczuć, jak to podejście może być używane do rozwoju GUI, warto spojrzeć na Fudgets , który podczas gdy jest coraz trochę długi w zębie w dzisiejszych czasach, jest zaprojektowany w połowie lat 90-tych, prezentuje solidne podejście FRP do projektu GUI.

Windows Presentation Foundation jest dowodem na to, że podejście funkcjonalne działa bardzo dobrze w przypadku programowania GUI. Ma wiele aspektów funkcjonalnych i "dobry" kod WPF (search for MVVM pattern) kładzie nacisk na podejście funkcjonalne nad imperatywem. Mogę śmiało twierdzić, że WPF jest najbardziej udanym w świecie rzeczywistym funkcjonalnym zestawem narzędzi GUI: -)

WPF opisuje interfejs użytkownika w XAML (chociaż można go przepisać do funkcjonalnie wyglądającego C # lub F#), więc aby stworzyć jakiś interfejs użytkownika napisałbyś:

<!-- 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>

Co więcej, WPF pozwala również deklaratywnie opisywać animacje i reakcje na zdarzenia za pomocą innego zestawu deklaratywnych tagów (ponownie to samo można zapisać jako kod C#/F#):

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

W rzeczywistości, myślę, że WPF ma wiele wspólnego z FRP Haskell (choć wierzę, że projektanci WPF nie wiedzieli o FRP i jest to trochę niefortunne-WPF czasami wydaje się trochę dziwne i niejasne, jeśli używasz funkcjonalnego punktu widzenia).

Powiedziałbym, że programowanie funkcyjne (F#) jest dużo lepszym narzędziem do programowania interfejsu użytkownika niż np. C#. Po prostu trzeba myśleć o problemie trochę inaczej.

Omawiam ten temat w mojej książce o programowaniu funkcyjnym w rozdziale 16, ale jest darmowy fragment, który pokazuje (IMHO) najciekawszy wzór, którego można użyć W F#. Powiedzieć, że chcesz zaimplementować rysowanie prostokątów (użytkownik naciska przycisk, przesuwa myszki i zwalnia przycisk). W F# możesz napisać coś takiego:

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 }

Jest to bardzo imperatywne podejście (w zwyczajowym pragmatycznym stylu F#), ale pozwala uniknąć używania zmiennego stanu do przechowywania bieżącego stanu rysunku i przechowywania początkowej lokalizacji. Może być jeszcze bardziej funkcjonalny, napisałem bibliotekę, która robi to w ramach mojej pracy magisterskiej, która powinna być dostępna na mój blog w ciągu najbliższych kilku dni.

Funkcjonalne Programowanie reaktywne jest bardziej funkcjonalne podejście, ale uważam, że jest nieco trudniejsze w użyciu, ponieważ opiera się na dość zaawansowanych funkcjach Haskella (takich jak strzałki). Jednak w dużej liczbie przypadków jest bardzo elegancki. Jego ograniczeniem jest to, że nie można łatwo zakodować maszyny stanowej (która jest użytecznym modelem mentalnym dla programów reaktywnych). Jest to bardzo proste przy użyciu powyższej techniki F#.

Niezależnie od tego, czy jesteś w hybrydowym języku funkcyjnym/oo, takim jak F# czy OCaml, czy w języku czysto funkcjonalnym, takim jak Haskell, w którym efekty uboczne są relegowane do monady IO, to głównie przypadek, że mnóstwo pracy wymaganej do zarządzania GUI jest znacznie bardziej "efektem ubocznym" niż czysto funkcjonalnym algorytmem.

To powiedziawszy, przeprowadzono naprawdę solidne badania w funkcjonalny GUI . Istnieją nawet niektóre (głównie) funkcjonalne Zestawy narzędzi, takie jak Fudgets lub FranTk .

Możesz sprawdzić serię Don Syme na F#, gdzie demo tworzy gui. poniższy link jest do trzeciej części serii (możesz link stamtąd do pozostałych dwóch części).

Używanie F # do tworzenia WPF byłoby bardzo interesującym paradygmatem GUI...

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

Jednym z pomysłów otwierających umysł za funkcyjnym programowaniem reaktywnym jest funkcja obsługi zdarzeń produkująca zarówno reakcję na zdarzenia, jak i następną funkcję obsługi zdarzeń. W ten sposób rozwijający się system jest reprezentowany jako sekwencja funkcji obsługi zdarzeń.

Dla mnie nauka Yampy stała się kluczowym poingiem, aby właściwie uzyskać tę funkcję-produkującą-funkcje. Są fajne papiery o Yampie. Polecam Yampa Arcade:

Http://www.cs.nott.ac.uk/~nhn/rozmowy / HW2003-YampaArcade.pdf (slajdy, PDF) http://www.cs.nott.ac.uk/ ~ nhn/publikacje / Hw2003. pdf (cały artykuł, PDF)

Jest strona wiki na Yampa w Haskell.org

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

Oryginalna Strona domowa Yampy:

Http://www.haskell.org/yampa (niestety w tej chwili jest zepsuty)

Rozmowę Elliota na FRP można znaleźć tutaj .

W dodatku, nie tak naprawdę odpowiedź, ale uwaga i kilka myśli: jakoś termin "funkcjonalny GUI" wydaje się trochę jak oksymoron(pureness i IO w tym samym terminie).

Ale moje niejasne zrozumienie jest to, że programowanie funkcjonalne GUI polega na deklaratywnym zdefiniowaniu funkcji zależnej od czasu, która pobiera (rzeczywisty)czas zależny od wejścia użytkownika i produkuje zależne od czasu wyjście GUI.

Innymi słowy, funkcja ta jest definiowana jak równanie różniczkowe deklaratywnie, a nie przez algorytm imperatywnie wykorzystujący stan zmienny.

Tak więc w konwencjonalnym FP używa się funkcji niezależnych od czasu, podczas gdy w FRP używa się funkcji zależnych od czasu jako bloków konstrukcyjnych do opisu programu.

Pomyślmy o symulowaniu piłki na sprężynce, z którą użytkownik może wchodzić w interakcje. Pozycja piłki jest wyjściem graficznym (na ekranie), użytkownik pchający piłkę jest naciśnięciem klawisza (wejściem).

Opisanie tego programu symulacyjnego w FRP (według mojego zrozumienia) odbywa się za pomocą jednego równania różniczkowego (deklaratywnie): przyspieszenie * masa = - rozciągnięcie sprężyny * stała sprężyny + siła wywierana przez użytkownika.

Oto film na ELM , który ilustruje ten punkt widzenia.

Odkąd to pytanie zostało zadane po raz pierwszy, programowanie funkcjonalne stało się bardziej powszechne przez Elm.

Proponuję sprawdzić na http://elm-lang.org , który ma również naprawdę doskonałe interaktywne samouczki, jak stworzyć w pełni funkcjonalny GUI w przeglądarce.

Pozwala na tworzenie w pełni funkcjonalnych GUI, w których kod, który musisz DOSTARCZYĆ, składa się tylko z czystych funkcji. Osobiście uważam, że dużo łatwiej się dostać niż różne Haskell GUI framework.

Od 2016 roku istnieje kilka innych, stosunkowo dojrzałych frameworków FRP dla Haskell, takich jak Sodium i Reflex (ale także Netwire).

The Manning book on Functional Reactive Programming prezentuje Java wersję Sodium, jako przykłady robocze, i ilustruje, jak zachowuje się baza kodu GUI FRP i skaluje się w porównaniu z imperatywem, a także podejściem opartym na aktorze.

Jest też niedawny artykuł na Arrowized FRP i perspektywa włączenia skutków ubocznych, IO i mutacja w ustawieniu zgodnym z prawem, czystym ustawieniu FRP: http://haskell.cs.yale.edu/wp-content/uploads/2015/10/dwc-yale-formatted-dissertation.pdf.

Warto również zauważyć, że JavaScript frameworków takich jak ReactJS i Angular i wiele innych albo już są lub idą w kierunku korzystania z FRP lub inaczej funkcjonalne podejście do osiągnięcia skalowalne i komponowalne komponenty GUI.

Języki znaczników, takie jak XUL, pozwalają zbudować GUI w deklaratywny sposób.

Aby się tym zająć zamieściłem kilka moich przemyśleń w using F#,

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

Planuję również zrobić samouczek wideo, aby zakończyć serię i pokazać, jak F # może przyczynić się do programowania UX.

Mówię tu tylko w kontekście F#.

-Fahad

Wszystkie te odpowiedzi opierają się na programowaniu funkcjonalnym, ale podejmują wiele własnych decyzji projektowych. Jedną z bibliotek zbudowanych zasadniczo w całości z funkcji i prostych abstrakcyjnych typów danych jest gloss. Oto typ dla jego play Funkcja ze źródła

-- | 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 ()

Jak widzisz, działa całkowicie poprzez dostarczanie czystych funkcji z prostymi abstrakcyjnymi typami, w których pomagają inne biblioteki.

Najbardziej widoczną innowacją zauważoną przez ludzi nowych w Haskell jest to, że istnieje oddzielenie między nieczystym światem, który zajmuje się komunikacją ze światem zewnętrznym, a czystym światem obliczeń i algorytmów. Częstym pytaniem dla początkujących jest "Jak mogę pozbyć się IO, tj. przekształcić IO a w a?"Sposobem na to jest użycie monad (lub innych abstrakcji) do pisania kodu, który wykonuje efekty IO i chains. Kod ten zbiera dane ze świata zewnętrznego, tworzy model tego, robi pewne obliczenia, ewentualnie stosując czysty kod, i wyprowadza wynik.

Jeśli chodzi o powyższy model, nie widzę nic strasznego złego w manipulowaniu Gui w IO monadzie. Największym problemem wynikającym z tego stylu jest to, że moduły nie są już komponowalne, tzn. tracę większość mojej wiedzy na temat globalnego porządku wykonywania poleceń w moim programie. Aby go odzyskać, muszę zastosować podobne rozumowanie jak w równoległym, imperatywnym GUI kod. Tymczasem dla nieczystego, nie-GUI kodu kolejność wykonania jest oczywista ze względu na definicję IO operatora >== monada (przynajmniej tak długo, jak jest tylko jeden wątek). W przypadku czystego kodu nie ma to żadnego znaczenia, z wyjątkiem przypadków narożnych, aby zwiększyć wydajność lub uniknąć oceny skutkującej ⊥.

Największą filozoficzną różnicą między konsolowym a graficznym IO jest to, że programy implementujące te pierwsze są zwykle pisane w stylu synchronicznym. Jest to możliwe ponieważ istnieje (pomijając sygnały i inne otwarte deskryptory plików)tylko jedno źródło zdarzeń: strumień bajtów powszechnie nazywany stdin. Interfejsy graficzne są z natury asynchroniczne i muszą reagować na zdarzenia klawiatury i kliknięcia myszy.

Praca z obiektami obserwacyjnymi FRP umożliwia odzyskanie kompostowalności, ponieważ zdarzenia w strumieniu są uporządkowane w czasie. Powodem jest to, że abstrakcja strumienia zdarzeń umożliwia wyświetlanie wszystkich obserwowalnych jako czarnych skrzynek. Ostatecznie połączenie strumieni zdarzeń za pomocą operatorów powoduje przywrócenie lokalnego porządku podczas realizacji. Zmusza mnie to do większej szczerości co do tego, na których niezmiennikach opiera się mój program, podobnie jak wszystkie funkcje w Haskell muszą być referencjalnie przejrzyste: jeśli chcę pobierać dane z innej części mojego programu, muszę być jawny ad zadeklarować odpowiedni typ dla moich funkcji. Monada IO, będąca specyficznym dla danej domeny językiem do pisania nieczystego kodu, skutecznie omija ten problem.]}

Programowanie funkcyjne mogło ruszyć dalej z czasów, kiedy byłem na uniwersytecie, ale o ile pamiętam, głównym punktem systemu programowania funkcyjnego było powstrzymanie programisty tworzenia jakiegokolwiek "efektu ubocznego". Jednak użytkownicy kupują oprogramowanie ze względu na efekty uboczne, które są tworzone, np. aktualizacja interfejsu użytkownika.