PREGUNTAS FRECUENTES SOBRE PROGRAMACIÓN
¿Qué editor utilizas?
vi.
¿Cómo aprendo a programar?
Busca un amigo que sepa programar. Haz que te configuren un sistema que te permita editar y ejecutar programas. Utiliza cualquier lenguaje que te sugieran para un principiante (probablemente será Python o Ruby). Luego, consigue el libro de O'Reilly y empieza a trabajar con el mismo.
A medida que aprendas la mecánica de escribir y ejecutar un programa, empieza a pensar acerca de programas específicos que desees escribir. Eso te motivara a aprender más.
No empieces con un problema demasiado grande. Una buena manera de comenzar es tomar un programa existente y modificarlo para que haga algo nuevo.
Inicialmente tus programas serán feos, pero no te preocupes por eso. Todos lo son. Sólo sigue adelante, y mejorarán.
A medida que aprendas, encontrarás útil analizar programas que otros han escrito. Sin embargo, aprenderás más acerca de esto una vez que tú mismo hayas intentado programar.
Por último, encuentra amigos a los que les guste escribir programas. Ellos pueden responder a tus preguntas técnicas; obtendrás nuevas ideas al hablar con ellos; y serán el público de tus primeros esfuerzos.
¿Por qué aconsejas zambullirse de lleno en un proyecto de programación antes de planificarlo cuidadosamente?
Si estás tratando de resolver un problema simple, predefinido, como hacer una búsqueda en profundidad, pensar en todo de antemano no hace daño. Pero pocos problemas reales son así. En aplicaciones del mundo real, usualmente no sabes, al principio, el problema que estas tratando de resolver. Así que si pasas mucho tiempo planificando de antemano, con lo que terminas es con un plan minuciosamente detallado para resolver el problema equivocado.
Con problemas complejos, mal definidos, es mejor escribir un prototipo tan rápido como sea posible, ver que resulta estar mal en el mismo, y a continuación, cambiar tu definición del problema de acuerdo a ello.
A menudo, la razón por la que los programadores se ven empujados a la planificación no es que el problema lo requiera, sino que los gerentes de proyectos lo requieren. Tal vez los programadores deberian dar a los gerentes una elección explícita: ¿quieres que resuelva el problema de manera que te haga sentir bien, o de manera que arroje la mejor solución?
¿Por qué sigues insistiendo en Lisp?
Hay una serie de temas sobre los que insisto: que las empresas pequeñas hacen las cosas mejor que las grandes; que los cubículos no ayudan; que tienes que entender el diseño para ser un buen hacker; que la planificación está sobrevalorada. Esos no parecen tan evidentes, porque muchos lectores o no tienen una opinión previa, o ya estan de acuerdo.
No cuesta nada darse cuenta de que los cubículos no ayudan. Pocas personas tienen un interés personal en un estilo de oficina sobre otra. Pero todo el mundo tiene un interés personal en los lenguajes que ya conocen, porque (a) es mucho trabajo aprender un nuevo lenguaje, y (b) los lenguajes de programación dictan tu manera de pensar acerca de los programas, por lo que es difícil incluso concebir un lenguaje más potente que cualquiera al que estemos acostumbrados.
Desvalorizar el lenguaje de alguien se considera grosero, lo sé. Pero grosero no es lo mismo que falso. Y cualquier diseñador de lenguajes tiene que enfrentarse a preguntas incómodas, como cuáles lenguajes son mejores, y por qué, al igual que los proctólogos tienen que hacer cosas que se considerarian muy groseras si la gente ordinaria las hiciera.
¿No esta la programación orientada a objetos naturalmente adecuada para ciertos problemas?
Sí y no. Mucho de lo que parecen ser problemas OO resultan no serlo si tienes acceso aleatorio a los conceptos que en conjunto constituyen la esencia de la orientación a objetos.
Si estuviera escribiendo un programa CAD o una simulación, por ejemplo, probablemente utilizaría abstracciones OO (aunque probablemente acabaría creando mi propio modelo OO con macros en lugar de utilizar cualquier cosa que viniera con el lenguaje).
Pero si estuviera tratando de resolver el problema que un lector me envió como ejemplo canónico de un problema OO, no lo haría.
Supón que tienes n puertos de serie, cada uno de los cuáles puede hablar uno de los protocolos de k, y esto debe ser configurable en tiempo de ejecución.
Yo simplemente utilizaría un array de clausuras n-por-k para representar esto.
Traducido de Programming FAQ por Paul Graham. Traducción: Armando Alvarez
Traducido de Programming FAQ por Paul Graham. Traducción: Armando Alvarez