Sự khác biệt lớn nhất giữa F # và Scala là gì?


59

F # và Scala đều là các ngôn ngữ lập trình chức năng không buộc nhà phát triển chỉ sử dụng các kiểu dữ liệu bất biến. Cả hai đều có hỗ trợ cho các đối tượng, có thể sử dụng các thư viện được viết bằng các ngôn ngữ khác và chạy trên máy ảo. Cả hai ngôn ngữ dường như được dựa trên ML.

Sự khác biệt lớn nhất giữa F # và Scala mặc dù thực tế là F # được thiết kế cho .NET và Scala cho nền tảng Java?


2
Nếu bạn có thể bỏ phiếu và nghĩ rằng đây là một câu hỏi hữu ích hoặc nó có câu trả lời hữu ích dưới đây, vui lòng bỏ phiếu. Các trang web StackExchange cần phiếu bầu để xây dựng một cộng đồng tốt. Bạn có thể cho 30 phiếu mỗi ngày, đừng lãng phí chúng. Người dùng đặc biệt có uy tín cao và số phiếu bầu thấp được đưa ra xin vui lòng đọc này: meta.programmers.stackexchange.com/questions/393/ Kẻ
Maniero

functional programming langugages that don't force the developer to only use immutable datatypes- có bất kỳ, ngoại trừ có thể ngôn ngữ đồ chơi?
Ingo

1
@Ingo, nếu bạn nghĩ rằng ML và Ocaml không đủ điều kiện là ngôn ngữ lập trình chức năng vì chúng cho phép khả năng biến đổi, có lẽ bạn nên điều chỉnh định nghĩa của mình!
Frank Shearar

3
+ Frank, bạn hẳn đã hiểu nhầm: Ý tôi là, ngay cả Haskell cũng có kiểu dữ liệu có thể thay đổi. Do đó, tôi vẫn muốn biết ngôn ngữ nào @Jonas có thể trong tâm trí sẽ buộc người ta chỉ sử dụng các kiểu dữ liệu bất biến?
Ingo

Câu trả lời:


61

Sự khác biệt lớn:

  • Cả Scala và F # kết hợp lập trình OO-mệnh lệnh và lập trình chức năng thành một ngôn ngữ. Cách tiếp cận của họ đối với việc thống nhất các mô hình là rất khác nhau mặc dù. Scala cố gắng hợp nhất hai mô hình thành một (chúng tôi gọi đó là mô hình chức năng đối tượng), trong khi F # cung cấp hai mô hình cạnh nhau. Ví dụ, các kiểu dữ liệu đại số trong F # là các cấu trúc chức năng thuần túy không có OO'ness trong khi các ADT trong Scala vẫn là các lớp và đối tượng thông thường. (Lưu ý: Trong quá trình biên dịch thành mã byte CLR, ngay cả F # ADT cũng trở thành các lớp và đối tượng nhưng chúng không hiển thị cho lập trình viên F # ở cấp nguồn.)

  • F # có kiểu suy luận kiểu Hindley-Milner đầy đủ. Scala có loại suy luận một phần. Hỗ trợ cho việc phân nhóm và thuần túy OO-ness làm cho kiểu suy luận kiểu Hindley-Milner không thể có đối với Scala.

  • Scala là ngôn ngữ tối giản hơn nhiều so với F #. Scala có một tập hợp các cấu trúc trực giao rất nhỏ được sử dụng lại trong suốt ngôn ngữ. F # dường như giới thiệu cú pháp mới cho mọi thứ nhỏ, do đó trở nên rất nặng cú pháp so với Scala. (Scala có 40 từ khóa, trong khi F # có 97. Điều đó sẽ cho bạn biết điều gì đó :-)

  • F # là ngôn ngữ của Microsoft có hỗ trợ IDE tuyệt vời dưới dạng Visual Studio. Mọi thứ không tốt lắm về phía Scala. Plugin Eclipse vẫn chưa đạt được mục đích. Tương tự với plugin NetBeans. IDEA dường như là sự đặt cược tốt nhất của bạn tại thời điểm này, mặc dù nó thậm chí không gần với những gì bạn nhận được với các IDE Java. (Đối với người hâm mộ Emacs, có ENSIME. Tôi đã nghe rất nhiều điều hay về gói này, nhưng tôi chưa thử nó.)

  • Scala có hệ thống loại mạnh hơn (và phức tạp) hơn nhiều so với F #.


Sự khác biệt khác:

  • Các chức năng F # được chế tạo theo mặc định. Trong Scala, cà ri có sẵn nhưng không được sử dụng rất thường xuyên.

  • Cú pháp của Scala là sự pha trộn của Java, Standard ML, Haskell, Erlang và nhiều ngôn ngữ khác. Cú pháp F # được lấy cảm hứng từ những cú pháp của OCaml, C # và Haskell.

  • Scala hỗ trợ các loại cao hơn và kiểu chữ. F # không.

  • Scala dễ sử dụng DSL hơn F #.


PS: Tôi yêu cả Scala và F #, và hy vọng chúng trở thành ngôn ngữ chính của các nền tảng tương ứng của chúng trong tương lai. :-)


6
Câu trả lời này kéo dài một số quan niệm sai lầm. Tôi sẽ liệt kê lần lượt từng cái. Bạn đã nói "các kiểu dữ liệu đại số trong F # là các cấu trúc chức năng thuần túy không có OO'ness trong chúng" nhưng các kiểu dữ liệu đại số trong F # chỉ là lớp và đặc biệt, chúng hỗ trợ tăng cường với các thuộc tính và thành viên tĩnh OO.
Jon Harrop

7
Bạn nói "Scala cố gắng hợp nhất hai mô hình thành một (chúng tôi gọi đó là mô hình chức năng đối tượng)" nhưng Scala thiếu loại bỏ cuộc gọi đuôi chung và do đó, bất kỳ mã chức năng không tầm thường nào (bao gồm hầu hết tất cả các thành ngữ chức năng thông thường như tiếp tục đi qua phong cách và tháo gỡ nút thắt đệ quy) có xu hướng chồng chất tràn trong Scala và do đó, thực tế là vô dụng.
Jon Harrop

4
@JonHarrop: Scala không đối xử đặc biệt với ADT. Họ được đối xử giống như các lớp học thông thường. Có Some(2)trong Scala có loại Some[Int]và không phải Option[Int]là IMO không mong muốn. Mặt khác, F # có một cú pháp và cách xử lý đặc biệt đối với các ADT và do đó có thể suy ra chính xác loại Some 2như int option. Vì vậy, mã hóa F # của ADT tốt hơn so với Scala (tất nhiên là IMO). Tôi đã không cố gắng ám chỉ rằng nó thấp kém, và tôi xin lỗi nếu nó đi qua như vậy.
năm11

9
@JonHarrop: Việc thiếu TCO trong JVM đã không làm phiền nhiều nhà phát triển Scala. Tin tôi đi, nó không phải là vấn đề lớn như bạn nghĩ đâu. Hầu hết thời gian, chúng tôi đang sử dụng các hàm bậc cao hơn, thay vì đệ quy rõ ràng. Và hầu hết các hàm bậc cao hơn trong Scala được thực hiện theo các vòng lặp, và không đệ quy. Vì vậy, thiếu TCO trở nên gần với phi vật chất.
missingfaktor

8
Tôi cảm thấy như toàn bộ câu trả lời này là một chút thiên vị đối với Scala. Ví dụ, Scala là ngôn ngữ tối giản hơn nhiều so với F # dường như đi ngược lại với lập luận / điểm sau này của một hệ thống loại phức tạp hơn.
Adam Gent

9
  • F # được giải quyết trên các khía cạnh chức năng trong khi scala dựa trên các khía cạnh hướng đối tượng.
  • F # có hỗ trợ IDE tốt hơn với Visual studio trong khi trình cắm nhật thực của Scala dành cho IDE nguồn mở và tương đối chậm hơn.
  • F #, giống ML nhiều hơn Scala, có nhiều tính toán lambda tối thiểu theo cách mà OCaml, ML chuẩn và Scheme có. F # dường như là một ngôn ngữ đơn giản hơn đáng kể.

4
"F # dường như là một ngôn ngữ đơn giản hơn đáng kể." << Không, không phải vậy. Nó lớn hơn Scala rất nhiều. Tôi nên viết một bài báo về chủ đề này một thời gian.
missingfaktor

4
"Scala dựa trên các khía cạnh hướng đối tượng." << Sai. Scala cố gắng hợp nhất OOP VÀ lập trình chức năng. Cá nhân tôi rất hiếm khi sử dụng các tính năng hướng đối tượng của nó. Hầu hết những gì chúng tôi làm là hoàn toàn chức năng.
missingfaktor

@missingfaktor: "Nó lớn hơn Scala". Làm thế nào lớn là ngữ pháp?
Jon Harrop

1
Tôi không biết nếu mọi thứ đã thay đổi. Scala trong IntelliJ rock, với plugin vẫn là nguồn mở.
Colliot

0

Một điểm nhỏ nhưng quan trọng là giấy phép: Scala là BSD (khá nhiều giấy phép phần mềm miễn phí dễ sử dụng nhất), F # từng là "thỏa thuận cấp phép nguồn chia sẻ nghiên cứu của Microsoft" nhưng hiện là một sản phẩm thương mại (theo @Lorenzo dưới đây, mặc dù tôi không thể tìm thấy thỏa thuận cấp phép cụ thể hơn ở bất cứ đâu).


3
Trên thực tế, F # hiện là nguồn mở và Scala hiện là sản phẩm thương mại của công ty Scala Solutions của Martin Oderky.
Jon Harrop

4
@Jon Harrop: Tôi nghĩ Scala Solutions chỉ bán các công cụ, dịch vụ, đào tạo liên quan đến Scala, v.v ... Bản thân ngôn ngữ dường như vẫn thuộc giấy phép BSD.
Joonas Pulakka

2
@Joonas: Chính xác, điều tương tự cũng đúng với F #.
Jon Harrop

5
@JonHarrop: Scala vẫn là nguồn mở. Xin đừng lan truyền thông tin sai lệch.
missingfaktor

2
@missingfaktor: Tôi không nói Scala là nguồn đóng.
Jon Harrop
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.