8 problemas más irritantes en programación

Redaccion

Los programadores pueden ser un poco más civilizados que los caballeros medievales, pero eso no significa que el mundo técnico moderno no tenga su parte de dragones...

CIO

Aquí hay dragones: Estos rincones oscuros del mundo de la codificación pueden ser enemigos formidables, incluso para los profesionales más experimentados en la programación.

Se ha dicho que los territorios inexplorados de los viejos mapas estaban a menudo marcados con la advertencia ominosa: “Aquí hay dragones”. Tal vez apócrifa, la idea era que nadie que vagara por estos rincones desconocidos del mundo lo hiciera sin estar listo para batallar contra un enemigo aterrador. Cualquier cosa podría suceder en estas regiones misteriosas, y a menudo no era nada bueno.

Los programadores pueden ser un poco más civilizados que los caballeros medievales, pero eso no significa que el mundo técnico moderno no tenga su parte de dragones técnicos esperándonos en lugares imprevistos: Problemas difíciles que esperan hasta que el plazo esté a minutos; complicaciones que han leído el manual y saben lo que no está bien especificado; dragones malvados, salen de su jaula, que saben colarse en errores incipientes y fallos intempestivos, a menudo justo después de que el código es entregado.

Lea también: 4 tipos de personas que detesta el CSO

Habrá algunos que descansan tranquilamente por la noche, calentados por su ingenua seguridad de que las computadoras son totalmente predecibles, generalmente produciendo las respuestas correctas. Oh, qué poco saben. Para todo el trabajo duro de los diseñadores de chips, desarrolladores de lenguaje y millones de programadores en todas partes, todavía hay espinas filosas de problemas de programación que pueden llevar incluso a los programadores más poderosos a arrodillarse.

Aquí están siete de los rincones más rudos del mundo de la programación en donde habíamos puesto los marcadores grandes que leían, “aquí hay dragones.”

1. multihilo/ Multithreading

Parecía una buena idea: desglosar su programa en secciones independientes y dejar que el sistema operativo los ejecute como pequeños programas separados. Si los procesadores tienen cuatro, seis, ocho o más núcleos, ¿por qué no escribir su código para que pueda tener cuatro, seis, ocho o más subprocesos utilizando todos los núcleos de forma independiente?

Le interesa: ¿En proceso de convertirse en un CIO?

La idea funciona cuando las partes están, de hecho, completamente separadas y no tienen nada que ver unas con otras. Pero una vez que necesitan acceder a las mismas variables o escribir bits en los mismos archivos, todas las apuestas están desactivadas. Uno de los hilos va a llegar a los datos primero y no se puede predecir qué hilo será.

Por lo tanto, creamos monitores, semáforos y otras herramientas para organizar el desorden multiproceso. Cuando funciona, funciona. Simplemente añaden otra capa de complejidad y convierten el acto de almacenar datos en una variable en un elemento que requiere un poco más de pensamiento.

Cuando no funcionan, es puro caos. Los datos no tienen sentido. Las columnas no se suman. El dinero desaparece de las cuentas con un poof. Son todos bits en la memoria. Y buena suerte tratando de identificarlos. La mayoría de las veces los desarrolladores terminan bloqueando grandes bloques de la estructura de datos para que sólo un hilo pueda tocarlo. Eso puede detener el caos, pero sólo matando la mayor parte de la ventaja de tener múltiples hilos trabajando en los mismos datos. Es posible que también lo reescriba como un programa de “un solo hilo“.

Leer más: Conozca a los CIO mejor pagados de 2016

2. Cierres

En algún momento, alguien decidió que sería útil pasar las funciones como si fueran datos. Esto funcionó bien en casos simples, pero los programadores comenzaron a darse cuenta de que los problemas surgían cuando las funciones alcanzaban más allá de sí mismos y accedían a otros datos, a menudo llamados “variables libres”. ¿Qué versión era la correcta? ¿Fueron los datos cuando se inició la llamada a la función? ¿O fue cuando la función realmente se ejecutó? Esto es especialmente importante para JavaScript donde puede haber intervalos largos entre los dos.

La solución, el “cierre”, es una de las mayores fuentes de dolores de cabeza para los programadores de JavaScript (y ahora Java y Swift). Los novatos e incluso muchos veteranos no pueden averiguar qué está cerrando y dónde pueden estar los límites del llamado cierre.

El nombre no ayuda -no es como si se cierra el acceso permanentemente como en un bar que anuncia la última llamada. En todo caso, el acceso está abierto, pero sólo a través de un agujero de gusano en la continuidad datos-tiempo, un extraño mecanismo de cambio de tiempo que está destinado a generar un programa de televisión de ciencia ficción. Pero llamarlo un “mecanismo de acceso de pila compleja” o “sistema de malabares de control de datos” parece demasiado largo, por lo que estamos atrapados con “cierres”. No me hagan empezar en si alguien tiene que pagar por las variables no libres. 

Conozca también: Conozca a los CIO mejor pagados de 2016

3. Datos demasiado grandes

Cuando la memoria RAM empieza a llenarse, todo empieza mal. No importa si está realizando análisis estadísticos de datos de consumo nuevos o trabajando en una hoja de cálculo aburrida. Cuando la máquina se queda sin memoria RAM, recurre a llamar una memoria virtual que se derrama en el disco duro súper lento. Es mejor que colapsar completamente o terminar el trabajo, pero ¡rayos! Sí que hace todo más lento.

El problema es que los discos duros son al menos 20 o 30 veces más lentos que la RAM y las unidades de disco de mercado masivo son a menudo más lentos. Si algún otro proceso también está tratando de escribir o leer desde el disco, todo se vuelve dramáticamente peor porque las unidades sólo pueden hacer una cosa a la vez.

La activación de la memoria virtual agrava otros problemas ocultos con el software. Si hay fallos de enrutamiento, comienzan a colapsar mucho más rápido porque los subprocesos que están atrapados en la memoria virtual del disco duro funcionan mucho más lentos que los otros subprocesos. Eso sólo dura un breve período, sin embargo, porque una vez que los hilos del wallflower recurren a la memoria, los otros hilos cuelgan. Si el código es perfecto, el resultado es simplemente mucho más lento. Si no es así, los defectos lo envían rápidamente al desastre. Ese es un pequeño ejemplo.

Manejar esto, es un verdadero desafío para los programadores que están trabajando con grandes pilas de datos. Cualquier persona que se descuide un poco con la construcción de estructuras de datos inútiles termina con el código que se ralentiza a paso de tortuga en la producción. Puede funcionar bien con unos cuantos casos de prueba, pero las cargas reales lo mandan a un espiral directo a fallar.

4. NP-completo

Cualquier persona con una educación universitaria en informática sabe de los misteriosos problemas envueltos en un acrónimo que rara vez se explica: polinomio no determinista completo, aka NP-completo. Los detalles toman a menudo un semestre entero para aprender, e incluso entonces, muchos estudiantes del CS salen con una noción nublada que nadie puede solucionar estos problemas porque son demasiado duros.

Los problemas NP-completos a menudo son bastante difíciles, si los atacan simplemente con fuerza bruta. El “problema del vendedor ambulante”, por ejemplo, puede tomar un tiempo exponencialmente largo ya que la ruta de ventas incluye más y más ciudades. Resolver el “problema de la mochila” al encontrar un subconjunto de números que se acerquen más a algún valor N, se resuelven probando todos los subconjuntos posibles, que es un número muy grande. Todo el mundo corre aterrorizado de estos problemas porque son el ejemplo perfecto de uno de los ‘cucos’ más grandes en Silicon Valley: algoritmos que no escalarán.

La parte difícil es que algunos problemas NP-completos son fáciles de resolver con una aproximación. Los algoritmos no prometen la solución exacta, pero se acercan bastante. Estos no pueden encontrar la ruta perfecta para el vendedor de viaje, pero pueden llegar a unos pocos puntos porcentuales de la respuesta correcta.

La existencia de estas soluciones bastante buenas, sólo hacen que los dragones sean más misteriosos. Nadie puede estar seguro de si los problemas son realmente difíciles o bastante fácil si usted está dispuesto a estar satisfecho con una respuesta que sea lo suficientemente buena.

5. Seguridad

Son conocidos que sabemos; Hay cosas que sabemos que conocemos“, dijo Donald Rumsfeld, secretario de Defensa durante la segunda administración Bush, en una conferencia de prensa. “También sabemos que hay desconocidos conocidos; Es decir, sabemos que hay algunas cosas que no sabemos. Pero también hay incógnitas desconocidas, de las que no sabemos que no sabemos.

Rumsfeld hablaba de la guerra en Irak, pero lo mismo ocurre con la seguridad informática. Los mayores problemas son los agujeros que ni siquiera sabemos que son posibles. Todo el mundo entiende que usted debe hacer su contraseña difícil de adivinar, eso es conocido. ¿Pero a quién le ha dicho que su hardware de red tiene su propia capa de software enterrada en su interior? La posibilidad de que alguien pueda omitir hackear su sistema operativo y en lugar de eso dirigirse a esta capa secreta, es una incógnita desconocida.

La posibilidad de que ese tipo de hackeo puede que no sea desconocido para usted ahora, pero ¿qué pasa si hay otros? No tenemos idea si podemos proteger los agujeros que ni siquiera sabemos que existen. Puedes anclar las contraseñas, pero hay grietas que ni siquiera puedes imaginar. Esa es la diversión de trabajar con seguridad informática. Y cuando se trata de la programación, la seguridad de pensamiento mental es cada vez más importante. No puede dejar que los profesionales de seguridad limpien su desorden.

6.Cifrado

El cifrado suena poderoso e impenetrable cuando los funcionarios encargados de hacer cumplir la ley se enfrentan al Congreso y piden lagunas oficiales para detenerlo. El problema es que la mayoría del cifrado se basa en una nube de niebla de incertidumbre. Qué pruebas matemáticas tenemos caen en suposiciones inciertas, como el que es difícil factorizar números realmente grandes o calcular un registro discreto.

¿Son esos problemas verdaderamente difíciles? Nadie ha descrito públicamente ningún algoritmo para romperlos, pero eso no significa que las soluciones no existan. Si usted encuentra una manera de escuchar a escondidas cada conversación y entrar a cualquier banco, ¿saldría corriendo a decirle al mundo y ayudarles a tapar los agujeros? ¿O permanecería en silencio?

El verdadero desafío es usar el cifrado en nuestro propio código. Incluso si confiamos en que los algoritmos básicos son seguros, hay mucho trabajo por hacer malabareando contraseñas, claves y conexiones. Si comete un error y deja una contraseña desprotegida, todo queda abierto.

7. Gestión de identidades

A todo el mundo le encanta el dibujo animado de New Yorker con la frase final, “En Internet, nadie sabe que eres un perro”. Incluso tiene su propia página de Wikipedia con cuatro secciones elaboradas. (En Internet, nadie conoce el viejo dicho de analizar el humor y diseccionar las ranas.)

La buena noticia es que el anonimato puede ser liberador y útil. La mala noticia es que no tenemos idea de cómo hacer nada más que comunicaciones anónimas. Algunos programadores hablan de “autenticación de dos factores”, pero los inteligentes saltan a la “autenticación de factor N”.

Después de la contraseña y tal vez un mensaje de texto a un teléfono móvil, no tenemos mucho que sea muy estable. Los lectores de huellas dactilares parecen impresionantes, pero muchas personas parecen dispuestas a divulgar cómo pueden ser hackeadas.

No mucho de esto importa para el mundo de la charla ociosa en Snapchat o Reddit, pero el flujo de páginas de Facebook hackeadas son un poco desconcertantes. No hay una manera fácil de manejar asuntos serios como la propiedad, el dinero, el cuidado de la salud o casi todo lo demás en la vida, excepto charlas pequeñas sin sentido. Los fanboys de bitcoin les encanta hablar de lo sólida que puede ser la cadena de bloques, pero de alguna manera las monedas siguen siendo timadas (ver aquí y aquí). No tenemos un método real para manejar la identidad.

8. Medición de la dificultad

Por supuesto, cuando se trata de programación, ¿existe alguna manera de medir la dificultad de un problema? Nadie lo sabe realmente. Sabemos que algunos problemas son fáciles de resolver, pero es completamente diferente para certificar uno que sea realmente difícil. NP-completitud es sólo una parte de un elaborado intento de codificar la complejidad de los algoritmos y análisis de datos. La teoría es útil, pero no puede ofrecer ninguna garantía. Es tentador decir que es difícil siquiera saber si un problema es difícil.

Este artículo está clasificado como: ,

Comentarios

Para poder comentar debe iniciar su sesión:

INGRESAR