Clojure độc ​​lập với Java như thế nào?


13

Tôi còn khá mới mẻ với thế giới Clojure. Tôi đánh giá cao việc người ta có thể truy cập dễ dàng vào tất cả các thư viện Java thông qua các tính năng xen kẽ của Clojure, nhưng tôi đã tự hỏi Clojure đứng trên đôi chân của mình bao nhiêu.

Tất nhiên, có một số nền tảng, như Android, trong đó khả năng tương tác với Java sẽ luôn được yêu cầu, bởi vì các thư viện cốt lõi được viết hoặc hiển thị trong Java. Hơn nữa, vì các chuỗi Clojure là các chuỗi Java, tôi hy vọng các thư viện thao tác chuỗi sẽ là một trình bao bọc trên các phương thức Chuỗi Java.

Nhưng đối với các nhiệm vụ khác, tôi thấy không có lý do tại sao các thư viện Clojure bản địa không thể được phát triển. Hãy nghĩ về http, thao tác ngày, phân tích cú pháp XML, tạo khuôn mẫu, tuần tự hóa và giải tuần tự JSON, OAuth, thư viện toán học, v.v.

Vì vậy, câu hỏi của tôi là:

Clojure đã đi được bao xa để trở nên độc lập với hệ sinh thái Java? Liệu nó có thư viện thành ngữ riêng cho hầu hết các nhiệm vụ này và các nhiệm vụ khác không?


ClojureCLR là một cổng Clojure cho khung .Net.
SL Barth - Phục hồi Monica

1
Đối với sở thích của tôi, quá nhiều lõi Clojure được triển khai trong Java, nó không được khởi động đúng cách.
SK-logic

@Barth: Tôi biết các cổng đến các nền tảng khác tồn tại, nhưng điều này không nói nhiều về câu hỏi. Nó có thể chạy trên CLR và vẫn không có thư viện riêng.
Andrea

1
@JeremyHeiler, tất nhiên bất cứ ai có đầu óc tỉnh táo sẽ cố gắng đạt được mục tiêu như vậy. Câu hỏi là - tại sao Clojure không được thực hiện theo cách này ngay từ đầu? Nó dễ dàng hơn nhiều so với mã hóa trình biên dịch trong Java.
SK-logic

1
@ SK-logic, Từ những gì tôi có thể nói, các tính năng mà Rich Hickey muốn để khởi động Clojure đúng cách đã mất thời gian để đi đến kết quả. Đó là, anh ta không muốn vội vàng đưa ra các quyết định thiết kế có thể ảnh hưởng xấu đến ngôn ngữ, các quyết định có khả năng mang lại kết quả tốt hơn nếu dành nhiều thời gian hơn để suy nghĩ về cách các tính năng nhất định có thể hoạt động. Có thể tôi hoàn toàn tắt, nhưng đó là việc tôi tham gia vào chủ đề này.
Jeremy Heiler

Câu trả lời:


2

Clojure ngày càng trở nên độc lập hơn với các thư viện Java khi cơ sở mã của nó phát triển và đa dạng hóa một cách tự nhiên. Một điểm mạnh lớn của Clojure là nó có thể gọi Java, vì vậy để thấy mã Clojure trong tương lai không sử dụng java sẽ khó xảy ra. Điều đó đang được nói, tôi đã thực hiện rất nhiều sự phát triển với việc gọi các lib Java (dòng lệnh args, minupulation văn bản cơ bản, v.v.). Dưới đây là danh sách các thư viện clojure thuần túy: http://www.clojure-toolbox.com/


Tôi đã chọn câu trả lời này nhờ vào liên kết đến kho lưu trữ các thư viện Clojure thuần túy.
Andrea

7

Tôi nghĩ thật công bằng khi nói rằng Clojure được thiết kế như một ngôn ngữ được lưu trữ và hiện tại nó có ba triển khai:

  • Clojure trên JVM
  • ClojureCLR trên .NET
  • ClojureScript trên JavaScript

Bởi vì nó được thiết kế như một ngôn ngữ được lưu trữ, thành ngữ này là tận dụng các thư viện của nền tảng cơ bản, nơi nó có ý nghĩa nhưng cũng cung cấp một tập hợp các thư viện "lõi" có thể di động (từ một mức sử dụng, không nhất thiết phải ở cấp mã). Tôi hy vọng theo thời gian chúng ta sẽ thấy nhiều thư viện Clojure hơn chạy trên cả ba nền tảng, nơi nó có ý nghĩa.

Tôi duy trì clojure.java.jdbc và clj-time (trình bao bọc xung quanh JodaTime) để không sử dụng chúng trên các phiên bản * CLR hoặc * Script nhưng các thư viện tương thích API trong các không gian tên khác nhau có thể là một khả năng.

Nhiều thư viện Clojure "thuần túy" nên được sử dụng đơn giản trên các phiên bản * CLR hoặc * Script.

Đối với câu hỏi của OP: "Clojure-the-ngôn ngữ" khá dễ mang theo nhưng "Clojure-the-exec" bị ràng buộc một cách có chủ ý với hệ sinh thái Java, cũng như ClojureCLR với .NET và ClojureScript thành JavaScript.


2

Khi Clojure tiếp tục phát triển, nó chắc chắn sẽ xây dựng ngày càng nhiều thư viện của riêng mình, cho phép các cổng dễ dàng hơn đến các máy ảo khác. Theo như Clojure trên JVM, tôi tin rằng mục tiêu dài hạn sẽ là thay thế hầu hết các lib bằng các lựa chọn thay thế Clojure (do đó có tính bất biến theo mặc định, STM, v.v.), đưa lớp xen kẽ Java xuống mức cơ bản và cơ sở thấp nhất các đối tượng như String. Điều này đặc biệt đúng khi nền tảng Java được mô đun hóa bằng trò chơi ghép hình / OSGi trong Java 8 (2013)

Tuy nhiên, tôi tin rằng Clojure vẫn sẽ muốn thử và tận dụng inv invocate (được giới thiệu như một hướng dẫn mã byte trong Java 7) và sẽ có một cách tiếp cận khá thực tế về việc thư viện nào sẽ thay thế khi nào (nếu Java có lib hoàn toàn tốt, vậy thì tại sao thay đổi sớm).

LƯU Ý: Tôi không tham gia sâu vào cộng đồng Clojure, vì vậy đây là một phần tin đồn / phỏng đoán.


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.