Blog cộng đồng về Công nghệ thông tin

“Nó được thiết kế đơn giản.”

Có một quan điểm rằng Java được thiết kế để trở thành một ngôn ngữ đơn giản, hoàn hảo để giải quyết các tác vụ phổ biến. Nhưng đó không phải là những gì mà tôi đọc được từ lịch sử.

Nếu đọc về sự hình thành Java ở đây, chúng ta sẽ thấy một vài điểm thú vị. Lúc đó, Java (Oak) được viết cho một thiết bị cầm tay, và nó không được tung ra thị trường. Vì vây, nó được phát triển tập trung vào Applet và internet để rồi sau đó từ bỏ tất cả để đón nhận làn sóng internet bùng nổ.

Phải, Java ban đầu được thiết kế cho set-top box và applet. Ngày nay, nó được biết đến như một ngôn ngữ enterprise được sử dụng rộng rãi nhất, và applet cũng không còn nữa. Mục đích sử dụng đã thay đổi, vậy tại sao không nếu Java, chính nó cũng thay đổi?

Tôi nghĩ rằng quan điểm của những người cho rằng chính sự đơn giản của Java đã đem lại thành công cho nó là một quan điểm sai lầm. Tôi dám chắc rằng Java đã chỉ gặp may.

Vẫn chưa tin? Vậy hãy thử xem đoạn trích này từ bài viết Cuộc hành trình dài và kì lạ của Java của Patrick Naugton.

“[Biil Joy] thường so sánh Oak (Java) với các ngôn ngữ phức tạp hơn như Python và Beta. Anh ấy có thể nói rất nhiều về việc Oak sẽ tuyệt vời thế nào nếu có closures, continuations và parameterized types. Mặc dù đồng ý rằng đó là những thứ rất tốt nhưng tất cả chúng tôi đều hy vọng hoàn tất ngôn ngữ này để rồi tạo ra các ứng dụng thú vị với nó. Càng tranh luận với Bill về những điều này, anh ta càng phản đối dữ dội. Sau một hồi lại trở thành lựa chọn giữa việc hoặc không có Bill tham gia, hoặc mất khả năng kiểm soát ngôn ngữ. Jame và tôi tranh luận kịch liệt với Bill trong văn phòng ở Aspen của anh ấy vào một buổi chiều về vấn đề này. Anh ấy bắt đầu bằng việc chỉ trích rằng Oak sẽ tệ thế nào nếu so sánh với các ngôn ngữ tốt hơn khác và anh ấy tự nguyện từ chức nếu chúng tôi muốn. Jame và tôi nghĩ rằng đó có thể là giải pháp tốt và Bill đã đi ngay. Thật quá vội.

Điều thú vị là chúng tôi đã đúng về việc ngôn ngữ phải được hoàn tất dù thiếu một vài feature.Đây là vấn đề thời gian, chỉ có 3 tháng để hiện tượng Java xuất hiện. Chúng tôi chỉ vừa vặn thực hiện được điều đó. Một điều thú vị khác là Bill đã hoàn toàn đúng về những thức mà Java cần về lâu dài. Khi nhìn lại danh sách những thứ mà anh ấy muốn thêm vào, tôi hoàn toàn đồng ý. Anh ấy đã đúng, như vẫn thường như vậy.”

Như vậy, Java thành công là nhờ nó xuất hiện đúng thời lúc, đúng chỗ. Và để làm được điều này, đã phải có một số thoả hiệp. Cụ thể là đã phải bỏ lại một vài feature như: assertions, closures, enums, generics. Bỏ lại, không phải là để cho nó đơn giản mà là để kịp thời gian.

Cái gọi là “sự đơn giản của Java” chỉ là ảo tưởng. Nhưng thây đổi bây giờ chỉ là để hoàn tất công việc còn dang dở và cũng phù hợp với thực tại của Java là một ngôn ngữ enterprise.

“Không gì hết ngoài Java”

Một số trong cộng đồng Java dường như cuồng tín với Java và kịch liệt phản đối tất cả các thay đổi. Điều này khiến họ không sẵn sàng đối với các ngôn ngữ khác, với niềm tin rằng tất cả những thứ ngoài Java đều dở.

Tôi không đồng tình với quan điểm đó. Các ngôn ngữ khác vẫn tồn tại với điểm mạnh, điểm yếu riêng. Và chúng dạy cho chúng ta cái gì tốt, cái gì không – rằng chúng ta sẵn sàng nhìn ra ngoài Java và học.

“Nhìn vào generics thì biết!”

Generics được đưa vào Java 5 nhưng thật không may, đây có thể là thay đổi gây rắc rối. Với bản FAQ hơn 400 trang cố gắng giải thích các corner case kì lạ, có vẻ như có vấn đề ở đâu đó.

Ý nghĩ tiêu cực rút ra là: chúng ta không nên thay đổi Java nữa vì có thể sẽ “tạo ra một generics khác”. Đây chắc chắn là một quan điểm mang tính ‘phản động’. Khi thay đổi nào đó được đưa ra một cách cẩn thận, và ngăn ngừa các corner case, nó sẽ là một thay đổi tốt. Và cộng đồng Java sẽ phải test, và thúc đẩy nó.

“Code không quan trọng”

Nhóm khác, cho rằng code và syntax không quan trọng. Thay vào đó, cần chú trọng vào process, teamwork, test và kĩ năng giải quyết vấn đề.

Vấn đề này có hai mặt. Thứ nhất, vấn đề về process tác động bạn dù dùng ngôn ngữ gì đi nữa nên nó không cần xét tới khi bàn về những thay đổi của ngôn ngữ.

Thứ hai, họ đã không nhận ra rằng số dòng code (LOC) cũng là một vấn đề. Ít LOC có nghĩa là phải test ít hơn. Ít cấu trúc if đồng nghĩa với ít lỗi, ít phải test. Nhiều lỗi phát hiện trong quá trình dịch được giải quyết thì ít vấn đề gặp phải trong sản phẩm và ít test hơn. Và ít LOC cũng đồng nghĩa với hệ thống tin cậy hơn (số bug tỉ lệ với LOC)

Bạn có thể hiểu sai đoạn trên và nghĩ tôi cho rằng LOC là chỉ số duy nhất để tính toán sự thay đổi – Tôi hoàn toàn không nghĩ thế nhưng nó hoá ra lại quan trọng hơn chúng ta tưởng rất nhiều.

“Những developer mới sẽ không hiểu”

Vấn đề đào tạo và sự thay đổi ngôn ngữ đường như đã được thổi phồng quá. Developer không ngu dốt – ngay cả những người mới, thường gọi là Java-Joes. Hàng ngày, họ tương tác với các framework gồm hàng trăm class, phức tạp hơn rất nhiều so với những thay đổi đang được nói đến.

Trong thực tế, đa số những thay đổi lại là để đơn giản hoá những tương tác đó. Bằng việc rút ra các pattern thông dụng trong các framework, kiến thức về một framework này, có thể dùng được trong framework khác và các tương tác tổng thể có thể trở nên đơn giản và an toàn hơn rất nhiều.

Nếu chúng ta không thay đổi …

Ngày càng nhiều developer nhìn ra ngoài bức tường lớn Java, đáng chú ý nhất là Ruby và Groovy. Những người này, khi họ quay trở lại viết code Java, họ có xu hướng cảm thấy rất nản. Đoạn trích sau trong Javalobby của Ray Cromwell có thể cho thấy điều đó:

“Tôi đã lập trình Java gần 12 năm, và tôi gần như sắp từ bỏ nó. Nếu không phải là cho IntelliJ IDEA, thì có lẽ tôi đã bỏ nó từ năm 2002. Nhiều khi tôi cảm thấy điên đầu khi phải viết lại liên tục những dòng code giống nhau. Các Java IDE, Java framework, JSR, và các Java developer đều tìm cố gắng giải quyết các vấn đề mà có thể được thực hiện chỉ với một vài thay đổi nhỏ trong bản thân ngôn ngữ.”

Tóm lại

Java vẫn là lựa chọn enterprise. Nhưng ngày càng nhiều người bắt đầu nhìn ra ngoài Java. Họ nhận ra rằng việc chỉ phải viết 1/2 hay ít hơn số code quả thực là một điều hấp dẫn vì code sẽ sáng sủa và dễ hiểu hơn rất nhiều. Và sẽ còn tiết kiệm được nhiều thời gian hơn nữa.

Java sẽ không bao giờ trở thành Ruby hay Grooby, nhưng Java cần phải học một vài điều từ chúng. Không cần phải lo lắng về quá trình thay đổi ấy vì nếu làm tốt, được ắt sẽ nhiều hơn mất.

Lược dịch từ blog của Stephen Colebourne