it-swarm-vi.com

Tại sao lập trình chức năng không phổ biến hơn trong ngành? Nó có bắt được bây giờ không?

Trong bốn năm ở trường đại học, chúng tôi đã sử dụng nhiều chương trình chức năng trong một số ngôn ngữ lập trình chức năng. Nhưng tôi cũng đã sử dụng nhiều lập trình hướng đối tượng và trên thực tế tôi sử dụng các ngôn ngữ hướng đối tượng nhiều hơn khi thực hiện dự án nhỏ của riêng mình để chuẩn bị cho công việc đầu tiên. Nhưng tôi thường ước rằng tôi đã được mã hóa bằng ngôn ngữ lập trình chức năng khi thực hiện các dự án này.

Tuy nhiên, khi tìm kiếm một công việc, rất hiếm khi thấy một công việc đòi hỏi kiến ​​thức về ngôn ngữ lập trình chức năng.

Tại sao các ngôn ngữ lập trình chức năng không được sử dụng nhiều hơn trong ngành? Có khá nhiều tin tức về ngôn ngữ lập trình chức năng ngày nay, vì vậy tôi tự hỏi liệu bây giờ lập trình chức năng có bắt kịp trong ngành không?

61
Jonas

Tôi muốn nói rằng một trong những lý do khiến lập trình chức năng không phổ biến hơn là thiếu cơ sở kiến ​​thức. Kinh nghiệm của tôi là các tập đoàn rất không thích rủi ro trong việc triển khai các công nghệ không phải là luồng chính và muốn đầu tư vào các khung đã thử và đúng (Java, c ++, c #). Chỉ khi có nhu cầu kinh doanh (như ở Ericsson) thì các mô hình mới mới được xem xét. Nhưng ngay cả trong trường hợp của Ericsson, tôi đã nghe nói rằng ban quản lý yêu cầu sử dụng c ++ và Joe Armstrong bị buộc phải viết mã các cuộc gọi erlang trong c ++ !! Điều này sẽ cho thấy các tập đoàn bất đắc dĩ phải thực hiện các công nghệ mới như thế nào!

38
ennuikiller

Tôi là một giáo sư và, giống như các lập trình viên, các giáo sư luôn tìm kiếm Next Big Thing. Khi họ nghĩ rằng họ đã tìm thấy một, họ biến nó thành một nhóm nhạc và mọi người chồng chất lên nhau. Vì họ đang giảng cho những sinh viên nghĩ rằng các giáo sư phải thực sự thông minh, nên tại sao họ lại là giáo sư, họ không nhận được sự phản kháng nào.

Lập trình chức năng là một bandwagon như vậy. Chắc chắn rằng nó có rất nhiều câu hỏi thú vị để điều tra, và rất nhiều bài báo hội thảo thú vị để viết. Đây không phải là một ý tưởng đặc biệt mới và bạn có thể thực hiện nó bằng bất kỳ ngôn ngữ hiện đại nào và các ý tưởng không phải là mới để trở nên thú vị. Đó cũng là một kỹ năng tốt để có.

Do đó, lập trình chức năng chỉ là một mũi tên cần có trong bộ rung của bạn, không phải là duy nhất, giống như OOP không phải là mũi tên duy nhất.

Thịt bò của tôi với học viện khoa học máy tính là thiếu sự tương tác thực tế với ngành công nghiệp để xác định điều gì thực sự có ý nghĩa trong thế giới thực, tức là kiểm soát chất lượng. Nếu kiểm soát chất lượng ở đó, có thể có một sự nhấn mạnh khác, về việc phân loại các vấn đề và phạm vi giải pháp cho chúng, với sự đánh đổi, thay vì chỉ là các băng thông mới nhất.

67
Mike Dunlavey

Bởi vì vấn đề lớn nhất trong phát triển phần mềm ngày nay là khả năng quản lý sự phức tạp. Đây không phải là trọng tâm của hầu hết các ngôn ngữ lập trình chức năng. Do đó, các ngôn ngữ do làm cho ưu tiên đó (cụ thể là các ngôn ngữ phổ biến hơn OOP) có xu hướng chỉ đánh cắp một số tính năng thú vị xuất phát từ tính hàn lâm hơn ngôn ngữ chức năng và vì vậy ở trên đầu trang.

25
Fishtoaster

Lập trình chức năng chắc chắn là bắt đầu để bắt kịp - từ từ nhưng chắc chắn.

Ví dụ: startup tôi đang xây dựng đang sử dụng ngôn ngữ chức năng (Clojure) làm ngôn ngữ phát triển chính vì các lý do sau:

  • Năng suất - học tập FP là khó, nhưng một khi bạn đã hiểu rõ về nó thì rất khó để đánh bại về mặt về sức mạnh và tính biểu cảm. Có lẽ tôi đang viết khoảng 1/10 số dòng để thực hiện bất kỳ phần chức năng nhất định nào so với những gì tôi cần trong C # hoặc Java

  • Độ tin cậy - các hàm thuần túy dễ dàng lý luận và kiểm tra hơn nhiều so với các đối tượng trạng thái. Do đó bạn có thể viết các bài kiểm tra tốt hơn và xác nhận tính chính xác của mã của bạn dễ dàng hơn nhiều.

  • Đồng thời - ngôn ngữ chức năng nhấn mạnh tính bất biến, có lợi ích to lớn cho các ứng dụng đồng thời hơn là cần chạy hiệu quả trên nhiều lõi. Và dù muốn hay không, chạy trên nhiều lõi là tương lai. Xem http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey để biết giải thích rõ ràng về lý do tại sao điều này rất quan trọng

  • Khả năng kết hợp/mô đun hóa - các ngôn ngữ chức năng dường như cho vay để cắm các thành phần dễ dàng hơn so với các hệ thống phức tạp OO. Tôi vẫn chưa tìm ra tất cả lý do cho việc này, nhưng một phần của nó bắt nguồn từ thực tế là bạn không có tất cả "sự phức tạp ngẫu nhiên" mà OO mô hình kéo theo họ. trên Tính đơn giản cấp tiến của Stuart Halloway khám phá những ý tưởng này sâu hơn nhiều.

[~ # ~] chỉnh sửa [~ # ~] : Đáp lại nhận xét của Despertar, một ví dụ về "độ phức tạp ngẫu nhiên" của OOP giới hạn tính mô đun là các vấn đề với nhân bản sâu so với nhân bản nông: bạn không thể kết hợp các đối tượng lại với nhau và chuyển chúng thành các cấu trúc tổng hợp mà không có phân tích rất cẩn thận về ngữ nghĩa nhân bản và đột biến. có thể quản lý được, nhưng trong các hệ thống phức tạp, nó nhanh chóng trở thành một vấn đề quan trọng. Vấn đề này sẽ không tồn tại ngay từ đầu nếu bạn dựa vào các cấu trúc dữ liệu chức năng thuần túy.

24
mikera

Thiếu ứng dụng sát thủ

Này, cái này ở đây trông tươi mới. (Đào đào)

Tôi nghĩ rằng hầu hết các ngôn ngữ lập trình phát triển mạnh nhờ có "ứng dụng sát thủ" - thứ gì đó hấp dẫn dành riêng cho ngôn ngữ (hoặc xem theo cách đó). Điều này không có nghĩa là tất cả sự hấp thu là ứng dụng đó , nhưng nó đã đưa ngôn ngữ đến một sự chấp nhận lớn hơn.

Đây là quan điểm không chính xác khủng khiếp của tôi về những gì thích hợp đã thúc đẩy việc áp dụng một số ngôn ngữ chúng ta có ngày nay:

  • C: Hoạt động ở khắp mọi nơi (Đây là cuối thập niên 70 và 80)
  • C++: Khung GUI (đầu thập niên 90)
  • Java: Applet và servlets (vào cuối những năm 90)
  • Objective-C: Ứng dụng iOS (Trước đó, ứng dụng OS X)
  • Ruby: Đường ray
  • C #: ASP.NET, WinForms
  • PHP: Wordpress, v.v.
  • Javascript: AJAX, đặc biệt là thông qua các khung
  • lua: Kịch bản trò chơi, đặc biệt là WoW

Bên cạnh đó, nhiều ngôn ngữ độc quyền đã lọt vào cửa thông qua các tổ chức bán hàng hùng mạnh (Oracle và ở mức độ thấp hơn các ngôn ngữ của Microsoft), tạo ra hiệu quả của riêng họ.

Một lưu ý rất quan trọng về danh sách đó: "thích hợp" của ngôn ngữ, như được chỉ ra bởi ứng dụng sát thủ, ngày càng cụ thể hơn khi nhiều thập kỷ trôi qua. Lưu ý cái cuối cùng trong danh sách: cụ thể là trò chơi kịch bản . Các ngôn ngữ ngày càng khó hơn để thu hút sự chú ý vì danh sách những điều đã được ngôn ngữ khác thực hiện đủ tốt.

Vì vậy, những gì bất kỳ ngôn ngữ chức năng cần phải thực sự cất cánh là một thích hợp. Trong thực tế, chưa có bất kỳ ngôn ngữ chức năng khổng lồ nào, nhưng có rất nhiều ngôn ngữ nhỏ hơn:

  • Emacs LISP: Sử dụng liên tục từ những năm 80 trong Emacs bởi các nhà phát triển. ( Hầu như không bao giờ được sử dụng ở bất kỳ nơi nào khác.)
  • Erlang: Bất cứ nơi nào bạn muốn có nhiều tác nhân đồng thời.
  • Đề án: Giáo dục
  • APL/J/K: Tài chính (Hãy gọi các chức năng này, để tranh luận)
  • LISP phổ biến: "AI" - Đây là những gì mọi người có xu hướng nói nó được sử dụng cho, đó là một phước lành và một lời nguyền.

Bây giờ, ngôn ngữ chính duy nhất tôi cảm thấy tôi đã rời khỏi cuộc thảo luận này là Python. Python đã làm một điều gì đó rất thú vị; nó đã thành công mà không có vẻ là người chiến thắng trong bất kỳ phân khúc chính nào. Điều này có thể có nghĩa là tôi đã sai lầm khi xem sự phổ biến ngôn ngữ theo cách này. Điều đó cũng có nghĩa là một ngôn ngữ đủ tốt có thể trở nên phổ biến mà không cần ứng dụng sát thủ để thúc đẩy việc áp dụng và chấp nhận, nhưng nó rất khó khăn và có thể mất một thời gian rất dài. (Perl có một câu chuyện tương tự, nhưng đã đến một vài năm trước đó và bây giờ ít hấp thu hơn.)

Từ đây, tôi có thể nói ngôn ngữ chức năng nào tôi nghĩ đang gia tăng:

  • Clojure: Lập trình web, đặc biệt. thông qua Heroku
  • Scala: Nâng (hoặc có thể Chơi, những ngày này) - JVM không có Java

Nếu bạn hỏi tôi nên tìm ngôn ngữ chức năng phổ biến nào tiếp theo, tôi sẽ nói rằng hãy tìm ngôn ngữ chức năng với phát triển đám mây chìa khóa trao tay (a la Heroku hoặc GAE) hoặc phát triển ứng dụng di động chìa khóa trao tay.

12
Jesse Millikan

Vì lý do tương tự mà LISP không bao giờ thực sự bắt kịp (hãy để flamewar bắt đầu!). Lập trình hàm là một mô hình rất xa lạ so với lập trình bắt buộc và hướng đối tượng. Nếu, giống như đại đa số sinh viên CS, bạn bắt đầu với C và tiến tới C++/Java, bạn có xu hướng không muốn học cách suy nghĩ theo cách hoàn toàn trực giao với cách bạn thường nghĩ.

9
Chinmay Kanchi

Hãy xem xét các doanh nghiệp và lập trình.

Có những doanh nghiệp sử dụng phần mềm của họ như một tài sản chiến lược. Đây không phải là điển hình. Đối với hầu hết các doanh nghiệp, CNTT là thứ hỗ trợ doanh nghiệp thực sự của công ty. Đó là một chi phí cần thiết. Họ bảo thủ vì họ biết rằng với $ X, họ có thể có được CNTT mà họ cần, trong khi nếu họ chuyển sang một thứ khác, họ sẽ tiết kiệm ít hơn $ X nếu mọi thứ suôn sẻ và mất đi thực sự nếu mọi thứ trở nên tồi tệ.

Hơn nữa, trong các doanh nghiệp, điều rẻ nhất để làm thường là những gì họ đã làm ngày hôm qua. Thay đổi, tuy nhiên, mong muốn, là đắt tiền. Nếu một công ty thay đổi từ, giả sử, một giải pháp C # /. NET, thậm chí thành F #, họ sẽ gặp vấn đề. Các lập trình viên của họ (có khả năng không phải là lập trình viên sắc sảo nhất ngoài kia) sẽ phải học một ngôn ngữ mới, và thành thạo cả hai, và sử dụng cả hai thường xuyên. Sẽ có những thói quen được viết trong cả hai trong một thời gian dài. Nếu họ chuyển sang một thứ như Haskell, hoặc nếu họ đang sử dụng C++/MFC ở nơi đầu tiên, họ sẽ thay đổi nhiều hơn và điều đó sẽ tốn kém hơn rất nhiều.

Ngoài ra, sẽ có một nguồn cung cấp cho các lập trình viên C # và tiếp tục hỗ trợ của Microsoft trong một thời gian dài sắp tới. Các thực hành CNTT hiện tại có thể được tính vào. Không có cùng mức hỗ trợ thể chế hoặc đảm bảo sự sẵn có liên tục của các lập trình viên.

Do đó, đối với hầu hết các doanh nghiệp, việc thay đổi lập trình chức năng sẽ rất tốn kém và sẽ chỉ tự trả nếu việc giảm chi phí CNTT là đủ trong thời gian dài, ngoại trừ việc lâu dài có khả năng là iffy.

6
David Thornley

Bạn đã viết mã theo kiểu chức năng, chỉ là bạn không biết nó.

Khi bạn được yêu cầu thực hiện kiểm tra đơn vị cho mã của mình, bạn có xu hướng viết các hàm kiểm tra, không tạo hoặc phụ thuộc vào các hiệu ứng phụ và luôn trả về cùng một kết quả trên cùng một đối số (được gọi là các hàm thuần túy). Đây là lợi thế chính của các chương trình chức năng.

Tôi nghĩ rằng ngôn ngữ chức năng là quá hạn chế. Vì vậy, thay vì thay thế các ngôn ngữ mệnh lệnh bằng các ngôn ngữ chức năng, các ngôn ngữ mệnh lệnh sẽ có được các tính năng chức năng. Ngày nay, hầu hết mọi ngôn ngữ lập trình đều có phần đóng và lambdas.

2
Calmarius

Tôi tin rằng chỉ có một câu trả lời thực sự cho câu hỏi của bạn. Bạn có thể nhận được rất nhiều lý do liên quan tại sao câu trả lời này là trường hợp, nhưng đó là những câu hỏi khác nhau.

Đây là:

  • Kiến trúc sư phần mềm cung cấp giải pháp họ tự tin sẽ làm việc.
  • Phần lớn các kiến ​​trúc sư không làm việc trong các ngôn ngữ chức năng.
  • Khi các công nghệ và ngôn ngữ được chọn, các doanh nghiệp sẽ tìm thấy những người có thể làm việc với họ.

Có bắt được không? Tất cả phụ thuộc vào việc những người tự tin sử dụng ngôn ngữ chức năng có trở thành kiến ​​trúc sư hay không và chọn sử dụng nó cho các dự án mà họ làm việc.

1
John Fisher

Vấn đề thực sự là nhà nước.

Ngôn ngữ chức năng không có nhà nước toàn cầu. Hầu hết các vấn đề công nghiệp yêu cầu trạng thái ở quy mô lớn (làm thế nào để bạn đại diện cho một sổ cái hoặc một bộ giao dịch) ngay cả khi một số chức năng ở quy mô nhỏ không thực sự yêu cầu nó (xử lý một sổ cái).

Nhưng chúng tôi đang chạy mã trên các máy kiến ​​trúc Von-Neuman vốn đã đầy đủ trạng thái. Vì vậy, chúng tôi chưa thực sự thoát khỏi trạng thái, các ngôn ngữ chức năng chỉ che giấu sự phức tạp của trạng thái khỏi nhà phát triển. Điều này có nghĩa là ngôn ngữ/trình biên dịch phải xử lý trạng thái đằng sau hậu trường và quản lý nó.

Vì vậy, mặc dù các ngôn ngữ chức năng không có trạng thái toàn cầu, thông tin trạng thái của chúng được truyền dưới dạng tham số và kết quả.

Vì vậy, câu hỏi sau đó trở thành ngôn ngữ có thể xử lý nhà nước hiệu quả đằng sau ý nghĩa? Đặc biệt là khi kích thước dữ liệu vượt xa kích thước của kiến ​​trúc.

Nhìn vào nó từ phía Phần cứng

HĐH đã giúp ích rất nhiều trong vài năm qua trong việc trực quan hóa không gian địa chỉ để các ứng dụng không chính thức phải lo lắng về điều đó. Nhưng các ứng dụng không lo lắng về việc rơi vào bẫy đập phần cứng khi áp lực bộ nhớ trở nên mãnh liệt (phần cứng đập sẽ làm chậm quá trình của bạn để thu thập dữ liệu).

Vì lập trình viên không kiểm soát trực tiếp trạng thái trong ngôn ngữ chức năng, họ phải dựa vào trình biên dịch để xử lý việc này và tôi chưa thấy các ngôn ngữ chức năng xử lý tốt việc này.

Về mặt trái ngược của đồng xu, lập trình viên toàn trạng có quyền kiểm soát trực tiếp trạng thái và do đó có thể bù cho các điều kiện bộ nhớ thấp. Mặc dù tôi chưa thấy nhiều lập trình viên thực sự đủ thông minh để làm như vậy.

Nhìn từ phía ngành công nghiệp:

Công nghiệp có rất nhiều lập trình viên nhà nước không hiệu quả.

Nhưng thật dễ dàng để đo lường sự cải thiện trong các chương trình này theo thời gian. Bạn ném một nhóm các nhà phát triển vào vấn đề họ có thể cải thiện mã bằng cách cải thiện cách chương trình xử lý trạng thái.

Đối với các chương trình chức năng, các cải tiến là nhiều hơn khó đo lường vì bạn cần cải thiện các công cụ sẽ cải thiện các chương trình (chúng tôi chỉ xem xét cách các ứng dụng xử lý trạng thái cơ bản hiệu quả ở đây, chứ không phải là cải tiến tổng thể của chương trình ).

Vì vậy, đối với ngành công nghiệp, tôi nghĩ rằng nó có khả năng đo lường sự cải tiến trong mã.

Từ góc độ tuyển dụng

Có rất nhiều lập trình viên đầy đủ cho thuê. Các lập trình viên chức năng rất khó tìm. Vì vậy, mô hình cung và cầu cơ bản của bạn sẽ phát huy nếu ngành công nghiệp chuyển sang lập trình kiểu chức năng và đó không phải là điều họ muốn xảy ra (lập trình viên đủ đắt như nó).

0
Martin York