FRP là về truyền phát các sự kiện và hành vi thông qua các chức năng thuần túy. Mô hình Actor - ít nhất, như được triển khai trong Akka - là về việc truyền các thông điệp bất biến (có thể được coi là các sự kiện rời rạc) thông qua các đối tượng không tinh khiết, được gọi là các tác nhân.
Vì vậy, trên bề mặt họ có vẻ liên quan.
Chúng ta có thể nói gì khác về cách chúng liên quan? Ngoài ra, những gì có thể nói về cái nào trong số chúng có thể phù hợp hơn cho các miền ứng dụng khác nhau?
Câu trả lời:
Cả diễn viên và FRP đều không phát trực tuyến. Các diễn viên thậm chí không hỗ trợ cấu hình bên ngoài của luồng đầu ra.
FRP được đặc trưng mạnh mẽ bởi các tín hiệu và sự kiện mô hình hóa trên dòng thời gian tuyến tính, cho phép các hành vi FRP sáng tác theo cách xác định. Các diễn viên được đặc trưng mạnh mẽ bằng cách xử lý các thông điệp theo thứ tự không xác định và hầu như không có thuộc tính cấu thành nào (nghĩa là bạn không thể coi sự sắp xếp của hai diễn viên là một diễn viên lớn hơn).
Nếu bạn đang tìm kiếm sự tương đồng, cả diễn viên và FRP đều có mối quan hệ mật thiết với phép tính lambda. Cả hai có thể mô hình hệ thống đáp ứng đầu vào của con người. Cả hai đều hỗ trợ mô hình hóa trạng thái nội bộ (cục bộ).
FRP hỗ trợ trạng thái cục bộ thông qua tích phân hoặc tích lũy (gấp theo thời gian), trong khi mô hình diễn viên hỗ trợ trạng thái bằng cách cho phép mỗi tác nhân chỉ định hành vi của mình cho thông báo tiếp theo để phản hồi lại thông báo hiện tại. Sự hỗ trợ phổ biến này cho trạng thái cục bộ làm cho cả FRP và Actor không đủ để lập trình trực tiếp (hoặc nâng cấp thời gian chạy mã chương trình); nó trở nên quá dễ dàng để mất trạng thái quan trọng.
Về lĩnh vực ứng dụng:
Mô hình diễn viên rất phù hợp cho các hệ thống mở, nơi chúng tôi có thể muốn cài đặt hoặc duy trì các tác nhân khi chạy. Mô hình diễn viên cũng rất phù hợp với các hệ thống phân tán, vì việc sắp xếp các thông điệp không xác định có thể làm cho việc thực hiện tuân thủ dễ dàng hơn. (Lý do các tác nhân không phù hợp hơn với các hệ thống phân tán là việc đảm bảo tin nhắn đến 'một lần và chỉ một lần' là khá khó khăn khi đối mặt với sự gián đoạn và các diễn viên cũng có xu hướng yêu cầu phân phối, đó là một nỗi đau.)
FRP rất phù hợp với các hệ thống khép kín hoạt động theo thời gian - ví dụ như bộ điều khiển robot, lập trình âm nhạc, đồ chơi tính toán. Tính quyết định và tính năng cấu thành giúp FRP thuận tiện hơn khi làm việc với các tác nhân, ít nhất là trong những trường hợp FRP có thể trực tiếp mô hình hóa một giải pháp. Tích hợp FRP với các hiệu ứng (thanh lịch, không hack mô hình với tạp chất) đã được chứng minh là khó khăn. Gần đây đã có nghiên cứu về FRP hiệu quả thông qua 'lỗ sâu đục' - truy cập tài nguyên một cách hiệu quả, duy nhất hoặc tuyến tính vào tài nguyên.
Có những mô hình khác nằm ở đâu đó giữa FRP và Diễn viên.
Lập trình dựa trên dòng chảy (FBP), được phát triển bởi John Paul Morrison, thực sự hỗ trợ truyền phát thông điệp.
Các giao thức Time Warp (hoặc công việc gần đây hơn về Light Time Warp (LTW)) đặt các thông điệp giống như diễn viên trên dòng thời gian logic để cung cấp một khái niệm kiểm soát và kết hợp nhiều hơn về việc truyền thông điệp. Warp thời gian thường được sử dụng cho các hệ thống song song và phân tán lớn, ví dụ tính toán khoa học. Warp thời gian ban đầu không được sử dụng cho các simulat tương tác (khả năng đáp ứng với đầu vào của con người) và LTW chỉ phù hợp với biên độ.
Tôi đang phát triển Lập trình nhu cầu phản ứng (RDP) cho phép xử lý và xử lý tín hiệu giống như FRP và xử lý tín hiệu trong các hệ thống mở và phân tán và loại bỏ trạng thái cục bộ. RDP đạt được bằng cách hạn chế các tác dụng phụ đối với ảnh hưởng giao hoán, bình thường đến trạng thái tài nguyên bằng các tín hiệu theo thời gian. RDP yêu cầu xem xét lại các mô hình tài nguyên và trạng thái.
Tôi muốn chỉ ra làm thế nào họ khác với quan điểm thực tế:
1) diễn viên gửi tin nhắn cho các diễn viên khác, thông điệp này được mô tả rõ ràng và bắt buộc .
Ví dụ:
send msg to Actor137.
2) trong FRP luồng dữ liệu được mô tả khai báo :
Ví dụ:
Cell134=Cell185+Cell42.
Truyền tin nhắn được xử lý bởi khung FRP và bạn không phải mô tả "thủ công" cách truyền tin nhắn từ một ô (gần giống với Diễn viên, đóng gói trạng thái, còn gọi là Hành vi) cho một ô khác.
Nói cách khác:
Bản chất của lập trình phản ứng chức năng là xác định hành vi động của một giá trị hoàn toàn tại thời điểm khai báo. Vì vậy, tất cả các phụ thuộc Cell134được xác định tại điểm khai báo.
Điều này không đúng với mô hình diễn viên. Các tác nhân ảnh hưởng đến hành vi của một diễn viên Akhông được xác định tại cùng một vị trí trong mã nguồn nơi diễn viên Ađược xác định.
Gần đây tôi nhận thấy rằng có một sự kết hợp thú vị giữa hai luồng: Akka, trong đó dataflow được mô tả khai báo nhưng được thực hiện bằng cách sử dụng các tác nhân.
Một điểm khác biệt là: Các diễn viên có xu hướng không đồng bộ trong khi FRP có xu hướng đồng bộ (thường không ổn ).