Ngày hôm nay, chúng ta sẽ chứng kiến
trận đấu giữa một bên đeo đai đỏ là một lập trình viên đặc biệt từ
Envato là anh Ryan Allen, đại diện cho ngôn ngữ Ruby, người đã xây dựng
phiên bản đầu tiên của FlashDen
bằng đôi bàn tay trần của anh. Và ở góc kia, người đeo đai xanh là
Michael Wales, một thành viên nổi tiểng trong cộng đồng PHP và
CodeIgniter. Trận chiến giữa PHP vs. Ruby bắt đầu!
Trước khi chúng ta bắt đầu
Chúng ta phải lưu ý một điều rằng dạng tranh luận này đơn thuần với mục đích cho vui và để học tập là chính. Có rất nhiều lần bạn sẽ lựa chọn PHP cho một dự án, và có nhiều lần khác bạn lại chọn Ruby. Tuy nhiên, mục tiêu của bài viết này là học cách làm thế nào và khi nào thì đưa ra quyết định đó. Những cuộc tranh luận kiểu này không phải để nói “ngôn ngữ của bạn tồi” mà theo cách để đưa ra lý do tại sao và trong những tình huống chắc chắn nào thì lựa chọn ngôn ngữ này hơn ngôn ngữ kia.
Trong trường hợp nào tôi nên sử dụng PHP và khi nào thì tôi nên dùng Ruby?
Các đối thủ
Đại diện cho ngôn ngữ Ruby là anh: Ryan AllenRyan Allen
là một kỹ sư phần mềm và hệ thống, người đang làm việc cho Envato. Anh đã xây dựng và hỗ trợ những phiên bản đầu tiên của Envato Marketplaces bằng framework Ruby on Rails, và bây giờ đang chăm sóc Tuts+, và một số hệ thống khác.Đại diện cho ngôn ngữ PHP là anh: Michael Wales
Michael Wales
là một lập trình viên web cho các cơ quan thuộc chính phủ Mỹ, và là một
người đóng góp tích cực vào các cộng đồng PHP và CodeIgniter.Và… Bắt đầu!
1 – . Anh quen thuộc với cả PHP và Ruby như thế nào?Ryan: PHP là một trong những ngôn ngữ lập trình đầu tiên mà tôi đã làm việc cùng (bên cạnh đó là ActionScript và một chút Visual Basic). Tôi bắt đầu xây dựng một số thứ bằng PHP vào năm 2001. Tôi đã làm việc hoàn toàn với nó như là một công cụ backend cho tới cuối năm 2005, khi Ruby (và Rails) thay thế vị trí của nó.
Michael: PHP là ngôn ngữ đầu tiên giới thiệu tôi tới thế giới phát triển web, vào năm 1999 — vì vậy tôi muốn nói rằng mình có một sự hiểu biết khá vững chắc về vị trí của nó trong ngành công nghiệp của chúng ta, lịch sử của nó và hướng đi mà nó đã dẫn đầu. Đối với Ruby, thì cũng giống như nhiều người khác, nó tạo được sự chú ý của tôi bằng việc có sự xuất hiện của framework Rails và sự thành công của trang web 37signals. Tôi có một sự hiểu biết tương đối chắc về Ruby, như là một ngôn ngữ kịch bản trong công việc quản trị hệ thống của mình (Capistrano) cũng như là một số dự án cá nhân (thư viện phát triển game Gosu và Rails). Tôi cảm thấy hơi xấu hổ khi phải thừa nhận rằng mình không quen thuộc với những phiên bản mới nhất của Rails và chắc chắn nó sẽ có trong danh sách những thứ mà tôi sẽ làm quen trở lại.
2 – . Anh có cảm thấy rằng ngôn ngữ anh dùng thì phù hợp hơn với người mới bắt đầu hay những người đã có kinh nghiệm? Ví dụ, nếu tôi khá mới đối với ngành này, tôi sẽ gặp nhiều khó khăn hơn khi học PHP hay Ruby?
Michael: Không may là tôi không thể đưa ra một câu trả lời dứt khoát — ít ra là không như bạn đang mong đợi, vì lẽ rằng PHP và Ruby là hai thực thể hoàn toàn khác nhau. PHP là một sự hỗn hợp của ngôn ngữ và web framework vào trong một gói, ngược lại Ruby là một ngôn ngữ lập trình cùng với một số framework có sẵn.
“Nếu sự tập trung của bạn là phát
triển web và đó là tất cả những gì bạn thực sự muốn làm ngay lúc này,
thì tôi sẽ dứt khoát khuyên bạn nên học PHP trước.”
Vì vậy, nếu sự tập trung của bạn là
phát triển web và đó là tất cả những gì bạn thực sự muốn làm ngay lúc
này, thì tôi sẽ dứt khoát khuyên bạn nên học PHP trước vì một số lý do
sau đây:- Bạn không cần phải hiểu một cách sâu sắc về System Administration hoặc cách triển khai tốt nhất để hoàn thành mọi thứ. Hầu như đối với tất cả các host thì bạn chỉ cần upload lên là xong.
- Bạn sẽ học được kiến thức ở mức thấp hơn của cách web làm việc; ví dụ, một request được truyền giữa client và server như thế nào (nó liên quan đến ứng dụng của bạn), chức năng của session là gì, những giới hạn của cookies, sự khác nhau giữa các phương thức request.
- Xét về ngôn ngữ Ruby (và tôi sẽ giả sử về framework Rails, dựa trên mức độ phổ biến rộng rãi của nó): công việc triển khai có thể khá phức tạp tại thời điểm này (mặc dù đã có sự hỗ trợ của những dịch vụ hosting như Heroku, nhưng bạn sẽ bị thiếu hụt mất cơ hội để học và hiểu ở mức thấp). Tôi nghĩ rằng sự thiếu hụt của kiến thức mức thấp là một nhược điểm chủ yếu của Rails, đứng ở góc nhìn triển khai cũng như góc nhìn phát triển — bạn có thể nhanh chóng và dễ dàng sử dụng session, cookies, tạo ra các controller insecure và destructive (thông qua phương thức GET request). Điều đó không có nghĩa là bạn không thể làm những thứ này tốt trong PHP, nhưng Rails hỗ trợ điểm này tốt hơn.
“Là một lập trình viên với 12 năm
kinh nghiệm, tôi đánh giá cao sự rút gọn mà framework Rails đã mang đến
cho ngành công nghiệp của chúng ta; nhưng đó chỉ là bởi vì tôi hiểu cái
gì đang thực sự diễn ra phía sau sân khấu.”
Nếu bạn muốn trở thành một nhà phát
triển (Web Developer, viết script System Administration, Game Developer,
API Developer), những người mà hiểu các khái niệm Khoa học Máy tính ở
mức thấp, lập trình hướng đối tượng nói chung và thúc đẩy các kỹ năng
suy nghĩ phản biện (Critical Thinking) — thì không cần phải nói, bạn hãy
bắt đầu bằng ngôn ngữ Ruby, nó là một ngôn ngữ lập trình thực thụ (nên
nhớ rằng, PHP là một web framework dưới hình thức là một ngôn ngữ lập
trình).Từ góc nhìn của một Web Developer, tôi nghĩ đây cũng là một nhược điểm của Ruby (và cả Python nữa) — đó là thực sự không có bất kỳ một điểm gia nhập ở mức trung bình nào (mid-level). Hoặc là bạn hiểu về giao thức HTTP, cùng với khả năng để viết stack của riêng bạn, top-to-bottom, hoặc là bạn phải đi cùng với một “framework tuyệt vời nào đó sẽ giúp bạn làm các thao tác về CRUD (Create, Retrieve, Update, Delete) dùm bạn”.
“Đây thực sự là sân khấu để PHP tỏa
sáng. Nếu bạn đang vượt lên phía trên ranh giới của CRUD, bạn không cần
phải có một sự hiểu biết sâu sắc của một HTTP server làm việc như thế
nào để biến giấc mơ của mình thành hiện thực.”
Ryan: Nếu phải dạy một
ai đó học lập trình từ đầu, thì tôi thích hướng dẫn họ sử dụng Ruby
(gác qua một bên về một số rắc rối khi thiết lập môi trường — tuy nhiên điều này đang ngày càng trở nên dễ hơn).
Một cách phổ biến để hướng dẫn ai đó bắt đầu (có lẽ sau khi giới thiệu
về biến và printing) là giảng giải về mảng (array) bằng một ví dụ về một
danh sách sản phẩm trong giỏ hàng, chúng ta xem ví dụ trong PHP trước:
Trước
đây khi tôi học PHP, tôi đã được dạy sử dụng các vòng lặp (cũng như là
tôi đã học trong ActionScript), khi sử dụng vòng lặp foreach thì ngắn
gọn hơn và ít bị lỗi hơn (và nó cũng giống trong ActionScript). Tôi đã
học tất cả về những thứ như $i=0, điều kiện dừng và giá trị tăng thêm.
Tất cả chúng dường như hơi khó hiểu! Đây là vòng lặp có chức năng tương
tự bằng ngôn ngữ Ruby:
Có
rất ít cú pháp ở đây, vòng lặp này thì đối với tôi sẽ dễ hiểu hơn rất
nhiều và dễ thực hiện. Nhưng với mục đích đầy đủ, tôi cũng đưa ra ví dụ
vòng lặp trong PHP sử dụng foreach:
Vâng,
nó thì thực sự cũng không đến nỗi tồi! Tôi thường khuyên bạn nên chỉ sử
dụng vòng lặp for để đếm đến 10 và những thứ giống vậy, vòng lặp
foreach thì dễ đọc và dễ dạy hơn và cũng khó phạm sai lầm hơn. Và các
vòng lặp tốt hơn, vì thế tôi sẽ sử dụng Ruby.3 – . Nhiều lập trình viên PHP chuyển sang Ruby sau một vài năm. Anh có nhận thấy hiện tượng này không, và nếu có thì theo anh tại sao hiện tượng này lại trở nên phổ biến? Thời điểm diễn ra nhiều nhất là khi nào?
Ryan: Thời điểm chuyển qua Ruby của tôi (vào năm 2005) khi xuất hiện Rails framework. Tôi cũng đã thử vọc vậy phát triển web bằng Python nhưng vì không có kinh nghiệm nên gặp một chút thời gian khó khăn, lúc đó tôi không biết nên làm cái gì hoặc nhìn đi đâu (nhưng tôi quyết định phải xây dựng một cái gì đó, vì vậy tôi bắt tay tiến hành!), nhưng tôi thực sự đã muốn sử dụng Python trong các hoạt động hàng ngày bởi vì tôi cảm thấy nó tốt hơn, được thiết kế cẩn thận hơn và tôi thích cú pháp của nó. Và bởi vì Snakes (con trăn – biểu tượng của ngôn ngữ Python) thì hấp dẫn hơn Elephants (con voi – biểu tượng của PHP).
ActiveRecord đúng là đáng kinh ngạc!
Tôi biết về các cơ sở dữ liệu quan hệ khá tốt nhưng tôi cảm thấy rất khó chịu khi phải viết đi viết lại những câu truy vấn SQL giống nhau. ActiveRecord đúng là rất, rất tuyệt vời! Ruby thì cũng gần giống như Python và tôi cũng hạnh phúc khi Larry (bất kể anh ấy là ai) có một framework mà tôi có thể trở nên bận rộn và bắt tay vào xây dựng các thứ. Vì vậy đối với tôi thì tôi yêu cái thư viện đó và cả cú pháp của nó nữa.
Ngày nay chúng ta có hàng đống những thư viện Ruby tuyệt vời được viết bởi những cá nhân tài năng, các thư viện như Sinatra (một web framework nhỏ), Nokogiri (một parser HTML/XML), Sequel (một thư viện database ở mức cao), RSpec (một thư viện kiểm thử tự động). Tất cả những thư viện này có thể cài đặt như là RubyGems mà tôi nhận thấy dễ dàng và thân thiện với người dùng hơn là làm việc với hệ thống PEAR của PHP.
Cộng đồng vẫn khá sôi nổi, thậm chí đã một số năm đã trôi qua, và các công ty cũng đang ráo riết tuyển dụng các lập trình viên Ruby giống như một thứ hàng quý. Ruby 1.9 thì cũng gần như nhanh bằng PHP, vì vậy có nhiều thời điểm để người ta chuyển qua Ruby!
Ruby 1.9 thì cũng gần như nhanh bằng PHP, vì vậy có nhiều thời điểm để người ta chuyển qua Ruby!
Michael: Tôi nghĩ rằng
điều này cũng là một quá trình hết sức tự nhiên của các lập trình viên
(từ Web Development để học thêm kiến thức về toàn bộ các ngôn ngữ lập
trình hướng đối tượng OOP và một bức tranh toàn cảnh về ngành Khoa học
Máy tính) nói chung — tôi biết vì đó cũng là một con đường mà tôi đã
trải qua.
“Tôi nghĩ sai lầm lớn nhất, cho đến
ngày nay, đó là thói quen nhặt lấy một ngôn ngữ lập trình và gắn chặt
với nó cho đến chết. Đó không phải là cách mà thế giới thực làm việc.”
Tôi xem bản thân mình là một
“Developer” — vì vậy có những trường hợp tôi chọn PHP (nếu chỉ có thời
gian rất ngắn — ngoài các thao tác CRUD, nó là ngôn ngữ mà tôi hầu như
quen thuộc nhất), có những lúc khác thì tôi chọn Ruby (triển khai thông
qua Capistrano hoặc các thao tác CRUD cơ bản bằng Rails) và thậm chí xa
hơn là Python — cái mà tôi thích cho các tác vụ Server Administration và
phân tích các loại file khác nhau.4 – . Thường thì, chúng ta xem ngôn ngữ hiện tại của mình là sự lựa chọn “tốt hơn” các ngôn ngữ trước đó. Nhưng có phải luôn là như vậy, hay nó chỉ “mới” xuất hiện? Có thể là những dòng code cũ của anh trông rất tồi bởi vì bây giờ anh là một lập trình viên dày dạn kinh nghiệm hơn xưa?
Michael: Tôi nghĩ các lập trình viên có thể rất thường chạy theo mốt kiểu “cái mới hay hơn cái cũ”. Đây là lý do tại sao nhóm của tôi luôn phải ngồi họp bàn kỹ lưỡng trước khi chúng tôi bắt đầu một dự án, chúng tôi phân tích các yêu cầu (trong cả thuật ngữ của người dùng và của developer — những thứ này có sự khác nhau rất lớn) và chúng tôi bàn luận về nó, cùng với rất ít sự tham chiếu đến các ngôn ngữ hoặc framework trong tâm trí. Tuần rồi chúng tôi đã phân tích một số GB dữ liệu log với Perl, tuần này chúng tôi xây dựng một ứng dụng mà chủ yếu hiển thị như một ExtJS GridPanel (bởi vì chúng tôi đã mở rộng các file lõi của CodeIgniter để quản lý bất kỳ trường hợp nào mà ExtJS ném ra ngoại lệ).
“Điều quan trọng là chúng ta có bao
nhiêu thời gian và làm thế nào để có thể tạo ra sản phẩm tốt nhất trong
khoảng thời gian đó?”
Ryan: Tất nhiên là một
số người (bao gồm cả tôi) thường thiết kế mọi thứ theo một cách chắn
chắn nào đó, và họ không muốn phải học lại và thay đổi tất cả những thói
quen mà phải vất vả lắm mới có được. Một khi bạn đã làm việc hiệu quả
với một cái gì đó, thì tại sao phải phiền toái thay đổi nó?Có một cách nghĩ khác là càng nhiều ngôn ngữ và công cụ mà bạn có kinh nghiệm, thì bạn sẽ có khả năng kết hợp những kỹ thuật và ý tưởng tốt nhất mà không cần quan tâm đến môi trường mà bạn đang làm việc trong đó (người ta nói về việc học LISP, nhưng tôi vẫn chưa học nó).
Các lập trình viên trẻ sẽ nhảy vào những thứ mới mẻ nhưng bạn sẽ trở nên già đi và trưởng thành hơn, bạn muốn làm việc cùng những công cụ nhỏ nhưng đơn giản và mạnh mẽ. Nếu bạn không sử dụng mọi đặc trưng và mọi thư viện có sẵn trong Ruby thì bạn có thể làm với những công cụ đơn giản và mạnh mẽ mà không gặp quá nhiều vấn đề.
5 – . Có những trường hợp nào khi anh có thể lựa chọn sử dụng Ruby cho dự án này, và PHP cho dự án khác (giả sử là anh có 100% quyền lựa chọn)?
“Nói ngắn gọn: phụ thuộc vào việc bảo trì.”
“Khi tôi lựa chọn công cụ, tôi
thường nghĩ về người nào sẽ phải bảo trì dự án đó nếu chẳng may tôi bị
tông bởi một chiếc xe bus (tai nạn xe máy, hoặc bất cứ cái gì giống
thế).”
Tôi chắc chắn sẽ không viết bất cứ cái gì bằng Haskell
hoặc LISP hay thậm chí F#, bởi vì chúng tôi sẽ phải khó nhọc lắm mới
thuê được ai đó có thể làm việc trên nó. Những tài năng có sẵn trong
công ty thì ảnh hưởng rất lớn đến quyết định của tôi.Có những trường hợp khác nơi mà tôi sẽ quan tâm đến ngôn ngữ, và đó là khi tôi tạo ra một sản phẩm dạng CMS để bán trên trang Code Canyon. Tôi sẽ không viết nó bằng Ruby bởi vì hầu hết các web hosting không hỗ trợ nó nhiều lắm. Ngược lại PHP thì đã có sẵn ở khắp nơi và các web designer lẫn các lập trình viên ít kinh nghiệm cũng quen thuộc với nó.
“Có những trường hợp khác nơi mà tôi sẽ quan tâm đến ngôn ngữ, và đó là khi tôi tạo ra một sản phẩm dạng CMS để bán trên trang Code Canyon.
Tôi sẽ không viết nó bằng Ruby bởi vì hầu hết các web hosting không hỗ
trợ nó nhiều lắm. Ngược lại PHP thì đã có sẵn ở khắp nơi và các web
designer lẫn các lập trình viên ít kinh nghiệm cũng quen thuộc với nó.”
Michael: Xem các câu trả lời của tôi tại #3/#4.6 – . Nếu tôi là một designer và đôi khi chỉ vọc vậy công việc phát triển, thì anh sẽ khuyên tôi nên chọn Ruby hay PHP?
Michael: Về mặt cá nhân, tôi đề xuất nên sử dụng framework Django của ngôn ngữ Python. Nó thì được thiết kế dành cho mục đích như vậy: có khả năng cho phép lập trình viên làm việc trên mô hình dữ liệu và hiển thị dữ liệu lên màn hình một cách nhanh nhất có thể, rất dễ dàng sử dụng đối với các designer để trình bày dữ liệu theo một cách thức phù hợp, trong khi lập trình viên tiếp tục làm việc trên các logic nghiệp vụ trong cùng một chu trình.
Ryan: Nếu bạn có kinh nghiệm kết hợp một số HTML và CSS cùng với nhau và upload chúng lên Server thông qua FTP, thì tôi có thể đề xuất sử dụng PHP, vì nó có một rào cản rất bé để bạn có thể gia nhập, bởi vì bạn cũng đã thân thuộc với cú pháp của nó rồi (code của nó được bao lấy trong thẻ <?php, sau đó upload nó tới server của bạn với đuôi là .php, và thế là hoàn thành!). Nhưng nếu bạn bắt đầu xem lập trình là công việc nghiêm túc, thì tôi gợi ý là bạn nên học thêm những thứ khác (chẳng hạn Ruby) để mở rộng tầm nhìn của mình.
“Khi mọi thứ bị sai, chính sự thiếu hụt kiến thức của bạn sẽ quay trở lại cắn bạn.”
7 – . Điểm đặc biệt nào ngôn ngữ của anh có mà các ngôn ngữ khác không có?
“Ruby thường được đánh giá cao, sôi động và quyến rũ.”
Đây là một bí mật: nếu PHP phát hành một phiên bản cập nhật chính thức cùng với một cú pháp thay thế (để giống với Ruby/Python hơn), và bao lấy thư viện chuẩn đang tồn tại vào trong một phong cách các thư viện phổ biến của Ruby (và làm cho nó nhất quán), và có những tương thích ngược với các phiên bản trước đây cùng khả năng tích hợp với code có sẵn, thì nó sẽ trở thành một sản phẩm không có đối thủ. Đừng nói với bất kỳ ai là tôi nói điều này nhé!
Michael: Dễ dàng triển khai, có một sự giới thiệu đơn giản với các khái niệm ở mức thấp hơn trong phát triển web và trên hàng trăm tài liệu và các bài thực hành thử-và-đúng thuộc loại tốt nhất.
8 – . Có một quan niệm chung rằng PHP đã đi rất xa và luôn là ngôn ngữ lập trình server-side phổ biến nhất trên web. Vâng, nhưng nó cũng là ngôn ngữ bị chê bai nhiều nhất. Tại sao lại có điều đó? Chắc chắn là có một lý do nào dó giải thích tại sao nó lại được sử dụng rộng rãi đến như vậy, phải không?
Michael: Tôi xin nhắc lại về PHP một lần nữa – dễ dàng triển khai, có một sự giới thiệu đơn giản với các khái niệm ở mức thấp hơn trong phát triển web và trên hàng trăm tài liệu và các bài thực hành thử-và-đúng thuộc loại tốt nhất.
Nhưng nghiêm túc mà nói — bởi vì rào cản để gia nhập vào PHP rất thấp, nên rất khó để có thể phân biệt sự khác nhau giữa một ai đó thực sự biết cái họ đang nói và một ai đó chỉ có cùng mức kỹ năng như bạn đó là có một không gian riêng dành cho blog. Thêm nữa, do bởi PHP đã tồn tại nhiều năm, vì vậy có rất nhiều nội dung ở ngoài kia — và không phải tất cả chúng đều tốt.
“Đây không phải là một vấn đề chỉ
PHP gặp phải– một cái nhìn qua loa tại W3Schools.com sẽ phá hủy những
giấc mơ của bất kỳ thành phần nào của xHTML, JavaScript, CSS hoặc PHP.”
Các lập trình viên PHP phải chịu đựng từ triệu chứng “không phát minh ở đây (not invented here syndrome)”.
Khi bạn đang học một ngôn ngữ lập
trình, thì rất dễ để tìm thấy một nguồn tài nguyên mà bạn cho là “đáng
tin cậy” (chúng có thể đã bị lạc hậu hoặc chỉ đơn giản là sai) và bạn
làm theo cái mà họ “dạy” bạn. Đây là một điều mà cộng đồng PHP cần phải
làm tốt hơn — trong việc lan tỏa phương pháp “đúng” để hoàn thành các
tác vụ nhất định nào đó. Tôi sẽ thừa nhận rằng — cộng đồng Ruby có điểm
thuận lợi ở đây, Rick Olson đã giải quyết phần xác thực (authentication)
cho mọi người khi anh ta tung ra plugin Restful-Authentication.Các lập trình viên PHP, trong một số năm đầu của họ, trải qua hội chứng “không phát minh ở đây (not invented here syndrome)” — cái mà tôi không tin là một thứ tồi (cho đến khi họ bắt đầu bán nó hoặc chuyển nó sang cho người khác). Tôi nghĩ cách suy nghĩ của một lập trình viên mới, đang trải nghiệm PHP lần đầu tiên, là họ thực sự muốn hiểu chính xác điều gì đang diễn ra — và PHP làm một công việc hoàn hảo “đưa cho họ đủ sợi dây thừng để treo họ lên” — bộc lộ đủ để học, nhưng bạn có thể sẽ làm tổn thương chính mình. Ngược lại, nếu không tính đến plugin của Rick (đó là một hệ thống authentication tuyệt vời), các lập trình viên Rails thì cho rằng mình đang đi đúng hướng và tiếp tục trên con đường của họ.
“PHP đã trở nên rất phổ biến bởi vì nó thì sinh ra đúng nơi và đúng lúc.”
Một thứ khác đã giúp PHP bùng nổ đó là những thứ như là sản phẩm cPanel và các nhà cung cấp hosting giá rẻ. Bất kỳ ai cũng có thể trở thành một web host giá rẻ mà không cần phải có kiến thức về kỹ thuật. Mọi người đều muốn có một trang web và hosting giá rẻ. PHP và MySQL là kho chuẩn về những thứ chia sẻ này, và chúng đã có mặt ở khắp nơi (và bây giờ vẫn thế). Sản phẩm tốt nhất không phải bao giờ cũng giành chiến ‘thắng’, cũng như rất nhiều người vẫn còn khó chịu về việc SmallTalk đã thất bại trước Java vậy.
9 – . PHP thì thường bị chỉ trích về tính luộm thuộm của nó. Nhưng, liệu đó có phải là do chính ngôn ngữ này nó như vậy, hay là do người dùng không quen với việc viết code chất lượng? Có rất nhiều cách để viết mã sạch bằng PHP dựa trên mô hình MVC.
Ryan: Điều này thì không dễ chịu lắm, nhưng tôi phải nói rằng những lời chỉ trích phổ biến về PHP thì tương đối đúng và là bởi vì cái cách mà “ngôn ngữ” này được thiết kế (hay nói đúng hơn, là không được thiết kế). PHP thì được sinh ra từ một số scripts CGI mà tác giả ban đầu viết bằng C (hoặc là Perl?).
Ruby thì trái hẳn lại, nó được thiết kế kết hợp những thứ tốt nhất từ một số ngôn ngữ lập trình để tạo một cái gì đó thú vị để làm việc, nó học hỏi từ Smalltalk, Perl, LISP và những ngôn ngữ khác.
“Một sự khác nhau rất lớn giữa PHP
và Ruby đối với tôi đó là Ruby khuyến khích bạn làm việc cùng với những
loại dữ liệu cơ bản như là Hashes (bảng băm) và Array (mảng) nơi mà tôi
chẳng bao giờ thấy chúng một cách tự nhiên trong PHP.”
Không có sự nhất quán trong thư viện
chuẩn của PHP, điều đó làm bạn nản lòng và nhiều khi muốn phát khùng.
Trong Ruby, thì tôi hiếm khi phải dành thời gian để đọc tài liệu về
những loại dữ liệu cơ bản, bởi vì những tương tác phổ biến thì rất dễ để
nhớ. Một khi bạn bắt đầu sử dụng các đặc trưng trong module Enumerable của Ruby, thì bạn sẽ tự hỏi làm thế nào mà mình lại sống được nếu thiếu nó.
Michael: Tôi nghĩ đây là một sự phản chiếu của cái rào cản thấp để gia nhập và kế thừa tính tò mò của các lập trình viên PHP để thực sự hiểu cái gì đang diễn ra. Tôi đã đọc/nghiên cứu hàng trăm cuốn sách, blog, bài viết về các hệ thống authentication — nhưng hầu như không thu được gì cho đến khi tôi tự xây dựng hệ thống của riêng mình thì tôi mới thực sự cảm thấy điều gì đang diễn ra. Tôi tin rằng những lập trình viên PHP mới thường háo hức chia sẻ sản phẩm mà họ đã hoàn thành cho phần còn lại của thế giới, và bởi vì họ không tuân theo những quy tắc tốt nhất hoặc các pattern đã được chứng minh là security.
10 – . Cộng đồng và tài liệu thì quan trọng hơn rất nhiều so với chính framework hoặc ngôn ngữ đó. Cộng đồng của Ruby hoặc PHP khi so sánh với các ngôn ngữ khác thì như thế nào?
Michael: Tôi nghĩ rằng cả PHP và Ruby đều có những vấn đề nghiêm trọng trong tài liệu của chúng — và bởi những lý do hoàn toàn trái ngược nhau.
PHP có hàng tấn tài liệu, vì nó đã tồn tại qua rất nhiều năm — bạn có thể tìm thấy câu trả lời cho bất kỳ câu hỏi nào cùng với một cú click chuột tìm kiếm nhanh trên Google. Đó có phải là giải pháp tốt nhất không? Có thể có, mà cũng có thể không…
“Rails đã phát triển một cách nhanh chóng, đến nỗi tôi cũng phải khó khăn lắm mới có thể luôn cập nhật.”
Ruby có tài liệu rất tuyệt vời, nhưng
trong thực tế có sự xuất hiện của những framework như Rails chẳng hạn.
Rails đã phát triển một cách nhanh chóng, đến nỗi tôi cũng phải khó khăn
lắm mới luôn cập nhật. Tài liệu về Rails API thì rất tuyệt; nhưng khi
nói đến các tài liệu của các hãng thứ ba (sách, bài viết trên blog, các
trả lời trên trang hỏi đáp StackOverflow) — thì tất cả chúng đều đã bị
lỗi thời và nếu làm theo cùng những thông tin này thì nó rất khó để gỡ
rối vấn đề và sửa nó.Trong mặt này, tôi tin rằng PHP có sự thuận lợi hơn vì có các framework riêng biệt (CodeIgniter, FuelPHP, Kohana, CakePHP, v.v…) có thể giảm nhẹ tác động theo một mức độ nào đó — nếu bạn đang sử dụng một trong những framework này, thì khá đơn giản để tìm câu trả lời dứt khoát cho vấn đề mà bạn đang tìm kiếm.
Ryan: Khi sử dụng PHP thì triết lý về tài liệu của nó dường như giống với ‘viết tài liệu một lần và cho phép mọi người bổ sung thêm phần của họ’.
Có rất nhiều các hàm API dùng chung được bao gồm trong lõi của PHP, chúng không thường xuyên thay đổi, vì vậy tôi nghĩ rằng một giải pháp dạng wiki sẽ thích hợp hơn. Theo cách đó thì cộng đồng có thể chỉnh sửa tài liệu chính thức, gợi ý những thay đổi, gợi ý những ví dụ, tích hợp những cái hay từ các bình luận vào trong tài liệu chuẩn. Điều này sẽ có ích hơn (đặc biệt đối với người mới bắt đầu).
Trong Ruby, có rất nhiều thư viện dùng chung trên GitHub, nơi mà mọi người có thể submit những thay đổi nhỏ để cải tiến, và tham gia vào chu trình phát hành đều đặn. Tài liệu thì đã có RDoc (cái cũng tương tự như PHPDoc), và khi bạn cài đặt thì nó cũng sinh ra tài liệu trên hệ thống cục bộ cho bạn. Đối với công việc của mình, tôi hoặc là sẽ đọc tài liệu chuẩn trên rubydoc.info, hoặc đọc tài liệu local trên máy tôi, hoặc trong bản thân mã nguồn của các thư viện.
