PHP e Ruby: como aproveitar os dois? e Vale a pena? [fechadas]


8

Como você deve ter notado no título, essa não é uma pergunta "PHP ou Ruby" ou "PHP vs. Ruby". Esta é uma pergunta sobre como alavancar o PHP + Ruby no mesmo negócio.

Eu mesmo sou desenvolvedor de PHP, amo a linguagem por sua conveniência e, especialmente, o ecossistema de recursos que a rodeia: Joomla, Drupal, Wordpress, Symfony2, Doctrine2, etc. No entanto, a própria linguagem pode ser um pouco decepcionante às vezes .

OTOH, Ruby parece uma linguagem muito bonita e - estudando superficialmente em vários aspectos - eu poderia dizer que é mais enxuto do que o Python como uma linguagem em si. No entanto, pelo que vi, há praticamente apenas o RoR fazendo barulho, e eu não gosto muito do RoR (principalmente porque a camada do modelo).

Como co-CEO e CTO da minha empresa, estou tentando pensar fora da caixa, pois quero começar a me concentrar no lado humano da tecnologia e ver se é sensato usar PHP e Ruby. Aqui estão alguns pensamentos aleatórios:

  • O povo Ruby geralmente parece ser um programador mais adequado que o PHP (em termos de médias), eu sei que a declaração anterior é um tanto idiota porque um PHP muito bom e bem arquitetado pode ser escrito, mas eu diria que a cultura do programador Ruby é melhor do que PHP.
  • O problema do Ruby é que ele parece mais adequado para o desenvolvimento rápido. Realmente não sei se esse é apenas o caso do RoR, mas sei que existem certas práticas (talvez não tão boas) como a aplicação de patches de macaco que permitem aos negócios precisa ser satisfeito rapidamente.
  • Do ponto de vista de marketing (sim, às vezes você precisa alavancar a BS de marketing para o bem da sua empresa) Ruby parece melhor enquanto o PHP carrega alguns estigmas.
  • O PHP 5.4 está trazendo características , e isso é melhor / mais limpo que o mixins. Isso poderia realmente tornar o PHP tão enxuto quanto Ruby - ou mais - para certas coisas.

Agora, concretamente, minhas perguntas:

  • Um programador PHP gostaria de aprender Ruby ?, eu sei que sim, mas por outro lado, um programador Ruby gostaria de aprender PHP ?.
  • Que tipos de projetos ou situações seriam mais adequados para Ruby que não são adequados para PHP ?.
  • Qual é o ecossistema atual do Ruby ?, além do RoR, eu não vi outras tecnologias / estruturas sensacionalistas (já vi o RSpec, mas confesso ser um noob total no que o BDD realmente consiste e suas implicações).
  • Supondo que haja um certo tipo de projeto ideal para Ruby, haveria um momento em que seria melhor movê-lo para o PHP ?. Eu sei que o PHP pode lidar com muitas coisas, mas eu li que Ruby tem suas limitações ao escalar (ou é o RoR ?, ou isso é besteira para os dois?).
  • Finalmente e mais importante, seria sensato manter projetos em dois idiomas ?, ou isso é apenas estúpido. Como eu disse, parece que Ruby é mais enxuto no curto prazo e isso pode fazer um projeto acontecer e ter sucesso, mas não tenho tanta certeza disso a longo prazo.

Estou procurando idéias principalmente de pessoas que conhecem bem os pontos fortes e fracos das linguagens - de preferência as duas - e o ecossistema de Ruby na prática real, o que significa: estruturas e aplicativos como os que citei no ecossistema do PHP.

Respostas:


7

Lembre-se, ao ler minhas respostas, que minha experiência em PHP (> 10 anos) é muito maior que minha experiência em Ruby (algumas semanas jogando com ele; ainda não há projeto ao vivo).

Um programador de PHP gostaria de aprender Ruby?

Pessoalmente, eu vim para o Ruby enquanto procurava uma linguagem mais limpa para o desenvolvimento da Web (especialmente quando se trata de reconhecimento de cadeia de bytes múltiplos) e scripts do lado do servidor (meus scripts bash do OSX sempre parecem ter um ou dois niggle quando executados no meu Servidor FreeBSD).

Antes de tentar, eu estava brincando com Lisp, Perl, Python e Node.js. Acabei abandonando o Lisp por causa da falta de um editor adequado (é emacs ou nada, e eu odeio o emacs com vingança), a estranheza na construção de um aplicativo da Web (existem ferramentas, mas elas não parecem naturais de usar) e as peculiaridades ocasionais (estou observando você car, cdre cons). Eu rapidamente descartei o Perl tão fedorento quanto o PHP quando se trata de reconhecimento de cadeias multibyte. Eu não gostei muito de Python (é apenas uma coisa de gosto; não tenho absolutamente nenhuma razão válida). E apesar de promissor, considero o Node.js muito jovem e exagerado. (Também considerei Erlang, mas nunca fui além de um tutorial.)

Por outro lado, um programador Ruby gostaria de aprender PHP ?.

(...) Finalmente e mais importante, seria sensato manter projetos em dois idiomas?

Só posso falar por mim aqui, mas quanto mais brinco com Ruby, mais sinto vontade de vomitar sempre que leio ou escrevo código PHP.

Que tipos de projetos ou situações seriam mais adequados para Ruby que não são adequados para PHP ?.

Qualquer coisa que envolva manipulação de strings UTF-8, por exemplo - que sem dúvida inclui tudo relacionado à Web. É como, sim, no PHP existem as mb_*funções; e as Intlaulas; e o /umodificador para as preg_*funções; e ... Como um viciado em PostgreSQL, vim considerar o manuseio de UTF-8 como um dado. É o tipo de coisa com a qual não quero me preocupar, especialmente quando se trata de bibliotecas, além de problemas específicos de localidade, como caso e agrupamento.

(Ruby não é absolutamente perfeito a esse respeito, a propósito. Python é um pouco melhor . Mas eu prefiro mixins. Em 15 anos de codificação, raramente preciso classificar seqüências não-ascii fora de um banco de dados, ou identificador de caso, além da transliteração de partes e partes que o transformam em um URI.)

O script de shell é outro. O PHP também pode ser usado para esse tipo de coisa, mas as inconsistências e confusão da linguagem a tornam muito menos agradável.

Qual é o ecossistema atual do Ruby ?, além do RoR, eu não vi outras tecnologias / estruturas sensacionalistas (já vi o RSpec, mas confesso ser um noob total no que o BDD realmente consiste e suas implicações).

Na verdade, existem várias outras estruturas além do Rails: Merb, Camping, Ramaze, Sinatra, etc.

Eu li que Ruby tem suas limitações ao dimensionar (ou é RoR ?, ou isso é besteira para ambos?).

O mesmo acontece com o PHP. :-)

Pessoalmente, acho que é bobagem para Ruby. Ao dimensionar, em qualquer idioma, você observa os gargalos e trabalha neles um por um. A partir daí, você dimensiona vertical e horizontalmente.

Você substitui sua linguagem de estimação quando apropriado (eu não executaria um servidor de bate-papo ou algum serviço financeiro de alto desempenho em PHP ou Ruby, por exemplo). Mas, em geral, na minha experiência, a linguagem não é o cerne do problema ao dimensionar, por mais lenta que seja - a arquitetura é. (Se a linguagem estivesse no centro do problema, os sites seriam escritos principalmente em C, C ++, C #, Java, Lisp, Erlang, etc. Cada um deles supera o PHP e o Ruby em uma ou duas ordens de magnitude.)

Para RoR, não posso dizer. Eu apenas olhei superficialmente. No entanto, compreendo perfeitamente por que ou como o RoR satisfaria um designer gráfico ou um estudante de CS. Insultava tudo o que eu tinha como certo como desenvolvedor de banco de dados.

Mais tarde, esbarrei em um longo discurso de Zed Shaw (um cara que escreveu um servidor web Ruby). Entre outras coisas, ele zombou do criador do Rails por não conseguir manter seus próprios servidores de produção em execução por mais de 4 minutos, em média. (Isso melhorou desde então.)


Concordo plenamente que, depois de aprender o básico do Ruby, o PHP agora me dá náusea e vômito. Quanto ao Rails, o objetivo principal do Active Record é ser um ORM e permitir que os desenvolvedores, que talvez não sejam bem versados ​​no design de banco de dados, façam coisas básicas do banco de dados, mantendo-os longe da maioria dos problemas. Se você pode escrever SQL enquanto dorme, o Active Record parecerá bastante restritivo e talvez até "embotado". Mas acho que vale a pena, mesmo que seja mais fácil escrever código bom do que escrever código ruim ou, pior, código com falhas de segurança.
Michael Hampton

2

Francamente, suas perguntas não parecem claras para mim, mas mesmo assim tentarei respondê-las.

Um programador PHP gostaria de aprender Ruby ?, eu sei que sim, mas por outro lado, um programador Ruby gostaria de aprender PHP ?.

Sem ofensa, mas esta pergunta não pode ser respondida. Realmente depende de muitos fatores, muitos dos quais estão ligados à personalidade do programador. Resposta fácil: claro, por que não? É mais uma ferramenta para criar sites.

Que tipos de projetos ou situações seriam mais adequados para Ruby que não são adequados para PHP ?.

Quanto aos projetos, ambos são igualmente adequados (se bem me lembro, o ruby ​​corre mais devagar, embora isso seja necessário com uma pitada de sal desde o AFAIK, o stackchange é construído com o RoR [nunca leio benchmarks reais]). Uma situação que se encaixaria mais que a outra é se você pretende usar uma estrutura específica ou se sua equipe é formada por pessoas com mais experiência em um dos dois idiomas. Realmente não acho que exista um tipo determinado de projeto que seja "ideal" para qualquer idioma específico. Realmente se resume às especificidades de cada projeto (e mesmo assim, as diferenças seriam sutis).

Qual é o ecossistema real do Ruby ?, além do RoR, eu não vi outras tecnologias / estruturas sensacionalistas.

Ruby on Rails é uma parte enorme do sucesso do Ruby. Ruby permaneceu um idioma desconhecido até o RoR ser lançado. Existem muitos projetos interessantes construídos no Ruby, mas nada chega perto em termos de sucesso e aceitação pela comunidade. Existem CMSs criados sobre o RoR que são bastante conhecidos. Lovd by Less, por exemplo.

Supondo que haja um certo tipo de projeto ideal para Ruby, haveria um momento em que seria melhor movê-lo para o PHP ?.

O único caso que posso imaginar é logo após a prototipagem com Ruby, se você achar que o PHP renderia a um desenvolvimento mais rápido. Mas depois que um projeto é iniciado, como você pretende "movê-lo para o PHP"? Portar todo o código que foi escrito?

Finalmente e mais importante, seria sensato manter projetos em dois idiomas?

Se você não tem uma bazuca apontada para sua cabeça, absolutamente não.
Se você quer manter dois projetos completamente diferentes em dois idiomas diferentes, então absolutamente. Eu acho que você nunca passará um longo período de tempo com o mesmo idioma. Por exemplo, estou constantemente pulando de um idioma para outro. Domino apenas alguns, mas conheço o suficiente dos outros para me livrar de qualquer situação (até agora). Como freelancer, as pessoas que trabalham em empresas podem ter uma experiência diferente. Mas o que quero dizer é que manter projetos diferentes em idiomas diferentes é fácil (suficiente) e divertido.


2
Acabei de ler que o stackxchange é baseado no ASP.NET MVC. Não que seja germaine para o seu post, mas pensei em mencioná-lo.
Kinakuta

você está certo, eu vou editar minha postagem para corrigir isso.
Xananax

+ 1 para o "Se você não tem uma bazuca apontada para sua cabeça, absolutamente não." A mistura de idiomas no mesmo projeto é problemática porque todos os mantenedores do projeto precisam conhecer os dois e é difícil encontrar um desenvolvedor que seja bom o suficiente nos dois idiomas. Obviamente, se houver uma separação clara entre todas as partes (como, por exemplo, back-end e front-end), pode haver uma desculpa. Mas é como chamar problemas.
Carlos Campderrós

Não quis dizer um único projeto nas duas linguagens, mas ter alguns projetos em PHP e outros em Ruby.
Dukeofgaming

Meu mal então. Eu não sei se sua pergunta não está clara ou se eu estava sob a influência do que estava trabalhando (mecanismo de marcação em php com visualização em js - exatamente como stackxchange-, portanto, dois analisadores em dois idiomas que devem produzir exatamente o mesmo resultado). Se você quer dizer ter projetos diferentes em idiomas diferentes, é claro, com certeza. Eu sempre preciso de alguns dias para escolher um idioma que você não usa há algum tempo, mas ele volta muito rápido.
Xananax


0

Ao ler, lembre-se de que sou desenvolvedor do Ruby on Rails e respondo a partir desse ecossistema. Meus pontos de vista serão inclinados nessa direção.

Um programador PHP gostaria de aprender Ruby ?, eu sei que sim, mas por outro lado, um programador Ruby gostaria de aprender PHP?

Absolutamente não, na maioria dos casos. Não apenas porque eu não gosto de PHP (não, mas eu o uso), mas porque os conjuntos de ferramentas têm diferenças ideais fundamentais. Existem muitas ferramentas, como rake e rspec, que auxiliam em algumas das TDD no mundo do ruby. Na maioria dos tutoriais de ruby ​​(e certamente trilhos), o teste vem em primeiro lugar. Isso não quer dizer que você não possa fazer isso no PHP, mas as convenções são diferentes. E as diferenças convencionais entre as duas línguas são, em geral, diretamente opostas.

Que tipos de projetos ou situações seriam mais adequados para Ruby que não são adequados para PHP ?.

Aplicativos de desktop, scripts de shell, aplicativos MVC (rails novamente) e pequenos aplicativos de console. Não que isso não possa ser feito com php, Ruby apenas tem um suporte melhor. Ao escrever um aplicativo Rails (desculpe), costumo escrever scripts únicos em ruby. Isso permite que meus scripts de implantação ou configuração estejam na mesma linguagem que meu aplicativo, onde, com o PHP, eu nunca tentaria escrever um script de shell no PHP. Eu usaria apenas o bash. Eu escrevi aplicativos Ruby QT e aplicativos MVC (Rails e não) e ruby ​​e suas bibliotecas vizinhas apenas "funcionam melhor" para esses casos.

Qual é o ecossistema atual do Ruby ?, além do RoR, eu não vi outras tecnologias / estruturas sensacionalistas (já vi o RSpec, mas confesso ser um noob total no que o BDD realmente consiste e suas implicações).

Isso é meio que um equívoco. O RoR é popular porque faz seu trabalho bem, mas existem outros conjuntos de ferramentas / pilhas que usam o ruby ​​em seu núcleo. Eles são menos populares porque estão entrando em um espaço que já tem alternativas. Eu gosto de escrever aplicativos GUI rápidos em ruby. Mas python, C #, VB, LISP, etc etc já podem fazer isso. RoR foi um divisor de águas. Assim, é popular. O mesmo pode ser dito para o PHP, cite uma estrutura PHP popular. Existem alguns, mas remova produtos (como o wordpress) da lista e você não ficará com muito.

Supondo que haja um certo tipo de projeto ideal para Ruby, haveria um momento em que seria melhor movê-lo para o PHP ?. Eu sei que o PHP pode lidar com muitas coisas, mas eu li que Ruby tem suas limitações ao escalar (ou é o RoR ?, ou isso é besteira para os dois?)

Esta é uma pergunta complicada e você deve perguntar: que idioma é melhor para o meu projeto? Eu nunca escreveria um blog no Rails. Eu sei que é o exemplo de tutorial padrão, mas se você quiser um blog, o wordpress é a ferramenta adequada. O mesmo se aplica aqui. Se você se deparar com um exemplo sólido de necessidade de mudar as linguagens do ruby, as limitações técnicas que você enfrentará também impedirão o PHP.

Finalmente e mais importante, seria sensato manter projetos em dois idiomas ?, ou isso é apenas estúpido. Como eu disse, parece que Ruby é mais enxuto no curto prazo e isso pode fazer um projeto acontecer e ter sucesso, mas não tenho tanta certeza disso a longo prazo.

Ruby é ótimo a longo prazo. O maior obstáculo ao sucesso a longo prazo não é a linguagem, mas o desenvolvedor. Quanto à manutenção de dois idiomas, depende de como você define um projeto. Eu tenho alguns projetos que têm uma aplicação pesada em trilhos, e um blog ou site de vendas usando wordpress / dupral / algum php. Eu os considero projetos separados. Eu direi que quanto mais idiomas você suportar, mais difícil é encontrar um bom desenvolvedor que seja bom em todos os idiomas. Por exemplo, eu uso e recomendo o wordpress, mas não sou tão "bom" em PHP quanto em RoR. Se um cliente realmente quisesse metade do seu produto principal em PHP e metade no RoR, eu realmente teria que descobrir o motivo e, dependendo da resposta, provavelmente diminuiria o trabalho.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.