Llegamos a ustedes gracias a:



Reportajes y análisis

10 furiosas batallas entre los desarrolladores de hoy

PHP versus Node, SQL versus NoSQL, compilado versus scripting; los debates apasionados y divisiones técnicas que definen la programación de hoy.

[23/12/2014] Si piensa que está conectado en la mente humana o es un producto inevitable de la formación de la sociedad, el dualismo define gran parte de nuestras vidas: el comunismo versus el capitalismo, lo salado versus lo dulce, -pasar la pelota versus correr con el balón en el fútbol. Dondequiera que miremos, los pares están encerrados en una batalla eterna, y nos presenta innumerables oportunidades para definirnos a nosotros mismos de acuerdo a qué lado de la línea favorecemos en un momento dado.

Esto puede ser aún más evidente en la industria informática, donde las tecnologías -que compiten por nuestros corazones, mentes y chequeras- se definen a menudo por las diferencias que ofrecen con respecto a su competencia. Por un lado hay X; por el otro, definitivamente no X. Y los fanáticos se alinean para burlarse y hostigar al lado contrario. Sin estas batallas, sin estos grandes argumentos y opciones, los repositorios se habrían fusionado hace mucho tiempo y nosotros estaríamos en otra parte, tal vez con un poco menos de innovación.

Lo que sigue son 10 de las batallas más interesantes, que existen entre los desarrolladores de hoy. Con cada nuevo proyecto que emprendemos, nos enfrentamos a las preguntas fundamentales que subyacen en las diferencias entre estas tecnologías. ¿Estamos a favor de la simplicidad o de la corrección? ¿del código abierto o del apoyado por las empresas? ¿soportes o espacios en blanco? Al igual que el Yin y el Yang, estas preguntas definen las grandes decisiones que deben tomar los desarrolladores de la empresa hoy en día.

Batalla No. 1: PHP versus Node.js

Nunca amado por los científicos de la computación, PHP fue abrazado por las masas que querían añadir un poco de inteligencia a un sitio Web. Estas hordas nos han dado marcos increíbles como WordPress, Drupal, Joomla, y más. Gran parte de la Web está construida en PHP.

Ahora hay grietas en el modelo. Los jóvenes tienen un amor a ciegas con Node.js, un mecanismo de servidor programado en JavaScript. De repente, los programadores pueden escribir código que se ejecuta en el cliente o en el servidor. No hay necesidad de aprender dos idiomas. Node.js tiene sus peculiaridades, pero ya hay marcos increíbles que ofrecen la función a la par con las mejores pilas de PHP.

¿La próxima generación será la que abrazará la sencillez de la escritura JavaScript y solo JavaScript? ¿O será que se aferrarán a la facilidad de incrustar código HTML? A quienes les gusta JavaScript seguramente se irán con Node. Aquellos que quieran utilizar las pilas estables de caballos de batalla de PHP como WordPress o Drupal, sobresaldrán de la tormenta Node.js.

Batalla No. 2: MySQL versus PostgreSQL

Las dos grandes bases de datos de código abierto se han enfrascado en un combate por cerca de dos décadas, sin un final a la vista. Por un lado, MySQL ha capturado la mayor parte de la carga de trabajo básica de la Web, en parte gracias a su facilidad de instalación y configuración. En el otro lado, PostgreSQL ha prometido durante mucho tiempo un mejor mecanismo de transacción para proteger los datos en caso de fallas. Las dos han estado creciendo juntas; como ahora que MySQL ofrece capacidades mejoradas de transacción, y PostgreSQL ha simplificado sus obstáculos de inicio.

Las viejas diferencias todavía definen líneas de batalla de hoy. PostgreSQL es vista como más "confiable" y MySQL como más "rápida", pero las diferencias son más fantasmas que realidades. Los viejos hábitos tardan en morir, y estos dos paquetes podrían estar compitiendo por su cuota en la mente de los usuarios por otros 20 años, y PostgreSQL está consiguiendo un poco de viento en popa durante los últimos tiempos de parte de piratas informáticos inconformista y personas que odian a Oracle.

Batalla No. 3: Swift versus Objective-C

Apple siempre ha sido el reducto solitario de Objective-C, la programación orientada a objetos. Pero los tiempos cambian y ahora Swift ofrece una sintaxis moderna libre de muchas de las molestias que han mantenido a los programadores recelosos de construir plataformas de Apple. Claro, a quienes aprendieron C desde la cuna no les importan los asteriscos y archivos múltiples, pero los recién llegados gestados en Python, Ruby, e incluso Java, son llevados a la distracción.

¿La estructura limpia de Swift capturará la cuota de la mente de los desarrolladores de Apple? ¿Los desarrolladores de Python y Rubí correrán hacia iOS y desplazarán a la vieja guardia de Objective-C? ¿O el mundo será dominado por la increíble eficiencia de los programadores comprobados de Objective-C? ¿Las nuevas bibliotecas y funciones serán codificadas en Swift o Objective-C? Apple ha dicho públicamente que ambos pueden coexistir. Así que los desarrolladores seguramente se quedarán con lo que les es familiar. Los que aman Python o Java se moverán hacia Swift. Los que crecieron con C se quedarán con Objective-C.

Batalla No. 4: Python versus Rubí

Hace mucho tiempo, un lenguaje de programación era como masticar una goma de mascar para el software. Si necesitaba pegar o unir programas, podría escribir código simple en el sistema operativo para que suceda.

En algún momento, las personas que amaban estas pequeñas lenguas, empezaron a construir grandes programas que resultaron útiles. Rubí explotó cuando se "casó con el marco Rails -el combo hace que sea sencillo atar un extremo frontal sofisticado para una base de datos con solo unas pocas líneas de código.

Python, por su parte, encontró su propio club de fans en las ciencias. Ahora se utiliza con frecuencia en los laboratorios de todo el mundo. Y con el análisis estadístico ocupando cada esquina del mundo empresarial, Python está ganando fuerza con los "laboratorios" de ciencia de datos del mundo de los negocios.

¿La próxima generación encajará en la simplicidad de Python que enmarca el código con el espacio en blanco? ¿Rubí se expandirá más allá de Rails? ¿Las funciones incorporadas de Python son una apuesta mejor a los "bloques" de Ruby? ¿Será mejor alinearse con los científicos o con los hackers Web? Tal vez las líneas de batalla ya se hayan endurecido para todos los tiempos, con los Gurús de la Web pegados a sus armas con Rails y los científicos enclaustrados en las bibliotecas de Python.

Batalla No. 5: SQL versus NoSQL

A un lado del pasillo están las bases de datos que utilizaban sus abuelos. Los datos ingresan muy bien en las tablas y la base de datos ejecutará consultas exóticas para hacer coincidir las tablas con las filas correctas. Por otro lado están los advenedizos NoSQL, que hacen grandes promesas acerca de la velocidad y el paralelismo, con la pequeña salvedad de que de vez en cuando las cosas podrían fallar y la base de datos enviará respuestas incorrectas o inconsistentes.

¿Los enfoques de bases de datos tradicionales con protección de transacción tradicional son lo correcto para sus datos? ¿O quiere una herramienta más rápida, más barata, más moderna que repartirá la carga efectiva sobre un grupo de máquinas? Claro, la consistencia y la precisión son importantes para los bancos, pero ¿qué pasa con una tabla llena de tonterías al azar a través de Internet? ¿Es necesario que todo tenga la mejor protección que los científicos de datos pueden ofrecer? La respuesta (a menudo) es: Los que necesitan consistencia absoluta como los bancos y las compañías aéreas, van con bases de datos tradicionales SQL y con transacciones reales. Todos los demás eligen a la veloz, NoSQL más simple y escalable.

Batalla No. 6: JavaScript versus Dart and Go (o tal vez el propio Google)

JavaScript puede tener fans en las granjas del cubículo de Google, pero no lo sabría de la incesante oleada de sustituciones. En primer lugar, existió GWT (Google Web Toolkit), un compilador cruzado inteligente que volvía Java en JavaScript. Si alguna vez ha visto los montones de código para Gmail, entre otros productos de Google, sabrá que no fue hecha a mano en JavaScript. Entonces Google creó Dart and Go, dos lenguas que podrían reemplazar a JavaScript en el navegador algún día.

Dart and Go tienen sus corazones en el lugar correcto. Arreglan los principales problemas evidentes con JavaScript y la pila del navegador, pero a muchas personas no les importa. JavaScript en el servidor ha venido explotando, gracias a Node.js. ¿Quién necesita algo más?

A pesar de su poder, Google se enfrenta a una lucha cuesta arriba contra un enorme ejército de programadores que aprendieron JavaScript hace tiempo, y ahora quiere volver a escribir su pila de servidor en el mismo. Es difícil luchar contra la inercia. Pero quizá los superlativos que los primeros adoptantes han estado alabando sobre la sintaxis más limpia y modelos simplificados de Dart and Go serán demasiado fuertes para que las masas lo ignoren.

Batalla No. 7: Cheff versus Puppet

Hace mucho tiempo, una corporación tenía unos pocos servidores en la trastienda y la instalación de nuevo software era simple. Entonces la nube explotó y todos los sitios Web que valían la pena se ejecutan en un clúster de máquinas que necesitan mantenerse en funcionamiento. Eso significaba hacer las cosas N veces en N máquinas y no echarlas a perder. Chef and Puppet son dos herramientas que han surgido para ayudar a que los administradores ejecuten una línea de montaje para la configuración de las máquinas en la nube.

Los especialistas DevOps dedicados a Chef premian la flexibilidad de la herramienta de gestión de la configuración que le permite escribir instrucciones para crear máquinas en Ruby. "El poder de Ruby es gratis", anotan. Puppet también configura el clúster pero con las instrucciones especificadas en un lenguaje de JSON como centrado en hacer bien una cosa. Mientras que las versiones más recientes de Puppet permiten un poco de Ruby, el lenguaje básico sigue siendo dominante. ¿Es mejor crear una sintaxis personalizada para el trabajo o darle a la gente el poder (y el peligro) de un lenguaje de propósito general ampliamente abierto?

Batalla No. 8: Hudson versus Jenkins

La idea de la integración continua era un truco para probar e implementar automáticamente todo el código nuevo a un repositorio. Cuando empezó a trabajar bien, la gente comenzó a luchar por su legado.

A un lado de la batalla está Hudson, la rama que es oficialmente parte de la Fundación Eclipse, y está dirigida por muchas de las personas en Oracle que heredaron el código de Sun. Traen la mejor actitud de las empresas a la construcción de una herramienta seria y estable para las empresas. Por otro lado está Jenkins, el hogar de muchos de los hackers originales que gustan de experimentar. El árbol Jenkins parece evolucionar mucho más rápido con las nuevas versiones que aparecen tan a menudo como cada semana.

La batalla entre Hudson y Jenkins es emblemática como una de las batallas más grandes en el mundo de desarrolladores, entre una firme devoción a la comprobación detallada y código estable frente a rasgos más rápidos de evolución, correcciones más rápidas ante gusanos, y una mayor participación de la comunidad de desarrolladores en general.

Batalla No. 9: MySQL versus MariaDB

Hablando de líneas de batalla dibujadas alrededor de los proyectos apoyados por Oracle, no olvidemos el cisma MariaDB con MySQL.

Cuando Oracle compró MySQL, los fans de código abierto tenían miedo de lo que podría venir de una empresa basada en una herramienta de gran alcance, propietaria. Sus temores han sido en gran parte infundados. Pero eso no ha detenido a Monty Widenius, uno de los fundadores de MySQL, en huelga por su cuenta. MariaDB ofrece gran parte de la misma sintaxis y características como MySQL, pero ahora viene con algunas características nuevas y motores de almacenamiento que van un poco más rápido, por lo menos a los ojos de los amantes MariaDB.

¿El mercado escogerá el rudimentario, el nuevo, o va a seguir con el código dominante que nos ha servido tan bien en los últimos años? ¿El mundo elegirá una pequeña pandilla de innovadores o una corporación grande, sólida dedicada a la estabilidad?

Batalla No. 10: Compiled versus scripting

La distinción entre código compilado y un script es tan clara como lo era antes, pero sigue siendo importante para los programadores. ¿Quieren que su código sea optimizado y traducido al código simple? ¿O quieren un enfoque más informal, donde la computadora interprete el código en tiempo de ejecución, permitiendo a veces que el código se modifique por sí mismo?

Por un lado están las lenguas clásicas como C y Java, apoyados por elaboradas suites de desarrollo. Por el otro están los lenguajes más simples de scripting como Python, Ruby y JavaScript que se pueden crear en un editor de texto y llevar inmediatamente a un pequeño traductor en ejecución. Para hacer las cosas más complejas, hay soluciones híbridas como Groovy, un lenguaje de script de ish que se ejecuta en la máquina virtual de Java, en sí misma es una herramienta que hace mucha optimización en tiempo de ejecución. Tal vez la distinción se esté desvaneciendo, pero eso no impide que la gente discuta sobre si realmente vale la pena el elaborado trabajo del compilador.