Discuss about Java

Chẳng mấy khi được nghe 2 cao thủ luận bàn, chẳng biết gì nên cứ copy về đây để bao giờ trình độ lên cao thì “nghiệm” vậy :”>

mega2look:
http://www.javavietnam.org/javavn/mvnforum/viewthread_thread,20372_offset,60#87886

Kính thưa các doanh nghiệp Việt Nam,

Hôm nay tôi xin thay mặt công ty SUN Microsystem gởi tới các đồng chí
lời chào thân ái và quyết thắng.

Chắc các đồng chí đều biết công ty chúng tôi là công ty hàng đầu về
bán server đã tối ưu để chạy công nghệ Java, dĩ nhiên công nghệ này
cũng của chúng tôi. Mặc dù tình hình kinh doanh của chúng tôi trong
những năm gần đây không được sáng sủa gì cho lắm, nhưng tôi đảm bảo
rằng chúng tôi vẫn là một trong những công ty hàng đầu trong vài năm
tới miễn là không thua lỗ nhiều quá, và đặc biệt là với sự ủng hộ vô
điều kiện của cộng đồng các nhà phát triển Java đầy tiềm năng tại Việt
Nam thì tương lai của SUN vô cùng sáng lạn.

Công ty chúng tôi chuyên cung cấp các giải pháp cỡ enterprise ở cả
phần mềm lẫn phần cứng. Trước hết tôi xin nói qua về giải pháp phần
mềm. Đây toàn là những phần mềm to vật vã, chức năng vô cùng khủng bố
hoàn toàn hợp với mác Enterprise mà các quí vị đang quan tâm. Để tạo
ra được phần mềm này các quí vị nên xem qua cái chuẩn J2EE (cũng do
chúng tôi định nghĩa ra nốt), nếu các vị chưa chóng mặt vì tầm mức vĩ
đại, kỳ vĩ của nó thì cũng sẽ phải thán phục trước độ phức tạp mà loài
người chưa từng hình dung ra từ trước tới nay.

Tất nhiên vệc phát triển các phần mềm loại này cũng vô cùng gian nan,
vất vả. Có những công việc mà nhẽ ra chỉ cần 2 dòng lệnh là làm được
thì chúng tôi tặng thêm cho quí vị 98 dòng lệnh nữa để phù hợp với tầm
mức của công việc tầm cỡ Enterprise. Số dòng lệnh dù có nhiều hơn chút
ít nhưng mang lại nhiều lợi ích xã hội to lớn như tạo ra vô số công
việc cho lập trình viên, tester và bảo trì. Hơn nữa tôi đố quí vị tìm
ra chỗ nào để rút bớt mà không ảnh hưởng tới mác Enterprise của phần
mềm này như J2EE, EJB…

Vì e rằng quí vị có thể bị nhồi máu cơ tim nên tôi không tiện nói giá
của giải pháp của chúng tôi ngay bây giờ, nhưng khi vận hành quí vị
chỉ cần bỏ vài trăm ngàn USD hàng năm là được đội ngũ chuyên gia lành
nghề của chúng tôi tận tình support. Hơn nữa, chúng tôi luôn cung cấp
giải pháp trọn gói với hy vọng sẽ phù hợp với tất cả các loại doanh
nghiệp dù ở Somali hay Afganistan. Việc customize trong trường hợp bất
khả kháng theo môi trường KD của Việt Nam sẽ được tiến hành theo đúng
trình tự enterprise, thường thì chỉ trong một vài năm là xong với giá
đặc biệt hữu nghị: chỉ gần bằng với giá giải pháp các vị đã mua.

Kết quả là sản phẩm của chúng tôi là dạng phần mềm khủng long, vô cùng
đồ sộ, khinh khủng. Tất nhiên, để vận hành các con khủng long này
chúng tôi đề nghị quí vị mua server của SUN. Tin mừng là do giá phần
cứng ngày càng rẻ nên giá server của chúng tôi đã hạ cả gần chục lần
so với thời kỳ dot-com (đây là một thời kỳ vàng son nhất của cty chúng
tôi). Giá server dòng bét nhất của chúng tôi giờ chỉ còn khoảng 10.000
USD và quí vị có thể mua về để chạy bản demo xem thử.

Nhưng do mức độ “khủng bố” của giải pháp phần mềm chúng tôi cung cấp
nên khi đưa vào vận hành trong môi trường thực tôi đề nghị quí vị nên
trang bị khoảng vài tá máy chủ tầm trung có giá từ 30.000 USD trở lên.

Đừng bao giờ tiết kiệm tiền mua server. Tôi xin kể ra đây trường hợp
một công ty có tên tuổi bày đặt dùng công nghệ Java mà lại thiếu tiền
sẽ dẫn tới hậu quả thế nào:

Friendster là mạng xã hội ra đời trước MySpace và Facebook và đã từng
thành công vang dội. Chắc quí vị cũng đoán ra, có được thành công đó
mạng này đầu tiên đã dùng Java lẫy lừng của chúng tôi. Nhưng không
hiểu sao nó càng ngày càng chậm, ngay cả tôi ở Mỹ mà phải 2 phút mới
load lên được một trang. Cuối cùng tôi đoán là do không đủ tiền mua
server của chúng tôi nên nó phải chuyển qua dùng một ngôn ngữ “rẻ
tiền” PHP. Tốc độ sau đó được cải thiện rõ rệt nhưng hậu quả là nó đã
mất hết người dùng ở Mỹ vào tay MySpace, FaceBook rồi. Mạng XH này bây
giờ vẫn rất nổi tiếng ở… Philipine.

Đây là bài học cho những ai muốn dùng Java mà lại không muốn bỏ ra số
tiền tương xứng. Quí vị có thể tham khảo thêm về bài học này ở đây:

* New York Times: Wallflower at the Web Party
* Hay bài viết này của SitePoint The J2EE guy still doesn’t get
PHP

Các bạn sẽ thấy chắc chắn kg phải do lỗi của Java mà hoặc là do bọn
Friendster nhà nghèo mà học đòi chơi sang hoặc là bị bọn làm PHP nó dụ
dỗ. To như Google mà cũng chẳng mấy khi dám dùng Java nữa là…

Đến đây chắc quí vị đồng chí Việt Nam đã hình dung ra mức độ hoành
tráng của giải pháp chúng tôi cung cấp rồi. Tôi xin đảm bảo rằng nếu
quí vị dùng trọn gói giải pháp của chúng tôi vài năm mà không phá sản
thì mọi người đều biết doanh nghiệp quí vị cũng thuộc hàng “khổng
tượng”, được thiên nhiên ưu đãi, tiêu tiền nhà nước không tiếc tay
kiểu như các doanh nghiệp NN về viễn thông, ngân hàng hay ít nhất là
quí vị có chân trong dự án 112. Tiếng tăm của DN quí vị sẽ ngày càng
lừng lẫy.

Chúc quí vị thành công với Java Enterprise!
_______________________________________________________

Rút ra được gì sau bài phát biểu này? Google không dùng Java mà dùng
Python, C#?

pcdinh: Google khởi đầu bằng C++ và vẫn cắm rễ trên C++
Sau đó vào năm 2005, Google tuyên bố chúng tôi có nhiều code Python
hơn code Java: http://www.sauria.com/~twl/conferences/pycon2005/20050325/Python%20at…

Google có dùng Java nhiều không thì cần hỏi kĩ sư của Google, Neal
Gafter, một người có ảnh hưởng lớn đến sự phát triển của Java và là
một người làm nên thành công của Google Calendar. Tương tự GMail cũng
có một phần backend là Java.

Mọi người vẫn nghĩ Java là chậm. Trên thực tế Java nhanh ngang ngửa
với C++ trong phần lớn các tác vụ liên quan đến computing. Cái khó
chịu của Java là tính phức tạp của nó và sự quan liêu của Sun trước
khi nó được mở mã nguồn. Làm việc với JDBC sẽ dễ chịu biết bao nếu
Java hỗ trợ multi-line string. Thế nhưng mấy bác ở Sun quan liêu thì
bảo là còn cần nghiên cứu để thống nhất mô hình foreign language. Đúng
là dân technical thuần túy của Sun chẳng hiểu cái đếch gì về time to
market hay easy to use. Năm 2005, Bob của Google phát hiện ra là phần
lớn lập trình viên Java mà anh ta tiếp xúc đều không biết cách viết
design pattern đơn giản nhất về implementation ở mức user land là
Singleton. Lý do Java quá phức tạp nên rất nhiều các cuốn sách Java
toàn viết nhăng viết cuội và cuối cùng là sai cả đám. Đó chỉ là các ví
dụ rất nhỏ để nói về tính phức tạp của Java mà phần nào lý giải tại
sao bản thân JVM thì rất nhanh nhưng rất nhiều ứng dụng Java lại ì
ạch. Thực ra đằng sau những ứng dụng ì ạch đó là crappy code, un-
maintainable, càng fix càng lỗi được viết bởi các lập trình viên Java
không hiểu về công nghệ mà mình đang làm việc trên nó. Đó đây tôi vẫn
thấy các lập trình viên có mác Java Lead Developer ở các công ty viễn
thông lớn của thế giới hồ hởi tuyên bố: Hibernate nhanh hơn JDBC. Thế
mới gấu biển chứ 😀 Java quá phức tạp. Từ hồi đẻ ra generic và
annotation tôi pó tay với Java luôn. Các công nghệ Java càng ngày càng
bloated, over-engineered làm người ta chỉ có khả năng viết theo
tutorial thôi chứ hiểu sâu thì chắc chịu thua. Tôi đã từng chứng kiến
một exception trace của Java lúc in ra dài đủ 12 trang giấy. Phong
cách lập trình wrapper của wrapper của wrapper ….. hay còn gọi là sự
trừu tượng hóa API để giải quyết sự khác biệt của các API khác mà bản
thân các API này cũng được sinh ra để giải quyết sự khác biệt của các
API khác …..Bên .NET nổi tiếng với thế hệ drag and drop rồi còn Java
chắc trong tương lai sẽ đẻ ra thế hệ copy and paste mất.

Google là một công ty BSD và Linux nên việc nói là họ dùng C# là
chuyện lạ, trừ khi để viết mấy cái API demo cho dịch vụ web của họ.
Những nguồn tin nói rằng Google dùng C# chẳng qua là từ Orkut, một
mạng xã hội mà Google mua lại được. Mạng đó dùng C# và .NET từ day
one. Nhưng do nó vô cùng chậm nên trước khi cho phép nó public chứ
không kín như trước thì Google có viết lại. Chẳng biết code legacy và
code mới chạy tỉ lệ như thế nào.

Giá máy chủ của Sun đâu có quá đắt so với hãng khác: http://www.sun.com/servers/index.jsp
Bắt đầu từ USD 700 . Không biết có ổ cứng chưa?

Tôi thì không khoái Python. Lý do: dùng whitespace để đánh dấu block
nên không thân thiện khi dùng nó làm ngôn ngữ template mà phải sáng
tạo ra một ngôn ngữ mới. Xem code Django. Dùng nó để xử lý text,
socket hay thread thì phù hợp. Tuy nhiên nó rất trong sáng, đơn giản.
PHP, Ruby và Python sẽ là các ngôn ngữ sống rất khỏe vì nó đơn giản về
cú pháp, cách tiếp cận vấn đề và tổ chức ứng dụng (bao gồm cả khâu
deployment). Tình hình này là đáng lo ngại với Java còn C# thì đang tự
giết chết chính nó với các bullet xếp ngày càng dài. Cộng đồng C# đang
còn bé tí nên sức căng của vấn đề này chưa lớn. Nhưng đến khi cỡ như
Java thì sẽ sụp đổ thôi. Java nên tập trung vào việc đơn giản hóa cú
pháp và tăng tính dễ sử dụng cho lập trình viên (ví dụ multi-line
string) chứ không nên theo đuôi chú C#. Nhìn cái closure trong Java 7,
tôi cảm thấy tính kém bền vững và sự lạm dụng kĩ thuật trong code của
Java sẽ ngày càng dài đặc thêm.

btnguyen2k: Comment bài viết 1 chữ thôi: XÀM!

Mà bác pcdinh cũng có vẻ không mặn mà với Java nhỉ 😉

Đồ sộ thì dĩ nhiên phức tạp, và kéo theo đó là khó mà thấu hiểu được
hết mọi thứ. Lập trình viên không hiểu hết về công nghệ, không dùng
đúng chỗ, đúng lúc thì code tồi là điển dĩ nhiên.
Cái này thì lập trình viên dùng công nghệ hay ngôn ngữ nào cũng thế
cả, đâu phải mỗi Java.

Ngôn ngữ nó giới thiệu những cái mới, nhưng nó cũng không bỏ những cái
cũ. Ai bắt lập trình viên phải theo cái mới đâu, anh vẫn có thể sử
dụng syntax cũ, không có vấn đề gì cả.

Geneeric của Java là xuất phát từ template của C++. Mà template của C+
+ đã được cả triệu lập trình viên C++ dùng bao năm nay rồi, khen nhiều
hơn chê. Không biết bác pcdinh “bó tay” với cái generic của Java vì lý
do gì?
Annotation của Java cũng là 1 cái rất hay, mà nó cũng chả phải là thứ
gì mới mẻ: @deprecated trong Javadoc cũng là 1 dạng annotation đấy
thôi. Chỉ có điều từ Java 1.5 thì Sun mới đẩy Annotation lên đỉnh cao
của nó.
phpDocumentor cũng dùng khá nhiều @name, 1 dạng ad-hoc annotation đấy
chứ. Cũng không hiểu bác pcdinh “bó tay” với annotation là vì sao?

Nói thực ra từ procedure programming lên OOP là cả 1 very huge jump!
PHP từ 1 ngôn ngữ lập trình thủ tục, nay đã bắt đầu lái lập trình viên
theo OOP và giờ là namespace.
1 huge jump với complexity từ procedure programming lên OOP phải nói
là cả trăm lần phức tạp hơn. Tại sao phải thế? Sự phát triển tự nhiên
nó thế. Không phải là người ta muốn cho nó phức tạp hơn, mà là đòi hỏi
của hệ thống ngày càng cao và phức tạp hơn nên ngôn ngữ lập trình cũng
tự nó phải phát triển lên nếu không muốn bị tàn lụi.
Nếu tới 1 ngày PHP cũng đòi 1 PVM để chạy thì nó cũng sẽ phải đi theo
còn đường “phức tạp hoá” như Java và .NET thôi. Đấy là con đường phát
triển tự nhiên.

Còn hiện tại, vẫn là 1 scripting language, nên rõ ràng quá trình
deployment của các ngôn ngữ như Ruby, Perl, PHP, v.v…đơn giản hơn
rất nhiều so với những món cần có VM để chạy như Java hay .NET.
Một bên mỗi lần chạy là script được compile lại (không tính trường hợp
gắn thêm “phụ kiện” nhé ;-)), còn một bên code được load lên VM 1 lần
rồi nằm yên ở đó thì nó phải khác nhau chứ.