News
Articles: Una experiencia docente...
Published: Sep 18, 2010 - 06:45 PM
Este es un correo que decidí enviar a la lista de profesores de la ECCI a pesar de estar siendo repetitivo.
Buenos días.
Quería compartir con ustedes este
artículo:
http://es.tldp.org/Presentaciones/200309hispalinux/15/15.pdf
Creo que no se puede exponer en palabras más claras, cuerdas y realistas cuáles son las características que debe tener un primer lenguaje de programación (ver apartado 2 del artículo). Está muy claro para mí que la presencia de Java en el mundo es una cuestión de mercadotecnia, y la presencia en el mercado o en el mundo, no puede, ni debe ser, un factor decisivo para escogerlo como primer lenguaje de programación (ya sea, para nuestros estudiantes o los de otras escuelas). [1]
Una de las cuestiones que más me molesta (y bastante) en este tema es que para graduarme de bachiller (ni siquiera estamos hablando de un nivel de posgrado, sino de formación básica) me obligaron a tomar un curso llamado "Organización de Lenguajes de Programación" (dicho sea de paso, lo disfruté mucho). Ahí aprendí a criticar los lenguajes de programación, a clasificarlos (desde diferentes puntos de vista), a entender que existen lenguajes que no son perfectos pero que son mejores en ciertos campos, etc. Sin embargo, cuando he hecho mis críticas a Java, siempre he obtenido la respuesta silenciadora y aplacadora. La primera vez que hice la observación de que se debería pasar Programación I a Python u otro lenguaje, en lugar de Java fue hace 7 o 5 años. En ese momento la propuesta era innovadora y visionaria... hoy sólo estaríamos copiando lo que han adelantado otros (y, sin embargo, aún así no lo hacemos). Es decir, seguimos atrasando algo que es importante, urgente e inevitable (tal vez, por falta de autocrítica y falta de objetivismo).
Muchas veces he escuchado argumentos que terminan rayando en el absurdo. Estos son algunos ejemplos (¡reales!):
- Críticas a los lenguajes interpretados (aunque los lenguajes interpretados se acercan más al tipo de ingeniería de software que se hace hoy día, es decir, desarrollo ágil, gracias a que permiten ciclos de desarrollo breves). Dicho sea de paso, Java es un lenguaje interpretado exactamente igual a PHP (con la diferencia que en PHP los generadores de lo que en la jerga de Java se llama bytecode son comerciales, no son libres).
- Que es muy elegante que un programa como el típico "Hola Mundo" deba ser escrito en una clase (algunos tienen "objetitis"). Aunque elegante = simple+poderoso = expresivo. Más sintaxis para una misma semántica no es más elegante. Inclusive, es mucha sintaxis para algo que es equivalente a un script dado que el método main debe ser static y no puede existir en una instancia.
- Que dado que los estudiantes aprendieron su lengua materna no son tontos y son capaces de lidiar con todas las incongruencias y contradicciones de Java (porque la lengua materna es más ambigua). Claro... por eso es que todos hablamos Chino, Francés, Inglés, Alemán, Griego, Suahili, Bribrí y otros con dominio maternal (es decir, podemos hacer chistes, conocemos expresiones familiares, etc.). Si mal no recuerdo, esa capacidad para aprender un idioma como lengua "materna" se termina entre los 7 o 9 años... y es un contexto muy diferente al del aprendizaje del primer lenguaje de programación (por otro lado, algunos adultos aún no dominan su propia lengua materna).
Argumentos académicos y prácticos no he escuchado. Voy a dar uno solo. Java es poco ortogonal. Es muy deseable la ortogonalidad en un lenguaje de programación (sobre todo para quienes están aprendiendo su primer lenguaje). La ortogonalidad de lenguajes es uno de los conceptos que aprendí en Organización de Lenguajes de Programación y que hoy me están obligando a olvidar. De hecho, aún recuerdo mi reacción y mi impresión cuando Adolfo Di-Mare utilizó la expresión ortogonalidad hablando de Perl (¿ángulos cuadrados en el lenguaje?, ¿de qué está hablando el profesor?). Hoy está claro para mí que se refería a la independencia de características o conceptos dentro del lenguaje, es decir, cuando no hay mezclas confusas de estas. [2] La ortogonalidad es necesaria, ya que, entre menos ortogonal sea una lenguaje más complicado y menos poderoso resulta (aunque parezca contradictorio). Por supuesto, algunas veces es bueno sacrificar ortogonalidad por intuitividad y flexibilidad.
Noten un ejemplo de la falta de ortogonalidad en Java, utilizando dos "características" o dos "conceptos" de Java, los condicionales y los enteros, además de dos operadores ('==' y '<').
En primer lugar, resulta que, tengo 3 maneras de definir el entero:
int a = 3;
/* Para mayor confusión del público de Java: */
Integer a = new Integer(3);
Integer a = 3;
Considerando que se utiliza el entero "objeto", la semántica esperada del operador == funciona únicamente en condiciones con "literales", con "primitivos" (más de la verborrea conceptual innecesaria de Java) o con objetos creados de manera especial (polimórfica), o sea, tenemos no-ortogonalidad. Alguien podría argüir que esto es obvio pues los objetos son referencias. Sin embargo, el lenguaje no es consecuente con esto pues el operador '<' no compara referencias mientras que el operador '==' sí y además la comparación con '==' compara valores cuando se trata de objetos inicializados de manera polimórfica (estamos hablando del objeto Integer). Así:
Integer a = 3;
Integer b = 3;
Integer c = new Integer(3);
Integer d = new Integer(3);
Integer e = new Integer(2);
int f = 3;
if (a == b) /* Verdadero, funciona como
esperado. */
System.out.println("a == b");
if (b == c) /* ¡Falso, no
funciona como esperado! */
System.out.println("b == c");
if (c == d) /* ¡Falso, no
funciona como esperado! */
System.out.println("c == d");
if (e < d) /* Verdadero, funciona como esperado (con la semántica de entero a pesar de ser referencias). */
System.out.println("e < d");
if (d == f) /* Verdadero, funciona como
esperado. */
System.out.println("d == e");
if (a == f) /* Verdadero, funciona como
esperado. */
System.out.println("a == e");Probablemente, quién ha leído hasta aquí me preguntaría, "¿usted le explica todo eso a sus estudiantes?" y luego me diría, "yo todas esas cuestiones las oculto". Es decir, para enseñar Java hay que buscar siempre la manera de simplificar las cosas en la lección magistral (inclusive existen artículos sobre esas "maromas" como si fuesen una gran cosa). Sin embargo, esa estrategia es un auto-engaño, el estudiante se va a topar con el problema se lo ocultemos o no. La prueba es que este ejemplo (tengo muchos) me lo encontré con mis estudiantes en un laboratorio. La solución la deduje rápidamente porque soy el profesor, entiendo el lenguaje y no estoy aprendiendo Java, sin embargo, no permite que los estudiantes se concentren en resolver el problema, sino que se deben concentrar en resolver el lenguaje. El error obliga a interrumpir el laboratorio y hacer una explicación para todos de la solución. Por otro lado, una gran mayoría de los estudiantes no va a entender la solución que es una conversión de tipo poco intuitiva:
if (b == (int) c)
if ((int) c == (int) d)
Una de las ventajas del curso de Principios de Informática (servicio) sobre el de Programación I (carrera) es que la mitad de las lecciones son laboratorios y estos permiten ver "en vivo" en donde cometen errores los estudiantes y cuáles son los defectos del lenguaje cuando se utiliza como primer lenguaje de programación. La ventaja también es una desventaja dado que implica que la teoría se debe impartir en la mitad del tiempo que se tiene para los estudiantes de Programación I.
Claro que muchos podrán decir también que el ejemplo que utilicé se soluciona utilizando siempre int (el dichoso "primitivo"). Sin embargo, la razón por la cual los estudiantes a quienes enseño utilizan Integer es para facilitar la sintáxis de la entrada de enteros:
int a =
Integer.parseInt(JOptionPane.showInputDialog(null,
"Digite entero a"));
vs
Integer a = new Integer(JOptionPane.showInputDialog(null,
"Digite entero a"));
De paso, aquí se puede notar como se hace difícil hacer algo tan simple como entrada y salida, una cuestión que es básica y, además, que enseñar Java implica enseñar dos paradigmas de programación: el orientado a objetos y el procedimental (volvimos atrás).
No entiendo como es posible que un lenguaje con un diseño tan estúpido sea tan popular (si no es por mercadotecnia). Lo que sí entiendo es que es importante que la ECCI tome medidas y haga cambios en la metodología de los primeros cursos de programación, sobre todo en cuanto a la herramienta principal del curso: el lenguaje.
Saludos cordiales a todos,
B.
[1] De hecho, mi opinión es que la compra de Sun Microsystems por parte de Oracle, fue prácticamente para controlar y poseer Java (no otros productos interesantes, aunque claro, eran un buen estímulo). Tanto es así, que Oracle demandó a Google por crear una versión propia de Java basada en un proyecto Apache.
[2] La definición formal de ortogonalidad en un lenguaje de programación está aquí: http://www.fh-jena.de/~kleine/history/languages/VanWijngaarden-MR76.pdf.
Ver el perfil de Braulio Solano Rojas