Tôi thấy rất nhiều cuộc nói chuyện ở đây về ngôn ngữ chức năng và công cụ. Tại sao bạn lại sử dụng một ngôn ngữ "truyền thống"? Họ làm gì tốt hơn? Họ tệ hơn ở cái gì? Ứng dụng lập trình chức năng lý tưởng là gì?
Câu trả lời:
Các ngôn ngữ chức năng sử dụng một mô hình khác với các ngôn ngữ bắt buộc và hướng đối tượng. Họ sử dụng các chức năng không có tác dụng phụ như một khối xây dựng cơ bản trong ngôn ngữ. Điều này cho phép nhiều thứ và làm cho nhiều thứ trở nên khó khăn hơn (hoặc trong hầu hết các trường hợp khác với những gì mọi người đã quen).
Một trong những lợi thế lớn nhất với lập trình chức năng là thứ tự thực hiện các chức năng không có tác dụng phụ là không quan trọng. Ví dụ, trong Erlang, điều này được sử dụng để cho phép đồng thời một cách rất minh bạch. Và bởi vì các hàm trong các ngôn ngữ chức năng hoạt động rất giống với các hàm toán học, thật dễ dàng để dịch chúng sang các ngôn ngữ chức năng. Trong một số trường hợp, điều này có thể làm cho mã dễ đọc hơn.
Theo truyền thống, một trong những nhược điểm lớn của lập trình chức năng cũng là thiếu tác dụng phụ. Rất khó để viết phần mềm hữu ích mà không có IO, nhưng IO khó thực hiện nếu không có tác dụng phụ trong các chức năng. Vì vậy, hầu hết mọi người không bao giờ nhận được nhiều hơn từ lập trình chức năng hơn là tính toán một đầu ra từ một đầu vào duy nhất. Trong các ngôn ngữ mô hình hỗn hợp hiện đại như F # hoặc Scala, điều này dễ dàng hơn.
Rất nhiều ngôn ngữ hiện đại có các yếu tố từ các ngôn ngữ lập trình chức năng. C # 3.0 có nhiều tính năng lập trình chức năng và bạn cũng có thể lập trình chức năng trong Python. Tôi nghĩ rằng lý do cho sự phổ biến của lập trình chức năng chủ yếu là vì hai lý do: Đồng thời đang trở thành một vấn đề thực sự trong lập trình thông thường bởi vì chúng ta ngày càng có nhiều máy tính đa bộ xử lý; và các ngôn ngữ đang trở nên dễ tiếp cận hơn.
Tôi không nghĩ rằng có bất kỳ câu hỏi nào về cách tiếp cận chức năng để lập trình "bắt kịp", bởi vì nó đã được sử dụng (như một phong cách lập trình) trong khoảng 40 năm. Bất cứ khi nào một lập trình viên OO viết mã sạch ủng hộ các đối tượng bất biến, mã đó sẽ mượn các khái niệm chức năng.
Tuy nhiên, những ngôn ngữ thực thi một phong cách chức năng đang nhận được rất nhiều mực ảo trong những ngày này, và liệu những ngôn ngữ đó sẽ trở nên chiếm ưu thế trong tương lai hay không là một câu hỏi mở. Sự nghi ngờ của tôi là các ngôn ngữ lai, đa mô hình như Scala hoặc OCaml có thể sẽ chiếm ưu thế đối với các ngôn ngữ chức năng "thuần túy" theo cùng cách mà ngôn ngữ OO thuần túy (Smalltalk, Beta, v.v.) đã ảnh hưởng đến lập trình chính thống nhưng vẫn chưa kết thúc lên như các ký hiệu được sử dụng rộng rãi nhất.
Cuối cùng, tôi không thể cưỡng lại việc chỉ ra rằng các bình luận của bạn là FP rất song song với những nhận xét mà tôi đã nghe từ các lập trình viên thủ tục cách đây không nhiều năm:
Cũng giống như giao diện người dùng đồ họa và "mã như một mô hình của doanh nghiệp" là những khái niệm giúp OO được đánh giá cao hơn, tôi tin rằng việc sử dụng song song (đơn giản) tăng cường sẽ giúp nhiều lập trình viên thấy được lợi ích mà phương pháp chức năng mang lại . Nhưng nhiều như chúng ta đã học được trong hơn 50 năm qua tạo nên toàn bộ lịch sử lập trình máy tính kỹ thuật số, tôi nghĩ chúng ta vẫn còn nhiều điều phải học. Hai mươi năm nữa, các lập trình viên sẽ nhìn lại sự kinh ngạc về bản chất nguyên thủy của các công cụ chúng ta hiện đang sử dụng, bao gồm các ngôn ngữ OO và FP phổ biến hiện nay.
Điểm cộng chính đối với tôi là tính song song vốn có của nó, đặc biệt là khi chúng ta đang di chuyển ra xa nhiều MHz hơn và hướng tới ngày càng nhiều lõi.
Tôi không nghĩ nó sẽ trở thành mô hình lập trình tiếp theo và thay thế hoàn toàn các phương thức loại OO, nhưng tôi nghĩ chúng ta sẽ hiểu được rằng chúng ta cần phải viết một số mã bằng ngôn ngữ chức năng hoặc ngôn ngữ mục đích chung của chúng ta sẽ phát triển để bao gồm các cấu trúc chức năng hơn.
Ngay cả khi bạn không bao giờ làm việc trong một ngôn ngữ chức năng một cách chuyên nghiệp, hiểu được lập trình chức năng sẽ giúp bạn trở thành một nhà phát triển tốt hơn. Nó sẽ cung cấp cho bạn một quan điểm mới về mã và lập trình của bạn nói chung.
Tôi nói không có lý do để không học nó.
Tôi nghĩ rằng các ngôn ngữ làm tốt công việc pha trộn phong cách chức năng và mệnh lệnh là thú vị nhất và có nhiều khả năng thành công nhất.
Tôi luôn hoài nghi về điều lớn tiếp theo. Rất nhiều lần Next Big Thing là tai nạn thuần túy của lịch sử, có mặt đúng nơi, đúng thời điểm cho dù công nghệ có tốt hay không. Ví dụ: C ++, Tcl / Tk, Perl. Tất cả các công nghệ thiếu sót, tất cả đều thành công rực rỡ bởi vì chúng được coi là để giải quyết các vấn đề trong ngày hoặc gần giống với các tiêu chuẩn cố thủ, hoặc cả hai. Lập trình chức năng có thể thực sự tuyệt vời, nhưng điều đó không có nghĩa là nó sẽ được thông qua.
Nhưng tôi có thể cho bạn biết lý do tại sao mọi người hào hứng với lập trình chức năng: nhiều, nhiều lập trình viên đã có một loại "trải nghiệm chuyển đổi" trong đó họ phát hiện ra rằng sử dụng ngôn ngữ chức năng giúp họ làm việc hiệu quả gấp đôi (hoặc có thể gấp mười lần năng suất) trong khi sản xuất mã có khả năng phục hồi tốt hơn để thay đổi và có ít lỗi hơn. Những người này nghĩ về lập trình chức năng như một vũ khí bí mật; một ví dụ điển hình cho suy nghĩ này là Beating the A Average của Paul Graham . Oh, và ứng dụng của mình? Ứng dụng web thương mại điện tử.
Từ đầu năm 2006 cũng đã có một số tiếng vang về lập trình chức năng và song song. Vì những người như Simon Peyton Jones đã lo lắng về sự song song và kể từ ít nhất là năm 1984, tôi không nín thở cho đến khi các ngôn ngữ chức năng giải quyết vấn đề đa lõi. Nhưng nó giải thích một số buzz bổ sung ngay bây giờ.
Nhìn chung, các trường đại học Mỹ đang làm một công việc kém dạy lập trình chức năng. Có một lõi hỗ trợ mạnh mẽ cho việc dạy lập trình giới thiệu bằng Scheme và Haskell cũng thích một số hỗ trợ ở đó, nhưng có rất ít cách dạy kỹ thuật nâng cao cho lập trình viên chức năng. Tôi đã dạy một khóa học như vậy tại Harvard và sẽ thực hiện lại vào mùa xuân này tại Tufts. Benjamin Pierce đã dạy một khóa học như vậy tại Penn. Tôi không biết Paul Hudak có làm gì ở Yale không. Các trường đại học châu Âu đang làm một công việc tốt hơn nhiều; ví dụ, lập trình chức năng được nhấn mạnh ở những nơi quan trọng ở Đan Mạch, Hà Lan, Thụy Điển và Vương quốc Anh. Tôi ít có ý thức về những gì đang xảy ra ở Australasia.
Tôi không thấy ai nhắc đến con voi trong phòng ở đây, vì vậy tôi nghĩ nó tùy thuộc vào tôi :)
JavaScript là một ngôn ngữ chức năng. Khi ngày càng có nhiều người làm những điều nâng cao hơn với JS, đặc biệt là tận dụng các điểm tốt hơn của jQuery, Dojo và các khung công tác khác, FP sẽ được giới thiệu bởi cửa sau của nhà phát triển web.
Kết hợp với các bao đóng, FP làm cho mã JS thực sự nhẹ, nhưng vẫn có thể đọc được.
Chúc mừng, PS
Hầu hết các ứng dụng đủ đơn giản để được giải quyết theo cách OO thông thường
Cách OO không phải lúc nào cũng là "bình thường." Tiêu chuẩn của thập kỷ này là khái niệm ngoài lề của thập kỷ trước.
Lập trình hàm là toán. Paul Graham trên Lisp (lập trình chức năng thay thế cho Lisp):
Vì vậy, lời giải thích ngắn gọn về lý do tại sao ngôn ngữ của những năm 1950 này không bị lỗi thời là nó không phải là công nghệ mà là toán học và toán học không trở nên cũ kỹ. Điều đúng đắn để so sánh Lisp không phải là phần cứng của những năm 1950, nhưng, giả sử, thuật toán Quicksort, được phát hiện vào năm 1960 và vẫn là loại mục đích chung nhanh nhất.
Tôi cá là bạn không biết bạn đã lập trình chức năng khi bạn sử dụng:
Lập trình viên trung bình của công ty, ví dụ như hầu hết những người tôi làm việc cùng, sẽ không hiểu điều đó và hầu hết các môi trường làm việc sẽ không cho phép bạn lập trình trong đó
Đó chỉ là vấn đề thời gian. Lập trình viên công ty trung bình của bạn học bất cứ điều gì Big Thing hiện tại. 15 năm trước, họ không hiểu OOP. NẾU FP bắt kịp, "lập trình viên trung bình của công ty" của bạn sẽ làm theo.
Nó không thực sự được dạy ở các trường đại học (hay ngày nay là vậy?)
Khác nhau rất nhiều. Tại trường đại học của tôi, SML là ngôn ngữ đầu tiên mà sinh viên được giới thiệu. Tôi tin rằng MIT dạy LISP như một khóa học năm đầu tiên. Tất nhiên, hai ví dụ này có thể không mang tính đại diện, nhưng tôi tin rằng hầu hết các trường đại học ít nhất cung cấp một số khóa học tùy chọn về FP, ngay cả khi chúng không biến nó thành một phần bắt buộc của chương trình giảng dạy.
Hầu hết các ứng dụng đủ đơn giản để được giải quyết theo cách OO thông thường
Đó thực sự không phải là vấn đề "đủ đơn giản". Một giải pháp sẽ đơn giản hơn (hoặc dễ đọc hơn, mạnh mẽ, thanh lịch, biểu diễn) trong FP? Nhiều thứ "đủ đơn giản để được giải quyết trong Java", nhưng nó vẫn đòi hỏi một lượng mã lớn.
Trong mọi trường hợp, hãy nhớ rằng những người đề xướng FP đã tuyên bố rằng đó là Điều lớn tiếp theo trong nhiều thập kỷ nay. Có lẽ họ đúng, nhưng hãy nhớ rằng họ không biết khi họ đưa ra cùng một yêu cầu 5, 10 hoặc 15 năm trước.
Tuy nhiên, một điều chắc chắn có lợi cho họ, đó là gần đây, C # đã có một bước chuyển biến mạnh mẽ về phía FP, đến mức nó thực sự biến một thế hệ lập trình viên thành lập trình viên FP, mà họ không hề hay biết . Điều đó có thể mở đường cho "cuộc cách mạng" của FP. Có lẽ. ;)
Con người không thể hiểu được sự hoàn hảo và không hoàn hảo của nghệ thuật đã chọn nếu anh ta không thể nhìn thấy giá trị trong các nghệ thuật khác. Theo các quy tắc chỉ cho phép phát triển đến một điểm trong kỹ thuật và sau đó sinh viên và nghệ sĩ phải tìm hiểu thêm và tìm kiếm thêm. Nó có ý nghĩa để nghiên cứu các nghệ thuật khác cũng như những chiến lược.
Ai chưa học được gì nhiều hơn về bản thân bằng cách xem hoạt động của người khác? Để học kiếm học đàn guitar. Để học nắm đấm học thương mại. Chỉ nghiên cứu thanh kiếm sẽ khiến bạn hẹp hòi và không cho phép bạn phát triển ra bên ngoài.
- Miyamoto Musashi, "Một cuốn sách năm chiếc nhẫn"
Một tính năng chính trong ngôn ngữ chức năng là khái niệm về các chức năng hạng nhất. Ý tưởng là bạn có thể truyền các hàm dưới dạng tham số cho các hàm khác và trả về chúng dưới dạng giá trị.
Lập trình chức năng liên quan đến việc viết mã không thay đổi trạng thái. Lý do chính để làm như vậy là để các lệnh gọi liên tiếp đến một hàm sẽ mang lại kết quả tương tự. Bạn có thể viết mã chức năng bằng bất kỳ ngôn ngữ nào hỗ trợ các chức năng hạng nhất, nhưng có một số ngôn ngữ, như Haskell, không cho phép bạn thay đổi trạng thái. Trên thực tế, bạn không được phép tạo ra bất kỳ tác dụng phụ nào (như in ra văn bản) - điều này nghe có vẻ như hoàn toàn vô dụng.
Thay vào đó, Haskell sử dụng một cách tiếp cận khác với IO: monads. Đây là những đối tượng có chứa hoạt động IO mong muốn được thực thi bởi toplevel của trình thông dịch của bạn. Ở bất kỳ cấp độ nào khác, chúng chỉ đơn giản là các đối tượng trong hệ thống.
Những lợi thế nào lập trình chức năng cung cấp? Lập trình chức năng cho phép mã hóa với ít tiềm năng hơn cho các lỗi vì mỗi thành phần được cách ly hoàn toàn. Ngoài ra, sử dụng các hàm đệ quy và hàm hạng nhất cho phép các bằng chứng đơn giản về tính chính xác thường phản ánh cấu trúc của mã.
Tôi không nghĩ rằng hầu hết mọi người thực tế nghĩ rằng lập trình chức năng sẽ bắt kịp (trở thành mô hình chính như OO). Xét cho cùng, hầu hết các vấn đề kinh doanh không phải là các vấn đề toán học đẹp mắt mà là các quy tắc bắt buộc để di chuyển dữ liệu và hiển thị chúng theo nhiều cách khác nhau, điều đó có nghĩa là nó không phù hợp với mô hình lập trình chức năng thuần túy (đường cong học tập của đơn vị vượt xa OO.)
OTOH, lập trình chức năng là những gì làm cho lập trình thú vị. Nó khiến bạn đánh giá cao vẻ đẹp vốn có, vượt thời gian của những biểu hiện cô đọng của toán học cơ bản của vũ trụ. Mọi người nói rằng học lập trình chức năng sẽ giúp bạn trở thành một lập trình viên tốt hơn. Điều này tất nhiên là rất chủ quan. Cá nhân tôi cũng không nghĩ điều đó hoàn toàn đúng.
Nó làm cho bạn trở thành một chúng sinh tốt hơn.
Tôi phải dày đặc, nhưng tôi vẫn không hiểu. Có bất kỳ ví dụ thực tế nào về ứng dụng nhỏ được viết bằng ngôn ngữ chức năng như F # nơi bạn có thể xem mã nguồn và xem cách thức và lý do tại sao nên sử dụng cách tiếp cận như vậy tốt hơn là, nói, C #?
Tôi đã chỉ ra rằng mọi thứ bạn đã nói về các ngôn ngữ chức năng, hầu hết mọi người đều nói về các ngôn ngữ hướng đối tượng khoảng 20 năm trước. Trước đó, rất phổ biến khi nghe về OO:
* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways
Thay đổi phải đến từ một nơi nào đó. Một thay đổi có ý nghĩa và quan trọng sẽ khiến chính nó xảy ra bất kể mọi người được đào tạo về các công nghệ trước đó có cho rằng thay đổi là không cần thiết hay không. Bạn có nghĩ rằng sự thay đổi thành OO là tốt mặc dù tất cả những người chống lại nó vào thời điểm đó?
F # có thể bắt kịp bởi vì Microsoft đang đẩy nó.
Chuyên nghiệp:
Contra:
Vì vậy, tôi cho 50:50 cơ hội để F # trở nên quan trọng. Các ngôn ngữ chức năng khác sẽ không làm cho nó trong tương lai gần.
Tôi nghĩ một lý do là một số người cảm thấy rằng phần quan trọng nhất của việc một ngôn ngữ sẽ được chấp nhận là ngôn ngữ đó tốt như thế nào . Thật không may, mọi thứ hiếm khi đơn giản như vậy. Ví dụ, tôi sẽ lập luận rằng yếu tố lớn nhất đằng sau sự chấp nhận của Python không phải là ngôn ngữ (mặc dù đó là khá quan trọng). Lý do lớn nhất khiến Python trở nên phổ biến là thư viện tiêu chuẩn khổng lồ và cộng đồng thư viện bên thứ 3 thậm chí còn lớn hơn.
Các ngôn ngữ như Clojure hoặc F # có thể là ngoại lệ đối với quy tắc này vì chúng được xây dựng dựa trên JVM / CLR. Kết quả là, tôi không có câu trả lời cho họ.
Hầu hết các ứng dụng có thể được giải quyết trong [chèn ngôn ngữ yêu thích của bạn, mô hình, v.v. vào đây].
Mặc dù, điều này là đúng, các công cụ khác nhau có thể được sử dụng để giải quyết các vấn đề khác nhau. Chức năng chỉ cho phép một sự trừu tượng hóa mức cao (cao hơn?) Khác cho phép thực hiện công việc của chúng ta hiệu quả hơn khi được sử dụng đúng cách.
Dường như với tôi rằng những người chưa bao giờ học Lisp hoặc Scheme khi còn là sinh viên đang khám phá ra nó. Cũng như rất nhiều thứ trong lĩnh vực này có xu hướng cường điệu và tạo ra những kỳ vọng cao ...
Nó sẽ qua.
Lập trình chức năng là tuyệt vời. Tuy nhiên, nó sẽ không chiếm lĩnh thế giới. C, C ++, Java, C #, v.v. vẫn sẽ xuất hiện.
Điều gì sẽ đến từ điều này tôi nghĩ là khả năng đa ngôn ngữ nhiều hơn - ví dụ như triển khai mọi thứ bằng ngôn ngữ chức năng và sau đó cấp quyền truy cập vào nội dung đó bằng các ngôn ngữ khác.
Khi đọc "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" của Tim Sweeney, Epic Games, suy nghĩ đầu tiên của tôi là - Tôi đã học Haskell.
Mọi thứ đã được di chuyển theo một hướng chức năng trong một thời gian. Hai đứa trẻ mới mẻ trong vài năm qua, Ruby và Python, gần như hoàn toàn gần gũi với các ngôn ngữ chức năng hơn những gì xuất hiện trước chúng - đến nỗi một số Lispers đã bắt đầu hỗ trợ một hoặc hai thứ khác là "đủ gần".
Và với phần cứng song song ồ ạt gây áp lực tiến hóa lên tất cả mọi người - và các ngôn ngữ chức năng là nơi tốt nhất để đối phó với các thay đổi - đó không phải là một bước nhảy vọt như đã từng nghĩ rằng Haskell hoặc F # sẽ là điều lớn tiếp theo.
Bạn đã theo dõi sự phát triển của ngôn ngữ lập trình gần đây? Mỗi bản phát hành mới của tất cả các ngôn ngữ lập trình chính thống dường như mượn ngày càng nhiều tính năng từ lập trình chức năng.
Đóng cửa, chức năng ẩn danh, chuyển và trả lại các chức năng như các giá trị từng là các tính năng kỳ lạ chỉ được biết đến với tin tặc Lisp và ML. Nhưng dần dần, C #, Delphi, Python, Perl, Javascript, đã thêm hỗ trợ cho việc đóng cửa. Không thể có bất kỳ ngôn ngữ sắp tới nào được thực hiện nghiêm túc mà không đóng cửa.
Một số ngôn ngữ, đặc biệt là Python, C # và Ruby có hỗ trợ riêng cho việc hiểu danh sách và trình tạo danh sách.
ML đã đi tiên phong trong lập trình chung vào năm 1973, nhưng hỗ trợ cho thuốc generic ("đa hình tham số") chỉ trở thành một tiêu chuẩn công nghiệp trong 5 năm gần đây. Nếu tôi nhớ chính xác, Fortran đã hỗ trợ thuốc generic vào năm 2003, tiếp theo là Java 2004, C # năm 2005, Delphi năm 2008 (Tôi biết C ++ đã hỗ trợ các mẫu từ năm 1979, nhưng 90% các cuộc thảo luận về STL của C ++ bắt đầu với "ở đây có quỷ" .)
Điều gì làm cho các tính năng này hấp dẫn các lập trình viên? Nó rõ ràng rõ ràng: nó giúp các lập trình viên viết mã ngắn hơn . Tất cả các ngôn ngữ trong tương lai sẽ hỗ trợ - ở mức tối thiểu - đóng cửa nếu họ muốn duy trì tính cạnh tranh. Về mặt này, lập trình chức năng đã có trong dòng chính.
Hầu hết các ứng dụng đủ đơn giản để được giải quyết theo cách OO thông thường
Ai nói không thể sử dụng lập trình chức năng cho những điều đơn giản? Không phải mọi chương trình chức năng đều cần phải là trình biên dịch, định lý định lý hoặc chuyển mạch viễn thông song song ồ ạt. Tôi thường xuyên sử dụng F # cho các kịch bản bỏ đi ad hoc ngoài các dự án phức tạp hơn của tôi.
Nó gây chú ý bởi vì đây là công cụ tốt nhất để kiểm soát sự phức tạp. Xem:
- slide 109-116 của Simon Peyton-Jones nói "A Taste of Haskell"
- "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" của Tim Sweeney
Tôi đồng ý với điểm đầu tiên, nhưng thời gian thay đổi. Các tập đoàn sẽ trả lời, ngay cả khi họ là người chấp nhận muộn, nếu họ thấy rằng có một lợi thế cần có. Cuộc sống thật năng động.
Họ đã dạy Haskell và ML tại Stanford vào cuối những năm 90. Tôi chắc chắn rằng những nơi như Carnegie Mellon, MIT, Stanford và các trường tốt khác đang giới thiệu nó cho sinh viên.
Tôi đồng ý rằng hầu hết các ứng dụng "phơi bày cơ sở dữ liệu quan hệ trên web" sẽ tiếp tục trong thời gian dài. Java EE, .NET, RoR và PHP đã phát triển một số giải pháp khá tốt cho vấn đề đó.
Bạn đã đánh vào một điều quan trọng: Đó có thể là vấn đề không thể giải quyết dễ dàng bằng các biện pháp khác sẽ thúc đẩy lập trình chức năng. Đó sẽ là gì?
Phần cứng đa lõi và điện toán đám mây khổng lồ sẽ đẩy chúng theo?
Bởi vì FP có lợi ích đáng kể về năng suất, độ tin cậy và khả năng bảo trì. Nhiều lõi có thể là một ứng dụng sát thủ cuối cùng đã khiến các tập đoàn lớn chuyển đổi mặc dù khối lượng lớn mã di sản. Ngoài ra, ngay cả các ngôn ngữ thương mại lớn như C # cũng mang một hương vị chức năng riêng biệt do lo ngại nhiều lõi - đơn giản là tác dụng phụ không phù hợp với sự tương tranh và song song.
Tôi không đồng ý rằng các lập trình viên "bình thường" sẽ không hiểu điều đó. Họ sẽ, giống như cuối cùng họ đã hiểu OOP (điều này cũng bí ẩn và kỳ lạ, nếu không muốn nói là như vậy).
Ngoài ra, hầu hết các trường đại học đều dạy FP, nhiều người thậm chí còn dạy nó như khóa học lập trình đầu tiên.
Wow - đây là một cuộc thảo luận thú vị. Suy nghĩ của riêng tôi về điều này:
FP làm cho một số tác vụ tương đối đơn giản (so với các ngôn ngữ không có FP). Không có ngôn ngữ-FP nào đã bắt đầu lấy ý tưởng từ FP, vì vậy tôi nghi ngờ rằng xu hướng này sẽ tiếp tục và chúng ta sẽ thấy nhiều sự hợp nhất sẽ giúp mọi người thực hiện bước nhảy vọt lên FP dễ dàng hơn.
Tôi không biết liệu nó có bắt kịp hay không, nhưng từ các cuộc điều tra của tôi, một ngôn ngữ chức năng gần như chắc chắn đáng để học hỏi và sẽ giúp bạn trở thành một lập trình viên tốt hơn. Chỉ cần hiểu tính minh bạch tham chiếu làm cho rất nhiều quyết định thiết kế trở nên dễ dàng hơn nhiều - và các chương trình kết quả dễ dàng hơn nhiều để lý do. Về cơ bản, nếu bạn gặp phải một vấn đề, thì nó có xu hướng chỉ là vấn đề với đầu ra của một hàm, chứ không phải là một vấn đề với trạng thái không nhất quán, có thể do bất kỳ trong số hàng trăm lớp / phương thức / hàm gây ra trong một ngôn ngữ khác biệt với tác dụng phụ.
Bản chất không trạng thái của bản đồ FP tự nhiên hơn với bản chất không trạng thái của web và do đó, các ngôn ngữ chức năng cho vay dễ dàng hơn đối với các ứng dụng web RESTFUL thanh lịch hơn. Tương phản với các khung công tác JAVA và .NET cần sử dụng các HACKS xấu xí khủng khiếp như các phím VIEWSTATE và SESSION để duy trì trạng thái ứng dụng và duy trì sự trừu tượng (đôi khi khá rò rỉ) của ngôn ngữ mệnh lệnh trạng thái, trên nền tảng chức năng không trạng thái như trên web.
Ngoài ra, ứng dụng của bạn càng không trạng thái, nó càng dễ dàng cho vay để xử lý song song. Rất quan trọng cho web, nếu trang web của bạn trở nên phổ biến. Không phải lúc nào cũng đơn giản chỉ cần thêm nhiều phần cứng vào một trang web để có hiệu suất tốt hơn.
Quan điểm của tôi là bây giờ họ sẽ nắm bắt được rằng Microsoft đã đẩy nó đi xa hơn vào dòng chính. Đối với tôi, nó hấp dẫn bởi vì những gì nó có thể làm cho chúng tôi, bởi vì đó là một thách thức mới và vì những cơ hội việc làm mà nó phẫn nộ cho tương lai.
Khi đã thành thạo, nó sẽ là một công cụ khác để tiếp tục giúp chúng ta làm việc hiệu quả hơn khi là lập trình viên.
Một điểm bị bỏ lỡ trong cuộc thảo luận là các hệ thống loại tốt nhất được tìm thấy trong các ngôn ngữ FP đương đại. Hơn nữa, trình biên dịch có thể tự động suy ra tất cả (hoặc ít nhất là) các loại.
Điều thú vị là người ta dành một nửa thời gian để viết tên loại khi lập trình Java, nhưng Java vẫn không phải là loại an toàn. Mặc dù bạn không bao giờ có thể viết các loại trong chương trình Haskell (ngoại trừ dưới dạng một loại tài liệu được kiểm tra trình biên dịch) và mã này là loại an toàn 100%.
Ngoài các câu trả lời khác, việc đưa ra giải pháp theo thuật ngữ chức năng thuần túy buộc người ta phải hiểu vấn đề tốt hơn. Ngược lại, suy nghĩ theo phong cách chức năng sẽ phát triển tốt hơn * kỹ năng giải quyết vấn đề.
* Hoặc vì mô hình chức năng tốt hơn hoặc bởi vì nó sẽ đủ khả năng cho một góc tấn công bổ sung.