Share
Es la hora; poner en cola el tema "Going the Distance" de Rocky. En el anillo rojo: el extraordinario desarrollador de Envato, Ryan Allen, quien construyó el FlashDen original con sus frías manos desnudas. En la esquina azul: Michael Wales, un miembro bien conocido en las comunidades de PHP y CodeIgniter. ¿La batalla? PHP vs Ruby. Lucha!
Cabe señalar que este tipo de debates son puramente para fines educativos y de diversión. Hay ocasiones en las que elegirás PHP para un proyecto, y hay ocasiones en las que optarás por Ruby. El objetivo de esta serie, sin embargo, es aprender. cómo y cuando Para tomar este tipo de decisiones. En lugar de "su idioma apesta", estos debates están destinados a delinear por qué Usted puede, en ciertas situaciones, elegir uno sobre el otro..
Ryan Allen es un ingeniero de sistemas y software web que ha estado trabajando para Envato desde siempre. Construyó y apoyó las primeras versiones de Envato Marketplaces en Ruby on Rails, y ahora se ocupa de los sistemas Tuts +, entre otras cosas..
Michael Wales es un desarrollador web para agencias del gobierno de los EE. UU. Y es un colaborador activo de las comunidades PHP y CodeIgniter..
Ryan: PHP fue uno de los primeros lenguajes de programación con los que trabajé (además de ActionScript y algunos Visual Basic muy breves). Comencé a construir cosas con PHP en 2001. Trabajé casi exclusivamente como herramienta de backend hasta fines de 2005, cuando Ruby (y Rails) tomó su lugar..
Miguel: PHP fue mi introducción al mundo del desarrollo web, en 1999, así que me gustaría decir que tengo una comprensión bastante sólida de su posición dentro de nuestra industria, su historia y la dirección en la que se dirige. Ruby, como muchos otros, me llamó la atención con el lanzamiento de Rails y el éxito de 37signals. Tengo una comprensión bastante sólida de Ruby, como lenguaje de scripting en mis tareas de Administración del Sistema (Capistrano), así como algunos proyectos personales y divertidos (la biblioteca de desarrollo de juegos Gosu y Rails). Me avergüenza admitir que no estoy tan familiarizado con las últimas versiones de Rails y definitivamente estoy en mi lista de cosas para reencontrarme con.
Miguel: Desafortunadamente, no puedo dar una respuesta definitiva a esto, al menos no como esperas, ya que PHP y Ruby son dos bestias completamente diferentes. PHP es una amalgama de lenguaje y marco web en un paquete, mientras que Ruby es un lenguaje de programación con numerosos marcos disponibles.
Si tu enfoque es el desarrollo web y eso es todo en lo que realmente querías enfocarte en este momento, definitivamente te recomendaría aprender PHP primero.
Entonces, si tu enfoque es el desarrollo web y eso es todo en lo que realmente querías enfocarte en este momento, definitivamente te aconsejaría que aprendieras PHP primero por varias razones:
Como desarrollador con 12 años de experiencia, aprecio los accesos directos que Rails aporta a nuestra industria; pero eso es solo porque entiendo lo que realmente está pasando detrás de las escenas.
Si desea convertirse en un desarrollador (desarrollador web, scripting de administración de sistemas, desarrollador de juegos, desarrollador de API) que entienda los conceptos informáticos de bajo nivel, la programación orientada a objetos y, en general, mejore sus habilidades de pensamiento crítico. Comience con Ruby, es un lenguaje de programación real (recuerde, PHP es un marco web disfrazado de lenguaje).
Desde la perspectiva de un desarrollador web, creo que esta también es una de las desventajas de Ruby (y de Python, BTW): ¿es que realmente no hay ninguna? Nivel medio? punto de entrada. O bien entiendes el protocolo HTTP, con la capacidad de escribir tu propia pila, de arriba a abajo, o te vas con uno de los? Mágicos, toma tu mano para hacer los marcos del sistema CRUD?.
Esta es realmente el área en la que brilla PHP. Si va más allá de los límites de CRUD, no necesita tener una comprensión extrema de cómo funciona un servidor HTTP para hacer sus sueños realidad..
Ryan: Si tuviera que enseñar a alguien a programar desde cero, preferiría enseñarle a Ruby (problemas para configurar entornos aparte, aunque esto se está volviendo más fácil). Una forma común de iniciar a alguien (después de quizás las variables e imprimirlas) es explicar las matrices con, por ejemplo, un ejemplo de lista de compras, tome este bit de PHP:
Accentsconagua
$ shopping_list = array ('Milk', 'Cheese', 'Hovercraft'); para ($ i = 0; $ i < count($shopping_list); $i++) echo $shopping_list[$i]; Cuando aprendí PHP, me enseñaron a usar los bucles (como lo estaba en ActionScript), cuando ya existía un bucle foreach más conciso y menos propenso a errores (como sucedió en ActionScript). Tuve que aprender todo sobre esta cosa $ i = 0, esta cosa de prueba y esta cosa incrementadora. ¡Todo era tan confuso! El número de veces que he jodido para bucles es incontable (sin juego de palabras). Así es como se vería la misma cosa en Ruby:
shopping_list = ['Milk', 'Cheese', 'Hovercraft'] shopping_list.each do | shopping_item | pone shopping_item final
Hay mucho menos sintaxis allí, y los iteradores son, en mi opinión, mucho más fáciles de entender y trabajar. Pero para completar, aquí está el ejemplo de PHP pero con un foreach:
$ shopping_list = array ('Milk', 'Cheese', 'Hovercraft'); foreach ($ shopping_list as $ shopping_item) echo $ shopping_item; Bueno, eso no está mal en realidad! Reconozco que solo deberías usar para que los bucles cuenten hasta 10 y cosas como esas, foreach es mucho más fácil de leer y enseñar y mucho más difícil de arruinar. Y los iteradores son aún mejores, así que iría con Ruby..
Ryan: El punto de venta para mí (en 2005) fue el marco de Rails. Había probado mi habilidad en el desarrollo web con Python, pero como no tenía experiencia, tuve un momento difícil, no sabía qué hacer ni dónde mirar (pero logré crear algunas cosas, así que toma eso), pero realmente quería hacerlo. use Python día a día porque sentí que tenía un diseño mejor y más deliberado y me gustó la sintaxis. Y porque las serpientes son más frescas que los elefantes..
ActiveRecord fue tan increíble!
Nunca había trabajado con nada más que ADODB en PHP, y había intentado y fracasado en hacer un ORM muchas veces (no tenía idea de lo que era un ORM pero sabía que quería algo que de alguna manera asignara clases a las tablas de la base de datos), cuando vi por primera vez ActiveRecord Era como si todas mis navidades hubieran llegado al mismo tiempo..
Conocía bastante bien las bases de datos relacionales, pero estaba harta de escribir el mismo SQL una y otra vez. ¡ActiveRecord fue simplemente, tan, increíble! Y Ruby estaba lo suficientemente cerca de Python. Estaba feliz de que Larry (quienquiera que sea) tuviera un marco en el que pudiera ocuparme y comenzar a construir cosas. Así que para mí fue el amor de una biblioteca y el amor de la sintaxis..
Hoy en día tenemos montones de increíbles bibliotecas de Ruby escritas por personas con talento, bibliotecas como Sinatra (un marco web ligero), Nokogiri (un analizador de HTML / XML), Sequel (una biblioteca de bases de datos de alto nivel), RSpec (una biblioteca de pruebas automatizadas). Todas estas bibliotecas se pueden instalar como RubyGems, que me parece mucho más fácil y fácil de usar que el sistema PEAR de PHP..
La comunidad sigue siendo bastante vibrante, incluso en unos pocos años, y las empresas están contratando a desarrolladores de Ruby como hotcakes. Ruby 1.9 es aparentemente casi tan rápido como PHP ahora también, así que hay muchos puntos de venta!
Ruby 1.9 es aparentemente casi tan rápido como PHP ahora también, así que hay muchos puntos de venta!
Miguel: Creo que esto es solo una progresión natural de los desarrolladores (desde el desarrollo web hasta la búsqueda de conocimientos generales de idiomas OOP y una educación general en informática) en general, sé que fue el camino que tomé.
Creo que la caída más grande, hasta el día de hoy, es la práctica de escoger un idioma y adherirlo a la muerte. No es así como funciona el mundo real..
Me considero un? Desarrollador? - por lo tanto, el idioma es una calificación ambigua como la marca de televisión para un vendedor de Best Buy. Hay instancias en las que escojo PHP (si hay una línea de tiempo extremadamente corta: fuera de CRUD, es el lenguaje con el que estoy más familiarizado), hay otras en las que escojo a Ruby (despliegue a través de Capistrano o CRUD básico con Rails) y , aún más, Python, que prefiero para las tareas de administración del servidor y el análisis de varios archivos.
Miguel: Creo que los desarrolladores muy a menudo pueden quedar atrapados en el "nuevo hotness, old busted"? manía. Es por eso que mi equipo siempre se sienta antes de comenzar un proyecto, establecemos los requisitos (tanto en términos de usuario como de desarrollador, que son dos cosas muy diferentes) y lo comentamos, con muy pocas preferencias de idioma / marco en mente . La semana pasada analizamos algunos GB de registros de mensajería con Perl, esta semana creamos una aplicación cuya vista principal era un panel de cuadrícula de ExtJS (porque hemos ampliado los archivos principales de CodeIgniter que manejan cualquier situación que ExtJS nos arroje con 3 líneas de código).
Se trata de cuánto tiempo tenemos y cómo podemos producir el mejor producto en ese período de tiempo?
Ryan: Absolutamente, algunas personas (yo incluido) se acostumbran a diseñar las cosas de una manera determinada que no quieren volver a aprender y cambiar todos sus hábitos ganados con tanto esfuerzo. Una vez que eres productivo con algo, ¿por qué te molestarías en cambiarlo??
Otra escuela de pensamiento es que cuanto más idiomas y herramientas tengas, podrás combinar las mejores técnicas e ideas sin importar el entorno en el que estés trabajando (dicen esto sobre aprender LISP, pero aún no lo he aprendido) ).
Los programadores jóvenes se lanzarán a las nuevas y brillantes cosas, pero a medida que envejezcan y maduren, querrá trabajar con herramientas pequeñas, simples y robustas. Si no usa todas las funciones y todas las bibliotecas disponibles en Ruby, puede obtener de forma simple y robusta sin demasiados problemas..
Una palabra: mantenimiento.
Ryan: Sí, una palabra: mantenimiento. Los proyectos de software tienen una tendencia a requerir modificaciones a lo largo del tiempo, y el autor original del programa no siempre será la persona que realice las modificaciones. Supongamos que hipotéticamente se inventan los teletransportadores y hay una conferencia mundial de Ruby y todos los desarrolladores de Ruby capaces del mundo se están yendo (¡telepuertos!). Ahora digamos también que la Tierra es hipotéticamente la Tierra Media, y Smaug, el dragón, está bastante molesto por todo este asunto de Ruby (los dragones prefieren Python, verás) y decide visitarlos y engullir a todos los desarrolladores por despecho. Ahora no hay desarrolladores de Ruby con experiencia en el mundo, ¡oh cielos! Ahora tiene este problema de no tener un grupo de desarrolladores de Ruby disponibles para trabajar en sus proyectos. ¿Qué vamos a hacer Gandalf??
Cuando elijo herramientas, a menudo pienso en quién tendrá que mantener el proyecto si un autobús me atropella (o choco mi motocicleta, lo cual es más probable).
Ciertamente no escribiría nada en Haskell, LISP o incluso F # porque nos costaría mucho contratar a alguien que pudiera o podría trabajar en ello. La disponibilidad del talento y el talento existente en una empresa influye mucho en mi decisión..
Hay otra situación en la que consideraría el idioma, y eso sería si estuviera vendiendo un producto, por ejemplo, un CMS personalizado que se vende en Code Canyon. No lo escribiría en Ruby porque el alojamiento web de productos básicos generalmente no lo admite. Mientras que PHP está prácticamente disponible en todas partes y los diseñadores web y los programadores menos experimentados están algo familiarizados con él.
Hay otra situación en la que consideraría el idioma, y eso sería si estuviera vendiendo un producto, por ejemplo, un CMS personalizado que se vende en Code Canyon. No lo escribiría en Ruby porque el alojamiento web de productos básicos generalmente no lo admite. Mientras que PHP está prácticamente disponible en todas partes y los diseñadores web y los programadores menos experimentados están algo familiarizados con él.
Miguel: Ver mis respuestas para # 3 / # 4.
Miguel: Personalmente, recomendaría el framework Django para Python. Fue diseñado con este propósito en mente: la capacidad de hacer que los desarrolladores trabajen en el modelado de datos y mostrar los datos en la pantalla lo más rápido posible, con etiquetas fáciles de usar para que los diseñadores presenten esos datos de una manera hermosa, mientras los desarrolladores continúan Trabajar sobre las reglas de negocio en un ciclo concurrente..
Ryan: Si tiene experiencia en juntar HTML y CSS y cargarlos con FTP, entonces probablemente recomendaría PHP, ya que tiene pocas barreras de entrada porque ya está familiarizado con su metáfora (envuelva su código .php ¡extensión! ¡Fuera vete!). Pero si empezaste a tomarte en serio la programación, te sugeriría expandirte y echar un vistazo a otras cosas (como Ruby) para ampliar tus horizontes..
Cuando las cosas vayan mal, tu falta de conocimiento volverá y te morderá.
A menudo veo a los programadores de PHP trabajando con bases de datos relacionales y que tienen muy poca comprensión de cómo funcionan. Entonces, realmente puede hacer las cosas sin una comprensión profunda de las tecnologías con las que está trabajando (rara vez usa PHP por su cuenta), pero cuando las cosas salen mal, su falta de conocimiento volverá y lo morderá. ¿Cuánto tiempo tienes para invertir en aprender estas cosas? ¿Puedes acudir a alguien en busca de ayuda si te atascas? ¿Estás aprendiendo PHP para poder trabajar con él o solo por diversión? La elección es una pregunta bastante abierta según cuáles sean tus objetivos.
En cuanto a las terminales, son, en definitiva, IMPRESIONANTES. Yo los uso todo el tiempo. Sí, tienen una curva de aprendizaje (¿pero qué no?). Una vez que los maneja y comienza a escribir sus propios pequeños programas, no puede continuar sin ellos. Para ser justos, no encontré el Indicador de comando en Windows muy útil, pero una vez que me cambié a una Mac y tuve acceso a toda la diversión * nix bajo el capó, se volvió bastante productivo.
Ruby tiene exageración, vitalidad y atractivo sexual.
Ryan: Diría que algo que Ruby actualmente tiene que PHP no es exageración, vitalidad y atractivo sexual. Ruby es inequívocamente sexy. Las mujeres lo aman. Los hombres quieren ser así. Godzilla lo teme. Yo sugeriría pasar a un grupo de usuarios de Ruby y encontraría un grupo diverso de personas a las que les encanta codificar, les encanta hacer cosas y la tecnología en general. Cuando comencé a conocer gente en la comunidad local de Ruby, fue la primera vez en mi vida que sentí que estaba con mi gente.? Honestamente, pensé que era el único programador del planeta que se preocupaba por su trabajo hasta ese momento. Fue muy refrescante y he aprendido mucho desde entonces, principalmente de las personas que he conocido a través de estos grupos..
Aquí hay un secreto: si PHP lanzó una actualización oficial con una sintaxis alternativa (más similar a Ruby / Python) y envolvió la biblioteca estándar existente al estilo de las bibliotecas populares de Ruby (y la hizo coherente), y tenía compatibilidad y capacidad retroactivas para Integrar con el código heredado, sería un producto asesino. No le digas a nadie que dije eso.
Miguel: Facilidad de implementación, una introducción elegante a los conceptos de desarrollo web de más bajo nivel y más de un siglo de documentación y mejores prácticas probadas..
Miguel: Nuevamente: facilidad de implementación, una introducción elegante a los conceptos de desarrollo web de nivel inferior y más de un siglo de documentación y mejores prácticas probadas..
Pero en serio, debido a la baja barrera de entrada con PHP, puede ser difícil discernir la diferencia entre alguien que realmente sabe de lo que están hablando y alguien con el mismo nivel de habilidad que usted tenía un dominio de repuesto para un blog. Además, debido a la gran antigüedad de PHP, hay un montón de contenido ahí fuera, y no todo es bueno.
Este no es un problema único de PHP: un vistazo rápido a W3Schools.com arruinará los sueños de cualquier proponente de xHTML, JavaScript, CSS o PHP.
Los desarrolladores de PHP sufren de? Síndrome no inventado aquí.?
Puede ser muy fácil, cuando estás aprendiendo un idioma, encontrar lo que crees que es un recurso autorizado (que podría estar desactualizado o simplemente equivocado) y seguir con lo que están enseñando. tú. Esto es algo que la comunidad de PHP necesita para mejorar mucho en la difusión del derecho, ¿no? Manera de realizar ciertas tareas. Admito que la comunidad de Ruby tiene la ventaja aquí. Rick Olson resolvió la autenticación para todos cuando lanzó el complemento de autenticación de descanso. J
Los desarrolladores de PHP, durante sus primeros años, padecen? ¿Síndrome no inventado aquí? - lo que no creo que sea algo malo (hasta que empiezan a vender eso o a pasarlo a otros). Creo que la mentalidad detrás de un nuevo desarrollador, experimentando PHP por primera vez, es que realmente quieren entender exactamente lo que está pasando, y PHP hace un trabajo perfecto de "darles la suficiente cuerda para colgarse". - Revelando lo suficiente como para aprender, pero probablemente te harás daño. Considerando que, y no para descontar el complemento de Rick (que es un sistema de autenticación impresionante), los desarrolladores de Rails están dispuestos a asumir que este tipo lo hizo bien y continuará su camino.
PHP se hizo inmensamente popular porque estaba en el lugar correcto en el momento correcto.
Ryan: Yo diría que PHP se hizo inmensamente popular porque estaba en el lugar correcto en el momento correcto. Las alternativas para el desarrollo del lado del servidor en el pasado requerían una gran cantidad de conocimientos de programación, sin embargo, muchas personas que nunca pensaron en sí mismos como programadores ya estaban lanzando cosas con HTML y CSS. Siguiendo la misma metáfora de implementación y una comprensión básica de cómo armar sitios web, puede crear programas de utilidad moderada y lanzarlos a un host web compartido económico. O puedes descargar uno que alguien más haya hecho y modificarlo un poco porque el código HTML y el código se mezclaron..
Otra cosa que ayudó a PHP fue el auge de los "me gusta", como el producto cPanel y los proveedores de hospedaje de alojamiento web de etiquetado blanco. Cada hombre y su perro pueden convertirse en un proveedor de alojamiento web a bajo costo y sin ningún conocimiento técnico. Cada hombre y su perro querían un sitio web y alojamiento barato. PHP y MySQL eran estándar estándar en estas configuraciones compartidas, y estaban en todas partes (y todavía están).
Lo mejor no siempre "gana", mucha gente sigue molesta porque SmallTalk perdió con Java, aunque la gente que conocí (veteranos de software serio) que estaban presentes cuando sucedió esto, dicen que se sienten como en casa en Ruby!
Ryan: Esto no es muy bueno, pero yo diría que las críticas comunes de PHP son bastante válidas y se deben a la forma en que el idioma? Fue diseñado (o más bien, no diseñado). PHP nació de una serie de scripts CGI que el autor original escribió en C (¿o era Perl?), Y el caso común de por qué PHP fue así fue? Podría tener un programador en C escribiendo guiones para el web en solo un par de dias?.
No recuerdo haberle pedido a un programador de C que me hiciera una aplicación web!
Ruby, por otro lado, fue diseñado para sacar lo mejor de una serie de idiomas para crear algo con lo que fue un placer trabajar, ha tomado las pautas de Smalltalk, Perl, LISP y otros, y muestra.
Una gran diferencia entre PHP y Ruby para mí fue que Ruby te alienta a trabajar con sus tipos de datos básicos como Hashes y Arrays, donde nunca los encontré naturales en PHP. La cantidad de veces que tuve que buscar el orden de los argumentos para Cadenas y Arrays en PHP es alucinante.
El número de veces que no pude recordar si esta o aquella función tenía guiones bajos o no era igual de molesto. Usé Zend IDE, así que no tenía que recordar pero no me gustaba el IDE. Se sentía como si estuvieras maldito si lo hicieras y maldito si no lo hicieras. No hay coherencia en la biblioteca estándar de PHP y es frustrante como un oso enfurecido en una cabina telefónica. En Ruby, rara vez dedico tiempo a la documentación de tipos de datos comunes porque las interacciones comunes son muy fáciles de recordar.
Una vez que comience a usar las funciones en el módulo Enumerable de Ruby, se preguntará cómo vivió sin él, juramento de color rosado.!
Miguel: Creo que esto es un reflejo de la barrera de entrada baja y la curiosidad heredada de los desarrolladores de PHP para entender realmente lo que está sucediendo. Había leído / estudiado cientos de informes, blogs, artículos sobre sistemas de autenticación, pero no fue hasta que construí el mío que realmente sentí como si supiera lo que estaba pasando. Creo que los nuevos desarrolladores de PHP están ansiosos por compartir lo que han hecho con el resto del mundo y con frecuencia son criticados por hacerlo, porque no siguieron las mejores prácticas ni los patrones de seguridad probados..
Miguel: Creo que tanto PHP como Ruby tienen serios problemas en su documentación, y por razones completamente opuestas.
PHP tiene un montón de documentación, gracias a su antigüedad: puede encontrar la respuesta a cualquier pregunta con una búsqueda rápida en Google y funcionará. ¿Es la mejor solución? Tal vez tal vez no?
Rails ha estado creciendo tan rápido, que incluso me cuesta trabajo mantenerme al día..
Ruby tiene una gran documentación, pero en realidad esto parece ser una pregunta de marco frente a marco, por lo que asumiremos Rails. Rails ha estado creciendo tan rápido, que incluso me cuesta trabajo mantenerme al día. La documentación API de Rails es genial; pero cuando se trata de documentación de terceros (libros, artículos de blog, respuestas de StackOverflow): todos están desactualizados y, al mismo tiempo que siguen esta información, es muy difícil depurar el problema y solucionarlo..
En este sentido, creo que PHP tiene la ventaja de que los marcos individuales (CodeIgniter, FuelPHP, Kohana, CakePHP, etc.) pueden mitigar este efecto hasta cierto punto. Si está utilizando uno de estos marcos, es fácil encontrar la respuesta definitiva. para lo que buscas.
Ryan: Cuando estaba usando PHP, se puso mucho énfasis en cuán asombrosos eran los comentarios en la documentación de PHP.net. La filosofía parecía ser "escribir la documentación una vez y dejar que la gente agregue sus dos centavos". El problema con esto es que los comentarios se presentan en orden de publicación, lo que significa que los buenos no se filtran a la parte superior, y cualquier información compartida en ellos no se incluyó en la documentación de manera oportuna (o en absoluto).
Gran parte de la API común está incluida en el núcleo de PHP, que no cambia tan a menudo, así que creo que una solución wiki sería más apropiada. De esa manera, la comunidad podría modificar la documentación oficial, sugerir cambios, sugerir ejemplos, integrar lo bueno de los comentarios en lo que la gente ve primero. Eso sería útil (especialmente para un principiante).
Los cursos de Java enseñan a las personas sobre el polimorfismo primero y observan lo que hacen: ¡diseñan con jerarquías de clase como primer corte! Eso me vuelve loco!
En Ruby, muchas de las bibliotecas de uso común están en GitHub, donde las personas pueden enviar pequeños cambios y mejoras que se incorporan a lo que generalmente es un ciclo de lanzamiento regular. La documentación se empareja en el código mediante RDoc (que es similar a PHPDoc), y cuando instala una gema, genera documentación en su sistema local. Durante gran parte de mi trabajo, estaré leyendo la documentación principal en rubydoc.info, o localmente en mi máquina, o si alguno de ellos falla el propio código fuente de las bibliotecas.
Hemos escuchado los pensamientos de Ryan y Michael, y ciertamente tienes tus propios puntos de vista. Continuar el debate en los comentarios.!
