Lập trình chức năng có thể được sử dụng để phát triển một ứng dụng doanh nghiệp đầy đủ?

Tôi mới bắt đầu học lập trình chức năng (FP). Tôi đến từ một thế giới OOP, nơi mọi thứ đều là đồ vật và hầu hết chúng đều có thể thay đổi. Tôi có một thời gian khó khăn xung quanh khái niệm rằng các chức năng không có tác dụng phụ.

Nếu một cái gì đó không thể thay đổi, làm thế nào là những đối tượng phổ biến như Nhân viên hoặc Người được đại diện trong FP.

Có thể sử dụng FP để tạo một ứng dụng doanh nghiệp chính thức?

Câu hỏi không phải là FP có thể được sử dụng trong Doanh nghiệp? Nhưng chúng ta có nên sử dụng FP trong Entepawn không?

Tất nhiên bạn có thể. Bạn có thể phát triển bất kỳ loại ứng dụng nào với bất kỳ loại ngôn ngữ lập trình nào, đó là lý do tại sao chúng được gọi là "Turing hoàn thành".

Bây giờ, với câu hỏi "Có nên sử dụng nó trong Doanh nghiệp?" Điều đó tùy thuộc vào bạn hoặc chủ lao động của bạn, FP có thể thực sự hữu ích trong một số loại ứng dụng và trên thực tế, nó được sử dụng khá nhiều: Haskell trong ngành

Bây giờ, bạn có thể hỏi "Vậy tại sao không được sử dụng nhiều hơn?" chủ yếu là vì các ngôn ngữ bắt buộc / OO khác phổ biến hơn và các công ty từ chối thay đổi sang ngôn ngữ "kỳ lạ" hơn vì chúng được sử dụng cho Java hoặc C ++.

Tôi đã bắt đầu tìm hiểu về các ngôn ngữ FP cách đây vài năm (Haskell, Scala, Scheme) và mặc dù tôi không phải là một chuyên gia, tôi phát hiện ra rằng chúng có thể khiến tôi cực kỳ năng suất, đối với một số nhiệm vụ nhất định hơn C ++ hoặc Java .

IMO, một số điểm mạnh của ngôn ngữ FP là:

• Họ có xu hướng rất súc tích, nhưng họ vẫn giữ được một ngữ nghĩa rõ ràng.
• Bạn có thể sử dụng một kiểu khai báo và không cần phải suy nghĩ quá nhiều về các chi tiết triển khai.
• Một hệ thống loại phong phú như Haskell có thể bắt gặp nhiều lỗi logic từ rất sớm (tại thời điểm biên dịch). Theo như tôi biết (thực tế không nhiều lắm), SML và Ocaml cung cấp những lợi thế tương tự.

Cho đến nay, tôi thấy việc chuyển đổi sang mô hình FP khá thú vị và không quá khó khăn khi bạn dành đủ thời gian cho nó. (Nhưng tôi đã dành bao nhiêu thời gian để học C hoặc C ++? Khá nhiều!)

Vì vậy, tôi nghĩ rằng từ quan điểm kỹ thuật, việc phát triển một ứng dụng doanh nghiệp đầy đủ bằng ngôn ngữ lập trình chức năng là hoàn toàn hợp lý.

Thật không may, mô hình này không phải là chủ đạo: hầu hết các công ty có xu hướng chỉ áp dụng các công nghệ được thử nghiệm tốt, vì vậy họ sẽ tránh xa FP cho đến khi họ có đủ bằng chứng cho thấy nó thực sự hoạt động, có đủ nhà phát triển, công cụ, thư viện, khung. Do đó, rất khó để tìm một công việc mà bạn có thể làm lập trình FP toàn thời gian ngay bây giờ.

Có thể tình hình hiện tại sẽ thay đổi nếu việc sử dụng ngày càng nhiều bộ xử lý đa lõi sẽ khuyến khích đầu tư nhiều hơn vào các ngôn ngữ FP, dường như khá mạnh để viết phần mềm đồng thời.

Ngoài ra, có xu hướng giới thiệu một số tính năng của FP thành các ngôn ngữ chính, phi chức năng như C #, C ++ để các lập trình viên có thể sử dụng một số FP mà không cần chuyển đổi mô hình hoàn chỉnh. Có thể trong mười năm nữa, các ngôn ngữ này sẽ bao gồm đủ các tính năng FP mà việc chuyển sang ngôn ngữ chức năng thuần túy sẽ dễ dàng hơn rất nhiều.

Tôi không nghĩ rằng đó là ý tưởng tốt nhất. Nhưng nó phụ thuộc vào bản chất của ứng dụng cụ thể.

Tôi tin tưởng rất nhiều vào triết lý của Eric Evans như được mô tả trong cuốn sách của ông, Thiết kế hướng tên miền , rằng bạn nên tạo một mô hình miền đại diện cho vấn đề có thể giúp bạn giải quyết vấn đề của mình. Evans đề nghị tìm một ngôn ngữ lập trình phù hợp với vấn đề cụ thể, ví dụ như ông đề cập đến Fortran như một cách giải quyết các vấn đề có tính chất toán học. Hoặc thậm chí tạo các ngôn ngữ chuyên biệt cho miền cụ thể cho vấn đề hiện tại.

Khi bạn đã thành công trong việc tạo ra một mô hình miền tốt, bạn sẽ thấy rằng mã trình bày kết thúc là một lớp vỏ mỏng trên đầu lớp miền.

Bây giờ, điều với ứng dụng doanh nghiệp là loại ứng dụng này (nếu bạn có thể khái quát về các ứng dụng doanh nghiệp) thường liên quan đến việc sửa đổi trạng thái của các thực thể có bản sắc quan trọng và duy trì các thực thể được sửa đổi trong cơ sở dữ liệu. Loại vấn đề rất khái quát này được IMHO giải quyết tốt hơn rất nhiều bằng cách sử dụng mô hình hướng đối tượng hơn là mô hình chức năng.

Điều này không có nghĩa là có những lĩnh vực của ứng dụng doanh nghiệp không thể giải quyết tốt hơn bằng mô hình chức năng. Ví dụ: mô-đun phân tích rủi ro của ứng dụng ngân hàng hoặc mô-đun lập kế hoạch tuyến đường trong ứng dụng vận chuyển. Và có lẽ một số ứng dụng doanh nghiệp có thể được thực hiện hoàn toàn bằng cách sử dụng một mô hình chức năng.

Nhưng nói chung, tôi nghĩ rằng mô hình hướng đối tượng cho phép tạo ra các mô hình miền hữu ích hơn cho phần lớn các ứng dụng doanh nghiệp.

Chỉnh sửa

Do một số upvote, tôi đã chú ý đến câu trả lời này - và kể từ khi tôi viết nó, tôi đã học được nhiều hơn về FP - và tôi không hoàn toàn chắc chắn rằng tôi đồng ý với câu trả lời của riêng mình nữa. Một số ngôn ngữ chức năng có thể mô tả rất độc đáo các trường hợp sử dụng. Nhưng bạn cần phải học một bộ tâm hoàn toàn khác.

Vâng, nó có thể. Google một chút và bạn sẽ tìm thấy phần mềm thực sự được mã hóa bằng các ngôn ngữ chức năng thuần túy.

Đối với câu hỏi của bạn về các đối tượng kinh doanh, tôi đoán vấn đề thực sự của bạn là bất biến. Trong trường hợp đó, hãy cân nhắc rằng bạn sẽ trả lại một "Người" mới mỗi lần bạn sẽ thay đổi nó nếu bạn đang sử dụng một ngôn ngữ bắt buộc.

Lưu ý rằng kỹ thuật này cũng có thể được thực hiện bằng các ngôn ngữ bắt buộc!

Lập trình hàm (FP) như Lập trình hướng đối tượng (OOP) là các mô hình. Chúng đại diện cho các mô hình hoặc cách tiếp cận khác nhau cho các vấn đề lập trình. Những cách tiếp cận khác nhau này không làm giảm khả năng sản xuất phần mềm có thể mở rộng, có thể bảo trì và có thể mở rộng. Điều đó không có nghĩa là các phương pháp tương đương với tất cả các loại vấn đề; họ không. Một số vấn đề nhất định tự sắp xếp tốt hơn (hoặc tệ hơn) với các mô hình cụ thể, ví dụ, FP sẽ không phải là lựa chọn đầu tiên của tôi cho một chương trình có chuỗi hoạt động phụ thuộc với các tác dụng phụ. Tuy nhiên các chương trình như vậy có thể và đã được viết, và viết tốt.

Có, FP có thể được sử dụng trong các ứng dụng doanh nghiệp. Clojure là một ví dụ về ngôn ngữ FP thành công trong doanh nghiệp: http://cognitect.com/clojure#successstories

Đại diện cho trạng thái có thể là một thách thức trong FP và thay đổi mô hình để phù hợp với FP có thể là một chút khó khăn trong tâm trí. Một số ngôn ngữ FP hoàn toàn không cho phép bên ảnh hưởng và trạng thái có thể thay đổi. Clojure cho phép cả hai nhưng không khuyến khích hoặc cô lập những mô hình đó.

Nói tóm lại, đại diện nhà nước có thể rất giống với OO. Đó là sửa đổi nhà nước rất khác nhau. Vì vậy, ví dụ, ở trạng thái FP có thể được thể hiện bằng danh sách và bản đồ. Một danh sách nhân viên có thể trông giống như:

[[name: "James Brown" address: "Barnwell, SC"]
 [name: "Elvis Presley" address: "Tupelo, MS"]]

Có hai cách tôi biết để xử lý sửa đổi trạng thái trong FP. Một là một cái gì đó giống như lập trình phản ứng chức năng. Trong mô hình này, tất cả trạng thái chỉ được xử lý ở mức cao nhất ... ví dụ: chế độ xem HTML của ứng dụng của bạn có trạng thái trong chế độ xem (như tên người, địa chỉ, v.v.). Bây giờ khi bạn nhấp vào "cập nhật tên", một chức năng được gọi là xử lý mọi điều về cập nhật tên ngoại trừ thực sự thay đổi tên. Điều này nghe có vẻ kỳ lạ ... nhưng hãy chịu đựng tôi. Tên đã thay đổi sau đó sẽ được trả về bởi hàm và chế độ xem (hoặc lưu trữ dữ liệu liên tục, v.v.) sẽ hiển thị tên mới. Hoặc, thay vào đó, toàn bộ cấu trúc mới với tên được cập nhật sẽ được trả về. Vậy chức năng này làm gì? Nó xác nhận tên và trả về tên mới nếu nó hợp lệ, lỗi nếu không, và có thể một chế độ xem mới hoặc liên kết điều hướng để theo dõi. Đối với một cái gì đó phức tạp hơn một sự thay đổi tên, nó có thể làm nhiều hơn nữa.

Vì vậy, đối với FRP, đối tượng được trả về bởi hàm là trạng thái mới và có thể được cung cấp trực tiếp cho khung nhìn hoặc bất cứ thứ gì ở mức cao. Trong một số trường hợp, FRP đưa toàn bộ trạng thái chuyển nó vào hàm và lấy lại toàn bộ trạng thái.

Với mô hình này, bộ chứa hoặc khung cần xử lý cập nhật màn hình, cơ sở dữ liệu hoặc bất cứ thứ gì khác cần cập nhật từ trạng thái mới. Vì vậy, bạn có thể tưởng tượng một khung vẽ ứng dụng trên màn hình. Khi người dùng nhấp vào một cái gì đó chức năng được gọi và trạng thái mới được trả về. Khung sau đó cập nhật màn hình bằng cách vẽ lại mọi thứ hoặc vẽ lại một cách thông minh các phần của màn hình. Xem http://blog.getprismatic.com/om-sweet-om-high-feftal-frontend-engineering-with-clojurescript-and-react/

Clojure sử dụng mô hình thứ hai mà tôi đã gặp và đó là cách ly các thay đổi trạng thái nhưng không nhất thiết phải hạn chế chúng ở mức cao nhất. Với Clojure, tất cả trạng thái có thể thay đổi phải được "giữ" (trừ khi bạn đang sử dụng các đối tượng Java cho trạng thái) bởi một nguyên tử, tác nhân hoặc tham chiếu. Cách thức hoạt động này là đối tượng được giữ hoặc chỉ hoặc tham chiếu (tuy nhiên bạn muốn gọi nó) bởi nguyên tử / tác nhân / ref là bất biến, nhưng nguyên tử / tác nhân / ref có thể thay đổi để trỏ đến một đối tượng mới. Trong trường hợp này, bạn sử dụng các phương thức đặc biệt trên nguyên tử / tác nhân / ref có nội dung "cập nhật đối tượng ở đây bằng cách thực hiện và làm như vậy và gán lại nguyên tử / tác nhân / ref cho một đối tượng mới".

Tại sao điều này có lợi bạn có thể yêu cầu? Bởi vì đối tượng bất biến được tham chiếu bởi các cấu trúc Clojure này có thể được truyền cho một hàm thực hiện điều gì đó và trong khi chức năng đó đang chạy tham chiếu đến đối tượng được đảm bảo không thay đổi. Đó là, nguyên tử / tác nhân / ref không được truyền cho hàm nhưng đối tượng bất biến được chỉ ra bởi chúng được truyền. Các nguyên tử, tác nhân và ref có các thuộc tính đặc biệt xử lý các cập nhật và đồng thời theo cách an toàn và là một phần của ngôn ngữ. Xem http://clojure.org/state

Tôi hi vọng cái này giúp được. Tôi đề nghị đọc thêm về trạng thái Clojure và FRP để hiểu rõ hơn về cách nhân viên và người có thể được đại diện trong FP. Mặc dù, biểu diễn thực tế sẽ tương tự như lập trình hướng đối tượng ... đó là khả năng biến đổi thực sự khác biệt.