Llegamos a ustedes gracias a:



Reportajes y análisis

10 cultos de desarrollo de software a los que vale la pena unirse

[12/11/2019] Cada programador conoce esa sensación. Usted ha escrito algunas líneas, las ha probado y las ha registrado en algún repositorio. Ahora es el momento de detenerse, respirar hondo, quizás reflexionar sobre la majestuosidad de todo, y luego volver a obsesionarse con su último culto de programador.

No importa si comenzó su primera clase de programación este otoño o si ha estado escribiendo código desde que tenía que ser procesado en el panel frontal de un Altair. Es muy divertido hablar de cosas mundanas como la corrección o la precisión. Solo el cliente es el que habla sobre qué tan bien el código cumple con las especificaciones.

La verdadera descarga de adrenalina proviene de vagar por los páramos como un poeta, atormentado y asediado por algunos de los matices más finos del arte de escribir código. Pegar variables y funciones juntas es aburrido. Solo vale la pena vivir la vida cuando uno se une a una tendencia, se pone en la cola detrás de un genio carismático, y se une a un debate estridente sobre los detalles de decirle a las computadoras qué hacer.

A continuación, 10 de los cultos más embriagadores a los que puede unirse.

El mágico espacio en blanco

Comencemos con uno de los debates más intensos, la pregunta sobre cómo estructuramos el espacio en blanco en nuestro código. Es un debate que literalmente trata sobre algo que no se puede ver y que a menudo no tiene ningún efecto. Pero la irrelevancia absoluta no importa, porque los programadores pueden discutir durante horas sobre el uso de las tabulaciones o los espacios en su código o, peor aún, cómo incluir espacios dentro de las líneas.

Un revisor de código le comentó a un gerente de proyecto que mi código estaba tan por debajo de los estándares que, inmediatamente, podía ver las terribles fallas cuando aparecía en la pantalla. Resulta que el "estándar era solo el número 19.4 de la infame guía de estilo de Airbnb, las formas preferidas de la compañía para formatear JavaScript. Mi error fue no poner un espacio en ambos lados de un signo igual. (Todavía estoy avergonzado, pero las profesiones públicas de culpa son parte de mi plan de 12 pasos). Mi crítico pudo decir que mi guion estaba "fuera del estándar con perfecta cortesía. ¿Por qué? Porque alguien se molestó en compilar una lista de reglas muy formales y serias, y luego el equipo decidió, en un momento de insania, adoptarlas.

Pero no nos dejemos atrapar demasiado por el hecho de que la mayoría de los algoritmos de análisis no se preocupan por el espacio en blanco, y omiten los espacios y las pestañas sin detenerse. Llamarlos "supremacistas del espacio en blanco solo los enojará. Llamémoslos puristas y celebremos su atención al detalle porque eso es muy raro hoy en día.

Llaves o sangrías

El lenguaje C nos ha dado muchas ideas sorprendentes, pero la más controvertida puede ser usar llaves para indicar el inicio y el final del bloque de código. A algunas personas les resulta fácil desempacar los bloques anidados y descubrir cómo se combinan las llaves. Entienden que fue un gran avance con respecto a la era de los números de línea y las declaraciones GOTO.

Sin embargo, existen otros que consideran que contar y emparejar es todo un problema, y no es un gran avance respecto al antiguo código de espagueti. Ellos encuentran a los lenguajes más nuevos, como Python, bastante atractivos. También les gustan los formatos de datos como YAML, que usan la sangría para indicar dónde comienzan y terminan los bloques anidados. Claro, están constantemente contando espacios o sangrías en lugar de llaves, pero eso es un paso adelante para ellos.

Podría elegir volar por encima de esta vorágine y pensar que los bloques de expresiones son solo bloques de expresiones, pero entonces no podría unirse a los argumentos. Elija el mal menor: llaves o sangrías y nunca mire hacia atrás.

Programación funcional

A los codificadores les encanta escribir sus instrucciones para las computadoras en líneas simples, limpias y concisas y les gusta emitir estas órdenes siempre que sea conveniente y práctico. El problema es que alguien descubrió que es mucho más fácil analizar y optimizar el software donde las instrucciones están organizadas en buenas funciones estructuradas, como cuadros negros con entradas y salidas claramente definidas. Las instrucciones aparentemente aleatorias para incrementar alguna otra variable o desactivar alguna función -lo que los programadores funcionales llaman "efectos secundarios- solo complican el asunto.

El culto a la programación funcional cree que todos debemos aspirar a esta estructura limpia de funciones, que no arrojan efectos secundarios en momentos aleatorios. Esto hace que la creación de código libre de errores y con muchos subprocesos sea mucho más simple. O al menos así lo consideran.

Ahora existen docenas de idiomas para los verdaderos creyentes en el enfoque funcional. Y muchos de ellos se inclinan ante la realidad de que los efectos secundarios a veces hacen que el código sea más fácil de crear y mantener. Lenguajes funcionales como Scala y Frege viven en el mundo con el apoyo de la ubicua máquina virtual Java, mientras que Rust es la última opción para aquellos que deben escribir el código del sistema.

Programación no funcional

Los devotos de la programación funcional tienden a ser académicos que escriben algoritmos complicados que abordan temas matemáticos abstractos. En otras palabras, estos son algunos de los algoritmos más fáciles de escribir de manera funcional. El resto del mundo lidia con interfaces de usuario más desordenadas para los humanos, que no tienden a pensar en abstracciones funcionales muy anidadas.

Existen pocas opciones funcionales en las listas de los lenguajes de programación más populares. Esto se debe, en gran parte, a que los programadores se han cansado de construir las aplicaciones más comunes con una camisa de fuerza funcional. Las alternativas han tomado nombres como programación imperativa, declarativa y orientada a objetos. Éstas no se tratan tanto de movimientos contrarios, sino más bien de colecciones o programadores que nunca fueron absorbidos por el culto funcional y se negaron firmemente a unirse.

Programación tipificada

La primera generación de lenguajes liberó a los programadores de la necesidad de realizar un seguimiento de los registros dentro de la CPU y hacer referencia a datos con nombres de variables como x. Los programadores inmediatamente abusaron de esta libertad y comenzaron a sobrecargar todo tipo de datos en variables por todas partes. Cuando esto se volvió demasiado confuso, los diseñadores de lenguajes de programación inteligentes propusieron pedir a los programadores que agreguen solo unos pocos caracteres más junto a la declaración inicial de una variable, caracteres que deletrearían el tipo de datos que se iban a insertar en la variable. Luego, la computadora podría volver a verificar los cálculos y asegurarse de que al menos todos los datos que entran en una función sean del tipo correcto.

Un grupo de programadores con mentalidad matemática ha creado teorías elaboradas de datos tipificados que imaginan jerarquías de tipos elegantes y sofisticadas que convergen en la única y auténtica verdad libre de errores que se devolverá al final del cálculo. El culto del lenguaje tipificado aspira a crear programas que se aproximen a este hermoso ideal. Quieren tipos rigurosamente definidos que le permitan al compilador ofrecer seguridad absoluta de que los tipos equivocados no dejarán ningún error.

Programación sin tipo

Tan pronto como los amantes del lenguaje tipificado comenzaron a ganar fuerza, un movimiento contrario comenzó a declarar que gran parte del trabajo de escribir sus datos era una pérdida de tiempo. No es que los programadores intenten agregar una cadena y un entero a propósito y luego, cuando se ejecute, el programa se bloqueará inmediatamente con una excepción. No es que el compilador ahorre mucho tiempo al marcar este problema con unos minutos de anticipación.

Los amantes de la programación sin tipo imaginan que no vale la pena deletrear un tipo cada vez que se define. No solo eso, sino que la tipificación, a medida que hay más datos disponibles durante el cálculo, agrega limitaciones estrictas en la creación de estructuras de datos flexibles que se adaptan y mejoran.

No solo eso, sino que algunos de los compiladores automáticos están mejorando mucho en leer nuestras mentes e inferir el tipo correcto de la variable. Si las computadoras pueden resolverlo, ¿no deberíamos encargarles la limpieza?

Low code / sin código

Escribir software es difícil. Por lo tanto, no sorprende que los programadores se inspiren para crear cualquier automatización que les ahorre la molestia de escribir más código. Cuando esta automatización se vuelve lo suficientemente sofisticada, los desarrolladores comienzan a presumir de que cualquiera puede crear algo sofisticado con poco o ningún código.

El problema es que el trabajo aún requiere pensar como un programador sobre abstracciones ocultas y estructuras de datos elaboradas. Este pensamiento necesita ser codificado y establecido, de una forma u otra, como un archivo JSON o tal vez algún XML. Los automatizadores generalmente descartan este trabajo como una mera configuración, pero a veces podemos pasar tantas horas jugando con los archivos de configuración como con instrucciones escritas en lenguajes de programación oficiales.

Estos detalles no importan demasiado. Los programadores siempre se sentirán atraídos por la automatización porque odian hacer lo mismo dos veces. Aún más importante, los ejecutivos siempre soñarán que la automatización reducirá sus costos y elevará el resultado final. Este sueño sostendrá el culto al low code, o sin código, durante meses y meses de retoques con opciones sin código.

Código Prolix

Durante los últimos 30 o 40 años, los oráculos de la programación han pronosticado que estaríamos haciendo clic en los íconos, arrastrando los diagramas de flujo o agitando nuestras manos para decirles a las máquinas qué hacer. Cualquier cosa menos escribir y agregar pulsaciones de teclas a algún archivo de texto. A pesar de las predicciones, la línea de comandos y los lenguajes de programación basados en texto simplemente no morirán. Más bien, parece que a los programadores les encanta escribir más que nunca y todas las últimas tendencias aparentan tratarse de texto únicamente.

Defensores de la privacidad

La gente ama su privacidad y los programadores no son la excepción. En todo caso, los programadores saben cuán invasivas pueden ser las computadoras. El problema es que muchos modelos de negocios implican el uso de software sofisticado para anticipar lo que los clientes quieren. Claro, podríamos preguntarles a las personas directamente, pero la mayoría de éstas se encuentra demasiado ocupada para completar otro formulario. Entonces, la única forma de hacer que estos modelos de negocio funcionen es dejar de lado las preocupaciones en torno a la privacidad... pero solo por esta instancia. Cuando se trata de elegir entre un trabajo y la privacidad de otra persona, a menudo no hay competencia.

Existen algunas concesiones interesantes. Las matemáticas que preservan la privacidad pueden funcionar en algunos casos y, al mismo tiempo que ofrecemos nuevas funciones de lectura de la mente, se dispone de algunas formas sofisticadas de garantizar que podamos proporcionar cierta apariencia de privacidad.

Defensores de la apertura

Todos adoran la idea del código y los estándares abiertos -hasta que, al permitir que los competidores tengan éxito, entran en conflicto con su propio modelo de negocios. Algunos de los mayores defensores del software de código abierto también son los que se mantienen con la receta secreta más patentada. Google, por ejemplo, ha apoyado maravillosos proyectos de código abierto y ha hecho campaña públicamente en contra del software de gestión de derechos digitales, que les otorga el poder de ganar algo de dinero a los creadores de contenido. Pero si pregunta por los algoritmos de clasificación de su motor de búsqueda, ellos trazan la línea. Eso no está abierto.

No están solos. La mayoría de las empresas siguen un enfoque flexible sobre la apertura. La apertura siempre es buena si se aplica al modelo de negocio de otra persona, pero no al suyo.

Todas las anteriores

Si bien todos estos cultos suenan absolutos y los verdaderos creyentes actúan como si las reglas fueran leyes dictadas por un Dios enojado listo para desplegar rayos, la realidad es que el mundo de la programación está lleno de trucos inteligentes que nos permiten extender las definiciones. A menudo, si es un poco inteligente respecto a cómo hacerlo, es posible unir dos cultos que parecen opuestos.

Algunos de los lenguajes funcionales, por ejemplo, son lo suficientemente flexibles como para permitirle hacer algunos trucos no funcionales si lo considera necesario. Mientras tanto, otros argumentarán que incluso las herramientas venerables como C son, en última instancia, lenguajes de programación funcionales. Algunos de los detractores de la tipificación debilitan los lenguajes de verificación de tipo, simplemente definiendo todas las funciones para tomar los objetos más genéricos en la jerarquía de tipos.

No existe ninguna razón por la cual no pueda ser lo suficientemente inteligente y crear su propia combinación de cultos, donde se mezclen estas diferentes filosofías, sin importar cuánto parezcan estar en conflicto. Usted es quien escribe el código. Usted es quien da las órdenes aquí.