สถานะของการใช้งาน Functional Reactive Programming ในปัจจุบันเป็นอย่างไร

ฉันพยายามนึกภาพระบบทางกายภาพอัตโนมัติง่ายๆ (เช่นลูกตุ้มแขนหุ่นยนต์ ฯลฯ ) ใน Haskell บ่อยครั้งที่ระบบเหล่านั้นสามารถอธิบายได้ด้วยสมการเช่น

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

ที่u(t)แสดงถึง 'การควบคุมอัจฉริยะ' บางประเภท ระบบเหล่านี้ดูเหมือนจะเข้ากันได้ดีในกระบวนทัศน์การเขียนโปรแกรมปฏิกิริยาเชิงฟังก์ชัน

ดังนั้นผมจึงคว้าหนังสือ "Haskell ของโรงเรียนในการแสดงออก" โดยพอลฮูดักและพบว่าเฉพาะโดเมนภาษา "FAL" (สำหรับฟังก์ชั่นนิเมชั่น Language) ที่นำเสนอมีการใช้งานได้จริงค่อนข้าง pleasently สำหรับระบบของเล่นที่เรียบง่ายของฉัน (แม้ว่าการทำงานบางอย่างสะดุดตาintegrate, ดูเหมือนจะขี้เกียจไปหน่อยสำหรับการใช้งานที่มีประสิทธิภาพ แต่แก้ไขได้ง่าย)

คำถามของฉันคืออะไรที่เป็นทางเลือกสำหรับผู้ใหญ่ที่ทันสมัยได้รับการดูแลเป็นอย่างดีได้รับการปรับแต่งประสิทธิภาพสำหรับแอปพลิเคชันขั้นสูงหรือแม้แต่ในทางปฏิบัติในปัจจุบัน

หน้าวิกินี้แสดงตัวเลือกต่างๆสำหรับ Haskell แต่ฉันไม่ชัดเจนเกี่ยวกับประเด็นต่อไปนี้:

1. สถานะของ "ปฏิกิริยา" โครงการจาก Conal Eliott ซึ่งเป็น (ตามที่ฉันเข้าใจ) หนึ่งในผู้คิดค้นกระบวนทัศน์การเขียนโปรแกรมนี้ดูไม่ค่อยดี ฉันชอบรหัสของเขา แต่ฉันควรลองทางเลือกอื่นที่ทันสมัยกว่านี้ไหม อะไรคือความแตกต่างหลักระหว่างพวกเขาในแง่ของไวยากรณ์ / ประสิทธิภาพ / ความเสถียรของรันไทม์

2. หากต้องการอ้างอิงจากการสำรวจในปี 2554 ตอนที่ 6 " ... การใช้งาน FRP ยังไม่มีประสิทธิภาพเพียงพอหรือสามารถคาดเดาได้ในประสิทธิภาพเพียงพอที่จะใช้อย่างมีประสิทธิภาพในโดเมนที่ต้องมีการรับประกันเวลาแฝง ... " แม้ว่าการสำรวจจะแนะนำการเพิ่มประสิทธิภาพที่น่าสนใจ แต่เนื่องจาก FRP อยู่ที่นั่นมานานกว่า 15 ปีแล้วฉันรู้สึกว่าปัญหาด้านประสิทธิภาพนี้อาจเป็นสิ่งที่ยากมากหรือแม้กระทั่งโดยเนื้อแท้ที่จะแก้ไขได้อย่างน้อยภายในไม่กี่ปี นี่คือเรื่องจริง?

3. นักเขียนคนเดียวกันของการสำรวจพูดคุยเกี่ยวกับเวลา "รั่วไหล" ของเขาในบล็อก ปัญหาเฉพาะของ FRP หรือสิ่งที่เราพบโดยทั่วไปเมื่อเขียนโปรแกรมด้วยภาษาที่บริสุทธิ์และไม่เข้มงวด? คุณเคยพบว่ามันยากเกินไปไหมที่จะทำให้ระบบที่ใช้ FRP เสถียรเมื่อเวลาผ่านไปถ้ามีประสิทธิภาพไม่เพียงพอ?

4. นี่ยังเป็นโครงการระดับการวิจัยอยู่หรือไม่? ผู้คนเช่นวิศวกรโรงงานวิศวกรหุ่นยนต์วิศวกรการเงิน ฯลฯ ใช้สิ่งเหล่านี้จริงหรือไม่ (ในภาษาใดก็ตามที่เหมาะกับความต้องการของพวกเขา)

แม้ว่าโดยส่วนตัวแล้วฉันชอบการใช้งาน Haskell แต่ฉันก็เปิดรับข้อเสนอแนะอื่น ๆ ตัวอย่างเช่นการใช้งาน Erlang จะเป็นเรื่องสนุกเป็นพิเศษ - จากนั้นก็จะมีกระบวนการเซิร์ฟเวอร์ที่ชาญฉลาดปรับตัวได้และเรียนรู้ด้วยตนเอง!

ตอนนี้มีไลบรารี Haskell ที่ใช้งานได้จริงสองไลบรารีสำหรับการเขียนโปรแกรมปฏิกิริยาเชิงฟังก์ชัน ทั้งสองได้รับการดูแลโดยบุคคลเดียว แต่ได้รับการสนับสนุนโค้ดจากโปรแกรมเมอร์ Haskell คนอื่น ๆ เช่นกัน:

• Netwireมุ่งเน้นไปที่ประสิทธิภาพความยืดหยุ่นและความสามารถในการคาดการณ์ มันมีกระบวนทัศน์เหตุการณ์ของตัวเองและสามารถใช้ในพื้นที่ที่ FRP แบบดั้งเดิมไม่ทำงานรวมถึงบริการเครือข่ายและการจำลองที่ซับซ้อน สไตล์: ประยุกต์และ / หรือลูกศร ผู้เขียนและผู้ดูแลเริ่มต้น: Ertugrul Söylemez (นี่คือฉัน)

• ปฏิกิริยากล้วยสร้างขึ้นจากกระบวนทัศน์ FRP แบบดั้งเดิม แม้ว่าจะใช้งานได้จริง แต่ก็ยังใช้เป็นพื้นฐานสำหรับการวิจัย FRP แบบคลาสสิก โฟกัสหลักอยู่ที่อินเทอร์เฟซผู้ใช้และมีอินเทอร์เฟซสำเร็จรูปสำหรับ wx สไตล์: ประยุกต์ ผู้เขียนและผู้ดูแลเริ่มต้น: Heinrich Apfelmus

คุณควรลองทั้งสองอย่าง แต่ขึ้นอยู่กับแอปพลิเคชันของคุณคุณน่าจะพบว่าอย่างใดอย่างหนึ่งเหมาะสมกว่า

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

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

เพื่อตอบคำถามอื่น ๆ ของคุณ: FRP ไม่เหมาะในสถานการณ์ที่คุณต้องการการคาดการณ์แบบเรียลไทม์ ส่วนใหญ่เกิดจาก Haskell แต่น่าเสียดายที่ FRP ยากที่จะเข้าใจในภาษาระดับล่าง ทันทีที่ Haskell พร้อมแบบเรียลไทม์ FRP ก็จะไปถึงที่นั่นเช่นกัน Netwire ตามแนวคิดพร้อมสำหรับการใช้งานแบบเรียลไทม์

การรั่วไหลของเวลาไม่ได้เป็นปัญหาอีกต่อไปเพราะส่วนใหญ่เกี่ยวข้องกับกรอบรูปแบบ monadic การใช้งาน FRP ในทางปฏิบัติไม่ได้นำเสนออินเทอร์เฟซแบบ monadic แยมปาได้เริ่มต้นสิ่งนี้และ Netwire และ reactive-banana ก็สร้างสิ่งนั้นขึ้นมา

ฉันไม่ทราบว่าไม่มีโครงการเชิงพาณิชย์หรือโครงการขนาดใหญ่ที่ใช้ FRP ในขณะนี้ ห้องสมุดพร้อมแล้ว แต่ฉันคิดว่าคนยังไม่ -

แม้ว่าจะมีคำตอบที่ดีอยู่แล้ว แต่ฉันจะพยายามตอบคำถามเฉพาะของคุณ

1. ปฏิกิริยาไม่สามารถใช้งานได้สำหรับโครงการที่ร้ายแรงเนื่องจากปัญหาการรั่วไหลของเวลา (ดู # 3) ห้องสมุดปัจจุบันที่มีการออกแบบที่คล้ายคลึงกันมากที่สุดคือ Reactive-banana ซึ่งได้รับการพัฒนาโดยมีปฏิกิริยาเป็นแรงบันดาลใจและอยู่ระหว่างการหารือกับ Conal Elliott

2. แม้ว่า Haskell เองจะไม่เหมาะสมสำหรับการใช้งานแบบเรียลไทม์อย่างหนัก แต่ก็เป็นไปได้ที่จะใช้ Haskell สำหรับแอปพลิเคชันแบบเรียลไทม์ที่นุ่มนวลในบางกรณี ฉันไม่คุ้นเคยกับการวิจัยในปัจจุบัน แต่ฉันไม่เชื่อว่านี่เป็นปัญหาที่ผ่านไม่ได้ ฉันสงสัยว่าทั้งระบบเช่น Yampa หรือระบบสร้างรหัสเช่น Atom อาจเป็นแนวทางที่ดีที่สุดในการแก้ปัญหานี้

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

ไลบรารี frp ที่ไม่สามารถสลับได้เช่น Yampa และ Reactive-banana เวอร์ชันเก่าจะไม่ประสบปัญหาการรั่วไหลของเวลา โดยทั่วไปแล้วไลบรารี frp ที่สลับได้จะใช้หนึ่งในสองรูปแบบ: มี "การสร้าง monad" แบบพิเศษซึ่งสร้างค่า FRP หรือใช้พารามิเตอร์ประเภท "อายุ" เพื่อ จำกัด บริบทที่สวิตช์สามารถเกิดขึ้นได้ elerea (และอาจเป็น netwire?) ใช้แบบเดิมในขณะที่กล้วยรีแอคทีฟล่าสุดและเกรปฟรุตใช้แบบหลัง

โดย "switchable frp" ฉันหมายถึงสิ่งที่ใช้ฟังก์ชันของ Conal switcher :: Behavior a -> Event (Behavior a) -> Behavior aหรือความหมายที่เหมือนกัน ซึ่งหมายความว่ารูปร่างของเครือข่ายสามารถสลับแบบไดนามิกได้เมื่อทำงาน

สิ่งนี้ไม่ได้ขัดแย้งกับคำสั่งของ @ ertes เกี่ยวกับอินเทอร์เฟซแบบ monadic: ปรากฎว่าการจัดเตรียมMonadอินสแตนซ์สำหรับการEventรั่วไหลของเวลาที่เป็นไปได้และด้วยวิธีการใดวิธีการหนึ่งข้างต้นทำให้ไม่สามารถกำหนดอินสแตนซ์ Monad ที่เทียบเท่าได้

ในที่สุดแม้ว่าจะยังมีงานอีกมากที่ต้องทำกับ FRP แต่ฉันคิดว่าแพลตฟอร์มใหม่ ๆ (reactive-banana, elerea, netwire) มีความเสถียรและเป็นผู้ใหญ่เพียงพอที่คุณจะสามารถสร้างโค้ดที่เชื่อถือได้จากพวกเขา แต่คุณอาจต้องใช้เวลามากในการเรียนรู้ข้อมูลเชิงลึกเพื่อที่จะเข้าใจวิธีการได้รับประสิทธิภาพที่ดี

ฉันจะแสดงรายการสองสามรายการในสเปซ Mono และ. Net และอีกหนึ่งรายการจากสเปซ Haskell ที่ฉันพบเมื่อไม่นานมานี้ ฉันจะเริ่มด้วย Haskell

Elm - ลิงค์

คำอธิบายตามไซต์:

Elm มุ่งหวังที่จะทำให้การพัฒนาเว็บส่วนหน้าน่าพอใจยิ่งขึ้น แนะนำแนวทางใหม่ในการเขียนโปรแกรม GUI ที่แก้ไขปัญหาระบบของ HTML, CSS และ JavaScript Elm ช่วยให้คุณทำงานกับเค้าโครงภาพได้อย่างรวดเร็วและง่ายดายใช้ผืนผ้าใบจัดการการป้อนข้อมูลของผู้ใช้ที่ซับซ้อนและหลีกหนีจากนรกแห่งการเรียกกลับ

มีFRP ที่แตกต่างกันไป จากการเล่นตามตัวอย่างมันดูเป็นผู้ใหญ่ทีเดียว

Reactive Extensions - ลิงค์

คำอธิบายจากหน้าแรก:

Reactive Extensions (Rx) คือไลบรารีสำหรับการเขียนโปรแกรมแบบอะซิงโครนัสและตามเหตุการณ์โดยใช้ลำดับที่สังเกตได้และตัวดำเนินการแบบสอบถามสไตล์ LINQ การใช้ Rx นักพัฒนาจะแสดงสตรีมข้อมูลแบบอะซิงโครนัสด้วย Observables แบบสอบถามสตรีมข้อมูลแบบอะซิงโครนัสโดยใช้ตัวดำเนินการ LINQ และกำหนดพารามิเตอร์การทำงานพร้อมกันในสตรีมข้อมูลแบบอะซิงโครนัสโดยใช้ตัวกำหนดเวลา พูดง่ายๆคือ Rx = Observables + LINQ + Schedulers

Reactive Extensions มาจาก MSFT และใช้ตัวดำเนินการที่ยอดเยี่ยมมากมายที่ทำให้เหตุการณ์การจัดการง่ายขึ้น มันก็เปิดมาเพียงไม่กี่วันที่ผ่านมา เป็นผู้ใหญ่มากและใช้ในการผลิต ในความคิดของฉันมันน่าจะเป็น API ที่ดีกว่าสำหรับ Windows 8 APIs มากกว่าที่ TPL-library มีให้ เนื่องจากสิ่งที่สังเกตได้อาจเป็นได้ทั้งแบบร้อนและเย็นและลองใหม่ / รวม ฯลฯ ในขณะที่งานมักแสดงถึงการคำนวณที่ร้อนหรือเสร็จสิ้นซึ่งกำลังทำงานผิดพลาดหรือเสร็จสิ้น

ฉันได้เขียนโค้ดฝั่งเซิร์ฟเวอร์โดยใช้ Rx สำหรับ asynchronocity แต่ฉันต้องยอมรับว่าการเขียนตามฟังก์ชันใน C # นั้นค่อนข้างน่ารำคาญ F # มี Wrapper สองสามตัว แต่มันยากที่จะติดตามการพัฒนา API เนื่องจากกลุ่มนี้ค่อนข้างปิดและไม่ได้รับการส่งเสริมโดย MSFT เหมือนโครงการอื่น ๆ

การจัดหาแบบเปิดมาพร้อมกับการจัดหาแบบเปิดของคอมไพเลอร์ IL-to-JS ดังนั้นจึงอาจทำงานได้ดีกับ JavaScript หรือ Elm

คุณอาจผูก F # / C # / JS / Haskell เข้าด้วยกันได้ดีมากโดยใช้นายหน้าส่งข้อความเช่น RabbitMQ และ SocksJS

Bling UI Toolkit - ลิงค์

คำอธิบายจากหน้าแรก:

Bling เป็นไลบรารีที่ใช้ C # สำหรับการเขียนโปรแกรมรูปภาพภาพเคลื่อนไหวการโต้ตอบและการแสดงภาพบน WPF / .NET ของ Microsoft ได้อย่างง่ายดาย Bling มุ่งเน้นไปที่นักเทคโนโลยีการออกแบบเช่นนักออกแบบที่บางครั้งตั้งโปรแกรมเพื่อช่วยในการสร้างต้นแบบอย่างรวดเร็วของแนวคิดการออกแบบ UI ที่หลากหลาย นักเรียนศิลปินนักวิจัยและมือสมัครเล่นจะพบว่า Bling มีประโยชน์ในฐานะเครื่องมือสำหรับการแสดงความคิดหรือการแสดงภาพอย่างรวดเร็ว API และโครงสร้างของ Bling ได้รับการปรับให้เหมาะสมสำหรับการเขียนโปรแกรมโค้ดแบบโยนทิ้งอย่างรวดเร็วซึ่งต่างจากการเขียนโปรแกรมรหัสการผลิตอย่างระมัดระวัง

ฟรีLTU บทความ

ฉันได้ทดสอบแล้ว แต่ใช้ไม่ได้กับโครงการไคลเอ็นต์ มันดูดีมากมีตัวดำเนินการ C # ที่ดีมากเกินไปซึ่งก่อให้เกิดการเชื่อมโยงระหว่างค่าต่างๆ ใช้คุณสมบัติการพึ่งพาใน WPF / SL / (WinRT) เป็นแหล่งเหตุการณ์ ภาพเคลื่อนไหว 3 มิติทำงานได้ดีบนฮาร์ดแวร์ที่เหมาะสม ฉันจะใช้สิ่งนี้หากฉันจบลงในโครงการที่ต้องการการสร้างภาพ อาจจะย้ายไปที่ Windows 8

ReactiveUI - ลิงค์

Paul Betts ก่อนหน้านี้ที่ MSFT ตอนนี้ที่ Github เขียนกรอบนั้น ฉันเคยทำงานกับมันมาแล้วและชอบโมเดล มันแยกออกจากกันได้ดีกว่า Blink (โดยธรรมชาติจากการใช้ Rx และ abstractions) ทำให้ง่ายต่อการใช้รหัสทดสอบหน่วย github git client สำหรับ Windows เขียนไว้ในนี้

ความคิดเห็น

แบบจำลองปฏิกิริยามีประสิทธิภาพเพียงพอสำหรับแอปพลิเคชันที่ต้องการประสิทธิภาพส่วนใหญ่ หากคุณกำลังคิดว่าจะยากแบบเรียลไทม์ฉันขอเดิมพันว่าภาษา GC ส่วนใหญ่มีปัญหา Rx, ReactiveUI สร้างออบเจ็กต์ขนาดเล็กจำนวนหนึ่งที่จำเป็นต้องเป็น GCed เนื่องจากเป็นวิธีการสร้าง / กำจัดการสมัครสมาชิกและค่ากลางจะดำเนินไปใน "monad" ของการเรียกกลับ โดยทั่วไปใน. Net ฉันชอบการเขียนโปรแกรมแบบรีแอคทีฟมากกว่าการเขียนโปรแกรมตามงานเพราะการเรียกกลับเป็นแบบคงที่ (รู้จักในเวลาคอมไพล์ไม่มีการจัดสรร) ในขณะที่งานจะถูกจัดสรรแบบไดนามิก (ไม่ทราบการเรียกทั้งหมดต้องมีอินสแตนซ์ขยะที่สร้างขึ้น) - และแลมบ์ดาสคอมไพล์ คลาสที่สร้างโดยคอมไพเลอร์

เห็นได้ชัดว่า C # และ F # ได้รับการประเมินอย่างเคร่งครัดดังนั้นการรั่วไหลของเวลาจึงไม่ใช่ปัญหา เหมือนกันสำหรับ JS อาจเป็นปัญหากับการสังเกตซ้ำหรือแคชได้