Dopaje

Ahora están los juegos olímpicos y hablar de super hombres que baten records increíbles es lo que manda.

Pero hay mucha hipocresía en esto.


Es cierto que realizan azañas brutales, pero no menos cierto es que algunos se dopan mucho, otros un poco menos y otros casi nada

Pero lo peor es que todos dicen que eso es trampa y nadie lo hace, lo que lleva a una ridícula competición farmaco-deportiva ridícula.


Se comparan deportistas no dopados con otros muy dopados como si estuvieran en las mismas condiciones y eso es ridículo.


Para el ingenuo que crea que los controles antidoping son efectivos casi totalmente...

Ver ejemplo de Mariom Jones. Una atleta de primerísimo nivel que estaba extremadamente vigilada no fue pillada nunca en controles antidoping aunque tomó esteroides durante muchos meses.


¿Cómo es posible?

Los laboratorios fabrican sustancias dopantes no detectables, hasta que alguien descubre la trampa.


Esto aumenta las diferencias en las condiciones de competición entre atletas, pero nadie quiere reconocerlo


En estas olimpiadas (de Pekín), un corredor ha destrozado el record de 100m.

¿Se dopaba?

Según un velocista alemán, sí. Y yo estoy convencido



¿Se puede evitar el dopaje?


Desde luego que se pueden hacer muchas más cosas para evitarlo, pero no quieren.



1.- Todo país que no controle de forma fiable a sus deportistas, no podrá competir en mundiales, olimpiadas, y otros eventos internacionales.
Carajo, se sabe que Jamaica no es que tenga manga ancha, es que no controla absolutamente nada.

2.- Guardar muestras para control tras varios años.
Cuando se conocen nuevas sustancias dopantes que se pueden detectar.
Se puede castigar al deportista, al país, federación y decir que han sido tramposos. Quitarles la gloria y cambiarla por un recordatorio de trampas


Podría haber tramposos que ganen dinero y les de igual que les pillen varios años después.

Sí, pero al menos no quedarían como héroes en la historia, sino como tramposos.

3.- Debería sancionarse a los laboratorios que crean sustancias que se pueden y se han utilizado para doparse sin detectarse en los controles


Si un laboratorio crea esteróides no detectables, debería informar para que sean detectables inmediatamente, en vez de comerciar con su uso con los deportistas


Es decir, no permitamos a los laboratorios hacer negocio con el dopaje



Pero un país podría mantenerse al margen de todo esto y permitir prácticas tramposas en deportistas y laboratorios


Pero el punto 2 nos garantiza que al final se les descubrirá y al final se anulará su gloria

Con sanciones contundentes a Países y federaciones, la cosa mejoraría mucho.



Por eso pienso que el dopaje está más permitido que perseguido por las autoridades respectivas



¿Qué pasaría si quitamos el dopaje?


Desaparecerían las actuaciones impresionantes actuales, y eso da menos espectáculo



Mientras el deporte sea un enorme negocio, es difícil controlar el dopaje.
Pero se hace mucho menos de lo que se podría, porque no se quiere hacer más.
Y lo peor es que pretenden vendernos que quieren perseguir y eliminar el dopaje

Marion Jones confiesa haberse dopado

Marion Jones, en los JJOO de Atenas 2004. (Foto: EFE)

Actualizado viernes 05/10/2007 00:51 (CET)

DPA

WASHINGTON.- La velocista estadounidense Marion Jones reconoció que utilizó esteroides como parte de la preparación para los Juegos Olímpicos de Sydney, su cumbre deportiva, en la que ganó cinco medallas, según publicó hoy el diario 'The Washington Post' en su edición digital. [Gráfico: El dopaje]

Jones planea declararse culpable este viernes en Nueva York de mentir a los agentes federales por el uso de drogas y de no declarar una cuenta a su nombre, de acuerdo con una carta que le envió a familiares cercanos y amigos.

La atleta asegura que desde 1999 y por dos años tomó el esteroide conocido como 'The clear' (el claro), según el diario, que cita a una persona cercana a la situación legal de Jones que tuvo acceso a la carta. La sustancia resultó ser el esteroide de diseño Tetrahidrogestrinona (THG).

"Deseo que me disculpen por todo esto", dice Jones en la misiva. "Lo siento por decepcionarlos a todos ustedes de muchas formas". Jones explica que su ex entrenador Trevor Graham le dio una sustancia con la explicación de que se trataba de un suplemento nutricional y debía tomarlo colocándose dos píldoras debajo de la lengua.

La aceptación de su culpabilidad podría costarle a Jones las tres medallas de oro y dos bronce que ganó en Sydney. En diciembre de 2004, el Comité Olímpico Internacional (COI) abrió una investigación alrededor de las alegaciones de que Jones había usado drogas para incrementar el rendimiento. Pero la corredora había negado hasta ahora vehementemente el uso de esteroides.

"Confié en él [Graham] y nunca lo pensé ni por un segundo", añadió Jones. "La preocupación creció cuando me dijo que no le comentara a ninguna persona acerca de ello", dice la 'sprinter', que reconoce haber experimentado cambios en su cuerpo y sentir cómo era capaz de recuperarse de grandes esfuerzos físicos.

Envuelta en el caso Balco

La THG fue el origen de uno de los mayores escándalos de dopaje de la historia del atletismo, alrededor del laboratorio californiano Balco. El laboratorio creó el esteroide, que fue indetectable en los controles antidoping hasta que el propio Graham envió una jeringuilla con la sustancia a la Agencia Antidopaje de EEUU (USADA) en 2003.

El dueño de los laboratorios Balco, Victor Conte, posa con una foto dedicada de Marion Jones. (Foto: AP)

El estallido del caso en 2003 se llevó por delante a Tim Montgomery, entonces plusmarquista mundial de 100 metros y compañero sentimental de Jones y padre de su hijo, y al ex marido de la atleta, el lanzador de peso C.J. Hunter, además de varios entrenadores.

El cerco se cerraba cada vez más sobre Jones, a la que Victor Conte, dueño de Balco, acusó en repetidas ocasiones de utilizar productos prohibidos. El caso no se limitó al atletismo. Los jugadores de béisbol Gary Sheffield y Jason Giambi admitieron ante un Gran Jurado el uso de THG.

Graham fue procesado en noviembre del año pasado por mentir a agentes federales sobre tres cuentas vinculadas con la investigación. Por el momento el ex entrenador se declaró inocente y el juicio está previsto para el próximo mes.

Se enfrenta a seis meses de prisión

Casada recientemente con el también ex velocista Obadele Thompson, Jones señala en la carta que planea volar desde su hogar en Austin, en el estado de Texas, y reunirse con su madre en Nueva York para la declaración. La atleta reconoce que podría enfrentar una sentencia de hasta seis meses en prisión.

Jones admite también haber mentido "por pánico" a los investigadores federales acerca de un cheque por valor de 25.000 dólares que le entregó Montgomery. Montgomery se declaró culpable este año en Nueva York de un fraude bancario multimillonario y de lavado de dinero.

Conjetura de Kepler

El País - Miércoles, 4 de enero de 2006

La demostración de la conjetura de Kepler

Un matemático logra desentrañar un problema planteado por el genio alemán hace cuatro siglos

Antonio Córdoba Barba, catedrático de Análisis Matemático (Universidad Autónoma de Madrid)

¿Cómo empaquetar del modo más eficaz esferas del mismo tamaño, es decir cómo hacer un montón de naranjas o de balas de cañón de manera que ocupen el mínimo espacio? El problema, formulado por Johannes Kepler, tiene por fin demostración, lograda con una combinación de herramientas matemáticas y de ordenadores.

El desafío involucra todas las maneras posibles de disponer bolas en el espacio. ¿Estamos en el umbral de una nueva era en la que las máquinas probarán los teoremas?

Annals of Mathematics, posiblemente la mejor revista matemática del mundo, ha publicado el pasado noviembre la demostración obtenida por Thomas C. Hales de una famosa conjetura formulada por Kepler hace cuatro siglos.

Que el autor del problema sea un afamado científico y que haya transcurrido tanto tiempo en resolverse lo asemeja al Último Teorema de Fermat, con el que también comparte la sencillez de su enunciado; el tener una historia rica en resultados parciales, incluyendo varias demostraciones falsas o incompletas; el que Hales, como hiciera Wiles en el caso del Fermat, haya dedicado más de seis años a perfilar la solución y, además, el haber sido publicadas ambas demostraciones en los Annals.

¿Cuál es la manera más eficiente de empaquetar esferas del mismo tamaño? En esta pregunta, engañosamente sencilla, radica el enigma propuesto por Kepler. Es claro que al disponer bolas en el espacio quedarán siempre intersticios y un empaquetamiento denso minimizará el volumen que resta fuera de ellas. Un ejemplo notable se construye disponiéndolas inicialmente sobre un plano, tangentes entre sí y formando hileras intercaladas, que crean una densa capa sobre la que podemos apilar las nuevas esferas colocándolas entre cada tres tangentes de la formación inicial. Iterando con cuidado este procedimiento, arriba y abajo de la primera capa, obtendremos un empaquetamiento periódico que, en cristalografía, recibe el nombre de red cúbica centrada y que aparece ilustrado en la manera habitual como disponen los fruteros la oferta de manzanas y naranjas. Es fácil calcular su densidad (0.74...), que Thomas Hales ha demostrado ser insuperable: no importa cómo llenemos el espacio con esferas, la densidad será siempre menor o igual que la alcanzada por la red cúbica centrada.

El problema fue sugerido a Kepler por un marino que deseaba estimar el número de balas de cañón que almacenaban los buques enemigos en su cubierta. Pero en 1611 no podían imaginar que el diseño de buenos empaquetamientos haya resultado ser ahora tan relevante en la tecnología de la información, tanto para enviar señales por un canal ruidoso sin perder calidad, como en los códigos que nos garantizan la fidelidad del sonido de un disco compacto.

Nosotros podemos bromear también con la perspicacia de los fruteros, pero ello nos distraería de la cuestión importante, es decir, del gran desafío a la mente humana que planteaba la conjetura, a la que había que atacar porque estaba ahí, como dijo E. Hillary sobre la escalada del Everest. El desafío es tremendo, casi de vértigo, pues involucra todas las maneras posibles de disponer bolas en el espacio: ¿cómo empezar siquiera semejante tarea?

Si se tratara sólo del caso periódico, entonces la escalada es más fácil y el gran Gauss, a mediados del siglo XIX, ya pudo realizarla. También podemos rebajar la dimensión y hacernos la pregunta análoga para círculos del plano: en torno a 1960, el matemático húngaro Fejes Toth encontró la respuesta correcta, que resultó ser la versión bidimensional de la red cúbica centrada.

Pero en tres dimensiones es mucho más difícil: en un empaquetamiento, cada esfera tiene asociada una celda de influencia, formada por los puntos del espacio que están más cerca de su centro que de los de las restantes esferas. El cociente entre el volumen de la esfera y el de su celda de influencia es la densidad local del empaquetamiento. Resulta que, en dimensión dos, las celdas de mayor densidad local son hexágonos, con los que se puede teselar el plano. En el espacio las celdas de la red cúbica centrada son dodecaedros rómbicos. La celda local más densa, sin embargo, es el dodecaedro regular, pero con ella, como bien saben los cristalógrafos, no se puede teselar el espacio. Esta discrepancia entre la solución óptima local y la global es una de las razones por las que el problema de Kepler ha resultado tan difícil.

El artículo de Hales consta de unas ciento veinte páginas de matemáticas convencionales. Pero depende de un programa informático que analiza cerca de cinco mil casos residuales, para los que hay que optimizar funciones de más de doscientas variables. Después de varios años de trabajo la comisión de expertos a quienes Annals encargó la revisión del artículo ha tirado la toalla, sintiéndose incapaz de escudriñar todos los detalles en un tiempo razonable; tarea que han comparado con la de cotejar, uno por uno, la veracidad de todos los datos del listín telefónico de Nueva York. Empero, el comité ha llevado a cabo el número adecuado de comprobaciones para poder sostener su fe en la corrección de la prueba con, según dicen, un 99% de probabilidad. Pero, ¿es eso suficiente?

Una demostración matemática es una cadena de razonamientos, a veces muy larga, que nos llevan desde una hipótesis de partida hasta una tesis de llegada y que es susceptible de ser engarzada por todo aquel que posea el tiempo y el entrenamiento adecuados. Pero éste no es el caso de la prueba de Hales. El dilema de Annals es tremendo y su solución ecléctica quizás no satisfaga a muchos: publica la parte que se ajusta al arquetipo tradicional, pero añade un comentario editorial advirtiendo de que la prueba depende de un programa que aparecerá en otra revista especializada en computación. Los editores señalan que estamos ante un caso de aproximación de las matemáticas a la práctica de las ciencias experimentales, por cuanto la verificación de la parte informática hay que hacerla con los criterios con los que se valida un experimento, pero no con los tradicionales de las matemáticas.

Annals es una centenaria revista bimensual editada en Princeton (Estados Unidos) conjuntamente por la Universidad y el Instituto de Estudio Avanzado. Los requisitos para aparecer en sus páginas son muy estrictos: ha de tratarse de un resultado relevante demostrado con técnicas originales. No es de extrañar que publicar en Annals sea objeto del deseo para los matemáticos y que traten de lograrlo con sus resultados mejores.

La demora entre la llegada y la publicación de un artículo oscila en torno a los dos años, pero ése es un dato que Annals comparte con otras revistas, que no son ya tanto un instrumento de comunicación, puesto que los resultados circulan antes por la red, sino una garantía de calidad. Ésa es ahora la principal razón de ser de las mejores revistas. Pero éstas son una minoría; la mayoría tienen criterios mucho más relajados: tanto, que sus publicaciones son con bastante frecuencia un mero y prescindible ruido.

A diferencia de la demostración del Teorema de Fermat, que ha requerido el fecundo ingenio matemático contemporáneo, creo que la prueba de la conjetura de Kepler, sin desmerecer con ello el trabajo de Hales, habría podido llevarse a cabo hace siglos de haber contado con los medios de cálculo que tenemos ahora a nuestro alcance. ¿Significa esta demostración que estamos en el umbral de una nueva era en la que las máquinas se encargarán de probar los teoremas? ¿Son los matemáticos una especie en extinción?

Sinceramente creo que la respuesta es un rotundo no, aunque sea un lugar común afirmar que el ordenador es un instrumento valiosísimo, una ayuda casi imprescindible, en la investigación actual. Pero es posible, y yo diría que muy deseable, que las máquinas se encarguen en el futuro de tantos desarrollos rutinarios y tantas demostraciones clónicas que mantienen ocupados a demasiados matemáticos quienes, incansables, publican obviedad tras obviedad. Llenando sin cesar, con mutuas referencias, el registro de esa grotesca casa de citas que tiene su sede en Filadelfia. Liberados por las máquinas, podrían estos artistas, siguiendo el buen ejemplo de Wiles y Hales, dedicar sus esfuerzos a resolver problemas realmente difíciles e interesantes que tengan luego cabida en Annals of Mathematics.

seguridad en vista

Visto en...

http://www.kriptopolis.org/la-puntilla-para-vista

Por Fernando Acero

De todos son conocidos los problemas de Windows Vista para entrar en el mercado, con controvertidas cifras de venta (recordemos que se lo hacen comer con patatas a cada comprador de un sistema informático) y con otros serios problemas con el hardware, los recursos y la compatibilidad, como ya predijo Gartner en su momento. Pero puede que la puntilla destinada a acabar definitivamente con este sistema operativo tan polémico se la acaben de haber dado en Las Vegas...

Al parecer, investigadores de IBM y VMWare acaban de desvelar durante la conferencia Black Hat de Las Vegas, una técnica que permite obtener control total de Windows Vista y lo hacen, de una manera que puede que sea prácticamente imposible de solucionar por Microsoft, a menos que cambie por completo. o sustancialmente, la arquitectura de seguridad de Windows Vista, lo que sinceramente, como están las cosas, me parece improbable.

El problema nace en la forma en la que algunos programas de Windows Vista, como el navegador Internet Explorer, cargan las DLLs (librerías dinámicas) en la memoria de la máquina. El error se basa en que Microsoft asumió para la arquitectura de seguridad de su sistema operativo Windows Vista, que cualquiera de los archivos de DLLs que se cargasen a través de su tecnología .NET, eran seguros por definición. Apuesta, que sin duda, es arriesgada para la seguridad del sistema, pero que parecía conveniente por motivos comerciales. Como están las cosas, basta mezclar la tecnología .NET con código malicioso embebido en DLL's, para tener un cóctel explosivo y demoledor para la seguridad de los usuarios.

Lo peor de todo, es que es una técnica muy sencilla de implementar y muy flexible, puesto que se pueden modificar las DLL maliciosas con mucha facilidad y añadirles un "payload" personalizado, lo que puede abrir las puertas a un nuevo universo de maldades informáticas, gracias a que cualquiera podrá tomar el control total y absoluto de un ordenador dotado con Windows Vista, con un acto tan inocente como visitar una página Web preparada para ejecutar el ataque.

Por si alguno piensa que el parche llegará pronto, hay un problema adicional en todo este asunto, como hemos dicho, el fallo reside en la arquitectura de seguridad de Windows Vista, es decir, que no explota un error de programación, más bien, explota un error de diseño que afecta a lo más íntimo del sistema operativo. La consecuencia es clara, puede que no se pueda arreglar con facilidad, o si se puede, el parche puede ser de varios cientos de megas y sobre todo, de poder arreglarse, es posible que tarde algún tiempo en llegar.

Por ahora, por asombroso que parezca, la única solución para protegerte de esto, es instalarte un Linux y no usar Windows Vista para abrir ningún archivo, o para acceder a Internet, si eres un feliz usuario de Vista no te puedes fiar de nada, la DLL maliciosa que, robe tu información personal, lo convierta en un miembro de honor de una red botnet, o que lo configure como servidor de pornografía infantil, puede venir por cualquier medio, a través de un chat, por correo electrónico, o simplemente, visitando una página web, etc, por ello, el mejor consejo que os puedo dar, felices usuarios de Vista es "olvidaos de Vista hasta que se solucione el problema, si es que se soluciona".

Ahora es el momento de pensar en lo que decía Bruce, sobre el coste para la seguridad que tiene un monopolio, o sobre los problemas de seguridad del código cerrado y monolítico.Pero lo peor de todo, es que a pesar del desastre para los usuarios de Vista, habrá muchos usuarios que no serán conscientes del problema y que seguirán usando Vista con todo lo que ello puede suponer para la seguridad global.

Fuente: Search Security / Black Hat.

"Copyleft 2008 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved."

apt-get

apt-get install





dpkg --configure --pending
Continúa el trabajo por donde se quedó (habitualmente con un bloqueo de sources.list)






apt-get autoclean
Like clean, autoclean clears out the local repository of retrieved
package files. The difference is that it only removes package files
that can no longer be downloaded, and are largely useless. This allows
a cache to be maintained over a long period without it growing out of
control. The configuration option APT::Clean-Installed will prevent
installed packages from being erased if it is set to off.


apt-get autoremove
autoremove is used to remove packages that were automatically
installed to satisfy dependencies for some package and that are no
more needed.

PostgreSQL vs Firebird

http://www.amsoftwaredesign.com/pg_vs_fb

PostgreSQL vs Firebird feature comparison (for Enterprise Use)

Feature		PostgreSQL 8.2.x	Firebird 2.0.x
MVCC		Yes	Yes
Row level Locking Available		Yes	Yes
Max Database Size		Unlimited*	Unlimited*
Max table Size		32 TB	~32 TB
Max Row Size		1.6 TB	64 KB
Max Field Size		1 GB Max size for all types including blobs Firebird seems to be a better choice if you need huge blob support.	Depends on Type (Varchar max size is 32k, Max Blob Size is 32GB)
Max Rows per Table		Unlimited*	> 16 Billion
Max Columns Per Table		50 - 1600 depending on column types	Depends on data types used.
Max Indexes Per Table		Unlimited*	65,535
Multi Threaded Architecture Available?		No	Yes (super server)
Ability to re-order table columns without re-creating from a temp table.		No	Yes
Stores Transaction Information in same file as data		No	Yes
Auto Increment Columns		Yes (serial type that uses sequences)	Yes (must use a generator and a trigger)
True Boolean column type		Yes	No
Table Inheritance		Yes	No
Domains		Yes	Yes
Table Partitioning		Yes (basic)	No
Updateable Views		Yes (via rules system)	Yes
Event/Notification System		Yes	Yes
Temporary Tables		Yes	No
Rich Built in Functions		Yes	No
Multi Lang Stored Procedures		Yes (PLPGSQL,PLPerl,PlJava etc)	No
Compiled External Function (UDF) Support		Yes (C,C++, Delphi possible but C headers would have to be ported)	Yes (C,C++,Delphi)
Exception handling in stored procedures		Yes	Yes
2 Phased Commit		Yes	Yes
Native SSL support		Yes	No
Multiple authentication methods (i.e. LDAP)		Yes	No
Compound Indexes		Yes	Yes
Unique Indexes		Yes	Yes
Partial Indexes		Yes	Yes
Functional Indexes		Yes	Yes
Multiple Index Storage Types		Yes (btree,hash etc)	No
Point in Time Recovery		Yes	No
Schema Support		Yes	No
Strongly conforms to ANSI-SQL 92/99		Yes	Yes
Limit/Offset support		Yes	Yes (FIRST/SKIP)
Create user defined types		Yes	No
Create user defined operators		Yes	No
Create user defined Aggregates		Yes	No
Log Shipping		Yes	No
Write ahead logging (Important for Point In Time Recovery and Log Shipping)		Yes	No
Tablespaces		Yes	No
Save Points		Yes	Yes
Open Source Async Replication		Yes (Slony )	No (Commercial solutions available. Database shadowing is also present.)
Online/Hot Backups		Yes	Yes
File System based backups possible		Yes (Postmaster must be stopped)	Yes
Require backup/restore to compact (not just reuse space, but shrink the physical size of the DB)		No	Yes
Fully ACID Compliant		Yes	Yes
Native Win32 Port		Yes (only runs on NTFS files systems)	Yes
Text/Memo field type (Having a type of TEXT or MEMO aids in porting from other databases and in maintaining a abstraction layer)		Yes	Yes (Can store text via BLOB Type 1 While FB can store text it is not referenced in DDL as TEXT or MEMO rather BLOB subtype 1. Can also use a domain to alias blob subtype 1 as TEXT or MEMO. Domain alias must be created by user.)
BLOB support		Yes (limited to the max field size of 1 GB)	Yes (Can be up to 32GB)
UTF8 support		Yes	Yes
Define charactersets/collations per database (default)		Yes (PostgreSQL can also define a characterset for the entire database cluster during the initdb process)	Yes
Define charactersets and collations on a per column level		No	Yes
Foreign Keys		Yes	Yes
Check Constraints		Yes	Yes
Unique Constraints		Yes	Yes
Not Null Constraints		Yes	Yes
Multiple Transaction Isolation levels		Yes	Yes
Fully relational System Catalogs		Yes	Yes
Information Schema		Yes	No (no schema support)
Native GIS support via GIST or other native means		Yes (PostGIS )	No
Open Source Full Text Search (Official part of Project)		Yes	No
Use POSIX Regular Expressions in queries		Yes	No
Database Monitoring		Yes (Supports among other things statement logging at server via config setting. Aids in debugging of client applications)	?
Ability to query databases on other servers local or remote.		Yes (Dblink )	No
Ability to query foreign databases (MS SQL Server, Oracle etc)		Yes (DBI-Link ,DBLink-TDS )	No
Read Only Databases		No	Yes
Regular Version Updates		Yes Major release once per year with frequent minor updates.	No (Often several years between major versions) Minor updates are more frequent. Project is active.

Estándares y Mocosoft

Recientemente he tenido que hacer un programa que entre otras cosas recogía y enviaba ficheros por FTP (programa en BOO sobre .net)


Tuve un problema cuando pedía la lista de ficheros (comando NLST) y el directorio no tenía ficheros

Me devolvía un error, pero no siempre


Miro y... código de error 550 que pueden ser diferentes cosas. Descripción del error "No files found" que es una de las posibles razones del error 550

Pero esto para mi era un problema

550 no es que no haya ficheros, también puede ser que no tengas permiso, por ejemplo

Pero yo quería saber si no había ficheros o no hay permisos o qué exactamente


Y no sirve con leer la descipción, porque es eso sólo una descripción.
No hay garantías que entre diferentes sistemas tengas la misma descripción en los mismos casos.
En ocasiones puedes tener más detalle y en otras menos



Pos vaya rollo lo del protocolo FTP...

O no, mejor mirar en el RFC de FTP (documento donde se especifica cómo debe trabajar)

Sorpresa 1.
A una petición de NLST no se le puede devolver un código de erorr 550 NUNCA ¿¿??


Probemos contra un servidor Linux a ver que dice al pedir la lista de un directorio vacío...


No devuelve código de error y de vuelve... en blanco, nada


Vaya, pues así me gusta más y además sigue es estándar


En ocasiones los estándares no son completos y pueden tener ambigüedades.
En otras ocasiones, el estándar tomó una decisión incorrecta

En estos casos, puede estar justificado hacer tu interpretación o mejora
(aunque con mucha cautela)


Pero nos encontramos con un caso en el que...


Mocosoft no sigue el estándar.
El estándar era claro y completo
La mejor solución era la del estándar


¿Porqué mocosoft lo hizo de otra forma?


No le encuentro ninguna razón que no sea perversa

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!

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.