Đối với những vấn đề phổ biến là lập trình chức năng không phù hợp? [đóng cửa]


22

Lập trình hàm là một mô hình khai báo. Một trong những điểm mạnh với FP là tránh các tác dụng phụ. Người ta nói rằng đối với một số vấn đề, FP không phù hợp.

Đối với những vấn đề phổ biến không phải là lập trình chức năng phù hợp?


Phù! Trong một khoảnh khắc tôi nghĩ bạn nói "là một mô hình khiếm khuyết ". Sau đó tôi quay lại và kiểm tra.
Đánh dấu C

1
Tôi nghĩ chính xác hơn khi nói rằng các tác dụng phụ bị cô lập (dù sao trong Haskell) hơn là tránh. Các đơn nguyên cho phép thay đổi trạng thái và thậm chí một cái còn được đặt tên là "Trạng thái".
Larry Coleman

Như Larry Coleman đã giải thích, không đúng khi lập trình chức năng tránh các tác dụng phụ, nhưng nó không khuyến khích việc sử dụng của họ và, trong một số ngôn ngữ, nó cách ly rõ ràng với họ. Đọc ví dụ Phần 7 của research.microsoft.com/en-us/um/people/simonpj/papers/...
Giorgio

Câu trả lời:


17

Các ứng dụng rất tự nhiên trong tự nhiên. Trò chơi điện tử là một ví dụ điển hình vì chúng mô hình hóa thế giới thực. Sẽ có ý nghĩa hơn nhiều khi nghĩ về việc sửa đổi trạng thái của thế giới thay vì xây dựng lại từ trạng thái trước mỗi khi có gì đó thay đổi.

Một ví dụ cụ thể sẽ thay đổi sức khỏe của quái vật sau khi nó bị bắn. Việc thay đổi sức khỏe của nó đơn giản hơn nhiều so với việc thay thế nó bằng một con quái vật hoàn toàn mới giống nhau về mọi mặt ngoại trừ bây giờ nó có ít sức khỏe hơn. Những loại thay đổi này tạo nên mọi thứ trong thế giới trò chơi và thực hiện điều này theo cách thức chức năng thuần túy không trực quan lắm. Tôi tưởng tượng có thể có một số hình phạt hiệu suất đáng kể, ít nhất là nếu bạn đang thực hiện nó bằng một ngôn ngữ hoàn toàn chức năng.

(Như một lưu ý phụ, một số vấn đề trong trò chơi rất phù hợp với lập trình chức năng, chẳng hạn như AI. Một ngôn ngữ chức năng / mệnh lệnh lai sẽ phù hợp tuyệt vời cho những trường hợp đó.)


9
Bài viết Ngôn ngữ lập trình chính tiếp theo: Quan điểm của nhà phát triển trò chơi lập luận cho một pl, đặc biệt cho phát triển trò chơi, trong đó hành vi chức năng thuần túy là mặc định và thay đổi trạng thái được theo dõi thông qua các loại, để tránh lỗi. Vì vậy, không phải ai cũng tin rằng mô hình chức năng vốn đã không phù hợp với lập trình trò chơi.
sepp2k

1
@ sepp2k, cảm ơn vì đường link. Tôi rất vui khi thấy viễn cảnh được tranh luận từ một người đã tạo ra các trò chơi thực sự.
Matt Olenik

3
@ sepp2k chờ đã, tôi có bỏ lỡ điều gì không? Sau khi đọc bản trình bày kỹ hơn, có vẻ như Sweeney đã lập luận rằng hầu hết các công cụ cốt lõi được viết bằng mã chức năng thuần túy, và hầu hết logic trò chơi được viết một cách bắt buộc (hoặc ít nhất là cho phép nó) và sử dụng STM để trợ giúp đồng thời . Điều này có vẻ rất hợp lý với tôi.
Matt Olenik

@Matt: Không, bạn nói đúng, anh ấy nói phần logic trò chơi sẽ chứa trạng thái có thể thay đổi. Tuy nhiên, điều đó không ngăn cản ngôn ngữ theo dõi khả năng biến đổi thông qua các loại (mà ông đề xuất trong phần "suy nghĩ"). Tất nhiên "trạng thái theo dõi thông qua các loại" không bằng "chức năng", vì vậy tôi có thể đã đưa ra nhận xét trước đây của mình một cách quá lạc quan.
sepp2k

@ sepp2k đúng, tôi hiểu ý của bạn.
Matt Olenik

17

Lập trình nhúng thời gian thực là tất cả về các tác dụng phụ. Tương tác với io kỹ thuật số và analog, bộ hẹn giờ, cổng nối tiếp và song song, mọi thứ thú vị đều được thực hiện bằng cách gọi các chức năng với các hiệu ứng phụ.


3
Chà, nếu bạn chỉ muốn nói đến giao diện phần cứng thì tôi nghi ngờ bất cứ điều gì khác ngoài C / C ++ là một lựa chọn tốt. Tuy nhiên, trên lớp trên cùng của các ngôn ngữ như Erlang đôi khi được sử dụng, đặc biệt trong các hệ thống viễn thông. Erlang là một ngôn ngữ chức năng được thiết kế cho các hệ thống thời gian thực nhúng quan trọng và chịu lỗi.
Jonas

@Jonas: Erlang có thể giảm thiểu đột biến nhưng nó phụ thuộc rất nhiều vào IO để truyền thông điệp, tất nhiên, đó là một tác dụng phụ.
Jon Harrop

11

Tôi cho rằng lập trình GUI không phù hợp với lập trình chức năng. GUI nói chung rất có trạng thái và việc mô hình hóa / quản lý chúng bằng trạng thái dễ dàng hơn nhiều so với sử dụng hiệu ứng phụ miễn phí. Chắc chắn có thể sử dụng ngôn ngữ lập trình chức năng cho GUI ... nhưng có lẽ đó không phải là ý kiến ​​hay.

Như đã lưu ý trong một câu trả lời khác, các trò chơi thường dễ quản lý hơn bằng cách theo dõi trạng thái và trong khi bạn có thể viết một trò chơi bằng ngôn ngữ chức năng, việc làm như vậy thường dễ dàng và hiệu quả hơn trong ngôn ngữ "trạng thái" (nghĩa là hướng đối tượng ngôn ngữ).


-1: Bạn đang nói về độ tinh khiết và bỏ qua việc sử dụng các hàm hạng nhất, ví dụ như gọi lại trong mã GUI dễ dàng hơn nhiều với các ngôn ngữ FP không tinh khiết so với các ngôn ngữ OOP.
Jon Harrop

4
@Jon Harrop: Các hàm hạng nhất không phải là duy nhất cho các ngôn ngữ lập trình hàm. Tôi vẫn cho rằng phong cách FP không phù hợp với GUI.
mipadi

1
Phụ thuộc vào người bạn hỏi. Đối với hầu hết các lập trình viên chức năng, các hàm hạng nhất là định nghĩa chính của lập trình hàm.
Jon Harrop

@Jon Harrop: Hầu hết các lập trình viên chức năng sẽ nói rằng lập trình chức năng là một phương pháp mô tả các chương trình như là thành phần và đánh giá các chức năng toán học. Các hàm hạng nhất là một phần quan trọng của mô hình này, nhưng các hàm hạng nhất không phải là ngôn ngữ lập trình chức năng (hoặc chương trình chức năng) tạo ra. Mô hình lập trình chức năng cố gắng giảm thiểu việc sử dụng các cấu trúc dữ liệu trạng thái và có thể thay đổi, và thậm chí các ngôn ngữ FP không tinh khiết khuyến khích phong cách này. FP nói nhiều về phong cách lập trình vì nó là các tính năng riêng lẻ như các chức năng hạng nhất và ...
mipadi

... Tôi không thấy rằng mô hình này đặc biệt phù hợp với lập trình GUI - nói chung, các ngôn ngữ hướng đối tượng phù hợp hơn với GUI, nói chung.
mipadi

5

Ứng dụng kinh doanh dựa trên dữ liệu. Giao diện người dùng và các thao tác dữ liệu đơn giản không cần FP.


2
Và bất kỳ dữ liệu / xem ứng dụng khác, thực sự. Phần lớn các trò chơi đều là về trạng thái và thay đổi nó, và do đó không dịch tốt sang một phong cách chức năng.
Jon Purdy

18
Có thật không? Tôi luôn nghĩ rằng FP sẽ đặc biệt tốt cho việc này. Không giống như 99% những gì các ứng dụng đó chọn, tổng hợp và chiếu dữ liệu? Về cơ bản filter, reducemap. Ném vào một số sort, partition, groupBy. Xét cho cùng, ngôn ngữ lập trình được sử dụng rộng rãi nhất để viết các ứng dụng như vậy là Excel, đây ngôn ngữ chức năng.
Jörg W Mittag

3
Các ứng dụng và ứng dụng kinh doanh dựa trên dữ liệu với các hoạt động dữ liệu đơn giản nghe có vẻ rất phù hợp với FP và tôi đã nghe nói rằng FP rất phổ biến cho những thứ như vậy. Ví dụ: xem Adventures fa lập trình viên chức năng trên Phố Wall
Jonas

1
-1: Bạn đã liệt kê một số ứng dụng mà FP vượt trội.
Jon Harrop

2

Bạn không thể dễ dàng loại bỏ bất kỳ vấn đề nào được đặt ra vì không phù hợp với lập trình chức năng.

Phần lớn phụ thuộc vào ngôn ngữ thực tế được sử dụng cho lập trình chức năng và các tính năng của nó.

Một ví dụ là Erlang đã được đề cập cho các hệ thống nhúng thời gian thực.

Đầy đủ trạng thái cũng không phải là một tiêu chí tốt để chống lại lập trình chức năng, có một số cách thành công được thực hiện trong các ngôn ngữ lập trình chức năng để đối phó với điều này.

Tác dụng phụ cũng thường được đề cập chống lại lập trình chức năng. Mỗi chương trình không hoàn toàn độc đoán đều có tác dụng phụ. Vì vậy, mọi ngôn ngữ FP trong thế giới thực đều có một số cách để đối phó với điều này, vấn đề chỉ là làm thế nào để gói gọn các tác dụng phụ của thế giới.

Không cần các tác dụng phụ tùy ý như các biến toàn cục.

Nhưng có những bộ vấn đề giúp bạn dễ dàng tham gia vào lập trình chức năng hơn vì chúng không làm thay đổi cách nhìn vấn đề quen thuộc của bạn nhiều như vậy. Nhưng một khi bạn quản lý để suy nghĩ chức năng, ngày càng nhiều bộ vấn đề được mở ra để ít tác dụng phụ hơn.

Ngay cả khi lập trình C, luôn luôn là một ý tưởng tốt để giảm các tác dụng phụ tùy ý như các biến toàn cục càng nhiều càng tốt.


Các ứng dụng ưu việt như ứng dụng GUI thực sự khó thực hiện theo cách chức năng, hoặc bạn có đề xuất nào không?
Jonas

Nếu bạn có một số loại trừu tượng của quy trình / luồng (ví dụ như trong Erlang), bạn có thể chuyển trạng thái của mình xung quanh trong một quy trình.
Peer Stritzinger

3
Các ứng dụng GUI thường được xây dựng xung quanh một vòng lặp sự kiện. Bạn có thể viết một vòng lặp sự kiện khá tốt bằng ngôn ngữ chức năng. Nếu nó phức tạp hơn, có thể bạn sẽ thêm một số chủ đề / quy trình để xử lý nền. Nhưng nếu bạn có một số loại trừu tượng của quy trình / luồng (ví dụ như trong Erlang), bạn có thể chuyển trạng thái của mình xung quanh trong một quy trình một cách dễ dàng. Tiếp tục cũng có thể có ích. Tôi nghĩ rằng nó chỉ quen với việc làm mọi thứ theo cách có chức năng để thậm chí xử lý GUI. Một lý do lập trình GUI được coi là khó hiện nay là hầu hết các bộ công cụ không dành cho sử dụng chức năng.
Peer Stritzinger

1
@Jonas: trong Haskell, bạn sẽ sử dụng đơn vị IO, đơn vị Nhà nước hoặc kết hợp.
Larry Coleman

1
@Jonas: điều đó phụ thuộc vào định nghĩa của bạn hữu ích. Ví dụ về wikibook sử dụng wxHaskell, trong khi Real World Haskell sử dụng gtk2hs. Tôi chưa thử vì ứng dụng Haskell của tôi dựa trên dòng lệnh.
Larry Coleman
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.