http://www.historiasdelaciencia.com/?p=36
Hilbert, además, tenía salidas geniales. Un día le invitaron a dar una conferencia sobre el tema que él quisiera. La conferencia creó una gran expectación ya que el tema elegido fue : “La prueba del último teorema de Fermat”. Llegó el día y dio la conferencia. La exposición fue muy brillante pero no tuvo nada que ver con el último teorema de Fermat. Cuando le preguntaron el porqué del título contestó: “Oh, el título era solamente para el caso de que el avión se estrellara”.
jueves, marzo 27, 2008
Inversión en ejecución concurrente Microsoft e Intel
Atención a la noticia...
http://www.infoq.com/news/2008/03/ParallelComputing
microsoft e intel invertirán 20millones de dólares para pensar como
hacer cosas que funcionen bien con muchos micropocesadores
1.- Ya hay una cosa fantástica y no han invertido tanto dinero Erlang
2.- Esto explica como escalan sus sistemas operativos (ver entrada anterior), de algún sitio
tienen que sacar el dinero
3.- Hablan de que el objetivo es chips con 1000 núcleos. Como
escarpias tengo los pelos de pensar lo que cuesta una licencia de
windows para ese chip tal y como escalan (nuevamente, ver entrada anterior)
Hace un par de días, el interesado era Java.
Vamos, que está de moda hablar de esto. Erlang lleva hablando del tema
muchos años.
curioso
pos ala, a comprar windows para 4 y 8 procesadores que necesitan
dinerito para invertir (en algo que ya existe, es libre y open source)
http://www.infoq.com/news/2008
microsoft e intel invertirán 20millones de dólares para pensar como
hacer cosas que funcionen bien con muchos micropocesadores
1.- Ya hay una cosa fantástica y no han invertido tanto dinero Erlang
2.- Esto explica como escalan sus sistemas operativos (ver entrada anterior), de algún sitio
tienen que sacar el dinero
3.- Hablan de que el objetivo es chips con 1000 núcleos. Como
escarpias tengo los pelos de pensar lo que cuesta una licencia de
windows para ese chip tal y como escalan (nuevamente, ver entrada anterior)
Hace un par de días, el interesado era Java.
Vamos, que está de moda hablar de esto. Erlang lleva hablando del tema
muchos años.
curioso
pos ala, a comprar windows para 4 y 8 procesadores que necesitan
dinerito para invertir (en algo que ya existe, es libre y open source)
Informática paralela
Ayer pude constatar algo que era más que probable, aunque no me guste
nada reconocerlo
No sé si te comenté algo de que la ley de Moore está agotada o cambiada.
Los procesadores ya no son más rápidos, ahora incorporan más núcleos
Hay documentación y gráficas por todos lados
¿Están los sistemas operativos, los programas y los lenguajes de
programación preparados para aprovechar sistemas con muchos
procesadores?
Hace poco Java se apuntó a esa corriente. Erlang es la mejor situada.
Haskell también está muy bien, etc...
Resulta que lo que mejor escala en el paralelismo NO ES ERLANG, ni
haskell, ni ada, ni la próxima versión de Java, ni Scala...
ES... microsoft
Cuando hay que reconocerlo se reconoce y punto
Para algo tenía que servir tantos cerebros concretrados en una empresa
La labor de ingeniería paralela realizada por los técnicos de
microsoft es aplastante y muy fácil de demostrar. Voy a ello...
Recordatorio...
Ahora que los procesadores no suben velocidad y suben en núcleos, que
ya no se pueden comprar mononúcleos y dentro de poco ni con dos
núcleos, es el momento y los sistemas operativos de microsoft están
ahí
Demostración...
Te compras una máquina con uno o dos procesadores, y le puedes poner
un XP Home o equivalente Vista. Precio... 120€
Pero si te la compras con tres o cuatro procesadores... Server básico.
Precio 1000€
Y si te hacen la faena de ponerte un par de procesadores multinúcleo y
el sistema operativo suma más de cuatro y menos de nueve... 3000€
Conclusión
Queda demostrado que en la informática paraLELAs y paraLELOs, lo que
mejor escala son lo sistemas operativos de mocosoft
Quiero pensar que mocosoft cambiará su estrategia a la VISTA de la
moda multicores, pero seguro que ellos también se beneficiarán del
cambio a costa de los paraLELOs y paraLELAs que no quieren poner linux
en casa
¿y GNU/LiNUX, que opina de todo esto?
Que yo sepan no escala bien, no creo que te cueste diferente para 2
que para 8 o 16 procesadores
nada reconocerlo
No sé si te comenté algo de que la ley de Moore está agotada o cambiada.
Los procesadores ya no son más rápidos, ahora incorporan más núcleos
Hay documentación y gráficas por todos lados
¿Están los sistemas operativos, los programas y los lenguajes de
programación preparados para aprovechar sistemas con muchos
procesadores?
Hace poco Java se apuntó a esa corriente. Erlang es la mejor situada.
Haskell también está muy bien, etc...
Resulta que lo que mejor escala en el paralelismo NO ES ERLANG, ni
haskell, ni ada, ni la próxima versión de Java, ni Scala...
ES... microsoft
Cuando hay que reconocerlo se reconoce y punto
Para algo tenía que servir tantos cerebros concretrados en una empresa
La labor de ingeniería paralela realizada por los técnicos de
microsoft es aplastante y muy fácil de demostrar. Voy a ello...
Recordatorio...
Ahora que los procesadores no suben velocidad y suben en núcleos, que
ya no se pueden comprar mononúcleos y dentro de poco ni con dos
núcleos, es el momento y los sistemas operativos de microsoft están
ahí
Demostración...
Te compras una máquina con uno o dos procesadores, y le puedes poner
un XP Home o equivalente Vista. Precio... 120€
Pero si te la compras con tres o cuatro procesadores... Server básico.
Precio 1000€
Y si te hacen la faena de ponerte un par de procesadores multinúcleo y
el sistema operativo suma más de cuatro y menos de nueve... 3000€
Conclusión
Queda demostrado que en la informática paraLELAs y paraLELOs, lo que
mejor escala son lo sistemas operativos de mocosoft
Quiero pensar que mocosoft cambiará su estrategia a la VISTA de la
moda multicores, pero seguro que ellos también se beneficiarán del
cambio a costa de los paraLELOs y paraLELAs que no quieren poner linux
en casa
¿y GNU/LiNUX, que opina de todo esto?
Que yo sepan no escala bien, no creo que te cueste diferente para 2
que para 8 o 16 procesadores
miércoles, marzo 26, 2008
Trabajando con sistemas críticos
Antes de empezar una aclaración.
NO PRETENDO DEMOSTRAR NADA EN ESTE CORREO.
Es frecuente que mucha gente utilice símiles para demostrar, pero eso es un error lógico total.
Los símiles sólo sirven para explicar.
Dicho esto...
Recordarás que el challenger explotó con 7 tripulantes a bordo.
Es más, había una importante expectación porque era la primera vez que había un tripulante civil (una profesora de colegio)
El tripulante civil, era claralmente una operación de marketing.
En un momento delicado, se pretendía demostrar que el transbordador era un gran invento.
Un camión de carga espacial, seguro y reutilizable.
El coste del trasbordador y los lanzamientos, eran bestiales
¿Estaba cumpliendo el carísimo transbordador la misión para la que fue desarrollado a un elevadísimo coste?
No.
Pero si se lanzaba con un civil, todo como si fuera una rutina y sin incidentes, podría parecer que casi.
Pero había algunos problemas.
Los ingenieros detectaron que había unas juntas tóricas (con forma de rosquilla) que tenían problemas.
Es más, sabían que tenían problemas gravísimos en condiciones de baja temperatura. No funcionaban como estaba previsto y las cosecuencias podían ser muy graves. (Para algo estarían estas juntas)
Un par de días antes del lanzamiento, un ingeniero jefe dijo que no de podría realizar.
La razón, es que tendrían una temperatura de un par de grados, y con ese frío, las juntas tóricas de los cohetes de combustible sólido...
Eso suponía para los gestores un revés importante.
Los gestores tenían la enorme responsabilidad de dar un empujon a la credibilidad y viabilidad de transbordador.
Pero los gestores no entendían nada de los argumentos de los ingenieros.
Así que cogieron al ingeniero jefe y lo presionaron para que firmara la aprobación para el lanzamiento.
Los gestores razonaron como sigue...
1.- Es importante realizar el lanzamiento según lo previsto
2.- Las juntas tóricas han tenido problemas en el pasado y todo fue bien. Lo que demuestra, que el sistema puede funcionar con este defecto en las juntas tóricas
3.- Los ingenieros son cobardes y excesivamente precavidos sin considerar en ningún momento otras cuestiones relevantes
El ingeniero firmó, por las presiones y considerando los argumentos de los gestores, por creer que quizá exageraba. El transbordador explotó matando a 7 personas
ERRORES EN RAZONAMIENTO DE LOS GESTORES
2.- Es un error lógico garrafal, deducir que algo no es importante porque no ha provocado un fallo en el pasado.
Eso no es científico, es un fallo muy grave que debe evitarse
Por dios, que nadie olvide que un defecto generá un fallo más tarde o temprano si le das las oportunidades suficientes. Es obvio
3.- Si no confías en la opinión de los ingenieros, no montes el sistema.
No olvidemos nunca que no sólo es importante la probablidad del fallo. Hay que valorar la unión de la probabilidad del fallo con el perjuicio del mismo
Otro símil clásico... Una pistola con 1 bala en un tambor de 6... tienes una probabilidad de pegarte un tiro en la ruleta rusa de 1/6. Es pequeña, ¿pero alguien en su sano juicio asumiría el riesgo?
No, porque no sólo es importante la probabilidad de que ocurra
Y ya sólo como curiosidad
En la comisión de investigación, detectaron más fallos importantes, empezando por dificultades burocráticas que incomunicaban ingenieros y mecánicos con gestores.
Fue difícil descubrir la causa, aunque había ingenieros muy afectados por lo ocurrido (ellos lo sabían)
Sólo se pudo indicar esta causa porque uno de los que formaban la comisión, era cabezota e intocable. Richard Feynman, premio de física en el 65 y uno de los mejores profesores de la historia
Dijo que si no se incluían sus observaciones, aunque fuera en un anexo, no firmaría y lo denunciaría en los medios de comunicación
CONCLUSIÓN...
¿APRENDIERON LA LECCIÓN?
SÍIIII
Ya sabes que hace poco, explotó en la reentrada otro transbordador
Este era un transbordador "reciclado".
Ya había terminado su vida útil según los ingenieros, pero eso es lo de menos.
Lo importante, es que explotó porque en el lanzamiento, el desprendimiento de un aislante blando y ligero del tanque central, provocó una avería en la nave.
TODOS SABÍAN QUE ERA FRECUENTE DESPRENDIMIENTOS DE ESTOS MATERIALES DURANTE EL LANZAMIENTO.
Y algunos pensaron... El que suceda desde el principio y con frecuencia, demuestra que no es peligroso. Nunca pasa nada.
¿Esto demuestra que yo no soy paranoico y pefeccionista?
NOOOOO
Pero espero que se entienda mejor mi punto de vista
Me considero no pefeccionista y podría detallar cientos de razones que lo avalan (de forma concreta en nuestro sistema).
Te sorprendería la cantidad de tornillos que están flojos en el sistema
El que se haya diseñado un sistema resistente a fallos, con ajuste continuo, no significa que pueda resistir cualquier cosa en todas condiciones.
El que defectos y fallos no provoquen incidentes graves, no demuestra que no sean importantes
¿De que sirve un sistema predictivo y dinámico si ignoramos sus advertencias y no realizamos los ajustes?
Antes de acusar de perfeccionismo hagamos un ejercicio...
¿Qué riesgos estáis dispuestos a asumir?
Valorad el coste de la reducción de esos riesgos con dichas situaciones
¿Cómo podéis acusarme por un lado de perfeccionista y por otro protestar (en muchas ocasiones) de que el sistema ha fallado por principio?
No es raro recibir llamadas que nos dicen... "el sistema ha funcionado mal Y ME HE PILLADO".
Luego cuesta horas, muchas horas, analizar lo sucedido y lo mismo para explicarlo. En el 99% de los casos, se demuestra que no ha sido un fallo del sistema.
No entiendo como en ocasiones culpamos al sistema por principio, para empezar, y por otro lado decimos que se trata de ser perfeccionista.
Es contradictorio
Pedazo reflexión (por el tamaño)
Si quieres más información del tema del challenger, hay un libro llamado "que le importa lo que digan los demás" que tiene el informe de Richard Feynman
(Yo aprendí muchas cosas de este informe)
saludos
Ejecución paralela en Java 7
Para Java 7, que está previsto que venga en el 2009
Comentarios...
Ya no son sólo los de la programación declarativa, especialmente Erlang los que dicen que hay que prestar atención a la ejecución paralela
Dan los mismos argumentos. La ley de Moore ha cambiado. Ahora los procesadores no son más rápidos, ahora incluyen más núcleos
Hablan de dividir los problemas recursivamente
De forma que los problemas más pequeños se puedan ejecutar en paralelo FORK
Y posteriormente combinar los resultados JOIN
Esta técnica la llaman FORK/JOIN
Para evitar la carga de la creación, destrucción y conmutación de threads, utilizan una piscina de threads donde distribuyen los trabajos.
El número de threads disponibles se ajustará al número de núcleos (más o menos)
Opinión subjetiva sin tener suficientes datos...
La idea parece chula y sencilla de utilizar, pero no confío que sea sencillo
Yo creo que este sistema, permitirá que algunos problemas se resuelvan de forma fácil y elegante.
Pero la mayoría de problemas, no serán triviales.
Es una mejora importante, quizá imprescindible, pero creo que utilizarla será un poco compleja y dificultará el diseño
Comprando con otros...
Erlang, está pensado desde el inicio para tabajar no sólo de forma concurrente, también de forma distribuida.
En erlang es natural tener muchos procesos (baratos) y además es muy fácil distribuir el programa. No es necesario pensar de otra forma
Scala
Probablemente Scala pueda aprovecharse mucho mejor de esta técnica que Java.
Si en Scala reduces la programación imperativa al mínimo y utilizas el modelo de actores (coordinación del paralelismo con paso de mensajes), el punto de partida es mucho mejor
Haskell
Como lenguaje declarativo, parte con una ventaja clara respecto a Java
pos eso
miércoles, marzo 19, 2008
El primer vuelo del Ariane-5
http://www.historiasdelaciencia.com/?p=249
El artículo de hoy está inspirado en uno que ya publicó Dan en su blog centpeus (blog en catalán) y del que ya os he hablado alguna vez, así que el mérito es enteramente de él. Yo, tan sólo, he retocado y añadido detalles.
La primera nave del Programa Mariner que llegó a Venus, el Mariner II, fue lanzada el 27 de agosto de 1962. Y si os preguntáis qué sucedió con el Mariner I os diré que cayó al mar inmediatamente después de despegar porque a alguien se le olvidó introducir un signo menos en el ordenador (dicen que fue un error al leerlo de la fórmula hecha a mano).
La NASA ha tenido bastantes fiascos posteriores debidos a fallos que podríamos calificar de “fácilmente evitables”. Uno de los mayores ridículos fue el perder una sonda que impactó contra la superficie de Marte porque se hicieron un lío entre una estación que expresaba las distancias en kilómetros y otra que lo hacía en millas.
Pero la ESA, la Agencia Espacial Europea, tampoco ha podido evitar unirse al espectáculo y el mayor y más sonado fue en el vuelo inicial del cohete Ariane-5, que estalló 39 segundos después del lanzamiento. Fue un golpe duro porque era el primer lanzamiento de la nueva generación de cohetes europeos, más grandes, más potentes y con más capacidad que los predecesores Ariane-4. El motivo del desastre fue ridículo: una de las unidades de 64 bits que controlaba la trayectoria hizo unos cálculos y emitió un número que envió a una unidad de 16 bits. Esta no pudo procesar el resultado porque el número era demasiado grande y simplemente ¡no cabía en 16 bits! Por lo tanto, hizo lo que hacen los ordenadores: dio un mensaje de error y se desconectó.
Había un sistema de emergencia que se puso en funcionamiento inmediatamente pero el software era idéntico al que había fallado, de forma que el error se repitió exactamente igual. La unidad también se desconectó, el cohete quedó sin control y adiós.
El problema con estas unidades fue que, en realidad aprovechaban el sistema operativo de los cohetes Ariane-4. Después de todo, aquel sistema había funcionado muy bien. Y si algo funciona correctamente lo mejor es no tocarlo (bien, esto es cierto a no ser que seas una multinacional de la informática que, por mantener el negocio, necesites vender cada 4 años un nuevo sistema operativo).
Pero, aun cuando el sistema iba muy bien por el Ariane-4, algunas cosas no servían para el Ariane-5 y esta era una de ellas.
La unidad que falló calculaba los desplazamientos horizontales del cohete y los técnicos no se debían preocupar por si daba un valor demasiado alto pues el Ariane-4 nunca se desplazaba tan deprisa. El problema era que el Ariane-5 era mucho más rápido y potente y sí que lo hacía. De forma que cuando el sistema detectó aquel desplazamiento lateral, no pudo calcularlo porque la realidad iba más allá de lo que en el diseño habían previsto (correctamente) que podía hacer un Ariane-4. En fin, que hizo que el ordenador central perdiera los datos de trayectoria del cohete y el desastre fue inevitable. La trayectoria no se pudo corregir de ninguna forma y al final empezó a ir demasiado “de lado”. Debido a esa inclinación (más de 20º), los propulsores se separaron de la etapa principal por efecto de las fuerzas aerodinámicas y se disparó el mecanismo de autodestrucción.
Y lo más irónico es que aquel sistema ya no hacía falta. La unidad que falló estaba diseñada por calcular los desplazamientos horizontales en los primeros segundos del lanzamiento, antes de que se estableciera el “modo de vuelo”, como si dijéramos cuando el cohete ya ha arrancado del todo.
Esto requería 40 segundos por los Ariane-4, pero sólo 3 segundos para el Ariane-5. De forma que el desastre pasó porque falló un procesador que, en realidad, ¡ya no servía para nada! Un curioso camino que empezó en un error al asumir que no hacía falta modificar el diseño de un programa informático y acabó en un fracaso de 7 mil millones de Euros.
Ya sabemos que no hay ningún sistema está 100% libre de errores pero, a veces, se pone de manifiesto de maneras bien espectaculares.
Moraleja: el “si funciona, no lo toques” no siempre es aplicable.
Fuentes:
“Astronomía”, Patrick Moore
http://centpeus.blogspot.com/2006/10/un-nmero-massa-gran.html
http://www.mononeurona.org/index.php?idnew=323
http://www.upv.es/satelite/trabajos/pract_9/kike/paginas/accid.htm
El Accidente del Columbia
http://es.geocities.com/fjcasadop/
El 1 de febrero de 2003, el telediario del mediodía nos sorprendía a muchos de nosotros con las imágenes, grabadas por un videoaficionado, del Columbia desintegrándose sobre el cielo de Texas, durante la maniobra de reentrada de la misión STS-107 del transbordador espacial norteamericano. El Columbia, el más veterano de la flota de transbordadores, contabilizaba con ésta un total de 28 misiones al espacio.
Casi de inmediato empezaron a surgir las primeras hipótesis sobre las causas del accidente, mostrándose unas imágenes tomadas durante el despegue de esta misión, en las que se observaba cómo un trozo del aislante que recubre gran el depósito central de propulsante se desprendía del mismo impactando sobre el ala izquierda del Columbia. Se planteaba que éste podía haber sido el origen del fallo, aunque al mismo tiempo se argumentaba que acontecimientos similares habían ocurrido en otros despegues sin que hubieran tenido el más mínimo efecto en la integridad del transbordador. De hecho, los técnicos de tierra habían observado el impacto y, tras varios días de debate, la conclusión oficial de la NASA era que no existía riesgo alguno, habiéndose proseguido la misión con normalidad.
Luego, como suele ocurrir, el accidente dejó de ser noticia, y la investigación sobre sus causas cayó en el olvido para el público en general.
Sin embargo, la investigación del accidente ha avanzado sin pausa en este tiempo, publicándose sus conclusiones el pasado mes de septiembre. El estudio ha sido exhaustivo: se han analizado uno a uno con gran detenimiento todos los datos (y son muchos) registrados por todos los sistemas de la nave a lo largo de la misión; se han observado una y otra vez los videos del despegue y las imágenes radar obtenidas durante la parte orbital de la misión; se han estudiado en detalle los restos minuciosamente recolectados a lo largo de varios estados; se han realizado múltiples ensayos de diferente tipo para intentar reproducir y validar las distintas hipótesis vertidas por el equipo de investigación sobre el desarrollo de los acontecimientos... Y como resultado de todo ello, la conclusión es que el desprendimiento y posterior impacto contra la parte inferior delantera del ala izquierda del transbordador de un trozo de espuma aislante desprendida del depósito ventral, fue el origen del daño que conduciría a la destrucción del vehículo durante la reentrada.
El trozo de aislante desprendido tenía una forma más o menos ovalada, con un tamaño de 500 a 700 mm de largo por 300 a 500 de ancho, y al menos 5 cm de espesor. Su peso estaba en torno a los 600 ó 800 gramos, y la velocidad de impacto fue del orden de los 260 m/s (más de 900 km/h) Aunque se trata de una ligerísima espuma rígida, los ensayos realizados durante la investigación han demostrado que, al contrario de lo que se pensó en su momento, un fragmento de estas características pudo llegar a ocasionar un gran agujero en el borde de ataque del ala izquierda del Columbia.
Se han estudiado otras posibilidades, como el impacto de un micrometeorito o de un fragmento de basura espacial durante la parte orbital de la misión, pero tras el detallado análisis de los sensores de la nave y las imágenes radar, no se ha encontrado nada que apoye esta hipótesis. No obstante, durante el segundo día en órbita se registró la separación de un pequeño objeto que se alejaba a baja velocidad de la nave. Tras extensos análisis, se ha descartado que pudiera proceder de algún equipo experimental de la bodega o que fuera algún deshecho del propio transbordador; se comparó la imagen radar obtenida de este objeto con la que dejarían distintos elementos de la nave, obteniéndose que sería aproximadamente idéntica a la que dejaría una loseta cerámica aislante del borde de ataque del ala, o una junta rígida de carbono del mismo borde de ataque. Aunque no puede probarse, parece probable que, tras el impacto, fragmentos del recubrimiento del borde de ataque cayeran hacia el interior del mismo, liberándose al exterior en ausencia de gravedad al efectuar una pequeña maniobra de giro del transbordador.
La secuencia del accidente se ha intentado reproducir y se conoce con bastante exactitud cómo se desarrollaron los acontecimientos. En un determinado momento de la maniobra de reentrada, con el Columbia ingresando en la atmósfera con el elevado ángulo de ataque requerido para presentar el escudo térmico en su posición más efectiva, comenzó a penetrar aire extremadamente caliente hacia el interior del ala a través de una fisura o, más probablemente, un agujero producido en el borde de ataque. Este flujo de gases a enorme temperatura fue erosionando y fundiendo los materiales, agrandando el agujero y avanzando por el interior del ala izquierda en dirección a la bahía del tren de aterrizaje. Los daños en el ala fueron aumentando, comenzando a afectar al elevón izquierdo y a la maniobrabilidad del transbordador, que empezó a desviarse de su actitud nominal en alabeo y guiñada. Los sistemas de control de la nave intentaron compensar la desviación, pero los daños fueron aumentando sin que pudiera restablecerse el control. Llegado un determinado momento, la posición del Columbia se alejó tanto de la nominal que el vehículo resultó destruido por las fuerzas aerodinámicas.
Fue, por tanto, el desprendimiento del aislante lo que provocó el accidente, pero ¿por qué se desprendió? ¿Fue una mala decisión del MRB, que aceptó con “use as is” un defecto en la aplicación del aislante que se había detectado en la inspección de calidad? ¿Se trató de un fallo aleatorio debido a la naturaleza misma del aislante y del procedimiento de aplicación? Probablemente nunca se sepa, pero las recomendaciones del comité investigador incluyen modificaciones en el esquema aislante del depósito central del transbordador espacial para evitar que hechos así se repitan en el futuro. Desprendimientos de aislante se han repetido en numerosos vuelos del transbordador espacial, pero nunca habían ocasionado ningún daño, y precisamente por ello no se le dio mayor importancia, aunque nunca hasta ahora el desprendimiento detectado había sido de esta magnitud.
De hecho, el informe del comité investigador es extremadamente crítico con la NASA, con su gestión y cultura interna, tanto en materia de seguridad como de organización en general. Es más, el comienzo y conclusiones del informe señala que si bien la causa física del accidente fue el desprendimiento del aislante, tan responsable o más que el propio trozo de aislante fue la gestión de la agencia en la valoración del incidente que dio lugar al trágico accidente con la pérdida de siete vidas.
Sin entrar en más detalle por la falta de espacio, simplemente señalar que los análisis advirtieron que existía la posibilidad de que el aislante hubiera podido penetrar en la estructura... aunque no era demostrable (el modelo no estaba preparado para impactos de esta magnitud). Para asegurarse, los técnicos pidieron que se tomasen imágenes del transbordador en órbita por parte de los sistemas ópticos del Dpto. de Defensa (telescopios espías de altísima resolución), pero la petición fue denegada por los gestores de la NASA, al considerar que no había motivos para la misma. El criterio general era que los habituales desprendimientos de espuma del depósito central no eran un asunto de seguridad de vuelo... aunque nunca se había probado lo contrario. La repetitividad de la anormalidad la había convertido en normalidad, sin ningún estudio que asegurase su inocuidad. De nuevo, como sucedió con el Challenger, el exceso de confianza y la priorización de los objetivos y plazos de la misión sobre la seguridad, tuvieron mucho que ver en este nuevo accidente de la aventura espacial.
El 1 de febrero de 2003, el telediario del mediodía nos sorprendía a muchos de nosotros con las imágenes, grabadas por un videoaficionado, del Columbia desintegrándose sobre el cielo de Texas, durante la maniobra de reentrada de la misión STS-107 del transbordador espacial norteamericano. El Columbia, el más veterano de la flota de transbordadores, contabilizaba con ésta un total de 28 misiones al espacio.
Casi de inmediato empezaron a surgir las primeras hipótesis sobre las causas del accidente, mostrándose unas imágenes tomadas durante el despegue de esta misión, en las que se observaba cómo un trozo del aislante que recubre gran el depósito central de propulsante se desprendía del mismo impactando sobre el ala izquierda del Columbia. Se planteaba que éste podía haber sido el origen del fallo, aunque al mismo tiempo se argumentaba que acontecimientos similares habían ocurrido en otros despegues sin que hubieran tenido el más mínimo efecto en la integridad del transbordador. De hecho, los técnicos de tierra habían observado el impacto y, tras varios días de debate, la conclusión oficial de la NASA era que no existía riesgo alguno, habiéndose proseguido la misión con normalidad.
Luego, como suele ocurrir, el accidente dejó de ser noticia, y la investigación sobre sus causas cayó en el olvido para el público en general.
Sin embargo, la investigación del accidente ha avanzado sin pausa en este tiempo, publicándose sus conclusiones el pasado mes de septiembre. El estudio ha sido exhaustivo: se han analizado uno a uno con gran detenimiento todos los datos (y son muchos) registrados por todos los sistemas de la nave a lo largo de la misión; se han observado una y otra vez los videos del despegue y las imágenes radar obtenidas durante la parte orbital de la misión; se han estudiado en detalle los restos minuciosamente recolectados a lo largo de varios estados; se han realizado múltiples ensayos de diferente tipo para intentar reproducir y validar las distintas hipótesis vertidas por el equipo de investigación sobre el desarrollo de los acontecimientos... Y como resultado de todo ello, la conclusión es que el desprendimiento y posterior impacto contra la parte inferior delantera del ala izquierda del transbordador de un trozo de espuma aislante desprendida del depósito ventral, fue el origen del daño que conduciría a la destrucción del vehículo durante la reentrada.
El trozo de aislante desprendido tenía una forma más o menos ovalada, con un tamaño de 500 a 700 mm de largo por 300 a 500 de ancho, y al menos 5 cm de espesor. Su peso estaba en torno a los 600 ó 800 gramos, y la velocidad de impacto fue del orden de los 260 m/s (más de 900 km/h) Aunque se trata de una ligerísima espuma rígida, los ensayos realizados durante la investigación han demostrado que, al contrario de lo que se pensó en su momento, un fragmento de estas características pudo llegar a ocasionar un gran agujero en el borde de ataque del ala izquierda del Columbia.
Se han estudiado otras posibilidades, como el impacto de un micrometeorito o de un fragmento de basura espacial durante la parte orbital de la misión, pero tras el detallado análisis de los sensores de la nave y las imágenes radar, no se ha encontrado nada que apoye esta hipótesis. No obstante, durante el segundo día en órbita se registró la separación de un pequeño objeto que se alejaba a baja velocidad de la nave. Tras extensos análisis, se ha descartado que pudiera proceder de algún equipo experimental de la bodega o que fuera algún deshecho del propio transbordador; se comparó la imagen radar obtenida de este objeto con la que dejarían distintos elementos de la nave, obteniéndose que sería aproximadamente idéntica a la que dejaría una loseta cerámica aislante del borde de ataque del ala, o una junta rígida de carbono del mismo borde de ataque. Aunque no puede probarse, parece probable que, tras el impacto, fragmentos del recubrimiento del borde de ataque cayeran hacia el interior del mismo, liberándose al exterior en ausencia de gravedad al efectuar una pequeña maniobra de giro del transbordador.
La secuencia del accidente se ha intentado reproducir y se conoce con bastante exactitud cómo se desarrollaron los acontecimientos. En un determinado momento de la maniobra de reentrada, con el Columbia ingresando en la atmósfera con el elevado ángulo de ataque requerido para presentar el escudo térmico en su posición más efectiva, comenzó a penetrar aire extremadamente caliente hacia el interior del ala a través de una fisura o, más probablemente, un agujero producido en el borde de ataque. Este flujo de gases a enorme temperatura fue erosionando y fundiendo los materiales, agrandando el agujero y avanzando por el interior del ala izquierda en dirección a la bahía del tren de aterrizaje. Los daños en el ala fueron aumentando, comenzando a afectar al elevón izquierdo y a la maniobrabilidad del transbordador, que empezó a desviarse de su actitud nominal en alabeo y guiñada. Los sistemas de control de la nave intentaron compensar la desviación, pero los daños fueron aumentando sin que pudiera restablecerse el control. Llegado un determinado momento, la posición del Columbia se alejó tanto de la nominal que el vehículo resultó destruido por las fuerzas aerodinámicas.
Fue, por tanto, el desprendimiento del aislante lo que provocó el accidente, pero ¿por qué se desprendió? ¿Fue una mala decisión del MRB, que aceptó con “use as is” un defecto en la aplicación del aislante que se había detectado en la inspección de calidad? ¿Se trató de un fallo aleatorio debido a la naturaleza misma del aislante y del procedimiento de aplicación? Probablemente nunca se sepa, pero las recomendaciones del comité investigador incluyen modificaciones en el esquema aislante del depósito central del transbordador espacial para evitar que hechos así se repitan en el futuro. Desprendimientos de aislante se han repetido en numerosos vuelos del transbordador espacial, pero nunca habían ocasionado ningún daño, y precisamente por ello no se le dio mayor importancia, aunque nunca hasta ahora el desprendimiento detectado había sido de esta magnitud.
De hecho, el informe del comité investigador es extremadamente crítico con la NASA, con su gestión y cultura interna, tanto en materia de seguridad como de organización en general. Es más, el comienzo y conclusiones del informe señala que si bien la causa física del accidente fue el desprendimiento del aislante, tan responsable o más que el propio trozo de aislante fue la gestión de la agencia en la valoración del incidente que dio lugar al trágico accidente con la pérdida de siete vidas.
Sin entrar en más detalle por la falta de espacio, simplemente señalar que los análisis advirtieron que existía la posibilidad de que el aislante hubiera podido penetrar en la estructura... aunque no era demostrable (el modelo no estaba preparado para impactos de esta magnitud). Para asegurarse, los técnicos pidieron que se tomasen imágenes del transbordador en órbita por parte de los sistemas ópticos del Dpto. de Defensa (telescopios espías de altísima resolución), pero la petición fue denegada por los gestores de la NASA, al considerar que no había motivos para la misma. El criterio general era que los habituales desprendimientos de espuma del depósito central no eran un asunto de seguridad de vuelo... aunque nunca se había probado lo contrario. La repetitividad de la anormalidad la había convertido en normalidad, sin ningún estudio que asegurase su inocuidad. De nuevo, como sucedió con el Challenger, el exceso de confianza y la priorización de los objetivos y plazos de la misión sobre la seguridad, tuvieron mucho que ver en este nuevo accidente de la aventura espacial.
Cuando los ingenieros se ponen en la piel de los gestores
http://www.historiasdelaciencia.com/?p=327
Sé que la historia de hoy la conocéis todos, pero no está de más desempolvar recuerdos para no olvidar errores de antaño. Uno de esos errores fue el desastre (que no accidente) del Challenger. Y sobre dicho desastre hablaremos en nuestra historia de hoy.
El 28 de enero de 1986, el excesivamente administrado programa espacial estadounidense alcanzó su nadir. Bajo la presión de tener que probar que el transbordador servía para lanzamientos sucesivos, funcionando como un camión, las administraciones de la NASA y de sus contratistas prefirieron ignorar las advertencias de los ingenieros.
El transbordador despegaba rumbo al espacio utilizando una combinación de cohetes; los motores de oxígeno e hidrógeno líquidos en la cola del orbitador y los dos cohetes aceleradores de combustible sólido, adosados a ambos lados del enorme depósito exterior que contenía el combustible líquido.
Los dos cohetes aceleradores de combustible sólido utilizados hasta 1986 eran una pila de segmentos reutilizables. Os pongo el detalle de uno de esos cohetes aceleradores.
Después de cada vuelo, estas pilas se desmontaban, recargaban y volvían a montar. Las conexiones entre los segmentos se sellaban con dos juntas de goma, una principal y otra de apoyo, llamadas juntas tóricas (literalmente del ingés anillos-O).
Para que dichas juntas funcionaran correctamente tenían que ser dúctiles y flexibles, capaces de cubrir bien la separación cuando el combustible comenzara a arder y la presión del gas lo empujara contra las conexiones entre los segmentos.
En siete de las nueve misiones que efectuaron los transbordadores en 1985 los ingenieros de Morthon Thiokol, la empresa fabricante de los cohetes aceleradores de combustible sólido, detectaron una erosión significativa y daños en las juntas tóricas primarias. En otro vuelo, realizado en abril de 1985, detectaron que una sección de una junta tórica primaria había quedado completamente calcinada. Estas pruebas sugerían que, en condiciones de bajas temperaturas, las juntas tóricas no funcionaban como se esperaba de su diseño. A pesar de la preocupación creciente entre los ingenieros, los transbordadores seguían volando. Tal y como Roger Boisjoly, ingeniero de Morthon Thiokol, escribió en un memorando fechado en julio de 1985: Siento el verdadero y sincero temor que si no actuamos inmediatamente y dedicamos un equipo a resolver el problema … entonces corremos el peligro de perder una misión junto con todas las instalaciones de lanzamiento.
En la mañana del 28 de enero de 1986, el pronóstico para cabo Cañaveral era de una temperatura de 2,2 ºC, próxima al punto de congelación. El transbordador Challenger se disponía a iniciar su décimo vuelo y la vigésimo quinta misión de los transbordadores. Transportaba a siete astronautas, entre ellos, la maestra de escuela Christa McAuliffe, que era el primer ciudadano estadounidense seleccionado para volar al espacio sin que formara parte del programa de astronautas de la NASA.
Los ingenieros de Morthon Thiokol volvieron a advertir a sus jefes y a los responsables de la NASA del Centro de Vuelo Espacial Marshall, quienes gestionaban las relaciones con el contratista, que las frías temperaturas de la Florida podían tener un efecto negativo sobre las juntas tóricas. Los gerentes, tanto en el centro Marshall como en Morthon Thiokol, se mostraban escépticos. Creían que los datos no eran concluyentes. Más importante aún: sentían la presión ineludible pero tácita de mantener el programa de vuelo previsto.
Siempre que la NASA había retrasado el lanzamiento de un transbordador, la agencia había tenido que enfrentarse al ridículo y a las acusaciones de sus adversarios en los medios de comunicación y el Congreso relativas a que el transbordador no estaba a la altura de la promesa de lanzamientos frecuentes y baratos. Esta presión pública la situaba en una posición incómoda: si se decantaba por la prudencia y cancelaba los lanzamientos bajo sospecha sería acusada de fracaso e incompetencia y daría municiones a aquellos adversarios que pretendían bajar el presupuesto de la agencia. Antes que brindarles a sus enemigos pruebas que el programa del transbordador era un fracaso, los administradores intentaban cada vez más a menudo aguantar el tipo, con la esperanza de demostrar que incluso en condiciones difíciles el transbordador podía funcionar como un avión de carga comercial.
La misma historia se repetía una y otra vez. Del mismo modo que las motivaciones políticas habían llevado a la NASA a comprometer tanto que el diseño del transbordador como el de la estación espacial, haciendo que ambos vehículos resultaran inadecuados para cumplir la tarea para la que habían sido originalmente concebidos, los gestores de Morthon Thiokol y de la NASA cambiaron una vez más de opinión en un intento inútil por complacer a los políticos, la prensa y el público; quienes o bien no comprendían el programa espacial o bien se oponían a él abiertamente.
En un momento de la noche anterior al lanzamiento, cuando los ingenieros de Morthon Thiokol intentaban desesperadamente convencer a sus jefes de que un lanzamiento al día siguiente podía ser muy arriesgado, un ejecutivo de la misma empresa, Jerald Mason, miró a Bob Lund, gerente del departamento de ingeniería y le dijo: “Bob, tienes que ponerte en la piel de un gestor y no en la de un ingeniero”.
La presión desde arriba, las dudas sobre los datos y la insistencia en que pensara “como un gestor y no como un ingeniero” fueron suficientes para que Lund cambiara de parecer. Se sumó a los otros gestores de Morthon Thiokol y, pasando por alto la opinión de sus ingenieros, certificó la seguridad de los cohetes aceleradores para el lanzamiento.
El Challenger despegó a las 11:38 de la mañana del 28 de enero de 1986. Sin embargo, tal y como temían Boisjoly y los demás ingenieros, al menos uno de las juntas tóricas del cohete acelerador de la derecha se había vuelto rígido y había perdido su flexibilidad a causa del frío. Con la junta incapaz de conservar el sellado hermético, un humo negro comenzó a filtrarse por la junta casi inmediatamente después de la ignición.
A los 58 segundos, cuando el transbordador había alcanzado una altura superior a los 6 km y se movía a una velocidad superior a la del sonido, las llamas producidas por la filtración comenzaron a extenderse al gigantesco depósito exterior. Antes del lanzamiento, este depósito contenía caso 630.000 L de oxígeno líquido y 1.700.000 L de hidrógeno líquido, la mayor parte de ellos todavía sin quemar en ese momento del vuelo. A los 74 segundos, se incendió el combustible del depósito y el transbordador, el depósito y los cohetes estallaron.
Los dos cohetes aceleradores salieron disparados como si fueran globos pinchados, obligando a los controladores de tierra a apretar sus botones de autodestrucción. El Challenger estalló en pedazos que se precipitaron al Atlántico. Su cabina de tripulantes, diseñada para resistir fuerzas como aquellas, resistió a la explosión y algunos de los tripulantes aún permanecían con vida en su interior.
Sin embargo, las fuerzas resultaron ser mortales; y el impacto contra el océano destruyó la cabina.
¿Hemos evolucionado desde entonces? Años después, en 1997, un astronauta estadounidense llamado Jerry Linenger estuvo un total de 132 días en la MIR. Fue el primer estadounidense en efectuar un paseo espacial vistiendo un traje ruso. Durante esa época tuvieron uno de sus momentos más críticos vividos en la MIR.
Al volver a la Tierra, cuestionó la seguridad de la estación y los gestores de la NASA se mostraron más proclives a calificarlo como “quejica” que a prestar atención a sus preocupaciones. Cuando Jim van Laak, el número dos del proyecto Shuttle-Mir escuchó el informe de Linenger, en vez de preocuparse, se enfureció. En lugar de dedicarse a investigar las quejas de Linenger, comenzó a controlar las entrevistas del astronauta con la prensa, al mismo tiempo que intentaba desacreditarle ante los periodistas. “En mi opinión Jerry Linenger no tiene razón”, comentó a los periodistas. También prohibió la circulación de transcripciones o notas de cualquier sesión informativa de dicho astronauta.
Nadie se levantó para afrontar los problemas comunicados por Linenger y decir: “Es difícil y hay cosas que han salido mal. Hemos cometido errores, pero todavía queremos hacerlo”. En vez de ello, todos se pusieron su gorra de gestor e hicieron como si los problemas no existiesen.
La situación no es muy esperanzadora. No hace falta que os diga que mintiendo no llegaremos muy lejos.
Volvamos con el Challenger. Tras el desastre, se formó la comisión Rogers. Uno de los componentes de dicha comisión fue Richard Feynman. Fue quien más duramente atacó la política de seguridad de la NASA. Les amenazó con retirar su firma del informe si no aparecían sus consideraciones personales, cuya última parte es famosa: para una gestión exitosa la realidad debe estar por delante de las relaciones públicas porque a la naturaleza no se la puede engañar. Bravo, Feynman.
Como ingeniero, me vais a permitir unas reflexiones. Estoy seguro que Bob Lund, el ingeniero al que presionaron “para que se pusiera en la piel de un gestor”, se sintió terriblemente responsable por ceder ante la presión. Sin embargo, sospecho que Mason, aquel ejecutivo que le presionó, se lavó las manos de cualquier responsabilidad, ya que él nunca tuvo que estampar su firma para garantizar la seguridad de los cohetes aceleradores y no era responsable de la seguridad de los mismos. Puede que su trabajo sólo consistiera en hacer presión o, simplemente, en transmitir la que le venía desde esferas más altas o una presión inventada por él mismo. Fuera su trabajo el que fuera, ¿cuál era exactamente su responsabilidad en el lanzamiento?
Pues bien, debo recordar a este ejecutivo y gentes que actúan de forma similar, que es muy fácil presionar a los ingenieros y a los técnicos: somos personas, y como tales, aguantaremos lo que haga falta. Llevadnos al límite de nuestro aguante, amenazadnos con despidos y ponednos en situaciones desesperadas. Lo conseguiréis: firmaremos, incluso, que un puente se mantiene con cuatro palillos. Ahora bien, debéis saber que los ingenieros no podemos presionar a la Naturaleza. No se deja. La Naturaleza no entiende de presiones políticas, económicas, personales, del público ni de la imagen. Es muy suya y tal y como Feynman lo sabía, lo sabemos también los ingenieros.
Es mucho más fácil presionar y responsabilizar a un técnico presionado de un error, que aguantar la presión y actuar con criterios de seguridad y de sentido común o, en caso de desastre, aceptar la responsabilidad de haber presionado. Es lo que se conoce coloquialmente como “endosar el marrón”: hazlo tú, hazlo para ayer y “mójate”; si sale bien, qué gran trabajo hemos hecho (algunos, incluso, dicen “gracias a mi gestión”); y si sale mal, el responsable eres tú.
Bien, amigo Jerald Mason. Ya has visto qué sucede cuando los ingenieros se ponen en la piel de los gestores. Ojalá llegue el día en que los gestores os pongáis en la piel de los ingenieros.
Conste que esta reflexión no la hubiera hecho si el Challenger hubiera explotado sin otras consecuencias más que las económicas o de imagen, al igual que sucedió con el Ariane-5. La reflexión es, sobre todo, porque hubo siete personas que pagaron con sus vidas toda esta lección de cómo no deben hacerse las cosas; personas que confiaron en el buen hacer de gestores y de ingenieros. Ojalá la lección haya sido asimilada, aunque me temo mucho que nunca aprenderemos.
Va por vosotros, muchachos.
Actualización: recomiendo leer el comentario de Javier Casado.
Fuentes:
“Adiós a la Tierra”, Robert Zimmerman
http://www.xtec.net/~cgarci38/ceta/tecnologia1/challenger.htm
Si queréis saber más sobre la catástrofe del Challenger y la comisión Rogers os recomiendo el libro Qué te importa lo que piensen los demás de Richard Feynman.
Tenéis montones de vídeos en youtube, por ejemplo, la explosión, el detalle de la cabina, etc.
miércoles, febrero 20, 2008
Observaciones Cpp
Observaciones Cpp
Puede que lo que voy a contar sea conocido en gran medida, pero seré breve y rápido.
Si alguien quiere repasar o profundizar en algún punto, fenomenal.
Los ejemplos no se han compilado e intencionadamente omito cosas que pueden hacer que no compilen (seguro que es obvio y no aporta nada escribirlo lo que falta)
Herencia
En c++ es normal hacer muchas cosas sin nada de herencia
No conviene abusar de la herencia
Algunos entendidos de c++ dicen que no se debe utilizar la herencia.
Excepto en casos que deben estar muy justificados
La herencia se utiliza con varios fines
Clasificación (es un)
Polimorfismo en tiempo de ejecución
Extender algo que ya existe
Constructor
Curiosa notación
// C++
class A {
int val;
A(int _val) : val(_val) {}
};
// Java
class A {
int val;
A(int _val)
{
val = _val;
}
};
¿Porqué en c++ se utiliza esa notación con ':'?
Son muy puristas
Les preocupa mucho el rendimiento
En el ejemplo anterior no hay una diferencia muy relevante.
En java, cuando se instancia una clase (se crea un objeto), la memoria que ocupará está rellenada con ceros. De esta forma todo se queda inicializado con los valores por defecto (quizá es por razones de seguridad).
Si luego le das un valor inicial, estás inicializando dos veces, una para nada.
Cuando se inicializan muchos objetos así, puede tener impacto en el rendimiento.
Pero en C++, se utiliza esta notación, sobre todo, por ser puristas y claros.
Un ejemplo más largo...
// C++
class A {
int entero;
A(int _entero) : entero(_entero) {}
};
class B {
A val; // #1
B(A valorInic) // esto no compila
{
val = valorInic;
}
};
No compila porque primero se crea val de tipo A con el contructor vacío (linea #1) y luego se intenta copiar el valor de valorInic en val.
Pero A no tiene constructor vacío.
En C++ el código del constructor, se ejecuta siempre, después de que se haya construído el objeto (en Java hay excepciones poco claras en la sintáxis)
Otro tipo de ejemplo...
// C++
class Padre {
int val;
Padre(int _val) : val(_val) {}
};
class Hija : public Padre {
Hija(int _val) // esto no compila
{
val = _val;
}
};
class Hija2 : public Padre {
Hija2(int _val) : Padre(_val) {} // ahora sí
};
Hija tampoco compila porque la clase padre no tiene constructor vacío.
Con la notación ':' se le dice que tiene que hacer en la construcción, no después
Destructores virtuales
Los destructores de C++ sólo son virtuales si se indica explícitamente
Que no sean virtuales les da más rendimiento, pero en ocasiones es necesario que sean virtuales
Ejemplo:
class Fruta {
int* punteroInt;
Fruta() : punteroInt(new int) {};
~Fruta() { delete punteroInt; };
};
class Platano : public Fruta {
int* punteroIntDelPlatano;
Platano() : punteroIntDelPlatano(new int) {};
~Platano() { delete punteroIntDelPlatano; };
};
...
Fruta* f = new Platano();
delete f;
En este mega programa tenemos una fuga de memoria (memoria sin liberar)
El tema es que f es de tipo de Fruta aunque señale a un plátano (como un plátano es una fruta...)
El delete f, llama al destructor de Fruta, con lo que se borra de la memoria su punteroInt. NUNCA SE LLAMA AL DESTRUCTOR del plátano (y este no tiene oportunidad de liberar su puntero, pobre....)
Una opción es hacer... delete dynamic_cast(f); (pero hay que estar un poco enfermo
Es mala opción porque no siempre sabes que f tiene un plátano, podría ser una fresa, y probar con todas las frutas es mala solución.
Opción 2. Hacer virtual el destructor del padre. SÍÍÍÍ
Opción 3. Pensárselo dos veces antes de utilizar la herencia y polimorfismo en tiempo de ejecución.
IMPORTANTE. Este problema no afecta sólo a la memoria, afecta a todo recurso "no local". Por ejemplo, un semáforo, región crítica, conexión bbdd, etc...
LA OPCIÓN CORRECTA... RAII
Tratar de no liberar explícitamente recursos (de ningun tipo)
Esto en el caso de la memoria, se puede hacer con un CountPtr
http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization)
Conviene saberlo aunque es poco probable que os suceda. Un escenario posible es con la vcl (haciendo algún componente)
Operador asignación y constructor de copia
C++ es muy amable y propone siempre que puede constructores de copia y operadores de asignación.
Pero no siempre los que propone sirven y hacen lo que queremos.
Es muy importante, siempre preguntarse si el que crea nos sirve o no
Anotar con un comentario que se ha verificado es saludable
OJO con clases con recursos no locales, habitualmente memoria en forma de punteros o referencias
Una curiosidad importante
class Pr {
Pr(int i)...
};
Pr prueba = Pr(4);
Aquí parece que...
Se instancia prueba de tipo Pr con constructor vacío
Luego se instancia Pr con valor 4
Luego se llama al operador de asignación para copiar el segundo objeto en el primero
PUES NO
Esa línea es totalmente equivalente a la siguiente (más clara en lo que hace)
Pr prueba(4);
Clases índice en mapas
std::map
Muy útil para almacenar datos indexados por lo que queramos de forma segura (verificación en tiempo de compilación) y eficiente
En un mapa la clase índice debe tener definida una relación de orden extricta con el operador <. Vamos, que si definimos el operador < style="font-weight: bold;">iteradores y end()
Por ejemplo, en un mapa llamamos al método find(xxx)
miMapa.find(esto)
SIEMPRE comprobar que no vale miMapa.end() (que significa que no lo ha encontrado)
En la próxima especificación de C++ esto será mejor
En Scala, en tiempo de compilación se verifica que no te olvidas
Si no se hace esta verificación, el programa explotará en algunas ocasiones
Punteros y referencias
No utilizar punteros crudos ni aritmética de punteros
Las referencias son punteros que no lo parecen (indirección implícita) y que siempre tienen valor (siempre están inicializados) y no tienen aritmética de punteros
Punteros nunca, referencias sí, en muchos casos
Envíe "aunque parezca increíble estoy leyendo esto" al 555 55 55, participará en el sorteo de un concepto
Los punteros a punteros y punteros a referencias NOOOOOOOO, caca, caca
Fugas de memoria
Dicen que C y C++ padecen de esto, pero... no parece razonable para el caso de C++
Para los casos raros en los que es necesario un puntero (memoria de montículo o por polimorfismo en tiempo de ejecución), utiliza un CountPtr
El problema del CountPtr está en las referencias circulares, pero no es tan fácil diseñar algo con referencias circulares en C++, especialmente si no se abusan de los punteros.
Con muy poco cuidado, eso no pasará nunca
Multimétodos
C++ no tiene
Está de moda, pero no hay consenso y lo discuten mucho
Scala, que ha metido de todo, no los tiene. El autor inicialmente dijo que no se acordó, pero después no lo puso porque decía era mejor sin.
Hay discusiones sobre esto en internet
A pesar de ser un concepto sencillo, tarde bastante en enterarme
// sin multimétodos
class Grafo {
virtual Distancia(Punto punto)=0;
}
class Punto : public Grafo
{
Distancia (Punto punto);
}
class Linea : public Grafo
{
Distancia (Punto punto);
}
Grafo g1 = new Punto(100,200);
Grafo g2 = new Punto(200, 600);
g1.Distancia(Punto(120, 400));
Grafo g3(100, 250, 30);
g3.Distancia(Punto(120, 400));
// con multimétodos
class Grafo {
...
}
class Punto : public Grafo
{
...
}
class Linea : public Grafo
{
...
}
Distancia(Punto p1, Punto p2) ...
Distancia(Linea l1, Punto p1) ...
Distancia(Linea l1, Linea l2) ...
Grafo g1 = new Punto(100,200);
Grafo g2 = new Punto(200, 600);
Grafo g3(100, 250, 30);
Distancia(g1, g2);
Distancia(g3, g2);
Sin multimétodos, la llamada a Distancia del un objeto Grafo, se pasa en tiempo de ejecución al hijo que corresponda, un punto o una línea (polimorfismo en tiempo de ejecución, una de las claves fundamentales de la OOP)
Pero el segundo objeto sobre el que se realiza el cálculo (el parámetro), no puede utilizar el mismo truco
Con multimétodos, a pesar de que llamamos a Distancia con dos parámetros de tipo Grafo, y no existe una Distancia definida para dos Grafos, en tiempo de ejecución, verifica que uno de los parámetros concretamente es un punto y el otro una línea y llama a esa Distancia concreta (o la que corresponda)
Se parece al polimorfismo en tiempo de ejecución, pero no sólo para uno, sino para varios
Lo dicho, que hay una discusión sobre el tema que se puede ver en internet
No está en C++ ni estará en la próxima especificación
Herencia múltiple de implementación
No utilizar
Es cierto que en algunos casos puede ser muy interesante, pero es muy delicado
Ahora está más de moda (y parece mejor) los mixins
Conversión implícita
Es un recurso potente que debe utilizarse con cuidado
Se puede conseguir en varias direcciones
Un constructor con un sólo parámetro del tipo a convertir
Operadores en la clase que se convierte
Podéis ver un ejemplo en la clase Variant de jleTibco
En general no utilizar
NUNCA...
NUNCA Utilizaré aritmética de punteros
NUNCA Utilizaré punteros crudos
NUNCA Arrays al estilo C (que en el fondo son punteros con aritmética de punteros)
En su lugar std::vector
NUNCA Herencia múltiple de implementación
NUNCA Abusaré de la herencia
NUNCA Utilizaré dynamic_cast, const_cast, ... (RTTI)
NUNCA Utilizaré reinterpret_cast (nunca jamás)
NUNCA haré un casting al estilo C (nunca jamás)
NUNCA Haré piezas que requieran liberación explícita de recursos
NUNCA Haré programas con muchas hebras
NUNCA Utilizaré mecanismos de concurrencia de bajo nivel (regiones críticas, semáforos, monitores, etc...)
NUNCA utilizaré "using namespace"
NUNCA intentaré utilizar namespaces anidados
NUNCA diré en la definición de una función o método las excepciones que puede lanzar
NUNCA pondré un nombre a un namespace superior a 3 letras
NUNCA utilizaré macros
NUNCA pensaré que C++ se parece a C
NUNCA manejaré los string de C ni la entrada salida de C, ni lista de parámetros variables (C otra vez)
NUNCA utilizar malloc ni semejantes
NUNCA Pondré degradados de colores ;-P
(consejos de un pecador)
Puede que lo que voy a contar sea conocido en gran medida, pero seré breve y rápido.
Si alguien quiere repasar o profundizar en algún punto, fenomenal.
Los ejemplos no se han compilado e intencionadamente omito cosas que pueden hacer que no compilen (seguro que es obvio y no aporta nada escribirlo lo que falta)
Herencia
En c++ es normal hacer muchas cosas sin nada de herencia
No conviene abusar de la herencia
Algunos entendidos de c++ dicen que no se debe utilizar la herencia.
Excepto en casos que deben estar muy justificados
La herencia se utiliza con varios fines
Clasificación (es un)
Polimorfismo en tiempo de ejecución
Extender algo que ya existe
Constructor
Curiosa notación
// C++
class A {
int val;
A(int _val) : val(_val) {}
};
// Java
class A {
int val;
A(int _val)
{
val = _val;
}
};
¿Porqué en c++ se utiliza esa notación con ':'?
Son muy puristas
Les preocupa mucho el rendimiento
En el ejemplo anterior no hay una diferencia muy relevante.
En java, cuando se instancia una clase (se crea un objeto), la memoria que ocupará está rellenada con ceros. De esta forma todo se queda inicializado con los valores por defecto (quizá es por razones de seguridad).
Si luego le das un valor inicial, estás inicializando dos veces, una para nada.
Cuando se inicializan muchos objetos así, puede tener impacto en el rendimiento.
Pero en C++, se utiliza esta notación, sobre todo, por ser puristas y claros.
Un ejemplo más largo...
// C++
class A {
int entero;
A(int _entero) : entero(_entero) {}
};
class B {
A val; // #1
B(A valorInic) // esto no compila
{
val = valorInic;
}
};
No compila porque primero se crea val de tipo A con el contructor vacío (linea #1) y luego se intenta copiar el valor de valorInic en val.
Pero A no tiene constructor vacío.
En C++ el código del constructor, se ejecuta siempre, después de que se haya construído el objeto (en Java hay excepciones poco claras en la sintáxis)
Otro tipo de ejemplo...
// C++
class Padre {
int val;
Padre(int _val) : val(_val) {}
};
class Hija : public Padre {
Hija(int _val) // esto no compila
{
val = _val;
}
};
class Hija2 : public Padre {
Hija2(int _val) : Padre(_val) {} // ahora sí
};
Hija tampoco compila porque la clase padre no tiene constructor vacío.
Con la notación ':' se le dice que tiene que hacer en la construcción, no después
Destructores virtuales
Los destructores de C++ sólo son virtuales si se indica explícitamente
Que no sean virtuales les da más rendimiento, pero en ocasiones es necesario que sean virtuales
Ejemplo:
class Fruta {
int* punteroInt;
Fruta() : punteroInt(new int) {};
~Fruta() { delete punteroInt; };
};
class Platano : public Fruta {
int* punteroIntDelPlatano;
Platano() : punteroIntDelPlatano(new int) {};
~Platano() { delete punteroIntDelPlatano; };
};
...
Fruta* f = new Platano();
delete f;
En este mega programa tenemos una fuga de memoria (memoria sin liberar)
El tema es que f es de tipo de Fruta aunque señale a un plátano (como un plátano es una fruta...)
El delete f, llama al destructor de Fruta, con lo que se borra de la memoria su punteroInt. NUNCA SE LLAMA AL DESTRUCTOR del plátano (y este no tiene oportunidad de liberar su puntero, pobre....)
Una opción es hacer... delete dynamic_cast
Es mala opción porque no siempre sabes que f tiene un plátano, podría ser una fresa, y probar con todas las frutas es mala solución.
Opción 2. Hacer virtual el destructor del padre. SÍÍÍÍ
Opción 3. Pensárselo dos veces antes de utilizar la herencia y polimorfismo en tiempo de ejecución.
IMPORTANTE. Este problema no afecta sólo a la memoria, afecta a todo recurso "no local". Por ejemplo, un semáforo, región crítica, conexión bbdd, etc...
LA OPCIÓN CORRECTA... RAII
Tratar de no liberar explícitamente recursos (de ningun tipo)
Esto en el caso de la memoria, se puede hacer con un CountPtr
http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization)
Conviene saberlo aunque es poco probable que os suceda. Un escenario posible es con la vcl (haciendo algún componente)
Operador asignación y constructor de copia
C++ es muy amable y propone siempre que puede constructores de copia y operadores de asignación.
Pero no siempre los que propone sirven y hacen lo que queremos.
Es muy importante, siempre preguntarse si el que crea nos sirve o no
Anotar con un comentario que se ha verificado es saludable
OJO con clases con recursos no locales, habitualmente memoria en forma de punteros o referencias
Una curiosidad importante
class Pr {
Pr(int i)...
};
Pr prueba = Pr(4);
Aquí parece que...
Se instancia prueba de tipo Pr con constructor vacío
Luego se instancia Pr con valor 4
Luego se llama al operador de asignación para copiar el segundo objeto en el primero
PUES NO
Esa línea es totalmente equivalente a la siguiente (más clara en lo que hace)
Pr prueba(4);
Clases índice en mapas
std::map
Muy útil para almacenar datos indexados por lo que queramos de forma segura (verificación en tiempo de compilación) y eficiente
En un mapa la clase índice debe tener definida una relación de orden extricta con el operador <. Vamos, que si definimos el operador < style="font-weight: bold;">iteradores y end()
Por ejemplo, en un mapa llamamos al método find(xxx)
miMapa.find(esto)
SIEMPRE comprobar que no vale miMapa.end() (que significa que no lo ha encontrado)
En la próxima especificación de C++ esto será mejor
En Scala, en tiempo de compilación se verifica que no te olvidas
Si no se hace esta verificación, el programa explotará en algunas ocasiones
Punteros y referencias
No utilizar punteros crudos ni aritmética de punteros
Las referencias son punteros que no lo parecen (indirección implícita) y que siempre tienen valor (siempre están inicializados) y no tienen aritmética de punteros
Punteros nunca, referencias sí, en muchos casos
Envíe "aunque parezca increíble estoy leyendo esto" al 555 55 55, participará en el sorteo de un concepto
Los punteros a punteros y punteros a referencias NOOOOOOOO, caca, caca
Fugas de memoria
Dicen que C y C++ padecen de esto, pero... no parece razonable para el caso de C++
Para los casos raros en los que es necesario un puntero (memoria de montículo o por polimorfismo en tiempo de ejecución), utiliza un CountPtr
El problema del CountPtr está en las referencias circulares, pero no es tan fácil diseñar algo con referencias circulares en C++, especialmente si no se abusan de los punteros.
Con muy poco cuidado, eso no pasará nunca
Multimétodos
C++ no tiene
Está de moda, pero no hay consenso y lo discuten mucho
Scala, que ha metido de todo, no los tiene. El autor inicialmente dijo que no se acordó, pero después no lo puso porque decía era mejor sin.
Hay discusiones sobre esto en internet
A pesar de ser un concepto sencillo, tarde bastante en enterarme
// sin multimétodos
class Grafo {
virtual Distancia(Punto punto)=0;
}
class Punto : public Grafo
{
Distancia (Punto punto);
}
class Linea : public Grafo
{
Distancia (Punto punto);
}
Grafo g1 = new Punto(100,200);
Grafo g2 = new Punto(200, 600);
g1.Distancia(Punto(120, 400));
Grafo g3(100, 250, 30);
g3.Distancia(Punto(120, 400));
// con multimétodos
class Grafo {
...
}
class Punto : public Grafo
{
...
}
class Linea : public Grafo
{
...
}
Distancia(Punto p1, Punto p2) ...
Distancia(Linea l1, Punto p1) ...
Distancia(Linea l1, Linea l2) ...
Grafo g1 = new Punto(100,200);
Grafo g2 = new Punto(200, 600);
Grafo g3(100, 250, 30);
Distancia(g1, g2);
Distancia(g3, g2);
Sin multimétodos, la llamada a Distancia del un objeto Grafo, se pasa en tiempo de ejecución al hijo que corresponda, un punto o una línea (polimorfismo en tiempo de ejecución, una de las claves fundamentales de la OOP)
Pero el segundo objeto sobre el que se realiza el cálculo (el parámetro), no puede utilizar el mismo truco
Con multimétodos, a pesar de que llamamos a Distancia con dos parámetros de tipo Grafo, y no existe una Distancia definida para dos Grafos, en tiempo de ejecución, verifica que uno de los parámetros concretamente es un punto y el otro una línea y llama a esa Distancia concreta (o la que corresponda)
Se parece al polimorfismo en tiempo de ejecución, pero no sólo para uno, sino para varios
Lo dicho, que hay una discusión sobre el tema que se puede ver en internet
No está en C++ ni estará en la próxima especificación
Herencia múltiple de implementación
No utilizar
Es cierto que en algunos casos puede ser muy interesante, pero es muy delicado
Ahora está más de moda (y parece mejor) los mixins
Conversión implícita
Es un recurso potente que debe utilizarse con cuidado
Se puede conseguir en varias direcciones
Un constructor con un sólo parámetro del tipo a convertir
Operadores en la clase que se convierte
Podéis ver un ejemplo en la clase Variant de jleTibco
En general no utilizar
NUNCA...
NUNCA Utilizaré aritmética de punteros
NUNCA Utilizaré punteros crudos
NUNCA Arrays al estilo C (que en el fondo son punteros con aritmética de punteros)
En su lugar std::vector
NUNCA Herencia múltiple de implementación
NUNCA Abusaré de la herencia
NUNCA Utilizaré dynamic_cast, const_cast, ... (RTTI)
NUNCA Utilizaré reinterpret_cast (nunca jamás)
NUNCA haré un casting al estilo C (nunca jamás)
NUNCA Haré piezas que requieran liberación explícita de recursos
NUNCA Haré programas con muchas hebras
NUNCA Utilizaré mecanismos de concurrencia de bajo nivel (regiones críticas, semáforos, monitores, etc...)
NUNCA utilizaré "using namespace"
NUNCA intentaré utilizar namespaces anidados
NUNCA diré en la definición de una función o método las excepciones que puede lanzar
NUNCA pondré un nombre a un namespace superior a 3 letras
NUNCA utilizaré macros
NUNCA pensaré que C++ se parece a C
NUNCA manejaré los string de C ni la entrada salida de C, ni lista de parámetros variables (C otra vez)
NUNCA utilizar malloc ni semejantes
NUNCA Pondré degradados de colores ;-P
(consejos de un pecador)
domingo, febrero 17, 2008
programación imperativa vs declarativa
Programación imperativa vs declarativa
Yo no soy expecialista en programación declarativa.
Una visión global y breve...
Conceptos breves antes de empezar...
La característica fundamental de la programación declarativa es que no tiene asignación destructiva. Es decir, que una variable no puede cambiar su valor.
Esto provoca que el orden de ejecución no tiene porque ser secuencial.
Los bucles hay que reemplazarlos por funciones recursivas.
1.---------------------------------------------------------------
Existen problemas que son naturalmente imperativos.
Un programa se descompone en entrada, proceso y salida.
Tanto la entrada como la salida, son acciones imperativas (consola, conexión tcp, fichero, etc..).
La mayoría de lenguajes declarativos, tienen características imperativas para ello (no son declarativos puros)
2.---------------------------------------------------------------
Todos los programadores declarativos conocen la programación imperativa.
Lógicamente, esto es porque la programación imperativa está muchísimo más extendida
Casi todos los programadores declarativos, empezaron con la programación imperativa, y ahora defienden la programación declarativa sobre la imperativa.
Esto podría ser el famoso efecto de las minorías y débiles, que tratan de compensarlo gritando más.
Pero en este caso, lo argumentan con lógica.
Richard Stallman, un genio de la programación, eligió LISP para su proyecto estrella Emacs
c omega es el lenguaje de programación para experimentar novedades para c#.
Inicialmente, este lenguaje se obtenía modificando el compilador de c# (que está escrito en c++ ¿no es tan bueno c#?).
Pero los programadores dijeron que era muy duro andar tocando el compilador c++ y optaron por utilizar un dialecto de scheme que generaba código c#, que luego volvían a compilar.
Aquí hay un tutorial de haskell para programadores imperativos
http://www.haskell.org/~pairwise/intro/intro.html
3.---------------------------------------------------------------
En la programación declarativa es más fácil la verificación de los programas.
En programación imperativa no sólo importa los valores con los que se llaman, también depende el orden de la llamada al método, a los métodos del objeto y casi siempre, a cualquier cosa del programa. Esto provoca una explosión de posibilidades imposible de verificar.
4.---------------------------------------------------------------
Los lenguajes declarativos suelen tener un poder expresivo impresionante.
El caso más radical es Haskell. Probablemente el lenguaje más potente y expresivo.
Quizá para ser capaz de sacarle partido, es necesaria una capacidad especial.
5.---------------------------------------------------------------
Los lenguajes declarativos, especialmente Haskell tienen fama de no ser muy eficientes.
Creo que para ejemplos sencillos, que se pueden optimizar fácilmente en c/c++ (por ejemplo), Haskell puede estar detrás.
Pero para casos reales, grandes y complejos de optimizar, Haskell tiene ventajas importantes.
La evaluación perezosa, la optimización dinámica y que el compilador pueda elegir el orden de ejecución para buscar el más óptimo... seguramente produzcan un código muy eficiente, sin mucha preocupación al programador.
Sin estas herramientas, todos sabemos, que las optimizaciones son la principal fuente de errores en los programas.
6.---------------------------------------------------------------
Los lenguajes declarativos son naturalmente paralelizables
Aquí la diferencia es radical e incomparable.
Un ejemplo muy bueno está en el lenguaje Erlang.
Erlang es un lenguaje declarativo muy, muy sencillo (uno de los más sencillos que he visto en mi vida)
Está orientado a sistemas de ejecución paralela, distribuida, tolerante a fallos, ejecución continua...
Para el SO, crear un proceso es caro, conmutar un proceso es caro.
Es más barato con hebras (para eso se crearon), pero aún así sigue siendo un recurso caro (unos pocos miles es demasiado).
En Erlang, crear un proceso es increíblemente barato, y lo mismo para las conmutaciones, y lo mismo para el paso de mensajes (nada de numeritos, mensajes complejos)
Ejemplo en yaws (yet another web server). Comparación con apache.
http://www.sics.se/~joe/apachevsyaws.html
Esta comparación es salvaje, pero también es comparar dos productos en el punto fuerte de uno de ellos.
En 4000 peticiones simultáneas, Apache casca, demasiados procesos.
Mientas que yaws (erlang) da mejor rendimiento incluso para 80.000 peticiones simultáneas.
7.---------------------------------------------------------------
El futuro es la programación paralela, dicen algunos.
La velocidad de los micros se ha parado, ahora buscan potencia haciéndolos multinúcleo.
Intel dice que prevee meter hasta 100 núcleos.
¿Están los programas preparados para aprovechar estas nuevas configuraciones?
NO
¿Están los lenguajes de programación preparados para ayudar en este nuevo escenario?
Los imperativos no.
Aquí tenéis un artículo fantástico
http://www.gotw.ca/publications/concurrency-ddj.htm
8.---------------------------------------------------------------
La programación declarativa es extrictamente académica??
Seguro que no está tan difundida como la imperativa, pero muchos defienden que no es puramente académica.
Se utilizar en las universidades, por profesores e investigadores, porque probablemente es la mejor opción.
Erlang está funcionando en máquinas muy caras con unas cifras espectaculares.
Ericson está explotando Erlang en máquinas con programas de más de 3 millones de líneas de código, con una tasa de fallo de 31 milisegundos al año
http://www.erlang.se/publications/BYTE2003.html
9.---------------------------------------------------------------
La programación declarativa es mejor para cosas pequeñas.
Erlang ha demostrado que puede funcionar muy bien en proyectos enormes.
Exprogramadores imperativos dicen que la gran ventaja de Haskell es para programas grandes o enormes
http://www.haskell.org/~pairwise/intro/intro.html
Scala recomienda utilizar todo lo posible la programación declarativa para poder eSCALAr al máximo.
10.-------------------------------------------------------------
Gran parte de las novedades de los lenguajes imperativos, o son características declarativas, o son cosas que aparecieron antes en estos lenguajes.
11.-------------------------------------------------------------
Líneas de código, tiempo de desarrollo...
Algunas pruebas dicen que Haskell gana
http://www.haskell.org/papers/NSWC/jfp.ps
12.-------------------------------------------------------------
Un inconveniente con los lenguajes muy expresivos, es que hace difícil la vida a los IDE y los compiladores.
Para un IDE es mucho más difícil funciones como autocompletar.
Para un compilador es más difícil informar con precisión del error.
Ver caso de C++ (seguro que también le sucederá a Scala). Creo que le pasa a Haskell
Yo no soy expecialista en programación declarativa.
Una visión global y breve...
Conceptos breves antes de empezar...
La característica fundamental de la programación declarativa es que no tiene asignación destructiva. Es decir, que una variable no puede cambiar su valor.
Esto provoca que el orden de ejecución no tiene porque ser secuencial.
Los bucles hay que reemplazarlos por funciones recursivas.
1.---------------------------------------------------------------
Existen problemas que son naturalmente imperativos.
Un programa se descompone en entrada, proceso y salida.
Tanto la entrada como la salida, son acciones imperativas (consola, conexión tcp, fichero, etc..).
La mayoría de lenguajes declarativos, tienen características imperativas para ello (no son declarativos puros)
2.---------------------------------------------------------------
Todos los programadores declarativos conocen la programación imperativa.
Lógicamente, esto es porque la programación imperativa está muchísimo más extendida
Casi todos los programadores declarativos, empezaron con la programación imperativa, y ahora defienden la programación declarativa sobre la imperativa.
Esto podría ser el famoso efecto de las minorías y débiles, que tratan de compensarlo gritando más.
Pero en este caso, lo argumentan con lógica.
Richard Stallman, un genio de la programación, eligió LISP para su proyecto estrella Emacs
c omega es el lenguaje de programación para experimentar novedades para c#.
Inicialmente, este lenguaje se obtenía modificando el compilador de c# (que está escrito en c++ ¿no es tan bueno c#?).
Pero los programadores dijeron que era muy duro andar tocando el compilador c++ y optaron por utilizar un dialecto de scheme que generaba código c#, que luego volvían a compilar.
Aquí hay un tutorial de haskell para programadores imperativos
http://www.haskell.org/~pairwise/intro/intro.html
3.---------------------------------------------------------------
En la programación declarativa es más fácil la verificación de los programas.
En programación imperativa no sólo importa los valores con los que se llaman, también depende el orden de la llamada al método, a los métodos del objeto y casi siempre, a cualquier cosa del programa. Esto provoca una explosión de posibilidades imposible de verificar.
4.---------------------------------------------------------------
Los lenguajes declarativos suelen tener un poder expresivo impresionante.
El caso más radical es Haskell. Probablemente el lenguaje más potente y expresivo.
Quizá para ser capaz de sacarle partido, es necesaria una capacidad especial.
5.---------------------------------------------------------------
Los lenguajes declarativos, especialmente Haskell tienen fama de no ser muy eficientes.
Creo que para ejemplos sencillos, que se pueden optimizar fácilmente en c/c++ (por ejemplo), Haskell puede estar detrás.
Pero para casos reales, grandes y complejos de optimizar, Haskell tiene ventajas importantes.
La evaluación perezosa, la optimización dinámica y que el compilador pueda elegir el orden de ejecución para buscar el más óptimo... seguramente produzcan un código muy eficiente, sin mucha preocupación al programador.
Sin estas herramientas, todos sabemos, que las optimizaciones son la principal fuente de errores en los programas.
6.---------------------------------------------------------------
Los lenguajes declarativos son naturalmente paralelizables
Aquí la diferencia es radical e incomparable.
Un ejemplo muy bueno está en el lenguaje Erlang.
Erlang es un lenguaje declarativo muy, muy sencillo (uno de los más sencillos que he visto en mi vida)
Está orientado a sistemas de ejecución paralela, distribuida, tolerante a fallos, ejecución continua...
Para el SO, crear un proceso es caro, conmutar un proceso es caro.
Es más barato con hebras (para eso se crearon), pero aún así sigue siendo un recurso caro (unos pocos miles es demasiado).
En Erlang, crear un proceso es increíblemente barato, y lo mismo para las conmutaciones, y lo mismo para el paso de mensajes (nada de numeritos, mensajes complejos)
Ejemplo en yaws (yet another web server). Comparación con apache.
http://www.sics.se/~joe/apachevsyaws.html
Esta comparación es salvaje, pero también es comparar dos productos en el punto fuerte de uno de ellos.
En 4000 peticiones simultáneas, Apache casca, demasiados procesos.
Mientas que yaws (erlang) da mejor rendimiento incluso para 80.000 peticiones simultáneas.
7.---------------------------------------------------------------
El futuro es la programación paralela, dicen algunos.
La velocidad de los micros se ha parado, ahora buscan potencia haciéndolos multinúcleo.
Intel dice que prevee meter hasta 100 núcleos.
¿Están los programas preparados para aprovechar estas nuevas configuraciones?
NO
¿Están los lenguajes de programación preparados para ayudar en este nuevo escenario?
Los imperativos no.
Aquí tenéis un artículo fantástico
http://www.gotw.ca/publications/concurrency-ddj.htm
8.---------------------------------------------------------------
La programación declarativa es extrictamente académica??
Seguro que no está tan difundida como la imperativa, pero muchos defienden que no es puramente académica.
Se utilizar en las universidades, por profesores e investigadores, porque probablemente es la mejor opción.
Erlang está funcionando en máquinas muy caras con unas cifras espectaculares.
Ericson está explotando Erlang en máquinas con programas de más de 3 millones de líneas de código, con una tasa de fallo de 31 milisegundos al año
http://www.erlang.se/publications/BYTE2003.html
9.---------------------------------------------------------------
La programación declarativa es mejor para cosas pequeñas.
Erlang ha demostrado que puede funcionar muy bien en proyectos enormes.
Exprogramadores imperativos dicen que la gran ventaja de Haskell es para programas grandes o enormes
http://www.haskell.org/~pairwise/intro/intro.html
Scala recomienda utilizar todo lo posible la programación declarativa para poder eSCALAr al máximo.
10.-------------------------------------------------------------
Gran parte de las novedades de los lenguajes imperativos, o son características declarativas, o son cosas que aparecieron antes en estos lenguajes.
11.-------------------------------------------------------------
Líneas de código, tiempo de desarrollo...
Algunas pruebas dicen que Haskell gana
http://www.haskell.org/papers/NSWC/jfp.ps
12.-------------------------------------------------------------
Un inconveniente con los lenguajes muy expresivos, es que hace difícil la vida a los IDE y los compiladores.
Para un IDE es mucho más difícil funciones como autocompletar.
Para un compilador es más difícil informar con precisión del error.
Ver caso de C++ (seguro que también le sucederá a Scala). Creo que le pasa a Haskell
miércoles, febrero 06, 2008
Matemáticas y beisbol
origen... http://www.historiasdelaciencia.com/?p=317#more-317
¿Qué relación hay entre el béisbol y los números primos? Aunque en el béisbol, al igual que en otros deportes, son muy importantes las estadísticas, en este artículo nos referimos a una relación bastante más curiosa e inesperada con las matemáticas, en particular, con los números primos. Y sobre ello y otras anécdotas versará nuestra historia de hoy.
El 8 de abril de 1974, Hank Aaron bateó un home run (en castellano se puede decir también “jonrón”): el numero 715 de su carrera. La importancia de este home run era que, con él, Aaron rompía la marca histórica que Babe Ruth estableció en 1935 y que estaba precisamente en 714.
Resulta que Carl Pomerance, un matemático que trabajaba en la ciudad de Atlanta, donde Aaron había bateado su home run 715, notó que los factores primos de 714 y 715 satisfacían una propiedad interesante.
Si factorizamos ambos números obtenemos las siguientes descomposiciones:
714 = 2 × 3 × 7 × 17
715 = 5 × 11 × 13
Si nos fijamos en las sumas de ambas factorizaciones tenemos que:
2 + 3 + 7 + 17 = 5 + 11 + 13 = 29
A los números que satisfacen esta propiedad, es decir, a los pares consecutivos cuya descomposición en factores primos tienen la misma suma, Pomerance les llamó pares de Ruth–Aaron. Y claro está, en cosas como esta, los ordenadores son fantásticos. Pomerance descubrió que entre los números menores que 20.000 hay 26 pares de Ruth–Aaron. El mayor en este rango lo forman el 18.490 y y el 18.491.
Aunque los pares disminuían en cantidad cuando los números crecían, Pomerance conjeturó que había infinitos pares de Ruth–Aaron, pero no tenía idea de demostrar su corazonada. Su descubrimiento fue publicado en un paper de tono desenfadado en el Journal of Recreational Mathematics. Una semana después de la publicación recibió una llamada de Paul Erdös, a quien no conocía. El maestro de la teoría de números le dijo que había demostrado la conjetura y que quería ser invitado a Atlanta para mostrarla. Esto de decir “quería ser invitado” debe ser matizado y sólo se entiende si conocemos un poquito más a este excéntrico y genial matemático, así que os recuerdo unos pocos detalles que, a buen seguro, harán vuestras delicias.
Reunía todos los clichés del sabio distraído y del genio desorganizado. Comenzó su fama como niño prodigio en Hungría. A los cuatro años de edad le dijo a su madre: “si sustraes 250 de 100, obtienes -150″. A esa misma edad era capaz de multiplicar cifras de tres y cuatro dígitos sólo de cabeza.
A los 18 años causó sensación en los círculos matemáticos de Hungría al presentar una prueba sencilla del teorema de Euclides que dice que entre cualquier número entero y su doble existe, al menos, un número primo. Esta prueba ya existía y la había dado el ruso Pafnuti Lvóvitch Chebyshef, pero su prueba era demasiado extensa para figurar en los libros de texto. Erdös había proporcionado, sin embargo, una prueba sencilla y simple.
Un día llamó a la puerta de una zapatería. La empleada salió a abrir. Después de las mínimas frases de introducción la conversación fue la siguiente:
- Dígame un número de cuatro cifras.
- 2.532 - respondió la dependienta.
- Su cuadrado es 6.411.024. Lo siento, estoy perdiendo facultades y no puedo darle el cubo. ¿Cuántas pruebas del teorema de Pitágoras conoce?
- Una.
- Yo conozco 37.
Y continuó un rato haciéndole preguntas de matemáticas.
De adulto sólo pensaba en matemáticas y se dice que incluso pensaba en ellas aunque estuviera pensando en otra cosa. Escribió, sólo y en colaboración con otros, un total de 1.475 artículos académicos, muchos de ellos imprescindibles y todos muy valiosos. Hizo matemáticas en 25 países diferentes, completando teoremas en lugares remotos y a veces publicándolos en revistas poco conocidas. En su época, se decía que alguien no era un verdadero matemático si no le conocía.
Le fascinaban los problemas fáciles de plantear pero difíciles de resolver. Tenía tanta manía matemática que cuando entraba en una habitación su primera observación era: “Cuatro paredes dividido por dos ventanas”. Sus cartas solían empezar normalmente con un “Supongamos que x es …”.
Medía un metro setenta, pesaba 49 kilos y tenía el pelo blanco, así que podemos decir que su aspecto era cadavérico, demacrado o enfermizo. Si a esto añadimos que cuando iba andando por la calle iba gesticulando, siempre sumido en las matemáticas, no sé qué más se podrá decir de él.
Sólo poseía una maleta, la ropa que llevaba puesta y una radio de la época de las cavernas. Decía que la propiedad privada era una carga. A principios de los setenta llegó como profesor invitado por un año. Después de cobrar su primera paga, un mendigo le pidió el dinero que costaba una taza de té. Erdös tomó el sobre, separó una cierta cantidad para sus gastos frugales y le dio el resto al mendigo. En 1984 le dieron el Premio Wolf, el más lucrativo en matemáticas con 50.000 dólares de premio. Se quedó con 720 dólares y el resto lo donó para que se hiciera un campamento para chicos con problemas de conducta. A finales de la década de los 80 supo de un estudiante que quería estudiar matemáticas pero que no podía por problemas de dinero. Le dio 1.000 dólares prestados y que sólo se los devolviera cuando hubiera arreglado dichos problemas. Una década más tarde el estudiante quiso devolvérselos y se lo dijo a Graham, un amigo común: “¿Erdös querrá que le pague con intereses?”. Cuando Graham se lo preguntó a Erdös le contestó: “Dile que haga con los 1.000 dólares lo mismo que hice yo”.
No tenía ocupación laboral estable: daba clases aquí y allá y conferencias, y así iba tirando. Renunció absolutamente a todas las comodidades materiales, incluso tampoco tenía domicilio fijo: vivía en casas de amigos allí donde le tocaba enseñar o hacer de conferenciante. Poseía un lenguaje peculiar. Los niños eran “épsilon” (en matemáticas, épsilon es un número muy pequeño), dar clases “predicar”, el matrimonio “captura” y Dios era “FS” (fascista supremo); las mujeres eran “jefes”, los hombres “esclavos”, los casados “atrapados”, la música era “ruido” y el alcohol “veneno”. Cuando decía que alguien había muerto significaba que había dejado de hacer matemáticas. Rechazaba toda religión organizada. Un día fue a dar clase a una escuela católica y dijo que lo único que le molestaba era que hubiera tantos signos “más” (+) en las paredes. En otra ocasión le preguntaron: “¿Qué dirías a Jesucristo si te lo encontraras en la calle?” y respondió que le preguntaría si la hipótesis del continuo era verdad. Daba tres posibilidades en la contestación que debía darle este último:
a) Gödel y Cohen ya había dicho todo lo que hay que saber.
b) Sí existe respuesta, pero tu cerebro no está lo suficientemente desarrollado para entenderla.
c) El Padre, el Espíritu Santo y Yo hemos estado elucubrando sobre el particular desde mucho antes de la Creación, pero no hemos llegado a ninguna conclusión.
Y añadía que esta última respuesta sería la más amable.
Una mañana, en Nueva Jersey, se mencionó el nombre de un colega de California. En ese momento, Erdös recordó un resultado matemático que quiso compartir con él. Se levantó y fue a marcar el número. Su anfitrión le recordó que en California eran las 5 de la mañana. Erdös respondió: “Muy bien, eso significa que estará en casa”.
Escribió con otros 485 autores, por lo que se puede decir que colaboró con más gente que cualquier otro matemático en la historia. A esos 485 se dice que tienen número de Erdös 1. Si alguien ha trabajado con uno de esos 485 se dice que tiene el número de Erdös 2. Si alguien con alguno de estos últimos tendrá el número de Erdös 3 y así sucesivamente. Einstein tenía número de Erdös 2. Aun cuando estuvo bien entrado en los 70, hubo algunos años en los que publicó 50 artículos. Los buenos matemáticos escriben ese orden de publicaciones … en toda su vida.
En 1976 George Purdy y otros matemáticos estaban tomando café en el salón de la Universidad de Texas. En la pizarra que quedaba a sus espaldas había un problema de análisis funcional, un campo extraño para Erdös. Purdy sabía que dos matemáticos acababan de dar con una solución del mismo que habían condensado en 30 páginas. Erdös miró a la pizarra y dijo: “¿Qué es eso? ¿Es un problema?”. Purdy le dijo que sí. Entonces, se dirigió a la pizarra y se concentró en los enunciados, hizo unas cuantas preguntas sobre qué representaban algunos símbolos y luego, sin esfuerzo, escribió la solución en dos líneas. Los que estaban presentes se quedaron estupefactos, como si hubieran asistido a un truco de magia.
Os podría contar muchas cosas más de este fascinante personaje, pero me extendería demasiado. Hay un maravilloso libro titulado “El hombre que sólo amaba los números” que cito en fuentes y que ya os recomendé que trata de la vida y peripecias de este hombre, su pasión por las matemáticas y su lado más humano.
Pero volvamos con Pomerance y los pares de Ruth-Aaron. El encuentro derivó en una colaboración que se plasmó en 21 publicaciones. En 1995, Hank Aaron y Paul Erdös recibieron el doctorado honoris causa de la Universidad de Emory. Erdös, si bien llevaba toga y birrete, también llevaba sus sandalias. Se sentó en el podio con la cabeza entre las manos garabateando sus cuadernos de matemáticas mientras duraba la ceremonia.
Pomerance explicó todo sobre los pares de Ruth-Aaron al propio jugador Hank Aaron, quien escuchó pacientemente lo que cambió la vida del propio Pomerance. Finalmente les pidió a ambos (a Erdös y a Aaron) que le autografiaran una pelota de béisbol, lo cual hicieron con gusto; y así, Pomerance afirmó: “Hank Aaron tiene número de Erdös uno”.
Os dejo finalmente con una frase que a Erdös le gustaba decir:
Un matemático es una máquina que convierte café en teoremas.
Estos matemáticos están locos.
Fuentes:
“El hombre que sólo amaba los números“, Paul Hoffman.
Un buen resumen del libro anterior
lunes, febrero 04, 2008
operación de EQUIVALENCIA en Java y Scala JVM
Capítulo 21 ScalaBook, lectura imprescindible
Especialmente para programadores Java y .net, pero muy práctico para todos
Trata sobre "¿este objeto es igual que este otro?"
Dice que en Java, se ha verificado que lo raro es encontrar este método correctamente sobreescrito (muy raro)
Es muy raro encontrar un programador de Java que sobreescriba la relación de equivalencia correctamente
Y eso puede tener consecuencias muy malas
¿Qué opina Scala de todo esto?
Primero...
El libro insiste como nadie en como debe hacerse correctamente para que no te equivoques.
Eso ayuda, pero... no es una ayuda impresionante.
Por ejemplo, Groovy (lenguaje compilado pero dinámico para la máquina virtual de Java) siempre te crea un operador de igualdad y función Hash correctas, tú puedes sobreescribirlo si quieres, pero, por defecto tienes algo que funciona
Si en Scala creas "case class" en vez de class normal, Scala te creará una función Hash y operador de comparación correctos
¿Porqué sólo si es una "case class"?
Quizá por rendimiento, pero lo importante es que si no es una "case class" funciona igual de mal que Java.
Tienes una función Hash y una función de equivalencia, que sólo sirven para dar problemas
¿No sería mejor en estos casos no tener nada y que explotara en tiempo de compilación?
Sí, pero en Java, son métodos definidos en Object. Por lo tanto todos tienen que tener implementación.
Como Java NUNCA da una implementación de estos automática para tus clases, y como es muy frecuente que tus clases no necesiten estos métodos... Java opta por...
No te voy a dar el coñazo obligándote a definir unos métodos que casi nunca te sirven para nada. Yo en Object ya te doy una implementación.
Majete que es el colega... no te da por saco continuamente, pero... eso provoca uno de los mayores puntos de error en Java (porque el pobrecito no tiene ni idea en Object de como se comparan manzanas)
Error que sólo se detecta en tiempo de ejecución y puede ser difícil de encontrar
La conclusión es que Scala en este punto es mucho mejor que Java, pero sigue sin ser una solución buena (véase Groovy)
Como siempre (y en este caso también), la recomendación de Scala es... no utilices clases con estado (asignación destructiva). Eso ayuda
¿Y QUÉ PASA CON LAS TUPLAS?
Las tuplas son inmutables (no tienen estado, no tienen asignación destructiva). Empezamos bien
Aunque en el libro no recuerdo haber leído nada al respecto, he podido comprobar que Scala sí crea método de equivalencia y Hash correctamente.
Muy buena noticia
En C++ no tienen esta paranoia
pos eso, ya me diréis como lo veis
He vuelto a leer sobre paralelismo, concurrencia, tolerancia a fallos... y me paso al lado tenebroso...
Programación declarativa, esa es la solución a los problemas de hoy y sobre todo del futuro (a no ser que llegue antes la computación cuántica de forma masiva y todos al paro)
Si me dejáis (es decir, si no recibo cientos de correos pidiendo que no os torture con eso), os iré contando
Por cierto...
¿Alguien se atreve a intentar explicarme cómo se comparan dos objetos en visual basic 6?
Es curiosidad porque no tengo ni idea
martes, enero 08, 2008
Hola, soy informático
Hola, vengo a contarles una cosa humillante acerca de mí: Soy informático.
Como lo oyen informático, y es una cosa de la que me han hecho avergonzarme.
Antes cuando uno decía, “soy informático”, la gente se callaba a tu lado, se notaba la admiración, vamos que te trataban como si cagases nocilla.
Ahora dices soy informático, y te dicen “y ¿a que academia has ido?”, ¡joder señora! un poco de respeto que soy un ingeniero. La verdad que no seria la primera vez que oigo “pero como sois los informáticos, ¡si el ordenador te lo hace todo!”.
Vale nos habéis pillado, pensábamos mantenerlo en secreto mas tiempo, pero es cierto, vuestro PC’s y programas aparecieron de la nada y evolucionan ellos solitos. Una vez conecté un PC a un portátil, y la nueve meses había surgido una grabadora de DVD, ¡y su abuelo es un spectrum que se lo montó con el tocadiscos!
En serio.. ¿conocen alguna profesión menos valorada que la de informático?
Es como si tu trabajo no valiera nada, ¡pepe venga venme a arreglar el ordenador que no te cuesta nada!, me’cago…
Fui a la panadería de mi amigo Juan a ver si eso era en todas las profesiones, y le dije:
-”Juan dame una barra de pan”, y cuando salgo me dice
-”Oye, ¿que no me la vas a pagar?”,
-”Pero coño Juan, no jodas, que a ti no te cuesta nada”
-”¿Pero tu eres gilipollas?”
-”No. ¡¡Soy informático !!”
Y las madres. ¡ay las madres!, quien les explica en que consiste tu trabajo, el otro día fui a verla y me dijo:
-”Hijo, mírame a ver el teléfono qu! e se cayo el otro día y no da línea”
-”Mama si quieres te lo llevo al técnico”
-”Pero hijo, ¡Tu no eres informático!”
Sin más, cuando voy a casa de los padres de mi novia, tengo que estar mirando tostadoras y televisiones que no funcionan bien, yo creo que piensan “hay que vigilar a la niña por que el chico con que esta no sabe nada de informática,… igual trafica con drogas !”.
La verdad que lo peor es cuando te encuentras un amigo por la calle, y te dice “coño, que el ordenador que me compraste hace 5 años, se me ha quedado anticuado, eh, a ver si prestamos mas atención, que yo no puedo tirar el dinero… jeje”, con supuesta ironía cabrona.
OK, ¡la próxima vez intentaré que la informática no avance hasta que te mueras!
Pero este por lo menos sabe que su PC se ha quedado anticuado, la semana pasada, me pidió uno que le pusiera la última tarjeta en 3D, a su 486, cuando le dije que no se podía me dijo:
-”Ah, entiendo, pero me la puedas poner de todas maneras”
-”Pues claro, y después bajo al garaje y te pongo el reactor de un avión en el SEAT panda, ¡Si soy informático!”
En fin, hágame caso, y realicen un oficio que sea respetable, como concursante de Gran Hermano, y a disfrutar de la vida…
La metáfora del arquitecto
RING RING (Suena el teléfono)
- Hola, Jose, qué tal
- Hombreeee, Antonio. Cómo estamos
- Pues mira, te llamo porque quiero comprarme una casa, y como tú eres arquitecto, pues a ver si me puedes aconsejar
- Bueno… a ver. Si quieres quedamos un día y damos una vuelta por unas cuantas immobiliarias, a ver cómo está el panorama
- Cojonodo, tío, ¡luego te invito a una birra eh!
- Vale, pues mañana por la tarde libro, quedamos a las cinco?
- Perfecto, perfecto. Hasta mañana, ¡gracias!
- Veenga, hasta mañana
(AL DÍA SIGUIENTE)
- Bueno, ya hemos visto cuatro o cinco fincas. ¿Qué te parecen?
- No sé, ¿tú qué crees? Como eres el entendido…
- Pues yo de tí me compraba esa casa de cemento, bien situada en la ciudad y que parece acogedora
- ¿De cemento? ¡Pero si yo quiero una casa de papel!
- ¿Pero para qué coño quieres una casa de papel?
- Joder, es lo que tiene todo el mundo, ¿no?
- ¡Pero si son una basura! ¿No me dijiste que precisamente Mariano había perdido la suya durante el último temporal? ¿Que salió volando con todo lo que tenía dentro?
- Es que las casas de cemento son sólo para arquitectos
- ¿Eso no te hace pensar que quizá sean mejores?
- Pero no puedo poner biombos en una casa de cemento, tendría que levantar paredes o tirar muros cuando quiera hacer reformas
- Efectivamente, y eso repercutirá en que tu casa será más segura. ¿No viste que a Luis le entraron hace poco? Se compró una puerta de conglomerado, y un ladrón se la tiró al suelo de una patada
- Mira, dirás lo que quieras, pero yo no me voy a meter en follones. Compraré la casa de papel
- ¿Ni aun a igualdad de precio?
- No
- ¿Entonces para qué quieres mi consejo?
- Nada hombre, te lo agradezco mucho, pero me quedo con la de papel
- En fin…
(AL CABO DE UNA SEMANA)
RIIING
- Hola, ¿Jose?
- Hombre, Antonio, qué tal con tu casa nueva
- Pues de eso te quería hablar. Resulta que quiero poner un par de biombos para separar habitaciones, y te llamaba para ver si me los podrías colocar tú
- ¿Yo? ¿Por qué no llamas al carpintero? ¿No te hicieron un presupuesto global? Puedes decirles que te los coloquen por el mismo precio
- Ya, pero es que me fío más de tí
(Claro, como el día que fuimos a mirar casas)
- Bueeeeno, vale, me pasaré por allí el sábado.
- ¿Puedes traerte biombos de casa?
- ¿Cómorrr?
- Sí, es que como son muy caros pues tú que tienes contactos a ver si puedes robar un par y traérmelos para mí
- ¿No te estás pasando?
- Venga joder, que a tí no te cuesta nada. Si no le digo a mi vecino que me dé un par, que conoce a un tío que se encarga de pillarlos y le salen tirados de precio
- Tú mismo.
(SÁBADO)
- Joder, suerte que vienes, Jose
- ¿Qué pasa?
- Se me ha derrumbado una pared. Es que ayer llovió bastante, se deshizo el papel y me he quedado sin pared
- ¿Te extraña?
- Venga, a ver si me lo puedes arreglar
- (pfffff…) Veré lo que puedo hacer
- Muchas gracias eh, luego te invito a una birra
(LUNES)
RIIING
(Es Antonio… ¿le cojo el teléfono?)
- Jose, Jose
- Quéeeee
- Pues que ayer por la noche mientras estaba en el bar, entró un chorizo en casa y me ha birlado la tele
- ¿Y eso?
- Pues que los biombos que me pasó mi vecino eran robados, y por lo visto alguien tenía una copia de la cerradura
- Normal
- ¿Puedes venir a arreglármelo?
- NO
- Joder tío no seas borde
- SI
- ¿Pero no eres arquitecto? Es que yo no entiendo de esto…
- Ya ví cómo te dejaste aconsejar cuando compraste la casa
- Pero es que yo la quería de papel
- Entonces asume las consecuencias
- Hostia, ¿no me puedes hacer el favor?
- NO. Si quieres te doy el teléfono de una immobiliaria que se dedica cambiar casas de papel por casas de cemento. Necesitarás hacer alguna reforma, pero como mínimo no te entrarán a robar cada dos por tres ni tendrás que contratar vigilancia privada, ni se derrumbará el techo cuando llueva. Tú mismo.
- Vale, vale, ya lo capto. Llamaré a Felipe para que me venga a arreglar el biombo. Muchas gracias por nada, ¿eh?
¿Hay alguna relación con la informática?
http://weblog.topopardo.com/?p=1208
domingo, septiembre 30, 2007
Organismo más dañino de la historia
http://fogonazos.blogspot.com/2007/09/el-organismo-ms-daino-de-la-tierra.html
El organismo más dañino del planeta fue un minúsculo ser humano nacido en algún lugar de Pennsylvania. Hacia 1921 Thomas Midgley era un joven ingeniero que trabajaba para la General Motors en Dayton e investigaba sobre el desarrollo de combustibles. Pronto descubrió que el plomo conseguía reducir el traqueteo de los motores e inventó un compuesto llamado plomo tetraetílico. En pocos años, las grandes compañías de automóviles comenzaron a utilizar su invento para la fabricación de carburantes y lanzaron a la atmósfera toneladas de plomo que perdurarían en el aire durante décadas.
A pesar de conocer su alta toxicidad y de que los trabajadores de las fábricas enfermaban uno tras otro por envenenamiento, Midgley se empeñó en negar la verdad e incluso simuló ante los periodistas que el plomo era perfectamente inocuo. En una rueda de prensa digna de ser recordada, Migdley se roció con plomo por el cuerpo y lo inhaló insistentemente de un bote mientras insistía en que podía hacer aquello todos los días. Por supuesto, cayó enfermo al cabo de unas horas y se mantuvo apartado durante meses de la opinión pública mientras se recuperaba.
Tal vez por su mala conciencia, Midgley trató entonces de encontrar una solución para los gases venenosos que soltaban los frigoríficos de la época. Concienciado por la muerte de cientos de personas, Midgley encontró la alternativa en un gas relativamente estable y que se podía respirar sin problemas: los conocidos como clorofluorocarburos, o CFC, y cuyo papel como principal destructor de la capa de ozono conocemos hoy en día.
Así pues, en apenas 20 años Midgley había propiciado el vertido de miles de toneladas de plomo sobre el planeta y la generación de una cantidad de CFC suficiente para destrozar buena parte de las reservas de ozono. No es de extrañar que, unos años después, un historiador calificara a Midgley como de “el organismo vivo que más impacto ha tenido en la atmósfera en la historia de la Tierra".
Para culminar su historia de despropósitos, en 1940 Midgley contrajo la polio y quedó postrado en la cama. A sus 51 años, el ingeniero se obsequió a sí mismo con una de sus creaciones y diseñó un sistema de poleas y cables para moverse sobre la cama. En 1944, la máquina se puso en marcha y Midgley murió estrangulado por su propio invento.
La historia también se cuenta en Una breve historia de casi todo, de Bill Bryson
El organismo más dañino del planeta fue un minúsculo ser humano nacido en algún lugar de Pennsylvania. Hacia 1921 Thomas Midgley era un joven ingeniero que trabajaba para la General Motors en Dayton e investigaba sobre el desarrollo de combustibles. Pronto descubrió que el plomo conseguía reducir el traqueteo de los motores e inventó un compuesto llamado plomo tetraetílico. En pocos años, las grandes compañías de automóviles comenzaron a utilizar su invento para la fabricación de carburantes y lanzaron a la atmósfera toneladas de plomo que perdurarían en el aire durante décadas.
A pesar de conocer su alta toxicidad y de que los trabajadores de las fábricas enfermaban uno tras otro por envenenamiento, Midgley se empeñó en negar la verdad e incluso simuló ante los periodistas que el plomo era perfectamente inocuo. En una rueda de prensa digna de ser recordada, Migdley se roció con plomo por el cuerpo y lo inhaló insistentemente de un bote mientras insistía en que podía hacer aquello todos los días. Por supuesto, cayó enfermo al cabo de unas horas y se mantuvo apartado durante meses de la opinión pública mientras se recuperaba.
Tal vez por su mala conciencia, Midgley trató entonces de encontrar una solución para los gases venenosos que soltaban los frigoríficos de la época. Concienciado por la muerte de cientos de personas, Midgley encontró la alternativa en un gas relativamente estable y que se podía respirar sin problemas: los conocidos como clorofluorocarburos, o CFC, y cuyo papel como principal destructor de la capa de ozono conocemos hoy en día.
Así pues, en apenas 20 años Midgley había propiciado el vertido de miles de toneladas de plomo sobre el planeta y la generación de una cantidad de CFC suficiente para destrozar buena parte de las reservas de ozono. No es de extrañar que, unos años después, un historiador calificara a Midgley como de “el organismo vivo que más impacto ha tenido en la atmósfera en la historia de la Tierra".
Para culminar su historia de despropósitos, en 1940 Midgley contrajo la polio y quedó postrado en la cama. A sus 51 años, el ingeniero se obsequió a sí mismo con una de sus creaciones y diseñó un sistema de poleas y cables para moverse sobre la cama. En 1944, la máquina se puso en marcha y Midgley murió estrangulado por su propio invento.
La historia también se cuenta en Una breve historia de casi todo, de Bill Bryson
Disparates, conspiraciones
Ya sabemos que la gente está dispuesta a creerse tonterías aplicando el principio opuesto a lo más verosímil es lo más sencillo.
Unos ejemplos...
http://mangasverdes.es/2007/09/26/las-teorias-conspiranoicas-mas-disparatadas/
Unos ejemplos...
http://mangasverdes.es/2007/09/26/las-teorias-conspiranoicas-mas-disparatadas/
Las teorías conspiranoicas más disparatadas
Swallowing the Camel publica una lista de las teorías conspiranoicas más demenciales que ha encontrado. He seleccionado y traducido las que me han parecido más divertidas y disparatadas, que se presentan, al igual que en el original, sin un orden concreto:
- El conductor fue el que mató a John Fitzgerald Kennedy.
- Los Beatles fueron creados por servicio de inteligencia del Gobierno británico para minar la moral de los jóvenes estadounidenses.
- La cruxifición de Jesús fue un montaje, en realidad éste huyó con María Magdalena y uno de ellos o los dos huyeron a Francia para proteger a su familia.
- El virus HIV no provoca el sida.
- El hombre jamás llegó a la Luna, es algo hoy por hoy imposible, aunque sí que hay una base alienígena allí.
- Stephen King asesinó a John Lennon.
- La II Guerra Mundial también fue un montaje, fruto de la conspiración para conducir al mundo hacia el pacifismo.
- La reina Isabel I era un hombre. La verdadera Isabel murió de niña.
- George Bush padre es, en realidad, George Scherff Sr., un nazi adolescente enviado para destruir América bajo la tutela de Prescott Bush. Hitler aún vivía en Montana allá por 1997 y Josef Mengele sobrevive aún gracias a un régimen de hormonas y canibalismo.
- Josef Mengele es Zodiac, el estrangulador de Bostón y el remitente de las cartas con Antrax.
- La emisión de ‘La Guerra de los Mundos’ en 1939 formaba parte de un plan militar financiado por la Fundación Rockefeller y diseñada para averiguar cómo reaccionarían los estadounidenses a una invasión enemiga.
Los judíos beben sangre y comen carne de niños durante la Pascua. - La expedición de Franklin al Ártico no tenía como misión encontrar el Paso del Noroeste. En realidad, era una misión secreta para investigar avistamientos de ovnis de los que se tenía noticia desde el año 1700. Los componentes de la expedición fueron capturados, sometidos a terribles experimentos y finalmente devorados por extraterrestres gigantes.
- Hitler y algunos de sus camaradas huyeron al Ártico en un submarino y viven allí felizmente en el interior de la Tierrra junto a alienígenas superavanzados.
- El aeropuerto internacional de Denver fue construido para ocultar un enorme complejo subterráneo, cuartel general de la elite del ‘nuevo mundo’. Las pistas se encuentran en un mural instalado en el propio aeropuerto.
- Cienciología: Hace mil millones de años el jefe supremo intergaláctico Xenu utilizó una película para lavarnos el cerebro y hacernos creer en las religiones, que también fueron inventadas por él.
- Los jesuitas hundieron el ‘Titanic’ para acabar con varios de los juudíos más poderosos del planeta.
- La temprana Edad Media nunca existió. Todo lo que se dice que ocurrió en esa época, incluyendo a Carlomagno está inventado. En realidad, vivimos en el año 1700.
Suscribirse a:
Entradas (Atom)