Lập trình chức năng ngày càng tăng?

Gần đây tôi đã nhận thấy rằng các ngôn ngữ lập trình chức năng đang trở nên phổ biến . Gần đây tôi đã thấy cách Tiobe Index cho thấy sự phổ biến của họ so với năm ngoái mặc dù hầu hết trong số họ thậm chí không đạt được 50 ngôn ngữ phổ biến nhất theo chỉ số này.

Và điều này đã xảy ra trong một thời gian khá dài. Lập trình hàm đơn giản là không trở nên phổ biến như các mô hình khác (tức là lập trình hướng đối tượng).

Tuy nhiên, tôi đã thấy sự quan tâm trở lại đối với sức mạnh của lập trình chức năng, và bây giờ, đa lõi ngày càng phổ biến hơn, các nhà phát triển đã bắt đầu quan tâm đến các mô hình đồng thời khác đã được khám phá trước đây bởi các ngôn ngữ như Haskell và Erlang.

Tôi thấy rất quan tâm đến thực tế là mặc dù họ không có sự chấp nhận của cộng đồng đáng kể, ngày càng có nhiều ngôn ngữ thuộc loại này tiếp tục xuất hiện. Clojure (2007), Scala (2003), F # (2002) chỉ là ba ví dụ của thập kỷ gần đây.

Bản thân tôi đã đầu tư thời gian để học Haskell và Scala. Và tôi tìm thấy tiềm năng lớn trong mô hình mà đối với tôi là mới mặc dù đã ở ngoài đó quá lâu.

Và tất nhiên, câu hỏi lớn nhất của tôi là liệu có ai trong số này sẽ trở nên đủ phổ biến để xem xét đưa bất kỳ nỗ lực nào vào họ hay không, nhưng đây là câu hỏi mà ngay cả Mandrake cũng không thể trả lời, mặc dù tất cả những người ồn ào đang làm về họ.

Điều tôi muốn hỏi là:

• Trong trường hợp nào tôi nên xem xét một ngôn ngữ lập trình chức năng phù hợp hơn để thực hiện một nhiệm vụ nhất định? Bên cạnh vấn đề đa lõi phổ biến gần đây của lập trình song song.
• Nếu tôi quyết định chuyển sang một ngôn ngữ lập trình chức năng mà bạn sẽ coi là những cạm bẫy lớn nhất mà tôi sẽ phải đối mặt? (Bên cạnh thay đổi mô hình và khó đánh giá hiệu suất do đánh giá lười biếng).
• Với rất nhiều ngôn ngữ lập trình chức năng ngoài kia, làm thế nào bạn chọn một ngôn ngữ phù hợp hơn với nhu cầu của bạn?

Bất kỳ khuyến nghị cho nghiên cứu tiếp theo sẽ được chào đón nhiều hơn.

Tôi đã tìm kiếm trên mạng các ý kiến, và có vẻ như tất cả sự phổ biến đổi mới này xuất phát từ ý tưởng rằng bây giờ chúng ta sắp sửa vượt qua Luật Moore và các ngôn ngữ lập trình chức năng sẽ đến và cứu chúng ta một cách anh hùng. Nhưng nếu đây là trường hợp, tôi sẽ nói có nhiều xác suất của các ngôn ngữ phổ biến hiện có thích ứng với mô hình.

Một số bạn, với nhiều kinh nghiệm làm việc mỗi ngày với các ngôn ngữ này có lẽ, có thể cung cấp cái nhìn sâu sắc hơn về chủ đề này. Tất cả các ý kiến ​​của bạn sẽ được đánh giá tốt hơn và xem xét cẩn thận.

Cảm ơn trước!

Trong trường hợp nào tôi nên xem xét một ngôn ngữ lập trình chức năng phù hợp hơn để thực hiện một nhiệm vụ nhất định? Bên cạnh vấn đề đa lõi phổ biến gần đây của lập trình song song.

Bất cứ điều gì liên quan đến việc tạo chuỗi các yếu tố dữ liệu dẫn xuất bằng cách sử dụng một số bước chuyển đổi.

Về cơ bản, "vấn đề bảng tính". Bạn có một số dữ liệu ban đầu và tập hợp các tính toán theo từng hàng để áp dụng cho dữ liệu đó.

Các ứng dụng sản xuất của chúng tôi thực hiện một số tóm tắt thống kê dữ liệu; Đây là tất cả các cách tiếp cận tốt nhất về chức năng.

Một điều phổ biến chúng tôi làm là hợp nhất giữa ba bộ dữ liệu quái dị. Tương tự như tham gia SQL, nhưng không khái quát. Tiếp theo là một số tính toán của dữ liệu dẫn xuất. Đây là tất cả chỉ là biến đổi chức năng.

Ứng dụng này được viết bằng Python, nhưng được viết theo kiểu chức năng sử dụng các hàm tạo và các bộ dữ liệu có tên bất biến. Đây là một thành phần của các chức năng cấp thấp hơn.

Đây là một ví dụ cụ thể của một thành phần chức năng.

for line in ( l.split(":") for l in ( l.strip() for l in someFile ) ):
    print line[0], line[3]

Đây là một cách mà lập trình chức năng ảnh hưởng đến các ngôn ngữ như Python.

Đôi khi loại điều này được viết là:

cleaned = ( l.strip() for l in someFile )
split = ( l.split(":") for l in cleaned )
for line in split:
     print line[0], line[3]

Nếu tôi quyết định chuyển sang một ngôn ngữ lập trình chức năng mà bạn cho là những cạm bẫy lớn nhất mà tôi sẽ phải đối mặt? (Bên cạnh thay đổi mô hình và khó đánh giá hiệu suất do đánh giá lười biếng).

Đối tượng bất biến là rào cản khó khăn nhất.

Thông thường, bạn sẽ kết thúc việc tính toán các giá trị tạo ra các đối tượng mới thay vì cập nhật các đối tượng hiện có. Ý tưởng rằng đó là một thuộc tính có thể thay đổi của một đối tượng là một thói quen tinh thần khó phá vỡ.

Một thuộc tính hoặc hàm phương thức dẫn xuất là một cách tiếp cận tốt hơn. Đối tượng nhà nước là một thói quen khó phá vỡ.

Với rất nhiều ngôn ngữ lập trình chức năng ngoài kia, làm thế nào bạn chọn một ngôn ngữ phù hợp hơn với nhu cầu của bạn?

Nó không quan trọng lúc đầu. Chọn bất kỳ ngôn ngữ để học. Khi bạn biết điều gì đó, bạn đang ở trong một vị trí cân nhắc chọn một thứ khác để phù hợp hơn với nhu cầu của bạn.

Tôi đã đọc trên Haskell chỉ để hiểu những điều Python thiếu.

"Chức năng" là một loạt các tính năng khác nhau, mỗi tính năng đều hữu ích độc lập và tôi thấy nó hữu ích hơn khi xem xét từng tính năng.

Bất biến

Bây giờ tôi đã quen với nó, bất cứ khi nào tôi có thể thoát khỏi việc trả lại một kết quả không thay đổi, tôi luôn cố gắng làm điều đó, ngay cả trong một chương trình hướng đối tượng. Lý do về chương trình sẽ dễ dàng hơn nếu bạn có dữ liệu loại giá trị. Thông thường bạn cần khả năng biến đổi cho những thứ như GUI và tắc nghẽn hiệu suất. Các thực thể của tôi (sử dụng NHibernate) cũng có thể thay đổi (điều này hợp lý vì chúng mô hình hóa dữ liệu được lưu trữ trong cơ sở dữ liệu).

Chức năng như các loại hạng nhất

Bất cứ điều gì bạn muốn gọi nó, đi qua các đại biểu, hành động hoặc chức năng, là một cách thực sự tiện dụng để giải quyết cả một lớp các vấn đề trong thế giới thực, như "lỗ hổng trong mô hình giữa". Tôi cũng thấy rằng việc truyền một đại biểu, hành động hoặc chức năng cho một đối tượng sẽ sạch hơn so với việc lớp đó khai báo một sự kiện và nối sự kiện đó (giả sử thông thường chỉ có một "người nghe"). Khi bạn biết có một người nghe, thì hành động gọi lại có thể được chuyển qua dưới dạng tham số hàm tạo (và được lưu trữ trong một thành viên không thay đổi!)

Có thể soạn thảo các hàm (ví dụ, biến Action<T>thành một Actioncũng khá hữu ích trong một số tình huống.

Chúng ta cũng nên lưu ý cú pháp Lambda ở đây, bởi vì bạn chỉ nhận được cú pháp Lambda khi bạn quảng bá các hàm lên các loại hạng nhất. Cú pháp Lambda có thể rất biểu cảm và súc tích.

Đơn nguyên

Phải thừa nhận rằng đây là điểm yếu của tôi, nhưng sự hiểu biết của tôi là quy trình tính toán trong F #, chẳng hạn như asyncquy trình công việc, là một đơn nguyên. Đây là một cấu trúc tinh tế nhưng rất mạnh mẽ. Nó mạnh mẽ như yieldtừ khóa được sử dụng để tạo IEnumerablecác lớp trong C #. Về cơ bản, nó đang xây dựng một bộ máy trạng thái cho bạn dưới vỏ bọc, nhưng logic của bạn có vẻ tuyến tính.

Đánh giá và đệ quy lười biếng

Tôi kết hợp chúng lại với nhau vì trong khi chúng luôn được coi là các tính năng của lập trình chức năng, chúng đã nhanh chóng chuyển sang các ngôn ngữ không bắt buộc đến mức khó có thể gọi chúng là chức năng nữa.

Biểu thức S

Tôi đoán tôi không chắc chắn nên đặt cái này ở đâu, nhưng khả năng coi mã chưa được biên dịch là một đối tượng (và kiểm tra / sửa đổi nó), chẳng hạn như Lisp S-Expressions, hoặc LINQ Expressions, theo một số cách, công cụ mạnh nhất của lập trình chức năng. Hầu hết các giao diện "thông thạo" và DSL mới, sử dụng kết hợp cú pháp lambda và Biểu thức LINQ để tạo một số API rất súc tích. Chưa kể Linq2Sql / Linq2Nhibernate nơi mã C # của bạn được "thực thi" một cách kỳ diệu dưới dạng SQL thay vì mã C #.

Đó là câu trả lời dài cho phần đầu tiên của câu hỏi của bạn ... bây giờ ...

Nếu tôi quyết định chuyển sang một ngôn ngữ lập trình chức năng mà bạn cho là những cạm bẫy lớn nhất mà tôi sẽ phải đối mặt? (Bên cạnh thay đổi mô hình và khó đánh giá hiệu suất do đánh giá lười biếng).

Cạm bẫy lớn nhất mà tôi gặp phải là cố gắng tìm ra ranh giới giữa việc sử dụng các giải pháp chức năng so với các giải pháp bắt buộc. Tuy nhiên, sau khi thử cả hai cách tiếp cận một vài lần, bạn bắt đầu cảm thấy nó sẽ hoạt động tốt hơn.

Với rất nhiều ngôn ngữ lập trình chức năng ngoài kia, làm thế nào bạn chọn một ngôn ngữ phù hợp hơn với nhu cầu của bạn?

Nếu bạn quen thuộc với .NET, tôi đánh giá cao F #. Mặt khác, nếu bạn quen thuộc hơn với JVM, luôn có Clojure . Nếu bạn học nhiều hơn thực tế, thì tôi sẽ đi với Common Lisp hoặc Scheme. Nếu bạn đã biết Python, tôi tin rằng có rất nhiều cấu trúc chức năng đã có sẵn ở đó.

Và điều này đã xảy ra trong một thời gian khá dài. Lập trình hàm đơn giản là không trở nên phổ biến như các mô hình khác (tức là lập trình hướng đối tượng).

Điều này đúng nếu bạn tính các chương trình được phát triển bởi các lập trình viên chuyên nghiệp (hoặc ít nhất là mọi người thấy mình như vậy). Nếu bạn trải rộng mạng lưới của mình để bao gồm các chương trình được phát triển bởi những người không tự coi mình như vậy, thì FP (hoặc ít nhất là lập trình theo kiểu chức năng) khá gần với OO (Excel, Mathicala, Matlab, R ... thậm chí là 'JavaScript' hiện đại ' ).

Trong trường hợp nào tôi nên xem xét một ngôn ngữ lập trình chức năng phù hợp hơn để thực hiện một nhiệm vụ nhất định? Bên cạnh vấn đề đa lõi phổ biến gần đây của lập trình song song.

Ý kiến ​​cá nhân của tôi là đa lõi không phải là tính năng sát thủ của FP (ít nhất là cho đến khi trình biên dịch Haskell, Scala, Clojure, F # giải quyết vấn đề cục bộ bộ đệm). Tính năng kẻ giết người là map, filter, foldvà bạn bè mà cho phép một biểu thức ngắn gọn hơn của một nhóm lớn các thuật toán. Điều này được kết hợp bởi các ngôn ngữ FP có cú pháp ngắn gọn hơn so với hầu hết các đối tác OO phổ biến.

Ngoài ra, việc gần gũi hơn với mô hình quan hệ giúp giảm sự không phù hợp trở kháng với RDBMS ... điều đó - một lần nữa - ít nhất là đối với những người không lập trình - rất hay.

Ngoài ra, khi bạn đặc biệt khó đáp ứng các yêu cầu 'chính xác' - ở dạng khó kiểm tra (phổ biến trong điện toán khoa học / phân tích dữ liệu lớn trong đó mục tiêu là nhận được trước đó và kết quả không thể xác định như vậy) FP có thể cung cấp lợi thế.

Nếu tôi quyết định chuyển sang một ngôn ngữ lập trình chức năng mà bạn cho là những cạm bẫy lớn nhất mà tôi sẽ phải đối mặt?

• thiếu hỗ trợ công cụ (F # và một số Lisps là ngoại lệ, Scala đang trên đường)
• khó hơn để vắt kiệt chút hiệu năng cuối cùng từ phần cứng của bạn
• các cộng đồng thường tập trung vào các vấn đề khác nhau so với những vấn đề mà một nhóm lớn các dự án phát triển phần mềm thương mại phải đối mặt
• rất ít nhà phát triển có kinh nghiệm trong việc sử dụng FP trong môi trường công nghiệp và nếu bạn có thể tìm thấy họ, bạn có thể phải cạnh tranh với mức lương và lợi ích mà ngành tài chính có thể mang lại
• phong cách chức năng của lập trình có xu hướng khó gỡ lỗi hơn; tức là quan sát giữa các kết quả trong một chuỗi dài các hàm tổng hợp thường không thể thực hiện được trong hầu hết (tất cả?) trình gỡ lỗi

Với rất nhiều ngôn ngữ lập trình chức năng ngoài kia, làm thế nào bạn chọn một ngôn ngữ phù hợp hơn với nhu cầu của bạn?

• Có bao nhiêu vấn đề của bạn có thể được giải quyết bằng cách thoát khỏi các thư viện / khung công tác trên nền tảng nào (ví dụ JVM hoặc .Net) có bao nhiêu vấn đề hoàn toàn mới? Có cấu trúc ngôn ngữ có khả năng thể hiện trực tiếp những vấn đề này không?

• Bạn cần bao nhiêu kiểm soát mức độ thấp đối với hiệu suất không gian và thời gian của ứng dụng của bạn?

• Làm thế nào nghiêm ngặt là yêu cầu "chính xác" của bạn?

• Bạn có đủ khả năng để đào tạo lại các nhà phát triển và / hoặc cạnh tranh với những lợi ích được cung cấp bởi một số ngách có lợi nhuận cao trong phát triển SW không?

Nếu tôi quyết định chuyển sang một ngôn ngữ lập trình chức năng mà bạn cho là những cạm bẫy lớn nhất mà tôi sẽ phải đối mặt? (Bên cạnh thay đổi mô hình và khó đánh giá hiệu suất do đánh giá lười biếng).

Giả sử bạn là nhà phát triển C ++ / C # / Java trong ngành ...

Hãy chuẩn bị cho những đồng nghiệp gắt gỏng không muốn học bất cứ điều gì. Hãy chuẩn bị cho những ông chủ có mái tóc nhọn áp đặt những lựa chọn ngôn ngữ tồi "bởi vì họ đã từng là một lập trình viên". Hãy chuẩn bị cho các học giả quan trọng trên các diễn đàn bảo trợ bạn về đơn chất. Hãy chuẩn bị cho các cuộc chiến ngôn ngữ bất tận vì Scala thậm chí không có loại bỏ cuộc gọi đuôi và Clojure thực sự yêu cầu bàn đạp chân cho tất cả các dấu ngoặc và đừng bắt tôi bắt đầu trên Erlang.

Nếu bạn là một lập trình viên web thì cạm bẫy lớn nhất có lẽ sẽ là mái tóc của bạn.

Với rất nhiều ngôn ngữ lập trình chức năng ngoài kia, làm thế nào bạn chọn một ngôn ngữ phù hợp hơn với nhu cầu của bạn?

Tôi sẽ bắt đầu với nền tảng:

• OCaml là tuyệt vời trên Linux và khủng khiếp trên Windows.
• F # là tuyệt vời trên Windows và khủng khiếp trên Linux.
• Scala và Clojure là tuyệt vời trên JVM.

Đối với một quan điểm (thừa nhận thiên vị) về câu hỏi này, bạn có thể xem blog của Bob Harper, Loại Hiện sinh . Carnegie Mellon gần đây đã làm lại chương trình giảng dạy CS của họ để dạy lập trình chức năng trước tiên, với các mô hình khác chỉ được dạy một khi nền tảng vững chắc về lập trình chức năng đã được thiết lập, và Harper đang thổi phồng khi chương trình giảng dạy mới được triển khai trong thực tế .

Harper là một trong những nhà phát triển chính của ngôn ngữ lập trình Standard ML, vì vậy thật công bằng khi nói ý kiến ​​của riêng anh ấy về vấn đề này có thể được đoán trước, và anh ấy chắc chắn không ngại những tuyên bố gây tranh cãi khi tranh luận về vị trí này, nhưng anh ấy đưa ra trường hợp của anh ấy tốt

Trong trường hợp nào tôi nên xem xét một ngôn ngữ lập trình chức năng phù hợp hơn để thực hiện một nhiệm vụ nhất định? Bên cạnh vấn đề đa lõi phổ biến gần đây của lập trình song song.

Không có công thức kỳ diệu nào cho bạn biết khi nào nên sử dụng lập trình chức năng. Nó không giống như lập trình hướng đối tượng phù hợp với các tình huống lập trình hiện tại của chúng tôi. Nó chỉ là một cách khác để cấu trúc các chương trình theo thuật ngữ khác.

Nếu tôi quyết định chuyển sang một ngôn ngữ lập trình chức năng mà bạn cho là những cạm bẫy lớn nhất mà tôi sẽ phải đối mặt? (Bên cạnh thay đổi mô hình và khó đánh giá hiệu suất do đánh giá lười biếng).

Lập trình chức năng không có gì để làm với sự lười biếng. ML và OCaml là các ngôn ngữ chức năng và nghiêm ngặt. Rào cản lớn nhất mà bạn sẽ phải đối mặt là cấu trúc mọi thứ theo các giá trị bất biến và quấn đầu xung quanh bất kỳ sự trừu tượng nào được sử dụng trong hệ thống loại cho các tác dụng phụ. Các ngôn ngữ chức năng phù hợp hơn để tối ưu hóa vì thực tế là chúng tạo ra các hiệu ứng phụ rất rõ ràng trong hệ thống loại. Haskell sử dụng các đơn nguyên nhưng có những cách tiếp cận khác để sử dụng hiệu ứng trong các ngôn ngữ chức năng thuần túy. Clean có các loại duy nhất và một số ngôn ngữ khác đang phát triển có những thứ khác.

Với rất nhiều ngôn ngữ lập trình chức năng ngoài kia, làm thế nào bạn chọn một ngôn ngữ phù hợp hơn với nhu cầu của bạn?

Trong số các ngôn ngữ lập trình tôi biết tôi chỉ nói Haskell và Clean có thể được gọi là ngôn ngữ chức năng. Tất cả những cái khác cho phép tác dụng phụ mà không làm cho những hiệu ứng đó rõ ràng trong hệ thống loại. Vì vậy, nếu bạn sẽ dành thời gian để học lập trình chức năng thì Haskell có lẽ là người duy nhất phù hợp với dự luật. Tất cả những cái khác mà tôi biết, Erlang, Scala, Clojure, v.v. chỉ cung cấp các khái niệm trừu tượng về chức năng trên một ngôn ngữ bắt buộc. Vì vậy, nếu bạn muốn tiếp cận mô hình chức năng theo bit thì tôi khuyên bạn nên Scala hoặc Erlang và nếu bạn muốn giải quyết mọi thứ ngay lập tức và có thể từ bỏ trong thất vọng thì bạn nên đi với Haskell.

Tôi cho rằng sự gia tăng hiện tại của các ngôn ngữ chức năng là thực tế rằng chúng là lý tưởng cho tính toán song song. Ví dụ, toàn bộ ý tưởng về giảm bản đồ dựa trên mô hình chức năng. Và không còn nghi ngờ gì nữa, tính toán song song sẽ tăng lên, vì rõ ràng việc mở rộng quy mô hiện nay dễ dàng hơn và rẻ hơn so với mở rộng quy mô. Ngay cả trên CPU thị trường tiêu dùng cũng nhận được nhiều lõi hơn, không nhiều GHz hơn.

EDIT: vì nó không rõ ràng cho tất cả.

Trong lập trình hàm thuần túy, một hàm lấy đầu vào, tạo đầu ra và không có tác dụng phụ. Không có tác dụng phụ, có nghĩa là nó không có trạng thái chia sẻ, do đó không cần cơ chế đồng bộ hóa, điều này sẽ cần thiết trong khi chạy đồng thời. Đồng bộ hóa là phần khó nhất trong mọi phần mềm đồng thời / song song, do đó thực hiện nó hoàn toàn là chức năng, về cơ bản bạn không phải đối phó với phần khó nhất.

Đối với bản đồ thu nhỏ, ngay cả tên cũng xuất phát từ lập trình chức năng (cả ánh xạ và thu nhỏ là các hoạt động điển hình trong mô hình chức năng). Cả hai bước của map-less là các hàm chạy song song, lấy đầu vào, tạo đầu ra và không có tác dụng phụ. Vì vậy, đây chính xác là ý tưởng lập trình chức năng thuần túy.

Một vài ví dụ về FP được sử dụng cho song song:

• CouchDB - xây dựng trên Erlang
• Trò chuyện trên Facebook - xây dựng trên Erlang
• Twitter - xây dựng phần lớn trên Scala