Hace un par de días se me ocurrió que el Flisol sería un buen ámbito para dar esta charla, así que me contacté con los organizadores a pesar de que ya había cerrado el llamado a charlas. Por suerte no tuvieron problemas en incluírme en la grilla.

Capturado el sábado 14 en la Feria del libro de Santa Fe. Versión en video de esta charla.

https://www.youtube.com/watch?v=hYXnjZJ0ygE

Luego de esto hicimos la presentación de la novela Xolopes.

Me desvela en la noche,

oscuro programa.

Códigos malévolos,

indescifrable anagrama.

Escribir instrucciones,

malditas sentencias.

Quien en un lugar programa,

en otro es ausencia.

Combinar comandos,

pensar algoritmos.

Manipular datos,

tipear a buen ritmo.

Exprime el cerebro,

modelando futuros.

La poesía se forma

de letras y números.

La noche no termina

hasta no verlo andando.

Máquina a cafeína

que sigue tipeando.

"Measuring programming progress by lines of code is like measuring aircraft building progress by weight."

• Bill Gatesy

De: http://www.junauza.com/2010/12/top-50-programming-quotes-of-all-time.html

Donkey, uno de los primeros programas de Bill Gates.

"Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program."

• Linus Torvalds

De: http://www.junauza.com/2010/12/top-50-programming-quotes-of-all-time.html

BTW, Linus tiene un libro llamado Just for fun.

Dijo nuestro escritor por excelencia:

"Uno llega a ser grande por lo que lee y no por lo que escribe."

BORGES, Jorge Luis

Escritor argentino.

Años más tarde, desde los más oscuros rincones de la web 2.0 y las redes sociales, el espíritu del poeta infunde a la juventud. Distinto oficio, misma verdad:

Los mejores programadores no son los que más código escriben, sino los que más código leen. @alejolp

Hace un par de días hablábamos con una compañera sobre NO USAR el tipo de datos float para manejar dinero:

>>> 0.1 + 0.3
0.40000000000000002

A no alarmarse, lo anterior sucede en todos los lenguajes de programación; aunque algunos lo ocultan más que otros. La charla terminó con la recomendación de revisar un sitio web que explica el tema de forma muy consisa:

What Every Programmer Should Know About Floating-Point Arithmetic

Además de explicar cómo funciona el tipo de datos float y cómo solucionar el problema, da machetes para varios lenguajes de programación (C#, Java, JavaScript, PHP y SQL).

Me sorprendió que no haya una para Python, por lo que seguí el mandato del autor del sitio web, fork me on github, y envié mis cambios. update: ya está disponible en el sitio web.

Siguiendo con el título del posts, me puse a buscar otros artículos con el formato: Lo que todo programador debería saber sobre... y encontré estos:

• The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
• What every programmer should know about memory
• What Every Developer Should Know About URLs

Cuando estamos programando, muchas veces necesitamos de un servidor de mails para que nuestro programa envíe todo tipo de mensajes: reportes de error, avisos, passowords luego de una gesistración, "contact us", etc...

Muchas veces no se tiene un servidor SMTP instalado en la computadora de desarrollo, pero si tenemos Python instalado, podemos ejecutar el siguiente comando y tener un servidor de prueba en el que en lugar de enviar los mails porla red, se imprimen por la salida standar:

python -m smtpd -n -c DebuggingServer localhost:25

Software does not make itself. Code does not spontaneously come from the ether of the universe.

El párrafo completo:

Software does not make itself. Code does not spontaneously come from the ether of the universe. Python is no exception to this rule. Since Python made its public debut back in 1991 many people beyond the BDFL (Benevolent Dictator For Life, Guido van Rossum) have helped contribute time and energy to making Python what it is today; a powerful, simple programming language available to all.

Fuente: http://python.org/dev/intro/

Esta es una traducción al español Argentino del famoso artículo de Peter Norvig Teach Yourself Programming in Ten Years. Hay una versión en español de España pero está desactualizada. Creo que es un artículo que cualquiera que gusta de la programación debería leer.

Aprendé a programar en diez años

Por Peter Norvig.  Teach Yourself Programming in Ten Years.

Traducción libre al español Argentino por Juan José Conti - actualizado con el original a Diciembre de 2009

Originalmente basado en la versión de Calos Rueda

¿Por qué están todos tan apurados?

Entrá a cualquier librería y vas a encontrar  Aprende Java en 7 Días y demás variaciones interminables ofreciendo enseñar Visual Basic, Windows, Internet, etc., en unos pocos días u horas. Yo hice la siguiente búsqueda avanzada (power search) en Amazon.com :

pubdate: after 1992 and title: days and (title: learn or title: teach yourself)

y obtuve 248 ítems de resultado. Los primeros 78 fueron libros de computación (el número 79 era Aprende Bengali en 30 días -- Learn Bengali in 30 days ). Remplacé "days" (días) por "hours" (horas) y sorprendentemente obtuve resultados similares: 253 libros más, con 77 libros de computación seguidos de Aprende Gramática y Estilo en 24 horas (Teach Yourself Grammar and Style in 24 Hours) en el número 78. Del total de los primeros 200, el  96% fueron libros de computación.

La conclusión es que, o bien la gente está muy apurada por saber de computadoras, o bien las computadoras son algo fabulosamente fácil de aprender, más que cualquiera otra cosa. No hay libros sobre cómo aprender Beethoven, o Física Cuántica, o incluso Estética Perruna en pocos días. Felleisen et al. asienten esta tendencia en su libro How to Design Programs, cuando dicen "La programación mala es fácil. Los idioitas pueden aprenderla en 21 días, incluso si son tontos" (original: "Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies.)

Analicemos lo que podría significar un título como Aprende C++ en Tres Días (Learn C++ in Three Days):

• Aprende: En 3 días no vas a tener tiempo de escribir varios programas significativos, y de aprender de tus aciertos y errores con ellos. No vas a tener tiempo de trabajar con un programador experimentado y entender lo que es vivir en un ambiente de C++. En resumen, no vas a tener tiempo de aprender mucho. Así que esos libros sólo podrán lograr una familiaridad superficial, no un entendimiento profundo. Como dijo Alexander Pope, poco aprendizaje es una cosa peligrosa.
• C++: En 3 días puedes aprender la sintaxis de C++ (si ya sabés otro lenguaje), pero no vas a poder aprender mucho sobre cómo usar el lenguaje. En síntesis, si fueras, digamos, un programador Basic, podrías aprender a escribir programas en el estilo de Basic usando la sintaxis de C++, pero no aprenderías para qué C++ es realmente bueno (o malo). Entonces ¿cuál es el punto? Alan Perlis dijo alguna vez: "Un lenguaje que no afecte tu manera de pensar acerca de la programación, no merece ser aprendido". Un objetivo posible es que tienes que aprender un poco de C++ (o más probablemente, algo como Visual Basic o JavaScript) porque necesitas tener una interface con una herramienta existente para realizar una cierta tarea. Pero entonces no estás aprendiendo cómo programar; estás aprendiendo cómo realizar esa tarea.
• en Tres Días: Desafortunadamente, no son suficientes, como se describe en la siguiente sección.

Aprendé a programar en diez años

Algunos investigadores (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) han mostrado que toma aproximadamente diez años desarrollar habilidades en cualquiera de una amplia variedad de áreas,  incluyendo jugar al  ajedrez, componer música, pintar, tocar el piano, operar un telégrafo, nadar, jugar al tenis, u investigar en neurosicología y topología. La clave es la práctica deliberada: no solo hacerlo una y otra vez, sino desafiarte con una tarea que es un poco más dificil que tu habilidad actual, intentando, analizando tu performance mientras lo hacés y corrigiendo cualquier error. Luego repetir. Y volver a repetir. Parece no haber atajos: incluso a Mozart, prodigio musical a los 4 años, le tomó 13 más empezar a producir música de calidad mundial. En otro género, parece que los Beatles llegan a escena apareciendo en el espectáculo de Ed Sullivan en 1964. Pero ellos habían estado tocando desde 1957, y aunque tenían una masa de seguidores desde antes, su primer gran éxito, Sgt. Peppers, apareció en 1967. Malcolm Gladwell reportó que un estudio en la Academia de Música de Berlín separó a los mejores, los del meido y los peores de la clase y les preguntó cuánto practicaban:

Todas las personas, las de los tres grupos, empezar a tocar casi al mismo tiempo (alrededor de la edad de 5 años). En esos primeros pocos años, todos practicaron casi la misma cantidad (dos o tres horas por semana). Pero a la edad de ocho, empezaro a surgir las verdaderas diferencias. Los estudiantes que terminarían en el mejor tercio de la clase empezaron a practicar más que los demás: seis horas a la semana a los nueve, ocho a los 12, 16 a los 14, y más y más hasta que a la edad de 20, los músicos elite alcanzaraon las 10000 horas de práctica en el curso de sus vidas. Los estudiantes que solo eran buenos sumaron 8000 horas y los futuros profesores de música solo 4000.

Entonces, deben ser esas 10000 horas, no los 10 años, el número mágico. Samuel Johnson (1709-1784) pensaba que llevaba más: "La excelencia en cualquier área solo puede lograrse con la labor de toda la vida; no debe ser comprada a un precio menor" . Y Chaucer (1340-1400) se quejaba de que  "la vida era muy corta, y el trabajo largo de aprender". Hipócrates (c. 400BC) es conocido por la frase "ars longa, vita brevis", qué es parte de una cita más larga: "Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile", que significa algo como "La vida es corta, el trabajo largo, la oportunidad fugaz, experimentar es traicionero, el juicio dificil". Aunque en Latin, ars puede significar tanto arte como trabajo, en el original griego "techne" solo puede significar "destreza", no "arte".

Aquí está mi receta para el éxito en programación:

• Interesate en la programación y programá, porque es divertida. Asegúrate de que siga siendo divertida, tanto que podrías invertir diez años haciéndolo.
• Habla con otros programadores. Lee otros programas. Esto es más importante que cualquier libro o curso.
• Programa. El mejor tipo de aprendizaje es aprender haciendo (learning by doing) . Para decirlo más técnicamente, "El máximo nivel de desempeño de los individuos en un dominio dado, no se logra automáticamente como función de experiencia extendida, sino que el nivel de desempeño puede incrementarse incluso en individuos altamente experimentados como resultado de esfuerzos deliberados por mejorar."(p. 366) y "el aprendizaje más efectivo requiere una tarea bien definida con un apropiado nivel de dificultad acorde con el individuo, retroalimentación informativa, y oportunidades de repetición y corrección de errores." (p. 20-21) El libro Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life es una interesante referencia sobre este punto de vista.
• Si querés, dedica cuatro o cinco años en una universidad (o más en una escuela de graduados). Esto te dará acceso a algunos posiciones que requieren credenciales, y te dará un entendimiento más profundo del campo, pero si no disfrutas la escuela, puedes (con algo de dedicación) obtener una experiencia similar trabajando. Como sea, la lectura de libros por sí sola no será suficiente. "La educación en computación no puede hacer a nadie un experto programador más que el estudio de pinceles y pigmentos puede hacer a alguien un pintor experto" dice Eric Raymond, autor de The New Hacker's Dictionary. Unos de los mejores programadores que yo haya contratado alguna vez tenía sólamente un grado de bachiller (High School); pero ha producido una gran cantidad de excelentes programas , tiene su propio grupo de noticias (news group) , y sin duda es mucho más rico de lo que yo llegue a ser.
• Trabajá en proyectos con otros programadores. Sé el mejor programador en algunos proyectos; sé el peor en otros. Cuando sos el mejor, ponés a prueba tus habilidades para liderar un proyecto y para inspirar a otros con tu visión. Cuando sos el peor, aprendés lo que los maestros hacen, y aprendes lo que a ellos no les gusta hacer (ya que te ponen a hacerlo a vos).
• Trabajá en proyectos después de otros programadores. Proponete entender un programa escrito por otra persona. Mirá cuánto toma entenderlo y hacele correcciones cuando los programadores originales no estén allí. Pensá cómo diseñar tus programas para facilitarles el trabajo a los que deban mantenerlo después de vos.
• Aprende por lo menos una media docena de lenguajes de programación.mIncluye uno con soporte para abstracciones de clases (como Java o C++), uno que dé soporte a la abstracción funcional (como Lisp o ML), uno que dé soporte a la abstracción sintáctica (como Lisp), uno que dé soporte a especificationes declarativas (como Prolog o plantillas C++), uno que dé soporte a corutinas (como Icon o Scheme), y uno que dé soporte al paralelismo (como Sisal).
• Recordá que hay una "computadora" en "ciencia de la computación". Conoce cuánto le toma a tu computadora ejecutar una instrucción, alcanzar una palabra de la memoria (con y sin cache), leer palabras consecutivas del disco, y ubicar una nueva localización en disco. (Respuestas más abajo)
• Participá de un plan de estandarización de algún lenguaje. Podría ser en el mismo comité ANSI C++, o podría ser simplemente decidir si tu estilo de codificación tendrá niveles de identación de 2 ó 4 espacios. Como sea, averiguá lo que les gusta a otras personas en un lenguaje, cómo lo perciben, y quizá incluso un poco de por qué lo perciben como lo hacen.
• Tené el buen juicio para lanzar el plan de estandarización del lenguaje tan pronto como sea posible.

Con todo lo anterior en mente, es cuestionable qué tan lejos puedes llegar sólo leyendo libros. Antes de que naciera mi primer hijo, leí todos los libros Aprende a (How To), y sin embargo me sentía como un tonto principiante. 30 meses después, cuando nació mi segundo hijo, ¿acaso regresé a los libros? No.

Al contrario, me apoyé en mi experiencia personal, que me resultó mucho más útil y confiable que las miles de páginas escritas por los expertos.

Fred Brooks, en su ensayo No Silver Bullets, identificó un plan de tres partes para encontrar grandes diseñadores de programas:

1. Sistemáticamente identificar a los diseñadores líderes lo más pronto posible.
2. Asignar un tutor de carrera para que sea responsable del desarrollo del prospecto y mantené un cuidadoso registro de todo.
3. Ofrecer oportunidades a los diseñadores en crecimiento para que interactúen y se motiven mutuamente.

Esto asume que algunas personas ya tienen las cualidades necesarias para ser grandes diseñadores; la tarea es persuadirlos apropiadamente.

Alan Perlis lo dice de manera más sucinta: "A cualquiera se le puede enseñar a esculpir: A Miguel Angel habría que habérsele enseñado cómo no hacerlo. Así pasa con los grandes programadores".

Así que adelante, compra ese libro de Java; probablemente obtendrás algo de él. Pero no cambiará tu vida o tus verdaderas habilidades como programador en 24 horas, días o incluso meses.

Referencias

Bloom, Benjamin (ed.) Developing Talent in Young People, Ballantine, 1985.

Brooks, Fred, No Silver Bullets, IEEE Computer, vol. 20, no. 4, 1987, p. 10-19.

Hayes, John R., Complete Problem Solver Lawrence Erlbaum, 1989.

Lave, Jean, Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life, Cambridge University Press, 1988.

Respuestas

Tiempos de demora de varias operaciones en una PC típica de 1GHz, verano de 2001:

Apéndice: Elección del lenguaje

Muchas personas me preguntaron qué lenguaje de programación deberían aprender primero. No hay una única respuesta, pero considerá estos puntos:

• Usá a tus amigos. Cuando me preguntan "qué sistema operativo debería usar, Windows, Unix, o Mac", mi respuesta suele ser : "usá lo que tus amigos usen". La ventaja que tenés de aprender de tus amigos compensará cualquier diferencia intrínsica entre  entre sistemas operativos o entre lenguajes de programación. También considerá a tus futuros amigos: la comunidad de programadores de la que vas a ser parte si continuás. ¿Tu lenguaje elejido tiene una comunidad amplia y en crecimiento o una pequeña y agonizante? ¿Hay libros, sitios web y foros en línea de dónde obtener respuestas? ¿Te caen bien las personas en esos foros?
• Mantenelo simple. Los lenguajes de programación como C++  y Java están diseñados para que desarrollen grandes equipos de programadores profesionales preocupados por la eficiencia en  tiempo de ejecución de su código. Como resultado, estos lenguajes tienen partes complicadas diseñadas para estas circunstancias. Vos estás preocupado en aprender a programar. No necesitás esas complicaciones. Querés un lenguaje diseñado para ser fácil de aprender y recordar para un programador nuevo.
• Jugá. ¿De qué forma preferirías aprender a tocar el piano: de la forma normal, interactiva, en la que escuchás cada nota inmediatamente después de apretar una tecla, o en modo "batch", solo escuchando las notas después de terminar de teclear una canción entera? Claramente, el modo interactivo hace que el aprendizaje de tocar el piano sea más fácil; también de la programación. Intentá con lenguajes que tengan un modo interactivo y usalo.

Con estos criterios, mis recomendaciones para un promer lenguaje de programacion serían Python o Scheme.Pero tus circunstancias pueden variar, y hay otras buenas opciones. Si tu edad es de un solo dígito, tal vez prefieras Alice o Squeak (aprendices mayores también apreciarían este). Lo importante es que hagas la elección y empieces.

Apéndice: Libros y otros recursos

Varias personas me preguntaron qué libros y páginas web utilizar para su aprendizaje. Repito que el aprendizaje solitario con un libro no es suficiente, pero puedo recomendar los siguientes:

• Scheme: Structure and Interpretation of Computer Programs (Abelson & Sussman) es probablemente la mejor introducción a la ciencia de la computación, y también enseña programación. Podés ver videos en línea de las clases basadas en el libro, así como el texto completo en línea. El libro es desafiante y puede desanimar a personas que podrían tener éxito con otro enfoque.
• Scheme: How to Design Programs (Felleisen et al.) es uno de los mejores libros sobre cómo realmente diseñar programas de forma elegante y funcional.
• Python: Python Programming: An Intro to CS (Zelle) es una buena introducción utilizando Python.
• Python: Varios tutoriales en línea disponibles en Python.org.
• Oz: Concepts, Techniques, and Models of Computer Programming (Van Roy & Haridi) es visto por varios como el sucesor moderno al libro de Abelson & Sussman. Es un tour por las grandes ideas de la programación, cubriendo un rango más amplio que Abelson & Sussman a la vez que es tal vez más fácil de leer y seguir. Usa Oz, un lenguaje que no es ampliamente conocido pero sirve de base para aprender otros lenguajes.

Notas

T. Capey señala que la página Complete Problem Solver en Amazon hoy tiene a los libros "Teach Yourself Bengali in 21 days" y "Teach Yourself Grammar and Style" bajo la sección "Los clientes que compraron este item, también compraron estos items". Supongo que una gran cantidad de personas que miran ese libro vienen de esta página. Gracias a Ross Cohen por ayudar con Hipócrates.

Peter Norvig (Copyright 2001)