Lợi ích của việc sử dụng C # vs F # hoặc F # vs C # là gì? [đóng cửa]

Tôi làm việc cho một công ty công nghệ chuyên tạo mẫu hơn là vận chuyển sản phẩm. Tôi vừa được hỏi sự khác biệt giữa C # và F # là gì, tại sao MS lại tạo ra F # và những kịch bản nào sẽ tốt hơn C #.

Tôi đã sử dụng ngôn ngữ này một thời gian và tôi yêu thích nó nên tôi có thể dễ dàng tiếp tục về các tính năng tuyệt vời của F # tuy nhiên tôi thiếu kinh nghiệm về C # để nói lý do tại sao chúng ta nên sử dụng ngôn ngữ này hơn ngôn ngữ kia.

Lợi ích của việc sử dụng C # vs F # hoặc F # vs C # là gì?

Các lợi ích chung của lập trình hàm trên các ngôn ngữ mệnh lệnh:

Bạn có thể hình thành nhiều vấn đề dễ dàng hơn nhiều, gần với định nghĩa của chúng và ngắn gọn hơn bằng ngôn ngữ lập trình chức năng như F # và mã của bạn ít bị lỗi hơn (tính bất biến, hệ thống kiểu mạnh hơn, thuật toán khôi phục trực quan). Bạn có thể viết mã ý của bạn thay vì những gì máy tính muốn bạn nói ;-) Bạn sẽ tìm thấy nhiều cuộc thảo luận như thế này khi bạn google nó hoặc thậm chí tìm kiếm nó tại SO.

Những ưu điểm đặc biệt của F #:

• Lập trình không đồng bộ cực kỳ dễ dàng và trực quan với async {}-expressions - Ngay cả với ParallelFX, C # -code tương ứng còn lớn hơn nhiều

• Tích hợp rất dễ dàng các trình biên dịch trình biên dịch và các ngôn ngữ dành riêng cho miền

• Mở rộng ngôn ngữ khi bạn cần: LOP

• Đơn vị đo lường

• Cú pháp linh hoạt hơn

• Các giải pháp thường ngắn hơn và thanh lịch hơn

Hãy xem tài liệu này

Ưu điểm của C # là nó thường chính xác hơn đối với các ứng dụng "mệnh lệnh" (Giao diện người dùng, các thuật toán mệnh lệnh) hơn là một ngôn ngữ lập trình chức năng, .NET-Framework mà nó sử dụng được thiết kế theo thứ bậc và nó phổ biến hơn.

Hơn nữa, bạn có thể có F # và C # cùng nhau trong một giải pháp, vì vậy bạn có thể kết hợp lợi ích của cả hai ngôn ngữ và sử dụng chúng ở những nơi cần thiết.

Nó giống như hỏi lợi ích của một cái búa so với một cái tuốc nơ vít. Ở cấp cực kỳ cao, về cơ bản cả hai đều làm giống nhau, nhưng ở cấp độ triển khai, điều quan trọng là phải chọn công cụ tối ưu cho những gì bạn đang cố gắng hoàn thành. Có những công việc khó và tốn thời gian trong c # nhưng lại dễ dàng trong f # - như cố gắng đập một cái đinh bằng tuốc nơ vít. Bạn có thể làm điều đó, chắc chắn - nó không lý tưởng.

Thao tác dữ liệu là một ví dụ mà cá nhân tôi có thể chỉ ra nơi mà f # thực sự tỏa sáng và c # có thể khó sử dụng. Mặt khác, tôi muốn nói (nói chung) giao diện người dùng trạng thái phức tạp dễ dàng hơn trong OO (c #) hơn là chức năng (f #). (Có lẽ sẽ có một số người không đồng ý với điều này vì bây giờ thật "tuyệt" để "chứng minh" việc làm bất cứ điều gì trong F # dễ dàng như thế nào , nhưng tôi vẫn giữ nguyên điều đó). Còn vô số những người khác.

• F # có thành tích tốt hơn C # trong môn Toán
• Bạn có thể sử dụng các dự án F # trong cùng một giải pháp với C # (và gọi từ cái này sang cái khác)
• F # thực sự tốt cho lập trình thuật toán phức tạp, các ứng dụng tài chính và khoa học
• Về mặt logic, F # thực sự tốt cho quá trình thực thi song song (dễ làm cho mã F # thực thi trên các lõi song song hơn C #)

Để trả lời câu hỏi của bạn khi tôi hiểu nó: Tại sao sử dụng C #? (Bạn nói rằng bạn đã được bán trên F #.)

Trước hết. Nó không chỉ là "chức năng so với OO". Đó là "Chức năng + OO so với OO". Các tính năng chức năng của C # khá thô sơ. F # không. Trong khi đó, F # thực hiện gần như tất cả các tính năng OO của C #. Đối với hầu hết các phần, F # kết thúc như một tập hợp siêu chức năng của C #.

Tuy nhiên, có một số trường hợp F # có thể không phải là lựa chọn tốt nhất:

• Tương tác. Có rất nhiều thư viện sẽ không quá thoải mái từ F #. Có thể họ khai thác những thứ C # OO nào đó mà F # không làm như vậy, hoặc có lẽ họ dựa vào nội bộ của trình biên dịch C #. Ví dụ, Biểu thức. Mặc dù bạn có thể dễ dàng biến một dấu ngoặc kép F # thành một Biểu thức, nhưng kết quả không phải lúc nào cũng chính xác như những gì C # sẽ tạo ra. Một số thư viện có vấn đề với điều này.

  • Có, interop là một mạng khá lớn và có thể dẫn đến một chút mâu thuẫn với một số thư viện.

  • Tôi coi tương tác cũng nên bao gồm nếu bạn có một cơ sở mã hiện có lớn. Sẽ không hợp lý nếu chỉ bắt đầu viết các phần bằng F #.

• Các công cụ thiết kế. F # không có bất kỳ. Không có nghĩa là nó không thể có bất kỳ, nhưng ngay bây giờ bạn không thể khởi động ứng dụng WinForms với F # codebehind. Ngay cả khi nó được hỗ trợ, chẳng hạn như trong các trang ASPX, bạn hiện không nhận được IntelliSense. Vì vậy, bạn cần xem xét cẩn thận ranh giới của mình đối với mã được tạo. Trong một dự án thực sự nhỏ, hầu như chỉ sử dụng các nhà thiết kế khác nhau, sẽ không đáng để sử dụng F # cho "keo" hoặc logic. Trong các dự án lớn hơn, điều này có thể trở nên ít vấn đề hơn.

  • Đây không phải là một vấn đề nội tại. Không giống như câu trả lời của Rex M, tôi không thấy bất kỳ điều gì nội tại về C # hoặc F # khiến chúng tốt hơn để thực hiện giao diện người dùng với nhiều trường có thể thay đổi. Có thể anh ấy đang đề cập đến việc phải viết "có thể thay đổi" và sử dụng <- thay vì =.

  • Cũng phụ thuộc vào thư viện / nhà thiết kế được sử dụng. Chúng tôi thích sử dụng ASP.NET MVC với F # cho tất cả các bộ điều khiển, sau đó là một dự án web C # để thu hút các nhà thiết kế ASPX. Chúng tôi trộn "mã nội tuyến" ASPX thực tế giữa C # và F #, tùy thuộc vào những gì chúng tôi cần trên trang đó. (Loại IntelliSense so với F #.)

• Các công cụ khác. Họ có thể chỉ mong đợi C # và không biết cách đối phó với các dự án F # hoặc mã đã biên dịch. Ngoài ra, các thư viện của F # không được vận chuyển như một phần của .NET, vì vậy bạn có thêm một chút để vận chuyển.

• Nhưng vấn đề số một? Mọi người. Nếu không có nhà phát triển nào của bạn muốn học F #, hoặc tệ hơn, gặp khó khăn nghiêm trọng trong việc hiểu các khía cạnh nhất định, thì có thể bạn đang nâng cốc. (Mặc dù vậy, dù sao thì tôi cũng cho rằng bạn sẽ nâng ly trong trường hợp đó.) Ồ, và nếu ban quản lý nói không, đó có thể là một vấn đề.

Tôi đã viết về điều này một thời gian trước: Tại sao KHÔNG F #?

Bạn đang yêu cầu so sánh giữa ngôn ngữ thủ tục và ngôn ngữ chức năng, vì vậy tôi cảm thấy câu hỏi của bạn có thể được trả lời ở đây: Sự khác biệt giữa lập trình thủ tục và lập trình chức năng là gì?

Về lý do tại sao MS tạo ra F #, câu trả lời đơn giản là: Tạo một ngôn ngữ chức năng có quyền truy cập vào thư viện .Net chỉ đơn giản là mở rộng cơ sở thị trường của họ. Và thấy cú pháp gần giống với OCaml, nó thực sự không đòi hỏi nhiều nỗ lực từ phía họ.

F # chưa phải là ngôn ngữ lập trình khác nếu bạn đang so sánh nó với C #, C ++, VB. C #, C, VB đều là ngôn ngữ lập trình mệnh lệnh hoặc thủ tục. F # là một ngôn ngữ lập trình chức năng.

Hai lợi ích chính của ngôn ngữ lập trình hàm (so với ngôn ngữ mệnh lệnh) là 1. chúng không có tác dụng phụ. Điều này làm cho lý luận toán học về các thuộc tính của chương trình của bạn dễ dàng hơn rất nhiều. 2. các chức năng đó là công dân hạng nhất. Bạn có thể chuyển các hàm dưới dạng tham số cho các hàm khác dễ dàng như bạn có thể các giá trị khác.

Cả ngôn ngữ lập trình mệnh lệnh và chức năng đều có công dụng của chúng. Mặc dù tôi chưa thực hiện bất kỳ công việc nghiêm túc nào trong F #, nhưng chúng tôi hiện đang triển khai thành phần lập lịch trong một trong các sản phẩm của mình dựa trên C # và sẽ thực hiện một thử nghiệm bằng cách mã hóa cùng một trình lập lịch trong F # để xem liệu tính đúng đắn của việc triển khai có thể được xác nhận dễ dàng hơn so với C # tương đương.

F # về cơ bản là C ++ của các ngôn ngữ lập trình hàm. Họ đã giữ gần như mọi thứ khỏi Objective Caml, bao gồm cả những phần thực sự ngu ngốc, và ném nó lên đầu thời gian chạy .NET theo cách mà nó mang lại tất cả những điều tồi tệ từ .NET.

Ví dụ, với Objective Caml, bạn nhận được một loại null, tùy chọn <T>. Với F #, bạn nhận được ba loại null, tùy chọn <T>, Nullable <T> và tham chiếu null. Điều này có nghĩa là nếu bạn có một tùy chọn, trước tiên bạn cần kiểm tra xem nó có phải là "Không" hay không, sau đó bạn cần kiểm tra xem nó có phải là "Một số (null)" hay không.

F # giống như bản sao Java cũ J #, chỉ là một ngôn ngữ bị biến dạng chỉ để thu hút sự chú ý. Một số người sẽ thích nó, một số ít người thậm chí sẽ sử dụng nó, nhưng cuối cùng thì nó vẫn là một ngôn ngữ 20 năm tuổi được đưa vào CLR.

Một trong những khía cạnh của .NET mà tôi thích nhất là generic. Ngay cả khi bạn viết mã thủ tục trong F #, bạn vẫn sẽ được hưởng lợi từ suy luận kiểu. Nó làm cho việc viết mã chung dễ dàng.

Trong C #, bạn viết mã cụ thể theo mặc định và bạn phải thực hiện thêm một số công việc để viết mã chung.

Trong F #, bạn viết mã chung theo mặc định. Sau hơn một năm lập trình bằng cả F # và C #, tôi thấy rằng mã thư viện tôi viết trong F # vừa ngắn gọn hơn vừa chung chung hơn mã tôi viết trong C #, và do đó cũng có thể sử dụng lại nhiều hơn. Tôi bỏ lỡ nhiều cơ hội để viết mã chung trong C #, có lẽ vì tôi bị che mắt bởi các chú thích kiểu bắt buộc.

Tuy nhiên, có những trường hợp sử dụng C # được ưu tiên hơn, tùy thuộc vào sở thích và phong cách lập trình của mỗi người.

• C # không áp đặt thứ tự khai báo giữa các kiểu và nó không nhạy cảm với thứ tự các tệp được biên dịch.
• C # có một số chuyển đổi ngầm định mà F # không thể thực hiện được do kiểu suy luận.