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ứ :D 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ứ.
