PHP và Ruby: làm thế nào để tận dụng cả hai? Và điều đó có xứng đáng không? [đóng cửa]

Như bạn có thể nhận thấy từ tiêu đề, đây không phải là câu hỏi "PHP hay Ruby" hay câu hỏi "PHP so với Ruby". Đây là một câu hỏi về cách tận dụng PHP + Ruby trong cùng một doanh nghiệp.

Bản thân tôi là một nhà phát triển PHP, tôi yêu ngôn ngữ vì sự tiện lợi của nó và tôi đặc biệt yêu thích hệ sinh thái tài nguyên bao quanh nó: Joomla, Drupal, Wordpress, Symfony2, Doctrine2, v.v. Tuy nhiên, đôi khi chính ngôn ngữ này có thể gây thất vọng .

OTOH, Ruby trông giống như một ngôn ngữ rất hay và từ đó nghiên cứu nó một cách hời hợt ở một số khía cạnh. Tôi có thể nói nó gầy hơn Python như một ngôn ngữ. Tuy nhiên, từ những gì tôi thấy, có rất nhiều RoR chỉ gây ồn ào và tôi không thích RoR lắm (chủ yếu là vì lớp mô hình của nó).

Là đồng Giám đốc điều hành và CTO tại công ty của tôi, tôi đang cố gắng nghĩ xa hơn vì tôi muốn bắt đầu tập trung vào khía cạnh công nghệ của con người và xem liệu có nên sử dụng cả PHP và Ruby hay không. Dưới đây là một số suy nghĩ ngẫu nhiên:

• Dân gian Ruby nói chung có vẻ phù hợp với các lập trình viên hơn so với dân gian PHP (tính theo mức trung bình), tôi biết câu lệnh trước có phần hơi khó bởi vì PHP có thể được viết rất tốt và được kiến ​​trúc tốt, nhưng tôi nói rằng văn hóa lập trình viên Ruby tốt hơn PHP.
• Vấn đề của Ruby là nó có vẻ phù hợp hơn cho sự phát triển nhanh chóng, tôi thực sự không biết liệu đây chỉ là trường hợp của RoR, nhưng tôi biết rằng có một số thực tiễn nhất định (có lẽ không tốt lắm) như vá khỉ cho phép kinh doanh nhu cầu được bão hòa nhanh hơn.
• Từ quan điểm tiếp thị (vâng, đôi khi bạn cần tận dụng BS tiếp thị vì lợi ích của công ty bạn) Ruby có vẻ tốt hơn trong khi PHP mang theo một số điều kỳ thị.
• PHP 5.4 mang lại những đặc điểm và tốt hơn / sạch hơn mixins. Điều đó thực sự có thể làm cho PHP trở nên gọn gàng như Ruby Gianor nhiều hơn đối với một số thứ nhất định.

Bây giờ, cụ thể, câu hỏi của tôi:

• Một lập trình viên PHP có muốn học Ruby không?, Tôi biết tôi làm, nhưng ngược lại, một lập trình viên Ruby có muốn học PHP không?.
• Những loại dự án hoặc tình huống nào sẽ phù hợp hơn với Ruby không phù hợp với PHP?.
• Hệ sinh thái thực sự của Ruby là gì? Ngoài RoR, tôi chưa thấy các công nghệ / khung được thổi phồng khác (Tôi đã thấy RSpec, nhưng tôi thú nhận là hoàn toàn không hiểu về những gì BDD thực sự bao gồm và ý nghĩa của nó).
• Giả sử có một loại dự án nhất định lý tưởng cho Ruby, liệu có lúc nào tốt hơn để chuyển nó sang PHP không?. Tôi biết PHP có thể xử lý rất nhiều thứ, nhưng tôi đã đọc rằng Ruby có những hạn chế của nó khi nhân rộng (hoặc đó là RoR?, Hay đó là baloney cho cả hai?).
• Cuối cùng và quan trọng nhất, sẽ là lành mạnh để duy trì các dự án bằng hai ngôn ngữ?, Hoặc đó chỉ là ngu ngốc. Như tôi đã nói, có vẻ như Ruby nghiêng về ngắn hạn và điều đó có thể khiến một dự án xảy ra và thành công, nhưng tôi không chắc về điều đó về lâu dài.

Tôi đang tìm kiếm những hiểu biết chủ yếu từ những người biết rõ điểm mạnh và điểm yếu của ngôn ngữ mà cả hai đều là hệ sinh thái của họ và của Ruby trong thực tế, nghĩa là: các khung và ứng dụng như những gì tôi đã trích dẫn từ hệ sinh thái của PHP.

Hãy ghi nhớ, trong khi đọc câu trả lời của tôi, rằng trải nghiệm PHP của tôi (> 10 năm) cao hơn nhiều so với trải nghiệm Ruby của tôi (một vài tuần chơi với nó; chưa có dự án trực tiếp nào).

Một lập trình viên PHP có muốn học Ruby không?

Cá nhân, tôi đã đến với Ruby trong khi tìm kiếm một ngôn ngữ sạch hơn để phát triển web (đặc biệt là khi nhận thức được chuỗi đa chuỗi) và kịch bản phía máy chủ (các tập lệnh bash OSX của tôi dường như luôn có một hoặc hai khi chúng chạy trên tôi Máy chủ FreeBSD).

Trước khi thử nó, tôi đã từng chơi đùa với Lisp, Perl, Python và Node.js. Cuối cùng tôi đã từ bỏ Lisp vì thiếu một trình soạn thảo thích hợp (đó là emacs hoặc không có gì, và tôi ghét emacs với sự báo thù), sự kỳ lạ trong việc xây dựng một ứng dụng web (có các công cụ, nhưng chúng không cảm thấy tự nhiên khi sử dụng) và sự khó chịu thường xuyên (tôi đang theo dõi bạn car, cdrvà cons). Tôi nhanh chóng loại bỏ Perl cũng hôi thối như PHP khi nói đến nhận thức về chuỗi đa bào. Tôi không thích Python nhiều (nó chỉ là một thứ hương vị; tôi hoàn toàn không có lý do chính đáng). Và trong khi hứa hẹn, tôi vuốt ve Node.js khi còn quá trẻ và quá sức. (Tôi cũng đã xem Erlang, nhưng không bao giờ vượt quá hướng dẫn.)

Ngược lại, một lập trình viên Ruby có muốn học PHP không?.

(...) Cuối cùng và quan trọng nhất, sẽ là lành mạnh để duy trì các dự án bằng hai ngôn ngữ?

Tôi chỉ có thể nói cho chính mình ở đây, nhưng tôi càng chơi với Ruby, tôi càng cảm thấy muốn mắng mỏ mỗi khi đọc hoặc viết mã PHP.

Những loại dự án hoặc tình huống nào sẽ phù hợp hơn với Ruby không phù hợp với PHP?.

Bất cứ điều gì liên quan đến việc xử lý chuỗi UTF-8, đối với một - có thể bao gồm mọi thứ liên quan đến web. Nó giống như, vâng, trong PHP có các mb_*hàm; và các Intllớp học; và công cụ /usửa đổi cho các preg_*chức năng; và ... Với tư cách là một Junky Postky, tôi đã đến để xử lý UTF-8 như một cách nhất định. Đó là điều tôi không muốn lo lắng, đặc biệt là khi nói đến các thư viện, ngoài các vấn đề cụ thể về địa phương như trường hợp và đối chiếu.

(Nhân tiện, Ruby không hoàn toàn hoàn hảo về mặt này. Python tốt hơn một chút . Nhưng tôi muốn có mixins. Trong 15 năm mã hóa, tôi hiếm khi cần phải sắp xếp các chuỗi không phải ascii bên ngoài cơ sở dữ liệu, hoặc xử lý trường hợp vượt quá các bit và phần phiên âm làm cho nó thành URI.)

Shell scripting là một. PHP cũng có thể được sử dụng cho loại công cụ này, nhưng sự không nhất quán và lộn xộn của ngôn ngữ làm cho nó trở nên ít dễ chịu hơn.

Hệ sinh thái thực sự của Ruby là gì? Ngoài RoR, tôi chưa thấy các công nghệ / khung được thổi phồng khác (Tôi đã thấy RSpec, nhưng tôi thú nhận là hoàn toàn không hiểu về những gì BDD thực sự bao gồm và ý nghĩa của nó).

Thực tế có một số khung khác ngoài Rails: Merb, Camping, Ramaze, Sinatra, v.v ... Chỉ là RoR đã có rất nhiều sự cường điệu từ rất sớm.

Tôi đã đọc rằng Ruby có những hạn chế khi nhân rộng (hoặc đó là RoR?, Hay đó là baloney cho cả hai?).

PHP cũng vậy. :-)

Cá nhân, tôi nghĩ đó là baloney cho Ruby. Khi nhân rộng, trong bất kỳ ngôn ngữ nào, bạn nhìn vào các nút thắt cổ chai và làm việc từng cái một. Từ đó, bạn mở rộng quy mô theo chiều dọc và chiều ngang.

Bạn thay thế ngôn ngữ thú cưng của bạn khi thích hợp (ví dụ: tôi sẽ không chạy máy chủ trò chuyện hoặc một số dịch vụ tài chính hiệu suất cao bằng PHP hoặc Ruby). Nhưng nhìn chung theo kinh nghiệm của tôi, ngôn ngữ không phải là cốt lõi của vấn đề khi mở rộng quy mô, bất kể nó chậm đến mức nào - kiến ​​trúc. (Nếu ngôn ngữ là cốt lõi của vấn đề, các trang web sẽ chủ yếu được viết bằng C, C ++, C #, Java, Lisp, Erlang, v.v. Mỗi ngôn ngữ sau đều vượt trội so với PHP và Ruby theo một hoặc hai bậc độ lớn.)

Đối với RoR, tôi không thể nói. Tôi chỉ nhìn vào nó một cách hời hợt. Tôi hoàn toàn hiểu tại sao hoặc làm thế nào RoR sẽ làm hài lòng một nhà thiết kế đồ họa hoặc một sinh viên CS. Nó xúc phạm tất cả mọi thứ tôi đến để được cấp như một nhà phát triển cơ sở dữ liệu.

Sau đó, tôi đã gặp phải một cơn thịnh nộ của Zed Shaw (một người đã viết một máy chủ web Ruby). Trong số những thứ khác, anh ta đã chế giễu người tạo Rails vì không thể giữ các máy chủ sản xuất của riêng mình chạy trung bình hơn 4 phút. (Điều này đã được cải thiện kể từ đó.)

Thành thật mà nói (các) câu hỏi của bạn dường như không rõ ràng với tôi, nhưng tôi sẽ cố gắng trả lời chúng.

Một lập trình viên PHP có muốn học Ruby không?, Tôi biết tôi làm, nhưng ngược lại, một lập trình viên Ruby có muốn học PHP không?.

Không xúc phạm, nhưng câu hỏi này là không thể trả lời. Nó thực sự phụ thuộc vào quá nhiều yếu tố, nhiều yếu tố gắn liền với tính cách của lập trình viên. Câu trả lời dễ dàng: Tất nhiên, tại sao không? Đó là một công cụ nữa để xây dựng trang web.

Những loại dự án hoặc tình huống nào sẽ phù hợp hơn với Ruby không phù hợp với PHP?.

Đối với các dự án, cả hai đều phù hợp (nếu tôi nhớ rõ, ruby ​​chạy chậm hơn, mặc dù điều này là để lấy một chút muối kể từ AFAIK, stackchange được xây dựng với RoR [Tôi không bao giờ đọc điểm chuẩn thực tế]). Một tình huống sẽ phù hợp hơn một tình huống khác là nếu bạn có ý định sử dụng một khung cụ thể hoặc nếu nhóm của bạn bao gồm những người có nhiều kinh nghiệm hơn về một trong hai ngôn ngữ. Tôi thực sự không nghĩ rằng có bất kỳ loại dự án xác định nào là "lý tưởng" cho bất kỳ ngôn ngữ cụ thể nào. Nó thực sự nắm rõ các chi tiết cụ thể của từng dự án (và thậm chí sau đó, sự khác biệt sẽ là tinh tế).

Hệ sinh thái thực tế của Ruby là gì? Ngoài RoR, tôi chưa thấy các công nghệ / khung được thổi phồng khác.

Ruby on Rails là một phần rất lớn trong thành công của Ruby. Ruby ở lại một ngôn ngữ không rõ cho đến khi RoR lăn ra. Có rất nhiều dự án thú vị được xây dựng trên Ruby, nhưng không có gì đến gần về mặt thành công và sự chấp nhận của cộng đồng. Có những CMS được xây dựng trên RoR khá nổi tiếng. Lovd by Less chẳng hạn.

Giả sử có một loại dự án nhất định lý tưởng cho Ruby, liệu có lúc nào tốt hơn để chuyển nó sang PHP không?.

Trường hợp duy nhất tôi có thể tưởng tượng là ngay sau khi tạo mẫu bằng Ruby, nếu bạn cảm thấy PHP sẽ mang lại sự phát triển nhanh hơn. Nhưng một khi dự án được bắt đầu, bạn dự định "chuyển nó sang PHP" như thế nào? Cổng tất cả các mã đã được viết?

Cuối cùng và quan trọng nhất, sẽ là lành mạnh để duy trì các dự án bằng hai ngôn ngữ?

Nếu bạn không có bazooka chỉ vào đầu của bạn, hoàn toàn không.
Nếu bạn có nghĩa là duy trì hai dự án hoàn toàn khác nhau bằng hai ngôn ngữ khác nhau, thì hoàn toàn. Tôi không nghĩ bạn sẽ đi trong một khoảng thời gian dài với cùng một ngôn ngữ. Ví dụ, tôi liên tục nhảy từ ngôn ngữ này sang ngôn ngữ khác. Tôi chỉ thành thạo một vài người, nhưng tôi biết đủ những người khác để thoát khỏi mọi tình huống (cho đến bây giờ). Tôi là freelancer nên những người làm việc trong các công ty có thể có một trải nghiệm khác. Nhưng quan điểm của tôi là, duy trì các dự án khác nhau bằng các ngôn ngữ khác nhau là dễ dàng (đủ) và thú vị.

Nếu bạn muốn thực hiện một số phát triển ứng dụng máy tính để bàn và muốn sử dụng cùng một ngôn ngữ lập trình, thì Ruby (đặc biệt là JRuby) sẽ phù hợp hơn PHP. /programming/1129383/non-trivial-desktop-apps-that-use-ruby

Khi đọc, hãy nhớ rằng tôi là Nhà phát triển Ruby on Rails và trả lời từ hệ sinh thái đó. Quan điểm của tôi sẽ bị nghiêng theo hướng đó.

Một lập trình viên PHP có muốn học Ruby không?, Tôi biết tôi làm, nhưng ngược lại, một lập trình viên Ruby có muốn học PHP không?

Hoàn toàn không, trong hầu hết các trường hợp. Không chỉ vì tôi không thích PHP (tôi không, nhưng tôi sử dụng nó), mà bởi vì các bộ công cụ có những khác biệt lý tưởng cơ bản. Có rất nhiều công cụ như cào và rspec hỗ trợ một số cho TDD trong thế giới ruby. Trong hầu hết các thử nghiệm hướng dẫn ruby ​​(và chắc chắn đường ray) đến đầu tiên. Điều đó không có nghĩa là bạn không thể làm điều này trong PHP, chỉ là các quy ước là khác nhau. Và sự khác biệt thông thường giữa hai ngôn ngữ nói chung là đối lập trực tiếp.

Những loại dự án hoặc tình huống nào sẽ phù hợp hơn với Ruby không phù hợp với PHP?.

Các ứng dụng máy tính để bàn, kịch bản shell, ứng dụng MVC (một lần nữa) và các ứng dụng bảng điều khiển nhỏ. Không phải bất kỳ điều nào trong số này không thể được thực hiện với php, Ruby chỉ cần hỗ trợ tốt hơn. Khi viết một ứng dụng Rails (xin lỗi) tôi thường viết một đoạn script bằng ruby. Điều này cho phép các tập lệnh triển khai hoặc thiết lập của tôi có cùng ngôn ngữ với ứng dụng của tôi, trong đó với PHP tôi thậm chí sẽ không bao giờ thử viết một tập lệnh shell trong PHP. Tôi sẽ chỉ sử dụng bash. Tôi đã viết các ứng dụng Ruby QT và các ứng dụng MVC (cả Rails và không) và ruby ​​và các lib xung quanh chỉ "hoạt động tốt hơn" cho những trường hợp đó.

Hệ sinh thái thực sự của Ruby là gì? Ngoài RoR, tôi chưa thấy các công nghệ / khung được thổi phồng khác (Tôi đã thấy RSpec, nhưng tôi thú nhận là hoàn toàn không hiểu về những gì BDD thực sự bao gồm và ý nghĩa của nó).

Đây là một loại quan niệm sai lầm. RoR rất phổ biến vì nó hoạt động tốt, nhưng có thể có các bộ công cụ / ngăn xếp khác sử dụng ruby ​​ở lõi của chúng. Chúng ít phổ biến hơn vì đang xâm nhập vào một không gian đã có sẵn các lựa chọn thay thế. Tôi cho một người như viết các ứng dụng GUI nhanh bằng ruby. Nhưng python, C #, VB, LISP, v.v ... có thể đã làm điều này. RoR là một người thay đổi cuộc chơi. Vì vậy, nó phổ biến. Điều tương tự cũng có thể nói với PHP, đặt tên cho một khung công tác PHP phổ biến. Có một số, nhưng loại bỏ các sản phẩm (như wordpress) khỏi danh sách, và không còn lại của bạn với rất nhiều.

Giả sử có một loại dự án nhất định lý tưởng cho Ruby, liệu có lúc nào tốt hơn để chuyển nó sang PHP không?. Tôi biết PHP có thể xử lý nhiều thứ, nhưng tôi đã đọc rằng Ruby có những hạn chế của nó khi nhân rộng (hoặc đó là RoR?, Hay đó là baloney cho cả hai?)

Đây là một câu hỏi khó và bạn phải hỏi, ngôn ngữ nào tốt hơn cho dự án của tôi? Tôi sẽ không bao giờ viết một blog trong Rails. Tôi biết đó là ví dụ hướng dẫn tiêu chuẩn, nhưng nếu bạn muốn có một blog thì wordpress là công cụ thích hợp. Áp dụng tương tự ở đây. Nếu bạn gặp phải một ví dụ chắc chắn về việc cần phải chuyển ngôn ngữ khỏi ruby, những hạn chế kỹ thuật bạn sẽ gặp cũng sẽ loại trừ PHP.

Cuối cùng và quan trọng nhất, sẽ là lành mạnh để duy trì các dự án bằng hai ngôn ngữ?, Hoặc đó chỉ là ngu ngốc. Như tôi đã nói, có vẻ như Ruby nghiêng về ngắn hạn và điều đó có thể khiến một dự án xảy ra và thành công, nhưng tôi không chắc về điều đó về lâu dài.

Ruby là tuyệt vời trong thời gian dài. Trở ngại lớn nhất cho thành công lâu dài không phải là ngôn ngữ, mà là nhà phát triển. Để duy trì hai langues, nó phụ thuộc vào cách bạn xác định một dự án. Tôi có một vài dự án có ứng dụng nặng trong đường ray và blog hoặc trang web bán hàng sử dụng wordpress / dupral / một số php. Tôi coi họ là những dự án riêng biệt. Tôi sẽ nói rằng cuối cùng bạn càng hỗ trợ nhiều ngôn ngữ, bạn càng khó tìm được một nhà phát triển tốt, tốt trong tất cả các ngôn ngữ. Ví dụ, tôi sử dụng và giới thiệu wordpress, nhưng tôi không ở đâu là "tốt" trong PHP như tôi ở RoR. Nếu một khách hàng thực sự muốn một nửa sản phẩm cốt lõi của họ bằng PHP và một nửa trong RoR, tôi thực sự sẽ phải tìm hiểu tại sao, và tùy thuộc vào câu trả lời của họ có thể sẽ từ chối công việc.