Tại sao những nỗ lực này để hạ Scala với Xtend và Kotlin? [đóng cửa]


26

Vì vậy, bây giờ Eclipse đã cung cấp Xtend và JetBrains đang cung cấp Kotlin - cả hai đều có vẻ là phiên bản của Scala. Câu hỏi của tôi là tại sao? Tôi đã chơi với Scala một chút và nó không phải khó khăn. Đây chỉ là một phản ứng đối với những khó khăn vốn có của bước nhảy vọt từ mệnh lệnh sang chức năng hay còn có điều gì khác ở nơi làm việc ở đây?


EDIT: Lời xin lỗi. Đọc lại câu hỏi khi tôi đăng nó ban đầu tôi có thể thấy nó nghe giống như trolling. Cách tôi đặt câu hỏi dường như là cách tốt nhất để đặt câu hỏi. Tôi đã thấy các bài đăng trên blog về hiệu ứng "Scala quá khó / Scala quá phức tạp" và cũng "Kotlin là một nỗ lực để làm Scala nhưng đơn giản hơn". Tôi sẽ rời khỏi cụm từ như ban đầu nhưng thật lòng tôi không cố gắng để troll.


20
Đối với tôi, dường như khá lớn khi chỉ đơn giản cho rằng một ngôn ngữ mới có một số điểm tương đồng với Scala phải là "phiên bản xuống nước của Scala" được viết bởi những người mà Scala quá khó. Bạn ít có khả năng nhận được câu trả lời được xem xét tốt bằng cách đặt câu hỏi như vậy.
Michael Borgwardt

8
Hội chỉ là một phiên bản rút gọn của mã máy, phải không?
Ben Brocka

6
@BenBrocka: Không, nó đồng hình với mã máy;)

4
Scala là tuyệt vời. Đối với tôi, tôi tin rằng mọi người nên từ bỏ việc phát minh lại Java và xe đạp (tất cả những ngôn ngữ mới, được đề cập và không) và chỉ sử dụng và cải thiện Scala. IMHO.
Ivan

2
@MichaelBogwardt một điểm công bằng. Tôi đang dựa trên sự khẳng định về những gì tôi đã thấy xung quanh thế giới blog. "Scala quá khó" và "Scala quá phức tạp" dường như là những khiếu nại tương đối phổ biến.
Onorio Catenacci

Câu trả lời:


39

IMHO từ ai đó lập trình bằng Java trong 7 năm qua và là ngôn ngữ mạnh nhất của tôi, tôi thấy Scala khá xa lạ và đang gặp khó khăn trong việc làm quen với nó.

Xtend cảm thấy giống Java hơn và có thể viết một ứng dụng đơn giản với nó nhanh hơn nhiều. Cứ cho là tôi không cho mình đủ thời gian với Scala, nhưng tôi chắc chắn hiểu tại sao một số có thể bị tắt bởi nó.

Với điều đó đã được nói, mọi người sẽ chọn một địa ngục quen thuộc trên một thiên đường xa lạ.


19
+1: "mọi người sẽ chọn một địa ngục quen thuộc trên một thiên đường xa lạ".
Giorgio

18

JetBrains có một trang wiki so sánh Scala với Kotlin và dường như có một vài điều mà Kotlin làm và Scala thì không:

  • Không có chi phí không an toàn. Scala có Tùy chọn, là trình bao bọc cú pháp và thời gian chạy
  • Diễn viên thông minh
  • Chức năng mở rộng tĩnh. Thay vì gói trong thời gian chạy
  • Các chức năng nội tuyến của Kotlin tạo điều kiện cho các bước nhảy không nhắm mục tiêu
  • Mẫu chuỗi. Có plugin trình biên dịch bên thứ 3 cho scala với chức năng tương tự: ScalaEnhifiedStrings
  • Đoàn hạng nhất. Cũng được thực hiện thông qua plugin của bên thứ 3: Mô-đun Autoproxy

Vì vậy, gọi Kotlin là nước xuống Scala có lẽ là một sự đơn giản hóa. Đối với Xtend, tôi nghĩ rằng nó nhắm mục tiêu chủ yếu là người dùng Xtext, thay vì đối tượng rộng hơn. Một sự khác biệt lớn đối với Scala là Xtend biên dịch sang Java chứ không phải mã byte.

Một ngôn ngữ "sát thủ Java" khác mà bạn nên thêm vào danh sách của mình là Ceylon của Red Hat , mặc dù tôi không biết nó có thể so sánh với Scala như thế nào.


13
Diễn viên tự động nghe có vẻ đáng sợ.
Jonas

14
Ngành công nghiệp có những cuộc cách mạng theo chu kỳ, nơi các nhà phát triển sẽ đi từ một thái cực và lặp đi lặp lại. Các ngôn ngữ mã hóa năng lượng phong phú là tốt, sau đó những kẻ ngốc đã viết mã xấu và chúng tôi đã tìm thấy những mối nguy hiểm để mọi người đổ xô đến sự an toàn được nhận thức của Java, bây giờ trở lại với các lập trình viên điện. Hãy xem Javascript và trình duyệt dựa trên trình duyệt tốt như thế nào, sau đó các applet xuất hiện và RIA với các plugin trình duyệt tốt và Javascript xấu, sau đó các khung AJAX hiện đại xuất hiện và các plugin không an toàn và xấu, sau đó Silverlight xuất hiện và mọi người nói AJAX đã chết, NGAY HTML5 thịnh hành và bổ sung lại xấu! :)
maple_shaft

3
@Jonas Tôi thậm chí không biết nếu tôi đồng ý với nó, nhưng đó là một hiện tượng mà tôi đã nhận thấy. Chắc chắn với mỗi cuộc cách mạng đến một giải pháp tinh vi hơn, nhưng mỗi giải pháp luôn có một gót chân Achilles. Giải quyết vấn đề gót chân khiến một số người nhìn ngược lại các giải pháp trước đây cho các ý tưởng, nhưng theo thời gian, mọi người quên mất lý do tại sao những giải pháp cũ đó bị bỏ rơi ban đầu. Theo thời gian, với mỗi cuộc cách mạng, gót chân cứ nhỏ dần. Java + XTend chắc chắn có thể không phức tạp như Scala, tuy nhiên các vấn đề nhỏ hơn so với đầu tư để chuyển hoàn toàn sang ngôn ngữ mới.
maple_shaft

2
@Jonas Vâng, chỉ có sự đơn giản hóa quá mức tiến hóa công nghệ mới phù hợp với một nhận xét. Tôi đồng ý với maple_shaft, sự phát triển công nghệ có một cảm giác lặp đi lặp lại .
yannis

3
@Jonas các diễn viên này không phải là diễn viên tự động mà là thông minh: nếu bạn nhìn vào bạn sẽ thấy nó không giống nhau: kotlinlang.org/docs/reference/typIDIA.html
cy6erGn0m

11

Tôi đã sử dụng Scala làm ngôn ngữ chính của mình trong năm ngoái (với Java là một giây gần gũi, cả trong một cơ sở mã Java kế thừa lớn.) Tôi vẫn phải tìm kiếm các tính năng khá cơ bản nếu tôi không sử dụng chúng trong một trong khi. Chắc chắn, bạn có thể viết một số Scala một cách nhanh chóng, nhưng đó là một ngôn ngữ cực kỳ giàu tính năng và phải mất một thời gian dài để thành thạo.

Hơn nữa, sự phức tạp của nó không chỉ là vấn đề đối với con người, mà còn đối với các IDE và trình biên dịch. Cả Celyon và Kotlin đều biên dịch trực tiếp thành JavaScript khá sạch. Scala có thể tạo ra JavaScript, thông qua GWT, mặc dù việc đó rất phức tạp và đầu ra của GWT không rõ ràng và cũng không được thiết kế để chơi độc đáo với JavaScript hoặc HTML bên ngoài.

Tôi chắc chắn có năng suất cao hơn trong Scala so với Java và mã này nhỏ gọn và dễ đọc hơn (một khi bạn biết một chút Scala.) Nhưng sự phức tạp của nó khiến tôi ngần ngại giới thiệu nó cho người khác. Một ngôn ngữ với 20% độ phức tạp nhưng 80% khả năng sẽ là một lựa chọn thay thế đáng hoan nghênh.

[Đã chỉnh sửa để xóa đề cập đến mã kế thừa, xem bình luận bên dưới.]

[Phụ lục 2017: Scala hiện hỗ trợ JavaScript làm mục tiêu xây dựng, trong khi Kotlin tiếp tục bổ sung các tính năng có ý nghĩa cho việc thay thế Java / Groovy / JavaScript giống như Scala. Bây giờ chúng là ngôn ngữ đặc biệt hơn so với khi tôi mới viết thứ này.]


Bạn có thể vui lòng xây dựng "phần lagacy" thêm một chút không? Ví dụ, phương pháp nào bạn có nghĩa là lấy Danh sách thay vì Seqs?
kiritsuku

Tôi sẽ chỉnh sửa điều đó, kể từ khi phản ánh, thư viện Scala tiêu chuẩn thực sự hiếm khi làm điều đó. JSONArray có một Danh sách, nhưng hầu hết các nhà xây dựng thì không. Bất kể, vẫn có sự thiên vị trong tài liệu về Danh sách, đặc biệt là từ Lập trình trong Scala, Phiên bản 2, chỉ bao gồm Scala 2.8, trước vectơ. Và các ví dụ mã của nó có xu hướng có các hàm tạo lấy List trong đó Seq sẽ tốt hơn.
David Leppik

Vâng, đối với 2.10 một số thứ là tốt hơn ( +:ví dụ như trình trích xuất). Tôi hy vọng Lập trình trong Scala sẽ được cập nhật trong tương lai gần. Đối với 2,11 một số điều cải thiện hơn nữa. Các stdlib đã được giải phóng khỏi sự phản đối và cũng sẽ thu nhỏ lại một chút. Có lẽ scala.util.parsingcũng sẽ được chuyển ra ngoài stdlib. Chúng ta sẽ thấy ...
kiritsuku

1
Tôi nên nói thêm rằng vấn đề thực sự của tôi với Danh sách so với vectơ là việc thêm các mục vào danh sách (ví dụ Seq trong Scala) là một thao tác rất cơ bản và có quá nhiều cách tương đương để thực hiện, tất cả đều có các biểu tượng ngộ nghĩnh khó thực hiện nhớ lại. Cách chính tắc là ::, ::=hoặc trả +:=trước, nhưng hầu hết mọi người muốn bổ sung :+=, nhưng điều đó không hiệu quả cho Danh sách.
David Leppik

10

JetBrains đã nêu rất rõ mục tiêu của họ đối với Kotlin :

Chúng tôi muốn trở nên năng suất hơn bằng cách chuyển sang một ngôn ngữ biểu cảm hơn. Đồng thời, chúng tôi không thể chấp nhận thỏa hiệp về khả năng tương tác Java (ngôn ngữ mới sẽ được giới thiệu dần dần và cần phải tương tác trơn tru với cơ sở mã hiện tại) hoặc tốc độ biên dịch (cơ sở mã của chúng tôi đủ lâu để biên dịch javac, và chúng tôi không thể đủ khả năng làm cho nó chậm hơn). Điều tiếp theo cũng khá đơn giản: chúng tôi hy vọng Kotlin sẽ thúc đẩy doanh số của IntelliJ IDEA.


8

Tôi đã sử dụng Scala một vài tháng trong Eclipse với Play Framework. Tôi thích ngôn ngữ này nhưng cũng có những thứ tôi không thích.

Đối với tôi, lý do để chuyển từ Java sang ngôn ngữ khác là để có năng suất cao hơn.

Cho đến nay tôi vẫn chưa làm việc hiệu quả hơn với Scala. Một lý do là thiếu sự hỗ trợ tốt cho Scala trong Eclipse, plugin Scala rất tệ (ví dụ như thụt lề không thành công) và chưa có nhiều chức năng (ví dụ: không có "Phân cấp cuộc gọi mở"). Trình biên dịch Scala cũng chậm, điều này có thể không thành vấn đề, nhưng tôi sử dụng Scala với Play Framework, nó biên dịch mã cho mọi yêu cầu và tốc độ trình biên dịch rất quan trọng.


2
Có lẽ bạn chưa học đủ thành ngữ Scala. Tôi đã sử dụng Scala cho các dự án nhỏ (công cụ) và tôi làm việc hiệu quả hơn với Scala so với Java, mặc dù tôi có nhiều kinh nghiệm hơn về Java (> 10 năm) so với Scala (<2 năm).
Giorgio

4

Không biết về Kotlin, nhưng Scala và Xtend là hai quái thú rất khác nhau.

Trái với những câu nói thông thường, Scala KHÔNG phải là một Java tốt hơn. Scala là ngôn ngữ nổi bật hơn nhiều so với Java, với cú pháp và ngữ nghĩa riêng và gói thư viện cơ sở riêng.

Xtend là một Java tốt hơn. Nó giữ ngữ nghĩa Java và tăng cường cú pháp của nó. Mỗi dòng mã Xtend có thể được dịch trực tiếp sang một loạt các dòng mã java. Không có thời gian chạy bổ sung, cũng không.

Tôi nghĩ rằng cả hai cách tiếp cận đều đúng, mặc dù khác nhau. Tôi không thích Scala (như một ngôn ngữ), nhưng không thích thêm bình Scala vào các dự án của tôi. Tôi cũng không thể sử dụng Scala đúng cách trong Android (nó cũng làm tăng thêm vấn đề về trọng lượng và hiệu suất). Xtend không có nhiều tính năng, nhưng đối với tôi (nó đáng sử dụng hơn ngôn ngữ Java) và nó hoạt động trên mọi nền tảng như thể tôi đang viết trực tiếp bằng Java.

Tôi tin rằng cả hai ngôn ngữ bao gồm các ngóc ngách khác nhau và có thể cùng tồn tại mà không can thiệp lẫn nhau. IMHO, Scala quá phức tạp, không có gì mới. Nếu bạn muốn đi nhiều chức năng hơn và ít OO hơn, chỉ cần chọn một trong nhiều ngôn ngữ chức năng đơn giản hơn, như Clojure hoặc JHaskell. Nếu bạn chỉ muốn Java với một số cú pháp tốt hơn và một chút lập trình chức năng, Fantom sẽ tuyệt vời như Scala (nó giống với C # rất nhiều).

Nhưng tôi thấy Xtend đang ở một điểm ngọt ngào giữa tất cả các ngôn ngữ đó. Nó bổ sung tất cả các mẫu cú pháp mà tôi muốn cho Java, giữ các phần tốt của Java (ngữ nghĩa của nó). Hãy nghĩ về nó như Coffescript cho Java.

Và hỗ trợ Eclipse là tuyệt vời ...


Càng và nó chỉ được hỗ trợ trong Eclipse. Đúng? Và Eclipse là một địa ngục
Sange Borsch

Xtend có thời gian chạy bổ sung. Khoảng 3 MB cuối tôi đã kiểm tra.
mm2001

@ mm2001 Có phụ thuộc: khoảng 300 Ko cho xtend và 2 Mo cho ổi trong dự án thử nghiệm nhỏ của tôi ( github.com/pdemanget/examples/tree/master/xtend/message-send ) Nhưng đó không phải là thời gian chạy, đó là các lớp bổ sung cho điều như InputOutput, các chú thích bổ sung. Nó không loại bỏ điểm chính với tôi rằng Scala và Xtend là 2 ngôn ngữ rất khác nhau như đã nói trong câu trả lời này.
pdem
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.