Tại sao chưa lập trình chức năng?


197

Tôi đã đọc một số văn bản về lập trình khai báo / chức năng (ngôn ngữ), đã tự mình thử Haskell cũng như viết một văn bản. Từ những gì tôi đã thấy, lập trình chức năng có một số lợi thế so với phong cách mệnh lệnh cổ điển:

  • Chương trình không quốc tịch; Không có tác dụng phụ
  • Đồng thời; Chơi cực hay với công nghệ đa lõi đang lên
  • Các chương trình thường ngắn hơn và trong một số trường hợp dễ đọc hơn
  • Năng suất tăng (ví dụ: Erlang)

  • Lập trình mệnh lệnh là một mô hình rất cũ (theo như tôi biết) và có thể không phù hợp với thế kỷ 21

Tại sao các công ty sử dụng hoặc các chương trình được viết bằng ngôn ngữ chức năng vẫn rất "hiếm"?

Tại sao, khi nhìn vào những lợi thế của lập trình chức năng, chúng ta vẫn đang sử dụng các ngôn ngữ lập trình bắt buộc?

Có thể đó là quá sớm cho nó vào năm 1990, nhưng ngày nay?


1
LƯU Ý: câu hỏi này đã được thảo luận về meta ít nhất hai lần và sự đồng thuận là nó nên được giữ, mặc dù được lưu trữ thông qua khóa "ý nghĩa lịch sử" được đề cập ở trên. Tôi đặc biệt khuyến khích bất cứ ai xem điều này với một mắt hướng tới việc mở khóa thay vì dừng lại và cảm ơn vì không phải tham gia vào một cuộc thảo luận tẻ nhạt khác về câu hỏi này, hãy tận hưởng câu trả lời như họ, và tiếp tục công việc của họ.
Shog9

Câu trả lời:


530

Vì tất cả những ưu điểm đó cũng là nhược điểm.

Chương trình không quốc tịch; Không có tác dụng phụ

Các chương trình trong thế giới thực là tất cả về tác dụng phụ và đột biến. Khi người dùng nhấn nút đó là vì họ muốn điều gì đó xảy ra. Khi họ gõ vào một cái gì đó, họ muốn trạng thái đó thay thế bất kỳ trạng thái nào đã từng ở đó. Khi Jane Smith làm kế toán kết hôn và đổi tên thành Jane Jones, cơ sở dữ liệu ủng hộ quy trình kinh doanh in tiền lương của cô ấy tốt hơn hết là xử lý loại đột biến đó. Khi bạn bắn súng máy vào người ngoài hành tinh, hầu hết mọi người không mô hình hóa tinh thần đó là việc xây dựng một người ngoài hành tinh mới với ít điểm nhấn hơn; họ mô hình hóa nó như một sự đột biến của các thuộc tính của người ngoài hành tinh hiện có.

Khi các khái niệm ngôn ngữ lập trình hoạt động cơ bản chống lại miền được mô hình hóa, thật khó để biện minh cho việc sử dụng ngôn ngữ đó.

Đồng thời; Chơi cực hay với công nghệ đa lõi đang lên

Vấn đề chỉ là đẩy xung quanh. Với cấu trúc dữ liệu bất biến, bạn có sự an toàn của luồng giá rẻ với chi phí có thể làm việc với dữ liệu cũ. Với cấu trúc dữ liệu có thể thay đổi, bạn có lợi ích là luôn luôn làm việc với dữ liệu mới với chi phí phải viết logic phức tạp để giữ cho dữ liệu nhất quán. Nó không giống như một trong những thứ đó rõ ràng là tốt hơn cái kia.

Các chương trình thường ngắn hơn và trong một số trường hợp dễ đọc hơn

Ngoại trừ trong trường hợp chúng dài hơn và khó đọc hơn. Học cách đọc các chương trình được viết theo phong cách chức năng là một kỹ năng khó; mọi người dường như tốt hơn nhiều trong việc hình thành các chương trình như một loạt các bước cần tuân thủ, giống như một công thức, thay vì một loạt các tính toán được thực hiện.

Năng suất tăng (ví dụ: Erlang)

Năng suất phải tăng lên rất nhiều để biện minh cho chi phí khổng lồ của việc thuê các lập trình viên, những người biết cách lập trình theo phong cách chức năng.

Và hãy nhớ rằng, bạn không muốn vứt bỏ một hệ thống làm việc; hầu hết các lập trình viên không xây dựng các hệ thống mới từ đầu, mà là duy trì các hệ thống hiện có, hầu hết được xây dựng bằng các ngôn ngữ phi chức năng. Hãy tưởng tượng cố gắng biện minh điều đó cho các cổ đông. Tại sao bạn lại loại bỏ hệ thống bảng lương làm việc hiện tại của mình để xây dựng một hệ thống mới với chi phí hàng triệu đô la? "Bởi vì lập trình chức năng là tuyệt vời" không thể làm hài lòng các cổ đông.

Lập trình mệnh lệnh là một mô hình rất cũ (theo như tôi biết) và có thể không phù hợp với thế kỷ 21

Lập trình chức năng cũng rất cũ. Tôi không thấy tuổi của khái niệm này có liên quan như thế nào.

Đừng hiểu lầm tôi. Tôi yêu thích lập trình chức năng, tôi tham gia nhóm này vì tôi muốn giúp đưa các khái niệm từ lập trình chức năng vào C # và tôi nghĩ rằng lập trình theo phong cách bất biến là con đường của tương lai. Nhưng có những chi phí rất lớn để lập trình theo kiểu chức năng không thể bỏ qua. Sự thay đổi theo hướng phong cách chức năng hơn sẽ diễn ra chậm và dần dần trong một khoảng thời gian nhiều thập kỷ. Và đó là những gì nó sẽ là: một sự thay đổi theo phong cách chức năng hơn, không phải là sự bán buôn bao gồm sự thuần khiết và vẻ đẹp của Haskell và việc từ bỏ C ++.

Tôi xây dựng trình biên dịch để kiếm sống và chúng tôi chắc chắn đang nắm giữ một phong cách chức năng cho thế hệ công cụ biên dịch tiếp theo. Đó là bởi vì lập trình chức năng về cơ bản là một kết hợp tốt cho các loại vấn đề chúng ta gặp phải. Vấn đề của chúng tôi là tất cả về việc lấy thông tin thô - chuỗi và siêu dữ liệu - và chuyển đổi chúng thành các chuỗi và siêu dữ liệu khác nhau. Trong các tình huống xảy ra đột biến, giống như ai đó đang gõ vào IDE, không gian vấn đề vốn đã tự cho mình sử dụng các kỹ thuật chức năng, chẳng hạn như chỉ xây dựng lại các phần của cây đã thay đổi. Nhiều miền không có các thuộc tính đẹp này khiến chúng rõ ràng có thể tuân theo kiểu chức năng .


41
"Khi Jane Smith làm kế toán kết hôn và đổi tên thành Jane Jones, cơ sở dữ liệu ủng hộ quy trình kinh doanh in tiền lương của cô ấy tốt hơn hết là xử lý loại đột biến đó." Sẽ có một bản ghi tên cũ của Jane Smith, chúng tôi không cập nhật hồi tố tất cả các trường hợp tên cũ của Jane thành tên mới của cô ấy;)
Juliet

40
@Juliet: Chắc chắn rồi. Quan điểm của tôi là nếu bạn có một đối tượng đại diện cho nhân viên, sẽ có ý nghĩa khi nghĩ về hoạt động "thay đổi tên của nhân viên" thành một đột biến của đối tượng đại diện cho nhân viên không thay đổi danh tính đối tượng . Khi Jane Smith thay đổi tên, bạn không tạo ra một nhân viên khác tên là Jane Jones mà ngược lại. Không có hai nhân viên với hai tên khác nhau. Việc mô hình hóa quá trình này là đột biến của một đối tượng, không phải là việc xây dựng một đối tượng mới.
Eric Lippert

24
Đây là một câu trả lời tốt, nhưng tôi nghĩ bạn đôi khi nói quá trường hợp của bạn. Giống như Juliet đã nói, mặc dù mọi người có thể nghĩ về nó như một sự thay đổi tên, nhưng nó thực sự là một sự thay thế tên ở cấp độ sâu hơn. Và mặc dù mọi người có thể khó đọc các chương trình chức năng hơn (vì đó một kỹ năng đã học), nhưng điều đó thường không phải vì chúng dài hơn. Một chương trình Haskell hầu như sẽ luôn ngắn gọn hơn, giả sử, một chương trình Java - ngay cả trong một miền "phù hợp xấu" với nhiều trạng thái vốn có.
Chuck

29
+1 Thật là một luồng không khí trong lành để đọc câu trả lời này. Thật tuyệt vời khi nghe chủ nghĩa thực dụng như vậy (với niềm đam mê tiềm ẩn về lập trình chức năng) từ một người nào đó ở vị trí của bạn.
Dhaust

11
"Bởi vì tất cả những lợi thế đó cũng là nhược điểm. Các chương trình không trạng thái; Không có tác dụng phụ": Theo như tôi hiểu (tôi không biết đủ về FP để viết một câu trả lời có thẩm quyền) điều này không đúng . Lập trình chức năng là về tính minh bạch tham chiếu chứ không phải về trạng thái tránh (mặc dù trạng thái phải được xử lý phù hợp để đảm bảo tính minh bạch tham chiếu). Haskell không cho phép trạng thái và đột biến. Nó chỉ cung cấp các công cụ khác nhau (người ta có thể tranh luận, tốt hơn) để lý luận về nó.
Giorgio

38

Những kẻ chủ mưu lập trình: Cuộc trò chuyện với những người tạo ra các ngôn ngữ lập trình chính

[Haskell]

Tại sao bạn nghĩ rằng không có ngôn ngữ lập trình chức năng đã đi vào dòng chính?

John Hughes: Tiếp thị kém! Tôi không có ý tuyên truyền; chúng tôi đã có rất nhiều điều đó. Tôi có nghĩa là một sự lựa chọn cẩn thận của một thị trường mục tiêu để chiếm ưu thế, tiếp theo là một nỗ lực quyết tâm để thực hiện lập trình chức năng cho đến nay là cách hiệu quả nhất để giải quyết thị trường đó. Trong những ngày hạnh phúc của thập niên 80, chúng tôi nghĩ rằng lập trình chức năng là tốt cho mọi thứ - nhưng gọi công nghệ mới là "tốt cho mọi thứ" cũng giống như gọi nó là "đặc biệt không có gì". Thương hiệu được cho là gì? Đây là một vấn đề mà John Launchbury đã mô tả rất rõ ràng trong bài nói chuyện được mời tại ICFP. Kết nối Galois gần như đã đi xuống khi thương hiệu của họ là "phần mềm trong các ngôn ngữ chức năng", nhưng họ đã tăng cường sức mạnh kể từ khi tập trung vào "phần mềm bảo đảm cao".

Nhiều người không biết làm thế nào sự đổi mới công nghệ xảy ra và hy vọng rằng công nghệ tốt hơn sẽ tự mình trở thành ưu thế ( hiệu ứng "bẫy chuột tốt hơn" ), nhưng thế giới không như vậy.


36
Haskell: sau 20 năm, một thành công chỉ sau một đêm!
Juliet

theo liên kết và đọc các nhận xét cho một dis khá thú vị của Grady Booch. Không biết Booch là ai, nhưng dù sao nó cũng khiến tôi cười.
sợofawhackplanet

4
Grady Booch chịu trách nhiệm, cuối cùng, cùng với Jacobson và Rumbaugh, về sự ghê tởm đó là UML.
CHỈ CẦN HOẠT ĐỘNG CỦA TÔI đúng

27

Câu trả lời chứng khoán là không hoặc sẽ thay thế cái khác - chúng là những công cụ khác nhau có những ưu và nhược điểm khác nhau, và cách tiếp cận nào có lợi thế sẽ khác nhau tùy thuộc vào dự án và các vấn đề "mềm" khác như nhóm tài năng có sẵn.

Tôi nghĩ rằng bạn đúng rằng sự tăng trưởng đồng thời do đa lõi sẽ làm tăng tỷ lệ phần trăm (của tập hợp các dự án phát triển toàn cầu) khi lập trình chức năng được chọn so với các kiểu khác.

Tôi nghĩ ngày nay hiếm vì phần lớn nhóm tài năng chuyên nghiệp ngày nay thoải mái nhất với các công nghệ bắt buộc và hướng đối tượng. Ví dụ, tôi đã hơn một lần chọn Java làm ngôn ngữ cho một dự án thương mại vì nó đủ tốt, không gây tranh cãi và tôi biết rằng tôi sẽ không bao giờ hết những người có thể lập trình (đủ tốt) trong đó.


Điều này là rất sâu sắc và thú vị thực dụng. Chắc chắn là câu trả lời tốt nhất tôi từng thấy cho câu hỏi này dưới mọi hình thức.
Benson

Có thể bởi một ngôn ngữ mà cả hai đều là công dân hạng nhất sẽ trở nên phổ biến.
Kevin Kostlan

1
Đồng ý 110%. Đôi khi, tôi đã cố gắng vào FP, nhưng tôi đã mất ý chí tiếp tục sau một vài tuần. Tôi đã lập trình thủ tục hơn 30 năm và tôi đã quá quen với việc lập trình bắt buộc. Điều này đúng với ngành công nghiệp CNTT nói chung. Thay đổi sẽ không đến dễ dàng cũng không nhanh chóng.
Richard Eng

26

Mặc dù có những lợi thế của lập trình chức năng, lập trình bắt buộc và hướng đối tượng sẽ không bao giờ biến mất hoàn toàn.

Lập trình bắt buộc và hướng đối tượng là một mô tả từng bước của vấn đề và giải pháp của nó. Như vậy, nó có thể dễ hiểu hơn. Lập trình chức năng có thể là một chút tối nghĩa.

Cuối cùng, một chương trình hữu ích sẽ luôn có tác dụng phụ (như cung cấp đầu ra thực tế cho người dùng để tiêu thụ), do đó, ngôn ngữ chức năng thuần túy nhất vẫn sẽ cần một cách để thỉnh thoảng bước vào thế giới mệnh lệnh.

Tình trạng hiện đại nhất là các ngôn ngữ bắt buộc (như C #) mượn các tính năng từ thế giới chức năng (như câu lệnh lambda) và ngược lại.


3
Không phải là OOP một số loại tập hợp con của lập trình mệnh lệnh?
pankrax

9
OOP là một superset. OOP là bắt buộc vì C ++ là C.
Robert Harvey

10
Tôi không nghĩ OOP nhất thiết phải phụ thuộc vào lập trình mệnh lệnh. Nhìn một Clojure hoặc CLOS - cả hai đều có chức năng, nhưng hướng đối tượng.
Gabe

9
Ngôn ngữ OO có xu hướng bắt buộc, nhưng không cần phải như vậy. OCaml là một ngôn ngữ chức năng mạnh mẽ (mặc dù không hoàn toàn) mà toàn bộ raison d''rere là OO.
Chuck

7
Tôi không hiểu tại sao OOP là một siêu chương trình cấp bách. Không phải tất cả các mã bắt buộc là OOP và không phải tất cả các mã chức năng đều không phải là OOP. Tôi muốn nói rằng OOP là lập trình bắt buộc và lập trình chức năng như cánh khí động học là để đua xe, hoặc máy bay, hoặc tên lửa làm mát, hoặc cối xay gió, hoặc ... tức là, các khái niệm có liên quan, nhưng không được liên kết chặt chẽ kết nối 1-1.
Sebastian Mach

21

Phải không?

Smalltalk là một hệ thống hướng đối tượng tuyệt vời trở lại trong ngày. Tại sao không lập trình hướng đối tượng tiếp quản? Vâng, nó có. Nó không giống như Smalltalk. Các ngôn ngữ chính vẫn tiếp tục giống như Smalltalk với C ++, Java, C #, v.v. Thời trang và phong cách thay đổi chậm hơn bất cứ thứ gì, vì vậy khi OO trở thành xu hướng, chúng tôi đã có được nó bằng cách dán các phần của OO vào các ngôn ngữ cũ để nó trông giống như C để nuốt .

Chức năng là cách tương tự. Haskell là một ngôn ngữ chức năng tuyệt vời. Nhưng chúng ta thậm chí còn có nhiều khối lập trình viên chính sử dụng cú pháp giống C ngày nay hơn 20 năm trước. Vì vậy, nó phải trông giống như C. Xong: nhìn vào bất kỳ biểu thức LINQ nào và cho tôi biết nó không hoạt động.


2
Điểm thú vị, nhưng làm thế nào mà các ngôn ngữ chính lại trở nên giống Smalltalk hơn? Ví dụ, C ++, Java và C # không dựa trên việc gửi tin nhắn, mà (tôi tin) là phần quan trọng nhất của mô hình Smalltalk.
Jonathan Sterling

4
Jonathan: Chọn bất kỳ tính năng Smalltalk nào và quan sát mức độ yếu nhất của nó trong C ++ (cũ nhất), OK trong Java và tốt hơn trong C #. Ví dụ: GC (chỉ Java / C #), autoboxing (chỉ sau Java / C #), đóng (chỉ C #) và phản chiếu (hiện trong Java, tốt hơn trong C #). Nếu bạn muốn truyền tin nhắn, hãy xem C # 4's dynamic. Đó là Smalltalk-y nhất trong số các tính năng này, vì vậy tôi không ngạc nhiên khi nó chỉ xuất hiện trong phiên bản mới nhất của ba ngôn ngữ hiện đại nhất này. :-)
Ken

Javascript, python và ruby ​​là những minh họa tốt về cách nó thực sự có
nafg

15

Tôi tin rằng các ngôn ngữ bắt buộc phổ biến hơn đơn giản vì đó là những gì nhiều người đã quen sử dụng. Cả lập trình hàm và mô hình lập trình mệnh lệnh đều tối nghĩa hoặc hàn lâm hơn các mô hình khác. Trong thực tế, họ là bổ sung.

Một người nói rằng mã bắt buộc dễ hiểu hơn mã lập trình chức năng. Điều này chỉ đúng nếu người đọc đã thấy mã bắt buộc, đặc biệt nếu các ví dụ trước là một phần của cùng một "gia đình" (ví dụ: C / C ++, Perl, PHP và Java). Tôi sẽ không tuyên bố rằng nó đúng với bất kỳ ngôn ngữ cấp bách nào ; hãy so sánh Java và Forth, để làm một ví dụ cực đoan.

Đối với một cư dân, tất cả các ngôn ngữ lập trình đều là ngôn ngữ không thể giải mã được, ngoại trừ có thể là các ngôn ngữ dài dòng như Hypertalk và SQL. (Lưu ý, SQL là ngôn ngữ khai báo và / hoặc chức năng và rất phổ biến.)

Nếu ban đầu chúng tôi được đào tạo về ngôn ngữ Lisp-y hoặc Haskell-y, tất cả chúng tôi đều nghĩ rằng ngôn ngữ lập trình chức năng là hoàn toàn bình thường.


"Một người đăng nói rằng mã mệnh lệnh dễ hiểu hơn mã lập trình chức năng. Điều này chỉ đúng nếu người đọc đã thấy mã mệnh lệnh, đặc biệt nếu các ví dụ trước là một phần của cùng một" gia đình "(ví dụ: C / C ++, Perl, PHP và Java). ": Rất đúng (+1): Tôi nhớ mình đã phải bỏ ra bao nhiêu nỗ lực để học Pascal và C khi bắt đầu lập trình. Và thật dễ dàng để đọc Scala, Haskell hoặc Scheme bây giờ khi tôi có một số kinh nghiệm với các ngôn ngữ này.
Giorgio

2
Lý do duy nhất tại sao đôi khi tôi vẫn coi trạng thái có thể thay đổi là hữu ích là nó cung cấp một cách dễ dàng để viết mã nhanh (không sao chép); nhưng lý do cho điều đó có thể là tôi không biết đủ lập trình chức năng và trong 90% tình huống, bạn có thể viết mã chức năng nhanh mà không cần sử dụng trạng thái có thể thay đổi.
Giorgio

3
Một trong những môi trường được sử dụng rộng rãi và lâu đời nhất để tổ chức tính toán là bảng tính; về cơ bản là một môi trường lập trình chức năng với các ô chứ không phải là các biến được đặt tên. Tôi không tin rằng mọi người, nói chung, vốn đã quan niệm các chương trình là một loạt các bước. Các lập trình viên ngập tràn trong các ngôn ngữ mệnh lệnh phổ biến, có thể.
jpnp

14

Bạn đã nhận được đủ câu trả lời mà tôi sẽ chỉ đề cập đến một vài điều mà tôi chưa thấy đề cập đến.

Đầu tiên và (trong suy nghĩ của tôi), các ngôn ngữ thủ tục đã được hưởng lợi rất nhiều từ mức độ phổ biến của chúng. Trong một ví dụ, hầu như bất kỳ ai biết hầu hết các ngôn ngữ thủ tục (hoặc OO) chính thống ở hầu hết mọi mức độ đều có thể đọc hầu hết các ngôn ngữ khác một cách hợp lý. Tôi chủ động tránh làm việc trong Java, C #, Cobol, Fortran hoặc Basic (chỉ một vài ví dụ) nhưng có thể đọc bất kỳ trong số chúng một cách hợp lý - thực tế, gần như là những người sử dụng chúng hàng ngày.

Về mặt chức năng, điều đó ít đúng hơn nhiều . Ví dụ, tôi cũng có thể viết Scheme khá hợp lý, nhưng điều đó ít được sử dụng trong việc đọc Ocaml hoặc Haskell (chỉ cho một vài ví dụ). Ngay cả trong một gia đình duy nhất (ví dụ, Scheme vs., Common Lisp) quen thuộc với một người dường như không dịch gần như tốt cho cả gia đình khác.

Khiếu nại rằng mã chức năng dễ đọc hơn có xu hướng chỉ đúng trong một phạm vi điều kiện hẹp. Đối với những người cực kỳ quen thuộc với ngôn ngữ này, khả năng đọc thực sự tuyệt vời - nhưng đối với mọi người khác, nó thường không có gì tồn tại. Tồi tệ hơn, trong khi sự khác biệt về ngôn ngữ thủ tục phần lớn là cú pháp và do đó tương đối dễ học, sự khác biệt về ngôn ngữ chức năng thường cơ bản hơn nhiều, vì vậy họ yêu cầu nghiên cứu đáng kể để thực sự hiểu (ví dụ, biết Lisp giúp ích rất ít trong việc hiểu Monads).

Điểm quan trọng khác là ý tưởng rằng các chương trình chức năng ngắn hơn các chương trình thủ tục thường dựa trên cú pháp nhiều hơn ngữ nghĩa. Các chương trình được viết bằng Haskell (ví dụ một ví dụ) thường khá ngắn, nhưng chức năng của nó là một phần khá nhỏ trong đó. Một thỏa thuận tuyệt vời nếu chỉ đơn giản là Haskell có một cú pháp tương đối ngắn gọn.

Rất ít ngôn ngữ chức năng thuần túy có thể cạnh tranh tốt với APL về mã nguồn ngắn gọn (mặc dù, công bằng mà nói, APL cũng hỗ trợ tạo các hàm cấp cao hơn, do đó, đó không phải là một sự khác biệt lớn như trong một số trường hợp khác). Ngược lại, Ada và C ++ (cho chỉ là một vài ví dụ) có thể khá cạnh tranh về số lượng các hoạt động cần thiết để thực hiện một nhiệm vụ nhất định, nhưng cú pháp là (ít nhất là thường) đáng kể dài hơn.


Nhận xét tuyệt vời! Tôi đồng ý hết lòng. Tôi thấy hầu hết các ngôn ngữ thủ tục khá dễ đọc và dễ hiểu, mặc dù tôi chỉ là một chuyên gia thực sự trong một vài trong số chúng. Không thể nói như vậy về các ngôn ngữ FP.
Richard Eng

1
Một điểm quan trọng khác là, trong bất kỳ mô hình nhất định nào, bạn tìm thấy một loạt các chuyên môn, từ người mới đến chuyên gia. Mã FP có thể dễ đọc và dễ hiểu đối với các chuyên gia, nhưng các lập trình viên trung gian vẫn có thể đấu tranh. Các chuyên gia thường chiếm một phần rất nhỏ trong cộng đồng FP.
Richard Eng

11

Không cần nhận thức

Tôi nhớ lại câu trả lời của ông chủ cũ Rick Cline khi tôi đưa cho anh ta một bản sao bài giảng Giải thưởng Turing của John Backus mang tên Lập trình có thể được giải phóng khỏi phong cách von Neumann không?

Câu trả lời của ông: "Có lẽ một số người trong chúng ta không muốn được giải phóng khỏi phong cách von Neumann!"


10

Tại sao chưa lập trình chức năng?

Chức năng là tốt hơn cho một số thứ và tồi tệ hơn cho những người khác vì vậy nó sẽ không bao giờ "tiếp quản". Nó đã có mặt khắp nơi trong thế giới thực.

Chương trình không quốc tịch; Không có tác dụng phụ

Chương trình không quốc tịch dễ kiểm tra hơn. Điều này hiện đang được đánh giá cao và thường được khai thác trong công nghiệp.

Đồng thời; Chơi cực kỳ hay với công nghệ đa lõi đang phát triển Các chương trình thường ngắn hơn và trong một số trường hợp dễ đọc hơn Năng suất tăng lên (ví dụ: Erlang)

Bạn đang kết hợp đồng thời và song song.

Đồng thời có thể được thực hiện một cách hiệu quả bằng cách sử dụng giao tiếp các quy trình tuần tự (CSP). Mã bên trong CSP có thể biến đổi trạng thái cục bộ của nó nhưng các thông điệp được gửi giữa chúng phải luôn luôn bất biến.

Lập trình chức năng thuần túy chơi cực kỳ tệ với đa lõi vì nó rất không thân thiện với bộ đệm. Lõi cuối cùng tranh giành bộ nhớ chia sẻ và các chương trình song song không mở rộng.

Tại sao các công ty sử dụng hoặc các chương trình được viết bằng ngôn ngữ chức năng vẫn rất "hiếm"?

Scala thường được coi là một ngôn ngữ chức năng nhưng nó không có nhiều chức năng hơn C #, một trong những ngôn ngữ phổ biến nhất trên thế giới hiện nay.

Tại sao, khi nhìn vào những lợi thế của lập trình chức năng, chúng ta vẫn đang sử dụng các ngôn ngữ lập trình bắt buộc?

Lập trình chức năng thuần túy có rất nhiều nhược điểm nghiêm trọng vì vậy chúng tôi sử dụng các ngôn ngữ chức năng không tinh khiết như Lisp, Scheme, SML, OCaml, Scala và C #.


7

Khi tôi nghĩ về những gì lập trình chức năng có thể mang lại cho các dự án của tôi tại nơi làm việc, tôi luôn bị dẫn theo cùng một lối suy nghĩ:

  1. Để có được những lợi thế đầy đủ của lập trình chức năng, bạn cần sự lười biếng. Vâng, có những ngôn ngữ chức năng nghiêm ngặt, nhưng lợi ích thực sự của lập trình chức năng không tỏa sáng cũng như trong mã nghiêm ngặt. Ví dụ, trong Haskell, thật dễ dàng để tạo một chuỗi các thao tác lười biếng trong danh sách và nối chúng và áp dụng chúng vào danh sách. Ví dụ. op1 $ op2 $ op3 $ op4 $ someList. Tôi biết rằng nó sẽ không xây dựng toàn bộ danh sách và trong nội bộ tôi sẽ chỉ có một vòng lặp tốt đẹp đi qua từng yếu tố một. Điều này cho phép bạn viết mã mô-đun thực sự. Giao diện giữa hai mô-đun có thể liên quan đến việc bàn giao các cấu trúc dữ liệu có khả năng lớn và bạn không cần phải có cấu trúc cư trú.

  2. Nhưng khi bạn có sự lười biếng, việc sử dụng bộ nhớ trở nên khó khăn. Thay đổi cờ trình biên dịch Haskell thường xuyên thay đổi lượng bộ nhớ được sử dụng bởi thuật toán từ O (N) thành O (1), ngoại trừ đôi khi không. Điều này thực sự không được chấp nhận khi bạn có các ứng dụng cần sử dụng tối đa tất cả bộ nhớ khả dụng và nó không tuyệt vời ngay cả đối với các ứng dụng không cần tất cả bộ nhớ.


Lười biếng cũng tương tác ít hơn lý tưởng với gỡ lỗi.
Brian

3
Vì tôi thấy rằng nhiều lỗi tôi theo đuổi trong các ngôn ngữ khác có liên quan đến việc thiếu minh bạch tham chiếu, tôi ít lo lắng hơn về các vấn đề gỡ lỗi, mặc dù đôi khi chúng có thể là một nỗi đau.
sigfpe

6

Hai điều:

  1. Nó chỉ mất thời gian cho dù công nghệ tốt như thế nào. Những ý tưởng đằng sau FP là khoảng 70 năm. Nhưng việc sử dụng chủ đạo của nó trong Kỹ thuật phần mềm (trong các chiến hào, trong công nghiệp) có lẽ ít hơn 10 năm. Yêu cầu các nhà phát triển áp dụng tư duy chủng tộc mới là có thể nhưng chỉ mất thời gian (nhiều, nhiều năm). Ví dụ, OOP thực sự có cách sử dụng chủ đạo vào đầu những năm 1980. Tuy nhiên, nó đã không đạt được ký túc xá cho đến cuối những năm 1990.
  2. Bạn cần mọi người buộc phải đối mặt với sức mạnh của công nghệ trước khi nó thành công lớn . Hiện tại, mọi người đang sử dụng các công cụ không sử dụng song song và mọi thứ hoạt động tốt. Khi các ứng dụng không sử dụng song song trở nên chậm không chịu nổi; sau đó nhiều người sẽ bị buộc phải sử dụng các công cụ song song và FP có thể trở nên phổ biến. Điều này cũng có thể áp dụng cho các thế mạnh khác của FP.

3
FP rất giỏi trong việc tái sử dụng mã. Có lẽ tốt hơn OO. Tôi đã phải đối phó với nó tại nơi làm việc một vài lần, chuyển sang các loại khác nhau, và một hệ thống mới và nó không gây đau đớn.
nlucaroni

@Freddy Rios và @nlucaroni. Tôi viết lại bình luận để giải thích sai.
Phil
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.