Published 17 years ago
(updated 13 years ago)
¿Estructurada, POO o Scripts?
Nuestro gremio se caracteriza por conformarse por dos principales perfiles: Autodidactas y escolarizados. Esto obedece a que el campo es aún novedoso, y es aún posible para un aficionado ir obteniendo de manera gradual e independiente los conocimientos para llegar a un nivel de competencia comparable con quien estudió una carrera formalmente.
El programador autodidacta típicamente es un miembro muy valioso del equipo de desarrollo, dado que llegó a acumular sus conocimientos -teóricos y prácticos por motivación propia. Si bien es común que su formación muestre importantes “agujeros” cognitivos en aquellos campos que requieren mayor rigor teórico/matemático, o en aquellos por donde el interés no lo llevó, comúnmente los subsanará tan pronto se enfrente a situaciones que los requieran. Sin embargo, es justamente en las áreas más teóricas y áridas del cómputo donde hay una mayor proporción de profesionales con éste perfil.
No puede ser casualidad que dentro de los desarrolladores de Software Libre haya tan alta proporción de autodidactas, gente formada en otras disciplinas, que ha ido encontrando su nicho de interés y trabajo en el cómputo, encontrando que en la creación de herramientas cubran sus necesidades particulares de una nueva vocación.
Podríamos dedicar un amplio espacio a analizar la relación entre el conocimiento adquirido formal e informalmente, y en cómo insertar a estos en un esquema académicamente más formal... Pero el tema del que quiero ocuparme en esta ocasión es de quien viene de una enseñanza escolarizada.
¿Cómo transmitir el conocimiento, el interés y el entusiasmo, a los programadores escolarizados, para que alcancen un nivel de habilidad similar al de los autodidactas? Para esto, es fundamental que nos preguntemos, ¿qué y cómo enseñan a los alumnos las universidades en nuestro País, las carreras relacionadas con el cómputo? ¿Qué perfiles reales de egreso hay de cada una de estas carreras (desde la Licenciatura en Informática Administrativa, pasando por las Ingenierías, con perfiles orientados más hacia Sistemas, Electrónica u otras variantes, y hasta las Ciencias de la Computación)? ¿Y cómo explicamos que, a la hora de buscar un trabajo, tan frecuentemente todos son puestos dentro de la misma bolsa?
El primer obstáculo al que creo todos los programas académicos deben reaccionar es que, muchos alumnos sienten que programar es una tarea tediosa, un rol que se verán forzados a desempeñar durante los primeros años de su trabajo, en lo que logran un ascenso a un puesto de “responsabilidad”. Esto es, en buena medida, por lo torpe que resulta la enseñanza de los conceptos y habilidades básicos de la programación.
Hay dos escuelas básicas: Comenzar enseñando programación utilizando un lenguaje mínimo aunque completo, apto para transmitir los fundamentos de la estructura y el control de flujo (al estilo de C o del venerable Pascal). En contraposición a ellos, muchos otros académicos defienden comenzar enseñando con un paradigma completamente POO, con lenguajes como Java o como C#. Y ambas alternativas nos dejan importantes huecos por llenar.
Para alguien que inició con lenguajes de muy alto nivel, resulta más difícil comprender la traducción a código de más bajo nivel y la implementación en hardware del mismo, especialmente lo relativo a administración de memoria y el órden de complejidad; en este sentido, una de las más brillantes exposiciones la hace Ulrich Drepper, en su texto “What Every Programmer Should Know About Memory” 1.
Para todas las aplicaciones que corren
“cerca del metal”, como desarrollos de sistemas tiempo real, embebidos, controladores de hardware o software orientado al alto rendimiento, es fundamental dominar estos temas.
Por otro lado, para los programadores que parten de un entorno meramente procedimental, la POO se presenta como una complejidad adicional, un obstáculo para la manera que tienen y conocen de solucionar los problemas.
Si bien la discusión académica respecto a estas dos escuelas está tan viva como cuando se planteó por primera vez hace más de 20 años (p.ej. 2 y sus respuestas en3), creo yo que el problema de la motivación reside en no enfocarnos en lenguajes y marcos “simples” (sin ser de juguete), que no permiten al alumno experimentar la “gratificación instantánea” de lograr resultados atractivos tras apenas un primer acercamiento. Los lenguajes denominados “de scripts” (Python, Ruby, Perl, y un largo etcétera) deben ser enseñados de otra manera, mucho más gradual, pero sin duda ayudan a mantener alta la motivación y baja la frustración.
Pero... ¿No son lenguajes con relativamente baja penetración corporativa? Así es, y eso representa otra ventaja - Una de las principales cualidades de un programador debe ser la capacidad de aprender tecnologías nuevas. Al enseñar con herramientas distintas, ayudamos a que los estudiantes desarrollen la importante habilidad de “aprender a aprender”, no encasillarse en una herramienta. ¡Que se hagan el hábito de aprender nuevos lenguajes para diferentes retos!
Referencias
[ 1. Drepper, Ulrich. “What Every Program-
mer Should Know About Memory”people.
redhat.com/drepper/cpumemory.pdf ]
[ 2. “Just say ‘A Class Defines a Data Type’”,
mags.acm.org/communications/200803 ]
[ 3. “Forum” ,
mags.acm.org/communications/200805 ]
Nuestro gremio se caracteriza por conformarse por dos principales perfiles: Autodidactas y escolarizados. Esto obedece a que el campo es aún novedoso, y es aún posible para un aficionado ir obteniendo de manera gradual e independiente los conocimientos para llegar a un nivel de competencia comparable con quien estudió una carrera formalmente.
El programador autodidacta típicamente es un miembro muy valioso del equipo de desarrollo, dado que llegó a acumular sus conocimientos -teóricos y prácticos por motivación propia. Si bien es común que su formación muestre importantes “agujeros” cognitivos en aquellos campos que requieren mayor rigor teórico/matemático, o en aquellos por donde el interés no lo llevó, comúnmente los subsanará tan pronto se enfrente a situaciones que los requieran. Sin embargo, es justamente en las áreas más teóricas y áridas del cómputo donde hay una mayor proporción de profesionales con éste perfil.
No puede ser casualidad que dentro de los desarrolladores de Software Libre haya tan alta proporción de autodidactas, gente formada en otras disciplinas, que ha ido encontrando su nicho de interés y trabajo en el cómputo, encontrando que en la creación de herramientas cubran sus necesidades particulares de una nueva vocación.
Podríamos dedicar un amplio espacio a analizar la relación entre el conocimiento adquirido formal e informalmente, y en cómo insertar a estos en un esquema académicamente más formal... Pero el tema del que quiero ocuparme en esta ocasión es de quien viene de una enseñanza escolarizada.
¿Cómo transmitir el conocimiento, el interés y el entusiasmo, a los programadores escolarizados, para que alcancen un nivel de habilidad similar al de los autodidactas? Para esto, es fundamental que nos preguntemos, ¿qué y cómo enseñan a los alumnos las universidades en nuestro País, las carreras relacionadas con el cómputo? ¿Qué perfiles reales de egreso hay de cada una de estas carreras (desde la Licenciatura en Informática Administrativa, pasando por las Ingenierías, con perfiles orientados más hacia Sistemas, Electrónica u otras variantes, y hasta las Ciencias de la Computación)? ¿Y cómo explicamos que, a la hora de buscar un trabajo, tan frecuentemente todos son puestos dentro de la misma bolsa?
El primer obstáculo al que creo todos los programas académicos deben reaccionar es que, muchos alumnos sienten que programar es una tarea tediosa, un rol que se verán forzados a desempeñar durante los primeros años de su trabajo, en lo que logran un ascenso a un puesto de “responsabilidad”. Esto es, en buena medida, por lo torpe que resulta la enseñanza de los conceptos y habilidades básicos de la programación.
Hay dos escuelas básicas: Comenzar enseñando programación utilizando un lenguaje mínimo aunque completo, apto para transmitir los fundamentos de la estructura y el control de flujo (al estilo de C o del venerable Pascal). En contraposición a ellos, muchos otros académicos defienden comenzar enseñando con un paradigma completamente POO, con lenguajes como Java o como C#. Y ambas alternativas nos dejan importantes huecos por llenar.
Para alguien que inició con lenguajes de muy alto nivel, resulta más difícil comprender la traducción a código de más bajo nivel y la implementación en hardware del mismo, especialmente lo relativo a administración de memoria y el órden de complejidad; en este sentido, una de las más brillantes exposiciones la hace Ulrich Drepper, en su texto “What Every Programmer Should Know About Memory” 1.
Para todas las aplicaciones que corren
“cerca del metal”, como desarrollos de sistemas tiempo real, embebidos, controladores de hardware o software orientado al alto rendimiento, es fundamental dominar estos temas.
Por otro lado, para los programadores que parten de un entorno meramente procedimental, la POO se presenta como una complejidad adicional, un obstáculo para la manera que tienen y conocen de solucionar los problemas.
Si bien la discusión académica respecto a estas dos escuelas está tan viva como cuando se planteó por primera vez hace más de 20 años (p.ej. 2 y sus respuestas en3), creo yo que el problema de la motivación reside en no enfocarnos en lenguajes y marcos “simples” (sin ser de juguete), que no permiten al alumno experimentar la “gratificación instantánea” de lograr resultados atractivos tras apenas un primer acercamiento. Los lenguajes denominados “de scripts” (Python, Ruby, Perl, y un largo etcétera) deben ser enseñados de otra manera, mucho más gradual, pero sin duda ayudan a mantener alta la motivación y baja la frustración.
Pero... ¿No son lenguajes con relativamente baja penetración corporativa? Así es, y eso representa otra ventaja - Una de las principales cualidades de un programador debe ser la capacidad de aprender tecnologías nuevas. Al enseñar con herramientas distintas, ayudamos a que los estudiantes desarrollen la importante habilidad de “aprender a aprender”, no encasillarse en una herramienta. ¡Que se hagan el hábito de aprender nuevos lenguajes para diferentes retos!
Referencias
[ 1. Drepper, Ulrich. “What Every Program-
mer Should Know About Memory”people.
redhat.com/drepper/cpumemory.pdf ]
[ 2. “Just say ‘A Class Defines a Data Type’”,
mags.acm.org/communications/200803 ]
[ 3. “Forum” ,
mags.acm.org/communications/200805 ]
- Log in to post comments