ฟังก์ชั่นการตอบสนองการเขียนโปรแกรมและรูปแบบของนักแสดงสัมพันธ์กันอย่างไร

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

ดังนั้นบนพื้นผิวที่พวกเขาดูเหมือนเกี่ยวข้อง

มีอะไรอีกบ้างที่เราสามารถพูดเกี่ยวกับความสัมพันธ์ของพวกเขา? นอกจากนี้สิ่งที่สามารถพูดเกี่ยวกับสิ่งที่พวกเขาอาจจะเหมาะสมกว่าสำหรับโดเมนแอปพลิเคชันที่แตกต่างกัน?

distributed-systems functional-programming programming-paradigms

— โรบินกรีน
แหล่งที่มา

นักแสดงและ FRP ไม่เกี่ยวกับการสตรีม นักแสดงไม่สนับสนุนการกำหนดค่าภายนอกของสตรีมเอาต์พุต

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

หากคุณกำลังมองหาความคล้ายคลึงกันทั้งนักแสดงและ FRP มีความสัมพันธ์ใกล้ชิดกับแลมบ์ดาแคลคูลัส ทั้งสองสามารถจำลองระบบตอบสนองต่ออินพุตของมนุษย์ สนับสนุนการสร้างแบบจำลองของรัฐภายใน (ท้องถิ่น)

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

เกี่ยวกับโดเมนแอปพลิเคชัน:

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

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

มีโมเดลอื่น ๆ ที่วางอยู่ระหว่าง FRP และนักแสดง

Flow Based Programming (FBP) พัฒนาโดย John Paul Morrison สนับสนุนการสตรีมข้อความจริงๆ

โปรโตคอล Time Warp (หรืองานล่าสุดเกี่ยวกับ Lightweight Time Warp (LTW)) วางข้อความที่เหมือนนักแสดงบนไทม์ไลน์แบบลอจิคัลเพื่อให้ความคิดที่มีการควบคุมและการเรียงองค์ประกอบของข้อความผ่านมากขึ้น การแปรปรวนของเวลามักถูกใช้สำหรับระบบขนานและการกระจายขนาดใหญ่เช่นการคำนวณทางวิทยาศาสตร์ วาร์ปเวลาดั้งเดิมไม่เหมาะสำหรับ simulatons แบบโต้ตอบ (การตอบสนองต่ออินพุตของมนุษย์) และ LTW นั้นเหมาะสมอย่างยิ่งเพียงเล็กน้อย

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

— dmbarbour
แหล่งที่มา

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

— Robin Green

@RobinGreen ความสามารถในการสร้างแบบจำลองความก้าวหน้าหรือการเปลี่ยนแปลงของเหตุการณ์นั้นมีประโยชน์มากทีเดียว นักพัฒนามีอิสระที่จะชดเชยด้วยการสร้างแบบจำลองการหน่วงเวลาทั้งอัพสตรีมหรือดาวน์สตรีม ด้วยประเภทที่ขึ้นกับหรือเชิงเส้นเราสามารถพัฒนาแนวคิดเรื่องความปลอดภัยเวลา (คุณสมบัติแบบเรียลไทม์การจัดสรรเวลาแฝงเป็นทรัพยากร) สำหรับระบบ FRP ที่ยากต่อการจำลองในระบบ atemporal

— dmbarbour

@ RobinGreen - เกี่ยวกับ "นิยายที่เหตุการณ์ B สามารถเกิดขึ้นได้หลังจากเหตุการณ์ A แต่ในเวลาเดียวกันบันทึก" ความคิดของเหตุการณ์ที่เกิดขึ้นในเวลาทันทีหรือยอดเยี่ยม (Lim (x-> 0 +) (T + x) คือ หนึ่งในข้อผิดพลาดสากลของนามธรรม 'เหตุการณ์' การเรียงลำดับของเหตุการณ์เมื่อทำซ้ำแยกและรวมกระแสข้อมูลเหตุการณ์กลายเป็นข้อมูลโดยพลการไม่สอดคล้องกันและสูญหายไปอย่างง่ายดาย (เทียบกับWhy Not Events )

— dmbarbour

คุณปรับเปลี่ยนโครงการ RDP ของคุณเป็นโครงการ Awelon หรือไม่

— CMCDragonkai

โครงการ Awelon จะใช้โมเดล / กระบวนทัศน์ RDP อย่างหนัก นึกถึง RDP ในลักษณะที่คล้ายกับ OOP รูปแบบการเขียนโปรแกรมมีผลกระทบต่อสถาปัตยกรรมและการออกแบบภาษา แต่ไม่ใช่สิ่งที่ฉันเรียกว่า 'โครงการ'

— dmbarbour

ฉันต้องการชี้ให้เห็นว่าพวกเขาแตกต่างจากมุมมองที่ใช้งานจริงได้อย่างไร:

1) นักแสดงส่งข้อความไปยังนักแสดงอื่น ๆ ผ่านข้อความนี้มีการอธิบายไว้อย่างชัดเจนและimperatively

ตัวอย่างเช่น:

send msg to Actor137.

2) ในการไหลของข้อมูล FRP อธิบายdeclaratively :

ตัวอย่างเช่น:

Cell134=Cell185+Cell42.

การส่งผ่านข้อความได้รับการจัดการโดยกรอบ FRP และคุณไม่จำเป็นต้องอธิบาย "ด้วยตนเอง" วิธีส่งข้อความจากเซลล์หนึ่ง (คล้ายกับ Actor, encapsulate state, aka Behaviour) ไปยังที่อื่น

ในคำอื่น ๆ :

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

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

เมื่อเร็ว ๆ นี้ฉันสังเกตเห็นว่ามีไฮบริดที่น่าสนใจระหว่างสองกระแส: Akka ซึ่งเป็นที่ที่มีการอธิบาย dataflow อย่างชัดเจน

แตกต่างก็คือ: นักแสดงมีแนวโน้มที่จะ async ขณะไฟเบอร์กลาสมีแนวโน้มที่จะซิงโคร (มักglitchฟรี)

— jhegedus
แหล่งที่มา