Barrapunto

La codificación. En mi corta carrera profesional no me he topado con ningún proyecto que no haya tenido ningún problema con las codificaciones. Especialmente grave cuando en una base de datos han mezclado datos con distintas codificaciones.

En el caso de una aplicación web, tienes que lidiar con la codificación de la base de datos, codificación de fuentes (si no están bien programados), codificación de archivos de datos, codificación de servidor web o de aplicaciones, y codificación del cliente.

Son un coñazo.

El problema número 0 de la informática son los gilipollas con corbata y cara sonriente...

La verdad es que leyendo el artículo en más profundidad, creo que el que lo escribe no es para nada un experto, o al menos a mí (que tampoco lo soy) no me gusta mucho su metodología:

Problema N2: Productividad en el desarrollo de interfaces web.
Cuando ya teníamos VisualBASIC 4.0 con el cual te picabas una aplicación operativa en 3 días, volvimos a usar diseño con lenguaje marcas que sólo funcionaba bien si lo editabas a pelo con UltraEdit, por no hablar de que el JavaScript ni siquiera tiene un debugger decente.

Para empezar, no me gusta la filosofía de "picarte" una aplicación en 3 días. Por esa filosofía, y la del Visual Basic en sí, te encuentras las barbaridades que te encuentras por ahí.

¿El lenguaje de marcas sólo funciona si te lo editas con el Ultraedit? También valdrán otros, ¿no? ¿O te refieres a no poder dibujar directamente las ventanitas?

Problema N5: Integridad referencial en los borrados.
¿Cómo borrar algo de una base de datos si infringir las reglas de integridad referencial? En realidad, la solución es simple ¡nunca borrar nada! sino en cambio dar bajas lógicas. Pero entonces ¿porqué no tenemos un procedimiento predefinido para las bajas lógicas?

Porque el borrado lógico no te va a solucionar los problemas de integridad referencial. El día que los gestores implementen el borrado lógico, y le hagan pasar por las mismas restricciones que el físico, su manejo será igual de complejo. Lo único que cambia es la posibilidad de recuperación.

Esto me hace pensar que este tipo, para evitar comprobaciones de integridad, se contenta con poner el campo de borrado a 0. Para eso no uses claves externas.

Problema N6: Empotrar SQL y XML dentro del lenguaje.
¿Porqué seguimos usando APIs como JDBC? Acaso es tan difícil integrar el acceso a base de datos dentro de la sintaxis de un dialecto de un lenguaje multipropósito como Java.

Las clases de acceso a bases de datos son estándar, ya están incluidas en java. Lo que tú tienes que añadir es la biblioteca que implementa el acceso. Obviamente los desarrolladores de los javas no pueden implementar todos los accesos a cualquier gestor de bases de datos, porque sería un trabajo titánico, y porque no creo que muchas estén dispuestas.

También tendría cosas que objetar al resto de párrafos, pero estos son los que veo más claros, y tampoco voy a hacer un comentario más largo que el de la Manesa.

Problema 11: El efecto barrapunto
Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Me quedo sin leer el artículo (por ahora)

Problema N1: Concepción colaborativa distribuida.
El nóbel de química se lo llevará quien invente una metodología sólida para concebir niños igual que funcionan las redes P2P, dividiendo el trabajo en tareas de no más de 1 mes que puedan ser ejecutadas redundantemente por varias madres geográficamente dispersas. Por ahora disponemos de herramientas de inseminacion artificial, fecundacion invitro,madres de alquiler, incubadoras, clonacion,celulas madre, etc. Pero los mejores niños (y casi los únicos que sobreviven bien) siguen siendo concebidos por un grupo muy reducido y cohesionado (una unica madre).

Lo de la multimoneda, leaks de memoria, bajas logicas integradas en bbdd , scriptings cutres,..
la idea que me queda es que la solucion a la mediocridad del desarrollo hay que buscarla en la arquitectura y en las herramientas cuando la solucion de todos esos problemas esta simplemente en la competencia del desarrollador.

el lameness filter

Un algoritmo funciona y ya!! el programador se va tan pancho a hacer otras labores, olvida optimizar y la respuesta es: compre mejor CPU y mas memoria.

Las generaciones de programadores pasadas que trabajaban con DOS y tenían esa limitante de los 640Kb o menos porque el DOS + Antivirus residente (TSR) dejaban menos de 500Kb haciamos maravillas optimizando cada registro, cada uso de variable y los programas eran de poco consumo y rápidos. Hoy veo programadores novatos que hacen programas devoradores de recursos e implementan herejías como:

1. Control de ciclos con variables tipo float o double (deben usar variables tipo int).

2. Uso del char en algunas variables (use fanáticamente int porque son nativas del procesador).

3. El manejo de estructuras de datos como arboles, listas, pilas, etc.. con las APIs mas abstractas y estratosféricas que encuentran con la pobre excusa de que así abstraen el problema cuando en realidad esconden el "ser tontos ignorantes que les da miedo usar directamente las estructuras". Obteniendo código muy lento.

4. Hiperabuso de funciones, he visto funciones que se usan solo una vez con dos líneas de código, ¿por que no la colocaron directamente en el grueso del código?

5. Funciones recursivas: el pecado original de la programación... ¿no saben que este tipo de programación consume demasiados recursos y es lenta?

6. Usar el lenguaje de moda o el que solo aprendieron en la Universidad sin importar que es mas lento que funcionario público.

7. La falsa autocomplacencia de "si señor cliente, el programa es muy lento pero es muy seguro, es poderoso, es flexible, es escalable, ..." y con las palabritas: "poderoso", "flexible", "escalable" disculpan un código mas lento que placa tectónica en movimiento.... y lo peor es que lo "poderoso", "flexible" y "escalable" jamás lo volverán a usar.

8. El "safe code" significa que "un hilo estará supervisando que el estúpido programador no haya cometido idioteces en manejo de punteros y manejo de memoria que bloqueen la aplicación avisándole donde cometió errores, pero este hilo y esa forma de protección traga recursos y hace el programa mas lento que la entrega de ayudas humanitarias en Africa", claro que suena mas guay "safe code".

9. No consultar practicas de optimización o mejorar el código en velocidad.

Que alguien me atice con una viga de hormigón si esto tiene sentido:

El uso de HTML y JavaScript supuso un retroceso de 10 años en el estado del arte de las herramientas de desarrollo.

No se, pero a mi me huele al típico programador que sólo sabe usar Visual Basic y se moriría antes de usar algo sin una interfaz gráfica. ¿"El estado del arte"? Sobre todo, me redujo a un estado de confusión lo siguiente:

Me refiero a un [tipo de datos] que te permita sumar 3 con 5$ y te dé el resultado correcto en función de un tipo de cambio dado externamente.

¿Tal vez será porque 3 euros y 5 dólares, no dan 8 euros?¿Nadie le enseñó que existen unas cosas llamadas funciones, que son implementadas por un programador, y que pueden hacer precisamente eso que tanto reclama? Por lo demás, me parecen las típicas quejas de un programador que defiende modelos de desarrollo que se han probado que no funcionan.

El problema del desarrollo, es que aqui a cualquier cosa se llama desarrollo. España no desarrolla, para que quede claro, ni Sistemas Operativos ni aplicaciones poderosas ni nada serio, tan sólo vende humo. En cambio hace chapuzas muy muy rápidas (3 días a 1 semana) en lenguajes de muy alto nivel, que fallan más que una escopeta de feria e intenta venderlos como productos serios. En España se habla de Proyectos (algo volátil y no tangible) en vez de Productos (algo físico y tangible) como en América, pero si intentan vender como productos finales, al estilo de Microsoft Word o Windows. La eficiencia es algo importantísimo, es lo mismo que si comparamos la calidad de una peli en el Cine y el screener. Hay que optimizar recursos, os guste o no, otra cosa es que sea divertido. Pero bueno, seguid pensando asi, que mientras haya gente que no piensen igual, se podrán forrar.

En el kernel Linux, efectivamente, hay aportaciones de mucha gente, pero date cuenta de lo que pasó cuando se comprobó que "Linus Torvalds no es escalable": muchos parches (incluso correctamente escritos) se perdían incluso si se enviaban repetidamente. Esto llevó a la aparición de los "lugartenientes", Bitkeeper y git. Y el problema sigue sin estar resuelto. Yo opino que el problema 1 no es un problema de programación, sino de descripción: para poder "tareas de no más de 1 hora que puedan ser ejecutadas redundantemente por varios programadores geográficamente dispersos", como se pide en el artículo, es imprescindible tener una declaración sin ambigüedades de dichas tareas. No necesariamente de su implementación, pero sí de lo que se espera de la misma. Y probablemente hagan falta aún más cosas.

Cambiando de problema, no veo sentido al problema 3: no es un problema específico del modelo relacional (el modelo jerárquico o el modelo en red tienen los mismos problemas) y en la mayoría de SGBDs modernos hay soluciones parciales (como los trigger) bastante eficaces que no requieren estar haciendo el trabajo "a mano".

No sé que pensar del problema 4: ahora va a resultar que el sistema debe conocer todas las monedas del mundo. No, hijo, no. Las monedas que se gestionen en la base de datos estarán anotadas en algún sitio, con su cotización respecto a una moneda de referencia, y basta. ¿Cuántas aplicaciones requieren sumar euros y dólares y sacar el resultado en rublos? Que yo conozca, ninguna: lo que se hace es convertir las dos cantidades a rublos y se suman como tales, que para algo tenemos el punto flotante y/o la precisión arbitraria.

El problema 5, como ya se ha indicado, está resuelto con la reglas de integridad en cascada. Estoy de acuerdo con la conveniencia de tener mecanismos de baja, pero la variabilidad de este mismo concepto según necesidades (sí, se pueden considerar diferentes tipos de baja) dificulta sobremanera una solución general.

El problema 6 adolece de escasez de miras: ¿qué hacemos mañana cuando salga una alternativa a SQL o una revisión de XML? Es muy seductora la tentación de añadir características nuevas al lenguaje, pero esto hay que hacerlo como se ha hecho siempre, con librerías externas. Porque ¿qué versión de SQL metemos? ¿La de la norma? Ya podemos olvidarnos de los desarrolladores que quieren aprovechar (con razón o sin ella) características específicas de un SGBD (Oracle, Mysql, PostgreSQL, Firebird... todos tienen sus idiosincrasias).

De nuevo, el problema 8 busca generalizar algo que es excesivamente específico: ¿Manipular ficheros de texto? Yo pensaba que teníamos cosas como sed, awk o Perl [wikipedia.org], por citar tres opciones más o menos emparentadas. ¿Qué quiere decir "cambiar cosas en las bases de datos"? No sé si se refiere a actualizaciones en masa de registros, modificar las tablas, o qué, pero me da la impresión de que quiere un Haz Lo Que Quiero (y no lo que digo) [wikipedia.org].

Problema 9: si el problema son los modelos, no sirve demonizar a toda la documentación. Quizá al autor del artículo UML no le explica nada, o quizá es que no le han dado UML bien hecho. O BON o algún otro lenguaje/sistema de modelado. Una de las razones por las que los lenguajes de modelado no suelen ser capaces de representar bien la realidad es porque suelen tener reglas de representación, y la realidad no. Como dice la cita, "la realidad es más increíble que la ficción, porque la ficción tiene que tener sen