Variable not found en Geeks.ms

Después de pasar un buen rato entretenido con la recopilación de frases célebres relacionadas con el mundo de la informática y especialmente el desarrollo de software, «101 Great computer programming quotes«, publicado en DevTopics hace unas semanas, no he podido resistir la tentación de traducirlo, previo contacto con su autor, el amabilísimo Timm Martin.

Ordenadores

1. «Los ordenadores son inútiles. Sólo pueden darte respuestas»
     — Pablo Picasso

2. «Los ordenadores son como los bikinis. Ahorran a la gente el hacer muchas conjeturas»
     — Sam Ewing

3. «Tienen ordenadores, y pueden tener otras armas de destrucción masiva»
     — Janet Reno

4. «Es genial trabajar con ordenadores. No discuten, lo recuerdan todo y no se beben tu cerveza»
     — Paul Leary

5. «Si la industria automovilística hubiera seguido el mismo desarrollo que los ordenadores, un Rolls-Royce costaría hoy 100 dólares, circularía un millón de millas con 3,7 litros y explotaría una vez al año, eliminando a todo el que estuviera dentro en ese momento»
     — Robert X. Cringely

Inteligencia artificial

6. «Los ordenadores se hacen cada vez más inteligentes. Los científicos dicen que pronto ellos serán capaces de hablarnos (y con ‘ellos’ me refiero a los ordenadores, dudo mucho que los científicos sean capaces de hablarnos)»
     — Dave Barry

7. «He notado últimamente que el miedo paranoico hacia ordenadores inteligentes tomando el control del mundo ha desaparecido totalmente. Todo lo que puedo contar es que este hecho coincide con la aparición de MS-DOS»
     — Larry DeLuca

8. «Preguntarse cuándo los ordenadores podrán pensar es como preguntarse cuándo los submarinos podrán nadar»
     — Edsger W. Dijkstra

9. «Es ridículo vivir 100 años y sólo ser capaces de recordar 30 millones de bytes. O sea, menos que un compact disc. La condición humana se hace más obsoleta cada minuto»
     — Marvin Minsky

Confianza

10. «R2D2, ¿te lo dijo la computadora central de la ciudad? ¡R2D2, sabes bien que no debes confiar en una computadora extraña!»
     — C3PO

11. «Nunca confíes en un ordenador que no puedas lanzar por una ventana»
     — Steve Wozniak

Hardware

12. «Hardware: las partes de un ordenador que pueden ser pateadas»
     — Jeff Pesis

Software

13. «La mayoría del software actual es muy parecido a una pirámide egipcia, con millones de ladrillos puestos unos encima de otros sin una estructura integral, simplemente realizada a base de fuerza bruta y miles de esclavos»
     — Alan Kay

14. «Por fin he entendido lo que significa ‘upward compatible’ (compatible hacia arriba). Significa que mantenemos todos nuestros viejos errores»
     — Dennie van Tassel

Sistemas operativos

15. «Hay dos grandes productos que salieron de Berkeley: LSD y UNIX. No creemos que esto sea una coincidencia»
     — Jeremy S. Anderson

16. «19 de enero de 2038, a las 3:14:07 AM»
     (Fin del mundo de acuerdo con la limitación de Unix de 2^32 segundos desde el 1 de enero de 1970)

17. «Todos los sistemas operativos que hay ahí fuera son más o menos iguales. Todos somos una mierda»
     — Brian Valentine, vicepresidente senior de Microsoft describiendo el estado del arte en seguridad de sistemas operativos en 2003

18. «Microsoft ha lanzado una nueva versión, Windows XP, que según todo el mundo ‘es la versión más fiable de Windows hasta la fecha’. Para mí, esto es como decir que el espárrago es el vegetal más articulado que ha existido nunca»
     — Dave Barry

Internet

19. «¿Internet? ¿Todavía anda eso por ahí?»
     — Homer Simpson

20. «La web es como una dominatriz. En todos los sitios que voy me encuentro pequeños botones ordenándome que me someta»
     — Nytwind
     Nota: el texto ‘submit’ que solemos ver en los botones de formularios se puede traducir como el verbo «someter».

21. «Ahora que lo pienso, ya hay un millón de monos con máquinas de escribir y Usenet no es en absoluto como la obra de Shakespeare»
     — Blair Houghton

Industria del software

22. «El logro más impresionante de la industria del software es su continua anulación de los constantes y asombrosos logros de la industria del hardware»
     — Henry Petroski

23. «La verdadera innovación a menudo viene de las pequeñas startups que son capaces de crear mercados pero carecen de peso para poseerlos»
     — Timm Martin

24. «Se dice que las grandes disciplinas científicas son ejemplos de gigantes subidos a los hombros de otros gigantes. También se dice que la industria del software es un ejemplo de enanos subidos a los dedos de los pies de otros enanos»
     — Alan Cooper

25. «No se trata bits, bytes y protocolos, sino de beneficios, pérdidas y márgenes»
     — Lou Gerstner

26. «Somos Microsoft. La resistencia es inútil. Serás absorbido»
     — Bumper sticker

Software Demos

27. «No importa lo estupendamente que haya ido la demo en los ensayos, cuando lo haces frente a tu audiencia la probabilidad de que sea una presentación existosa es inversamente proporcional al número de personas mirando, elevado a la cantidad de dinero que hay en juego»
     — Mark Gibbs

Patentes software

28. «La mayoría de las patentes son una mierda. Dedicar tiempo a leerlas
es estúpido. Es cosa de los propietarios de las patentes hacerlo y procurar que se respeten»
     — Linus Torvalds

Complejidad

29. «Controlar la complejidad es la esencia de la programación»
     — Brian Kernigan

30. «La complejidad es destructiva. Chupa la sangre de los desarrolladores, hace que los productos sean difíciles de planificar, construir y probar, introduce problemas de seguridad y provoca la frustración de usuarios finales y administradores»
     — Ray Ozzie

31. «Hay dos maneras de diseñar software: una es hacerlo tan simple que sea obvia su falta de deficiencias, y la otra es hacerlo tan complejo que no haya deficiencias obvias»
     — C.A.R. Hoare

32. «La función de un buen software es hacer que lo complejo aparente ser simple»
     — Grady Booch

Facilidad de uso

33. «Recuerda: no eres torpe, no importa lo que digan esos libros. Los torpes de verdad son gente que, creyéndose expertos técnicos, no podrían diseñar hardware y software manejable por usuarios normales aunque la vida les fuera en ello»
     — Walter Mossberg

34. «Los proveedores de software están intentando hacer sus productos más amigables para el usuario. Su mejor aproximación hasta el momento ha sido tomar sus antiguos folletos y estampar las palabras ‘amigable para el usuario’ en la portada»
     — Bill Gates

35. «Hay una antigua historia sobre una persona que quería que su ordenador fuese tan fácil de utilizar como su teléfono. Estos deseos se han hecho realidad, ya no sé cómo usar mi teléfono»
     — Bjarne Stroustrup

Usuarios

36. «Cualquier idiota puede usar un ordenador. De hecho, muchos lo hacen»
     — Ted Nelson

37. «Sólo hay dos industrias que se refieren a sus clientes como ‘usuarios'»
     — Edward Tufte

Desarrolladores

38. «La programación es una carrera entre los desarrolladores, intentando construir mayores y mejores programas a prueba de idiotas, y el universo, intentanto producir mayores y mejores idiotas. Por ahora va ganando el Universo»
     — Rich Cook

39. «La mayoría de ustedes están familiarizados con las virtudes del programador. Son tres, por supusto: pereza, impaciencia y orgullo desmedido»
     — Larry Wall

40. «El problema que hay con los programadores es que nunca puedes contar lo que un programador está haciendo hasta que es demasiado tarde»
     — Seymour Cray

41. «Esto es lo que ocurre con la gente que piensa que odia los ordenadores. Lo que realmente odia es a los malditos programadores»
     — Larry Niven

42. «Durante mucho tiempo no entendía cómo algo tan caro y puntero podía ser tan inútil. Y entonces me vino a la mente que un ordenador es una máquina estúpida con la habilidad de hacer cosas increíblemente inteligentes, mientras que los programadores son inteligentes personas con la habilidad de hacer cosas estúpidas. Son, en resumen, una pareja perfecta»
     — Bill Bryson

43. «La formación en informática no puede convertir a nadie en experto programador, de la misma forma que estudiar pinceles y pigmentos puede hacer a alguien un experto pintor»
     — Eric Raymond

44. «Un programador es la persona considerada experta en ser capaz de sacar, después de innumerables tecleos, una serie infinita de respuestas incomprensibles calculadas con precisión micrométrica a partir de vagas asunciones basadas en discutibles cifras tomadas de documentos inconcluyentes y llevados a cabo con instrumentos de escasa precisión, por personas de fiabilidad dudosa y cuestionable mentalidad con el propósito declarado de molestar y confundiar al desesperado e indefenso departamento que tuvo la mala fortuna de pedir la información en primer lugar»
     — IEEE Grid newsmagazine

45. «Un hacker puede ser capaz de producir, en unos pocos meses, algo que un pequeño grupo de desarrolladores (digamos de 7 u 8 personas) podría tener trabajado duramente juntos más de un año. IBM solía decir que ciertos programadores podían ser 100 veces más productivos que otros trabajadores, o más»
     — Peter Seebach

46. «Los mejores programadores no son sólo marginalmente mejores que los buenos. Se trata de un orden de magnitud mayor, medida por cualquier estándar: creatividad conceptual, velocidad, ingenio o habilidad para solucionar problemas»
     — Randall E. Stross

47. «Un gran operario de tornos vale varias veces más que un operario medio, pero un gran escritor de código vale 10.000 veces el precio de un desarrollador medio»
     — Bill Gates

Programación

48. «No te preocupes si no funciona bien. Si todo estuviera correcto, serías despedido de tu trabajo»
     — Ley de Mosher de la Ingeniería del Software

49. «Medir el progreso del desarrollo de software por líneas de código es como medir el progreso de la construcción de un avión por su peso»
     — Bill Gates

50. «La escritura de código tiene un lugar en la jerarquía humana de valores por encima del saqueo de tumbas y por debajo de la dirección y gestión»
     — Gerald Weinberg

51. «Primero aprende informática y toda la teoría. Después desarrolla un estilo de programación. Entonces, olvídalo todo y hackea»
     — George Carrette

52. «Primero resuelve el problema. Entonces, escribe el código»
     — John Johnson

53. «El optimismo es un riesgo laboral de la programación; el feedback es el tratamiento»
     — Kent Beck

54. «Iterar es humano, ‘recursivar’ es divino»
     — L. Peter Deutsch

55. «Lo mejor de los booleanos es que si te equivocas estás a un sólo bit de la solución correcta»
     — Anónimo

56. «¿Los índices de los arrays deberían comenzar en 0 o en 1? Mi propuesta neutral de usar 0.5 fue rechazada, en mi opinión, sin la debida consideración»
     — Stan Kelly-Bootle

Lenguajes de programación

57. «Hay sólo dos clases de lenguajes de programación: aquellos de los que la gente está siempre quejándose y aquellos que nadie usa»
     — Bjarne Stroustrup

58. «PHP es un mal menor perpetrado y creado por amaterus incompetentes, mientras que Perl es un gran e insidioso mal perpetrado por hábiles pero pervertidos profesionales»
     — Jon Ribbens

59. «El uso de COBOL daña la mente. Su enseñanza debería ser considerada como un ataque criminal»
     — E. W. Dijkstra

60. «Es prácticamente imposible enseñar buenos hábitos de programación a estudiantes que hayan sido previamente sometidos a una exposición de BASIC. Como desarrolladores en potencia, están mentalmente mutilados sin esperanza de regeneración»
     — E. W. Dijkstra

61. «Pienso que Microsoft eligió el nombre .Net para que no pudiera ser mostrado en un listado de directorio de Unix»
     — Oktal

62. «No hay lenguaje de programación, no importa su estructura, que impida que los programadores hagan malos programas»
     — Larry Flon

63. «El diseño de lenguajes de programación es como pasear en el parque. Bueno, en parque jurásico»
     — Larry Wall

C/C++

64. «¿Cincuenta años de investigación en lenguajes de programación, y acabamos con C++?»
     — Richard A. O’Keefe

65. «Escribir en C o C++ es como utilizar una sierra eléctrica sin ningún tipo de protección»
     — Bob Gray

66. «Cuando usas C++ es más difícil que te dispares a tí mismo en el pie, pero cuando lo haces, te vuelas la pierna entera»
     — Bjarne Stroustrup

67. «C++ : Donde los amigos tienen acceso a tus miembros privados»
     — Gavin Russell Baker

68. «Una de las causas principales de la caída del imperio romano fue que, como no usaban el cero, no tenían forma de saber cuándo sus programas en C terminaban correctamente»
     — Robert Firth

Java

69. «Java es, en muchos sentidos, C++-«
     — Michael Feldman

70. «Decir que Java es estupendo porque funciona con todos los sistemas operativos es como decir que el sexo anal es estupendo porque funciona con todos los géneros»
     — Alanna

71. «Bien, Java podría ser un buen ejemplo de cómo debería ser un lenguaje de programación. Sin embargo, las aplicaciones Java son buenos ejemplos de cómo las aplicaciones no deberían ser»
     — Pixadel

72. «Si Java dispusiera de un mecanismo real de recolección de basura, la mayoría de los programas deberían autoeliminarse al ser ejecutados»
     — Robert Sewell

Software libre

73. «El software es como el sexo: mejor si es libre y gratis»
     — Linus Torvalds

74. «Las únicas personas que tienen algo que temer de software libre son aquellos cuyos productos tienen un valor aún menor»
     — David Emery

Código

75. «El buen código es su mejor documentación»
     — Steve McConnell

76. «Cualquier código tuyo que no hayas mirado en los últimos seis meses o más es como si lo hubiese escrito otro»
     — Eagleson’s Law

77. «El primer 90% del código corresponde al primer 90% del tiempo de desarrollo. El 10% restante corresponde al otro 90% del desarrollo»
     — Tom Cargill

Desarrollo de software

78. «Los buenos programadores usan sus cerebros, pero unas buenas directrices nos ahorran de tener que hacerlo en cada caso»
     — Francis Glassborow

79. «En software, muy raramente partimos de requisitos con sentido. Incluso teniéndolos, la única medida del éxito que importa es si nuestra solución resuelve la cambiante idea que el cliente tiene de lo que es su problema»
     — Jeff Atwood

80. «Considerando el lamentable estado de nuestras aplicaciones informáticas actuales, el desarrollo de software es todavía un arte oscuro, y no puede ser aún considerado una ingeniería»
     — Bill Clinton

81. «No puedes crear un gran software sin un gran equipo, y la mayoría de los equipos de desarrollo se comportan como familias disfuncionales»
     — Jim McCarthy

Depuración

82. «Tan pronto como comenzamos a programar encontramos, para nuestra sorpresa, que crear programas correctos no era tan fácil como habíamos pensado. Tuvo que descubrirse la depuración. Puedo recordar el instante exacto en el que me dí cuenta que una gran parte de mi vida desde entonces iba a pasarla encontrando errores en mis propios programas»
     — Maurice Wilkes descubre la depuración, 1949

83. «Depurar es al menos dos veces más duro que escribir el código por primera vez. Por tanto, si tu escribes el código de la forma más inteligente posible no serás, por definición, lo suficientemente inteligente para depurarlo»
     — Brian Kernighan

84. «Si la depuración es el proceso de eliminar errores, entonces la programación debe ser el proceso de introducirlos»
     — Edsger W. Dijkstra

Calidad

85. «¡No me importa si funciona en tu máquina! ¡No estamos vendiendo tu máquina!»
     — Vidiu Platon

86. «Programar es como el sexo: un único error y tienes que estar soportándolo toda la vida»
     — Michael Sinz

87. «Hay dos formas de escribir programas sin errores; sólo la tercera funciona»
     — Alan J. Perlis

88. «Puedes tener un software de calidad o puedes tener aritmética de punteros, pero no puedes tener ambas cosas al mismo tiempo»
     — Bertrand Meyer

89. «Si McDonnalds funcionara como una compañía de software, uno de cada cien Big Macs te envenenarían, y la respuesta sería ‘lo sentimos, aquí tiene un cupón para dos más'»
     — Mark Minasi

90. «Codifica siempre como si la persona que finalmente mantendrá tu código fuera un psicópata violento que sabe dónde vives»
     — Martin Golding

91. «Cometer errores es humano, pero para estropear realmente las cosas necesitas un ordenador»
     — Paul Ehrlich

92. «Un ordenador te permite cometer más errores y más rápido que cualquier otra invención en la historia de la humanidad, con las posibles excepciones de las pistolas y el tequila»
     — Mitch Radcliffe

Predicciones

93. «Todo lo que puede ser inventado ha sido ya inventado»
     — Charles H. Duell, Comisario de oficina de Patentes en EEUU, en 1899

94. «Pienso que hay mercado en el mundo como para unos cinco ordenadores»
     — Thomas J. Watson, Presidente de la Junta Directiva de IBM, sobre 1948

95. «Podría parecer que hemos llegado a los límites alcanzables por la tecnología informática, aunque uno debe ser prudente con estas afirmaciones, pues tienden a sonar bastante tontas en cinco años»
     — John Von Neumann, sobre 1949

96. «Pero, ¿para qué puede valer eso?»
     — Ingeniero en la división de sistemas informáticos avanzados de IBM, hablando sobre los microchips, en 1968

97. «No hay ninguna razón para que un individuo tenga un ordenador en su casa»
     — Ken Olson, Presidente de Digital Equipment Corporation, en 1977

98. «640K deberían ser suficientes para todo el mundo»
     — Bill Gates, 1981

99. «Windows NT podrá direccionar 2GB de RAM, que es más de lo que cualquier aplicación va a necesitar jamás»
     — Microsoft, durante el desarrollo de Windows NT, en 1992

100. «Nunca seremos realmente una sociedad sin papeles hasta que la gente de la Palm Pilot creen ‘WipeMe 1.0′»
     — Andy Pierson
     (Nota: Wipe es la traducción de toallita de papel)

101.»Si las cosas siguen así, al hombre se le atrofiarán todas sus extremidades excepto los dedos de pulsar los botones»
     — Frank Lloyd Wright

Publicado en: http://www.variablenotfound.com/.

Encuentro en Apuntes de un Loco que hace un par de días Microsoft publicó las especificaciones de varios de sus formatos de archivo binario de Microsoft Office, así como otros de soporte, en el contexto del compromiso de apertura de especificaciones que mantiene desde algo más de un año.

• Word 97-2007 (.doc)
  
• Powerpoint 97-2007 (.ppt)
  
• Excel 97-2007 (.xls)
  
• Excel 2007 (.xlsb)
  
• Office Drawing 97-2007
  
• Compound file (OLE 2.0)
  
• Windows Metafile (.wmf)
  
• Ink Serialized Format (ISF)

Una iniciativa interesante derivada de esto ha sido la creación en SourceForge del proyecto «Office Binary Translador to Open XML«, que pretende crear herramientas de conversión automática a este estándar ECMA. Supongo que en breve esta información se usará también para realizar conversiones fiables hacia y desde otros formatos, como los utilizados en otras suites ofimáticas como Open Office (Open Document).

Se trata sin duda de una buena noticia para facilitar la interoperabilidad entre aplicaciones.

Publicado en: http://www.variablenotfound.com/.

Existen muchos consejos para crear código mantenible, como los que ya cité cuando hablaba sobre comentar el código fuente, pero ninguno iguala a este:

«Always code as if the person who will maintain your code is a maniac serial killer that knows where you live»

(Codifica siempre como si la persona que fuera a mantener tu código fuera un asesino en serie maníaco que sabe donde vives)

Al parecer se trata de un leyenda urbana sobre Visual C++ 6.0, pero no deja de tener su razón…

Imagen: My Confined Space

Publicado en: http://www.variablenotfound.com/.

Hace sólo unos días alucinaba con la existencia y gran difusión del leet speak, y de nuevo vuelvo a asombrarme con la programación esotérica, otra prueba de que en este mundillo siempre hay algo sorprendente que descubrir.

Los lenguajes esotéricos, también llamados esolangs, son lenguajes de programación cuyo objetivo, al contrario que en los «tradicionales», no es ser útil, ni solucionar problemas concretos, ni ser especialmente práctico, ni siquiera incrementar la productividad del desarrollador. De hecho, lo normal es que atente contra todas estas características de forma contundente.

Aunque algunos se diseñan como pruebas de concepto de ideas para determinar su viabilidad en lenguajes reales, lo más frecuente es que sean creados por diversión y exclusivamente con objeto de entretener a sus posibles usuarios. Viendo esto, puede parecer que no existirán más de un par de lenguajes esotéricos, ¿no? Pues haciendo un recuento rápido en la lista de lenguajes de esolang.org he podido contar más de cuatrocientos, lo cual da una idea de la dimensión de la frikada de la que estamos hablando.

Pero no hay nada como unos ejemplos ilustrativos para que tomemos conciencia total de la cuestión.

Ejemplo 1: «Hello World» en lenguaje Argh!

Este lenguaje utiliza una matriz de 80×40 caracteres, en cuyas celdas pueden aparecer tanto código como datos. La siguiente matriz codifica el tradicional «Hello World»:

j       world
lppppppPPPPPPsrfj
 hello,      *  j
              qPh

Según la especificación oficial, la ejecución comienza en la esquina superior izquierda, donde la orden «j» hace que la dirección de la ejecución sea hacia abajo. La siguiente orden procesada, «l», modifica el sentido de la ejecución hacia la derecha. Una «p» hace que se envíe a la consola el carácter que se encuentra en la celda inmediatamente inferior, de la misma forma que las «P» lo hacen con los caracteres situados en las celdas superiores.

Para no extenderme demasiado, resumiré un poco. Una vez enviado el saludo, se imprime un retorno de carro utilizando la pila para restar del carácter «*» (ASCII 42) el espacio (ASCII 32), se envía a la consola y se finaliza el programa (orden «q»).

Ejemplo 2: «Hello World» en Brainfuck (jodecerebros)

Este lenguaje es un clásico en este mundillo debido a que ha servido como base para la creación de muchos otros lenguajes esotéricos. Se basa en la manipulación de un array de celdas utilizando tan solo 8 comandos, los siguientes caracteres: <, >, +, -, punto, coma, [, ].

Estas órdenes permiten desplazarse por las celdas hacia delante y hacia atrás («<» y «>»), incrementar o disminuir el valor de la celda actual («+» y «-«), escribir y leer caracteres hacia/desde consola («.» y «,») y hacer bucles simples («[» y «]»). Como muestra, ahí va el «Hello world»:

>+++++++++[<++++++++>-]<.>
+++++++[<++++>-]<+.+++++++..+++.
>>>++++++++[<++++>-]
<.>>>++++++++++[<+++++++++
>-]<—.<<<<.+++.
——.——–.>>+.

Gran muestra de código mantenible, sin duda.

Como curiosidad, añadir que existe un intérprete y compilador de Brainfucker para .NET en Google Code.

Ejemplo 3: «HAI WORLD» en LOLCODE

Lolcode es otro buen ejemplo de frikismo, aunque en este caso más orientado hacia la broma. Se trata de programar utilizando el peculiar lenguaje que usan unos populares gatitos, llamados lolcats, una mezcla entre la jerga de un bebé y el lenguaje habitual en los SMS.

HAI
CAN HAS STDIO?
VISIBLE «HAI WORLD!»
KTHXBYE

Es interesante saber que existen multitud de implementaciones de este lenguaje, una de ellas incluso en .NET, aún en versión alfa, con perfecta integración en Visual Studio.



En fin, que después nos quejamos de que los desarrolladores tenemos fama de rarillos… 😉

Publicado en: http://www.variablenotfound.com/.

Los métodos de extensión son otra de las interesantes características que nos ofrecen las nuevas versiones de los lenguajes C# y VB que han sido publicados junto con la plataforma .NET v3.5 y Visual Studio 2008.

Los, en inglés, extension methods, permiten añadir métodos a clases existentes sin necesidad de utilizar el mecanismo de la herencia. Aunque dicho así parezca ser una aberración y atente directamente contra una de las principales bases de la programación orientada a objetos, y de hecho están considerados por algunos como auténticos inventos diabólicos, la cosa tampoco es tan grave siempre que se mantenga cierto control y conocimiento de causa. Y es que, como muchas otras características aparecidas recientemente en estos lenguajes, no son sino una base sobre la que sustentar frameworks como Linq, y que de paso pueden ayudarnos a ser algo más productivos.

En realidad, y siendo prácticos, los métodos de extensión no aportan grandes novedades, casi nada que no pudiéramos hacer con la versión 1.0 del framework, simplemente nos facilitan nuevas vías sintácticamente más simples de hacerlo. Por ejemplo, seguro que alguna vez habéis querido dotar una clase X con nuevas funcionalidades y no habéis podido heredar de ella por estar sellada (sealed en C# o NotInheritable en VB)… ¿Qué es lo que habéis hecho? Pues probablemente crear en otra clase un método estático con un parámetro de tipo X que realizaba las funciones deseadas en alguna clase de utilidad. ¿Lo vemos mejor con un ejemplo?

Supongamos que deseamos añadir a la clase string un método que nos retorne la cadena almacenada entre un tag (X)HTML strong. Como String no es heredable, la solución idónea sería crear una clase de utilidad donde codificar este métodos y otros similares que pudieran hacernos falta:

public static class HtmlStringUtils
{
   public static function string Negrita(string s)
   {
     return «<strong>» + s + «</strong>»;
   }
   public static function string Cursiva(string s) {…}
   public static function string Superindice(string s) {…}
   […]
}

Su uso tendría que pasar necesariamente por la referencia a la clase estática y el paso del parámetro a convertir, así:

  HtmlStringUtils.Negrita(currentUser.Name)

Esta técnica es correcta, aunque tiene un problema de visibilidad del código. Ningún desarrollador podría intuir la existencia de la clase HtmlStringUtils de forma natural; tampoco sería posible que un IDE sofisticado nos sugiriese el método Negrita() como una posibilidad a la hora de manipular una cadena, como hace Intellisense con los métodos de instancia habituales.

Los extension methods vienen a cubrir estos inconvenientes, creando una vía de alternativa para codificar el ejemplo anterior, facilitando después su uso de una forma más sencilla. Ojo al parámetro que recibe la función, que incluye la palabra reservada «this» por delante del mismo:

public static class HtmlStringUtils
{
   public static function string Negrita(this string s)
   {
      return «<strong>» + s + «</strong>»;
   }
   […]
}

De esta forma, incluyendo como primer parámetro el tipo precedido de la palabra «this», este método estático se convertirá automáticamente en un método de extensión de dicho tipo, y pueda ser utilizado como si fuera un método de instancia más del mismo:

  return currentUser.Name.Negrita();

Y, por supuesto, tendríamos toda la potencia de nuestro querido Intellisense (en VS2008) a nuestra disposición.

Lo único a tener en cuenta es el primer parámetro, que debe ser del tipo a extender. En éste se introducirá la instancia de dicho tipo de forma automática, y el resto de parámetros serán enviados al método en el mismo orden, es decir:

   // Método de extensión sobre un string
   public static string Colorea(this string s, Color color)
   {
      […]
   }

   // Forma de invocarlo:
   string str = User.Name.Colorea(Color.Red);
 

En esta ocasión no hablaré nada de lenguajes de programación, aunque sí de algo igualmente críptico para los no iniciados, el 1337, L337 o «leet speak». Y es que, aunque lo había visto utilizado en muchos sitios y a veces incluso soy capaz de leerlo, no conocía el nombre de este tipo de escritura ni era consciente de su gran difusión.

1337 es una forma de escribir textos usada en la actualidad por usuarios avanzados de determinadas comunidades de Internet, que consiste en la utilización de combinaciones de caracteres alfanuméricos de forma que no puedan ser entendidos fácilmente por parte de los neófitos o no iniciados. Este carácter elitista se ha reflejado en su nombre, puesto que el término «1337» es la escritura correspodiente de «LEET», que proviene del término «élite» (en inglés). Además, aportaba a sus conocedores interesantes ventajas a la hora de esquivar filtros de contenidos en servicios on-line como chats o foros durante la popularización del uso de Internet.

¿Y cómo se lee o escribe 1337?

En un primer nivel, esta técnica sustituye los caracteres de un mensaje por otros similares, o al menos ligeramente parecidos, como dígitos o símbolos. Por ejemplo, la letra «S» puede ser sustituida por el número «5», «I» por el número uno, o la «T» por un «7»:

• E570y 35cr1813nd0 3n 1337: Estoy escribiendo en 1337.
  
• Un4 53gund4 pru384: Una segunda prueba.
  
• En m1 0p1n1ón, 35 un h4ck3r: En mi opinión, es un hacker.

El texto en nivel uno puede leerse muy fácilmente, como comentaban en Microsiervos, si se lee muy rápidamente. Probad y veréis que es cierto.

Un uso avanzado de 1337, sin embargo, es algo más difícil de leer y escribir. Aquí ya hay sustituciones complejas, como representar una «M» como «|V|», o «B» como «|3» y similares, se utilizan acrónimos (BTW, EMHO, LOL), y términos propios (H4xOr),

• 3570Y 35(R|8|3|||)0 3|| 1337: Estoy escribiendo en 1337
  
• |_|||4 53G|_||||)4 PR|_|3|34: Una segunda prueba
  
• E|/||-|0, 35 |_||| H4xOr: En mi opinión, es un hacker

Por último, decir que 1337 no tiene unas reglas fijas, por lo que cada uno puede usar su propio leet speak, siempre que pueda entenderse de forma similar a la descrita aquí. La imaginación y creatividad en el uso de símbolos está permitida, al igual que la corrección ortográfica o sintáctica no son especialmente necesarias.

En fin, hay que ver la de cosas curiosas que hay por el mundo…

35P3R0 q|_|3 31 P057 05 |-|4Y4 R35|_|174|)0 |||73R354||73.

Más información en:

• Traductores 1337 on-line.
  
• Cómo leer y escribir en 1337
  
• Leet speak en la Wikipedia
  
• ¡Google en versión 1337!

Publicado en: http://www.variablenotfound.com/.

He encontrado una interesante relación de técnicas destinadas a favorecer la creatividad y generar ideas publicada en Neuronilla. En ella se explica, a veces de forma muy detallada, para qué puede ser aplicada cada técnica, el procedimiento a seguir en cada caso, ejemplos y enlaces para ampliar información.

A modo de resumen, encontraremos:

• Mapas mentales, que permite explorar problemas y generar ideas usando una técnica muy gráfica de acceso al potencial del cerebro a través del pensamiento irradiante.
  
  
• Arte de preguntar, útil para observar problemas desde distintas perspectivas, utilizando un arsenal de preguntas predefinidas (¿cuándo?¿qué clase de?¿con qué?…)
  
  
• Brainstorming, o tormenta de ideas, todo un clásico en las técnicas grupales para generar ideas.
  
  
• Relaciones forzadas, técnica que suele usarse complementando al brainstorming en momentos de aparente bloqueo, creando nuevas situaciones a partir de la combinación de hechos conocidos con desconocidos.
  
  
• SCAMPER, cuyo nombre está compuesto por las iniciales de las cuestiones a plantearse que estimulan la creación de ideas: ¿Sustituir?¿Combinar?¿Adaptar?¿Modificar?¿Para otros usos? ¿Eliminar o reducir?¿Reordenar o invertir?
  
  
• Listado de atributos, técnica considerada ideal para la generación de nuevos productos, o mejorar los existentes, consiste en enumerar atributos del objeto o concepto, e intentar mejorar o solucionar cada uno de ellos.
  
  
• Analogías, consistente en la generación de ideas para solucionar un problema dando un rodeo, acudiendo a otras disciplinas no relacionadas; por ejemplo, resolver un problema empresarial observando el comportamiento de un equipo deportivo.
  
  
• Biónica, técnica usada en ámbitos tecnológicos, que persigue la creación de aparatos útiles basados en el estudio de los sistemas biológicos. Ejemplos hay muchos: aviones, radares, el velcro…
  
  
• Creación en sueños, que aprovecha el poder creativo del sueño y estados de sopor para solucionar un problema, se basa en la interiorización de la cuestión a solventar antes de ir a dormir, y en tener a mano papel y lápiz para anotar las imágenes y asociaciones llegadas en estos momentos.
  
  
• Método Delfos, también llamado Delphi, que utiliza expertos en una materia para encontrar soluciones a problemas a través de análisis sucesivos de éste y las respuestas obtenidas en fases iterativas.
  
  
• Análisis morfológico, que permite generar gran cantidad de ideas en muy poco tiempo descomponiendo un problema en sus elementos más básicos, creando una matriz que facilita la combinación aleatoria de las distintas posibilidades existentes en cada uno de ellos.
  
  
• CPS (Creative Problem Solving) define procedimiento de seis pasos para la solución creativa de problemas: definición de objetivos, captura de información, reformulación del problema, generación de ideas, selección y refuerzo y creación del plan de acción.
  
  
• Técnica Clásica, que establece un método de cinco pasos secuenciales a seguir para la generación estructurada de ideas: recogida de materia prima, trabajo con ideas, incubación inconsciente, inspiración y finalización.
  
  
• Relajación, como técnica básica para potenciar la imaginación, intuición, concentración y atención.
  
  
• Visualización, o pensamiento mediante imágenes, esquiva las limitaciones del lenguaje centrándose exclusivamente en otros aspectos, facilitando la vivencia de experiencias futuras.
  
  
• Mitodología, aprendizaje del proceso creativo a través del uso de dramatizaciones basadas en personajes mitológicos.
  
  
• Ideart, usa estímulos visuales (pinturas) para la generación de ideas mediante provocación, creando vínculos entre ellos y el foco creativo.
  
  
• TRIZ, una metodología creada especialmente para generar ideas ingeniosas en problemas tecnológicos, muy utilizada en ámbitos industriales.
  
  
• CRE-IN, conjunto de técnicas destinadas a la búsqueda interna de la paz, la reflexión, relax, etc., con objeto de generar una actitud más imaginativa y desestructurada.
  
  
• 4x4x4, técnica de producción de ideas a base de la obtención, primero de forma individual y luego grupal, de ideas, que van compartiendo y seleccionando sucesivamente.
  
  
• La técnica DaVinci, que se basa en dejar actuar a la intuición para la generación de ideas de forma visual, dibujando y escribiendo conceptos procedentes del subconsciente.
  
  
• Seis sombreros para pensar, una técnica de análisis y resolución de problemas desde distintas perspectivas, representadas como sombreros. Así, los participantes deberán concentrarse en generar ideas según el sombrero que tengan puesto: optimismo, objetividad, creatividad, cautela, etc.
  
  
• Provocación, que elimina del pensamiento los patrones establecidos para la resolución de problemas al basarse en ideas deliberadamente absurdas (provocaciones), lo que facilita la generación de ideas diferentes.
  
  
• Programación neurolingüística, que ayuda a determinar las estrategias mentales de personas muy creativas para poder replicarlas en otros. Por ejemplo, del estudio de Walt Disney se obtuvo el Modelo de Creatividad Disney, una técnica basada en el comportamiento de este genio.
  
  
• DO IT, que además de traducirse como «Hazlo», corresponde a las iniciales de las fases de la técnica, Definir el problema, Open (abrir la mente a múltiples soluciones), Identificar la mejor solución y Transformarla en acción eficazmente.
  
  
• Estratal, técnica consistente en la creación de enunciados paralelos en torno al objetivo, que se consideran como una totalidad aún siendo independientes unos de otros.
  
  
• Método 635, en el que seis personas escriben tres ideas durante cinco minutos, pasándolas a sus compañeros hasta completar un ciclo. Se considera igual de efectivo que el brainstorming, y más controlable.
  
  
• Brainwriting, o lluvia de ideas escritas, utiliza una técnica similar al brainstorming para generar gran cantidad de ideas en grupos remotos, o con problemas con dificultades de comunicación.
  
  
• Conexiones morfológicas forzadas, facilita la aparición inicial de ideas sobre aspectos que no se han tenido en cuenta, así como la inspiración basada en analogías.
  
  
• Inversión, una interesante técnica que consiste en darle la vuelta al objetivo y hacer que este giro hacia un planteamiento absurdo provoque la aparición de nuevas ideas.
  
  
• Empatía, que facilita la percepción desde una perspectiva ajena al individuo.
  
  
• Alternative Environment, técnica utilizada para favorecer la aparición de soluciones inusuales a retos usuales.

Como indican al principio, aunque es posible usar muchas de ellas de forma individual, lo óptimo es trabajarlas en grupos de 6 u 8 personas de perfil heterogéneo, sin niveles jerárquicos, clima de confianza y cohesión y manteniendo siempre visibles los objetivos a lograr.

Para más información, visitad la web http://www.neuronilla.com/.

Publicado en: http://www.variablenotfound.com/.

FxCop es una herramienta que nos ayuda a mejorar la calidad de nuestras aplicaciones y librerías desarrolladas en cualquier versión de .Net, analizando de forma automática nuestros ensamblados desde distintas perspectivas y sugiriéndonos mejoras cuando detecta algún problema o incumplimiento de las pautas de diseño para desarrolladores de librerías para .Net Framework (Design Guidelines for Class Library Developers).

La versión actual (1.35) se puede descargar desde esta dirección, aunque ya existe una beta de la v1.36 en la web de Microsoft. Todos los comentarios que siguen se refieren a esta última versión, la 1.36 (beta), osado que es uno ;-), pero la mayor parte son válidos para la última revisión estable, la 1.35.

Una vez instalado tendremos a nuestra disposición dos aplicaciones: FxCop, que facilita el análisis y consulta de resultados a través de su propia GUI, y FxCopCmd, ideada para su utilización desde línea de comandos e integrarlo en otros sistemas, como Visual Studio, como parte del proceso de construcción (build) automatizado.

En cualquiera de los dos casos, el análisis de los ensamblados se realiza sometiéndolos a la comprobación de una serie de reglas basadas en buenas prácticas y consejos para asegurar la robustez y mantenibilidad de código. Del resultado del mismo obtendremos un informe con advertencias agrupadas en las siguientes categorías:

• Advertencias de diseño, recoge avisos de incumplimientos de buenas prácticas de diseño para .Net Framework, como pueden uso de constructores públicos en tipos abstractos, interfaces o namespaces vacíos, uso de parámetros out, capturas de excepciones genéricas y un largo etcétera.



• Advertencias de globalización, que avisan de problemas relacionados con la globalización de aplicaciones y librerías, como pueden ser el uso de aceleradores de teclado duplicados, inclusión de rutas a carpetas de sistema dependientes del idioma («archivos de programa»), etc.



• Advertencias de interoperabilidad, que analizan problemas relativos al soporte de interacción con clientes COM, como el uso de tipos auto layout visibles a COM, utilización de System.Int64 en argumentos (que no pueden ser usados por clientes VB6), o la sobrecarga de métodos.



• Advertencias de movilidad, cuestionando el soporte eficiente de características de ahorro de energía, como uso de procesos con prioridad ProcessPriorityClass.Idle., o inclusión de Timers que se repitan más de una vez por segundo.



• Advertencias de nombrado, que detectan las faltas de cumplimiento de las guías y prácticas recomendadas en cuanto al nombrado de elementos (clases, métodos, variables, etc.), como uso de nombres de parámetros que coinciden con nombres de tipo, y más con los propios de un lenguaje concreto, mayúsculas y minúsculas no utilizadas correctamente, eventos que comiencen por «Before» o «After», puesto que deben nombrarse conjugando verbos en función del momento que se producen (p.e., Closing y Closed en lugar de BeforeClose y AfterClose), y un largo conjunto de comprobaciones.



• Advertencias de rendimiento, que ayudan a detectar problemas en el rendimiento de la aplicación o librería, comprobando puntos como el número de variables locales usadas, la existencia de miembros privados o internos (a nivel de ensamblado) no usados, creación de cadenas (strings) innecesarias, por llamadas múltiples a ToLower() o ToUpper() sobre la misma instancia, realización de conversiones (castings) innecesarios, concatenaciones de cadenas en bucles, etc.



• Advertencias de portabilidad, que recoge observaciones interesantes para la portabilidad a distintas plataformas, como el uso de declaraciones PInvoke.



• Advertencias de seguridad, que se centran en analizar aspectos que podrían dar lugar a aplicaciones o librerías inseguras, avisando de problemas potenciales como la ausencia de directivas de seguridad, punteros visibles, o uso de arrays de sólo lectura, entre otros.



• Advertencias de uso, que analizan el uso apropiado del framework .Net realizando multitud de chequeos sobre el código, detectando aspectos como ausencia la liberación (dispose) explícita de tipos IDisposable, resultados de métodos no usados, uso incorrecto de NaN, etc.

(Puedes ver la lista completa de comprobaciones, en inglés, aquí)

Realizar un análisis de un ensamblado con FxCop resulta de lo más sencillo. Basta con crear un proyecto (al iniciar la aplicación aparecerá uno creado por defecto), añadir los ensamblados a analizar y pulsar el botón que iniciará el proceso.

El tiempo dependerá del número y complejidad de los ensamblados a analizar, así como del conjunto de reglas (pestaña «rules») a aplicar, que por defecto serán todas. En cualquier caso, el proceso es rápido y finalizará con la presentación de una lista con el resumen de las anomalías detectadas, sobre la que podremos navegar y ampliar información.


Por cada anomalía, además, podremos acceder a una descripción completa de sus causas, origen en el código fuente, posibles soluciones, una URL para ampliar información, grado de certeza de existencia del problema, su gravedad y la categoría a la que pertenece. Con estos datos, sólo nos quedará acudir a nuestro código y corregir o mejorar los aspectos indicados.

En conclusión, se trata de una interesante herramienta que puede ayudarnos a mejorar la calidad del código que creamos. Aunque existen los «falsos positivos» y a veces no es todo lo precisa que debiera, la gran cantidad de comprobaciones que realiza, la posibilidad de añadir reglas personalizadas, así como el detalle de los informes de resultados hacen de ella una utilidad casi imprescindible para los desarrolladores .Net.

Publicado originalmente en: http://www.variablenotfound.com/.

Hace unos meses, el blog Inter-Sections publicó un interesante post donde el autor recogía las conclusiones obtenidas a partir de su experiencia desarrollando y seleccionando personal, respecto a cómo reconocer a los buenos desarrolladores.

Esta información, además, ha sido complementada con decenas de comentarios de lectores a raíz de su reciente aparición en Slashdot, convirtiéndose en un artículo muy recomendable para los que estamos en el mundo del desarrollo de software y vemos lo complicado que resulta a veces dar con las personas apropiadas. Y es que la contratación del personal adecuado es un factor clave para el éxito (y a veces supervivencia) en una empresa de software, cuya actividad se basa en gran medida en el talento de sus desarrolladores.

Los indicadores clave que, según Daniel, nos pueden ayudar a detectar a los buenos desarrolladores de software se agrupan en los siguientes puntos:

1. son apasionados por el desarrollo
   
2. son autodidactas y les encanta aprender
   
3. son inteligentes
   
4. normalmente tienen experiencia oculta
   
5. son conocedores de tecnologías variadas y punteras
   
6. por último, aporta lo que en su opinión no es en absoluto determinante: la titulación.

Estos se concretan en un resumen final de características positivas y negativas, casi un checklist, que nos podrían ayudar a detectar comportamientos y actitudes clave:

Indicadores Positivos (propios de los buenos desarrolladores)

1. Apasionado por la tecnología
   
2. Programa por hobby
   
3. Capaz de hablar durante horas sobre temas técnicos si se le anima
   
4. Lleva (y ha llevado) a cabo proyectos personales
   
5. Aprende nuevas tecnologías por su cuenta
   
6. Opina sobre las tecnologías apropiadas en cada caso
   
7. Se siente poco cómodo usando tecnologías que no considera correctas
   
8. Es claramente inteligente, se puede conversar con él de muchos temas
   
9. Comenzó a programar mucho antes de ir a la universidad o empezar a trabajar
   
10. Tiene «icebergs» ocultos, grandes proyectos y actividades personales que no aparecen en el currículum.
    
11. Conoce gran variedad de tecnologías, que pueden no encontrarse reflejadas en el CV.

Indicadores Negativos (propios de los no tan buenos desarrolladores)

1. Ve la programación simplemente como su trabajo
   
2. No habla de programación fuera del trabajo
   
3. Aprende nuevas tecnologías exclusivamente en cursos ofrecidos por la empresa
   
4. Se siente cómodo con la tecnología que se les imponga, piensa que cualquiera es buena
   
5. No parece ser muy inteligente
   
6. Comenzó a programar en la universidad
   
7. Toda su experiencia en programación está en su currículum
   
8. Está centrado exclusivamente en una o dos tecnologías

En mi opinión, aunque la lista incluye puntos interesantes y acertados, y puede sernos útil como base para la reflexión, el tema creo que es mucho más complejo. Seguro que cada uno de nosotros podría matizar los puntos, eliminarlos o ampliar las listas, tal y como se pone de manifiesto en los comentarios del post, partiendo de nuestras propias experiencias y convicciones.

Por ejemplo, desde mi punto de vista, los indicadores positivos podríamos ampliarlos mucho; los buenos desarrolladores deben mostrar, aparte de las habilidades y actitudes ya citadas, otras comentadas por aquí hace tiempo como capacidad de comunicación e integración en equipos de trabajo, responsabilidad, compromiso, interés y cariño por el resultado de los productos que uno genera, habilidades literarias, curiosidad y seguro que un larguísimo etcétera. Además, pueden producirse falsos positivos; como muestra, decir que es bueno ser un apasionado del desarrollo, pero este hecho no garantiza el ser un gran desarrollador.

En el grupo de los indicadores negativos podríamos añadir, por ejemplo, los inversos de las características anteriores (incapacidad de hacerse responsable de algo, falta de cuidado en los resultados…), o matizar las recogidas por Daniel. Por ejemplo, estar centrado exclusivamente en una o dos tecnologías puede ser indicador de una gran especialización, o tener intereses y hobbies ajenos a la programación puede ser muy beneficioso para los profesionales que nos dedicamos a esto.

Y es que también hay que tener en cuenta que no es lo mismo ser un gran desarrollador en tu casa, como hobby, que serlo en una empresa. He conocido magníficos desarrolladores que según estos indicadores no parecerían pasar de la mediocridad, al igual que otros que aún cumpliendo la mayoría de los puntos positivos adolece de otras características, como habilidades de trabajo en equipo o actitudes elitistas, que lo hacen absolutamente inútil en una compañía de producción de software en el que tendrá que trabajar codo con codo con sus compañeros.

En cualquier caso, se trata siempre de características difíciles de percibir por la empresa vía el tradicional currículum y de ahí la necesidad de contar con medios complementarios como los blogs (sabéis que tengo la certeza de que los blogs ayudan a encontrar empleo), o realizar entrevistas y pruebas de nivel cada vez más complejas.

Publicado en: http://www.variablenotfound.com/.

Visual
Basic .NET 9.0, disponible con Visual Studio 2008, incluye, al igual
que C# 3.0, multitud de novedades y mejoras que sin duda nos harán la
vida más fácil.

Una de ellas es la posibilidad de declarar
variables sin necesidad de indicar de forma explícita su tipo, cediendo
al compilador la tarea de determinar cuál es en función del tipo de
dato obtenido al evaluar su expresión de inicialización. El tipado
implícito o inferencia de tipos también existe en C# y ya escribí sobre ello hace unos días, pero me parecía interesante también publicar la visión para el programador Visual Basic y las particularidades que presenta.

Gracias a esta nueva característica, en lugar de escribir:

  Dim x As XmlDateTimeSerializationMode = XmlDateTimeSerializationMode.Local
  Dim i As Integer = 1
  Dim d As Double = 1.8

podremos utilizar:

  Dim x = XmlDateTimeSerializationMode.Local
  Dim i = 1
  Dim d = 1.8

El
resultado en ambos casos será idéntico, ganando en comodidad y
eficiencia a la hora de la codificación y sin sacrificar los beneficios
propios del tipado fuerte.

Hay un detalle importante que los
veteranos habrán observado: Visual Basic ya permitía (y de hecho
permite) la declaración de variables sin especificar el tipo, de la
forma Dim i = 1 (con Option Strict Off), por
lo que podría parecer que el tipado implícito no sería necesario. Sin
embargo, en este caso los compiladores asumían que la variable era de
tipo Object, por lo que nos veíamos obligados a realizar
castings o conversiones en tiempo de ejecución, penalizando el
rendimiento y aumentando el riesgo de aparición de errores imposibles
de detectar en compilación. Tampoco tiene nada que ver con tipados
dinámicos (como los presentes en javascript), o con el famoso tipo Variant
que estaba presente en Visual Basic 6; el tipo asignado a la variable
es fijo e inamovible, como si lo hubiésemos declarado explícitamente.

En Visual Basic 9, siempre que no se desactive esta característica incluyendo la directiva Option Infer Off
en el código, el tipo de la variable será fijado justo en el momento de
su declaración, deduciéndolo a partir del tipo devuelto por la
expresión de inicialización. Por este motivo, la declaración y la
inicialización deberán hacerse en el mismo momento:

  Dim i = 1 ' La variable "i" es Integer desde este momento

  Dim j     ' La variable "j" es Object, como siempre, 
  j = 1     ' ... si Option Scrict está en Off. 
            ' En caso contrario aparecerá un error de compilación.

El tipado implícito puede ser asimismo utilizado en las variables de control de bucles For o For Each, haciendo su escritura mucho más cómoda:

 
  Dim suma = 0
  For i = 1 To 10       ' i se está declarando ahí mismo como Integer,
    suma += i           ' no existía con anterioridad
  Next

  Dim str = "abcdefg"
  For Each ch In str    ' ch se declara automáticamente como char,
      Console.Write(ch) ' que es el tipo de los elementos de "str"
  Next

 
Y
también puede resultar bastante útil a la hora de obtener objetos de
tipos anónimos, es decir, aquellos cuya clase se define en el mismo
momento de su instanciación, como en el siguiente ejemplo:

  Dim point = New With {.X = 1, .Y = 5}
  point.X += 1
  point.Y += 1

Por
último, es interesante comentar que, a diferencia de C#, Visual Basic
permite declarar en la misma línea distintas variables de tipo
implícito, por lo que es posible escribir Dim k=1, j=4.8, str="Hola"
sin temor a un error en compilación, asignándose a cada una de ellas el
tipo apropiado en función de su inicialización (en el ejemplo, Integer, Double y String respectivamente).

Coinciden,
sin embargo, en que en ambos lenguajes esta forma de declaración de
variables se aplica exclusivamente a las locales, es decir, aquellas
cuyo ámbito es un método, función o bloque de código. No pueden ser
propiedades ni variables de instancia; en el siguiente ejemplo, x será declarada de forma implícita como Object, mientras que el tipo de la variable y será inferido como Integer:

  Public Class Class1
    Dim x = 2        ' Es una variable de instancia
    Public Sub New()
        Dim y = 2    ' Es una variable local
    End Sub
  End Class

 
En
resumen, se trata de una característica muy útil que, además de
permitirnos programar más rápidamente al ahorrarnos teclear los tipos
de las variables locales, actúa como soporte de nuevas características
del lenguaje y la plataforma .NET, como el interesantísimo Linq.

Es
conveniente, sin embargo, utilizar esta característica con cordura y
siendo siempre conscientes de que su uso puede dar lugar a un código
menos legible y generar errores difíciles de depurar. De hecho,
Microsoft recomienda usarlas «sólo cuando sea conveniente».

Publicado en: Variable Not Found.