Me pregunto si hay recursos menos sesgados que brinden descripciones buenas y específicas de los lenguajes de programación y sus objetivos. Me gustaría aprender un nuevo idioma, pero visitar los sitios de cada idioma no funciona. Cada uno habla de lo bueno que es sin mencionar mucho sus debilidades u objetivos específicos .

Ruby es un lenguaje de programación dinámico y de código abierto con un enfoque en la simplicidad y la productividad.

Python es un lenguaje de programación que le permite trabajar más rápidamente e integrar sus sistemas de manera más efectiva.

Habiendo sido un desarrollador de PHP durante años, Vic Cherubini resume bien mi situación:

Conocía bien PHP, tenía mi propio marco y podía trabajar rápidamente para poner en marcha algo.

Lo programé así durante toda la revolución MVC. Obtuve mejores y mejores trabajos (léase: mejor pago, mejor título) como desarrollador de PHP, pero en todo momento me di cuenta de que el código que escribí en mi propio tiempo fue excelente, y el código con el que trabajé en el trabajo fue horrible. Como, peor que horrible. Atroz. Nivel de comercio del sistema operativo incorrecto. Tener proyectos paralelos me mantuvo cuerdo, porque el código con el que trabajé en el trabajo me hizo sentir miserable.

Es por eso que me retiro de PHP para mis proyectos paralelos y nuevas empresas de programación. Me paso con PHP. Agotado, por así decirlo. Llegué a un nivel en el que creo que estoy en la cima con él como lenguaje y si no paso a un nuevo idioma pronto, terminaré por completo con la programación y no quiero eso.

Los idiomas que he visto incluyen JavaScript (para node.js), Ruby, Python y Erlang. Incluso he pensado en Scala o C ++.

El problema es descubrir cuáles están diseñados para satisfacer mejor mis necesidades.

Entonces, ¿dónde puedo ir para omitir la publicidad y obtener información real sobre la madurez de una plataforma, el tamaño de la comunidad y las fortalezas y debilidades de ese idioma. Si los conozco, elegir un idioma para continuar con mi desarrollo web debería ser fácil.

Actualizar

Simplemente no quiero obtener 4 meses en el futuro con un poco de lenguaje y me parece que apesta porque cada hilo tiene 4 MB de sobrecarga, o las conexiones simultáneas máximas son 999, no hay un paquete para hacer la función "X", o el soporte es ser eliminado para una nueva rama de idiomas.

No iba a publicar esto como respuesta, pero Xeoncross me lo pidió, así que aquí vamos:

(Nota al margen: si alguien pudiera solucionar el problema del descuento en el pequeño ejemplo de código, lo agradecería).

Publicado por Alex Martelli en comp.lang.python : ¿Qué hay de mejor en Ruby que en Python? el 18 de agosto de 2003, 5:50 p.m.

Erik Max Francis escribió:

"Brandon J. Van Every" escribió:

¿Qué hay de mejor en Ruby que en Python? Estoy seguro de que hay algo. ¿Qué es? ¿No tendría mucho más sentido preguntarle a la gente de Ruby esto, en lugar de a la gente de Python?

Podría, o no, dependiendo de los propósitos de uno: por ejemplo, si los propósitos de uno incluyen un "estudio sociológico" de la comunidad de Python, entonces hacer preguntas a esa comunidad probablemente resulte más revelador de información al respecto, que ponerlas en otro lugar :-). Personalmente, aproveché la oportunidad para seguir el tutorial de un día de Dave Thomas sobre Ruby en el último OSCON. Debajo de una delgada capa de diferencias de sintaxis, encuentro a Ruby y Python increíblemente similares: si calculara el árbol de expansión mínimo entre casi cualquier conjunto de idiomas, estoy bastante seguro de que Python y Ruby serían las dos primeras hojas en fusionarse un nodo intermedio :-).

Claro, me canso, en Ruby, de escribir el "final" tonto al final de cada bloque (en lugar de simplemente desangrar), pero luego evito escribir el igualmente tonto : que Python requiere al comienzo de cada bloque, así que eso es casi un lavado :-). Otras diferencias de sintaxis como @fooversus self.fooo la mayor importancia del caso en Ruby vs Python son realmente tan irrelevantes para mí.

Otros sin duda basan su elección de lenguajes de programación en tales problemas, y generan los debates más candentes, pero para mí eso es solo un ejemplo de una de las Leyes de Parkinson en acción (la cantidad de debate sobre un tema es inversamente proporcional a la del tema importancia real). Una diferencia de sintaxis que considero importante, y a favor de Python, pero otras personas sin duda pensarán exactamente lo contrario, es "cómo se llama a una función que no toma parámetros". En Python (como en C), para llamar a una función siempre se aplica el "operador de llamada" - paréntesis finales justo después del objeto que está llamando (dentro de esos paréntesis finales van los argumentos que está pasando en la llamada, si no estás pasando argumentos, entonces los paréntesis están vacíos). Esto deja la mera mención de cualquier objeto, sin operador involucrado, que significa solo una referencia al objeto, en cualquier contexto, sin casos especiales, excepciones, reglas ad-hoc y similares. En Ruby (como en Pascal), para llamar a una función CON argumentos, pasa los argumentos (normalmente entre paréntesis, aunque ese no es siempre el caso) - PERO si la función no toma argumentos, simplemente menciona la función implícitamente. Esto puede cumplir con las expectativas de muchas personas (al menos, sin duda, aquellas cuya única experiencia previa de programación fue con Pascal u otros lenguajes con "llamadas implícitas" similares, como Visual Basic), pero para mí, significa la mera mención de un objeto puede significar ya sea una referencia al objeto, O una llamada al objeto, dependiendo del tipo de objeto, y en aquellos casos en los que no puedo obtener una referencia al objeto simplemente mencionándolo, necesitaré usar explícitamente "¡dame una referencia a esto, NO lo llames!" operadores que no son necesarios de otra manera. Siento que esto afecta la "primera clase" de funciones (o métodos u otros objetos invocables) y la posibilidad de intercambiar objetos sin problemas. Por lo tanto, para mí, esta diferencia de sintaxis específica es una marca negra seria contra Ruby, pero entiendo por qué los demás pensarían lo contrario, a pesar de que difícilmente podría estar en desacuerdo con ellos con más vehemencia :-). Debajo de la sintaxis, llegamos a algunas diferencias importantes en la semántica elemental, por ejemplo, las cadenas en Ruby son objetos mutables (como en C ++), mientras que en Python no son mutables (como en Java, o creo que C #). Una vez más, las personas que juzgan principalmente por lo que ya están familiarizados pueden pensar que esto es una ventaja para Ruby (a menos que estén familiarizados con Java o C #, por supuesto :-). Yo, creo que las cadenas inmutables son una excelente idea (y no me sorprende que Java, independientemente, creo, reinventó esa idea que ya estaba en Python), aunque tampoco me importaría tener un tipo de "buffer de cadena mutable" (e idealmente uno con mejor facilidad de uso que los propios "buffers de cadenas" de Java); y no doy este juicio por familiaridad, antes de estudiar Java, aparte de los lenguajes de programación funcionales donde las personas que juzgan principalmente por lo que ya están familiarizados pueden pensar que esto es una ventaja para Ruby (a menos que estén familiarizados con Java o C #, por supuesto :-). Yo, creo que las cadenas inmutables son una excelente idea (y no me sorprende que Java, independientemente, creo, reinventó esa idea que ya estaba en Python), aunque tampoco me importaría tener un tipo de "buffer de cadena mutable" (e idealmente uno con mejor facilidad de uso que los propios "buffers de cadenas" de Java); y no juzgo por familiaridad, antes de estudiar Java, aparte de los lenguajes de programación funcionales donde las personas que juzgan principalmente por lo que ya están familiarizados pueden pensar que esto es una ventaja para Ruby (a menos que estén familiarizados con Java o C #, por supuesto :-). Yo, creo que las cadenas inmutables son una excelente idea (y no me sorprende que Java, independientemente, creo, reinventó esa idea que ya estaba en Python), aunque tampoco me importaría tener un tipo de "buffer de cadena mutable" (e idealmente uno con mejor facilidad de uso que los propios "buffers de cadenas" de Java); y no juzgo por familiaridad, antes de estudiar Java, aparte de los lenguajes de programación funcionales donde Creo que las cadenas inmutables son una excelente idea (y no me sorprende que Java, independientemente, creo que reinventó esa idea que ya estaba en Python), aunque no me importaría tener un tipo de "buffer de cadena mutable" también (y idealmente uno con mejor facilidad de uso que los propios "buffers de cadena" de Java); y no juzgo por familiaridad, antes de estudiar Java, aparte de los lenguajes de programación funcionales donde Creo que las cadenas inmutables son una excelente idea (y no me sorprende que Java, independientemente, creo que reinventó esa idea que ya estaba en Python), aunque no me importaría tener un tipo de "buffer de cadena mutable" también (y idealmente uno con mejor facilidad de uso que los propios "buffers de cadena" de Java); y no doy este juicio por familiaridad, antes de estudiar Java, aparte de los lenguajes de programación funcionales dondetodos los datos son inmutables, todos los lenguajes que conocía tenían cadenas mutables; sin embargo, cuando vi por primera vez la idea de la cadena inmutable en Java (que aprendí mucho antes de aprender Python), inmediatamente me pareció excelente, una muy buena opción para la semántica de referencia de un lenguaje de programación de nivel superior (a diferencia de la semántica de valor que mejor se adapta a los lenguajes más cercanos a la máquina y más alejados de las aplicaciones, como C) con cadenas como una primera clase, incorporada (y bonita crucial) tipo de datos.

Ruby tiene algunas ventajas en la semántica elemental: por ejemplo, la eliminación de las "listas vs tuplas" de Python es una distinción extremadamente sutil. Pero sobre todo el puntaje (como lo mantengo, con simplicidad, una gran ventaja y distinciones sutiles e inteligentes, un notable menos) está en contra de Ruby (por ejemplo, tener intervalos cerrados y medio abiertos, con las anotaciones a..by a .. .b [alguien quiere afirmar que es obvio cuál es cuál? -)], es una tontería - ¡En mi humilde opinión, por supuesto!). Una vez más, las personas que consideran tener muchas cosas similares pero sutilmente diferentes en el núcleo de un idioma MÁS, en lugar de MENOS, por supuesto contarán esto "al revés" de la forma en que los cuento :-).

No se deje engañar por estas comparaciones para pensar que los dos idiomas son muydiferente, te importa. No lo son Pero si me piden comparar "capelli d'angelo" con "spaghettini", después de señalar que estos dos tipos de pasta son casi indistinguibles para cualquiera e intercambiables en cualquier plato que desee preparar, entonces inevitablemente tendría para pasar al examen microscópico de cómo las longitudes y diámetros difieren imperceptiblemente, cómo se afilan los extremos de los hilos en un caso y no en el otro, y así sucesivamente, para tratar de explicar por qué yo personalmente preferiría capelli d 'angelo como la pasta en cualquier tipo de caldo, pero preferiría spaghettini como la pastasciutta para ir con salsas adecuadas para esas formas largas y delgadas de pasta (aceite de oliva, ajo picado, pimientos rojos picados y anchoas finamente molidas, por ejemplo, pero si rebanó los ajos y los pimientos en lugar de picarlos, entonces debe elegir el cuerpo de espagueti más sólido en lugar de la evanescencia más delgada de los espaguetis, y le recomendamos que renuncie a la vista y agregue un poco de albahaca fresca de primavera [ o incluso, soy un hereje ...! - hojas de menta clara - en el último momento antes de servir el plato). Vaya, lo siento, eso demuestra que estoy viajando al extranjero y no he comido pasta por un tiempo, supongo. ¡Pero la analogía sigue siendo bastante buena! -) y sería aconsejable renunciar a la vista y agregar un poco de albahaca fresca de primavera [o incluso, ¡soy un hereje ...! - hojas de menta clara - en el último momento antes de servir el plato). Vaya, lo siento, eso demuestra que estoy viajando al extranjero y no he comido pasta por un tiempo, supongo. ¡Pero la analogía sigue siendo bastante buena! -) y sería aconsejable renunciar a la vista y agregar un poco de albahaca fresca de primavera [o incluso, ¡soy un hereje ...! - hojas de menta clara - en el último momento antes de servir el plato). Vaya, lo siento, eso demuestra que estoy viajando al extranjero y no he comido pasta por un tiempo, supongo. ¡Pero la analogía sigue siendo bastante buena! -)

Entonces, volviendo a Python y Ruby, llegamos a los dos grandes (en términos de lenguaje apropiado: abandonar las bibliotecas y otros accesorios importantes como herramientas y entornos, cómo incrustar / extender cada idioma, etc., etc., fuera de por ahora, no se aplicarían a todas las IMPLEMENTACIONES de cada idioma de todos modos, por ejemplo, Jython vs Classic Python son dos implementaciones del lenguaje Python):

1. Los iteradores y bloques de código de Ruby frente a los iteradores y generadores de Python;

2. La "dinámica" desenfrenada TOTAL de Ruby, que incluye la capacidad de "reabrir" cualquier clase existente, incluidas todas las integradas, y cambiar su comportamiento en tiempo de ejecución, frente a la gran pero limitada dinámica de Python , que nunca cambia el comportamiento de las clases     existentes. clases integradas y sus instancias.

Personalmente, considero 1 un lavado (las diferencias son tan profundas que fácilmente podría ver a las personas odiando cualquiera de los dos enfoques y revertir el otro, pero en MIS escalas personales, las ventajas y desventajas casi se igualan); y [2] un tema crucial, uno que hace que Ruby sea mucho más adecuado para "retoques", PERO Python es igualmente más adecuado para su uso en grandes aplicaciones de producción. Es divertido, en cierto modo, porque ambos idiomas son MUCHO más dinámicos que la mayoría de los demás, que al final la diferencia clave entre ellos de mi POV debería depender de eso: que Ruby "va a once" en este sentido (la referencia aquí está a "Spinal Tap", por supuesto). En rubí¡PUEDO HACER ESO ! Es decir, puedo alterar dinámicamente la clase de cadena incorporada para que

a = "Hola mundo" 
b = "hola mundo" 
si a == b 
    imprimir "igual! \ n" 
más 
    imprimir "diferente! \ n" 
final
 

Imprimirá "igual". En python, NO hay forma de que pueda hacer eso. A los efectos de la metaprogramación, la implementación de marcos experimentales y similares, esta increíble capacidad dinámica de Ruby es extremadamente atractivo. PERO, si estamos hablando de aplicaciones grandes, desarrolladas por muchas personas y mantenidas por más, incluyendo todo tipo de bibliotecas de diversas fuentes, y que necesitan entrar en producción en sitios de clientes ... bueno, no QUIERO Un lenguaje que es MUY dinámico, muchas gracias. Odio la idea de que una biblioteca rompa involuntariamente otras no relacionadas que confían en que esas cadenas son diferentes: ese es el tipo de "canal" profundo y profundamente oculto, entre piezas de código que MIRAN separadas y DEBEN SER separadas, que deletrean la muerte en programación a gran escala. Al permitir que cualquier módulo afecte el comportamiento de cualquier otro "encubierto",

Si tuviera que usar Ruby para una aplicación tan grande, trataría de confiar en restricciones de estilo de codificación, muchas pruebas (para volver a ejecutar cada vez que CUALQUIER cosa cambie, incluso lo que debería estar totalmente sin relación ...) y similares, para prohibir el uso de esta función de lenguaje. Pero NO tener la función en primer lugar es incluso mejor, en mi opinión, al igual que Python sería un lenguaje aún mejor para la programación de aplicaciones si se pudiera "concretar" cierto número de funciones integradas, por lo que SABÍA que , por ejemplo, len("ciao")es 4 (en lugar de tener que preocuparse subliminalmente si alguien ha cambiado el enlace de nombre lenen el __builtins__ módulo ...). Espero que eventualmente Python "clave" sus elementos integrados.

Pero el problema es menor, ya que volver a vincular los elementos integrados es una práctica bastante obsoleta y poco común en Python. En Ruby, me parece importante, al igual que las instalaciones macro demasiado potentes de otros idiomas (como, por ejemplo, Dylan) presentan riesgos similares en mi opinión (espero que Python nunca tenga un sistema macro tan poderoso, no importa el atractivo de "dejar que las personas definan sus propios pequeños lenguajes específicos de dominio integrados en el lenguaje mismo": en mi humilde opinión, perjudicaría la maravillosa utilidad de Python para la programación de aplicaciones, al presentar una "molestia atractiva" al aspirante a manipulador que acecha en el corazón de cada programador ...).

Alex

Buena suerte

Ninguna de las descripciones de ejemplo dadas es objetiva o comprobable. Todos son bombo y opinión.

... simplicidad y productividad ... más rápidamente ... más efectivamente.

Intentalo

Tome un pequeño proyecto de muestra del tipo que probablemente esté haciendo y pruébelo con todos los idiomas que le interesen. Luego publique su revisión objetiva y todos lo sabremos.

Creo que parte del problema es que cualquiera que sepa lo suficiente como para comentar significativamente sobre uno o más idiomas tendrá un sesgo. En casi 4 décadas de programación, he trabajado en más idiomas de los que puedo contar. Puedo darle opiniones (algunas de ellas fechadas) sobre algunos de esos idiomas, pero ninguna de esas opiniones será imparcial.

Tomo el enfoque de usar el lenguaje correcto para el trabajo. Usted pregunta específicamente sobre el desarrollo web , pero sigue siendo una categoría bastante amplia, algo así como decir que está interesado en la fotografía. ¿Micro? Astro? etc. Aunque estoy de acuerdo en que PHP no es un lenguaje emocionalmente satisfactorio para trabajar, para muchos clientes es el lenguaje correcto en función de una serie de factores, entre los cuales se encuentra la capacidad a largo plazo de encontrar programadores para arreglar el sitio después de que te vayas. y / o ser atropellado por un autobús.

Entonces, tal vez debería mirar a los tipos de clientes que están interesados ​​en proyectos que se prestan a algo diferente, y luego trabajar para hacer que sea interesante para ellos.

Pitón

El propósito más universal y general de todos ellos, pero también en el caso de la programación web, ofrece una mayor variedad de productos. Tener una interfaz WSGI estandarizada garantiza una gran interoperabilidad entre el marco y los servidores. Algunos de los productos web notables de Python:

• Django: marco de alto nivel maduro y completo con ORM avanzado, sistema de plantillas, manejo de formularios, etc.
• Twisted: marco para la programación de red controlada por eventos (asíncrona), se puede usar para chats, servidores de socket, servicios web, lo que sea.
• Tornado: también marco basado en eventos, pero este está diseñado para servicios web asíncronos.

Rubí

Ruby también es un lenguaje bastante universal. Pero, con mucho, su producto más notable es Ruby on Rails. Su diseño ha sido inspiración para muchos (incluido Django mencionado anteriormente).

JavaScript

Actualmente, la única opción del lado del servidor para JS es node.js. Es muy similar a Tornado y Twisted (por lo que se inspiró). Sin embargo, todavía carece de un marco completo similar a Django o RoR construido sobre él.

Scala

Al ser un lenguaje funcional, es excelente para la computación paralela masiva, en lo que respecta a la programación web de uso general, existe Lift - marco web inspirado en RoR, utilizado por ejemplo por FourSquare.

En mi último proyecto web comencé con PHP porque lo había usado antes para proyectos web (inicio rápido), pero tuve muchos problemas con el lenguaje, por ejemplo, mal soporte UTF-8 y tipeo dinámico. También tengo algunos antecedentes de Java y realmente disfruto la escritura estática y las buenas herramientas de refactorización. Java también tiene un buen rendimiento en comparación con PHP. Pero también me gusta la expresividad de la programación funcional.

Scala y Play Framework

Con la experiencia anterior, realmente disfruto del lenguaje de programación Scala, está estáticamente tipado, tiene soporte para programación funcional y orientada a objetos y tiene un buen rendimiento en comparación con otros lenguajes utilizados para el desarrollo web. Pero no me gustaron los frameworks web para Java y los servlets, y encontré Play Framework que tiene soporte para Scala y Java y tiene un ciclo de desarrollo muy rápido: guarde el archivo y actualice su página web. Estuve muy satisfecho con Scala & Play Framework el último mes. Pero el soporte de Scala en Play Framework aún no es muy maduro, y tampoco el soporte de herramientas.

En resumen, recomiendo Scala como lenguaje de programación y Play Framework como marco web.

En realidad, probablemente esté viendo tres tipos de recursos:

• El que explica los conceptos básicos del lenguaje y por qué quieres usarlo,
• El que compara varios idiomas.
• El que critica algún aspecto de un lenguaje.

Ambos recursos estarían sesgados.

• Cuando explicas algo sobre un idioma, la mayoría de las veces intentas convencer al lector de que lo use. Así que rara vez dirías que el idioma apesta.
• Cuando compara varios idiomas, siempre tiene una preferencia personal por uno de ellos.
• Cuando criticas algo, bueno, es casi imposible ser neutral.

Puede tener la oportunidad de encontrar una comparación neutral, pero es muy difícil escribir una. Personalmente, nunca podría escribir una comparación entre un lenguaje real y PHP sin criticar PHP todo el tiempo. Y estoy bastante seguro de que no estoy solo para no ser lo suficientemente neutral.

Si desea tener una visión general de los diferentes idiomas, debe aprenderlos usted mismo y leer mucho . Al aprender, me refiero a conocer los conceptos básicos del idioma, pero poder tener tu propia opinión . No es porque haya leído un manual de Ruby que pueda explicar qué es bueno y qué es malo en este idioma.

Esto significa que tienes que pasar tiempo (meses o incluso años) practicando. O puedes leer mucho. Pero trata de leer cosas contradictorias . Si alguna persona escribe que odia PHP y PHP es uno de los peores lenguajes de la historia, especialmente en comparación con lenguajes reales como Ruby, C # o Java, intente también encontrar a una persona que diga que PHP es maravilloso, y es mucho más fácil de usar que C #, mucho más rápido que Java, y mucho ... (realmente no sé qué) que Ruby.

Recuerda una cosa: si ya conoces bien un idioma, serás muy crítico al principio cuando aprendas otro , creyendo que el idioma que ya conoces es mejor y mucho más fácil de usar. Es como los usuarios de Linux que odian a Windows y los usuarios de Windows que odian a Linux: de hecho, ninguno de los dos sistemas operativos es mejor; es solo que un usuario de Linux no sabe cómo usar Windows, y viceversa. Solo después de adquirir suficiente experiencia en ambos, podrá decidir correctamente cuál es mejor para usted.

Lo último, a menudo olvidado: también es muy importante poder evaluar el "entorno" de un idioma:

• ¿Qué tan bueno es el marco (o los marcos más utilizados)?
• ¿Es fácil encontrar un servicio de alojamiento? ¿Aprecias el IDE?
• ¿Hay muchas bibliotecas de terceros bien escritas?
• ¿La comunidad está compuesta por desarrolladores altamente profesionales, o principalmente por principiantes que no saben nada sobre programación en general, ni sobre el lenguaje en sí?
• ¿Es la documentación lo suficientemente detallada y fácil de buscar y entender?
• ¿Se actualizan con frecuencia el lenguaje y los marcos?
• etc.

Bueno, dado que uno de sus criterios parece ser "es divertido trabajar con él", creo que le gustaría encontrar información sesgada. Si el autor de algo es un apasionado de su idioma de elección, existe una gran posibilidad de que dé una evaluación parcial.

Tal vez deberías abordarlo desde la otra dirección. Como parece que estás hablando de hacer un cambio profesional en lugar de un pasatiempo, tal vez deberías encuestar algunos anuncios de trabajo, encontrar algunas tecnologías / idiomas interesantes y buscarlos.

En cuanto a los idiomas que tienen objetivos específicos, muchos idiomas no los tienen. La mayoría de los idiomas que enumeraste son de uso bastante general. Por ejemplo, el lenguaje Ruby es un lenguaje de propósito general bastante adecuado para muchas tareas. Una vez que le agregas un marco, como Rails , eso tiene un objetivo bastante específico.

Esto no es exactamente lo que estabas preguntando, pero si estuviera buscando algo para sacarme de la rutina profesional del desarrollo web, y al mismo tiempo aprovechar esa experiencia y contactos, me gustaría escribir aplicaciones de Android y iPhone. Ser capaz de vender una aplicación que complemente el sitio web de un cliente realmente podría hacer que se destaque desarrollando para un Internet al que se accede cada vez más a través de dispositivos móviles.

¿Realmente has alcanzado el límite de PHP, o solo los límites de PHP tal como lo conoces?

¿Has mirado en Drupal ? Es un marco de programación y CMS basado en PHP que fomenta firmemente los buenos estándares y prácticas de codificación. (Habiendo tenido que trabajar con OSCommerce en trabajos anteriores, siento su dolor allí.) Aunque está basado en PHP, es lo suficientemente diferente como para que a menudo la forma "correcta" de hacer algo en PHP puro no sea la forma correcta de hacerlo en Drupal, y vas a tener una buena curva de aprendizaje para escalar para dominarlo realmente. Sin embargo, puede cambiar sus perspectivas sobre las capacidades de PHP como lenguaje y el desarrollo web en su conjunto.