[Solar-general] Programar no es solo hacer matematicas

[Pablo Manuel Rizzo]

Un artículo excelente, con muy buenas apreciaciones sobre  el desarrollo 
de software, no solo para programadores, también puede ser interesante 
para usuarios de software (o sea, para todos)


  Programar no es sólo hacer matemáticas
  <http://www.versioncero.com/articulo/581/programar-no-es-solo-hacer-matematicas>


*

Cada cierto tiempo se oyen voces críticas sobre la falta de rigor con la 
que trabajan la mayoría de los programadores. La falta de métodos 
formales de verificación y benchmarking produce muchos programas lentos 
y nada fiables. Pero ¿es la programación sólo una extensión de las 
matemáticas por otros medios?

*

por Sergio Montoro Ten 
<http://www.versioncero.com/editores/120/sergio-montoro-ten>, 30 enero 08

El pasado 9 de diciembre Robert Scoble tuvo la en apariencia inocente 
ocurrencia de preguntar en su blog porqué el software de gestión no 
puede ser igual de sexy que el de consumo 
<http://scobleizer.com/2007/12/09/why-enterprise-software-isnt-sexy/> 
Más de cien comentarios y acusaciones de que no entiende el software 
empresarial <http://blogs.zdnet.com/projectfailures/?p=524> como la de 
Michael Krigsman pusieron de manifiesto que con la pregunta Scoble tocó 
hueso.

En defensa de Robert salió el reputado Nicholas Carr, diciendo que es 
Krigsman quien no entiende nada de software 
<http://www.roughtype.com/archives/2007/12/michael_krigsma.php> y que 
creando una falsa dicotomía entre el software de consumo y el software 
de gestión lo único que se consigue es dar a los fabricante de éste 
último la excusa perfecta para seguir creando aplicaciones difíciles y 
desagradables.

El /flame war/ continuó con otra andanda de Krigsman 
<http://blogs.zdnet.com/projectfailures/?p=525> argumentando que Carr 
vive en un mundo de fantasía donde es posible emplear tiempo en dotar a 
las aplicaciones empresariales de pijadas totalmente innecesarias antes 
que atender a los requisitos funcionales básicos, las prioridades del 
negocio, el soporte de aplicaciones /legacy/ y las limitaciones 
tecnológicas de la infraestructura.

Pero el clímax de esta historia lo he alcanzado leyendo una referencia 
<http://weblogs.madrimasd.org/softwarelibre/archive/2008/01/22/82989.aspx> 
en el blog de Agustín González-Quel al artículo Where Are the Software 
Engineers of Tomorrow? 
<http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html> 
de Robert B.K. Dewar y Edmond Schonberg. En el cual los papás de ADA 
despotrican abiertamente contra el uso de Java para fines pedagógicos en 
las universidades, argumentando que el uso de Java es nocivo porque en 
vez de incentivar la reducción de la complejidad formal de procesos a un 
pequeño conjunto de operaciones primitivas, lo que Java fomenta es la 
resolución de problemas cual fontanero en ferretería tirando de todo lo 
que pilla en lo cajones a modo de frameworks y librerías que acaban 
convirtiendo al estudiante en un ignorante total del coste computacional 
de lo que está haciendo y de nociones imprescindibles para la 
programación como son los punteros.

Es verdad que entre los programadores más jóvenes hay una excesiva 
tendencia a abusar de las librerías. Cogen unos mágicos tags de Java y 
convierten una JSP que antaño era fácilmente legible y rápida en un 
amasijo de abreviaturas crípticas que tiran contra lentísimos servlets 
que hay que recompilar cada vez que quieres tocar algo. O se pillan 
Castor (o lo que sea) y unas DTDs y te dejan varios cientos de clases 
basura pregeneradas para leer un archivo XML de 10 líneas. Es decir, a 
veces matan moscas a cañonazos simplemente porque lo que tienen a mano 
para combatir insectos es un cañón.

Pero no es menos cierto que Java ha supuesto un gran salto cualitativo 
hacia adelante en la programación. Quien ha programado con punteros se 
acuerda de que en los 80 y 90 estábamos hartos de ellos y de las 
pérdidas de memoria que siempre acaban provocando. Y fue por eso que 
acabamos quitándolos en los lenguajes modernos. Hubo un tiempo en el que 
se cuestionaba la eficiencia y la viabilidad de usar recolectores de 
basura como el de la máquina virtual de Java, cuya utilidad y eficacia 
ahora ya nadie se atreve a poner en duda. Cuando no teníamos esas 
librerías ballena de Java, nos dedicábamos a escribirlas ¿Alguien se 
acuerda de ACE o de Rogue Wave para C++?

Por supuesto que hay muchas cosas muy mejorables en Java. Pero para mi 
Java ha sido un avance y no un retroceso.

Sobre si el software empresarial tiene que funcionar bien y no 
necesariamente ser bonito opino que: *nadie puede ser buen programador 
si ignora la reacción emocional que sus programas causan en los 
usuarios*. Escribimos programas para que alguien los use (o los sufra). 
Bueno, si, algunos escriben módulos de control para satélites, pero no 
me refiero a ese tipo de software, sino al típico software de gestión 
que debe necesariamente interactuar con humanos.

Los que reclaman más métodos formales y algebraicos y menos 
giliflauteces, deben entender que la programación no es simplemente una 
variante de las matemáticas, porque en el momento en que entra el juego 
el factor humano, la idoneidad del programa realizado deja de ser 
rigurosamente medible.

En un mundo utópico los programas son bellas estructuras matemáticas y 
el arte de programar consiste en emplear el intelecto para reducir la 
complejidad, abstraer y sintetizar.

Pero en el mundo real las cosas están pensadas para ser simples, porque 
si fueran complejas no podríamos manejarlas en el día a día. Las 
herramientas están pensadas para que le des al botón de crear 
formulario, pegues unos cuantos controles visuales dentro, escribas un 
poco de código para procesar los eventos y a las seis te vayas a tu casa 
a jugar con tus hijos sin tener ni la menor idea de lo que es un puntero.

Y los usuarios no sólo quieren que el software funcione, quieren que 
mole y que les divierta. Porque ¿quién dijo que el daño económico que 
causa un bug es peor que el daño psicológico que causa no poder poner la 
foto de tu perro como fondo de pantalla?

Por último, haré una afirmación aún más radical, *lo que diferencia a un 
programador bueno de uno sobresaliente no es su capacidad para buscar 
soluciones lógicas, sino su capacidad para buscar soluciones ilógicas*. 
Me explico: cuando tiene delante un problema que tiene pies y cabeza, 
cualquier ingeniero cualificado puede atacarlo aplicando alguna 
determinada metodología y, con el paso del tiempo, tarde o temprano lo 
acabará resolviendo. Pero, de vez en cuando, se presentan problemas 
totalmente desconcertantes y aparentemente sin sentido. Puede, por 
ejemplo, que el ordenador haya sido infectado por un virus sibilino. 
Entonces es posible perder horas persiguiendo un bug fantasma hasta que 
alguien llega y dice ¡hey si no es el programa lo que funciona mal 
entonces debe ser otra cosa! y con dicha hipótesis ad-hoc completamente 
infundada dispara un proceso de pensamiento lateral de búsqueda de 
soluciones en las que no se había pensado. Algo así como cuando alguien 
dijo ¡hey, y si deterioramos la calidad de la imagen? Y entonces se 
inventó JPEG (sin menosprecio de su fundamento en la teoría de 
información) o cuando Steve Jobs se pregunto ¡hey, porqué todas las 
letras de la pantalla tienen que ser de ancho fijo? Los programadores 
comunes pierden horas buscando una explicación aparente razonable a un 
problema que les trae muertos. Los programadores de élite huelen el 
problema y buscan un atajo, es casi como si diagnosticaran el error con 
la punta de su nariz antes que con el cerebro.

-- 
Pablo Manuel Rizzo
----------------------------------------------------------------------
Aunque supiera que el mundo se acabará mañana,
Igual plantaría mi manzano.   -- Martin Luther King --
----------------------------------------------------------------------


------------ próxima parte ------------
Un artículo excelente, con muy buenas apreciaciones sobre  el desarrollo de software, no solo para programadores, también puede ser interesante para usuarios de software (o sea, para todos)
http://www.versioncero.com/articulo/581/programar-no-es-solo-hacer-matematicas Programar no es sólo hacer matemáticas
Cada cierto tiempo se oyen voces críticas sobre la falta de rigor con la que trabajan la mayoría de los programadores. La falta de métodos formales de verificación y benchmarking produce muchos programas lentos y nada fiables. Pero ¿es la programación sólo una extensión de las matemáticas por otros medios?
por http://www.versioncero.com/editores/120/sergio-montoro-ten Sergio Montoro Ten
, 30 enero 08
El pasado 9 de diciembre Robert Scoble tuvo la en apariencia inocente ocurrencia de preguntar en su blog http://scobleizer.com/2007/12/09/why-enterprise-software-isnt-sexy/ porqué el software de gestión no puede ser igual de sexy que el de consumo
Más de cien comentarios y acusaciones de que http://blogs.zdnet.com/projectfailures/?p=524 no entiende el software empresarial
como la de Michael Krigsman pusieron de manifiesto que con la pregunta Scoble tocó hueso.
En defensa de Robert salió el reputado Nicholas Carr, diciendo que http://www.roughtype.com/archives/2007/12/michael_krigsma.php es Krigsman quien no entiende nada de software
y que creando una falsa dicotomía entre el software de consumo y el software de gestión lo único que se consigue es dar a los fabricante de éste último la excusa perfecta para seguir creando aplicaciones difíciles y desagradables.
El
flame war
continuó con otra http://blogs.zdnet.com/projectfailures/?p=525 andanda de Krigsman
argumentando que Carr vive en un mundo de fantasía donde es posible emplear tiempo en dotar a las aplicaciones empresariales de pijadas totalmente innecesarias antes que atender a los requisitos funcionales básicos, las prioridades del negocio, el soporte de aplicaciones
legacy
y las limitaciones tecnológicas de la infraestructura.
Pero el clímax de esta historia lo he alcanzado leyendo una http://weblogs.madrimasd.org/softwarelibre/archive/2008/01/22/82989.aspx referencia
en el blog de Agustín González-Quel al artículo http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html Where Are the Software Engineers of Tomorrow?
de Robert B.K. Dewar y Edmond Schonberg. En el cual los papás de
ADA
despotrican abiertamente contra el uso de Java para fines pedagógicos en las universidades, argumentando que el uso de Java es nocivo porque en vez de incentivar la reducción de la complejidad formal de procesos a un pequeño conjunto de operaciones primitivas, lo que Java fomenta es la resolución de problemas cual fontanero en ferretería tirando de todo lo que pilla en lo cajones a modo de frameworks y librerías que acaban convirtiendo al estudiante en un ignorante total del coste computacional de lo que está haciendo y de nociones imprescindibles para la programación como son los punteros.
Es verdad que entre los programadores más jóvenes hay una excesiva tendencia a abusar de las librerías. Cogen unos mágicos tags de Java y convierten una
JSP
que antaño era fácilmente legible y rápida en un amasijo de abreviaturas crípticas que tiran contra lentísimos servlets que hay que recompilar cada vez que quieres tocar algo. O se pillan Castor (o lo que sea) y unas
DTD
s y te dejan varios cientos de clases basura pregeneradas para leer un archivo
XML
de 10 líneas. Es decir, a veces matan moscas a cañonazos simplemente porque lo que tienen a mano para combatir insectos es un cañón.
Pero no es menos cierto que Java ha supuesto un gran salto cualitativo hacia adelante en la programación. Quien ha programado con punteros se acuerda de que en los 80 y 90 estábamos hartos de ellos y de las pérdidas de memoria que siempre acaban provocando. Y fue por eso que acabamos quitándolos en los lenguajes modernos. Hubo un tiempo en el que se cuestionaba la eficiencia y la viabilidad de usar recolectores de basura como el de la máquina virtual de Java, cuya utilidad y eficacia ahora ya nadie se atreve a poner en duda. Cuando no teníamos esas librerías ballena de Java, nos dedicábamos a escribirlas ¿Alguien se acuerda de
ACE
o de Rogue Wave para C++?
Por supuesto que hay muchas cosas muy mejorables en Java. Pero para mi Java ha sido un avance y no un retroceso.
Sobre si el software empresarial tiene que funcionar bien y no necesariamente ser bonito opino que:
nadie puede ser buen programador si ignora la reacción emocional que sus programas causan en los usuarios
. Escribimos programas para que alguien los use (o los sufra). Bueno, si, algunos escriben módulos de control para satélites, pero no me refiero a ese tipo de software, sino al típico software de gestión que debe necesariamente interactuar con humanos.
Los que reclaman más métodos formales y algebraicos y menos giliflauteces, deben entender que la programación no es simplemente una variante de las matemáticas, porque en el momento en que entra el juego el factor humano, la idoneidad del programa realizado deja de ser rigurosamente medible.
En un mundo utópico los programas son bellas estructuras matemáticas y el arte de programar consiste en emplear el intelecto para reducir la complejidad, abstraer y sintetizar.
Pero en el mundo real las cosas están pensadas para ser simples, porque si fueran complejas no podríamos manejarlas en el día a día. Las herramientas están pensadas para que le des al botón de crear formulario, pegues unos cuantos controles visuales dentro, escribas un poco de código para procesar los eventos y a las seis te vayas a tu casa a jugar con tus hijos sin tener ni la menor idea de lo que es un puntero.
Y los usuarios no sólo quieren que el software funcione, quieren que mole y que les divierta. Porque ¿quién dijo que el daño económico que causa un bug es peor que el daño psicológico que causa no poder poner la foto de tu perro como fondo de pantalla?
Por último, haré una afirmación aún más radical,
lo que diferencia a un programador bueno de uno sobresaliente no es su capacidad para buscar soluciones lógicas, sino su capacidad para buscar soluciones ilógicas
. Me explico: cuando tiene delante un problema que tiene pies y cabeza, cualquier ingeniero cualificado puede atacarlo aplicando alguna determinada metodología y, con el paso del tiempo, tarde o temprano lo acabará resolviendo. Pero, de vez en cuando, se presentan problemas totalmente desconcertantes y aparentemente sin sentido. Puede, por ejemplo, que el ordenador haya sido infectado por un virus sibilino. Entonces es posible perder horas persiguiendo un bug fantasma hasta que alguien llega y dice ¡hey si no es el programa lo que funciona mal entonces debe ser otra cosa! y con dicha hipótesis ad-hoc completamente infundada dispara un proceso de pensamiento lateral de búsqueda de soluciones en las que no se había pensado. Algo así como cuando alguien dijo ¡hey, y si deterioramos la calidad de la imagen? Y entonces se inventó
JPEG
(sin menosprecio de su fundamento en la teoría de información) o cuando Steve Jobs se pregunto ¡hey, porqué todas las letras de la pantalla tienen que ser de ancho fijo? Los programadores comunes pierden horas buscando una explicación aparente razonable a un problema que les trae muertos. Los programadores de élite huelen el problema y buscan un atajo, es casi como si diagnosticaran el error con la punta de su nariz antes que con el cerebro.
-- Pablo Manuel Rizzo ---------------------------------------------------------------------- Aunque supiera que el mundo se acabará mañana, Igual plantaría mi manzano. -- Martin Luther King -- ----------------------------------------------------------------------