ฟังก์ชั่นการเขียนโปรแกรม GUI สามารถทำได้หรือไม่? [ปิด]

ฉันเพิ่งเจอข้อผิดพลาด FP (พยายามเรียนรู้ Haskell) และฉันก็ประทับใจกับสิ่งที่ฉันเห็นมามาก (ฟังก์ชั่นชั้นหนึ่งการประเมินที่ขี้เกียจและสารพัดอื่น ๆ ) ฉันยังไม่มีความเชี่ยวชาญ แต่ฉันได้เริ่มเข้าใจแล้วว่าเหตุผล "ตามหน้าที่" ง่ายกว่าเหตุผลสำหรับอัลกอริธึมพื้นฐาน (และฉันมีปัญหาในการกลับไปที่ที่ฉันต้องทำ)

พื้นที่หนึ่งที่ FP ในปัจจุบันดูเหมือนจะค่อนข้างแบนอย่างไรก็ตามคือการเขียนโปรแกรม GUI วิธี Haskell ดูเหมือนว่าจะห่อชุดเครื่องมือ GUI ที่จำเป็น (เช่น GTK + หรือ wxWidgets) และใช้บล็อก "do" เพื่อจำลองสไตล์ที่จำเป็น ฉันไม่ได้ใช้ F # แต่ความเข้าใจของฉันคือมันใช้ OOP กับ. NET class เห็นได้ชัดว่ามีเหตุผลที่ดีสำหรับเรื่องนี้ - การเขียนโปรแกรม GUI ปัจจุบันเป็นเรื่องของ IO และผลข้างเคียงดังนั้นการเขียนโปรแกรมที่ใช้งานได้อย่างแท้จริงนั้นไม่สามารถทำได้ด้วยเฟรมเวิร์กส่วนใหญ่ในปัจจุบัน

คำถามของฉันคือมันเป็นไปได้ที่จะมีวิธีการทำงานกับการเขียนโปรแกรม GUI? ฉันมีปัญหาในการจินตนาการว่าสิ่งนี้จะดูเหมือนในทางปฏิบัติ ไม่มีใครรู้เกี่ยวกับกรอบใด ๆ ทดลองหรืออย่างอื่นลองสิ่งนี้ (หรือแม้แต่กรอบที่ออกแบบมาจากพื้นดินสำหรับภาษาทำงาน) หรือวิธีการแก้ปัญหาเพียงแค่ใช้วิธีไฮบริดกับ OOP สำหรับส่วน GUI และ FP สำหรับตรรกะ? (ฉันแค่ขอความอยากรู้อยากเห็น - ฉันชอบที่จะคิดว่า FP คือ "อนาคต" แต่การเขียนโปรแกรม GUI ดูเหมือนจะเป็นช่องโหว่ขนาดใหญ่ที่จะเติมเต็ม)

วิธี Haskell ดูเหมือนจะห่อชุดเครื่องมือ GUI ที่จำเป็น (เช่น GTK + หรือ wxWidgets) และใช้บล็อก "do" เพื่อจำลองสไตล์ที่จำเป็น

นั่นไม่ใช่วิธี "Haskell" จริงๆ - นั่นเป็นเพียงวิธีที่คุณเชื่อมโยงกับชุดเครื่องมือ GUI ที่จำเป็นที่สุดโดยตรง - ผ่านส่วนต่อประสานที่จำเป็น Haskell เพิ่งจะมีการผูกที่โดดเด่นพอสมควร

มีหลายวิธีในระดับปานกลางหรือมากกว่านั้นสำหรับการใช้งานจริง / การทดลองเพื่อ GUIs ซึ่งส่วนใหญ่อยู่ใน Haskell และส่วนใหญ่จะใช้การเขียนโปรแกรมเชิงโต้ตอบ

ตัวอย่างบางส่วนคือ:

• reflex-platform, https://github.com/reflex-frp/reflex-platform
• ส้มโอ, http://hackage.haskell.org/package/grapefruit-ui-gtk
• ปฏิกิริยา, http://hackage.haskell.org/package/reactive-glut
• wxFruit, http://hackage.haskell.org/package/wxFruit
• reactive-banana, http://hackage.haskell.org/package/reactive-banana

สำหรับผู้ที่คุณไม่คุ้นเคยกับ Haskell, Flapjax, http://www.flapjax-lang.org/คือการใช้งานของการเขียนโปรแกรมปฏิกิริยาการทำงานด้านบนของ JavaScript

คำถามของฉันคือมันเป็นไปได้ที่จะมีวิธีการทำงานกับการเขียนโปรแกรม GUI?

คำสำคัญที่คุณกำลังค้นหาคือ "การเขียนโปรแกรมเชิงโต้ตอบ" (FRP)

Conal Elliott และคนอื่น ๆ ได้สร้างอุตสาหกรรมคอทเทจสักเล็กน้อยเพื่อพยายามหาสิ่งที่เป็นนามธรรมสำหรับ FRP มีการนำแนวคิด FRP ไปใช้งานหลายอย่างใน Haskell

คุณอาจพิจารณาเริ่มต้นด้วยล่าสุดโคแนล"Push-Pull หน้าที่ปฏิกิริยาการเขียนโปรแกรม"กระดาษ แต่มีหลายอื่น ๆ (เก่า) การใช้งานบางอย่างที่เชื่อมโยงจากเว็บไซต์ haskell.org Conal มีความสามารถพิเศษในการครอบคลุมทั้งโดเมนและสามารถอ่านกระดาษของเขาได้โดยไม่ต้องอ้างอิงถึงสิ่งที่เกิดขึ้นก่อนหน้านี้

เพื่อให้เข้าใจว่าวิธีนี้สามารถใช้สำหรับการพัฒนา GUI ได้อย่างไรคุณอาจต้องการดูFudgetsซึ่งในขณะที่มันเริ่มมีปัญหาอยู่บ้างในขณะนี้ซึ่งได้รับการออกแบบในช่วงกลางยุค 90 แสดงวิธี FRP ที่มั่นคง เพื่อการออกแบบ GUI

Windows Presentation Foundationเป็นข้อพิสูจน์ว่าวิธีการใช้งานนั้นทำงานได้ดีสำหรับการเขียนโปรแกรม GUI มันมีแง่มุมการใช้งานมากมายและรหัส WPF "ดี" (ค้นหารูปแบบ MVVM) เน้นวิธีการทำงานมากกว่าความจำเป็น ฉันกล้าอ้างว่า WPF เป็นชุดเครื่องมือ GUI ที่ใช้งานได้จริงที่สุดในโลก :-)

WPF อธิบายส่วนต่อประสานผู้ใช้ใน XAML (แม้ว่าคุณจะสามารถเขียนใหม่เพื่อให้มองหา C # หรือ F # ได้เช่นกัน) ดังนั้นเพื่อสร้างส่วนต่อประสานผู้ใช้ที่คุณจะเขียน:

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

นอกจากนี้ WPF ยังช่วยให้คุณสามารถอธิบายภาพเคลื่อนไหวและปฏิกิริยาต่อเหตุการณ์โดยใช้แท็กที่ประกาศอีกชุด (อีกครั้งสามารถเขียนสิ่งเดียวกันเป็นรหัส C # / F #):

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

ในความเป็นจริงฉันคิดว่า WPF มีหลายสิ่งร่วมกันกับ FRP ของ Haskell (แต่ฉันเชื่อว่านักออกแบบ WPF ไม่ทราบเกี่ยวกับ FRP และมันค่อนข้างโชคร้าย - WPF บางครั้งรู้สึกแปลกและไม่ชัดเจนถ้าคุณใช้ฟังก์ชัน มุมมอง).

ฉันจะบอกว่าการเขียนโปรแกรมฟังก์ชั่น (F #) เป็นเครื่องมือที่ดีกว่าสำหรับการเขียนโปรแกรมส่วนติดต่อผู้ใช้มากกว่าตัวอย่างเช่น C # คุณเพียงแค่ต้องคิดเกี่ยวกับปัญหาที่แตกต่างกันเล็กน้อย

ฉันพูดถึงหัวข้อนี้ในหนังสือการเขียนโปรแกรมเชิงฟังก์ชั่นของฉันในบทที่ 16 แต่มีข้อความที่ตัดตอนมาฟรีที่แสดง (IMHO) รูปแบบที่น่าสนใจที่สุดที่คุณสามารถใช้ใน F # สมมติว่าคุณต้องการใช้การวาดรูปสี่เหลี่ยม (ผู้ใช้กดปุ่มเลื่อนเมาส์และปล่อยปุ่ม) ใน F # คุณสามารถเขียนดังนี้:

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 }

นี่เป็นวิธีที่จำเป็นอย่างยิ่ง (ในรูปแบบปกติในทางปฏิบัติ F #) แต่ก็หลีกเลี่ยงการใช้สถานะที่ไม่แน่นอนในการจัดเก็บสถานะปัจจุบันของการวาดภาพและสำหรับการจัดเก็บตำแหน่ง inital มันสามารถทำงานได้มากขึ้นแม้ว่าฉันจะเขียนห้องสมุดที่เป็นส่วนหนึ่งของวิทยานิพนธ์ปริญญาโทของฉันซึ่งควรจะมีอยู่ในบล็อกของฉันในอีกไม่กี่วันถัดไป

ฟังก์ชั่นการตอบโต้การเขียนโปรแกรมเป็นวิธีการที่ใช้งานได้มากกว่า แต่ฉันคิดว่ามันค่อนข้างยากกว่าที่จะใช้เนื่องจากมันอาศัยคุณสมบัติของ Haskell ค่อนข้างสูง (เช่นลูกศร) อย่างไรก็ตามมันมีความสง่างามมากในหลายกรณี มีข้อ จำกัด คือคุณไม่สามารถเข้ารหัสเครื่องสถานะได้ง่าย (ซึ่งเป็นแบบจำลองทางจิตที่มีประโยชน์สำหรับโปรแกรมที่ทำปฏิกิริยา) สิ่งนี้ง่ายมากโดยใช้เทคนิค F # ด้านบน

ไม่ว่าคุณจะอยู่ในภาษา / OO ไฮบริดทำงานเช่น F # หรือ OCaml หรือในภาษาทำงานอย่างหมดจดเช่น Haskell ที่ผลข้างเคียงที่จะผลักไสให้ IO monad ก็ส่วนใหญ่เป็นกรณีที่ตันของการทำงานที่จำเป็นในการจัดการ GUI เป็นมากกว่า "ผลข้างเคียง" มากกว่าเช่นอัลกอริทึมการทำงานอย่างหมดจด

ที่กล่าวว่าได้มีการวิจัยบางใส่ของแข็งจริงๆเป็นGUIs ทำงาน มีแม้กระทั่งบางคน (ส่วนใหญ่) ชุดเครื่องมือการทำงานเช่นFudgetsหรือFranTk

คุณอาจดูซีรี่ส์โดย Don Syme บน F # ซึ่งเขาสาธิตกำลังสร้าง gui ลิงค์ต่อไปนี้เป็นส่วนที่สามของซีรี่ส์ (คุณสามารถลิงค์จากที่นั่นไปยังอีกสองส่วน)

การใช้ F # สำหรับการพัฒนา WPF จะเป็นกระบวนทัศน์ GUI ที่น่าสนใจมาก ...

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

หนึ่งในความคิดที่เปิดใจอยู่เบื้องหลังฟังก์ชั่นการเขียนโปรแกรมปฏิกิริยาคือการมีฟังก์ชั่นการจัดการเหตุการณ์ที่เกิดปฏิกิริยาทั้งต่อเหตุการณ์และฟังก์ชั่นการจัดการเหตุการณ์ต่อไป ดังนั้นระบบที่พัฒนาขึ้นจะถูกแสดงเป็นลำดับของฟังก์ชั่นการจัดการเหตุการณ์

สำหรับฉันแล้วการเรียนรู้ของ Yampa กลายเป็นสิ่งสำคัญในการทำให้ฟังก์ชั่นการผลิตฟังก์ชั่นถูกต้อง มีเอกสารดีๆเกี่ยวกับยัมปา ฉันแนะนำ The Yampa Arcade:

http://www.cs.nott.ac.uk/~nhn/Talks/HW2003-YampaArcade.pdf (สไลด์, PDF) http://www.cs.nott.ac.uk/~nhn/Publications/hw2003 pdf (บทความเต็มรูปแบบ PDF)

มีหน้า wiki บน Yampa ที่ Haskell.org

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

หน้าแรกของ Yampa ดั้งเดิม:

http://www.haskell.org/yampa (น่าเสียดายที่ถูกทำลายในขณะนี้)

ตั้งแต่คำถามนี้ถูกถามครั้งแรกการเขียนโปรแกรมเชิงโต้ตอบที่ใช้งานได้ถูกทำให้มีความสำคัญมากกว่าเดิมโดย Elm

ฉันขอแนะนำให้ตรวจสอบที่http://elm-lang.orgซึ่งมีบทเรียนแบบโต้ตอบที่ยอดเยี่ยมบางอย่างเกี่ยวกับวิธีสร้าง GUI ในเบราว์เซอร์ที่ทำงานได้อย่างสมบูรณ์

ช่วยให้คุณสร้าง GUI ที่ใช้งานได้อย่างสมบูรณ์โดยที่โค้ดที่คุณต้องการในการใช้งานประกอบด้วยฟังก์ชันบริสุทธิ์เท่านั้น โดยส่วนตัวแล้วฉันพบว่ามันง่ายกว่าที่จะเข้าไปในเฟรมเวิร์ค Haskell GUI ที่หลากหลาย

พูดคุยเกี่ยวกับเอลเลียตไฟเบอร์กลาสสามารถพบได้ที่นี่

นอกจากนี้ไม่ใช่คำตอบจริงๆ แต่เป็นคำพูดและความคิดบางอย่าง: คำใดคำหนึ่ง "functional GUI" ดูเหมือนเล็กน้อยเช่น oxymoron (ความบริสุทธิ์และ IO ในระยะเดียวกัน)

แต่ความเข้าใจที่คลุมเครือของฉันก็คือการเขียนโปรแกรมฟังก์ชั่น GUI นั้นเกี่ยวกับการกำหนดฟังก์ชั่นขึ้นอยู่กับเวลาที่ใช้อินพุตของผู้ใช้ขึ้นอยู่กับเวลา

ฟังก์ชันนี้ถูกนิยามเหมือนสมการเชิงอนุพันธ์ที่ประกาศอย่างชัดเจนแทนที่จะเป็นอัลกอริธึมที่จำเป็นต้องใช้สถานะที่ไม่แน่นอน

ดังนั้นใน FP แบบทั่วไปจะใช้ฟังก์ชั่นอิสระตามเวลาในขณะที่ FRP หนึ่งจะใช้ฟังก์ชั่นที่ขึ้นกับเวลาเป็นหน่วยการสร้างสำหรับการอธิบายโปรแกรม

ให้เราคิดเกี่ยวกับการจำลองลูกบอลในฤดูใบไม้ผลิที่ผู้ใช้สามารถโต้ตอบ ตำแหน่งของลูกเป็นเอาท์พุทแบบกราฟิก (บนหน้าจอ) ผู้ใช้ดันลูกบอลเป็นปุ่มกด (อินพุต)

การอธิบายโปรแกรมการจำลองนี้ใน FRP (ตามความเข้าใจของฉัน) ทำโดยสมการเชิงอนุพันธ์เดียว (อย่างชัดเจน): การเร่งความเร็ว * มวล = - การยืดของสปริง * ค่าคงที่ของฤดูใบไม้ผลิ * ค่าคงที่ของสปริง + แรงที่กระทำโดยผู้ใช้

นี่คือวิดีโอเกี่ยวกับELMที่แสดงมุมมองนี้

ในปี 2559 มีกรอบ FRP ที่ค่อนข้างเป็นผู้ใหญ่มากกว่าสำหรับ Haskell เช่น Sodium และ Reflex (แต่ยังเป็น Netwire)

หนังสือนิงในฟังก์ชั่นการเขียนโปรแกรมปฏิกิริยาโชว์ผลงานรุ่น Java ของโซเดียมสำหรับตัวอย่างการใช้งานและแสดงให้เห็นถึงวิธีการที่จะทำงาน FRP GUI ฐานรหัสและเครื่องชั่งน้ำหนักในการเปรียบเทียบกับความจำเป็นเช่นเดียวกับนักแสดงวิธีการตาม

นอกจากนี้ยังมีรายงานล่าสุดเกี่ยวกับ Arrowized FRP และโอกาสของการรวมผลข้างเคียง, IO และการกลายพันธุ์ในการปฏิบัติตามกฎหมายการตั้งค่า FRP บริสุทธิ์: http://haskell.cs.yale.edu/wp-content/uploads/2015/10/ DWC-เยลรูปแบบ-dissertation.pdf

นอกจากนี้ที่น่าสังเกตก็คือเฟรมเวิร์ก JavaScript เช่น ReactJS และ Angular และอื่น ๆ อีกมากมายไม่ว่าจะเป็นหรือกำลังเคลื่อนไปสู่การใช้ FRP หรือวิธีการทำงานอื่น ๆ เพื่อบรรลุองค์ประกอบ GUI ที่ปรับขนาดได้และเรียงความได้

ภาษามาร์กอัปเช่น XUL ช่วยให้คุณสร้าง GUI ในลักษณะที่เปิดเผยได้

เพื่อที่อยู่นี้ฉันโพสต์ความคิดของฉันในการใช้ 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 /

ฉันยังวางแผนที่จะทำวิดีโอสอนเพื่อจบซีรีส์และแสดงให้เห็นว่า F # สามารถมีส่วนร่วมในการเขียนโปรแกรม UX ได้อย่างไร

ฉันแค่พูดในบริบทของ F # ที่นี่

-Fahad

คำตอบอื่น ๆ ทั้งหมดนี้สร้างขึ้นจากการเขียนโปรแกรมที่ใช้งานได้ แต่ต้องตัดสินใจออกแบบของตัวเองเป็นจำนวนมาก glossห้องสมุดหนึ่งที่ถูกสร้างขึ้นโดยทั่วไปทั้งหมดออกจากฟังก์ชั่นที่ง่ายและชนิดข้อมูลนามธรรม นี่คือประเภทของplayฟังก์ชันจากแหล่งที่มา

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

อย่างที่คุณเห็นมันทำงานได้อย่างสมบูรณ์โดยการจัดหาฟังก์ชั่นที่บริสุทธิ์ด้วยประเภทนามธรรมอย่างง่ายที่ห้องสมุดอื่น ๆ จะช่วยเหลือคุณ

นวัตกรรมที่ชัดเจนที่สุดที่สังเกตเห็นโดยผู้ที่เพิ่งเริ่มใช้ Haskell คือมีการแยกระหว่างโลกที่ไม่บริสุทธิ์ซึ่งเกี่ยวข้องกับการสื่อสารกับโลกภายนอกและโลกที่บริสุทธิ์ของการคำนวณและอัลกอริธึม คำถามเริ่มต้นที่พบบ่อยคือ "ฉันจะกำจัดIOเช่นเปลี่ยนIO aเป็นaอย่างไร" วิธีที่จะใช้มันคือการใช้ monads (หรือ abstractions อื่น ๆ ) เพื่อเขียนโค้ดที่ใช้ผลของ IO และเชน รหัสนี้รวบรวมข้อมูลจากโลกภายนอกสร้างแบบจำลองของมันทำการคำนวณบางอย่างซึ่งอาจเกิดจากการใช้รหัสที่บริสุทธิ์และส่งผลลัพธ์ออกมา

เท่าที่โมเดลด้านบนเป็นห่วงฉันไม่เห็นอะไรผิดปกติอย่างใหญ่หลวงกับการจัดการ GUIs ในIOmonad ปัญหาที่ใหญ่ที่สุดที่เกิดจากรูปแบบนี้ก็คือโมดูลจะไม่สามารถเรียบเรียงได้อีกต่อไปนั่นคือฉันสูญเสียความรู้ส่วนใหญ่เกี่ยวกับลำดับการดำเนินการทั่วโลกของงบในโปรแกรมของฉัน ในการกู้คืนฉันต้องใช้เหตุผลที่คล้ายกันเช่นเดียวกับในโค้ด GUI ที่จำเป็นพร้อมกัน ในขณะเดียวกันสำหรับรหัสที่ไม่เป็น GUI นั้นไม่บริสุทธิ์ลำดับการดำเนินการจะชัดเจนเนื่องจากคำจำกัดความของโอเปอเรเตอร์IOของ monad >==(อย่างน้อยตราบใดที่มีเพียงเธรดเดียวเท่านั้น) ⊥สำหรับรหัสบริสุทธิ์มันไม่สำคัญที่ทุกคนยกเว้นในกรณีที่มุมเพื่อเพิ่มประสิทธิภาพการทำงานหรือเพื่อหลีกเลี่ยงการประเมินผลใน

ความแตกต่างทางปรัชญาที่ใหญ่ที่สุดระหว่างคอนโซลและกราฟิก IO คือโปรแกรมที่ใช้งานในอดีตมักจะเขียนในลักษณะซิงโครนัส นี้เป็นไปได้เพราะมี (ออกจากกันสัญญาณและอื่น ๆ ที่อธิบายไฟล์เปิด) เพียงหนึ่งในแหล่งที่มาของเหตุการณ์: กระแส byte stdinที่เรียกกันทั่วไป GUIs นั้นทำงานแบบอะซิงโครนัสและต้องตอบสนองต่อเหตุการณ์แป้นพิมพ์และการคลิกเมาส์

ปรัชญาที่ได้รับความนิยมในการทำแบบอะซิงโครนัส IO ในลักษณะการทำงานเรียกว่า Functional Reactive Programming (FRP) มันมีแรงฉุดมากในภาษาที่ไม่บริสุทธิ์และไม่สามารถใช้งานได้ต้องขอบคุณห้องสมุดเช่นReactiveXและเฟรมเวิร์กเช่น Elm โดยสรุปก็เหมือนกับการดูองค์ประกอบ GUI และสิ่งอื่น ๆ (เช่นไฟล์นาฬิกาสัญญาณเตือนแป้นพิมพ์เมาส์) เป็นแหล่งของเหตุการณ์เรียกว่า "observables" ซึ่งปล่อยกระแสของเหตุการณ์ เหตุการณ์เหล่านี้จะรวมกันโดยใช้ผู้ประกอบการที่คุ้นเคยเช่นmap, foldl, zip, filter, concat, joinฯลฯ ในการผลิตกระแสใหม่ สิ่งนี้มีประโยชน์เนื่องจากสถานะโปรแกรมสามารถถูกมองว่าเป็นscanl . map reactToEvents $ zipN <eventStreams>ของโปรแกรมซึ่งNเท่ากับจำนวนของสิ่งที่สังเกตได้ที่เคยพิจารณาโดยโปรแกรม

การทำงานกับสิ่งที่สังเกตเห็นได้ของ FRP ทำให้สามารถกู้คืนความสามารถในการจัดองค์ประกอบได้เนื่องจากมีการสั่งซื้อเหตุการณ์ในสตรีมในเวลา เหตุผลก็คือนามธรรมของเหตุการณ์ทำให้มันเป็นไปได้ที่จะดูสิ่งที่สังเกตได้ทั้งหมดเป็นกล่องดำ ในที่สุดการรวมสตรีมเหตุการณ์โดยใช้โอเปอเรเตอร์จะช่วยให้มีการสั่งซื้อในพื้นที่สำหรับการดำเนินการ สิ่งนี้ทำให้ฉันมีความซื่อสัตย์มากขึ้นเกี่ยวกับโปรแกรมที่ไม่เปลี่ยนแปลงของฉันอาศัยอยู่คล้ายกับวิธีที่ฟังก์ชั่นทั้งหมดใน Haskell ต้องมีความโปร่งใสอ้างอิง: ถ้าฉันต้องการดึงข้อมูลจากส่วนอื่นของโปรแกรมของฉันฉันต้องชัดเจน โฆษณาประกาศประเภทที่เหมาะสมสำหรับฟังก์ชั่นของฉัน (IO monad ซึ่งเป็นภาษาเฉพาะโดเมนสำหรับการเขียนโค้ดที่ไม่บริสุทธิ์และหลีกเลี่ยงปัญหานี้ได้อย่างมีประสิทธิภาพ)

การเขียนโปรแกรมเชิงฟังก์ชั่นอาจจะย้ายจากเมื่อฉันอยู่ที่มหาวิทยาลัย แต่ในขณะที่ฉันจำจุดหลักของระบบการเขียนโปรแกรมการทำงานคือการหยุดโปรแกรมเมอร์ที่สร้าง "ผลข้างเคียง" ใด ๆ อย่างไรก็ตามผู้ใช้ซื้อซอฟต์แวร์เนื่องจากผลข้างเคียงที่สร้างขึ้นเช่นการอัปเดต UI