[Solar-general] Programar no es solo hacer matematicas

Mar Abr 8 20:37:43 CEST 2008

En la facultad, tanto la UTN como la UBA, al lado mio, tengos personas que
son unos monstruos programando en cualquier cosa. Tienen sueldos de $2000 en
blanco en empresas de software de primera linea; pero en analisis y algebra
les tiemblan las piernas y la mayoria termino recursando.
Las matemáticas te habre mucho la cabeza pero la creatividad y un buen
orden  a la hora de programar te ahorrra mucho, sino te agrada la
matemática.

Un fuerte abrazo.

El día 8/04/08, Pablo Manuel Rizzo <info en pablorizzo.com> escribió:
>
> 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-matematicasProgramar 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.aspxreferencia
> en el blog de Agustín González-Quel al artículo
> http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.htmlWhere 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 --
> ----------------------------------------------------------------------
>
> _______________________________________________
> Solar-general mailing list
> Solar-general en lists.ourproject.org
> https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-general
>

-- 
Hernán López Pardo
http://otrodiaparaser.blogspot.com
------------ próxima parte ------------
Las matemáticas te habre mucho la cabeza pero la creatividad y un buen orden  a la hora de programar te ahorrra mucho, sino te agrada la matemática.
Un fuerte abrazo.
El día 8/04/08,
Pablo Manuel Rizzo
< mailto:info en pablorizzo.com info en pablorizzo.com
> escribió:
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 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 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/ 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 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 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 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 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 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 -- ----------------------------------------------------------------------
_______________________________________________
Solar-general mailing list
mailto:Solar-general en lists.ourproject.org Solar-general en lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-general https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-general
--
Hernán López Pardo
http://otrodiaparaser.blogspot.com http://otrodiaparaser.blogspot.com