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

Question

Tôi làm việc cho một công ty công nghệ tạo mẫu thử nhiều hơn so với lô hàng sản phẩm. Tôi vừa được hỏi sự khác biệt giữa C# và F #, tại sao MS tạo F # và 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 thích nó vì vậy tôi có thể dễ dàng tìm hiểu về các tính năng tuyệt vời của F # tuy nhiên tôi thiếu kinh nghiệm trong C# để nói lý do tại sao chúng ta nên sử dụng cái kia.

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

Answer 1

lợi ích chung của lập trình chức năng so với ngôn ngữ bắt buộc:

Bạn có thể xây dựng nhiều vấn đề dễ dàng hơn nhiều, gần gũi hơn với định nghĩa của họ và súc tích hơn trong một ngôn ngữ lập trình chức năng như F # và mã của bạn là ít dễ bị lỗi (không thay đổi, hệ thống kiểu mạnh mẽ hơn, các thuật toán lặp lại trực quan). Bạn có thể mã những gì bạn có nghĩa là 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.

đặc biệt F # -advantages:

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

• Very easy integration của trình biên dịch biên dịch và các ngôn ngữ cụ thể theo miền

• Mở rộng ngôn ngữ khi bạn n EeD nó: LOP

• Units of measure

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

• Thông thường giải pháp thanh lịch hơn

Hãy xem this document

Những lợi thế của C# là ngắn hơn và rằng nó thường chính xác hơn để "bắt buộc" -ứng dụng (Giao diện người dùng, các thuật toán bắt buộc) so với một ngôn ngữ lập trình hàm, .NET Framework mà nó sử dụng được thiết kế một cách bất hợp pháp và nó phổ biến rộng rãi 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 các lợi ích của cả hai ngôn ngữ và sử dụng chúng khi cần.

Answer 2

• F# Has Better Performance than C# in Math
• Bạn có thể sử dụng F # các dự án trong cùng một giải pháp với C# (và gọi từ một đến khác)
• F # là 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
• F # logic thực sự tốt cho việc thực hiện song song (dễ dàng hơn để làm cho mã F # thực thi trên các lõi song song, hơn C#)

Answer 3

Bạn đang yêu cầu so sánh giữa ngôn ngữ thủ tục và af ngôn ngữ không thích hợp vì vậy tôi cảm thấy câu hỏi của bạn có thể được trả lời ở đây: What is the difference between procedural programming and functional programming?

Vì sao MS tạo F # câu trả lời đơn giản: Việc tạo một ngôn ngữ chức năng có quyền truy cập vào thư viện .Net đơn giản mở rộng cơ sở thị trường của họ. Và nhìn thấy cách 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ọ.

Answer 4

Nó giống như yêu cầu những lợi ích của một cái búa trên một tuốc nơ vít là gì. Ở cấp độ cực cao, cả hai đều thực chất 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 thực hiện. Có những nhiệm vụ khó khăn và tốn thời gian trong C# nhưng dễ dàng trong f # - giống như cố gắng đập móng tay bằng tuốc nơ vít. Bạn có thể làm điều đó, chắc chắn - nó không chỉ lý tưởng.

Thao tác dữ liệu là một ví dụ tôi có thể đích thân trỏ đến nơi f # thực sự tỏa sáng và C# có khả năng khó sử dụng. Mặt khác, tôi muốn nói (nói chung) UI phức tạp trạng thái dễ dàng hơn trong OO (C#) so với chức năng (f #). (Có lẽ sẽ có một số người không đồng ý với điều này vì nó "mát mẻ" ngay bây giờ để "chứng minh" cách dễ dàng để làm bất cứ điều gì trong F #, nhưng tôi đứng bởi nó). Có vô số người khác.

Answer 5

F # không phải là ngôn ngữ lập trình khác nếu bạn so sánh nó với C#, C++, VB. C#, C, VB là tất cả các ngôn ngữ lập trình bắt buộc hoặc thủ tục. F # là một ngôn ngữ lập trình hàm.

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. chức năng đó là công dân hạng nhất. Bạn có thể chuyển các hàm như các tham số đến một hàm khác dễ dàng như bạn có thể có các giá trị khác.

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

Answer 6

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

Ví dụ: với mục tiêu Caml bạn nhận được một loại null, tùy chọn < T>. Với F # bạn có ba kiểu 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", thì bạn cần phải kiểm tra xem đó có phải là "Some (null)" hay không.

F # giống như bản sao Java cũ J #, chỉ là một ngôn ngữ khốn khổ chỉ để thu hút sự chú ý. Một số người sẽ thích nó, một vài trong số đó 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 tuổi được gắn vào CLR.

Answer 7

Để trả lời câu hỏi của bạn khi tôi hiểu câu hỏi: Tại sao nên 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 # là không. Trong khi đó, F # 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 superset của chức năng của C#.

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

• Interop. Có rất nhiều thư viện mà sẽ không quá thoải mái với F #. Có lẽ họ khai thác một số điều C# OO 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. Trong khi bạn có thể dễ dàng biến một báo giá F # thành một biểu thức, kết quả không phải lúc nào cũng chính xác 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 ma sát với một số thư viện.

  • Tôi xem xét interop để cũng bao gồm nếu bạn có một codebase lớn hiện có. Nó có thể không có ý nghĩa để chỉ bắt đầu viết các phần trong F #.

• Công cụ thiết kế. F # không có. 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ể whip lên một ứng dụng WinForms với F # codebehind. Ngay cả khi nó được hỗ trợ, như trong các trang ASPX, bạn hiện không nhận được IntelliSense. Vì vậy, bạn cần phải cẩn thận xem xét nơi ranh giới của bạn sẽ được cho mã được tạo ra. Trên một dự án thực sự nhỏ mà hầu như chỉ sử dụng các nhà thiết kế khác nhau, nó có thể không có giá trị nó để sử dụng F # cho "keo" hoặc logic. Trên các dự án lớn hơn, điều này có thể trở thành ít hơn của một vấn đề.

  • Đây không phải là vấn đề thực chất. Không giống như câu trả lời của Rex M, tôi không thấy bất cứ điều gì thực chất về C# hoặc F #, làm cho chúng tốt hơn khi thực hiện giao diện người dùng với nhiều trường có thể thay đổi. Có lẽ anh ta đang nói đến chi phí phụ trội của 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 đó một dự án web C# để có được các nhà thiết kế ASPX. Chúng tôi trộn ASPX "mã nội tuyến" 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 đó. (Các 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ã được biên dịch. Ngoài ra, các thư viện của F # không được gửi như một phần của .NET, vì vậy bạn có thêm một chút để gửi đi.

• Nhưng vấn đề số một? Những 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, có 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 bánh mì. (Mặc dù, tôi muốn tranh luận bạn đang nướng bánh mì trong trường hợp đó.) Ồ, và nếu quản lý nói không, đó có thể là một vấn đề.

tôi đã viết về vấn đề này một thời gian trước: Why NOT F#?

Answer 8

Một trong những khía cạnh của .NET Tôi thích nhất là thuốc 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ừ kiểu suy luận. Nó làm cho việc viết mã chung dễ dàng.

Trong C#, bạn viết mã bê tông theo mặc định và bạn phải đặt 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 khi trải qua một năm lập trình trong cả F # và C#, tôi thấy rằng mã thư viện mà tôi viết trong F # là ngắn gọn hơn và chung chung hơn mã tôi viết trong C#, và do đó cũng có thể tái sử dụng được 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ị mù bởi các chú thích loại bắt buộc.

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

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