sábado, junio 28, 2008

Entrevista Bjarne Stroustrups

http://www.dosideas.com/actualidad/37-actualidad/109-entrevista-a-bjarne-stroustrup-creador-de-c.html


Escrito por Leonardo De Seta
Miércoles 25 de Junio de 2008 22:02
retrato de Bjarne Stroustrup

Bjarne Stroustrup es un científico en computación y Catedrático de Ciencias de la Computación en la Universidad A&M de Texas. Es reconocido mundialmente por ser el creador del lenguaje de programación C++.

Stroustrup es un cand. scient. (el equivalente danés a un máster) en matemática y ciencias de la computación (1979) por la Universidad Aarhus, Deinamarca, y Doctor en ciencias de la computación (1979) por la Univesidad de Cambridge, Inglaterra. Anteriormente trabajó a la cabeza del departamenteo de Investigación en Programación de los laboratorios Bell de AT&T, desde su creación hasta finales de 2002.

En esta entrevista, Bjarne Stroustrup nos cuenta todo sobre el diseño y desarrollo de C++, los garbage collectors, el futuro de C++ y el rol de la barba en la creación de lenguajes de programación exitosos.

Computerworld publicó recientemente esta excelente entrevista a Bjarne Stroustrup (en inglés), como parte de su serie "The A-Z of Programming Languages". A continuación una traducción al castellano con lo destacado de la nota.
¿Qué lo motivó para desarrollar C++?

Necesitaba una herramienta para diseñar e implementar una versión distribuida del kernel de Unix. En ese momento, 1979, no existía dicha herramienta. Necesitaba algo que pudiera expresar la estructura del programa, manipulara directamente el hardware, y que sea lo suficientemente eficiente y portable para programación de sistemas importantes.

Pueden encontrar más información y detalles acerda del diseño y evolución de C++ en mi notas de HOPL (Histoy of Programming Languages - Historia de los Lenguajes de Programación), las cuales pueden encontrar en mi página personal y en mi libro "El Diseño y Evolución de C++".
¿Qué problemas específicos intentaba resolver?

Los dos problemas que me vienen a la mente eran poder simular la infraestructura de comunicación inter-procesos para un sistema distribuido o un sistema de memoria compartida (para determinar qué servicios del Sistema Operativo podríamos correr en cada procesador por separado); y el escribir los drivers de red para este sistema. Obviamente, como Unix estaba escrito en C, también quería un alto grado de compatiblidad con C. Muy tempranamente, desde 1980 en adelante, fue utilizado por otras personas (con mi ayuda) para simular distintos protocolos de red y altoritmos de gestión de tráfico.
¿De dónde proviene el nombre de C++?

Mientras "C con Clases" (el ancestro de C++) se volvia popular dentro de Bell Labs, algunas personas pensaban que era un nombre demasiado largo y comenzaron a llamarlo "C". Esto significaba que tenían que aclarar a lo que se referián cuando necesitaban distinguirlo del lenguaje de Dennis Rithcie, al cual llamaban "Viejo C", "C original", y así. Algunos pensaban que era una falta de respeto hacia Dennis (ni él ni yo lo sentiamos así) y un día recibí un "pedido" de Bell Labs para que le cambiara el nombre. Como resultado, lo nombramos C84 por un tiempo. Este cambio no ayudó demasiado, así que pedí ayuda por sugerencias y elegí C++ de una lista de candidatos. Todos están de acuerdo que, semánticamente hablando, ++C hubiera sido todavía mejor, pero habría ocasionado demasiados problemas para quienes no conocen la sintaxis.
¿Hubo algún problema particularmente dificil o frustrante que hubo que superar durante la creación del lenguaje?

Montones! Para empezar, ¿cuales deberían ser las reglas fundamentales del lenguaje? ¿Qué debía estar en el lenguaje, y que debia quedar afuera? La mayoría quiere un lenguaje pequeño que brinde todas las características que encuentran útil en el resto de los lenguajes. Desafortunadamente, eso es imposible.

Luego de un corto tiempo de confiar en la suerte y el buen gusto, me decidí por un grupo de "reglas a ojo" que pretendian asegurar que los programas en C++ fueran a la vez elegantes (como en Simula67, el lenguaje que presentó la programación orientada a objetos) y efcientes para la programación de sistemas (como C). Obviamente, no todos los programas logran ambas cosas, pero la idea era (y es) lograr que un desarrollador competente pueda expresar practicamente cualquier idea directamente y lograr su ejecución con un mínimo overhead (cero overheads comparando contra una versión en C).

Convencer a la comunidad de programadores del valor del chequeo de tipos fue sorprendemente dificil. La idea de chequear los argumentos de una función contra una delcaración de la función fue resistida fuertemente - al menos hasta que C adoptó la idea.

En la actualidad la programación orientada a objetos está por todos lados, por lo que a las personas les cuesta creer que me fue imposible convencer a las personas de su utilidad hasta que finalmente agregué funciones virtuales y demostré que eran lo suficientemente rápidas para usos muy demandantes. El enfoque de C++ hacia la Programación Orientada a Objetos fue (y es) básicamente el mismo que Simula, con simplificaciones y mejores de peformance.

La compatibilidad con C fue (y es) una gran fuente de problemas y fortalezas. Al ser compatible con C, los desarrolladores de C++ tenian garantizada una gran cantidad de características que usualmente faltan en las primeras versiones de los lenguajes, y acceso directo (y efeciente) a una gran cantidad de código - no sólo código en C, sino también en Fortran y más ya que las convenciones de llamadas de C eran simples y similares a las que soportaban otros lenguajes. Después de todo, como solía decir, la reutilización comienza por utilizar algo que ya existe, en vez de esperar que alguien desarrolle nuevos componentes reutilizables. Por otro lado, C tiene varias vueltas sintácticas y semánticas, por lo que seguir a la par de C mientras fue evolucionando no es tarea fácil.
¿Cuáles son las principales diferencias entre C con Clases y C++?

La mayoría de las diferencias estuvieron en la técnica de implementación. C con Clases se implentó con un preprocesador, mientras que C++ requiere un compilador apropiado (por lo cual escribí uno). Era facil transcribir programas en C con Clases hacia C++, pero los lenguajes no eran 100% compatibles. Desde un punto de vista del lenguaje, la mayor mejora fue la incorporación de funciones virtuales, lo cual permitió la programación orientada a objetos clásica. También se agregó la sobrecarga (incluyendo la sobrecarga de operadores). Vale destacar que las características fundamentales de C++ para la gestión de recursos generales, constructores y destructores ya se encontraban en las primeras versiones de C con Clases. Por otro lado, los templates (y las excepciones) se añadieron en versiones algo posteriores de C++ (1989); antes de esto, soliamos usar macros para expresar ideas generales de programación.
¿Qué hubiera hecho diferente en el desarrollo de C++ si hubiera tenido la oportunidad?

Esta pregunta es un poco injusto porque, por supuesto, no tenía el beneficio de casi 30 años de experiencia con C++, y mucho de lo que sé actualmente es el resultado de experimentar con versiones anteriores de C++. Por otro lado, en aquel entonces básicamente no tenía recursos (sólo yo y mi tiempo libre), por lo tanto si dijera (correctamente) que las funciones virtuales, los templates (con "conceptos", tal como los ofrece C++0x) y las excepciones hubieran hecho de C++85 un mejor lenguaje, estaría no sólo sugiriendo algo que no hubiera sabido diseñar en 1980, sino también que, aunque hubiera encontrado el diseño perfecto de forma mágica, no lo hubiera podido implementar en un tiempo razonable.

Creo que hubiera sido posible lanzar una mejor librería estandard en 1985 junto a C++ 1.0, la cual hubiera mejorado mucho con el tiempo. Con "mejor librería" me refiero a una librería con clases que incluyeran una mejora versión de funciones para soportar concurrencia y un set de clases de containers.

Más tarde, hubiera desarrrolaldo templates (claves para el estilo de programación genérico de C++) antes que herencia múltiple (no una gran característica, como muchos la consideran), y hubiera hecho más énfasis en las excepciones.
¿Como se sintió cuando C++ logró la estandarización en 1998, y cómo participó del proceso de estandarización?

Trabajé duro en la estandarización durante años (1989-1997); ahora estoy trabajando en el sucesor del estándard: C++0x. Evitar que un lenguaje popular se fragmente en dialectos es una tarea dificil y esencial. C++ no tiene un dueño o un "papá rico" para brindar fuerza de desarrollo, librerías "gratis" y marketing. El comité de estandarización ISO fue esencial para el crecimiento de la comunidad de C++.
¿Cuál fue el programa más interesate que escribió en C++?

No puedo elegir uno, y en general no pienso en los programas como "interesantes". Me fijo más en los sistemas completos, de los cuales algunas partes están escritos en C++. Entre estos me vienen a la mente el sub-sistema de manejo autónomo del Mars Rover de la NASA, el motor de búsqueda de Google, y el sistema de reservas de vuelos de Amadeus. Mirando el código aislado, creo que la librería STL de Alexander Stepanov (containers, iteradores, y librerias parte de la librería estándard de C++) está entre las porciones de código más interesantes, útiles e influeyentes para C++ que haya visto.
¿Alguna vez vio al lenguaje utilizarse para algo que no fue originalmente planeado?

Diseñé C++ para la generalidad. Es decir, las características que tiene fueron deliberadamente diseñadas para hacer cosas que no me podía imaginar. Además, las facilidades de abstracción de C++ (por ejemplo, clases y templates) fueron diseñadas para ser rápidas cuando son usadas en hardware convencional, de forma que las pesonas pudieran construir las abstracciones básicas que necesitaran para un área de aplicación determinada (como ser números complejos y manejadores de recursos) dentro del lenguaje.

Entonces, si, vi utilizar a C++ para muchas cosas que no hubiera pensado, y ser usado de muchas formas que no anticipé, pero en general no estoy completamente sorprendido.

Muchas veces me desespera ver los intentos de forzar C++ en un molde que no encaja simplemente porque alguien no se molestó en aprender lo básico de C++. Por supuesto, las personas que hacen esto no creen que están actuando irracionalmente; en cambio, piensan que saben cómo programar y que no hay nada nuevo o diferente acerca de C++ que requiera que cambien sus hábitos y aprendan "trucos nuevos". Estas personas estructuran su código como lo harían, por ejemplo, para C o para Java, y luego se sorprenden cuando C++ no funciona como esperan. Algunos hasta se enojan mucho, aunque no entiendo porqué deberían enojarse al darse cuenta que tienen que tener más cuidado con el sistema de tipos en C++ que en C, o que no hay una companía brindando librerias "gratis" y "estándard" para C++ como lo hay en Java. Para usar C++ bien se tiene que utilizar el sistema de tipos, y se tienen que buscar librerias. Intentar construir una aplicación directamente con C++ a secas, o usando sólo las librerías estándard, es una pérdida de tiempo y esfuerzo.
Parece que una gran cantidad de programadores nunca usaron los templates, incluso aunque sean programadores C++

Puede ser cierto esto, pero yo creo que al menos la mayoría utilizan los templates a través de STL (u otras librerías similares), y que la cantidad de programadores que evitan los templates va en disminuación.
¿Por qué cree que ocurre esto?

Por miedo a algo que es diferente a lo que ya conocen, rumores de complicaciones en el código, problemas de linking, y mensajes de error espectacularmente malos.
¿Alguna vez deseó que el compilador GNU C++ hubiera mostrado errores de compilación más cortos, para que no ahuyentara a estudiantes?

Por supuesto, pero no es todo culpa del GCC. El problema fundamental es que C++98 no tiene una forma para que el programador indique de manera directa los requerimientos de un template en los tipos de argumentos. Esta es una debilidad del lenguaje, no del compilador, y sólo puede resolverse completamente con un cambio en el lenguaje, el cual será parte de C++0x.

Me estoy refiriendo a los "conceptos", los cuales serán parte de C++0x. Para más detalles, vean mis notas sobre C++0x. Hasta que los "conceptos" estén disponibles para todos, se pueden usar "constrains classes" para mejorar los chequeos; vean mi FAQ técnico para más información.
En los últimos años se está viendo que el procesamiento distribuido está más al alcance del programador promedio. ¿Cómo afectará esto a C++?

Es dificil de saber, pero antes de entrar en la programación distribuido un lenguaje tiene que soportar concurrencia y poder tratar más que el modelo de memoria tradicional "plano/uniforme". C++0x hace exactamente esto. El modelo de memoria, tipos atómicos, y el almacenamiento local de hilos brindan las garantías básicas para soportar una buena librería de hilos. En resumen, C++0x permite un uso eficiente de multi-núcleos.

Por supuesto que no es necesario esperar a C++0x para hacer programación concurrente en C++. Las personas hicieron esto durante años, y la mayor parte de lo que el nuevo estándard ofrece ya existe actualmente en otras formas.
¿Ve esto como una tendencia a la creación de una nueva generación de lenguajes de propósito general?

Muchos de los lenguajes "de scripting" brindan utilidades para manipular el estado de entorno Web, y allí reside su verdera potencia. La manipulación simple de texto se logra bastante facilmente con librerias, como las nuevas librerías de expresiones regulares de C++ (disponibles hoy en boost.org), pero es dificil concebir un lenguaje que es tanto de propósito general como distribuido. La raíz del problema es que los lenguajes distribuidos prácticos utilizan la simplificación y la especialización. Un lenguaje de propósito general no puede proveer un único modelo distribuido de alto nivel.

No veo una razón importante que impidan que un lenguaje de propósito general crezca con utilidades para distribución. Sin embargo, yo sostengo (sin éxito) que C++0x debería hacer exactamente esto. Creo que eventualmente todos los principales lenguajes van a proveer algún tipo de soporte para la distribución, a través de una combinación de soporte directo del lenguaje, soporte en tiempo de ejecución, o librerias.
En su opinión, ¿qué aporte perdurable en el tiempo le dio C++ al desarrollo de sistemas?

C++ llevó la programación orientada a objetos al público general, y está haciendo lo mismo para la programación genérica.

Si se mira a algunos de los programas más exitosos de C++, especialmente los relacionados a la gestión de recursos, se tiende a encontrar que los destructores son fundamentales e indispensables en su diseño. Creo que los destructores serán vistos como la contribución más importante - todo lo demás depende en una combinación de características del lenguaje y técnicas para soportar un estilo de programación, o combinación de estilos.

Otra aporte del legado de C++ es que hizo que la abstracción sea manejable y posible de realizar en áreas aplicativas donde las personas necesitan programar en lenguaje de máquina directamente, como con bits, bytes, words y direcciones.

En el futuro, apunto a lograr una mayor integración entre la orientación a objetos y la programación genérica, y una mejor articulación entre los ideales de generalidad, elegancia y eficiencia.
¿Por dónde cree que pasará el futuro de C++?

Por la misma parte en la que C++ tuvo su mayor fuerza desde el primer día: aplicaciones con componentes críticos de sistema, especialmente la provisión de infraestructura. Actualmente, casi todas las infraestructuras (incluyendo la implementación de lengujaes de más alto nivel) están bajo C++ (o C), y creo que seguirá siendo así. También, la programación de sistemas embebidos es una área importante de crecimiento para C++; por ejemplo, el software para la próxima generación de aviones de combate de Estados Unidos está escrito en C++ (vean las Reglas de codificación JSF++ en mi página). C++ brinda lo mejor cuando se necesita simultáneamente alta performance y alto nivel de abstracción, especialmente bajo retricciones de recursos. Casualmente, esta descripción encaja tanto para el iPod como para una aplicación científica de gran escala.
¿Lo sorprendió la evolución y popularidad del lenguaje?

Nadie, con la posible excepción de Al Aho, pudo prever la magnitud del éxito de C++. Supongo que durante los años '80 estaba demasiado ocupado para sorprenderme: el uso de C++ se duplicaba cada 7.5 meses, como calculé más tarde - y todo esto se logró sin un departamente de marketing dedicado, casi sin personas, y un presupuesto prácticamente nulo. Apunté a lograr generalidad y eficiente, y tuve éxito más allá de cualquier expectativa.

Por cierto, cada tanto me encuentro con personas que asumen que, porque alago de C++ y lo dfiendo de sus detractores, pienso que es perfecto. Esto es obviamente absurdo. C++ tiene un montón de debilidades - y las conoczco mejor que nadie - pero el objetivo de realizar el diseño y la implementación no era no cometer errores (esto es imposible en un proyecto tan grande, y bajo tales restricciones Draconianas). El objetivo era crear una herramienta que, en manos competentes, sea efectiva para la construcción de sistemas importantes para el mundo real. En esto, creo que tuvo éxito más allá de mis mayores expectativas.
¿Qué le responde a las críticas del lenguaje, como que heredó todas las falencias de C y que tiene una enorme cantidad de caracertísticas que lo hacen "complicado"?

C++ heredó las debilidades y fortalezas de C, y creo que hicimos un buen trabajo en compensar las debilidades sin comprometer las fortalezas. C no es un lenguaje simple (el estándard ISO tiene más de 500 páginas), y la mayoría de los lenguajes modernos son más grandes aún. Obviamente, C++ (como C) es "complicado" comparado con otros lenguajes de juguete, pero realmente no es tan grande al compararlo con otros lenguajes modernos. Hay razones prácticas y sólidas de porqué todos los lenguajes actuales que se usan para trabajo industrial serio son "complicados": las tareas que deben resolver son enormes y de una complejidad más allá de la imaginación.

Otra razón para el tamaño "incómodo" de los lenguajes actuales es su necesidad de ser estables. Escribí código en C++ hace 20 años que aún hoy corre, y estoy seguro que seguirá compilando dentro de otros 20 años. Quienes construyen proyectos de infraestructura grandes necesitan esta estabilidad. Sin embargo, para mantenerse modernos y poder enfrentar nuevos desafios, los lenguajes deben crecer (tanto en características del lenguaje como en librerías base), pero si quitás algo, rompés el código. Por lo tanto, los lenguajes que se construyen pensando en serio en los usuarios (como C++ y C) tienden a mantener características durante décadas, y tienden a "complicarse". La alternativa son lenguajes hermosos para los cuales hay que re-escribir el código cada 5 años.

Por último, C++ soportó explícticamente y desde el primer día más de un estilo de programación, y una interacción entre estos estilos. Si pensás que existe un único estilo de programación que es el mejor para todas las personas y aplicaciones (por ejemplo, la programación orientada a objetos), entonces ahí tenés una oportunidad para lograr simplificación. Sin embargo, yo creo fervientemente que la mejor solución (la más legile, mantenible, eficiente, etc) requieren más de un estilo de programación. Por lo tanto, el tamaño de C++ no puede ser reducido mediante el soporte de un único estilo de programación. El uso combinado de diferentes estilos es clave en mi visión de C++, y una gran parte de su fortaleza proviene de aquí.
¿De qué está más orgulloso, en términos del desarrollo inicial del lenguaje y su uso continuado?

Estoy orgulloso de que se haya utilizado a C++ para tantas aplicaciones que hicieron del mundo un lugar mejor. A través de C++ pude realizar una pequeña contribución al proyecto del Genoma Humano, a proyectos de física (C++ se utiliza en el CERN, Fermilab, SLAC, etc), exploración espacial, energía eólica, etc. Pueden ver una pequeña lista de aplicaciones C++ en mi página. Siempre me pone feliz cuando escucho que el lenguaje está siendo usado para algo bueno.

Segundo, estoy orgulloso de que C++ haya ayudado a mejorar la calidad del código en general, no sólo dentro de C++. Los lenguajes más nuevos, como Java y C#, utilizan técnicas que C++ hizo que fueran posibles para el uso en el mundo real, y comparado con el código de 20 años atrás muchos sistemas en los que dependemos actualmente son increiblemente confiables y fueron construidos bajo un presupuesto restringido. Obviamente, podemos y debemos hacer mejor, pero podemos sentirnos orgullosos del camino que recorrimos hasta ahora.

En términos de una contribución directa y personal, estoy contento de haber escrito el primer compilador C++, Cfont, para poder compilar programas para el mundo real en máquinas de 1MHz con 1MB de memoria. Esto es increiblemente pequeño hoy en día, pero esto fue lo que se necesitó en su momento para comenzar con los lenguajes de alto nivel en las primeras PC. Cfront fue escrito en C con Clases y luego pasado a C++.
¿Hacia dónde le parece se encaminan los lenguajes de programación en el futuro?

"Es dificil realizar predicciones, en especial sobre el futuro". Obviamente, no lo sé, pero espero ver lenguajes de programación generales con mejores mecanismos de abstracción, mejor controles de tipos, y mejores facilidades para utilizar concurrencia. Espero que C++ sea uno de estos lenguajes. Van a existir infraestructuras y lenguajes corporativos complicados; va a aparecer toda una serie de lenguajes para dominios específicos, y existirán lenguajes tal como hoy que persisten sin cambios en algunos nichos. Nótese que estoy asumiendo una evolución importante de C++, más allá de C++0x. Creo que la comunidad de C++ es demasiado grande y activa como para que el lenguaje y su librería estándard se queden estáticas.
¿Tiene algún consejo para los futuros programadores?

Conozan las bases de la ciencia de la computación: algoritmos, arquitectura de máquinas, estructuras de datos, etc. No copien técnicas a ciegas de aplicación a aplicación. Sepan lo que están haciendo, cómo y porqué funciona. No crean que van a a saber cómo será la industria en 5 años o qué estarán haciendo entonces, así que creen y ármanse un portfolio de habilidades generales y útiles. Intenten escribir mejor código. Trabajen para hacer de la programación una actividad más profesional y menos de "hacking" de bajo nivel (la programación también es un arte, pero no sólo es un arte). Aprendan de los libros clásicos en el área y de manuales más avanzados; no se conformen con las simples guías de "cómo hacer" y la documentación online: en general, no es profunda.
Hay una sección en su página dedicada al "¿Realmente dijo eso?". ¿Qué frase de ahí lo persigue más?

No me siento perseguido. Posteo estas frases porque me siguen preguntando por ellas, así que prefiero aclarar la situación directamente. "C++ hace que sea más dificil dispararte en el pie, pero cuando lo hacés te vuela la pierna completa", generalmente se cita como una frase hostil hacia C++. Esto es llanamente inmaduro. Todas las herramientas poderosas pueden causar problemas si se usan mal, y se debe tener más cuidado que con herramientas menos potentes. Se puede realizar más daño (a uno y a otros) con un auto que con una bicicleta, con una sierra electrica que con un serrucho, etc. Esto es también cierto para otros lenguajes modernos: por ejemplo, es trivial causar problemas de memoria con Java. Los lenguajes modernos son herramientas potentes. Esta es la razón por la cual hay que tratarlas con respeto, y los programadores deben encarar sus tareas de manera profesional. Y no es un motivo para evitarlas, ya que las alternativas "más simples" son peores aún.
Llegó el momento para la pregunta obligada sobre los garbage collectors (GC). ¿Por qué las personas están tan interesadas en este aspecto?

Porque la gestión de recursos es la tarea más importante, porque algunos personas piensan (incorrectamente) que un GC es un signo de programación descuidada, y porque algunos personas piensan (incorrectamente) que los GC distinguen a los lenguajes buenos de los inferiores. Mi opinión sobre los GC es que pueden ser una herramienta muy útil, pero no son necesarios ni apropiados para todos los programas, por lo que un GC debería ser algo que se pueda utilizar opcionalmente en C++. C++0x refleja esta visión.

Mi visión de los GC es que yo creo que son la última aternativa para la administración de recursos, no la primera, y que es una herramienta más entre tantas otras para el diseño de un sistema, y no una herramienta fundamental para simplificar la programación.
¿Cómo recomienda que se administre la memoria en C++?

Mi recomendación es ver a la memoria como un recurso más entre otros (hilos, bloqueos, archivos, sockets), y representar cualquier recurso como un objeto de dicha clase. Por ejemplo, la memoria puede ser usada para mantener elementos de un container o caracteres de un string, por lo que debemos usar tipos como vector en lugar de hacernos lio con estructuras de bajo nivel (como ser un array de punteros a arrays terminados con cero) y manejar explíticamente la memoria. Aquí, tanto el vector como los string pueden ser manipuladores de recursos que automáticamente administran el recurso.

Cuando sea posible, recomiendo usar estos "manipuladores de recursos" como variables con alcance (scope) restringido. En este caso, no hay un uso incorrecto de gestión de memoria que el programador pueda hacer mal. Cuando la vida de un objeto no puede ser acotada, recomiendo otros esquemas simples, como el uso de punteros "inteligentes" (provsitos en C++0x), o representar la propiedad como miembro de una colección. Estas técnicas tienen la ventaja de que aplican uniformemente a todo tipo de recursos, y se integran bien con varios y distintos enfoques para administrar errores.

Sólo cuando estos enfoques se torna inmanejables, utilizaría un GC. Desafortunadamente, estas situaciones también son comunes, por lo que un GC sería una muy buena opción aunque no se integre limpiamente con la gestión de recursos generales. También, los GC se puede convertirse en un excelente detector de leaks si se les indica que informen sobre la basura encontrada.

Cuando se usa una gestión de recursos acotada y containers, se genera muy poca "basura" y un GC se torna en algo rápido. Este asunto está detrás de mi opinión "C++ es mi lenguaje de GC favorito porque genera muy poca basura".

Esperaba que un GC pudiera ser opcionalmente habilitado en C++0x, pero hubo muchos problemas técnicos así que tuve que conformarme con una especificación sobre cómo debería integrarse un GC al lenguaje, si fuera provisto. Como con casi todo respecto a C++0x, existe una implementación experimental.

Hay muchos más aspectos de GC más allá de los mencionados aquí, pero bueno, esto es una entrevista, no un libro.
En un lado ya menos serio, ¿cree que la barba está relacionada con el grado de éxito de los lenguajes de programación?

Supongo que si lo miramos filosóficamente todo está relacionado de alguna manera, pero en este caso fueron sólo el humor y la moda de esa época. Toda una generación anterior de diseñadores de lenguajes exitosos usaban barba: Backus (Fortran), Hopper (COBOL), y McCarthy (Lisp), como también Dahl y Nygaard (Simula y la Programación Orientada a Objetos).. En mi caso, soy pragmático: mientras vivía en climas más frios (Dinamarca, Inglaterra y New Jersey) usaba barba; ahora vivo en lugares cálidos, Texas, y decido no sufrir con una barba.
Por último, ¿hay algo más que quisiera agregar?

Si, creo que debemos considerar la relación entre las ideas y la educación. Toqué este tema más arriba, pero el problema de enseñar C++ a las personas y cómo usarlo bien resultó ser un tema tan dificil como diseñar e implementar el lenguaje. No tiene sentido hacer un buen trabajo técnico y no contarle a las personas. Por si mismas, las características de un lenguaje son estériles y aburridas; para que sean útiles, los programadores tienen que aprender cómo se pueden usar estas características de forma de cumplir algún ideal de programación, como ser la orientación a objetos o la programación generica.

Por supuesto que llevo escritos muchos documentos meramente técnicos, pero mucho de mi trabajo está apuntado a elevar el nivel de abstracción de los programaas, a mejorar la calidad de código, y a explicarle a las pesonas cómo funcionan las cosas, y porqué. Pedirle a un programador a que haga algo sin explicarle el motivo es tratarlo como si fueran chicos: deberían sentirse ofendidos por esto. Mis ediciones de "The C++ Programming Language", D&E, "Teaching Standard C++ as a New Language", y mis notas HOPL, son todos mis intentos de relacionar mejor mis ideales para C++, y de ayudar a madurar a la comunidad de C++. Por supesto que esto fue tan sólo exitoso en parte: todavía hay mucha programación de "cortar y pegar", código C++ de baja calidad, pero me siento alentado por la cantidad de buen código y la calidad de los sistemas producidos.

Últimamente, me fui desplazando de la industria hacia la academia, y ahora veo a los problemas educativos desde otro ángulo. Necesitamos mejorar la educación de nuestros desarrolladores de software. En los últimos 3 años, desarrollé un nuevo curso para principiantes (estudiantes de primer año, a menudo programadores por primera vez). Esto me dio la oportunidad de llegarle a una audiencia que antes no conocia. El resultado de esto es el libro "Programming: Principles and Practice using C++", que estará disponible en Octubre.

Picaduras mosquitos

http://cosasmiasyotroscuentos.blogspot.com/2007/08/pican-pican-los-mosquitos.html


"¿Se acuerdan de esa canción que dice "Pican, pican los mosquitos/pican con gran disimulo. /Unos pican en la espalda/ otros pican en. . . "? Es mentira. Los mosquitos no pican. Pican las mosquitas.
En los charcos o en cualquier lugar donde se acumule un poco de agua, casi seguro que aparecen unas pequeñas balsas, que si uno las mira de cerca, están formadas por pequeños huevos, pegados unos a otros. Si nada se los come, y si el charco no se seca, de ellos acaban saliendo unas larvas bastante raras : son como tubos, que en una punta tienen una cabeza. "Cuelgan" de la superficie del agua, y de vez en cuando se desprenden y, sacudiéndose, van al fondo, o cambian de lugar. Por el tubito que las une a la superficie, entra el aire que respiran. Los pelos que salen de su cuerpo, le sirven para flotar. Algunas comen algas, y otras, comen larvas, o cualquier animalito que tenga el tamaño apropiado. Y a su vez, son comidas por peces, y por insectos más grandes que ellas.
A los pocos días, se transforman en ninfas. Siguen flotando justo bajo la superficie, pero ahora los tubos por los cuales respiran salen del medio del cuerpo. Si una las mira con atención, ve que están apareciendo cosas que no estaban en la larva. Y ahora. . . ¡el gran final! Tres o cuatro días después de transformada en ninfa, unos ocho después de puestos los huevos (si hace frío, tardan más) la criatura muda, es decir, su piel se abre. Y algo sale de ella, un insecto que queda parado sobre los restos de su antiguo cuerpo, que flotan en el agua. Extiende un par de pequeñas alas y recién ahora nos damos cuenta de que es. . . ¡un mosquito!
Los mosquitos son dípteros, es decir, insectos con dos alas, como las moscas. Sólo que, a la hora de alimentarse, no andan por ahí, chupando lo que encuentran. Son mucho más especiales que eso. Los mosquitos machos, se alimentan de jugos vegetales. Son chupadores, sin causar mayores molestias a nadie. El menú de las damas Es cosa bien distinta : chupan sangre caliente, de mamífero. Para ello, las partes que forman la boca, llamadas apéndices, se han modificado, formando una serie de tubos que perforan y taladran la piel. Los más finos entran a través de ese agujero, hasta la sangre, y la chupan. ¿Por qué pican las picaduras? Porque al picar, la hembra nos inyecta un líquido que es venenoso. Y nuestro cuerpo responde a esa minúscula gota de veneno, enviando más sangre a la zona, para neutralizarla. Y exactamente eso es lo que favorece al mosquito : la sangre, su alimento, viene a él, en cantidades. La sirve a la hembra para madurar los huevos, esos mismos que después veremos flotar sobre las charcas.
Las partes que forman el aparato bucal de los insectos, llamados apéndices bucales, en el mosquito se unen para formar un aparato que sirve a la vez para agujerear, inyectar saliva y chupar. Las vainas de afueras se pliegan al picar, dejando pasan las perforantes a través de la piel. Una forma de distinguir a los mosquitos, es por como se posan. Los Anofeles lo hacen con el abdomen apuntando para arriba, y los Culex (se llaman así) con el abdomen para abajo.
Como comen cosas diferentes, viven en lugares distintos. Esas nubes de insectos que zumban al volar, y que podés ver sobre los baldíos, son los machos. Con ese zumbido, atraen a las hembras, que permanecen posadas cerca de sus víctimas. Si pican a seres humanos, deben estar dentro de las casas. Así que viven separados. Cuando una hembra siente el zumbido, vuela hacia la nube de machos, y se va con uno. Así de fácil. La hembra entonces busca un lugar con agua para poner los huevos, y los deja allí. Ya no se volverá a ocupar de ellos : irá a "cargar" sangre, conseguirá otro macho, y otra vez a poner huevos. todo el verano hará ese trabajo. Al comenzar el frío Termina tanta actividad : buscan un lugar reparado (una cueva, un sótano) se posan en sus paredes y techo, y se aletargan durante el invierno. Este letargo puede compararse con un sueño profundo. Se detienen todas las funciones vitales, el mosquito no se mueve, apenas respira. . . y "aguanta" así hasta que pasa el frío. (...)
Las picaduras de los mosquitos son molestas. Pero ese no es el único problema. Junto con la saliva que inyectan en nosotros, suelen ir organismos que provocan enfermedades. La malaria, por ejemplo, es transmitida por un mosquito llamado Anofeles . Esta enfermedad la producen unos pequeños seres unicelulares. Estos viven en los glóbulos rojos de los seres humanos. Así que cuando un mosquito pica a una persona enferma, después contagia a las que usa para alimentarse. Y esta es la única manera en que se transmite la enfermedad. Otra enfermedad que transmiten es el paludismo. La única manera de evitar contagiarse es, en zonas en que alguna de estas enfermedades existe, mantener alejados a los mosquitos. O matarlos. Pero para eso hay que usar venenos, que por lo general terminan también con otros seres vivos.(www.infoplagas.com)

"Las picaduras de mosquitos causan manifestaciones cutáneas inmediatas y tardías. La reacción inmediata suele consistir en un enrojecimiento más o menos grande que aparece a los pocos minutos de la picadura y desaparece a las pocas horas para dejar paso a una pápula (abultamiento ) pruriginosa (que pica mucho) que aparece entre las 2-6 horas posteriores y dura entre 1-2 días, aunque en algunos sujetos puede permanecer durante más tiempo (varios días o incluso semanas).Tras sucesivas picaduras, los lugares de antiguas picadas, pueden mostrar una reactivación en forma de ronchas que pican mucho, lo cual da como consecuencia la aparición del denominado prúrigo agudo o urticaria papulosa, muy común en niños. "(www.yahoo.com)

Pican a unos sí y otros no porque "algunas personas emiten ciertos olores que evitan que los mosquitos los encuentren... Principalmente estas sustancias que estas personas emiten ocultan a las demás, las cuales son las que atraen a los mosquitos." (http://granimpetu.com/)

Hay especies, como el flebotomo, en las que la hembra muere después de picar una sola vez.

Los criaderos se evitan impidiendo "que se acumule el agua limpia proveniente de la lluvia, de las tuberías e incluso de las fosas desbordadas que llegan a sedimentar y producen acumulos de agua limpia que quedan a expensas de los mosquitos. Los criaderos más frecuentes de los Aedes aegypti suelen estar en los tanques llenos de agua para el consumo doméstico ya sea en los techos o en los bajos de las viviendas, además de otros depósitos artificiales dispuestos en torno al hogar como tinas, cisternas, tubos de cercas y bebederos de animales. Otros pueden estar en depósitos naturales como los huecos de los árboles y charcos.
Para detectar los criaderos se requiere de una revisión exhaustiva y sistemática pues no siempre son evidentes a simple vista y pueden surgir de improviso, sobre todo después de la lluvia. De modo que para eliminarlos se necesita drenar las acumulaciones de agua, rellenar los huecos con tierra o cemento y eliminar cualquier depósito innecesario que pueda eventualmente llenarse de agua.
Cuando es indispensable reservar agua para el consumo es necesario que el recipiente se mantenga herméticamente tapado y considerar además las medidas contra el huevo y la larva de forma sistemática para que este recipiente no se convierta en un criadero potencial.
Los huevos pueden ser destruidos mecánicamente restregando la superficie del depósito con un cepillo o estropajo duro; no es efectivo hacerlo con las manos. Este método es útil en caso de vasos espirituales y bebederos de animales que están permanentemente expuestos y es fácil su higienización al menos cada dos días.
Cuando la superficie de los recipientes es porosa, extensa o se dificulta su higienización se puede recurrir al flameado. Un lápiz de crayola sirve para marcar con una cruz los límites del área a flamear, luego se derrama alcohol en el interior terminando en un chorro fuera del recipiente por donde se acerca un fósforo encendido, para no exponer las manos de la persona a la súbita llamarada. Cuando la marca de crayola se derrite es señal de que se ha alcanzado la temperatura suficiente para quemar los huevos. Es conveniente flamear todos los depósitos que contengan o puedan contener agua, previendo la existencia de huevos residuales de mosquitos que hayan resistido la desecación durante varios meses y que se encuentran a la espera del agua para la eclosión. "(www.sld.cu/saludvida/)

Espero que difundiendo información acerca del enemigo y los modos de extinción, haya consumado una aceptable venganza... ¡Qué hija de puta! ¡Cómo me ha dejado!

martes, junio 24, 2008

paralelismo erlang y scala (eng)

http://www.infoq.com/news/2008/06/scala-vs-erlang


There has been a somewhat heated debate about Scala vs. Erlang on the blogosphere recently. The future will be multi-cored, and the question is how the multi-core crises will be solved. Scala and Erlang are two languages that aspire to be the solution, but they are a bit different. What are the pros and cons with their approaches?

The problem

Moore’s law has changed. We don’t get the same increase in clock frequency as we used to. Instead, we get more cores. Today, even your laptop probably has two cores.

To utilize more than one core, your application has to be concurrency-aware. If your customer bought an eight-core machine, you will have a hard time explaining to them that it’s normal that the application only uses about 12% of the CPU capacity, even if the machine is dedicated to that particular application.

In the future, this will be even worse. Not only will your sequential code not run faster, it will actually run slower. The reason is that the more cores you get, the slower each core will run for power and heat reasons. In a couple of years, Intel will give us 32 cores, and there are trends that suggests that will have thousands of cores before we know it. But each core will be very slow compared to todays cores.

Concurrent code

One obvious way to solve the problem is to write (and rewrite) software to be concurrent. The most common way to do that is to use threads, but most developers consider thread-based applications particularly hard to write. Deadlocks, starvation and race conditions are concepts that are way too familiar for a majority of developers doing concurrency. Both Erlang and Scala take away a lot of that pain.

An brief overview of the languages

Scala is sometimes seen as the next big JVM language. It combines the object-oriented paradigm with the functional paradigm, has a terse syntax compared to Java, is statically typed and is as fast or sometimes even faster than Java. There are numerous reasons to take a serious look at Scala.

Erlang is a language designed for robustness, but because of its design, it is thereby a language that scales well. It predates Java, but it is often considered to be a language of the concurrent future. It is a dynamically typed, functional language, with some remarkable examples of uptime.

The debate

So what’s the Scala vs. Erlang debate all about? In the end, performance and scalability, but the debate includes other things like style, language features and library support as well. The debate was started unintentionally when Ted Neward gave his opinions about a number of languages and that “the fact that [Erlang] runs on its own interpreter [is] bad”.

Steve Vinoski and Ted then had a couple of rounds of debate, but the discussion then moved to a couple of other blogs where it highlighted interesting differences and similarities between Scala and Erlang. We’ll summarize each interesting point to show pros and cons of each language and the different views on some problems.

Reliability

Steve Vinoski wrote a response to Ted’s post where he gave his take on that Erlang runs its own interpreter:

The fact that it runs on its own interpreter, good; otherwise, the reliability wouldn’t be there and it would be just another curious but useless concurrency-oriented language experiment.

Steve is talking about the problem that even if a language itself is reliable, everything it stands upon has to be reliable too. Since Erlang is designed from the bottom up for reliability and thereby concurrency, it doesn’t suffer from usual problems when it comes to concurrency, primarily that the underlying libraries needs to play well in a concurrent setting.

Scala on the other hand lives on top of the JVM and one of the most important selling points is the potential usage of all existing Java code. However, a lot of Java code is not designed for concurrency, and Scala code needs to take this into account.

Lightweight processes

To run massively concurrent applications, you need a lot of parallel execution. This can be done in several ways. Using threads is one common way, using processes is another. The difference is that a thread shares memory with other threads, processes share nothing. That means that threads needs locking mechanisms like mutexes to prevent two threads from manipulating the same memory at the same time, but processes don’t suffer from that problem and instead uses some kind of message passing to communicate with other processes. But processes are normally expensive regarding performance and memory, and that is a reason why people often choose thread based concurrency, even though it’s a harder programming model.

Steve Vinoski writes:

Massive concurrency capabilities become far easier with an architecture that provides lightweight processes that share nothing, but that doesn’t mean that once you design it, the rest is just a simple matter of programming.

Erlang takes this approach to concurrency. An Erlang process is very lightweight, and Erlang applications commonly have tens-of thousands of threads or more.

Scala on the other hand does the same thing with event-based actors. Yariv Sadan explains how:

Scala has two types of Actors: thread-based and event based. Thread based actors execute in heavyweight OS threads. They never block each other, but they don’t scale to more than a few thousand actors per VM. Event-based actors are simple objects. They are very lightweight, and, like Erlang processes, you can spawn millions of them on a modern machine.

Yariv explains that there is a difference though:

The difference with Erlang processes is that within each OS thread, event based actors execute sequentially without preemptive scheduling. This makes it possible for an event-based actor to block its OS thread for a long period of time (perhaps indefinitely).

Immutability

Erlang is a functional language. This means that data is immutable, like Java’s strings, and there is no risk of side effects. Any operation on some data will result in a new modified version of that data, but the old one stays the same. Immutability is a highly regarded ingredient when it comes to robustness, since no code can unintentionally change data that someone else is dependent upon, but from a concurrency point of view, it is also an important feature. If data is immutable, the risk of it being changed by two parallel execution paths doesn’t exist and data can even be copied to other machines since there is no way for it to change and nothing to keep in sync.

Since Scala is based upon the JVM and combines an object-oriented and functional approach, there are no guarantees of immutability like in pure functional languages. However, in the comment section of Yariv’s post, a very interesting discussion between Yariv and David Pollack on interesting differences between the languages took place. David, who is the creator of the Scala web framework Lift, gives his views on immutability.

Immutability — Erlang enforces this and there’s almost no way around it. But you trade the rest of Scala’s amazingly powerful type system for enforcement of this single type. I do my Scala Actor coding with immutable data and I have Scala’s type system to enforce the rest of my types.

Yariv asks:

Doesn’t sending only immutable types a big limitation? It means you can’t, for example, load a simple bean from Hibernate and send it to another actor.

David answers:

I’ve built a number of production systems based on Scala Actors. There’s very little work actually required to deal with the immutable issue. You just define your case classes (the messages) to be immutable and away you go.

Type systems

Erlang is dynamically typed. Scala is statically typed and has a stronger type system than Java. However, a big difference compared to Java is that Scala has type inference. This means that you can omit a lot of type annotations, which makes the code cleaner but the compiler will still do all checks.

The debate about pros and cons of dynamic and static type systems will likely never come to an end, but that is a noticeable difference between Erlang and Scala.

Tail recursion or loops

Yariv again:

Functional programming and recursion go hand-in-hand. In fact, you could hardly write working Erlang programs without tail recursion because Erlang doesn’t have loops — it uses recursion for everything (which I believe is a good thing :) ).

This is definitely something that differs Erlang a lot from Scala. Scala has a much more traditional style of iterations, but David Pollack doesn’t see an advantage for tail recursion in this context:

Tail recursion — It’s a non-issue for event-based actors.

In that case, it all comes down to preference and style.

Hot swapping code

Since Erlang was designed for reliability, hot swapping code (replacing code in runtime) is built in.

The JVM has some support for hot swapping code. Classes can be changed, but due to the static type system, method signatures can not be changed - only the content of a method. There are third party tools to get around that, and there are frameworks that promotes a programming style that makes it easier to swap classes in running systems, but because of how a Scala Actor is built up, how swapping works even though it runs on the JVM. Jonas Bonér gives a thorough example of how to do it.

Summary

Both Scala and Erlang are languages that target the multi-core crises. They come from different background and eras and thereby approach some problems differently, but in many ways they have more in common than they differ, at least when it comes to the concurrency issues.

Erlang has been around for a couple of decades, and has proved itself in many critical real-world systems. One of it’s drawbacks is that it is a bit of an island and the recent polygot programming trend is not likely to affect Erlang community that much.

Scala on the other hand is the new kid on the block for the same type of applications. There are real world applications just coming out the door, and there are companies that are betting their future on it. Scala’s biggest advantage compared to Erlang is that is runs on the JVM and can use all existing Java code, frameworks and many of the tools. That said, that power comes with great responsibility, since most Java code don’t automatically fit well the Scala’s Actor model.

Both languages offer similar ways to solve a increasingly pressing problem that mainstream languages don’t help developers with very well. Hopefully you have a slightly better insight about which language to take a closer look at for your particular situation after reading this debate summary.

The future is multi-cored. Scala and Erlang is likely to increase in popularity.

martes, junio 10, 2008

Cuento traje emperador

Hace unas semanas le leí a Marcos este cuento.
Es fantástico

Hoy me lo he encontrado por internet accidentalmente





El traje nuevo del Emperador
[Cuento infantil. Texto completo]
Hans Christian Andersen

Hace muchos años había un Emperador tan aficionado a los trajes nuevos, que gastaba todas sus rentas en vestir con la máxima elegancia.
No se interesaba por sus soldados ni por el teatro, ni le gustaba salir de paseo por el campo, a menos que fuera para lucir sus trajes nuevos. Tenía un vestido distinto para cada hora del día, y de la misma manera que se dice de un rey: “Está en el Consejo”, de nuestro hombre se decía: “El Emperador está en el vestuario”.
La ciudad en que vivía el Emperador era muy alegre y bulliciosa. Todos los días llegaban a ella muchísimos extranjeros, y una vez se presentaron dos truhanes que se hacían pasar por tejedores, asegurando que sabían tejer las más maravillosas telas. No solamente los colores y los dibujos eran hermosísimos, sino que las prendas con ellas confeccionadas poseían la milagrosa virtud de ser invisibles a toda persona que no fuera apta para su cargo o que fuera irremediablemente estúpida.
-¡Deben ser vestidos magníficos! -pensó el Emperador-. Si los tuviese, podría averiguar qué funcionarios del reino son ineptos para el cargo que ocupan. Podría distinguir entre los inteligentes y los tontos. Nada, que se pongan enseguida a tejer la tela-. Y mandó abonar a los dos pícaros un buen adelanto en metálico, para que pusieran manos a la obra cuanto antes.
Ellos montaron un telar y simularon que trabajaban; pero no tenían nada en la máquina. A pesar de ello, se hicieron suministrar las sedas más finas y el oro de mejor calidad, que se embolsaron bonitamente, mientras seguían haciendo como que trabajaban en los telares vacíos hasta muy entrada la noche.
«Me gustaría saber si avanzan con la tela»-, pensó el Emperador. Pero había una cuestión que lo tenía un tanto cohibido, a saber, que un hombre que fuera estúpido o inepto para su cargo no podría ver lo que estaban tejiendo. No es que temiera por sí mismo; sobre este punto estaba tranquilo; pero, por si acaso, prefería enviar primero a otro, para cerciorarse de cómo andaban las cosas. Todos los habitantes de la ciudad estaban informados de la particular virtud de aquella tela, y todos estaban impacientes por ver hasta qué punto su vecino era estúpido o incapaz.
«Enviaré a mi viejo ministro a que visite a los tejedores -pensó el Emperador-. Es un hombre honrado y el más indicado para juzgar de las cualidades de la tela, pues tiene talento, y no hay quien desempeñe el cargo como él».
El viejo y digno ministro se presentó, pues, en la sala ocupada por los dos embaucadores, los cuales seguían trabajando en los telares vacíos. «¡Dios nos ampare! -pensó el ministro para sus adentros, abriendo unos ojos como naranjas-. ¡Pero si no veo nada!». Sin embargo, no soltó palabra.
Los dos fulleros le rogaron que se acercase y le preguntaron si no encontraba magníficos el color y el dibujo. Le señalaban el telar vacío, y el pobre hombre seguía con los ojos desencajados, pero sin ver nada, puesto que nada había. «¡Dios santo! -pensó-. ¿Seré tonto acaso? Jamás lo hubiera creído, y nadie tiene que saberlo. ¿Es posible que sea inútil para el cargo? No, desde luego no puedo decir que no he visto la tela».
-¿Qué? ¿No dice Vuecencia nada del tejido? -preguntó uno de los tejedores.
-¡Oh, precioso, maravilloso! -respondió el viejo ministro mirando a través de los lentes-. ¡Qué dibujo y qué colores! Desde luego, diré al Emperador que me ha gustado extraordinariamente.
-Nos da una buena alegría -respondieron los dos tejedores, dándole los nombres de los colores y describiéndole el raro dibujo. El viejo tuvo buen cuidado de quedarse las explicaciones en la memoria para poder repetirlas al Emperador; y así lo hizo.
Los estafadores pidieron entonces más dinero, seda y oro, ya que lo necesitaban para seguir tejiendo. Todo fue a parar a sus bolsillos, pues ni una hebra se empleó en el telar, y ellos continuaron, como antes, trabajando en las máquinas vacías.
Poco después el Emperador envió a otro funcionario de su confianza a inspeccionar el estado de la tela e informarse de si quedaría pronto lista. Al segundo le ocurrió lo que al primero; miró y miró, pero como en el telar no había nada, nada pudo ver.
-¿Verdad que es una tela bonita? -preguntaron los dos tramposos, señalando y explicando el precioso dibujo que no existía.
«Yo no soy tonto -pensó el hombre-, y el empleo que tengo no lo suelto. Sería muy fastidioso. Es preciso que nadie se dé cuenta». Y se deshizo en alabanzas de la tela que no veía, y ponderó su entusiasmo por aquellos hermosos colores y aquel soberbio dibujo.
-¡Es digno de admiración! -dijo al Emperador.
Todos los moradores de la capital hablaban de la magnífica tela, tanto, que el Emperador quiso verla con sus propios ojos antes de que la sacasen del telar. Seguido de una multitud de personajes escogidos, entre los cuales figuraban los dos probos funcionarios de marras, se encaminó a la casa donde paraban los pícaros, los cuales continuaban tejiendo con todas sus fuerzas, aunque sin hebras ni hilados.
-¿Verdad que es admirable? -preguntaron los dos honrados dignatarios-. Fíjese Vuestra Majestad en estos colores y estos dibujos -y señalaban el telar vacío, creyendo que los demás veían la tela.
«¡Cómo! -pensó el Emperador-. ¡Yo no veo nada! ¡Esto es terrible! ¿Seré tan tonto? ¿Acaso no sirvo para emperador? Sería espantoso».
-¡Oh, sí, es muy bonita! -dijo-. Me gusta, la apruebo-. Y con un gesto de agrado miraba el telar vacío; no quería confesar que no veía nada.
Todos los componentes de su séquito miraban y remiraban, pero ninguno sacaba nada en limpio; no obstante, todo era exclamar, como el Emperador: -¡oh, qué bonito!-, y le aconsejaron que estrenase los vestidos confeccionados con aquella tela en la procesión que debía celebrarse próximamente. -¡Es preciosa, elegantísima, estupenda!- corría de boca en boca, y todo el mundo parecía extasiado con ella.
El Emperador concedió una condecoración a cada uno de los dos bribones para que se las prendieran en el ojal, y los nombró tejedores imperiales.
Durante toda la noche que precedió al día de la fiesta, los dos embaucadores estuvieron levantados, con dieciséis lámparas encendidas, para que la gente viese que trabajaban activamente en la confección de los nuevos vestidos del Soberano. Simularon quitar la tela del telar, cortarla con grandes tijeras y coserla con agujas sin hebra; finalmente, dijeron: -¡Por fin, el vestido está listo!
Llegó el Emperador en compañía de sus caballeros principales, y los dos truhanes, levantando los brazos como si sostuviesen algo, dijeron:
-Esto son los pantalones. Ahí está la casaca. -Aquí tienen el manto… Las prendas son ligeras como si fuesen de telaraña; uno creería no llevar nada sobre el cuerpo, mas precisamente esto es lo bueno de la tela.
-¡Sí! -asintieron todos los cortesanos, a pesar de que no veían nada, pues nada había.
-¿Quiere dignarse Vuestra Majestad quitarse el traje que lleva -dijeron los dos bribones- para que podamos vestirle el nuevo delante del espejo?
Quitose el Emperador sus prendas, y los dos simularon ponerle las diversas piezas del vestido nuevo, que pretendían haber terminado poco antes. Y cogiendo al Emperador por la cintura, hicieron como si le atasen algo, la cola seguramente; y el Monarca todo era dar vueltas ante el espejo.
-¡Dios, y qué bien le sienta, le va estupendamente! -exclamaban todos-. ¡Vaya dibujo y vaya colores! ¡Es un traje precioso!
-El palio bajo el cual irá Vuestra Majestad durante la procesión, aguarda ya en la calle - anunció el maestro de Ceremonias.
-Muy bien, estoy a punto -dijo el Emperador-. ¿Verdad que me sienta bien? - y volviose una vez más de cara al espejo, para que todos creyeran que veía el vestido.
Los ayudas de cámara encargados de sostener la cola bajaron las manos al suelo como para levantarla, y avanzaron con ademán de sostener algo en el aire; por nada del mundo hubieran confesado que no veían nada. Y de este modo echó a andar el Emperador bajo el magnífico palio, mientras el gentío, desde la calle y las ventanas, decía:
-¡Qué preciosos son los vestidos nuevos del Emperador! ¡Qué magnífica cola! ¡Qué hermoso es todo!
Nadie permitía que los demás se diesen cuenta de que nada veía, para no ser tenido por incapaz en su cargo o por estúpido. Ningún traje del Monarca había tenido tanto éxito como aquél.
-¡Pero si no lleva nada! -exclamó de pronto un niño.
-¡Dios bendito, escuchen la voz de la inocencia! -dijo su padre; y todo el mundo se fue repitiendo al oído lo que acababa de decir el pequeño.
-¡No lleva nada; es un chiquillo el que dice que no lleva nada!
-¡Pero si no lleva nada! -gritó, al fin, el pueblo entero.
Aquello inquietó al Emperador, pues barruntaba que el pueblo tenía razón; mas pensó: «Hay que aguantar hasta el fin». Y siguió más altivo que antes; y los ayudas de cámara continuaron sosteniendo la inexistente cola.

FIN

Mi primer concierto

Martes 3 de Julio de 2008, 8:45, palacio de deportes de Madrid...

El primer concierto de Kylie Minogue en España y mi primer concierto (la primera vez que voy a un concierto)

Impresionante.
La combinación de la imagen y la música, la coreografía, los bailarines, Kylie, la pantalla gigante, todo perfectamente coordinado con la música...

Un espectáculo impresionante



Empiezan con un look de ciencia ficción

Luego el equipo de futbol americano Kylie (Kylie está en buena forma, es capaz de abrir completamente las piernas)

Japoneses, samurais y geisas.
Kylie sale de una pirámide y 4 bailarines hacen una fantástica exibición atlética.
Complicados saltos por encima de la pirámide para aterrizar en cilindros (nada grandes)
Complicadísimas figuras en unos postes (que son parte de un cubo que bajó para encajar en la pirámide)
Una de las figuras más espectaculares es cuando estaban sujetos al poste sólo con los brazos, el cuerpo perfectamente estirado y separado dos palmos del poste. Bastante complicado, pero si ahora empiezan a girar sobre el poste manteniendo la altura y la posición y la separación al mismo... impresionante


Un descanso "jolvemos en 20 minutos" y más espectáculo


Ahora estamos en un crucero al estilo de vacaciones en el mar.
Marineritos, animadoras, una barra, baile, música Copa Cabana...

Una calavera metálica y Kylie vestida de rojo con un gran sombrero gorra encima de la misma

Luego, un castillo de cuento, un suelo tablero de ajedrez, vestido complejo, baile elegante...

Ahora se arranca parte del traje elegante y se queda con los pantalones ajustados y una camiseta también bastante ajustada
Mucha marcha...




Habla un poco en español y termina con la canción "I should be so lucky"

Afortunadamente fuimos con prismáticos y así pudimos verlo bien



Me gustó mucho y me agobió poco la aglomeración, apenas sí me percaté. Quizá porque la entrada y la salida fueron fáciles y rápidas


Una muy buena experiencia y probablemente una oportunidad única

Es la primera vez en 20 años que viene y puede que no vuelva nunca. Ya veremos






http://www.publico.es/122315/kylie/minogue/debuta/espana/publico/entregado

Veinte años se ha hecho de rogar una de las reinas del pop para lucirse por tierras españolas, tan sólo había pasado por aquí de promoción y a hacer algún que otro "playback", por eso el público estaba expectante y recibía con una calurosa acogida a Kylie Minoge en Madrid.

Ella, un tanto distante y fría, aunque hacía sus pinitos en castellano, ofrecía un concierto en el que presentaba los temas de su último trabajo, "X", y hacía un recorrido por clásicos de su repertorio como "In your eyes", "Your disco needs you", "Can't get you out of my head", "Kids", "Step back in time" o "Love at first sign".

También hubo versiones, como "Copacabana", de Barry Manilow, pero faltaron esas otras que ella ha sabido hacer suyas como "Hand on your head" o la del clásico de los 60, "Locomotion", con el que en el verano del 87 saltaba a los primeros puestos de las listas de ventas.

Convertida en una de las grandes divas del pop, con 40 años recién cumplidos y recuperada del cáncer de mama que la ha tenido retirada de los escenarios una temporada, Kylie llegaba al Palacio de Deportes de Madrid con un espectáculo hecho a su medida, acompañada de un cuerpo de baile y un coro de chicas que suplía alguna de sus carencias.

Y es que las estrellas, aunque dan todo lo que tienen encima del escenario, muchas veces no tienen todo lo que parece.

Jean Paul Gaultier hace las delicias del público masculino con el vestuario de la cantante australiana

Eso sí, el vestuario diseñado, también para ella en exclusiva para la gira "KylieX2008", por Jean Paul Gaultier, hizo las delicias del público, mayoritariamente masculino, y que se tomaba este concierto como un anticipo de las madrileñas fiestas del orgullo gay, que se celebrarán la primera semana de julio.

El escenario estaba concebido al más puro estilo Las Vegas, con constantes cambios de luces, ascensores que subían, bajaban y transportaban a la diva de una lado al otro del mismo.

El espectáculo estaba dividido en siete partes, para cada una de las cuales Kylie lucía diferente vestido, comenzando con una traje de noche de cola color morado y terminando con un top de pedrería acompañado por un pantalón negro.

Pero no faltaron los disfraces de "cheerleader", "dominatrix", "manga", "domadora" o "marinerita", este último para el homenaje a la serie de televisión de los 80, "Vacaciones en el mar".

lunes, junio 09, 2008

Accidente de escalador y navaja multiusos

Es una historia antigua pero impresionante y que he recordado este fin de semana.


http://news.nationalgeographic.com/news/2004/08/0830_040830_aronralston.html

http://news.nationalgeographic.com/news/2004/08/0830_040830_aronralston_2.html



Climber Who Cut Off Hand Looks Back

August 30, 2004

In April 2003 climber Aron Ralston entered Utah's Bluejohn Canyon only to become trapped when an 800-pound (360-kilogram) boulder shifted, crushed his hand, and pinned him to the canyon wall. For six days, Ralston struggled to free himself while warding off dehydration and hypothermia.

Trapped and facing certain death, Ralston chose a final option that later made him an international sensation: Using a multitool, the climber amputated his right hand, then rappelled to freedom.

Ralston has written an account of his experience, Between a Rock and a Hard Place (Atria Books), which arrives in bookstores this month. National Geographic Adventure recently spoke with Ralston about his accident and lifesaving act.

How did you finally decide to start cutting?

After having enough sleepdeprived, meandering thoughts about how I arrived in the canyon, I realized that [my situation] was the result of decisions that I had made. I chose to go out there by myself. I chose to not tell anyone where I was going. I chose not to go with [two climbers] I had met in the canyon [on the first day].

But I also realized that I had made all of the choices up to that point that had helped me survive. I took responsibility for all of my decisions, which helped me take on the responsibility of getting myself out.

But how did someone who had been repulsed by dissecting a sheep's eyeball in ninth grade manage to sever his own hand?

It was strange. I kind of entered a flow state. I've been there before while climbing. You are not thinking ahead. You are just thinking about what is in front of you each second.

I was so engrossed that I had to catch myself when I got to the arteries so that I didn't sever those without a tourniquet on.

The answer seems obvious, but did it hurt?

Well, I didn't have any sensation in my right hand from the time of the accident onward. However, I did feel pain coming from the area where the boulder rested on my wrist.

When I amputated, I felt every bit of it. It hurt to break the bone, and it certainly hurt to cut the nerve. But cutting the muscle was not as bad.




Overall, it was a hundred times worse than any pain I've felt before. It recalibrated what I'd understood pain to be. At the same time, it was also the most beautiful thing I've ever felt. Later, you fielded a lot of criticism, mainly from climbers who focused on your mistakes. Do you think their points were justified?

I certainly made mistakes. I think the people that say to never go out alone are completely off-base. But I agree with the people who say to never go out alone without telling someone where you are going. Normally, I do that. I didn't this time, because I miscalculated the risks.

When I climb a fourteener [a 14,000-foot/4,260-meter peak] in the winter by myself, I leave an itinerary and information about where my vehicle will be parked and the name of the county sheriff to contact in case I don't get home. I blew it by not telling anyone about Bluejohn.

You videotaped yourself on a daily basis while trapped. Why?

It gave me a sense of completion. Not only did the camera let me tell my family and friends what had happened, but also it gave me the opportunity to tell them how I was feeling and that I loved them. I liked the thought that I wasn't going to leave an unexplained mess.

What are you going to do with the video?

I hadn't planned on sharing any of it, but in the first week of May I read the transcript from the video of American contractor Nick Berg, who had been taken hostage and eventually beheaded in Iraq. Our messages were very similar: This is who I am; these are my parents; this is where they live.

It struck me that in our last hours, even though we may have moved away from those things, there's a levelheaded understanding of what's important. I decided that that point cannot be emphasized enough, so I decided to share that portion of the tape with Dateline NBC.

Have you been able to return to climbing?

My prosthetic is the key. The part replacing my hand includes a [combination] climbing pick and adze manufactured by Trango. I plug the device into my arm and use it for both vertical ice and rock. Then I just switch it out for a claw attachment for belaying and rope management.

I feel like I'm climbing as well, if not better, than ever. In January I got up a pitch of grade-five ice, which for me is as hard as I've ever climbed.

What do you think about being cast as a hero?

I think that people responded to the way I reacted to what happened, not to the accident itself. I guess there is some irony there. But what are you going to do?

Sign up for the free Inside National Geographic newsletter. Every two weeks we'll send you our top news stories by e-mail.


lunes, junio 02, 2008

Premio príncipe de asturias al creador de linux

Esta es la noticia en varios medios de comunicación, pero no me convence totalmente

El premio es para Linus Torvalds, creador de Linux, el núcleo que es utilizado en muchas distribuciones "Linux" o "GNU/Linux"

Lo malo es que Linux es un nombre del kernel, pero casi todo el mundo lo asocia con un sistema operativo alternativo o incluso lo confunden con las distribuciones.

¿El premio es para el creador del núcleo Linux?

Sería correcto.
Espero que los que han otorgado el premio no hayan confundido Linux (el kernel) con el movimiento "Linux" (que sería más correcto decir movimiento GNU o incluso OpenSource)
Pero me temo que sí lo han confundido



¿Es justo darle un premio a Linus Torvalds por el kernel Linux?

Sí y más


Pero hay gente dentro del movimiento "Linux" que se lo merece más, empezando por Richard Stallman.

Poca gente sabe bien que significa con detalle Linux.

La mayoría de la gente lo relaciona con un sistema operativo libre, distribuciones, etc...

Linux es un núcleo (kernel) tipo Unix.
Linux está basado en Minix que a su vez, es una especie de Unix.

El problema es que Linux, por su gracia y semejanza con Unix, ha sido un nombre de éxito y ahora se utiliza para algo mucho más general, donde realmente encajaría mejor GNU

Pero el nombre GNU no tiene "pegada" y ha sido desplazado por el simpático nombre Linux.

¿Es posible que este "marketing" de nombres provoque confusiones y errores?

Por supuesto que sí.

¿Darle el premimo a Linus Torvalds ayuda a estos errores?
No

¿Podemos estar seguro de que se da este premio por el núcleo Linux y no por lo que significa el sistema GNU/Linux?
No


Pero aún más...

¿El movimiento GNU/Linux que tanta fuerza está alcanzando podría haber existido sin el núcleo Linux?


Hay varias posibilidades.
Una muy fácil, es montar un sistema con otro núcleo. Ya existen alternativas, por ejemplo BSD
Esta además tiene varias ventajas. Una, no está personalizado, eso es bueno.
Otra, que tiene un nombre con poca fuerza como GNU


Una opción más compleja, si no hubiera existido el núcleo Linux, sería hacer uno.
En este sentido, desde FSF se inició un desarrollo muy ambicioso, quizá demasiado, un núcleo con arquitectura micronúcleo.

Este se llama Hurd, que también es un nombre flojo.
Aunque muchas veces pensamos que Hurd es un fracaso, quizá no lo es tanto, porque está basado en Match, al que habrá ayudado y Match es la base del núcleo actual del Apple/Mac


¿Linus Torvalds ha sido un personaje relevante en el movimiento GNU/Linux?
Sí, pero otros más, empezando por Richard Stallman

La clave del movimiento GNU/Linux es una filosofía reflejada en una licencia (que utiliza el propio núcleo de Linux)

Además, los programas GNU que existían antes que el propio núcleo son incluso más complejos y no menos importantes, empezando por gcc


Resumiendo...

Muy bien el premio a Linus Torvalds (si se lo dan, que por el momento es sólo una propuesta y no es la primera vez), pero dárselo también o antes a Richard Stallman, habría sido mejor