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:
- Sistemáticamente identificar a los diseñadores líderes lo más pronto posible.
- Asignar un tutor de carrera para que sea responsable del desarrollo del prospecto y mantené un cuidadoso registro de todo.
- 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:
| execute single instruction |
1 nsec = (1/1,000,000,000) sec |
| fetch word from L1 cache memory |
2 nsec |
| fetch word from main memory |
10 nsec |
| fetch word from consecutive disk location |
200 nsec |
| fetch word from new disk location (seek) |
8,000,000nsec = 8msec |
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:
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)
Autor: Juan-Pierre Luminet
Autor: Isaac asimov
Autor: Claudia Piñeiro
Autor: Carlos Ruiz Zafón
Yo suelo consumir muchas novelas, no exageradamente muchas pero si más (creo) que la media (sin hacer muchas cuentas diría que entre 10 y 20 al año). Y nunca me había encontrada con una organizada de esta forma. Me encantó.
Hace un par de meses ya 
