Nhận định 1: “Ruby is not a silver bullet.”, thì từ hồi mới có máy tính và ngôn ngữ lập trình - tức là từ những năm 40 của thế kỷ trước - cho đến nay ai mà chả biết. Có lẽ mỗi ông chủ cửa hàng CD là không biết, nên mới coi đấy là một phát kiến gì ghê gớm lắm của chính ông ta. Sự thực là bất kỳ lập trình viên nào (nếu xứng đáng được gọi là lập trình viên) cũng phải biết cách nhận định, đánh giá công cụ cho mỗi dự án. Nếu một lập trình viên chỉ biết một ngôn ngữ, ví dụ Java, và project nào cũng đem ra dùng, thì chẳng khác nào trong tay hắn có một cái búa, và hắn nghĩ rằng thế giới này toàn những cái đinh.

Về hai nhận định 2 và 3, they are very questionable.
Khi xem xét một nhận định, một đánh giá hay một so sánh, bao giờ chúng ta cũng phải xem xét nó trong một ngữ cảnh, phạm vi nhất định.

Vậy ngữ cảnh của nhận định của ông chủ cửa hàng CD online này là gì? Ông ta xây dựng một Website để mua bán CD online. Xét về tính phức tạp của application, đây không phải là một ứng dụng phức tạp, chỉ có các yêu cầu về quản lý người dùng, quản lý số lượng CD tồn kho, quản lý việc nhận đơn đặt hàng, thanh toán và gửi CD cho khách hàng. Tóm lại, các vấn đề ở đây chỉ xoay quanh việc phát triển một giao diện Web, cho phép nhập, thêm, xóa, sửa thông tin và hiển thị thông tin từ một số lượng rất hạn chế các table trong database.

Đối với những ứng dụng đơn giản, nghĩa là dùng một vài trang Web để baby-sit một vài table trong database, thì dùng PHP để phát triển sẽ nhanh hơn và đơn giản hơn là dùng Ruby hay Java. Trên web site của tôi, hệ thống Content Management System cũng là PHP, chứ không phải Ruby hay Java, mặc dù tôi làm enterprise software bằng Ruby và Java hơn 10 năm nay.

Tuy nhiên, khi phát triển những enterprise software đòi hỏi những chức năng như sau đây, thì PHP không hể đáp ứng được:

- High-volume transaction database processing, ví dụ như những ứng dụng trong production system của Boeing, Airbus, Rolls Royce, Daimler-Benz, BMW …, và những ứng dụng tài chính, ngân hàng.

- Heavy and complex business processing: Trong enterprise software, phần xử lý dữ liệu và các quy luật kinh doanh trong sản xuất và tài chính ngân hàng là rất phức tạp, có sự tương tác giữa nhiều loại dữ liệu tổ chức theo nhiều cách khác nhau, đến từ nhiều nguồn.

- Inter-system collaboration: Trong những enterprise lớn, bao giờ cũng có nhiều chi nhánh, nhiều bộ phận, nhiều văn phòng ở những thành phố khác nhau, các nước khác nhau và các châu lục khác nhau. Thậm chí, các văn phòng còn có thể dùng các loại ứng dụng khác nhau trên nhiều hệ điều hành khác nhau, và từ nhiều kỷ nguyên máy tính khác nhau, từ thời mới có máy tính to bằng cái nhà cho đến các mini computer, multi-processor server và PC computer. Việc thống nhất một enterprise-information bus đòi hỏi khả năng tương tác cao của công cụ, hỗ trợ tốt multi-system integration và SOA.

- Internet high-volume consumer-based application, ví dụ như các ứng dụng có hàng tỷ người truy cập một ngày như e-Bay, Amazon, Akamai, Yahoo, Google …, nhất là các ứng dụng cho phép chia sẻ, tag, search các multimedia data như video, ảnh, audio …, thì PHP không thể làm được.

- Web Services, SOA design, RESTful development …

Còn khá nhiều lĩnh vựa khác, ví dụ như Rich-User-Interface app, Communication protocol imlementation, Multi-threading processing … thì ….

Còn các bạn muốn biết tại sao không thể làm được, thì làm ơn tự học hỏi, tự thử nghiệm và tìm tòi. Rất có thể là 10 năm sau các bạn mới tìm ra, nhưng như thế là còn may cho các bạn, vì có những người cả đời vẫn không tìm ra.

Về chuyện “Ruby cannot do anything better than PHP”, thì ông chủ cửa hàng CD này rõ ràng là ếch ngồi đáy giếng. Ngoại trừ những thứ Ruby làm được và PHP không làm được kể trên, thì tính ngay trong phạm vi Web-based application, Ruby có những ưu thế rõ ràng so với PHP.

- Ruby supports MVC 2, trong đó nó phân chia riêng biệt Model, View, Controller thành những component rõ ràng, khác biệt và dễ cài đặt. PHP supports only MVC 1, trong đấy PHP page vừa là model, vừa là view, vừa là controller. Nếu các bạn muốn học về sự khác biệt về MVC 1 và MVC 2 thì làm ơn đi học. Tong quá trình làm việc của tôi tại một công ty làm enterprise software tại Mỹ, tôi có đề ra thêm một mô hình nữa là mix- MVC.

- Ruby supports AJAX development: Trong Ruby, bạn có thể viết Ruby code theo phong cách OOP, kèm với RJS để tạo ra Web-based application với AJAX functionalities. Trong PHP, bạn phải dùng lẫn PHP code, HTML code, java script.

- Ruby support reuse of HTML partial views: Support này của Ruby thì cả PHP, J2EE và .NET đều không có, mặc dù cái gọi là include của PHP, J2EE và .NET cũng cho phép include một vài trình bày của HTML vào trong một file. Nhưngcác partial của Ruby cho phép cùng một partial nhưng có các data và cách hiển thị khác nhau, tùy theo cách partial đó được render như thế nào.

- Ngoài ra còn rất nhiều thứ khác như Unit Test, Code Block, Duck Typing …, làm cho chương trình Ruby dễ bảo trì, mở rộng, và được viết một cách ngắn gọn, súc tích hơn bất kỳ một ngôn ngữ (phổ biến) nào như PHP, Java, .NET… Hiện tại chỉ có hai ngôn ngữ có thể so sánh được với Ruby về cái đẹp của cú pháp là Smalltalk và Python.

Quay trở lại vấn đề của ông chủ cửa hàng CD online. Thứ nhất, nghề của ông ta là bán CD, chứ không phải làm software.
Thứ hai, căn cứ vào những gì ông ta viết, vì dụ như 85 người viết một cái application với hàng trăm nghìn dòng PHP code rải rác lung tung, thì rõ ràng vấn đề của ông ta là system design chứ không phải là coding và programming language. Nếu như ông ta có một system design kém, thì dù có viết bằng PHP, Ruby, Java, .NET hay Python hay viết bằng ngôn ngữ giời đi nữa, thì ông ta vẫn thất bại như thường.

Và việc ông ta thất bại trong việc dịch cái chương trình của ông ta từ PHP sang Ruby và Rails là minh chứng rõ ràng nhất cho cái gọi là Bad System Design. Ông ta cho rằng ông ta thuê được một lập trình viên giỏi Ruby để làm việc đó. Ông ta là chủ một cửa hàng CD, nên khó mà biết được thế nào là giỏi đối với ông ta. Hơn nữa, một lập trình viên giỏi không có nghĩa là một software architect giỏi. Anh ta có thể hoàn toàn viết code rất tốt ở mức object, nhưng khi ghép các component của một application lại, thì vẫn có thể tạo ra một ứng dụng vứt đi.

Việc ông ta trở lại dùng PHP, thiết kế lại chương trình, chia lại chương trình thành các module tử tế, vận dụng các nguyên tắc như DRY, YAGNI … và thành công, cũng là một minh chứng là ông ta đã có một system design kém trước đó, chứ không phải vấn đề là PHP hay Ruby.

Critical thinking
Thế kỷ 21 này là thời buổi mà ai cũng vào được Internet và ai cũng mở được blog. Vì thế, khi các bạn đọc một nhận định, đánh giá, phân tích thì phải dựa trên một vài tiêu chí khách quan, và phải có khả năng tư duy logic. Ở Tây, ngay từ thế kỷ 15 người ta đã có một bộ môn gọi là critical thingking.

Còn ở Việt nam thì rất tiếc là các bạn từ 4000 năm nay đã được dạy từ tuổi đi vườn trẻ là tất cả những gì người lớn nói đều đúng, tất cả những gì cô giáo dạy đều đúng, tất cả những gì trong sách viết đều đúng, và nguy hiểm nhất là các bạn mở rộng nó ra thành tất cả những gì có trong Internet đều đúng. Nếu tất cả đều đúng hết rồi, thì còn ai đi làm nghiên cứu làm gì, làm gì có gì mới để mà phát triển nữa? Vì thế, nếu các bạn nghĩ tất cả các giá trị đã được xác định là đúng trong mọi trường hợp, mọi phạm vi mọi thời đại, cái gì hôm qua đúng thì hôm nay vẫn đúng, thì cho đến giờ, loài người chắc vẫn có đuôi, sống ở trong rừng, ở trên cây và ăn hoa quả.

Khi nghiên cứu một nhận định, bao giờ cũng phải có phân tích, đánh giá:

- Phạm vi, ngữ cảnh, hoàn cảnh mà tác giả đưa ra nhận định.

- Độ tin cậy của tác giả. Ví dụ như một ông chủ cửa hàng CD nói về software development thì độ tin cậy khó có thể cao như một software architect. Ở đây, tôi rất thận trọng, và dùng chữ “khó có thể”, chứ không dùng chữ “không”, vì tôi sợ rằng những con vẹt 4000 năm sẽ hiểu nhầm chữ Ví dụ, và nghĩ rằng một người có vị trí đã xác định thì luôn nói đúng hơn người không có vị trí. It is not always the case. Ví dụ như những “nhà khoa học” đã đề nghị thiêu sống Giordano Bruno. Hoặc những giáo sư tiến sĩ vật lý của châu Âu và châu Mỹ lên tiếng chửi bới một anh nhân viên thư ký quèn không bằng cấp ở một Văn phòng quản lý bằng sáng chế phát minh ở Thụy sĩ - vâng, Albert Einstein. Hoặc những người theo thuyết tương đối của Einstein chửi bới thuyết bất định của Werner Heissenberg… Tuy nhiên normally thì một ông software architect thường là nói về software development dễ tin hơn một ông chủ cửa hàng CD.

- Khi không biết thì phải thử: Như trên đã nói, nhiều khi rất khó xác định được phạm vi, ngữ cảnh hay độ tin cậy của người phát biểu nhận định, nên khi bạn không biết thì phải thử. Ngày nay, vào Internet, nếu bạn chịu khó tìm tòi thì sẽ thấy nhiều Web site với nhiều giáo sư tiến sĩ đánh giá A tốt hơn B, đồng thời cũng nhiều Web site với nhiều giáo sư tiến sĩ khác đánh giá B tốt hơn A. Và các Web site này đều sử dụng logic hình thức tốt như nhau, they are written by doctor professors, after all. Vì thế nên nếu bạn không chắc chắn, thì chỉ có mỗi cách là phải thử. Vì thế nên mới có các quy trình gọi là pilot implementation và proof-of-concept implementation khi làm software project.

- Những gì đúng trong đa số trường hợp, không có nghĩa là nó đúng trong một trường hợp cụ thể. Đa số Tất cả, các con vẹt 4000 năm thân mến của tôi ạ.

- Những gì hôm qua đúng, hôm nay chưa chắc đã đúng. Vì thế, trừ khi các bạn nhất quyết làm thợ lập trình, ai dạy gì nghe nấy, thợ cả bảo xếp gạch thì xếp gạch, bảo trộn hồ thì trộn hồ, còn không thì phải luôn luôn để ý, tìm tòi, học hỏi, thử nghiệm, khám phá.

Ví dụ trực quan sinh động cho các con vẹt là cần thiết, nên tôi đưa ra một ví dụ. Nếu như các bạn đọc các Web site về lập trình Java, kể cả các Website của Sun, đều sẽ thấy nói là đối với String, nếu dùng s1 + s2 + s3 + s4 thì chậm hơn là dùng StringBuffer để append. Điều này đúng với Java từ 1.4 trở về trước. Đối với Java 6, các bạn thử xem cái nào nhanh hơn. viết thử một chương trình Java nhỏ để cộng chuỗi bằng “+” và “StringBuffer” , đo là biết ngay. Vì sao? Trên Internet có, Google có, MIT có giáo trình miễn phí. Các bạn vào được forum, thì cũng vào được Internet.

Nếu các bạn không có khả năng tư duy logic, không biết thế nào là critical thinking, thì tốt nhất là không nên làm nghề lập trình, mà nên làm diễn viên hài, và vở hài kịch tốt nhất có thể đóng được là “Đẽo cày trên Internet”.

(Không biết các bạn trẻ ngày nay có biết truyện ngụ ngôn “Đẽo cày giữa đường” hay không nữa? Xem ra thế hệ @ ngày nay còn thua xa các cụ nông dân kể truyện ngụ ngôn, hút thuốc lào, uống chè xanh và đi cày bằng trâu ngày xưa).